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

Hi Dale,

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

How about referring to them as "account password" and "credential
password" according to context?
 
> Some have suggested that server implementations may want to ensure the
> 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? 

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

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?

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

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?

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

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

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

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

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

Ta.

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

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