Re: beep+sasl+srp draft issues

Dale,

> > - 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?
> 
> preference 1)  skip it.  do appropriate UI checking in the client
> 
> preference 2)  send in hash(user-id) as part of SASL-SRP authenticated login
> sequence.

Ok - that's three opinions (more?)

> > - 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.)
> 
> Defeats one benefit of any strong-pw protocol which requires nothing to be
> preconfigured in the client.

It didn't require that. The idea was that the client generated the
key pair on the fly - the private being stored as an encrypted
part of the credential & the public being a clear part of the credential.
A client can then sign a credential upload & the server can verify
off-of the previous instance of that credential.

> > - 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?
> 
[...]
> I'd be inclined to stick with that for now although I can see the benefit of
> some type of self-registration feature.

That's the one I'm on about.

> > - 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?
> 
> Seems like an unnecessary complication.
> 
> Why can't the roaming user access the target credential server directly?
> Clearly, she can access lots of other things directly.

Probably can - if you know its name/address and there's no f/w in
the way. For someone roaming around inside an intranet both are 
issues (e.g. when I'm in our Boston office).

Stephen.

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