Hi Ben, Thank you for your comments. Responding to most of them below (I will respond to the rest in a separate message). On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell <ben@xxxxxxxxxxxx> wrote: > 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? Yes. I've added forward references. [...] > 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? My understanding is that use of SHA-1 under HMAC is still considered reasonable. The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided to proceed with SHA-1, because it is more frequently implemented in libraries and hardware. > -- 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? The reference to RFC 4086 is already present elsewhere in the document, but I added it here. > -- Section 9, 1st paragraph: > > Can you describe the required properties expected from a "strong security > layer"? (i.e. confidentiality, integrity protection, etc.) I've added "(such as TLS with data confidentiality)". I hope this is clearer. [...] > --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? IPR claims on authentication mechanisms such as SRP. Text commenting on IPR was removed as per Pasi's request. > Nits/editorial comments: > > -- 1.1, 2nd bullet: Can you include an informational reference for RADIUS? Added. > -- 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? The latter. (This == Hi()) > -- 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? Deleted. > -- 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..." Yes. Changed. > -- IDNits reports the following: > > == Outdated reference: A later version (-03) exists of > draft-melnikov-sasl-scram-ldap-02 The two documents would be published simultaneously, so this will go away during editing by the RFC Editor. > 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. Right. Regards, Alexey _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf