Re: beep+sasl+srp draft issues

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Hi Mike,

> > - We want to hash the userid in case the user types her
> > password into the "username" box. We could do this above
> > SASL-SRP or else could try get the SASL-SRP draft to include
> > the trick itself (I prefer the latter). Any opinions?
> >
> 
> As I've stated before, I've never felt this was necessary to do in the first place, so I'd say
> neither. If the password is entered in the "username" box, then I presume nothing would be entered
> in the "password" box.  

Well, I've done it myself with some apps.

> Can't the client just ensure that both fields are populated before
> communicating with the server. It just seems annoying as well for the server to have to key on the
> hash of the username.

I kind of think its cute though:-)

Best would be for this to be part of SASL-SRP - I'll ask the authors
what they think of that.

> > - The sacred-pdm draft had an "extra" rsa private key which
> > was used for signing credential uploads - do we want to
> > maintain this feature? (The reason for it was to make
> > it harder to benefit from stealing the server's database.)
> >
> 
> Where does the user obtain this key pair from?  >From the credential server? I'd prefer if the
> credential server didn't have to act like a CA as well. The user can just register one of their
> credentials for authenticating to the credential server, or use their password as for credential
> download.

The idea was that the user generated this key pair and probably only used 
it to secure credential uploads (though I think Radia was willing to 
consider the private key as "the credential" itself, i.e. no p#12s or CAs
needed at all).

> Thinking about how this might actually be built, the credential server might exist in the same
> organization as the user, and hence, could be initiated with the CA trust anchor, allowing the
> credential server to trust users issued certificates by this CA.

Something (I need) to think about.
 
> > - SASL-SRP makes it easy to authenticate and derive keys for
> > credential download, changes etc, but what about initial
> > registration? Is that to be offline only or do we need
> > to have a credential deposit operation that uses some other
> > "in-payload" security?
 
[...]
> Couldn't the client just anonymously register a set of
> credentials, establish a password, and thereafter, use that password for authenticating to obtain
> the registerd credentials.  I remember thinking about this before, but can't recall if concluded
> it was a good or bad idea....)

That's what I was getting at. I think it'd be good to include
this if possible (and secure!).

> > - The sacred-pdm draft had some notes about "away-from-home"
> > operation, which is harder using SASL (unless we put the
> > SASL PDUs in our payload as Magnus suggested). Do we want
> > to support this & if so, how?
> >
> 
> I'm not sure.

Me neither;-) I guess that we'll probably end up dropping this feature
unless people object. Be nice to have it if we could though, since 
otherwise the user has to somehow point the client s/w at the
right server which can be a problem when roaming.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com