Subject: [eap] Proposed Resolution to Issue 178: Review of Key Framework

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Oct 2003 18:30:25 -0700 (PDT)

The proposed text of Issue 178 is enclosed below.

The required fixes are extensive, and multiple reviewers have commented on
some sections, so I think we will need to address the issues in several
passes.  Here is a first pass at some fixes:

In Section 1, change:

"Since in EAP keying material is generated by EAP
methods, transported by AAA protocols, transformed into session keys by
secure association protocols and used by link layer ciphersuites, it is"

To:

"Since in EAP keying material is generated by EAP
methods, transported by AAA protocols, transformed into session keys by
secure association protocols and used by lower layer ciphersuites, it is"

In Section 1, delete:

"The document is organized as follows:

Section 1 provides an introduction and defines terminology.
Section 2 describes the EAP key hierarchy and exchanges.
Section 3 describes EAP security associations and key naming.
Section 4 describes the threat model and security requirements.
Section 5 describes the IANA considerations.
Section 6 describes security considerations.
Section 7 provides references.
Appendix A summarizes the keying requirements for link layer ciphersuites.
Appendix B provides an example transient EAP key (TEK) hierarchy.
Appendix C provides an example MSK and EMSK hierarchy.
Appendix D provides an example Transient Session Key (TSK) derivation.
Appendix E describes AAA-Key derivation, including fast handoff."

In Section 1.2, delete:

"For example, attributes might include the peer layer 2
address (Calling-Station-Id), the authenticator layer 2 address
(Called-Station-Id) and IP address (NAS-IP-Address), the key name,
etc."

In Section 1.2, change:

"The format and wrapping of the AAA-Token, which is intended
to be accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol."

To:

"The format and wrapping of the AAA-Token, which is intended
to be accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples
include RADIUS [RFC2548], and Diameter [DiamEAP]."

In Section 1.2, delete:

"Key derivation
This refers to the ability of the EAP method to export a
ciphersuite-independent Master Session Key (MSK), Extended Master
Session Key (EMSK), and (optionally) an Initialization Vector (IV)."

In Section 1.2, add:

"AAA-Key
A key derived by the EAP peer and EAP server and transported to
the authenticator. In 802.11 terminology, the first 32 octets of
the AAA-Key is known as the Pairwise Master Key (PMK)."

In Section 1.3, change:

"Once the EAP peer and authenticator discover each other, they
authenticate using EAP (phase 1a)."

To:

"Once the EAP peer and authenticator discover each other, EAP
authentication may begin (phase 1a)."

In Section 1.3, delete:

"In 802.11 terminology, the first
32 octets of the AAA-Key is known as the Pairwise Master Key (PMK)."

In Section 1.3, change:

" <--------------------------------
AAA-Key transport (phase 1b)"

to:

" <--------------------------------
AAA-Key transport (optional; phase 1b)"

In Section 1.3, change:

" <----------------------------->
Multicast Secure association (phase 2b)"

To:

" <----------------------------->
Multicast Secure association (optional; phase 2b)"

In Section 1.3.2, change:

"Once the EAP peer and authenticator discover each other, they
authenticate using EAP (phase 1a)."

To:

"Once the EAP peer and authenticator discover each other, they
exchange EAP packets."

In Section 1.3.2, change:

"EAP supports either one-way authentication (in which the peer
authenticates to the EAP server), or mutual authentication (in which the
peer and EAP server mutually authenticate)."

To:

"Some EAP methods exist which only support one-way
authentication; however, EAP methods deriving keys
are required to support mutual authentication."

In Section 1.3.3, delete:

"While EAP methods may be based on key management protocols, EAP itself
is not a protocol for negotiation of security associations. While EAP
methods supporting key derivation provide for mutual authentication and
creation of EAP (phase 1) security associations, in order to preserve
media independence, they typically do not support generation of
transient session keys or negotiation of ciphersuites used in the
protection of data. As a result, where EAP is used for key derivation,
a secure association protocol (phase 2) should be provided, supporting
the creation and deletion of phase 2 security associations used for the
protection of data."

In Section 1.3.3, change:

" [2] Generation of fresh transient session keys. This is typically
accomplished via the exchange of nonces within the secure
association protocol, and includes generation of both unicast
(phase 2a) and multicast (phase 2b) session keys. While multicast
traffic may only pass in one direction in certain cases (such as in
IEEE 802.11 infrastructure mode, where only the Access Point sends
multicast traffic), in other cases (such as IEEE 802.11 adhoc
mode), both endpoints may send multicast traffic. By not using the
AAA-Key directly to protect data, the secure association protocol
protects against compromise of the AAA-Key, and by guaranteeing the
freshness of transient session key, assures that session keys are
not reused."

to:

" [2] Generation of fresh transient session keys. This is typically
accomplished via the exchange of nonces within the secure
association protocol, and includes generation of both unicast
(phase 2a) and multicast (phase 2b) session keys. By not using the
AAA-Key directly to protect data, the secure association protocol
protects against compromise of the AAA-Key, and by guaranteeing the
freshness of transient session key, assures that session keys are
not reused."

In Section 2.1.1 add to the end:

"As a result, EAP methods should not utilize identifiers associated
with a particular usage environment (e.g. MAC addresses)."

In Section 2.1.3, change:

"Ciphersuite negotiation
In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated between the peer and
authenticator."

To:

"Knowledge of capabilities
In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated between the peer and
authenticator."

In Section 2.2, change:

"EAP Master key (MK)
A key derived between the EAP client and server during the EAP
authentication process, and that is kept local to the EAP method
and not exported or made available to a third party. Since the MK
is a residue of a successful EAP authentication exchange, it is
possible to shorten future EAP exchanges between an EAP peer and
server by providing proof of MK possesion, a technique known as
"fast resume".

Master Session Key (MSK)
Keying material (at least 64 octets) that is derived between the
EAP client and server and exported by the EAP method. Whenever a
full EAP authentication is performed (not fast handoff), the MSK is
chosen as the AAA-Key (see Appendix E for details)."

To:

"EAP Master key (MK)
A key derived between the EAP client and server during the EAP
authentication process, and that is kept local to the EAP method
and not exported or made available to a third party."

Master Session Key (MSK)
Keying material (at least 64 octets) that is derived between the
EAP client and server and exported by the EAP method."

In Section 2.2, change:

"Extended Master Session Key (EMSK)
Additional keying material (64 octets) derived between the EAP
client and server that is exported by the EAP method. Unlike the
MSK which is transported from the authentication server to the
authenticator, the EMSK is known only to the EAP peer and server
and is not provided to a third party. The EMSK therefore is not
transported by the backend authentication server to the
authenticator, although quantities derived from it may be used as
the AAA-Key in situations in which EAP authentication is bypassed
(e.g. fast handoff).

Currently the EMSK is reserved for future uses that are not defined
yet. For example, it could be used to derive additional keying
material for purposes such as fast handoff, man-in-the-middle
vulnerability protection, etc."

to:

"Extended Master Session Key (EMSK)
Additional keying material (64 octets) derived between the EAP
client and server that is exported by the EAP method. The
EMSK is known only to the EAP peer and server and is not
provided to a third party."

In Section 3.5, delete:

"As noted earlier, the discovery phase (phase 0) may be insecure so that
in order to prevent spoofing of discovery packets, the secure
association (phase 2) protocol should support the secure verification of
discovered capabilities, including ciphersuites and other security
parameters. This is more scalable than attempting to configure the
supported capabilities on each peer and authenticator and more secure
than unprotected capabilities negotiation."

Move the contents of Section 2.4 to the beginning of Section 4.1.

In Section 4.1, delete:

"If the authenticator and backend authentication server do not mutually
authenticate, then the peer will be vulnerable to rogue backend
authentication servers, authenticators, or both. If there is no per-
packet authentication, integrity and replay protection between the
authenticator and backend authentication server, then an attacker can
spoof or modify packets in transit."

In Section 4.2.2, change:

"Session Keys
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use session keys, as in Diameter EAP
[DiamEAP] and RADIUS over IPsec [RFC3579], rather than using a
static key, as originally defined in RADIUS [RFC2865]."

To:

"Session Keys
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use dynamic key management in order to
derive fresh session keys, as in Diameter EAP [DiamEAP] and
RADIUS over IPsec [RFC3579], rather than using a
static key, as originally defined in RADIUS [RFC2865]."

In Section 4.2.2, change:

"Forgery protection
AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators."

To:

"Authorization
AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators."

In Section 7.1, change:

"[RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol
(EAP)", Internet draft (work in progress), draft-ietf-
eap-rfc2284bis-04.txt, June 2003."

To:

"[RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol
(EAP)", Internet draft (work in progress), draft-ietf-
eap-rfc2284bis-06.txt, October 2003."

In Section 7.2, delete:

"[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998."

(already listed in Section 7.1)

In Section 7.2, change:

"[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", Internet
draft (work in progress), draft-ietf-aaa-diameter-17.txt,
December 2002."

To:

"[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", RFC 3588,
September 2003."

In Section 7.2, change:

"[IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD
FOR Telecommunications and Information Exchange between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Specification for Enhanced
Security", August 2003."

to:

"[IEEE80211i] IEEE Draft 802.11I/D6.1, "Draft Supplement to STANDARD
FOR Telecommunications and Information Exchange between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Specification for Enhanced
Security", August 2003."

--------------------------------------------------------
Issue 178: Review of Key Framework Document
Submitter name:  Tschofenig Hannes
Submitter email address: [email-masked]
Date first submitted: 9/29/2003
Reference:
http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes:
Document: Keyframe-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
I have compiled some comments for the eap key management framework draft.
you find the comments at:

http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes:

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap