Re: beep+sasl+srp draft issues

(Seems my initial message was blocked because I mailed from the wrong
acct--thanks for the note, Paul)

Howdy,

Some comments inline.  Forgize any ignorance on my part.

On Tue, 23 Oct 2001, Stephen Farrell wrote:

>  > > - 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?)

As a sysadmin, I'm not all that well versed in hash algorithms.  But if
the usernames are hashed, doesn't that present the possibility of unique
usernames generating the same hash key?  Granted, it's probably a remote
possilibity, but Users will always find a way.

>  > > - 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.

Will PDAs and cell phones, for example, be allowed to upload credentials?
(This would make sense to me--verifying, for instance, what your cell #
is)  If so, wouldn't this be a bit computationally harsh for them?

>  > > - 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).

I don't see why this would be a problem.  If the credential server is
(partially) exposed to the internet, and given a unique name
(credential-west.radioactivedata.org and
credential-east.radioactivedata.org, for example, if there are two
credential servers in a company), how does the firewall get in the way?

   -Mike DeGraw-Bertsch
    President
    Radioactive Data Research
    http://www.radioactivedata.org