Subject: [eap] EAP-SAKE comments

From: Jouni Malinen <[email-masked]>
Date: Sun, 23 Apr 2006 13:30:30 -0700

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "M. Vanderveen" <[email-masked]>
Date: Tue, 25 Apr 2006 10:36:34 -0700 (PDT)

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 <[email-masked]> wrote:

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

   
  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.

3.2.8.2 AT_PADDING

  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

  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 :-)
  
  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.

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

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 25 Apr 2006 21:05:48 -0700

>   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 v…

Well, it does not fit in with the design I decided to use for this.. I
have generic EAP header validation and generation functions that can
handle both legacy and expanded EAP headers without the EAP method
implementation having to know which header type is used. This works as
long as the payload is identical in both cases. The padding byte you
have currently for expanded header means that there is need for the EAP
method to know which payload type (with or without 1-octet pad) is used.

Of the attributes that are currently defined in EAP-SAKE draft, only
AT_MSK_LIFE looks like something that would benefit from being 32-bit
aligned. However, since the header is 16 bits, that alignment is likely
lost anyway.. In other words, I think that the implementation will have
to assume that the value is unaligned and adding the extra 1-octet pad
would not really help here.

If the fields values should be aligned, quite a bit more padding would
be needed (e.g., all attributes could be aligned to start at 32-bit
boundary and things like MSK lifetime would be prepended by 16-bit
padding to make the 32-bit value be aligned).. I don't know whether this
would really be worth the problem in this case since there are not
really many 16 or 32-bit integers in the definition.

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

I haven't explicitly tried to do this, but I just verified that I can
run EAP-MD5 and EAP-GTC without issues with both the legacy and expanded
headers by just modifying the generic EAP message allocation and header
generation function. In other words, the EAP method implementations did
not need any changes for this.

I don't know why one would use expanded format with Vendor-Id=IETF
type=1..255 since the expanded header is just making the frames longer.
RFC 3748 seems to require that these cases are considered "semantically
identical". I could even go as far as assuming that it is actually
requiring that data following the header should be identical and the
one-byte pad in EAP-SAKE would not be allowed if the method is allocated
an EAP type within 4..191.

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

IEEE 802.11i does not seem to be saying this explicitly, but that
(Len+159)/160 is integer division and use of FLOOR instead of CEIL would
indeed make the KDF in SAKE match with PRF in 802.11i and would make it
more likely for implementation to be able to share the same function.
Not that this would make much difference, but it could help me save the
ca. 256 bytes that the separate KDF for SAKE is currently taking ;-)
without having to introduce a new function argument for starting value
for the counter.

>   MCV>> Not sure what you mean, the EAP header is included here in the exact form as it is in 3.3.1.

What I was trying to say is that the draft did not include the full
header (the first line, i.e., Code/Identifier/Length, missing) in 3.3.2.
Anyway, I would kind of hope that all new EAP method drafts/RFCs were
not required to describe both old and expanded header formats..

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

I don't remember cases where end of the message would be padded and I
don't see how that would make the implementation easier. Padding inside
the message can indeed help if it is guaranteed to make some multi-octet
fields aligned.

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

Since I don't see need for such alignment, I would probably just remove
this completely rather than changing it to MAY.

>   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 j…

If there are no length fields or separators between the IDs, one could,
at least in theory, derive the same MIC value with different IDs. For
example (SERVERID=foo, PEERID=bar) and (SERVERID=fo, PEERID=obar) would
produce the same MIC_S values. However, different order in MIC_P
calculation would detect this, but that is only used in one direction
(peer->server).. Anyway, to avoid potential attacks, it could be better
to make sure that the IDs are explicitly defined to have either
separation (trailing \0 is often used in this kind of cases if the data
itself is not allowed to include \0 which I would expect to be the case
here).

>   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 th…

Unless AT_SERVERID is included, I would not expect peer to even know the
domain name or at least I don't know what the mechanism would be to
provide such information to an EAP method. Anywya, what I would like to
see is an explicit comment making it clear what is included in each
possible case (AT_SERVERID included/not, AT_PEERID included/not,
different IDs in SAKE/Identity and SAKE/Challenge, etc.).. And if this
can be made simpler (as in just one possible case ;-), that would be
appreciated. If I remember correctly, there were some confusing corner
cases in EAP-SIM/AKA and use of three different identity types and
selection of which one to use in MIC calculation (or key derivation; I
don't remember which one it was anymore).

---

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 26 Apr 2006 08:59:05 -0700 (PDT)

Thanks, Jouni,
  We'd like to make the minor changes as necessary to take all your suggestions into account, to make implementations easier. 
   
  Jari -- to remove confusion we would like to remove the Expanded Types section altogether, so that an implementation will assume that the expanded types header is followed by exactly the header shown.
  Not sure about the status of this draft - does it need a last call before it goes into the experimental RFC queue?
   
  Thanks,
  Michaela

		
---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.