Gen-ART LC Review of draft-ietf-sasl-scram-07

[Ben Campbell <ben at estacado.net>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.