Subject: beep+sasl+srp draft issues

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2001 11:21:50 +0100

All,

In transforming the sacred-pdm draft to the above, I've come 
across the following issues, about which I'd appreciate your 
feedback and/or ideas.

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

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

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

- 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 sure there'll be more as I go through it, but that's
enough for now.

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: Dale Gustafson <[email-masked]>
Date: Tue, 23 Oct 2001 10:16:50 -0500

Hi Stephen,

Comments inline.

Best Regards,

Dale Gustafson

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

Base-64 encode of the hashed user name should work fine with the SRP draft as
is.

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

Seems like time would be better spent protecting the server's database.

> to have a credential deposit operation that uses some other

I think we've previously agreed that the Admin <--> credential server interface
is out of scope for now (e.g., offline or server specific).

Implies that admin activities such as installing SRP info. that must be known
apriori by the server (user name, salt, password verifier, etc.) would not be
part of the credential exchange protocol.

I'd be inclined to stick with that for now although I can see the benefit of
some type of self-registration feature.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2001 16:43:35 +0100

Dale,

> preference 2)  send in hash(user-id) as part of SASL-SRP authenticated login

Ok - that's three opinions (more?)

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

> > to have a credential deposit operation that uses some other
[...]
> some type of self-registration feature.

That's the one I'm on about.

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Oct 2001 23:23:11 +0200

> Ok - that's three opinions (more?)

A minor point, but since SRP was designed to counter dictionary
attacks, the hash(user-id) "fix" might end up being less secure than
SRP, since you then can perform dictionary attacks on the
hash(user-id) value that is transfered.  This would probably only be a
practical problem if servers' blindly start to swap username/password
to "help" clueless clients/users, instead of failing. Perhaps that
wasn't the intention, and that servers MUST fail if they encounter
swapped username/password fields.

My point is that the hash(user-id) fix adds complexity that might
obscure what is really going on.  Maybe either ignore the problem, or
treat both username and password as sensitive information, instead of
chosing a weak scheme for one of the fields (username).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Oct 2001 12:49:58 +0100

All,

Here's what I take from the mail exchanges on these issues

> the trick itself (I prefer the latter). Any opinions?

We drop this & ask the SASL-SRP authors if they'll include it.
So this is closed.
 
> it harder to benefit from stealing the server's database.)

No-one argued to keep the "extra" key, so it's gone. However,
whether to allow support for something "better" than just SRP 
for uploads (e.g. signing) is still an issue - I'll think 
about this a bit more and send a separate mail.

> to have a credential deposit operation that uses some other

I wasn't clear describing this one: what I wanted to know was
whether we need to support a secure form of on-line user 
self-registration. (We clearly need to allow, but not specify 
mechanisms for, out-of-band/offline/bulk registration.)

I got the (not very strong:-) impression that folks do want to 
support this, so I'll try to include something.

> to support this & if so, how?

No-one so far seems to really need this, so I'll drop it
(but maybe leave some notes in an appendix in case it turns
up again later.)

Stephen.

---

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

Stephen,

Thanks for the summary. Just two more comments:

On Wed, 24 Oct 2001, Stephen Farrell wrote:

[...]
> about this a bit more and send a separate mail.

I think we certainly should _allow_ for alternate methods for the
upload. This could include a PKI-based upload, e.g. along the lines of
Mike Just's scenario were the user is in possession of a private key
certified by an authority trusted by the credential server. If SASL is
being used, this (allowing other methods) should be virtually a no-op.

> support this, so I'll try to include something.

That's fine, I should not prioritize this work however, as the focus
right now probably should be on the down- and up-load.(?)

-- Magnus