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 protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
