Re: beep+sasl+srp draft issues

Stephen, Mike, All,

On Tue, 23 Oct 2001, Stephen Farrell wrote:

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

But I agree with Mike. If the feature is needed, it is rather an
attribute of the SASL mechanism in question than inherent in the
protocol itself. I could well imagine cases were the SASL mechanism to
download your credentials is based on something stronger than
passwords and in those cases there would be no need for this, hence
the SACRED protocol should not require it.

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

Agreed, yes.

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

My conclusion here is to skip this extra key, and rely on the SASL
mechanism (which certainly can be a strong one in the case of uploads)
to authenticate the user. When I asked about this in July, Charlie K's
answer seemed to indicate that this was related to PDM -
"It exists so that someone who has read the PDM "public" credentials
stored on the server, but who does not know the user's password, can't
use that information to trick the server into replacing the user's
credentials with garbage. Details are in a paper Radia and I are
presenting at USENIX Security in August." - and, if we now go ahead
with the SASL approach we'll push this to the SASL mechanism level,
as I understand it.

-- Magnus
Magnus Nystrom
RSA Security