Re: [sasl] Last Call: draft-ietf-sasl-scram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Simon Josefsson wrote:

I support publication of draft-ietf-sasl-scram.

I have implemented SCRAM in a beta version of GNU SASL [1], see [2], so
I have good confidence that the document is in sufficiently good
technical condition.

I have not yet managed to do interop testing with anyone else though.
Please contact me if you are implementing it and we haven't already
spoken about testing.

I have two remaining comments on the document:
Hi Simon,
Thank you for the comments.

1) This is an editorial issue.

The hashed password that needs to be stored with clients are either both
ClientKey and ServerKey OR only the SaltedPassword.  The SaltedPassword
can be used to compute ClientKey/ServerKey, so it may be preferable in
some situations where you only want to store one hash for the user.

OLD:
        client implementation MAY cache SaltedPassword/ClientKey for
NEW:
        client implementation MAY cache ClientKey/ServerKey (or just
        SaltedPassword) for

Also, clients may not need to have access to passwords if they have
access to the cached information.

OLD:
  To begin with, the SCRAM client is in possession of a username and
  password.
NEW:
  To begin with, the SCRAM client is in possession of a username and
  password (or a ClientKey/ServerKey or SaltedPassword).
I have no problems with these editorial changes.

2) This is a technical issue.

SCRAM does not say anything about the encoding used for the password
(e.g., Latin-1, UTF-8) or whether SASLprep should be applied to the
string or not.  I believe this violates this requirement in RFC 4422:

  In order to avoid interoperability problems due to differing
  normalizations, when a mechanism calls for character data (other than
  the authorization identity string) to be used as input to a
  cryptographic and/or comparison function, the specification MUST
  detail precisely how and where (client or server) the character data
  is to be prepared, including all normalizations, for input into the
  function to ensure proper operation.

  For simple user names and/or passwords in authentication credentials,
  SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
  algorithm), SHOULD be specified as the preparation algorithm.

For highest interoperability the document could do MUST use UTF-8 and
MUST use SASLprep.  I understand that some people will not implement
SASLprep, and I agree with them that there are valid reasons for not
implementing SASLprep (such as it being based on obsolete Unicode
versions), so I would be equally happy with MUST use UTF-8 and SHOULD
use SASLprep.  I don't think the requirement on SASLprep can be relaxed
further without breaking the requirements in RFC 4422.

Yes.

Personally, in
the long term I would prefer to deprecate SASLprep in favor of Net-UTF-8
(i.e., RFC 5198) for use in SASL applications.

Or we can revise SASLPrep.

I believe "SHOULD use
SASLprep" in SCRAM is a reasonable trade-off considering these factors.

Agreed.

For what its worth, my GNU SASL implementation supports SASLprep via GNU
Libidn [3] which implements SASLprep.  Libidn is free software, so
anyone is able to use it if they desire SASLprep support.

Thanks,
Simon

[1] http://www.gnu.org/software/gsasl/
[2] http://lists.gnu.org/archive/html/help-gsasl/2009-09/msg00003.html
[3] http://www.gnu.org/software/libidn/
_______________________________________________
sasl mailing list
sasl@xxxxxxxx
https://www.ietf.org/mailman/listinfo/sasl

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]