eap Mailing List: Issue 412: Evaluation of EAP Lower Layers?

[Bernard Aboba (bernard_aboba]

Issue 412: Evaluation of EAP lower layers?
Submitter name: Charlie Kaufman
Submitter email address: charliek [at] microsoft.com
Date first submitted:  October 18, 2007
Reference:
Document: draft-ietf-eap-keying-18.txt
Comment type:  Technical
Priority: S
Section: Section 1.3.1, 3.1, 5
Rationale/Explanation of Issue:

Section 3.1 describes SAP properties, but it doesn't evaluate existing EAP 
lower layers (such as PPP, IKEv2, IEEE 802.11, IEEE 802.16) against these 
properties.   Also Section 5 is somewhat inconsistent in evaluating the RFC 
4962 criteria against existing examples; some sections do this, others do 
not.

[BA] Sections 1.3.1 and 2.1 discuss existing EAP lower layers.  Perhaps it 
would be helpful to add more detail to these Sectoins? Here is some 
suggested text:

Section 1.3.1:

"1.3.1.  Examples

  Existing EAP lower layers implement phase 0, 2a and 2b in different
  ways:

PPP  The Point-to-Point Protocol (PPP), defined in [RFC1661] does not
    support discovery, nor does it include a Secure Association
    Protocol.

PPPoE
    PPP over Ethernet (PPPoE), defined in [RFC2516], includes support
    for a Discovery stage (phase 0).  In this step, the EAP peer sends
    a PPPoE Active Discovery Initiation (PADI) packet to the broadcast
    address, indicating the service it is requesting.  The Access
    Concentrator replies with a PPPoE Active Discovery Offer (PADO)
    packet containing its name, the service name and an indication of
    the services offered by the concentrator.  The discovery phase is
    not secured.  PPPoE, like PPP, does not include a Secure
    Association Protocol.

IKEv2
    Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes
    support for EAP and handles the establishment of unicast security
    associations (phase 2a).  However, the establishment of multicast
    security associations (phase 2b) typically does not involve EAP and
    needs to be handled by a group key management protocol such as GDOI
    [RFC3547], GSAKMP [RFC4535], MIKEY [RFC3830], or GKDP [GKDP].
    Several mechanisms have been proposed for discovery of IPsec
    security gateways.  [RFC2230] discusses the use of Key eXchange
    (KX) Resource Records (RRs) for IPsec gateway discovery; while KX
    RRs are supported by many Domain Name Service (DNS) server
    implementations, they have not yet been widely deployed.
    Alternatively, DNS SRV RRs [RFC2782] can be used for this purpose.
    Where DNS is used for gateway location, DNS security mechanisms
    such as DNSSEC ([RFC4033], [RFC4035]), TSIG [RFC2845], and Simple
    Secure Dynamic Update [RFC3007] are available.

IEEE 802.11
    IEEE 802.11, defined in [IEEE-802.11], handles discovery via the
    Beacon and Probe Request/Response mechanisms.  IEEE 802.11 access
    points periodically announce their Service Set Identifiers (SSIDs)
    as well as capabilities using Beacon frames.  Stations can query
    for access points by sending a Probe Request to the broadcast
    address.  Neither Beacon nor Probe Request/Response frames are
    secured.  The 4-way handshake defined in [IEEE-802.11] enables the
    derivation of unicast (phase 2a) and multicast/broadcast (phase 2b)
    secure associations.  Since the group key exchange transports a
    group key from the access point to the station, two 4-way
    handshakes can be needed in order to support peer-to-peer
    communications.  A proof of the security of the IEEE 802.11 4-way
    handshake when used with EAP-TLS is provided in [He].

IEEE 802.1X
    IEEE 802.1X-2004, defined in [IEEE-802.1X] does not support
    discovery (phase 0), nor does it provide for derivation of unicast
    or multicast secure associations.
"

Section 2.1:

"2.1.  Transient Session Keys

  Where explicitly supported by the lower layer, lower layers MAY cache
  keying material, including exported EAP keying material and/or TSKs;
  the structure of this key cache is defined by the lower layer.  So as
  to enable interoperability, new lower layer specifications MUST
  describe key caching behavior.  Unless explicitly specified by the
  lower layer, the EAP peer, server and authenticator MUST assume that
  peers and authenticators do not cache keying material.  Existing EAP
  lower layers and AAA layers handle the generation of transient
  session keys and caching of EAP keying material in different ways:

IEEE 802.1X-2004
    When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does
    not support link layer ciphersuites and a result, it does not
    provide for generation of TSKs, or caching of EAP keying material
    and parameters.  Once EAP authentication completes, it is assumed
    that EAP keying material and parameters are discarded; on IEEE 802
    wired networks there is no subsequent Secure Association Protocol
    exchange.  Perfect Forward Secrecy (PFS) is only possible if the
    negotiated EAP method supports this.

PPP  PPP, defined in [RFC1661] does not include support for a Secure
    Association Protocol; nor does it support caching of EAP keying
    material or parameters.  PPP ciphersuites derive their TSKs
    directly from the MSK, as described in [RFC2716].  This is NOT
    RECOMMENDED, since if PPP were to support caching of EAP keying
    material, this could result in TSK reuse.  As a result, once the
    PPP session is terminated, EAP keying material and parameters MUST
    be discarded.  Since caching of EAP keying material is not
    permitted within PPP, there is no way to handle TSK re-key without
    EAP re-authentication.  Perfect Forward Secrecy (PFS) is only
    possible if the negotiated EAP method supports this.

IKEv2
    IKEv2, defined in [RFC4306] only uses the MSK for authentication
    purposes and not key derivation.  The EMSK, IV, Peer-Id, Server-Id
    or Session-Id are not used.  As a result, the TSKs derived by IKEv2
    are cryptographically independent of the EAP keying material and
    re-key of IPsec SAs can be handled without requiring EAP re-
    authentication.  Within IKEv2 it is possible to negotiate PFS,
    regardless of which EAP method is negotiated.  IKEv2 as specified
    in [RFC4306] does not cache EAP keying material or parameters; once
    IKEv2 authentication completes it is assumed that EAP keying
    material and parameters are discarded.  The Session-Timeout
    attribute is therefore interpreted as a limit on the VPN session
    time, rather than an indication of the MSK key lifetime.

IEEE 802.11
    IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer-
    Id, Server-Id, or Session-Id.  More details about the structure of
    the cache are available in [IEEE-802.11].  In IEEE 802.11, TSKs are
    derived from the MSK using a Secure Association Protocol known as
    the 4-way handshake, which includes a nonce exchange.  This
    guarantees TSK freshness even if the MSK is reused.  The 4-way
    handshake also enables TSK re-key without EAP re-authentication.
    PFS is only possible within IEEE 802.11 if caching is not enabled
    and the negotiated EAP method supports PFS.

IEEE 802.16e
    IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
    MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id.  IEEE
    802.16e support a Secure Association Protocol in which TSKs are
    chosen by the authenticator without any contribution by the peer.
    The TSKs are encrypted, authenticated and integrity protected using
    the MSK and are transported from the authenticator to the peer.
    TSK re-key is possible without EAP re-authentication.  PFS is not
    possible even if the negotiated EAP method supports it.
"
Also, I have added a bit more detail to Section 5 on how various existing 
protocols conform to the RFC 4962 criteria.