Re: [TLS] draft on new TLS key exchange

["Dan Harkins" <[e-mail]>]

  Hello,

On Wed, October 5, 2011 2:09 pm, Geoffrey Keating wrote:
> "Dan Harkins" <[e-mail]> writes:
>
>>          http://tools.ietf.org/html/draft-harkins-tls-pwd-00
>>
>>   Please take a look. The authors solicit comments.
>
> It would be helpful to have a comparison between this proposal and
> RFC5054, since both protocols appear to have the same aim ("secure
> authentication using only a simple, low-entropy, password").

  TLS is rife with drafts and RFCs that have the same aim but go about
it differently.

> Some features of RFC5054 I noticed that could be used to improve this
> draft are:
>
> - RFC5054 requires that the server store only the 'verifier', while
>   this protocol appears to require storing the plaintext password.
>   There doesn't seem to be any discussion on the risks of storing the
>   plaintext password or any mitigations (for example, using a salted
>   hash of the password instead of the password directly).

  Yes, I got another comment to add something to the security
considerations regarding compromise of the client and server. This
draft does not propose any protection against server compromise
the way RFC 5054 does. On the other hand, with this scheme one is not
required to fix a particular domain parameter set to a user at password
provisioning time. This allows for the choice of domain parameter set
to be based on the particular ciphersuite the server is proposing
to use (and removes a security critical decision from someone-- the
person provisioning the password on the server-- who might not have
the competence to make that decision).

  We could add some protection against server compromise by salting the
password when it is provisioned and sending the salt in the
ServerKeyExchange. The drawback to this is that the salting technique
has to be determined at provisioning time, but that's probably not that
big of a deal as the technique has no bearing on the security of the
underlying key exchange.

  Thanks for the suggestion!

> - RFC5054 already specifies an extension for the user name.  I would
>   suggest using the same extension for this protocol rather than
>   creating a new one.

  It's named "srp" though which makes it less desirable. We'll note your
suggestion but unless there is strong desire by the WG to change this
we'd like to keep it as is. There's 65k extensions available so exhaustion
of this resource is unlikely.

> - RFC5054 has test vectors, this draft doesn't.

  Another good suggestion. We'll add some.

  thanks,

  Dan.