eap Mailing List: Re: EAP-SAKE comments

[M. Vanderveen (mvandervn]

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



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

> On Tue, Apr 25, 2006 at 10:36:34AM -0700, M. Vanderveen wrote:
>
> > 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. 
>
> 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 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.
>
> 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.
>
> > 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.
>
> 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.
>
> > 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.
>
> 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..
>
> > 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.
>
> 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.
>
> > - 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. 
>
> Since I don't
>  see need for such alignment, I would probably just remove
> this completely rather than changing it to MAY.
>
> > 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 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).
>
> > - 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.
>
> 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).
>
> -- 
> Jouni Malinen PGP id EFC895FA

---

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