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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf