Document: draft-ietf-sasl-scram-07
Reviewer: Ben Campbell
Review Date: 2009-08-23
IETF LC End Date: 2009-08-28
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as a proposed standard. I have a few questions and editorial comments that might be worth considering prior to publication.

Major issues:

None.


Minor issues:

- Section 2, 1st paragraph: "...addresses the requirements necessary to deploy a challenge- response mechanism more widely than past attempts."

What are these requirements? Are they documented somewhere? Do you mean for appendix A or B to express them?

-- section 4, first paragraph: "...as long as this alternative name doesn’t conflict with any other hash function name from the IANA "Hash Function Textual Names" registry."

What prevents future conflicts if someone registers a name that conflicts with the short name? Should the short-names be IANA registered to prevent this? (Should future names be limited to 9 chars?)

-- section 4, 2nd paragraph:

I'm no crypto expert, so please forgive me if this is silly--but isn't there a movement to phase out sha-1? If so, should that be the default "must implement" hash for a new mechanism?

-- section 5.1, definition of "r:", "It is important that this value be different for each authentication."

Are there any best practices for nonce generation that can be mentioned or referenced?

-- Section 9, 1st paragraph:

Can you describe the required properties expected from a "strong security layer"? (i.e. confidentiality, integrity protection, etc.)

-- 2nd paragraph: " ...increase the iteration count over time."

Can  you elaborate on how this helps, and possibly offer guidance on how implementations should use it?

--3rd paragraph:

I gather you are saying that there are techniques that mitigate the damage of a stolen authorization database, but the work group chose not to use them. Can you elaborate on the wg motivation for not doing so?



Nits/editorial comments:

-- 1.1, 2nd bullet: Can you include an informational reference for RADIUS?

-- 1.2, last bullet:

What is the referent for "this"? Is there perhaps a missing word(s), or maybe this paragraph belongs with the previous bullet?

-- 2, last paragraph:

Do you plan for this paragraph to stay in the RFC? Is the work group mail list permanent enough to be published in the RFC?

-- 5.1, definition of "c:", 2nd bullet: "(recall: a channel binding flag and an optional authzid.)

I'm not sure I follow the sentence. Do you mean to say something like "Recall the G2 header contains a..."




-- IDNits reports the following:

  == Outdated reference: A later version (-03) exists of
      draft-melnikov-sasl-scram-ldap-02

It also reports a number of false errors about undefined references. I think it's confused by your non-standard reference sections, which I think make sense under the circumstances.