Subject: [eap] Issue 235: (Key Framework) Rewrite of Section 1

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Apr 2004 15:45:13 -0800 (PST)

Issue 235: Rewrite of Section 1
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 4/3/2004
Reference: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-02.txt
Document: Keying-01
Comment type: T/E
Priority: S
Section: 1
Rationale/Explanation of issue:

I've gone and rewritten Section 1 of the Key Framework document in order
to improve the organization and readability.

Replace Section 1 with the following:

"1.  Introduction

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   was designed to enable extensible authentication for network access
   in situations in which the IP protocol is not available.  Originally
   developed for use with PPP [RFC1661], it has subsequently also been
   applied to IEEE 802 wired networks [IEEE8021X].

   This document provides a framework for the generation, transport and
   usage of keying material generated by EAP authentication algorithms,
   known as "methods".  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 necessary to describe each of these elements and provide a
   system-level security analysis.

1.1.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized. The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in BCP 14 [RFC2119].

1.2.  Terminology

   This document frequently uses the following terms:

authenticator
     The end of the link initiating EAP authentication.  The term
     Authenticator is used in [IEEE-802.1X], and authenticator has the
     same meaning in this document.

peer The end of the link that responds to the authenticator.  In
     [IEEE-802.1X], this end is known as the Supplicant.

Supplicant
     The end of the link that responds to the authenticator in
     [IEEE-802.1X].  In this document, this end of the link is called
     the peer.

backend authentication server
     A backend authentication server is an entity that provides an
     authentication service to an authenticator.  When used, this server
     typically executes EAP methods for the authenticator.  This
     terminology is also used in [IEEE-802.1X].

AAA  Authentication, Authorization and Accounting.  AAA protocols with
     EAP support include RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-
     eap].  In this document, the terms "AAA server" and "backend
     authentication server" are used interchangeably.

EAP server
     The entity that terminates the EAP authentication method with the
     peer.  In the case where no backend authentication server is used,
     the EAP server is part of the authenticator.  In the case where the
     authenticator operates in pass-through mode, the EAP server is
     located on the backend authentication server.

1.3.  Overview

   EAP is typically deployed in order to support extensible network
   access authentication in situations where a peer desires network
   access via one or more authenticators.  The situation is illustrated
   in Figure 1 below.

   Since both the peer and authenticator may have more than one physical
   or logical port, a given peer may simultaneously access the network
   via multiple authenticators, or via multiple physical or logical
   ports on a given authenticator.  Similarly, an authenticator may
   offer network access to multiple peers, each via a separate physical
   or logical port.

   The peer may be stationary, in which case it may establish
   communications with one or more authenticators while remaining in one
   location.  Alternatively, the peer may be mobile, changing its point
   of attachment from one authenticator to another, or moving between
   points of attachment on a single authenticator.

   Where authenticators are deployed standalone, the EAP conversation
   occurs between the peer and authenticator, and the authenticator must
   locally implement an EAP method acceptable to the peer.

   However, one of the advantages of EAP is that it enables deployment
   of new authentication methods without requiring development of new
   code on the authenticator.  While the authenticator may implement
   some EAP methods locally and use those methods to authenticate local
   users, it may at the same time act as a pass-through for other users
   and methods, forwarding EAP packets back and forth between the
   backend authentication server and the peer.  This is accomplished by
   encapsulating EAP packets within the Authentication, Authorization
   and Accounting (AAA) protocol, spoken between the authenticator and
   backend authentication server.  AAA protocols supporting EAP include
   RADIUS [RFC3579] and Diameter [I-D.ietf-aaa-eap].

                               +-+-+-+-+
                               |       |
                               | EAP   |
                               | Peer  |
                               |       |
                               +-+-+-+-+
                                 | | |  Peer Ports
                                /  |  \
                               /   |   \
    Phase 0: Discovery        /    |    \
    Phase 1: Authentication  /     |     \
    Phase 2: Secure         /      |      \
             Association   /       |       \
                          /        |        \
                         /         |         \
                      | | |      | | |      | | |  Authenticator Ports
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                    |       |  |       |  |       |
                    | Auth. |  | Auth. |  | Auth. |
                    |       |  |       |  |       |
                    +-+-+-+-+  +-+-+-+-+  +-+-+-+-+
                         \         |         /
                          \        |        /
                           \       |       /
             EAP over AAA   \      |      /
               (optional)    \     |     /
                              \    |    /
                               \   |   /
                                \  |  /
                               +-+-+-+-+
                               |       |
                               | AAA   |
                               |Server |
                               |       |
                               +-+-+-+-+

   Figure 1:  Relationship between peer, authenticator and backend server

   Where EAP key derivation is supported, the conversation between the
   peer and the authenticator 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)

   In the discovery phase (phase 0),  peers locate authenticators and
   discover their capabilities.  For example, 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.

   The authentication phase (phase 1) may begin once the peer and
   authenticator discover each other.  This phase always includes EAP
   authentication (phase 1a).  Where the chosen EAP method supports key
   derivation, in phase 1a keying material is derived on both the peer
   and the EAP server.  This keying material may be used for multiple
   purposes, including protection of the EAP conversation and subsequent
   data exchanges.

   An additional step (phase 1b) is required in deployments which
   include a backend authentication server, in order to transport keying
   material (known as the AAA-Key) from the backend authentication
   server to the authenticator.

   A Secure Association exchange (phase 2) then 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 phases and relationship between the parties is shown
   below in Figure 2.

     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 2: Conversation Overview

1.3.1.  Discovery Phase

   In the discovery phase (phase 0), the EAP peer and authenticator
   locate each other and discover each other's capabilities. Discovery
   can occur manually or automatically, depending on the lower layer
   over which EAP runs.

   For example, where EAP runs over PPP, the EAP peer might be
   configured with a phone book providing phone numbers of
   authenticators and associated capabilities such as supported rates,
   authentication protocols or ciphersuites.

   In contrast, PPPoE [RFC2516] provides support for a Discovery Stage
   to allow a peer to identify the Ethernet MAC address of one or more
   authenticators and establish a PPPoE SESSION_ID.

   IEEE 802.11 [IEEE80211] also provides integrated discovery support
   utilizing Beacon and/or Probe Request/Response frames, allowing the
   peer (known as the station or STA) to determine the MAC address and
   capabilities of one or more authenticators (known as Access Point or
   APs).

   Since discovery is handled outside of EAP, there is no need to
   provide this functionality within EAP.

1.3.2.  Authentication Phase

   Once the peer and authenticator discover each other, they exchange
   EAP packets.  Typically, the peer desires access to the network, and
   the authenticators provide that access.  In such a situation, access
   to the network can be provided by any authenticator attaching to the
   desired network, and the EAP peer is typically willing to send data
   traffic through any authenticator that can demonstrate that it is
   authorized to provide access to the desired network.

   An EAP authenticator may handle the authentication locally, or it may
   act as a pass-through to a backend authentication server.  In the
   latter case the EAP exchange occurs between the EAP peer and a
   backend authenticator server, with the authenticator forwarding EAP
   packets between the two. The entity which terminates EAP
   authentication with the peer is known as the EAP server.  Where pass-
   through is supported, the backend authentication server functions as
   the EAP server; where authentication occurs locally, the EAP server
   is the authenticator.  Where a backend authentication server is
   present, at the successful completion of an authentication exchange,
   the AAA-Key is transported to the authenticator (phase 1b).

   EAP may also be used when it is desired for two network devices (e.g.
   two switches or routers) to authenticate each other, or where two
   peers desire to authenticate each other and set up a secure
   association suitable for protecting data traffic.

   Some EAP methods exist which only support one-way authentication;
   however, EAP methods deriving keys are required to support mutual
   authentication.  In either case, it can be assumed that the parties
   do not utilize the link to exchange data traffic unless their
   authentication requirements have been met.  For example, a peer
   completing mutual authentication with an EAP server will not send
   data traffic over the link until the EAP server has authenticated
   successfully to the peer, and a Secure Association has been
   negotiated.

   Since EAP is a peer-to-peer protocol, an independent and simultaneous
   authentication may take place in the reverse direction.  Both peers
   may act as authenticators and authenticatees at the same time.

   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).  As a result, EAP may be used
   for "pre-authentication" in situations where it is necessary to pre-
   establish EAP security associations in order to decrease handoff or
   roaming latency.

1.3.3.  Secure Association Phase

   The Secure Association phase (phase 2) always occurs after the
   completion of EAP authentication (phase 1a) and key transport (phase
   1b), and typically supports the following features:

[1]  Secure capabilties negotiation.  This provides for the secure
     negotiation of usage modes, session parameters, ciphersuites, and
     required filters, including confirmation of the capabilities
     discovered during phase 0.  By securely negotiating session
     parameters, the secure Association Protocol protects against
     spoofing during the discovery phase and ensures that the peer and
     authenticator are in agreement about how data is to be secured.

[2]  Generation of fresh transient session keys (TSKs).  The Secure
     Association Protocol typically guarantees the freshness of session
     keys by exchanging nonces and then mixing the nonces with the AAA-
     Key in order to generate fresh 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 keys, assures that they are not reused.

[3]  Key activation and deletion. In order for the peer and
     authenticator to communicate securely, it is necessary for both
     sides to derive the same session keys, and remain in sync with
     respect to key state going forward.  One of the functions of the
     Secure Association Protocol is to synchronize the activation and
     deletion of keys so as to enable seamless rekey, or recovery from
     partial or complete loss of key state by the peer or authenticator.

[4]  Mutual proof of possession of the AAA-Key.  This demonstrates that
     both the peer and authenticator have been authenticated and
     authorized by the backend authentication server.  Since mutual
     proof of possession is not the same as mutual authentication, the
     peer cannot verify authenticator assertions (including the
     authenticator identity) as a result of this exchange.

1.4.  EAP Invariants

   By utilizing a three phase exchange, the EAP key management framework
   guarantees that certain basic characteristics, known as the "EAP
   Invariants" hold true for all implementations of EAP.  These include:

      Media independence
      Method independence
      Ciphersuite independence

1.4.1.  Media Independence

   One of the goals of EAP is to allow EAP methods to function on any
   lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
   For example, as described in [RFC3748], EAP authentication can be run
   over PPP [RFC1661],  IEEE 802 wired networks [IEEE8021X], and IEEE
   802.11 wireless LANs [IEEE80211i].

   In order to maintain media independence, it is necessary for EAP to
   avoid inclusion of media-specific elements.  For example, EAP methods
   cannot be assumed to have knowledge of the lower layer over which
   they are transproted, and cannot utilize identifiers associated with
   a particular usage environment (e.g. MAC addresses).

   The need for media independence has also motivated the development of
   the three phase exchange.  Since discovery is typically media-
   specific, this function is handled outside of EAP, rather than being
   incorporated within it.  Similarly, the Secure Association Protocol
   often contains media dependencies such as negotiation of media-
   specific ciphersuites or session parameters, and as a result this
   functionality also cannot be incorporated within EAP.

1.4.2.  Method Independence

   By enabling pass-through, authenticators can support any method
   implemented on the peer and server, not just locally implemented
   methods.  This allows the authenticator to avoid implementing code
   for each EAP method required by peers.  In fact, since a pass-through
   authenticator is not required to implement any EAP methods at all, it
   cannot be assumed to support any EAP method-specific code.

   As a result, as noted in [RFC3748], authenticators must by default be
   capable of supporting any EAP method.  Since the Discovery and Secure
   Association exchanges are also method independent, an authenticator
   can carry out the three phase exchange without having an EAP method
   in common with the peer.

   This is useful where there is no single EAP method that is both
   mandatory-to-implement and offers acceptable security for the media
   in use.  For example, the [RFC3748] mandatory-to-implement EAP method
   (MD5-Challenge) does not provide dictionary attack resistance, mutual
   authentication or key derivation, and as a result is not appropriate
   for use in wireless LAN authentication [WLANREQ].  However, despite
   this it is possible for the peer and authenticator to interoperate as
   long as a suitable EAP method is supported on the EAP server.

1.4.3.  Ciphersuite Independence

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of data
   is negotiated within the Secure Association Protocol, out-of-band of
   EAP.

   The backend authentication server is not a party to this negotiation
   nor is it an intermediary in the data flow between the EAP peer and
   authenticator.  The backend authentication server may not even have
   knowledge of the ciphersuites implemented by the peer and
   authenticator, or be aware of the ciphersuite negotiated between
   them, and therefore does not implement ciphersuite-specific code.

   Since ciphersuite negotiation occurs in the Secure Association
   protocol, not in EAP, ciphersuite-specific key generation, if
   implemented within an EAP method, would potentially conflict with the
   transient session key derivation occurring in the Secure Association
   protocol.  As a result, EAP methods generate keying material that is
   ciphersuite-independent.

   Additional advantages of ciphersuite-independence include:

Update requirements
     If EAP methods were to specify how to derive transient session keys
     for each ciphersuite, they would need to be updated each time a new
     ciphersuite is developed.  In addition, backend authentication
     servers might not be usable with all EAP-capable authenticators,
     since the backend authentication server would also need to be
     updated each time support for a new ciphersuite is added to the
     authenticator.

EAP method complexity
     Requiring each EAP method to include ciphersuite-specific code for
     transient session key derivation would increase method complexity
     and result in duplicated effort.

Knowledge of capabilities
     In practice, an EAP method may not have knowledge of the
     ciphersuite that has been negotiated between the peer and
     authenticator, since this negotiation typically occurs within the
     Secure Association Protocol.

     For example, PPP ciphersuite negotiation occurs in the Encryption
     Control Protocol (ECP) [RFC1968].  Since ECP negotiation occurs
     after authentication, unless an EAP method is utilized that
     supports ciphersuite negotiation, the peer, authenticator and
     backend authentication server may not be able to anticipate the
     negotiated ciphersuite and therefore this information cannot be
     provided to the EAP method.  Since ciphersuite negotiation is
     assumed to occur out-of-band, there is no need for ciphersuite
     negotiation within EAP.

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

---

From: Florent Bersani <[email-masked]>
Date: Thu, 08 Apr 2004 14:40:55 +0200

Bernard,

I have concerns with the current wording of section 1.4.1 of the Key 
management framework: it seems to me as though it hinders the channel 
binding capability (please see the thread on Jari and Pasi's new I-D on 
authenticated service identities) - since to provide channel binding, 
EAP methods precisely need to transfer media specific information 
(though in a possibly media agnostic framework like the aforementioned 
draft).

I understand (and subscribe to) the fact that EAP methods should be 
media agnostic in their design. However, a possible way to do so is 
precisely to define appropriate elements for every media type (although 
this probably means quite a lot of work for now and the future).

I would thus rather have something like: "Should an EAP method have 
knowledge of the lower layer over which it is transported and should it 
wish to utilize identifiers associated with a particular media 
environment - for instance to provide channel binding, it MAY do so but 
it SHOULD support all media types EAP is commonly run over to avoid 
specializing EAP to a particular media type".

Cheers,

Florent

Bernard Aboba wrote:

>...

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Apr 2004 06:50:56 -0700 (PDT)

> specializing EAP to a particular media type".

Media independence is one of the fundamental properties of EAP.  It is not
a "nice to have".

Had this advice been taken in 1998 when EAP was first implemented,
operation over 802.11 would not be possible today since that was not one
of the media on which EAP was commonly run over at the time.

Similarly, 802.16 is not common today, but it has adopted EAP as its
authentication framework.

I am not aware of a case in which media independence needs to be
compromised in order to provide for identification or channel binding.
For example, an EAP method need not necessarily be aware of the content
of an Identifier in order to use it.  In terms of channel binding, it can
pass the Called or Calling-Station-Id to the AAA server as an opaque blob
and receive back a confirmation of whether it matched or not, again
without having knowledge of media.

---

From: Florent Bersani <[email-masked]>
Date: Thu, 08 Apr 2004 17:07:08 +0200

>Media independence is one of the fundamental properties of EAP.  It is not
I agree, apologies if my wording offended you.

>authentication framework.
I totally agree - at least for the ongoing revision of 802.16 since the 
original standard does not use EAP at all, as you know

>without having knowledge of media.
Let's rephrase: my point was that to the naive reader that I am, the 
media independence seemed to contradict the channel binding. If this is 
not the case (which I do hope and believe), then some clarification 
might be needed. The text you very kindly provided might be well suited 
to do so...

My only question (which does not belong to EAP) is more of a trivial 
conclusion on implementations: for the EAP method to pass the opaque 
blob containing the Called or Calling-Station-Id, it first needs to get 
that blob. Hence, we need here some communication between the EAP method 
and something that is aware of the media over which EAP is being run, 
don't we?

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 8 Apr 2004 12:02:37 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Florent Bersani
> Sent: Thursday, April 08, 2004 8:07 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Issue 235: (Key Framework) Rewrite of Section 1
> 
> 
> 
> 
> Bernard Aboba wrote:
> 
> >>knowledge of the lower layer over which it is transported 
> and should 
> >>it wish to utilize identifiers associated with a particular media 
> >>environment - for instance to provide channel binding, it MAY do so 
> >>but it SHOULD support all media types EAP is commonly run over to 
> >>avoid specializing EAP to a particular media type".
> >>    
> >>
> >
> >Media independence is one of the fundamental properties of 
> EAP.  It is 
> >not a "nice to have".
> >  
> >
> >operation over 802.11 would not be possible today since that was not 
> >one of the media on which EAP was commonly run over at the time.
> >
> >of an Identifier in order to use it.  In terms of channel 
> binding, it 
> >can pass the Called or Calling-Station-Id to the AAA server as an 
> >opaque blob and receive back a confirmation of whether it matched or 
> >not, again without having knowledge of media.
> >
> >  
> >
[Joe] Yes, there needs to be a communication between EAP, which does
authentication, and the party(s) responsible for authorization.  There needs
to be some data exported out of the EAP method to accomplish this such as
authenticated identity and channel binding information.  The authorization
piece would need to be aware of what the parties communication is trying to
do.

---

From: Alper Yegin <[email-masked]>
Date: Mon, 12 Apr 2004 13:33:13 -0700

> piece would need to be aware of what the parties communication is
trying
> to

This should be handled by the NAS, which implements (and glues together)
EAP, EAP lower layer, AAA backend protocols.

Alper