eap Mailing List: Proposed Resolution of Issue 215: Comments on Section 3

[Bernard Aboba (aboba]

The body of Issue 215 and the associated discussion can be found at:
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20215

The proposed resolution of is as follows.  Add the following text for
Section 2.4, and replace Section 3 with the following:

"2.4.  Key Naming

   MSK Name

      This key is created between the EAP peer and EAP server, and is
      uniquely named by the concatenation of the string "MSK", EAP
      Method Type, EAP peer name, EAP server name, EAP peer nonce, and
      the EAP server nonce.  Here the EAP peer name and EAP server name
      are the identifiers securely exchanged within the EAP method.
      Since multiple MSKs may exist between an EAP peer and EAP server,
      the EAP peer nonce and EAP server nonce allow MSKs to be
      differentiated; at least one of these nonces is necessary. The
      inclusion of the Method Type in the name ensures that each EAP
      method has a distinct name space.

      Note that the components of the MSK Name are only known by the EAP
      method. As a result, the MSK Name is exported from the method, and
      no detailed format of the MSK Name can be specified without a
      reference to a particular method.

   EMSK Name

      The EMSK is named similarly to the above. Its name is the
      concatenation of the string "EMSK", the EAP Method Type, EAP peer
      name, EAP server name, EAP peer nonce, and the EAP server nonce.


      Note that neither the MSK nor EMSK names include the authenticator
      identity or the peer or authenticator port over which the EAP
      conversation took place.  This is because the MSK and EMSK are not
      bound to an authenticator, or to specific ports on the peer or
      authenticator.

   AMSK Name

      AMSKs, if any, may be named by the concatenation of the string
      "AMSK", key label, application data (see Appendix F), and EMSK
      Name.

   AAA-Key Name

      The AAA-Key is named by the concatenation of the string "AAA-Key",
      the authenticator name (since the AAA-Key is bound to a particular
      authenticator), and the name of the key from which the AAA-Key is
      derived (MSK or AMSK Name).  For the purpose of identifying the
      authenticator, the contents of the NAS-Identifier attribute is
      recommended.  In order to ensure that all parties can agree on the
      authenticator name this requires the authenticator to advertise
      its name (typically using a lower layer mechanism, such as the
      802.11 Beacon/Probe Response).

      Note that the AAA-Key name does not include the peer or
      authenticator port over which the EAP conversation took place.
      This is because the AAA-Key is not bound to a specific peer or
      authenticator port.

   PMK Name

      The PMK has no name of its own, and is only identified by the AAA-
      Key from which it is derived.

   TEKs

      The TEKs may or may not be named. Their naming is specified in the
      EAP method.

   TSKs

      The TSKs are typically named. Their naming is specified in the
      Secure Association (phase 2) protocol, so that the correct set of
      transient session keys can be identified for processing a given
      packet.  Explicit creation and deletion operations are also
      typically supported so that establishment and re-establishment of
      transient session keys can be synchronized between the parties.

      In order to avoid confusion in the case where an EAP peer has more
      than one AAA-Key (phase 1b) applicable to establishment of a phase
      2 security association, the secure Association protocol needs to
      name the AAA-Key so that the appropriate phase 1b keying material
      can be identified for use in the Secure Association Protocol
      exchange.

3.  Security Associations

   During EAP authentication and subsequent exchanges, four types of
   security associations (SAs) are created:

[1]  EAP method SA.  This SA is between the peer and EAP server.  It
     stores state that can be used for "fast resume" or other
     functionality in some EAP methods.  Not all EAP methods create such
     an SA.

[2]  EAP-Key SA.  This is an SA between the peer and EAP server, which
     is used to store the keying material exported by the EAP method.
     Current EAP server implementations do not retain this SA after the
     EAP conversation completes, but proposals such as [IEEE-03-084] and
     [I-D.irtf-aaaarch-handoff] use this SA for purposes such as pre-
     emptive key distribution.

[3]  AAA SA(s).  These SAs are between the authenticator and the backend
     authentication server.  They permit the parties to mutually
     authenticate each other and protect the communications between
     them.

[4]  Service SA(s). These SAs are between the peer and authenticator,
     and they are created as a result of phases 1-2 of the conversation
     (see Section 1.3).

3.1.  EAP Method SA (peer - EAP server)

   An EAP method may store some state on the peer and EAP server even
   after phase 1a has completed.

   Typically, this is used for "fast resume": the peer and EAP server
   can confirm that they are still talking to the same party, perhaps
   using fewer round-trips or less computational power. In this case,
   the EAP method SA is essentially a cache for performance
   optimization, and either party may remove the SA from its cache at
   any point.

   An EAP method may also keep state in order to support pseudonym-based
   identity protection. This is typically a cache as well (the
   information can be recreated if the original EAP method SA is lost),
   but may be stored for longer periods of time.

   The EAP method SA is not restricted to a particular service or
   authenticator and is most useful when the peer accesses many
   different authenticators.  An EAP method is responsible for
   specifying how the parties select if an existing EAP method SA should
   be used, and if so, which one.  Where multiple backend authentication
   servers are used, EAP method SAs are not typically synchronized
   between them.

   EAP method implementations should consider the appropriate lifetime
   for the EAP method SA. "Fast resume" assumes that the information
   required (primarily the keys in the EAP method SA) hasn't been
   compromised. In case the original authentication was carried out
   using, for instance, a smart card, it may be easier to compromise the
   EAP method SA (stored on the PC, for instance), so typically the EAP
   method SAs have a limited lifetime.

   Contents:

      o  Implicitly, the EAP method this SA refers to
      o  One or more internal (non-exported) keys
      o  EAP method SA name
      o  SA lifetime

3.1.1.  Example: EAP-TLS

   In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
   and server can store the following information:

      o  Implicitly, the EAP method this SA refers to (EAP-TLS)
      o  Session identifier (a value selected by the server)
      o  Certificate of the other party (server stores the client's
         certificate and vice versa)
      o  Ciphersuite and compression method
      o  TLS Master secret (known as the EAP-TLS Master Key or MK)
      o  SA lifetime (ensuring that the SA is not stored forever)
      o  If the client has multiple different credentials (certificates
         and corresponding private keys), a pointer to those credentials

   When the server initiates EAP-TLS, the client can look up the EAP-TLS
   SA based on the credentials it was going to use (certificate and
   private key), and the expected credentials (certificate or name) of
   the server. If an EAP-TLS SA exists, and it is not too old, the
   client informs the server about the existence of this SA by including
   its Session-Id in the TLS ClientHello message. The server then looks
   up the correct SA based on the Session-Id (or detects that it doesn't
   yet have one).

3.1.2.  Example: EAP-AKA

   In EAP-AKA [I-D.arkko-pppext-eap-aka], after EAP authentication the
   client and server can store the following information:

      o  Implicitly, the EAP method this SA refers to (EAP-AKA)
      o  A re-authentication pseudonym
      o  The client's permanent identity (IMSI)
      o  Replay protection counter
      o  Authentication key (K_aut)
      o  Encryption key (K_encr)
      o  Original Master Key (MK)
      o  SA lifetime (ensuring that the SA is not stored forever)

   When the server initiates EAP-AKA, the client can look up the EAP-AKA
   SA based on the credentials it was going to use (permanent identity).
   If an EAP-AKA SA exists, and it is not too old, the client informs
   the server about the existence of this SA by sending its re-
   authentication pseudonym as its identity in EAP Identity Response
   message, instead of its permanent identity. The server then looks up
   the correct SA based on this identity.

3.2.  EAP-Key SA

   This is an SA between the peer and EAP server, which is used to store
   the keying material exported by the EAP method.  Current EAP server
   implementations do not retain this SA after the EAP conversation
   completes, but future implementations could use this SA for pre-
   emptive key distribution.

   Contents:

      o  MSK and EMSK names
      o  MSK and EMSK
      o  SA lifetime

3.3.  AAA SA(s) (authenticator - backend authentication server)

   In order for the authenticator and backend authentication server to
   authenticate each other, they need to store some information.

   In case the authenticator and backend authentication server are
   colocated, and they communicate using local procedure calls or shared
   memory, this SA need not necessarily contain any information.

3.3.1.  Example: RADIUS

   In RADIUS, where shared secret authentication is used, the client and
   server store each other's IP address and the shared secret, which is
   used to calculate the Response Authenticator [RFC2865] and Message-
   Authenticator [RFC3579] values, and to encrypt some attributes (such
   as the AAA-Key [RFC2548]).

   Where IPsec is used to protect RADIUS [RFC3579] and IKE is used for
   key management, the parties store information necessary to
   authenticate and authorize the other party (e.g. certificates, trust
   anchors and names). The IKE exchange results in IKE Phase 1 and Phase
   2 SAs containing information used to protect the conversation
   (session keys, selected ciphersuite, etc.)

3.3.2.  Example: Diameter with TLS

   When using Diameter protected by TLS, the parties store information
   necessary to authenticate and authorize the other party (e.g.
   certificates, trust anchors and names). The TLS handshake results in
   a short-term TLS SA that contains information used to protect the
   actual communications (session keys, selected TLS ciphersuite, etc.).

3.4.  Service SA(s) (peer - authenticator)

   The service SA stores information about the service being provided.
   This includes:

      o  Service parameters (or at least those parameters
         that are still needed)
      o  On the authenticator, service authorization
         information received from the backend authentication
         server (or necessary parts of it)
      o  On the peer, usually locally configured service
         authorization information.
      o  Transient Session Keys used to protect the communication
      o  The AAA-Key, if it can be needed again (to refresh
         and/or resynchronize other keys or for another reason)
      o  AAA-Key lifetime

   The information in the service SA can be grouped into several
   different SAs. This would make sense if, for instance, the service
   provided is naturally divided into several different sub-
   conversations with different parameters.

   Service SAs may include both unicast and multicast SAs.  An EAP peer
   may be able to negotiate multiple service SAs with a given
   authenticator, or may be able to maintain one or more secondary
   service SAs with multiple authenticators, depending on the properties
   of the media.

   In order for service SAs and associated TSKs to be established, it is
   not necessary for an EAP exchange to be rerun each time.  Instead,
   the Secure Association protocol can be used to mutually prove
   possession of the AAA-Key and create associated service SAs and TSKs,
   enabling the EAP exchange to be bypassed.

   It is possible for more than one unicast or multicast service SA to
   be derived from a single AAA-Key.  However, a service SA always
   descended from only one AAA-Key.  Service SAs descended from the same
   AAA-Key may utilize the same security parameters (e.g. mode,
   ciphersuite, etc.) or they may utilize different parameters.

   Except where explicitly specified by the Secure Association protocol,
   it should not be assumed that the installation of new service SAs
   implies deletion of old service SAs.  During a re-key of a service SA
   (unicast or multicast), it is possible for two service SAs to exist
   during the period between when the new service SA and corresponding
   TSKs are calculated and when they are installed.

   Similarly, deletion or creation of a unicast or multicast service SA
   does not necessarily imply deletion or creation of related unicast or
   multicast service SAs, unless specified by the Secure Association
   protocol.  For example, a unicast service SA may be rekeyed without
   implying a rekey of the multicast service SA.

   The deletion of the AAA-Key does not necessarily imply the deletion
   of the service SAs and associated TSKs derived from that AAA-Key.
   Failure to mutually prove possession of the AAA-Key during the Secure
   Association protocol exchange need not be grounds for deletion of the
   AAA-Key by both parties; the action to be taken is defined by the
   Secure Association protocol.

   One function of the Secure Association protocol is to bind the the
   TSKs to endpoint identifiers.  For example, within [IEEE802.11i], the
   4-way handshake binds the TSKs to the MAC addresses of the endpoints;
   in IKE [RFC2409], the TSKs are bound to the IP addresses of the
   endpoints and the negotiated SPI.  How exactly the relevant service
   SA is chosen at each point depends on the protocol; see below for
   examples.

3.4.1.  Example: 802.11i

   [IEEE802.11i] Section 8.4.1.1 defines the security associations used
   within IEEE 802.11.  A summary follows; the standard should be
   consulted for details.

   o Pairwise Master Key Security Association (PMKSA)

      The PMKSA is a bi-directional SA, used by both parties for sending
      and receiving.  It is created on the peer when EAP authentication
      completes successfully or a pre-shared key is configured.  The
      PMKSA is created on the authenticator when the PMK is received or
      created on the authenticator or a pre-shared key is configured.
      The PMKSA is used to create the PTKSA.  PMKSAs are cached for
      their lifetimes.  The PMKSA consists of the following elements:

      - PMKID (security association identifier)
      - Authenticator MAC address
      - PMK
      - Lifetime
      - Authenticated Key Management Protocol (AKMP)
      - Authorization parameters specified by the AAA server or
        by local configuration.  This can include
        parameters such as the peer's authorized SSID.
        On the peer, this information can be locally
        configured.
      - Key replay counters (for EAPOL-Key messages)
      - Reference to PTKSA (if any), needed to:
          o delete it (e.g. AAA server-initiated disconnect)
          o replace it when a new four-way handshake is done
      - Reference to accounting context, the details of which depend
        on the accounting protocol used, the implementation
        and administrative details. In RADIUS, this could include
        (e.g. packet and octet counters, and Acct-Multi-Session-Id).

   o Pairwise Transient Key Security Association (PTKSA)

      The PTKSA is a bi-directional SA created as the result of a
      successful four-way handshake.  There may only be one PTKSA
      between a pair of peer and authenticator MAC addresses.  PTKSAs
      are cached for the lifetime of the PMKSA.  Since the PTKSA is tied
      to the PMKSA, it only has the additional information from the
      4-way handshake.  The PTKSA consists of the following:

         - Key (PTK)
         - Selected ciphersuite
         - MAC addresses of the parties
         - Replay counters, and ciphersuite specific state
         - Reference to PMKSA: This is needed when:
            o A new four-way handshake is needed (lifetime, TKIP
              countermeasures), and we need to know which PMKSA to use

   o Group Transient Key Security Association (GTKSA)

      The GTKSA is a uni-directional SA created based on the four-way
      handshake or the group key handshake.  A GTKSA consists of the
      following:

         - Direction vector (whether the GTK is used for transmit or
receive)
         - Group cipher suite selector
         - Key (GTK)
         - Authenticator MAC address
         - Via reference to PMKSA, or copied here:
           o Authorization parameters
           o Reference to accounting context

3.4.2.  Example: IKEv2/IPsec

   Note that this example is intended to be informative, and it does not
   necessarily include all information stored.

o IKEv2 SA

   - Protocol version
   - Identities of the parties
   - IKEv2 SPIs
   - Selected ciphersuite
   - Replay protection counters (Message ID)
   - Keys for protecting IKEv2 messages (SK_ai/SK_ar/SK_ei/SK_er)
   - Key for deriving keys for IPsec SAs (SK_d)
   - Lifetime information
   - On the authenticator, service authorization information
     received from the backend authentication server.

When processing an incoming message, the correct SA is looked up based
on the SPIs.

o IPsec SAs/SPD

   - Traffic selectors
   - Replay protection counters
   - Selected ciphersuite
   - IPsec SPI
   - Keys
   - Lifetime information
   - Protocol mode (tunnel or transport)

   The correct SA is looked up based on SPI (for inbound packets), or
   SPD traffic selectors (for outbound traffic).  A separate IPsec SA
   exists for each direction.

3.4.3.  Sharing service SAs

   A single service may be provided by multiple logical or physical
   service elements.  Each service is responsible for specifying how
   changing service elements is handled. Some approaches include:

Transparent sharing
     If the service parameters visible to the other party (either peer
     or authenticator) do not change, the service can be moved without
     requiring cooperation from the other party.

     Whether such a move should be supported or used depends on
     implementation and administrative considerations. For instance, an
     administrator may decide to configure a group of IKEv2/IPsec
     gateways in a cluster for high-availability purposes, if the
     implementation used supports this. The peer does not necessarily
     have any way of knowing when the change occurs.

No sharing
     If the service parameters require changing, some changes may
     require terminating the old service, and starting a new
     conversation from phase 0. This approach is used by all services
     for at least some parameters, and it doesn't require any protocol
     for transferring the service SA between the service elements.

     The service may support keeping the old service element active
     while the new conversation takes phase, to decrease the time the
     service is not available.

Some sharing
     The service may allow changing some parameters by simply agreeing
     about the new values. This may involve a similar exchange as in
     phase 2, or perhaps a shorter conversation.

     This option usually requires some protocol for transferring the
     service SA between the elements. An administrator may decide not to
     enable this feature at all, and typically the sharing is restricted
     to some particular service elements (defined either by a service
     parameter, or simple administrative decision). If the old and new
     service element do not support such "context transfer", this
     approach falls back to the previous option (no transfer).

     Services supporting this feature should also consider what changes
     require new authorization from the backend authentication server
     (see Section 4.2).

     Note that these considerations are not limited to service
     parameters related to the authenticator--they apply to peer's
     parameters as well.