eap Mailing List: Issue 343: Section 1,2 and 5 cleanup

[Bernard Aboba (bernard_aboba]

Issue 343: Section 1,2 and 5 cleanup
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: March 27, 2006
Reference:
Document: Keying-10
Comment type: E
Priority: S
Section: 1, 2, 5
Rationale/Explanation of issue:

The flow of Section 1 leaves something to be desired.  It launches
right into the EAP key hierarchy without any overview, and the
security goals of EAP are not discussed until Section 5, which
seems somewhat out of place.

The proposed resolution is to move the first half of Section 2.1
(up to the examples) and the portion of Section 5
dealing with security goals to Section 1.3.

The examples in the second half of Section 2.1 will be moved
to section 1.3.1.  Section 1.3 (EAP Key Hierarchy) becomes
Section 1.4;  Section 1.4 (EAP Invariants) becomes Section 1.5.

Section 2.2 (Layering) becomes Section 2 (Lower Layer Operation);
Section 2.3 (Transient Session Keys) becomes Section 2.1, Section
2.4 (Authenticator Architecture) becomes Section 2.2; Section
2.5 (Key Scope) becomes section 2.3.

Section 5.1 will be incorporated in Section 5, rather than being
a separate section.  Section 5.2 (Threat Model) becomes Section
5.1.

The following paragraphs in Section 5.6 relate to authenticator
and peer identification, a subject extensively discussed in Section 2.4:

"  In order to enable key binding and authorization of all parties, it is
   RECOMMENDED that the parties use a set of identities that are
   consistent between the conversation phases. RADIUS [RFC2865] and
   Diameter NASREQ [RFC4005] require that the NAS/EAP authenticator
   identify itself by including one or more identification
   attributes within an Access-Request packet (NAS-Identifier,
   NAS-IP-Address, NAS-IPv6-Address).

   Since the backend authentication server provides EAP keying material
   for use by the EAP authenticator as identified by these attributes,
   where an EAP authenticator may have multiple ports, it is RECOMMENDED
   for the EAP authenticator to identify itself using NAS identification
   attributes during the Secure Association Protocol exchange with the
   EAP peer.  This enables the EAP peer to determine whether EAP keying
   material has been shared between EAP authenticators as well as to
   confirm with the backend authentication server that an EAP
   authenticator proving possession of EAP keying material during the
   Secure Association Protocol was authorized to obtain it.  Typically,
   the NAS-Identifier attribute is most convenient for this purpose,
   since a NAS/authenticator may have multiple IP addresses.

   Similarly, the backend authentication server authorizes the EAP
   authenticator to provide access to the EAP peer identified by the
   Peer-ID, securely verified during the EAP authentication exchange.
   In order to determine whether EAP keying material has been shared
   between EAP peers, where the EAP peer has multiple ports it is
   RECOMMENDED for the EAP peer to identify itself using the Peer-ID
   during the Secure Association Protocol exchange with the EAP
   authenticator."

To reduce redundancy, it is recommended that these paragraphs be
changed to the following:

"In order to enable key binding and authorization of all parties, it is
RECOMMENDED that the parties use a set of identities that are
consistent between the conversation phases.
Section 2.2 discusses identification issues that arise where the
EAP authenticator and peer may have multiple ports.  Consistently
identifying the EAP authenticator enables the EAP peer to determine
whether EAP keying material has been shared between EAP authenticators
as well as to confirm with the backend authentication server that an EAP
authenticator proving possession of EAP keying material during the
Secure Association Protocol was authorized to obtain it.

Similarly, the backend authentication server authorizes the EAP
authenticator to provide access to the EAP peer identified by the
Peer-ID, securely verified during the EAP authentication exchange.
In order to determine whether EAP keying material has been shared
between EAP peers, where the EAP peer may have multiple ports it is
RECOMMENDED for the EAP peer to identify itself using the Peer-ID
during the Secure Association Protocol exchange with the EAP
authenticator."

In Section 5.8, the following sentence contradicts the
discussion in Section 2.1.

"TSKs are permitted to be accessed
only by the EAP peer and authenticator.
Since the TSKs can be determined from the transported EAP
keying material and the cleartext of the Secure Association
Protocol exchange, the backend authentication server will have
access to the TSKs"

Recommend that it be changed to:

"TSKs are permitted to be accessed
only by the EAP peer and authenticator (Section 1.3).
As discussed in Section 2.1, PPP and 802.11i derive the TSKs
from transported EAP keying material;
802.16e utilizes transported EAP keying material for TSK keywrap; IKEv2
utilizes transported EAP keying material only to authenticate the
derivation of TSKs.  Possession of transported keying material enables the
backend authentication server to masquerade as the authenticator, and
in some cases to obtain the TSKs (PPP, 802.11i, 802.16e)"

Section 1.3 now reads as follows:

"1.3.  Overview

   Where EAP key derivation is supported, the conversation typically
   takes place in three phases:

      Phase 0: Discovery
      Phase 1: Authentication
               1a: EAP authentication
               1b: AAA Key Transport (optional)
      Phase 2: Secure Association Establishment
               2a: Unicast Secure Association
               2b: Multicast Secure Association (optional)

   Of these phases, Phase 0, 1b and Phase 2 are handled external to EAP.
   Phases 0 and 2 are handled by the lower layer protocol and phase 1b
   is typically handled by a AAA protocol.

   In the discovery phase (phase 0),  peers locate authenticators and
   discover their capabilities.  A peer may locate an authenticator
   providing access to a particular network, or a peer may locate an
   authenticator behind a bridge with which it desires to establish a
   Secure Association.  Discovery can occur manually or automatically,
   depending on the lower layer over which EAP runs.

   EAP peer                   Authenticator               Auth. Server
   --------                   -------------               ------------
    |<-----------------------------|                               |
    |     Discovery (phase 0)       |                               |
    |<-----------------------------|<-----------------------------|
    |   EAP auth (phase 1a)         |  AAA pass-through (optional)  |
    |                               |                               |
    |                               |<-----------------------------|
    |                               |       AAA Key transport       |
    |                               |      (optional; phase 1b)     |
    |<-----------------------------|                               |
    |  Unicast Secure association   |                               |
    |          (phase 2a)           |                               |
    |                               |                               |
    |<-----------------------------|                               |
    | Multicast Secure association  |                               |
    |     (optional; phase 2b)      |                               |
    |                               |                               |

                  Figure 1: Conversation Overview

   The authentication phase (phase 1) may begin once the peer and
   authenticator discover each other.  This phase, if it occurs, always
   includes EAP authentication (phase 1a).  Where the chosen EAP method
   supports key derivation, in phase 1a EAP keying material is derived
   on both the peer and the EAP server.

   An additional step (phase 1b) is required in deployments which
   include a backend authentication server, in order to transport keying
   material from the backend authentication server to the authenticator.
   In order to obey the principle of Mode Independence, where a backend
   server is present, all keying material which is required by the lower
   layer needs to be transported from the EAP server to the
   authenticator.  Since existing TSK derivation techniques depend
   solely on the MSK, in existing implementations, this is the only
   keying material replicated in the AAA key transport phase 1b.

   Successful completion of EAP authentication and key derivation by a
   peer and EAP server does not necessarily imply that the peer is
   committed to joining the network associated with an EAP server.
   Rather, this commitment is implied by the creation of a security
   association between the EAP peer and authenticator, as part of the
   Secure Association Protocol (phase 2).  The Secure Association
   exchange (phase 2) occurs between the peer and authenticator in order
   to manage the creation and deletion of unicast (phase 2a) and
   multicast (phase 2b) security associations between the peer and
   authenticator.  The conversation between the parties is shown in
   Figure 1.

   The goal of the EAP conversation is to derive fresh session keys
   between the EAP peer and authenticator that are known only to those
   parties, and for both the EAP peer and authenticator to demonstrate
   that they are authorized to perform their roles either by each other
   or by a trusted third party (the backend authentication server).
   Authorization issues are discussed in Sections 5.8.

   Completion of an EAP method exchange (Phase 1a) supporting key
   derivation results in the derivation of EAP keying material (MSK,
   EMSK, TEKs) known only to the EAP peer (identified by the Peer-ID)
   and server (identified by the Server-ID).  Both the EAP peer and EAP
   server know the exported keying material to be fresh.  Disclosure
   issues are discussed in Section 5.5; key freshness is discussed in
   Sections 3.3, 3.4 and 5.7.

   Completion of the AAA exchange (Phase 1b) results in the transport of
   EAP keying material from the EAP server (identified by the Server-ID)
   to the EAP authenticator (identified by the NAS-Identifier) without
   disclosure to any other party.  Both the EAP server and EAP
   authenticator know this keying material to be fresh.  Security
   properties of AAA protocols are discussed in Sections 5.2-5.8, and
   5.11.

   Completion of the Secure Association Protocol (Phase 2) results in
   the derivation of Transient Session Keys (TSKs) known only to the EAP
   peer (identified by the Peer-ID) and authenticator (identified by the
   NAS-Identifier).  Both the EAP peer and authenticator know the TSKs
   to be fresh.  Security properties of Secure Association Protocols are
   discussed in Section 3.1."