Subject: [eap] Proposed resolution of Issue 225: Review

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 May 2004 20:19:10 -0700 (PDT)

The text of Issue 225 is enclosed below.  The proposed resolution is as
follows:

Add the following text:
"2.4. Non-compliant EAP authentication methods

EAP-MD5-Challenge (the current mandatory-to-implement EAP
authentication method), is defined in [RFC3748] Section 5.4. EAP-
MD5-Challenge and two EAP authentication methods defined in
[RFC3748], One-Time Password (Section 5.5) and Generic Token Card
(Section 5.6), are non-compliant with the requirements defined in
this document. As noted in [RFC3748], these methods do not support
any of the mandatory requirements defined in Section 2.2 including
key derivation, or mutual authentication. In addition, these methods
do not support the optional features defined in Section 2.4.

3. Security Considerations

Within [IEEE802.11i], EAP is used for both authentication and key
exchange between the EAP peer and server. Given that wireless local
area networks provide ready access to an attacker within
range, EAP usage within [IEEE802.11i] is subject to the threats
outlined in [RFC3748] Section 7.1. Security considerations relating
to EAP are discussed in [RFC3748] Sections 7; where an authentication
server is utilized, the security considerations described in
[RFC3579], Section 4 will apply.

The system security properties required to address the threats
described in [RFC3748] Section 7.1 are noted in [Housley56]:

Algorithm independence
Wherever cryptographic algorithms are chosen, the algorithms must
be negotiable, in order to provide resilience against compromise of
a particular algorithm. This is addressed by mandatory requirement
[7] in Section 2.1.1. For interoperability, at least one suite of
algorithms MUST be implemented. Since no standards track EAP methods
meeting these requirements have been published as RFCs, [IEEE802.11i]
does not define a mandatory-to-implement algorithm. However, it is
hoped that this document will contribute toward the development of
EAP methods meeting these requirements, so that selection of a
mandatory-to-implement algorithm might be possible in the future.

Strong, fresh session keys
Session keys must be demonstrated to be strong and fresh in all
circumstances, while at the same time retaining algorithm
independence. Key strength is addressed by mandatory
requirement [2] in Section 2.1.1. Recommendations for
ensuring the Freshness of keys derived by EAP methods are
discussed in [RFC3748], Section 7.10. Algorithm independence
is one of the EAP invariants described in [KEYFRAME].

Replay protection
All protocol exchanges must be replay protected. This is
addressed by mandatory requirement [6] in Section 2.1.1.

Authentication
All parties need to be authenticated. Mutual authentication is
required as part of mandatory requirement [3] in Section 2.1.1.
The confidentiality of the authenticator must be maintained.
Identity protection is an optional capability, described in
requirement [10] in Section 2.3. No plaintext passwords are
allowed. EAP does not support plaintext passwords, as noted
in [RFC3748] Section 7.14.

Authorization
EAP peer and authenticator authorization must be performed.
Issues relating to authorization are discussed in
[RFC3748] Section 7.15, and [RFC3579] Section 4.3.7.

Session keys
Confidentiality of session keys must be maintained. Issues
relating to Key Derivation are described in [RFC3748]
Section 7.10, as well as in [KEYFRAME].

Ciphersuite negotiation
The selection of the "best" ciphersuite must be securely confirmed.
This is addressed in mandatory requirement [7] in Section 2.1.1.

Unique naming
Session keys must be uniquely named. Key naming issues are
addressed in [KEYFRAME].

Domino effect
Compromise of a single authenticator cannot compromise any other
part of the system, including session keys and long-term secrets.
This issue is addressed by mandatory requirement [6] in Section 2.1.1.

Key binding
The key must be bound to the appropriate context. This issue is
addressed in optional requirement [9] in Section 2.3. Channel binding
is also discussed in Section 7.15 of [RFC3748].
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.

[Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA
WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html,
March 2003."

-----------------------------------------------------------------------
Issue 225: ReviewSubmitter name: Steve Bellovin
Submitter email address: [email-masked]
Date first submitted: 2/24/2004
Reference:
Document: EAP-WLAN-00
Comment type: 'T'echnical
Priority: S
Section: Various
Rationale/Explanation of issue:

The document doesn't have a Security Considerations section, and --
speaking almost purely syntactically; I haven't read the draft yet --
I'd sure want Section 2.5 to explain which criteria each of the
unacceptable methods fail to meet.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap