Subject: Review Comments: draft-ietf-sacred-protocol-bss-00.txt

From: Dale Gustafson <[email-masked]>
Date: Mon, 03 Dec 2001 10:11:03 -0600

Hi Stephen,

( to the intended mailing list this time ...  :-)

A few comments on the latest revision of the SACRED protocol
specification.

2.1.4 Password Change

Perhaps the terminology can be clarified to differentiate the passwords
involved;  one password may be needed for the authentication/session
security method (when SRP-3 is used in this document); the other (2nd)
password is used to derive a secret key that provides persistent
encryption for the credential per se.

Some have suggested that server implementations may want to ensure the
two passwords are always the same (e.g., for user convenience).

From a security standpoint, it would be preferable that the server does
not need to have access to the credential password -- or at least the
protocol does not require the server to handle the password in it's
plain text form for change password (or any other) function.

2.1.5 Credential Upload

The current text uses different forms of the Upload request to;  add a
new credential, update (replace) an existing credential, or delete a
credential.  This seems like it could lead to confusion when multiple
credentials are being accessed from several internet devices.

Client software should be able to allow the user to clearly see/verify
what they are overwriting or deleting (assuming that such decisions are
not always easily reversed).

2.2 Session Security

Allowing clients to support either authentication/session security
method (and requiring servers to support both) is a big workability
improvement.

This is of paramount importance for SACRED because fitting all needed
functions into memory constrained ROM or firmware based internet devices
is often way harder than it looks.  We may want to add some words to
that effect.

2.4 Handling Multiple Credentials for an Account

Similar comment to 2.1.5.

Should be possible for the user to manage multiple credentials on a
server in a fairly controlled fashion.

3.2 Credential Format

The format for xbulk:pkcs-15 may need to be defined in this document
(if/as needed to satisfy current IETF guidelines for referenced
standards).

4. BEEP Profile for SACRED

Stephen mentioned recently that SACRED is using BEEP but the XML groups
appear to be committed to SOAP and SAML.

Since the transactions defined in this document are very simple
(generally, a one message client request with a one message server
reply), it's not clear to me how much elegance we need at the session
layer other than setting up a security environment to protect the
transaction data during network transfer and clearly identifying the
data types.

We began with the simple notion of requiring user login via secure
password (or equivalent method) to ensure credentials are delivered to
the rightful user and no others.  I assume we'd strongly prefer to
retain that level of functionality and flexibility.

Is BEEP the right direction here?

5. IANA Considerations

 ... IANA registers the BEEP profile specified in Section 4 ...

6. Security Considerations

No mention of the need to limit password guesses via the network.  We
really need to mention the different forms of password guessing that
should be limited by servers.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Dec 2001 16:23:25 +0000

Hi Dale,

> encryption for the credential per se.

How about referring to them as "account password" and "credential
password" according to context?
 
> two passwords are always the same (e.g., for user convenience).

I don't recall the suggestion that the server enforce this - wouldn't
that break the requirement that the server must not be required to
have access to the cleartext credential? 

> plain text form for change password (or any other) function.

Actually, the intent with the current draft was that the client could
control all of this - if the client wanted the two passwords to be the
same, it (the client) enforces that. Maybe more work's needed to do this
right?

> not always easily reversed).

Isn't the selector string enough? If not, then I'm not sure what you
mean. Maybe you could suggest what else should be done?

> (if/as needed to satisfy current IETF guidelines for referenced

Yes. Synchronizing with xkms will be needed if we stick with the
current approach.

> Is BEEP the right direction here?

That's a fair question. See my response to Gareth's earlier mail.

>  ... IANA registers the BEEP profile specified in Section 4 ...

Ta.

> should be limited by servers.

Fair enough. I'll add something in the next draft (but would appreciate
offers of text...)

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: Thu, 13 Dec 2001 13:46:57 -0600

Stephen,

A couple of responses inline.

Regards,

--dg

> password" according to context?

Done.

[...]

> mean. Maybe you could suggest what else should be done?

This appears be solved with Gareth and Magnus' most recent proposal:

 - each credential must have a selector (name)
 - version identifier = credential fingerprint
 - etc.

[...]

> Fair enough. I'll add something in the next draft (but would appreciate

suggested text:

V6.  An attacker can attempt to masquerade as a client in an attempt to get a
     server to reveal information that allows for a later dictionary attack on
     user credentials.

   - The use of the SRP strong password algorithm counters this to a great
extent.
     Additionally, credential servers MAY choose to provide mechanisms that
protect
     against online dictionary attacks against user account passwords, either by

     repeated access attempts to a single user account (varying the password) or
by
     attempting to access many user accounts using the same password.

BTW, implies we will need additional error status values such as:

 - account locked
 - please call your administrator
 - other / TBD

I agree with (somebody) that it's easiest to let the server send a small text
message to the user in any error response.