Subject: [eap] Issue: Security associations

From: <[email-masked]>
Date: Wed, 15 Oct 2003 02:09:00 +0300

Oops, the previous e-mail wasn't actually a new issue; it was 
an update of issue 180 which has a wrong name (it should be
something else than "SA Descriptions"--the new issue in THIS
message is about SAs).

Security associations
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: October 14, 2003
Reference: 
Document: Keying framework
Comment type: T
Priority: 1
Section: 3
Rationale/Explanation of issue:

Here is proposed replacement for Section 3 of the keying
framework (will be updated during/after interim, especially
the 802.11i specific parts!).

3. Security Associations

   The EAP model has four types of security associations (SAs):

   [1] Long-term EAP SA.  This is an SA between the peer and
       backend authentication server, and it allows them
       to authenticate each other.

   [2] Short-term EAP method SA.  This SA is also between the peer
       and backend authentication server.  It stores state that
       can be used for "fast resume" or other functionality 
       in some EAP methods. Not all EAP methods have this SA.

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

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

3.1 Long-term EAP SA (peer - backend authentication server)
 
   In order for the peer and backend authentication server to
   authenticate each other, they need to store some information.
 
   The authentication can be based on different mechanisms, such
   as shared secrets or certificates. If the authentication is
   based on a shared secret key, the parties store the EAP
   method to be used and the key.  The backend authentication
   server also stores the peer's identity and/or other
   information necessary to decide whether access to some
   service should be granted. The peer stores information
   necessary to choose which secret to use for which service.

   (TBD: Possibility of "alternate means of access")

3.2 Short-term EAP method SA (peer - backend authentication server)

   An EAP method may store some state on the peer and backend
   authentication server even after phase 1a has completed.
   
   Typically, this is used for "fast resume": the peer and
   backend authentication server can confirm that they are still
   talking to the same party, perhaps using fewer roundtrips 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.

   Another purpose for an EAP method to keep state is for
   pseudonym-based identity protection. This usually works as a
   cache as well (the information will 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 some particular
   service type or authenticator; indeed, these EAP method SAs
   are especially useful when the peer often accesses services
   from many different authenticators.

   Each EAP method should specify how the parties select if an
   existing EAP method SA should be used, and which EAP method
   SA should be used (if several are maintained). Note that in
   case there are multiple different backend authentication
   servers, the EAP method SAs are not typically synchronized
   between them.

   EAP methods should also consider how long the SA is stored.  The
   "fast resume" typically assumes that the information needed
   (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.

3.2.1 Example: EAP-TLS

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

   o  Implicitly, the EAP method this method SA refers to (EAP-TLS)
   o  Session identifier (a random value selected by the server)
   o  Certificate of the other party (server stores the clients's 
      certificate and vice versa)
   o  Cipher spec and compression method
   o  Master secret (a secret key)
   o  Some kind of lifetime information (ensuring that the
      SA is not stored forever)
   o  If the client has multiple different credentials (certificates
      and corresponding private keys), 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.2.2 Example: EAP-AKA

   In EAP-AKA, after the EAP authentication the client and
   server can store the following information: 

   o  Implicitly, the EAP method this method SA refers to (EAP-AKA)
   o  A re-authentication pseudonym 
   o  The server stores 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)

   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.3 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  Keys used to protect the communication 
   o  Possibly also the Authorization Key, if there is a possibility 
      that it will be needed again (to refresh and/or resynchronize 
      other keys, or sequence numbers, or something else)

   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
   subconversations with different parameters.
 
   How exactly the relevant service SA is chosen at each point
   depends on the protocol; see below for examples.

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

   o  PMKSA

      -  Key (PMK)
      -  PMKID 
      -  SSID
      -  Supplicant and authenticator group addresses (PMKSA can be 
         used if the SSID and group addresses stay the same)
      -  Key replay counters (for EAPOL-Key messages)
      -  Lifetime information (that can be different client and AP)

      -  Reference to PTKSA (if any), needed for:
         - to delete it (e.g. AAA server-initiated disconnect)
         - to replace it when a new four-way handshake is done
           after reauthentication

      -  Authorization information. On the authenticator, this
         can be locally configured or received from the backend
         authentication server. On the peer, this is usually
         locally configured.
         
      -  Reference to accounting context (the details of which depend 
         on the accounting protocol used, and various implementation 
         and administrative details. In RADIUS, this could include 
         e.g. packet and octet counters, and Acct-Multi-Session-Id).
      
   o  PTKSA

      The PTKSA is created based on the four-way handshake.
      When receiving or sending a packet, the correct PTKSA is
      looked up based on TA and RA (Transmitter/Received
      Address).

      -  Key (PTK)
      -  Selected ciphersuite
      -  MAC addresses of the parties
      -  Replay counters, and ciphersuite specific state
      -  Reference to PMKSA: This is needed for
         - If a new four-way handshake is needed (lifetime, TKIP
           countermeasures), we need to know which PMKSA to use
      -  Via the reference to PMKSA, or copied here: 
         - SSID (to select VLAN tags)
         - Authorization information (such as L2 packet filters)
         - Reference to accounting context (right counters etc.)

   o  GTKSA

      The GTKSA is created based on the four-way handshake, or
      the four-way handshake and a separate group key handshake.
      When receiving a packet, the correct GTKSA is looked up
      based on source MAC address. When sending a packet, this
      is looked up by own MAC address and SSID.

      -  Direction bit
      -  Key (GTK)
      -  Sender (AP) MAC address 
      -  Selected cipher suite
      -  Ciphersuite-specific data
      -  Via reference to PMKSA, or copied here:
         - SSID (to select VLAN tags)
         - Reference to accounting context

3.3.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 
      -  Identitites 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.3.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:

   o  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.

   o  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.

   o  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 1.7).

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

3.4 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 in the same node, and they communicate using,
   for instance, local procedure calls or shared memory, this SA
   does not necessarily contain any information.

3.4.1 Example: RADIUS

   In RADIUS, the parties store the other party's IP address and
   the shared secret. This shared secret is used to calculate
   Response Authenticator and Message-Authenticator values, and
   to encrypt some attributes (such as Authorization key).

3.4.2 Example: Diameter with TLS

   If using Diameter protected by TLS, the parties store
   information necessary to authenticate the other party (e.g.,
   certificate, or trust anchors and a name). Running 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.).

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