Subject: [eap] Re: EAP method of type EAPOL-Key

From: [email-masked] (Bernard Aboba)
Date: Mon, 20 May 2002 13:04:42 -0700 (PDT)

EAP (RFC 2284) does not define a packet of type EAPOL-Key. Rather, this
is an IEEE 802.1X packet. The format of the RC4 key descriptor is not
fully defined within IEEE 802.1X however, so this has been added to:

http://www.drizzle.com/~aboba/IEEE/draft-congdon-radius-8021x-19.txt

The reason that the original EAPOL-Key packet was not defined in EAP was
that originally this was only to deal with 802.11-specific keying
phenomena (e.g. the default key). 

However, since then the purpose of this packet has expanded. In the latest
802.11 Tgi draft, it is also used for generic functions such as nonce
exchanges, and key synchronization. Adding this functionality to IEEE
802.1X instead of to EAP has some implications that probably need to be
thought through. 

For example, including a nonce exchange outside of EAP means that an EAP
method cannot depend on such an exchange being available. Thus, it might
choose to do its own exchange, in which case the 802.1X nonce exchange
might be considered duplicative. Similarly, key change synchronization
seems like a general purpose facility; isn't this something that other
media might need? On the other hand, the key exchanges that have been
proposed do have some 802.11-specific elements to them, so the case is not
entirely clearcut. 

I ask because one of the major priniciples of EAP is the creation of
authentication methods that can work on any media. Adding facilities
outside of EAP (such as EAPOL-Start) have tended to bite us either because
the facilities lie outside the protective envelope of proposals such as
TTLS or PEAP, or because those facilities end up having to be duplicated
on other media. 

So it's worth asking where this functionality should go, and why.