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

Stephen,

A couple of responses inline.

Regards,

--dg


Stephen Farrell wrote:

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

Done.

[...]

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

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

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

[...]

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

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.

> 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