Subject: Re: [Emu] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)

From: <[email-masked]>
Date: Fri, 4 Jul 2008 10:46:48 +0300

Charles Clancy wrote:

> See comments inline.  An updated draft will be released shortly.
> Also note that the new draft addresses Dan's comments about
> resistance to dictionary attack.  

Thanks for the update! I have some additional comments (see below),
but they should be easy to address.

> > S4, "EAP_Method_Type refers to the integer value of the IANA
> > allocated EAP Type code", "...to the EAP type code (1 byte),
> > specified in Section XX"?
> 
> I don't think it's ever been clear how to reference the IANA
> allocated EAP type code in an I-D before it's been allocated.  These
> are things that would be fixed by the RFC Editor or in AUTH48, once
> IANA has allocated the type code.

For clarity, I'd still suggest adding the "(1 octet)" part (although
someone reading RFC 3748 will of course figure out that it's 1 octet).

> > S6 and elsewhere: Several places in the document assume that KS
> > (key size of the ciphersuite) is always the same as the MAC output
> > length.  This would make it difficult to define ciphersuites based
> > on e.g. AES-CMAC-256. If this restriction is intentional (and WG
> > is happy with it), at the very least it needs to be emphasized
> > much more.
> 
> I'm not sure what AES-CMAC-256 means.  RFC 4493 defines CMAC
> specifically for 128 length AES, so if you wanted to something
> involving 256, you'd need to define exactly what AES-CMAC-256 was,
> and I imagine it would have a 256-bit input and a 256-bit output.
> Regardless, I added a statement in the key derivation section saying
> the input and output lengths of your ciphersuite must be equal.

As Dan Harkins already pointed out, NIST 800-38B does define CMAC 
for 256-bit AES, with 256-bit key and 128-bit output.

So hardcoding this assumption in EAP-GPSK seems to limit the future
algorithm agility somewhat -- is the WG sure this is an acceptable
limitation?

(If this limitation is kept, I'd suggest mentioning in Section 2
that "KS" is not only the key size, but also MAC output length.)

> > S5 and S8.2 are not consistent about ciphersuite formatting (is
> > enterprise number 3 or 4 octets; if you're not sure, suggest
> > doing what RFC3748 did)
> 
> Fixed (should be 4).

Figure 3 in S6 still assumes it's 3.

> > S8.4, text and bit diagram are not consistent about whether
> > enterprise code is 3 or 4 bytes
> 
> Text consistent with length 4 enterprise code.

The 1st figure (now in S9.4) still shows 3 octets; so does the text 
at end of S9.4, and IANA considerations text for PData/Specifier.

> > S9, "If the MAC validation fails, the server MUST transmit a
> > GPSK-Fail message specifying "Authentication Failure" and discard
> > the received packet." Not quite sure what "discard the received
> > packet" here exactly means in the context of EAP state machine (If
> > the server sends a reply, it's not discarding the packet as such).
> 
> Fixed.

It seems this text was not changed at all? 

> > Interoperability requires the ability to enter same PSK in 
> > both client and server. See e.g. RFC4306 S2.15 and RFC4279 S5.4 
> > for examples of management interface requirements.
> 
> Added.

The text (Section 5) should probably say something about non-ASCII
characters, especially since NAIs can contain them (and IETF policies
usually require dealing with non-ASCII in strings handled by ordinary
users -- RFC4306/4279 are probably mostly for admins).

Maybe "SHOULD support non-ASCII", with pointer to detailed instructions 
in Section 2.4 of RFC 4282?

Addtional comments:

S2, "PL": would help reading if it said PL must be >= KS (it's said
in S6, but this assumption is already needed in S4).

S3, should also mention GPSK-Fail and GPSK-Protected-Fail messages
for completeness (in additino to GPSK-1...4).

S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)

S9.3, "from the ID_Client length" -> "from the ID_Peer length"

S11, GPSK-3 and GPSK-Fail are distinct message Op-Codes, so showing
e.g. "EAP-Request/GPSK-3 (GPSK-Fail (PSK Not Found or Authentication
Failure))" is confusing. Should be just "EAP-Request/GPSK-Fail ...".

S12.1, the references to sections 11.* should be to 12.* (and some 
of the subsection numbers don't match; e.g. channel binding is .13, 
not .12).

S12.9: the text about minimal state (only RAND_Peer) seems
inconsistent with S10, which requires discarding GPSK-3 if the
RAND_Server and CSuite_Sel fields are not the same as in GPSK-2.  
To make that comparison, it seems you need to store the values after
sending GPSK-2?

>From idnits: 
Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

Best regards,
Pasi
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Jul 2008 18:00:30 +0300

Hi Pasi,

thanks for the new round of comments.

> someone reading RFC 3748 will of course figure out that it's 1 octet).
Does this sound better:
"
EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code value.
"

> that "KS" is not only the key size, but also MAC output length.)
This seems to require a separate discussion on the list.

> Figure 3 in S6 still assumes it's 3.
Fixed the figure.

+------------+----+-------------+--------------+----------------+
| CSuite/    | KS | Encryption  | Integrity /  | Key Derivation |
| Specifier  |    |             | KDF MAC      | Function       |
+------------+----+-------------+--------------+----------------+
| 0x00000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF           |
+------------+----+-------------+--------------+----------------+
| 0x00000002 | 32 | NULL        | HMAC-SHA256  | GKDF           |
+------------+----+-------------+--------------+----------------+

> at end of S9.4, and IANA considerations text for PData/Specifier.
Done.

> It seems this text was not changed at all? 
Done.

Fixed.

> in S6, but this assumption is already needed in S4).
Done.

> for completeness (in additino to GPSK-1...4).
Ok.

> S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)
2 octets.

> S9.3, "from the ID_Client length" -> "from the ID_Peer length"
OK

> Failure))" is confusing. Should be just "EAP-Request/GPSK-Fail ...".
OK

Fixed.

> To make that comparison, it seems you need to store the values after
I added text on this issue. I am not fully sure whether it resolves the 
aspect entirely though.

> Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
Ok.

I am going to ship an update to make sure that we capture the previously 
discussed aspects.

Ciao
Hannes

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 10:47:58 +0300

> This seems to require a separate discussion on the list.

Ok -- please let me know once you think the discussion has
concluded.

> > characters, especially since NAIs can contain them (and IETF
> > policies usually require dealing with non-ASCII in strings handled
> > by ordinary users -- RFC4306/4279 are probably mostly for admins).
> >
> > Maybe "SHOULD support non-ASCII", with pointer to detailed 
> > instructions in Section 2.4 of RFC 4282?
> 
> Fixed.

It seems this update got garbled somehow -- at least I have some
difficulties in parsing the new text:

   Thus the management interface SHOULD support non-ASCII to allow
   entering values for the ID_Peer and ID_Server as ASCII strings up
   to 254 octets in length.

> > S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)

The text in Section 4 should say so.

> I added text on this issue. I am not fully sure whether it resolves
> the aspect entirely though.

Not really -- the text in Section 12.9 seems to say that doing
the comparison (of RAND_Server and CSuite_Sel) can be omitted,
but it's a MUST in Section 10. These two sections need to be
consistent.
 
> > Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

The names of the pre-defined IANA policies were also slightly changed,
so Section 13 needs some small updates.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 18:05:29 +0300

Charles,

Thanks for the update! There's one change I'm slightly worried 
about:

Version -10:
   For GPSK-3, a peer MUST silently discard messages where the
   RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match 
   those transmitted in GPSK-2.

Version -11:
   For GPSK-3, a peer MUST silently discard messages where the 
   RAND_Peer field does match the value transmitted in GPSK-2. 

I guess the security analysis of GPSK was performed assuming
the peer does check RAND_Server and CSuite_Sel? 

While I can't come up with any attack even if this check is
omitted (e.g., RAND_Server and CSuite_Sel are still included 
in MK derivation), is the whole WG comfortable with this change?
(I didn't see any discussion about this topic yet.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Charles Clancy [mailto:[email-masked]] 
> Sent: 29 July, 2008 14:42
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-emu-eap-gpsk-08 (1st round 
> of comments)
> 
> Pasi,
> 
> I've submitted an update that addresses the ASCII text garbling, PL 
> encoding, packet validation inconsistencies, and IANA policies.  All 
> that remains is the key/MAC-length issue.
> 
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
> 
>

---

From: Charles Clancy <[email-masked]>
Date: Tue, 29 Jul 2008 12:28:02 -0400

Pasi,

This state-minimization approach was proposed by the Stanford security 
review.  In earlier versions of the draft, CSuite_Sel and RAND_Server 
were not included in GPSK-3, and were not verified.  I'm not sure why 
the language you referenced below got updated after they were added to 
GPSK-3.

All -- Does anyone in the WG object to this change?