Subject: Re: beep+sasl+srp draft issues

From: Mike DeGraw-Bertsch <[email-masked]>
Date: Tue, 23 Oct 2001 14:31:49 -0400 (EDT)

(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

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 24 Oct 2001 14:06:01 -0400 (EDT)

Re: the mysterious encrypted private key in PDM.

The purpose of that was to make it so that someone couldn't use
a stolen copy of the server database to directly impersonate the user.

If we're only downloading credentials, this is not an important
property, since someone who stole the server's database already
has the credentials.

However, for "logging in" to the credential server for the purpose
of uploading new credentials, it seemed like a valuable property.

This property is known in the strong password biz as "the augmented property".
PDM accomplishes the augmented property with an RSA private key which
must be transmitted to the user, who can decrypt it with her password.
Someone who steals the server database cannot use it directly because
it requires knowing the user's password.

SRP accomplishes the augmented property by having the server store
g**W, where W is a hash of the password, and in the key generation
it requires the client to directly know W.

Since PDM was using an RSA key, we were saying that key could actually
be the user's credential. But SRP has no such quantity that gets
passed to the user, so with SRP it's just doing SASL-SRP which
authenticates to the credentials server and the credentials server
then transmits the credential. There's no option with SRP of having the
user already obtain the credential as part of the strong password
mechanism.

Radia