Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-sasl-scram-07

From: Alexey Melnikov <[email-masked]>
Date: Fri, 2 Oct 2009 18:14:47 +0100

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 <[email-masked]> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 2 Oct 2009 18:31:48 +0100

[...]
> -- 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?

Good point.

> Should the short-names be IANA registered to prevent
> this?

This is a good idea. I've added:
  Such alternative name SHOULD be registered in the IANA
  "Hash Function Textual Names" registry.

> (Should future names be limited to 9 chars?)

I would rather not put extra restrictions on another registry due to
limitations on SASL mechanism names.

I would also note that the likelyhood of registering another SCRAM
mechanism name is quite low, and the likelyhood of the conflict
described above is even lower, so I wouldn't worry too much about this
case anyway.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 2 Oct 2009 12:50:05 -0500

Hi Alexey,

Your responses in this and your other email address all of my comments.

Thanks!

Ben.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 13:17:26 -0500

> to proceed with SHA-1, because it is more frequently implemented in libraries

This matter has come up elsewhere, such as in the KRB-WG.  NIST has not
obsoleted the use of HMAC-SHA-1, though I don't have a reference handy
at the moment (but a quick search of the KRB-WG mailing list and, maybe,
the [email-masked] list should yield one).

> The latter. (This == Hi())

Incidentally, Hi() should be shown as taking the iteration count as an
argument.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 13:25:22 -0500

On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote:
> -- 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?

Good point.  With SCRAM as specified, a server cannot increase the
iteration count without somehow getting access to the cleartext
password.  If the server were to store SaltedPassword _and_
U_iteration_count (from Hi()'s internals), then the server could compute
a new SaltedPassword and U_iteration_count with a higher iteration
count.  However, the server isn't intended to store SaltedPassword,
rather, the server stores StoredKey and ServerKey, and there's a reason
for this: a server that's never authenticated a given user before cannot
impersonate that user, but if the server were to store SaltedPassword,
then the server could impersonate the user.

Thus, to "increase the iteration count over time" requires, effectively,
changing the user's password.  This is probably worth pointing out.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 15:59:21 -0500

> the [email-masked] list should yield one).

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

"After 2010, Federal agencies may use SHA-1 only for the following
applications: hash-based message authentication codes (HMACs); key
derivation functions (KDFs); and random number generators (RNGs).
Regardless of use, NIST encourages application and protocol designers to
use the SHA-2 family of hash functions for all new applications and
protocols."

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Oct 2009 00:24:31 +0100

[...]

>Incidentally, Hi() should be shown as taking the iteration count as an
Fixed in my copy.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Oct 2009 00:31:27 +0100

>changing the user's password.  This is probably worth pointing out.
I tried to clarify that.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 19 Oct 2009 16:48:57 -0500

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-sasl-scram-10
Reviewer: Ben Campbell
Review Date: 19 Oct 2009
IESG Telechat date: 22 Oct 2009

Summary:

This draft is ready for publication as a draft standard.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Oct 2009 08:18:03 -0500

On Oct 20, 2009, at 2:30 AM, Simon Josefsson wrote:

> Did you mean proposed standard?

Uhm, yes, sorry. I guess after typing "draft" once in the sentence I  
got carried away.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 20 Oct 2009 09:30:47 +0200

> None.

That is the shortest gen-art review I have seen.  Good work, SCRAM
authors!  :-)

/Simon