Issue 226: Comments on WLAN requirements
From: Bernard Aboba (abobainternaut.com)
Date: Thu, 26 Feb 2004 12:34:30 -0500 (EST)
Issue 226: Comments on WLAN requirements
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 2/25/2004
Reference:
Document: EAP-WLAN-00
Comment type: 'T'echnical
Priority: S
Section: 1, 1.2, 2.2, 3
Rationale/Explanation of issue:
I don't think there is enough overview material, describing the
IEEE 802.11i environment.

Change Section 1 to the following:

"1. Introduction

The Draft IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i]
makes use of IEEE 802.1X [IEEE8021X-REV] which in turn relies on the
Extensible Authentication Protocol (EAP), defined in [RFC2284bis].

Deployments of IEEE 802.11 wireless LANs today are based on EAP, and use
several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS [TTLS], PEAP
[PEAP] and EAP-SIM [SIM]. These methods support authentication
credentials that include digital certificates, user-names and passwords,
secure tokens, and SIM secrets.

This document defines requirements for EAP methods used in IEEE 802.11
wireless LAN deployments."

The draft could benefit by addition of a terminology section.

Add Section 1.2:

"1.2 Terminology

authenticator
The end of the link initiating EAP authentication. The
term Authenticator is used in [IEEE-802.1X], and
authenticator has the same meaning in this document.

peer
The end of the link that responds to the authenticator. In
[IEEE-802.1X], this end is known as the Supplicant.

Supplicant
The end of the link that responds to the authenticator in
[IEEE-802.1X].

backend authentication server
A backend authentication server is an entity that provides
an authentication service to an authenticator. When used,
this server typically executes EAP methods for the
authenticator. This terminology is also used in
[IEEE-802.1X].

EAP server
The entity that terminates the EAP authentication method
with the peer. In the case where no backend authentication
server is used, the EAP server is part of the
authenticator. In the case where the authenticator
operates in pass-through mode, the EAP server is located on
the backend authentication server.

Master Session Key (MSK)
Keying material that is derived between the EAP peer and
server and exported by the EAP method. The MSK is at least
64 octets in length. In existing implementations a AAA
server acting as an EAP server transports the MSK to the
authenticator.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. The EMSK is
at least 64 octets in length. The EMSK is not shared with
the authenticator or any other third party. The EMSK is
reserved for future uses that are not defined yet."

4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP)
defined in [IEEE802.11i], which confirms mutual possession
of a Pairwise Master Key by two parties and distributes a
Group Key."

With respect to Section 2.2, clause [3], my recommendation would be to
delete this,
since "Protected Result Indications" is no longer listed as a security
claim within
[RFC2284bis].

Change Section 2.5 to the following:

"2.5. Non-compliant EAP authentication methods

EAP-MD5-Challenge (the current mandatory-to-implement EAP authentication
method), is defined in [RFC2284bis] Section 5.4. EAP-MD5-Challenge and
two EAP authentication methods defined in [RFC2284bis], One-Time
Password (Section 5.5) and Generic Token Card (Section 5.6), are non-
compliant with the requirements defined in this document, since as is
noted in [RFC2284bis], they do not support any of the mandatory
requirements defined in Section 2.2, or the optional features defined
in Section 2.4."

Insert a Section 3, and renumber subsequent sections:

"3. Security Considerations

Within [IEEE802.11i], EAP is used for both authentication and key exchange
between the EAP peer and server. The use of EAP for key exchange is
described within [KEYFRAME].  Given that wireless local area networks
provide access to the media to an attacker within range, EAP usage within
[IEEE802.11i] is subject to the threats outlined in [RFC2284bis] Section
7.1, as well as the security considerations described in Section 7.3
through Section 7.16. In addition, in environments in which an
authentication server is used, the security considerations described in
[RFC3579] Section 4 will apply."

Add to the informative references:

[RFC3579]
Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User
Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.

[KEYFRAME]
Aboba, B., "EAP Key Management Framework", draft-ietf-eap-keying-01 (work
in progress), October 2003.

  • (no other messages in thread)

Results generated by Tiger Technologies using MHonArc.