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