eap Mailing List: EAP-SAKE comments

[Jouni Malinen (jkmaline]

While implementing EAP-SAKE, I wrote down couple of questions/comments
about draft-vanderveen-eap-sake-01.txt. Do these sound reasonable?
It would be useful to get some of the open areas clarified in order to
make sure that I interpreted the draft correctly.

Do you happen to have an implementation of EAP-SAKE peer or server?
I'm now able to test this against my own implementation, but it would
be nice to be able to run some interop tests with another implementation
if one were available.


3.2.6.1 KDF

- "a corrected version" of PRF of IEEE 802.11i
  What was corrected?

- "Length" gets values 1, 2, ... in the for loop whereas 802.11i is
   using 0, 1, ...
  Is this on purpose?


3.3.2 Expanded Types

- EAP header not included here even though it was included in 3.3.1
- EAP packet payload is different in case of legacy and expanded EAP
  formats; I would assume this is because of alignment(?), but it makes
  the implementation to have two separate code paths if both legacy and
  expanded header is used. I haven't seen this kind of description in
  any other EAP method. Is this necessary?


3.2.8.2 AT_PADDING

- What's the point in adding AT_PADDING into the _end_ of the message?
  I would understand alignment for each attribute inside the message and
  padding to make AT_ENCR_DATA length match with cipher block size, but
  what is the need to pad the end of the message?
- 3.3.1 says "All EAP-SAKE packets SHOULD align on a 32-bit boundary"
  Should that be MUST instead of SHOULD or is the padding actually
  optional?


3.3.10 Request/Identity

- s/AT_PERM..._REQ/AT_PERM_ID_REQ/
  (there is enough space for full attribute name)


3.2.8.1

- Do PEERID and SERVERID (as part of key derivation) include any length
  field or termination or is it just the contents of ther peer/server
  id?
- If AT_SERVERID and AT_PEERID were not sent at all, are these
  identities still included in MIC calculation? e.g., PEERID would be
  user identity from EAP-Response/Identity. Would SERVERID be
  zero-length in that case?


-- 
Jouni Malinen                                            PGP id EFC895FA