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:
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).
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. 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. I believe "SHOULD use
SASLprep" in SCRAM is a reasonable trade-off considering these factors.
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/
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf