eap Mailing List: Re: EAP-SAKE comments

[M. Vanderveen (mvandervn]

Greatly appreciate your comments Jouni. Trying to implement a method is IMO the ultimate test of whether it's solid :-).

The question on Expanded Types we can discuss here (vs. inline) as it is an RFC3748 issue that Jari addressed in his earlier comments. The EAP packet payload is different in the case of regular vs. expanded types purely for alignment purposes. However if in itself makes the implementation more difficult then we're willing to remove the padding.

This description was put here in the first place in an attempt to comply with RFC 3748, which reads that all NEW methods must support both regular and expanded types. Have you tried to implement another new method ("new" meaning after the publication of 3748)? EAP-SAKE means to be nothing special with regards to this expanded types issues. Whatever is customary (does anyone know??), that's what we would like to specify for EAP-SAKE. If there is no such thing, then I'm at a loss as to what to do with these types.

Jouni Malinen <jkmaline [at] cc.hut.fi> wrote:

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.
MCV>> So sorry we do not have an implementation ready to share.

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?

 

MCV>> The KDF in the 802.11i 2004 spec needs correction as i being an integer cannot take the value (Len+159)/160. It should probably be 0 to FLOOR((Len+159)/160). Thomas Otto pointed out to me that CEIL should be used, in which case i should go from 1 to CEIL((Len+159)/160). It's apparent to me now that the two are not equivalent :-(. For EAP-SAKE we tried to write the KDF in the hope that an implementation  compliant with 802.11i and written in *assembly* can be reused for EAP. Thus for lack of a better guess, we wrote the KDF so that the shortest length variant (that is, for Length=16 bytes), we get as the output just R:= H-SHA1(Key, Label, Msg, 1). Perhaps it should have been i=0 to FLOOR((Len+19)/20), resulting in

R:= H-SHA1(key, Label, Msg, 0). Perhaps if Thomas reads this he can chime in.

3.3.2 Expanded Types

- EAP header not included here even though it was included in 3.3.1

MCV>> Not sure what you mean, the EAP header is included here in the exact form as it is 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?

MCV>> That would be purely for implementation ease. I gather that does not add contribute to it. I would say whatever is customary, that should be the norm. See below.

- 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?

MCV>> Good catch. That should be changed to a MAY. This way you don't have to add the padding at the end of the message.


3.3.10 Request/Identity

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

MCV>> Ok.


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?

MCV>> This was meant to mimick the IEEE 802.11i way of doing things...In that they just use the MAC address, which obviously has a well defined number of bytes. To answer your question, I would just use the contents of the peer/serverID, with no trailing \0 or length field. We can make this clear in the text too. Unless, of course, you tell me that it is *customary* to implement such IDs, when used in a hash function, with a trailing zero byte or length field. EAP-SAKE wants to be no different :-)

- 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?

MCV>> This is a good question, it should probably be allowed for a Peer NOT to know the FQDN of the server which holds its credentials, but just the domain name, e.g. verizon.com. In this case the SERVERID should be zero-length. That too needs to be added to the text. Thanks for pointing this out.


--
Jouni Malinen PGP id EFC895FA

---

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1¢/min.