[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-sasl-scram-02
It's been a while since I read this, so I re-read it from scratch. Mostly
implementation may chose to use the same iteration count for all
account.) The server sends the salt and the iteration count to the
generic-message = attr-val *("," attr-val)
;; Generic syntax of any server challenge
;; or client response
I observe that gs2-header does not conform to "generic-message" if it
begins with "y" or "n". This inconsistency could be resolved by removing
"generic-message" from the document.
SASL Mechanisms registry. IANA is requested to prevent future
registrations of SASL mechanisms starting with SCRAM- without
consulting the SASL mailing list <ietf-sasl@xxxxxxx> first.
This at least needs to designate a successor review process if
ietf-sasl@xxxxxxx goes away. I'd also prefer the document enumerate
principles for when to allow registration. Personally, I consider
undesirable to have the family be large. I'd prefer it contain only
SCRAM-SHA-1, and in the future SCRAM-SHA-3 (with the -PLUS variants).
Perhaps we could briefly discuss this at the meeting.
I support advancement of this version of the document on the standards
I intend to implement it excluding section 8 and SASLprep. I will attempt
to implement channel bindings, but it has gotten fairly complex
particularly with all this stuff about different types of channel bindings.
I am unsure how difficult it will be to add channel binding support to NSS.
In the event I succeed with channel bindings, but subsequently experience
interoperability problems with channel bindings, I will remove all channel
binding support from my implementation.