Subject: Re: [Emu] WG Last Call: draft-ietf-emu-eap-gpsk-03.txt

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 05 Mar 2007 18:15:47 -0800

Review summary:  Thanks to Charles and Hannes for their hard work on 
this draft, but I think it needs another revision before going to AD 
Review and IETF LC.

I have been part of the design team, and so I am responsible for some of 
the following issues being still pending at this stage.  I may have also 
brought up some of these issues in the past and the consensus determined 
the current contents; if so, please refresh my memory :).  Thanks.

1. The definition of KS is inconsistent.  Figure 3 shows that SHA-1 is 
the hash function and the key size is 16.  The definition in Section 2 
says that KS is the key size of the selected cipher suite.  Well that is 
not precise enough as it turns with the 128-bit key cipher and 160-bit 
key hash function being used.

2.  Nit: There may be 1 or more occurrences of the word 
PD_Payload_Blocks; my understanding is that there is only one block and 
there could be 1 or more PD_Payloads.

3. Nits: The relative order of definitions of PK, SK and MK might be 
changed so there is no forward referencing.  I recall complaining that 
the names PK and SK are not intuitive.  Same goes for SEC_X(Y) by the 
way.  I also realized I don't quite like us renaming the EAP peer as the 
"client."

4. Borderline Nit: The description of the messages at the beginning of 
Page 9 can be tighter.  Some examples:

* The MAC computation needs to be more clearly specified.  The current 
text says the MAC is over all "these" parameters and "session 
parameter".  We need a more precise specification.

The MAC serves two purposes, the first is a PoP of the PSK or a derived 
key thereof and integrity protection over the message contents.  For the 
PoP we need a certain MAC coverage and for integrity protection a larger 
coverage.

A related question is whether the EAP header needs integrity protection? 
  Otherwise, what happens if an adversary modifies the message ID (OP 
Code).  Perhaps all that is plausible is a DoS attack.  However, since 
we have specific error codes, we might take advantage and be more 
precise about the error (I am of course not happy that we are declaring 
that "Authentication failed" indirectly signaling MAC failure :) ).

5. GPSK-4 is needed only as a filler for EAP request/response pairing, 
right?  Perhaps we should state that clearly.

6. At the end of Section 3, we have "Upon receipt of GPSK-4, the server 
assures that the peer has derived session keys."  I guess the server 
assures "itself." :)  More importantly though, doesn't the server know 
that about the peer upon request of GPSK-2.

7. (Page 10) Why is MK's KDF using 0 as the key?  Why not use the PSK? 
I do see that the MK is used as input in other KDFs and so there might 
not be a problem.  Thoughts?

8. (Page 12) s/SHA-1/HMAC-SHA-1; s/SHA256/HMAC-SHA-256

Also I like the GKDF specification that Charles had in one of the 
earlier inputs to this process.

As it is, we need to make at least one modification:

s/ Hash-Function(i||Y||Z)/KDF_Y(i||Z)/        or KDF_Y(M_{i-1}||i||Z) 
(I think this is what Charles specified earlier).

9. s/MAC-based ciphersuite/hash-based ciphersuite
    s/MAC output size/hash output size

10. In Section 6.1.1, I strongly suggest that we should AES-CTR and not 
AES-CBC.  I can make a case in a separate email if necessary, but with 
AES-CTR it is plausible that a host can get away with not implementing 
the AES cipher's reverse operation and we should allow that possibility.

11. Section 7.3.  Instead of length(CSuite_List), could we not use 
NumberOf_CSuites and reduce the field size to 1 octet?

Clearly there are a few nits and things that we could live with; however 
there are some issues that need to be addressed now.  Some of them are 
for clarity and correctness of the spec and others are to address 
security issues (8 above and 7 too).  10 is an issue I request the group 
to consider.

thanks,
Lakshminath

Joseph Salowey (jsalowey) wrote:
> This is a working group last call for draft-ietf-emu-eap-gpsk-03. 
> 
> Send your comments to the EMU list by March 7, 2007.  Please respond to
> this call even if you have reviewed the draft and found no problems.  
> 
> The document can be accessed here:
> http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-03.txt
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu