Subject: [sasl] AD Review comments for draft-ietf-sasl-scram-05

From: <[email-masked]>
Date: Wed, 9 Sep 2009 12:51:00 +0200

I've now done my AD review for draft-ietf-sasl-scram-05.  
Basically, the document looks good, but has couple of places 
where some additional details are probably needed to ensure 
different implementors understand it the same way.

Most important first:

- Section 8.2: I was having some problems in figuring out how the
per-message tokens actually work -- probably this section could use
some further clarification. 

Is the "128-bit session key" the same thing that gets used as
"base-key" to derive Kc/Ke/Ki (RFC 3961 Section 5.3)? If it is, saying
so would be useful (and what is the "usage number" value to be used)?

In general, it seems this section should include pointers to specific
sections of RFC 4121 (probably at least 4.2.6.1 and 4.2.6.2), RFC 3961
(probably at least 5.3) and 3962 to help the reader find the relevant
parts for implementing the per-message tokens for SCRAM GSS-API
mechanism (most of these RFCs is not needed for that).

- Section 8.3: Is the key the same 128-bit session key as
in Section 8.2? (If it is, saying so here would help the reader.)

- Section 9: I would strongly suggest removing all mentions of IPR
disclosures (especially considering RFC 3979 Section 11), and instead
saying something like "the WG selected not to use EKE like mechanisms
as basis for SCRAM".

- Shouldn't the document title be "Salted Challenge Response (SCRAM)
SASL and GSS-API Mechanism" (to make it more obvious that it may be of
interest also to GSS-API users who don't use SASL)

- Section 10: "This document also requests IANA to assign a GSS-API
mechanism OID for SCRAM." Please give the registry name here.

- Should the document explicitly say the mechanism is client-first
(RFC 4422 Section 2, item 2a) or should this be obvious to the reader?

Couple of editorial nits:

Globally: s/[email-masked]/[email-masked]/
Section 3: s/chose/choose/
Section 10: s/"IETF Consensus"/"IETF Review" [RFC5226]/ (twice)

I think we should make a new version before going to IETF Last Call
(including Simon's suggestions, too), so I've changed the state
to "AD Evaluation::Revised ID Needed".
 
Best regards,
Pasi

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 11:39:24 -0500

> some further clarification. 

Well, we re-use the Kerberos V5 GSS-API mechanism's [RFC4121]
per-message tokens, using a single Kerberos enctype.  A required detail
is: how to derive the session key from which to derive the keys
mentioned in RFC4121, section 2 -- we provide that detail.

> so would be useful (and what is the "usage number" value to be used)?

It's the same thing that gets used in RFC4121, section 2:

"
2.  Key Derivation for Per-Message Tokens

   To limit the exposure of a given key, [RFC3961] adopted "one-way"
   "entropy-preserving" derived keys, from a base key or protocol key,
   for different purposes or key usages.

   This document defines four key usage values below that are used to
   derive a specific key for signing and sealing messages from the
   session key or subkey [RFC4120] created during the context
   establishment.

           Name                         Value
         -------------------------------------
          KG-USAGE-ACCEPTOR-SEAL         22
          KG-USAGE-ACCEPTOR-SIGN         23
          KG-USAGE-INITIATOR-SEAL        24
          KG-USAGE-INITIATOR-SIGN        25

   ...
"

The actual key derivation is then done as per-RFCs 3961 and 3962, with
the usage values from RFC4121.

> mechanism (most of these RFCs is not needed for that).

OK.

> in Section 8.2? (If it is, saying so here would help the reader.)

Yes.

> saying something like "the WG selected not to use EKE like mechanisms

I agree.

> interest also to GSS-API users who don't use SASL)

Yes, I think so!  It will help users of the RFC search tool in
particular.

> mechanism OID for SCRAM." Please give the registry name here.

IANA should use the iso.org.dod.internet.security.mechanisms prefix (see
smi-numbers, under "SMI Security for Mechanism Codes").

> (RFC 4422 Section 2, item 2a) or should this be obvious to the reader?

It wouldn't hurt to say it, no.  It was obvious to me, because GSS-API
mechanisms are always client sends first, and because the GS2 family of
SASL mechanisms is client sends first (and SCRAM is a member of that
family).  But yes, we should state that up front (and in the GS2
document as well).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 12:21:31 -0500

> It's the same thing that gets used in RFC4121, section 2:

I'm not sure that this needs clarifying, but the following text should
do it:

OLD:
   The 128-bit session key SHALL be derived by using the least
   significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
   key" || ClientKey || AuthMessage).

NEW:
   The 128-bit session "protocol key" SHALL be derived by using the
   least significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API
   session key" || ClientKey || AuthMessage).  "Specific keys" are then
   derived as usual as described by RFC4121 (section 2) and RFCs 3961
   and 3962.

   The terms "protocol key" and "specific key" are Kerberos V5 terms
   [RFC3961].

> > mechanism (most of these RFCs is not needed for that).

OLD:
   The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the
   same as those for the Kerberos V GSS-API mechanism [RFC4121], using
   the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].

NEW:
   The per-message tokens for SCRAM as a GSS-API mechanism SHALL be the
   same as those for the Kerberos V GSS-API mechanism [RFC4121] (see
   RFC4121, section 4.2, and sub-sections), using the Kerberos V5
   "aes128-cts-hmac-sha1-96" enctype [RFC3962].

> > in Section 8.2? (If it is, saying so here would help the reader.)

OLD:
   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().

NEW:
   The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
   the Kerberos V GSS-API mechanism [RFC4402].  There is no acceptor-
   asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
   GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
   The protocol key to be used for the GSS_Pseudo_random() SHALL be the
   same as the key defined in Section 8.2.

> smi-numbers, under "SMI Security for Mechanism Codes").

OLD:
   This document also requests IANA to assign a GSS-API mechanism OID
   for SCRAM.

NEW:
   This document also requests IANA to assign a GSS-API mechanism OID
   from the iso.org.dod.internet.security.mechanisms prefix (see "SMI
   Security for Mechanism Codes" registry).

> family).  But yes, we should state that up front (and in the GS2

Actually, we might want to have all of the responses to the RFC4422
section 5 requirements gathered into one section, no?

x.  Compliance with SASL mechanism requirements

   See RFC4422, section 5.

   1) "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS".
   2a) SCRAM is a client-first mechanism.
   2b) No.
       [Right?  The server-final-message does include an indication of
       success, but no further messag exchanges are then needed.
       Someone please confirm/deny my understanding of RFC4422 section
       5, item (2b) -Nico]
   3) SCRAM is capable of transferring authorization IDs from the client
      to the server.
   4) SCRAM does not offer any security layers (SCRAM offers channel
      binding instead).
   5) N/A.

(The above is not xml2rfc-formatted.)

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Sep 2009 21:09:11 +0100

>>saying something like "the WG selected not to use EKE like mechanisms
Done.

>Yes, I think so!  It will help users of the RFC search tool in
Changed.

>smi-numbers, under "SMI Security for Mechanism Codes").
Done.

>family).  But yes, we should state that up front (and in the GS2
Agreed.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Sep 2009 21:44:51 +0100

Hi Pasi,
Thank you for your review.

>(RFC 4422 Section 2, item 2a) or should this be obvious to the reader?
All of these were addressed as per Nico's reply.

Done.

>to "AD Evaluation::Revised ID Needed".
I will post a new version later today.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Sep 2009 22:29:05 +0100

Hi Nico,

>>On Wed, Sep 09, 2009 at 12:51:00PM +0200, [email-masked] wrote:
I used all your other changes.
 [...]

>   2a) SCRAM is a client-first mechanism.
Correct.

>       Someone please confirm/deny my understanding of RFC4422 section
The answer to the question is Yes: the last leg provides extra data for 
the client to mutually authenticate the server, but at this point 
authentication already completed successfully as far as the server is 
concerned.

Yes.

>   5) N/A.
Actually the answer is Yes, as there is a hash protecting the 
authorization identity.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 09 Sep 2009 17:50:17 -0400

> the usage values from RFC4121.

In other words, reading and implementing this document _requires_ reading 
and understanding substantial portions of RFC4121 (and, in turn, RFC3961), 
because the present protocol reuses pieces of that one which live below the 
abstraction.  The reuse is (IMHO) appropriate, and in fact we've reused 
those same pieces in several GSS-API mechanisms that have been discussed at 
various times and places.  However, such reuse is necessarily below the 
GSS-API abstraction, and thus, implementing one mechanism requires reading 
the spec for another.

>> mechanism (most of these RFCs is not needed for that).

Mostly, I agree; more precise pointers are generally useful, especially in 
the case of references to RFC4121, which has quite a few pieces that are 
not reused by SCRAM.

In the case of RFC3961, I'm not convinced that a reference to 5.3 is 
appropriate from anything other than an enctype specification.  Key usage 
numbers are introduced in section 2, "Concepts", and their use as input to 
the key derivation operation is described in section 3.  Section 5, 
including 5.3, describes a simplification which makes it easier to define 
new enctypes based on CBC-mode block ciphers; it lives below the 
abstraction seen by _users_ of RFC3961, including SCRAM.  An implementor of 
the AES enctypes described in RFC3962 would need to understand that 
document and all of RFC3961, including section 5.  But part of our hope in 
reusing RFC3961 is that people will reuse libraries which implement it.

So, precision in references to RFC3961 is fine, provided the reference is 
to the right place.  Implementors of SCRAM will need to understand RFC3961 
sections 1 through 4, I think, and to have code (new or reused) which 
implements the abstraction defined therein.

> Yes, I think so!  It will help users of the RFC search tool in

Sadly, it should probably be something like "Salted Challenge Response 
(SCRAM) Simple Authentication and Security Layer (SASL) and Generic 
Security Service Application Programming Interface (GSS-API) Mechanism", 
which is quite a mouthful.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 09 Sep 2009 17:57:23 -0400

>    The terms "protocol key" and "specific key" are Kerberos V5 terms

OK.  Properly they're RFC3961 terms, and not used above that abstraction, 
even in Kerberos itself.

>    "aes128-cts-hmac-sha1-96" enctype [RFC3962].

Yes, that's good.  Pretty much all of RFC3962 defines that enctype.

>    same as the key defined in Section 8.2.

This should be obvious, but spelling it out does no harm.
I think s/SHALL/is/, perhaps in both cases seen here.

>    4) SCRAM does not offer any security layers (SCRAM offers channel

Not by-number, no.  Like, what is "2b"?  I understand SASL, but to 
understand what this says I have to read it side-by-side with SASL.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 17:05:13 -0500

> OK.  Properly they're RFC3961 terms, and not used above that abstraction, 

Right.  Pasi's point is a good one though, that a few breadcrumbs to
lead readers unfamiliar with Kerberos to the right places would be good.

> I think s/SHALL/is/, perhaps in both cases seen here.

Heh.  I wrote it out both ways and thought about it, and though the
"SHALL" is redundant to anyone familiar with RFCs 4121 and 4402, I
thought that we could have specified the use of a different protocol key
here, so SHALL is not quite so redundant.

> understand what this says I have to read it side-by-side with SASL.

Yes, but I think that's reasonable, because it makes the text in this
section concise.  RFC4422, section 5 lists the questions, and this
provides the answers.  If we provide more than numbered answers then IMO
we should have a verbatim copy of the questions (numbered!) and the
answers on separate lines.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 09 Sep 2009 18:51:00 -0400

> answers on separate lines.

Eh.  I don't think we need a section for this.

The answer to (1) takes three paragraphs, which are section 4.

The answer to (2) belongs in the first paragraph of section 5:

   SCRAM is a client-first SASL mechanism ([RFC4422] section 5,
   item 2a), and returns no additional data long with a server's
   indication of a successful outcome.

The answer to (3) belongs in the introduction:

   When used as a SASL mechanism, SCRAM is capable of transporting
   authorization identities (see [RFC4422] section 2) from the client
   to the server.

The answer to (4) already _is_ in the introduction, as the second graf.

And of course, for (5) there isn't really anything to answer.  It's just a 
constraint on the protocol design, which SCRAM meets.

-- Jeff