Subject: [eap] Issue 412: Evaluation of EAP Lower Layers?

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 23 Oct 2007 18:50:47 -0700

Issue 412: Evaluation of EAP lower layers?
Submitter name: Charlie Kaufman
Submitter email address: [email-masked]
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.

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

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