Subject: [eap] Issue 343: Section 1,2 and 5 cleanup

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 27 Mar 2006 10:42:46 -0800

Issue 343: Section 1,2 and 5 cleanup
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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."

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 28 Mar 2006 15:46:11 -0800

>Possession of transported keying material enables
>the backend authentication server to masquerade as the authenticator, and

Actually, I don't believe this is true in IKEv2 since the authenticator 
needs to prove possession of *both* the IKEv2 secret (e.g. DH key) as well 
as the EAP MSK.  So gaining possession of the MSK would not allow a backend 
authentication server to masquerade as the authenticator.  Suggest this be 
rewritten as follows:

"Where demonstration of authorization depends entirely on possession of 
transported EAP keying material (such as in PPP, 802.11i and 802.16e), this 
enables the backend server to masquerade as the authenticator, and possibly 
to obtain the TSKs"