Harald Alvestrand, Chairman
IETF, IESG

Dear Harald,

The purpose of the IEEE 802.11i task group is to enhance the security of IEEE 802.11 
systems. The purpose of this letter is to provide the IETF and IESG with an 
understanding of the expectations that IEEE 802.11 has of the work that is needed from 
the IETF to support enhanced security initiatives. We have identified three areas 
requiring work within the IETF, and each of these is discussed below.

1.	 Specification of EAP authentication methods. The IETF PPPEXT working group 
does have EAP in its charter, but is currently focused on PPP. At IETF 52, the 
PPPEXT working group chair, Karl Fox suggested that an alternative forum for 
discussion of EAP might be appropriate. Please clarify the appropriate forum for 
future EAP discussions.

2.	Specification of EAP keying. EAP methods are being defined which use EAP 
keying. However, important aspects of EAP keying, including the types of keys 
an EAP method should produce, have not been described in a framework RFC. 
We would like the IETF to publish an EAP Keying Framework RFC.

3.	 Specification of RADIUS keying attributes. RADIUS keying attributes are used 
to deliver keys from the AAA server to the wireless access point. A security 
review of proposed RADIUS keying attributes is needed. Proposed attributes are 
documented in informative text in the current 802.11i draft, Annex K. We would 
like the IETF to publish an RFC on RADIUS keying attributes, including a 
security review of the proposed attributes.

Standard, experimental and informational RFCs are all acceptable formats for the RFCs 
specifying EAP methods and keying attributes.

EAP Authentication methods

IEEE 802.11i voted on its first draft in May of 2001. The first draft incorporates IEEE 
802.1X as an upper layer authentication mechanism. Therefore, IEEE 802.11i has an 
interest in EAP authentication types, required by 802.1X. In July of 2001, IEEE 802.11i 
decided that it would not define EAP authentication types, voting that specific EAP 
authentication types are out of scope for the IEEE 802.11i specification except where it 
affects the IEEE 802.1X and/or IEEE 802.11 framework. We expect the IETF to define, 
select and publish new and existing EAP methods.



The following information is input from IEEE 802.11i regarding EAP. 

IEEE 802.11i Draft 1.7, clause 8.1.4.2 requires authentication methods within 802.11 
environments to perform mutual authentication and to establish keys based on the 
authentication. Some authentication algorithms should also:

1)	Be suitable for a range of deployment scenarios such as: mobile device to network 
in corporate environment, mobile device to internet gateway in home 
environment, mobile device to public infrastructure network, and mobile device to 
mobile device environments. Centralized AAA may or may not be available. 
Authentication credentials may include passwords, certificates, or tokens.

2)	Be suitable for implementation in access points and clients that have low or 
moderate computational resources. "Low or moderate" computational resources 
means a class of device for which the following example is indicative: For 
example, on initial association, a 40MIPS access point or mobile terminal with 
limited RAM must be able to execute the method in 5 seconds or less.

3)	Be unencumbered.

4)	Provide for fast re-connect to a new access point. Some applications are sensitive 
to potential disconnections when a station roams from one AP to another.

It is acceptable for the IETF to NOT choose a single method as mandatory to implement. 
IEEE 802.11i initially attempted to specify a single method. Consensus could not be 
achieved, as the variety of applications and infrastructure assumptions were too broad to 
be served by a single method. Existing RFC-specified methods include EAP-MD5, a 
password based authentication method that does not provide mutual authentication. EAP-
TLS, RFC 2716, supports mutual authentication, but requires digital certificates to be 
used on the client. Thus new EAP methods are needed for 802.11 applications.

EAP Keying Framework

EAP methods are being defined which use EAP keying. However, important aspects of 
EAP keying, including the types of keys an EAP method should produce, have not been 
described in a framework RFC. We would like the IETF to publish an EAP Keying 
Framework RFC.

RADIUS Keying Attributes

Existing EAP method implementations rely on vendor specific RADIUS attributes for the 
delivery of key information. 
We request that the IETF publish an RFC on RADIUS keying attributes. These proposed 
attributes are documented in informative text in IEEE 802.11i draft 1.7, Annex K.  In 
addition, a security review of proposed RADIUS keying attributes is needed.

Please contact Stuart Kerry, 802.11 Chair and David Halasz, Chair of 802.11i 
dhala@cisco.com with any questions, and to discuss IETF follow-up.


Stuart Kerry

Chair 802.11
Atts: Copy of draft