Subject: RE: beep+sasl+srp draft issues

From: Mike Just <[email-masked]>
Date: Tue, 23 Oct 2001 08:15:56 -0400

Hi Stephen,

Some responses below.

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

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

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.

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

It could be offline (as initial authentication in CMP), or could be online,
with the user authenticating with their credentials. As I indicate above, in
an enterprise environment, the credential server could have a CA trust
anchor installed, allowing them to trust all certificates issued by this CA.
Users can then use their own authentication credentials to authenticate to
the credential server for initialization, and upload. (Download, of course,
would still have to be password based.)  

In case the user doesn't have such a relationship established with the
credential server, their likely needs to be some offline mechanism, e.g.
user registers with and obtains an "authentication code" from the credential
server.  (This assumes that the client must actually be properly identified
to the credential server.  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....)

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

Cheers,
Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2001 15:17:13 +0100

Hi Mike,

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

> 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.
 
> > to have a credential deposit operation that uses some other
 
[...]
> 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!).

> > to support this & if so, how?

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:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Magnus Nystrom <[email-masked]>
Date: Wed, 24 Oct 2001 10:07:27 +0200 (W. Europe Daylight Time)

Stephen, Mike, All,

On Tue, 23 Oct 2001, Stephen Farrell wrote:

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

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

Agreed, yes.

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

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