Subject: [eap] Rewrite of Key Framework Section 3

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Apr 2004 15:50:27 -0700 (PDT)

I'm not posting this as an issue or resolution yet, since the text needs
quite a bit more work.  But here is the strawman text of Section 3.
Comments welcome.

3.  Security Associations

   EAP key management involves five types of security associations
   (SAs):

[1]  EAP SA.  This is an SA between the peer and EAP server, which
     allows them to authenticate each other.

[2]  EAP method SA.  This SA is also 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.

[3]  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.

[4]  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.

[5]  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 SA (peer - EAP server)

   In order for the peer and EAP 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 EAP 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.

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

   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.2.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 clients'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.2.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) (server)
      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.3.  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  Name/identifier for this SA
      o  Identities of the parties
      o  MSK and EMSK

3.4.  AAA SA(s) (authenticator - backend auth. 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.4.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.4.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.5.  Secure Association SAs

3.5.1.  Unicast Secure Association SA

   The unicast Secure Association SA exists between the EAP peer and
   authenticator.  It includes:

      o  the peer port identifier (Calling-Station-Id)
      o  the NAS port identifier (Called-Station-Id)
      o  the unicast Transient Session Keys (TSKs)
      o  the unicast Secure Association peer nonce
      o  the unicast Secure Association authenticator nonce
      o  the negotiated unicast capabilities and unicast ciphersuite.

   During the phase 2a exchange, the EAP peer and authenticator
   demonstrate mutual possession of the AAA-Key derived and transported
   in phase 1; securely negotiate the session capabilities (including
   unicast ciphersuites), and derive fresh unicast transient session
   keys.  The AAA-Key SA (phase 1b) is therefore used to create the
   unicast Secure Association SA (phase 2a), and in the process the
   phase 2a unicast Secure Association SA is bound to ports on the EAP
   peer and authenticator.  However in order for a phase 2a security
   association to be established, it is not necessary for the phase 1a
   exchange to be rerun each time.  This enables the EAP exchange to be
   bypassed when fast handoff support is desired.

   Since both peer and authenticator nonces are used in the creation of
   the unicast Secure Association SA,  the transient session keys (TSKs)
   are guaranteed to be fresh, even if the AAA-Key is not.  As a result
   one or more unicast Secure Association SAs (phase 2a) may be derived
   from a single AAA-Key SA (phase 1b).  The phase 2a security
   associations may utilize the same security parameters (e.g. mode,
   ciphersuite, etc.) or they may utilize different parameters.

   A unicast Secure Association SA (phase 2a) may not persist longer
   than the maximum lifetime of its parent AAA-Key SA (if known).
   However, the deletion of a parent EAP or AAA-Key SA does not
   necessarily imply deletion of the corresponding unicast secure
   association SA.  Similarly, the deletion of a unicast secure
   Association Protocol SA does not imply the deletion of the parent
   AAA-key SA or EAP SA.  Failure to mutually prove possession of the
   AAA-Key during the unicast Secure Association Protocol exchange
   (phase 2a) need not be grounds for removal of a AAA-Key SA by both
   parties; rate-limiting unicast Secure Association exchanges should
   suffice to prevent a brute force attack.

   An EAP peer may be able to negotiate multiple phase 2a SAs with a
   single EAP authenticator, or may be able to maintain multiple phase
   2a SAs with multiple authenticators, based on a single EAP SA derived
   in phase 1a. For example, during a re-key of the Secure Association
   protocol SA, it is possible for two phase 2a SAs to exist during the
   period between when the new phase 2a SA parameters (such as the TSKs)
   are calculated and when they are installed.  Except where explicitly
   specified by the semantics of the unicast Secure Association
   protocol, it should not be assumed that the installation of a new
   phase 2a SA necessarily implies deletion of the old phase 2a SA.

   On some media (e.g. 802.11) a port on an EAP peer may only establish
   phase 2a and 2b SAs with a single port of an authenticator within a
   given Local Area Network (LAN).  This implies that the successful
   negotiation of phase 2a and/or 2b SAs between an EAP peer port and a
   new authentiator port within a given LAN implies the deletion of
   existing phase 2a and 2b SAs with authenticators offering access to
   that Local Area Network (LAN).  However, since a given IEEE 802.11
   SSID may be comprised of multiple LANs, this does not imply an
   implicit binding of phase 2a and 2b SAs to an SSID.

3.5.2.  Multicast Secure Association SA

   The multicast Secure Association SA includes:

      o  the multicast Transient Session Keys
      o  the direction vector (for a uni-directional SA)
      0  the negotiated multicast capabilities and multicast ciphersuite

   It is possible for more than one multicast Secure Association SA to
   be derived from a single unicast Secure Association SA.   However, a
   multicast Secure Association SA is bound to a single EAP SA and a
   single AAA-Key SA.

   During a re-key of the multicast Secure Association Protocol SA, it
   is possible for two phase 2b SAs to exist during the period between
   when the new phase 2b SA parameters (such as the multicast TSKs) are
   calculated and when they are installed.  Except where explicitly
   specified by the semantics of the multicast Secure Association
   protocol, it should not be assumed that the installation of a new
   phase 2b SA necessarily implies deletion of the old phase 2b SA.

   A multicast Secure Association SA (phase 2b) may not persist longer
   than the maximum lifetime of its parent AAA-Key or unicast secure
   association SA. However, the deletion of a parent EAP, AAA-Key or
   unicast Secure Association SA does not necessarily imply deletion of
   the corresponding multicast Secure Association SA.  For example, a
   unicast Secure Association SA may be rekeyed without implying a rekey
   of the multicast Secure Association SA.

   Similarly, the deletion of a multicast Secure Association Protocol SA
   does not imply the deletion of the parent EAP, AAA-Key or unicast
   Secure Association SA.  Failure to mutually prove possession of the
   AAA-Key during the unicast Secure Association Protocol exchange
   (phase 2a) need not be grounds for removal of the AAA-Key, unicast
   Secure Association and multicast Secure Association SAs; rate-
   limiting unicast Secure Association exchanges should suffice to
   prevent a brute force attack.

3.6.  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)

   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.6.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.6.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.6.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 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.7.  Key Naming

   In order to support the correct processing of phase 2 security
   associations, the Secure Association (phase 2) protocol supports the
   naming of phase 2 security associations and associated transient
   session keys, 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 securely bind the AAA SA (phase 1b) to its child phase 2
   security associations, the phase 2 Secure Association Protocol allows
   the EAP peer and authenticator to mutually prove possession of the
   AAA-Key.  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, it is necessary for the secure
   Association Protocol (phase 2) to support key selection, so that the
   appropriate phase 1b keying material can be utilized by both parties
   in the Secure Association Protocol exchange.

   For example, a peer might be pre-configured with policy indicating
   the ciphersuite to be used in communicating with a given
   authenticator.  Within PPP, the ciphersuite is negotiated within the
   Encryption Control Protocol (ECP), after EAP authentication is
   completed.  Within [IEEE80211i], the AP ciphersuites are advertised
   in the Beacon and Probe Responses, and are securely verified during a
   4-way exchange after EAP authentication has completed.

   As part of the Secure Association Protocol (phase 2), it is necessary
   to bind the Transient Session Keys (TSKs) to the keying material
   provided in the AAA-Token.  This ensures that the EAP peer and
   authenticator are both clear about what key to use to provide mutual
   proof of possession.  Keys within the EAP key hierarchy are named as
   follows:

EAP SA name
     The EAP security association is negotiated between the EAP peer and
     EAP server, and is uniquely named as follows <EAP peer name, EAP
     server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
     Here the EAP peer name and EAP server name are the identifiers
     securely exchanged within the EAP method.  Since multiple EAP SAs
     may exist between an EAP peer and EAP server, the EAP peer nonce
     and EAP server nonce allow EAP SAs to be differentiated.  The
     inclusion of the Method Type in the EAP SA name ensures that each
     EAP method has a distinct EAP SA space.

AAA-Key Name
     The AAA-Key is named by the concatenation of the EAP SA name, "AAA-
     Key" and the authenticator name, since the AAA-Key is bound to a
     particular authenticator.  For the purpose of identification, the
     NAS-Identifier attribute is recommended.  In order to ensure that
     all parties can agree on the NAS name this requires the NAS to
     advertise its name (typically using a media-specific mechanism,
     such as the 802.11 Beacon/Probe Response)."

3.8.  Key Scoping

   A AAA-Key provided by the backend authentication server to the
   authenticator is for use only by that authenticator.  While AAA
   protocols such as RADIUS [RFC2865] or Diameter [RFC3588] support
   mutual authentication between the authenticator (known as the AAA
   client) and the backend authentication server (known as the AAA
   server), the security mechanisms vary according to the AAA protocol.

   In the case of RADIUS, the shared secret used for authentication is
   determined by the source address of the RADIUS packet. As noted in
   [RFC3579] Section 4.3.7, it is highly desirable that the source
   address be checked against one or more NAS identification attributes
   so as to detect and prevent impersonation attacks.

   A wide variety of authenticator and peer designs need to be
   accomodated within the EAP key management framework.  As noted in
   Section 1.3, an authenticator may contain multiple physical ports; a
   single physical authenticator may, for the purpose of peer discovery,
   advertise itself as multiple "virtual authenticators"; authenticators
   may be compromised of multiple CPUs; authenticators may utilize
   clustering in order to provide load balancing or failover.
   Similarly, a peer may support multiple ports; may support multiple
   CPUs; or may support clustering.

   While AAA protocols mutually authenticate the AAA client and server
   they do not distinguish authenticator architectures.  Therefore while
   the AAA-Key provided by the AAA server is for use solely by the
   authenticator receiving the key, by default the usage boundary is
   defined by the authenticator architecture.

   This may have unexpected consequences. Where a physical authenticator
   acts as multiple "virtual authenticators", unless each "virtual
   authenticator" identifies itself distinctly to the AAA server, then a
   AAA-Key provided by the AAA server is by default available for use by
   any of the "virtual authenticators".

   This enables potential security vulnerabilities. For example, an EAP
   peer could authenticate with the "guest" "virtual authenticator" and
   negotiate a AAA-Key. The peer could then attempt to use that AAA-Key
   to do a fast handoff to the "Corporate Intranet" virtual
   authenticator within the same physical authenticator. If the virtual
   authenticators do not identify themselves distinctly to the AAA
   server, then the key cache will be shared in common and the fast
   handoff attempt will be successful.

   In order to address this vulnerability, authenticators need to cache
   not only the AAA-Keys, but also the associated authorizations. This
   ensures that an attacker could not obtain elevated privileges even if
   they could authenticate successfully to another "virtual
   authenticator" hosted within the same physical chassis.

   If further protection is required, it is advisable for the AAA server
   to explicitly restrict the AAA-Key scope by including additional
   scope restriction attributes within the AAA-Token. Examples of scope
   restriction attributesw include:

Virtual authenticator restrictions
     In the case of 802.11, this could involve including a list of
     authorized Called-Station-Ids or SSIDs for which the AAA-Key is
     valid.

Peer restrictions
     In the case of 802.11, this could involve including a list of
     authorized Calling-Station-Ids for which the AAA-Key is valid.

     Note that in restricting the use of the AAA-Key it is important to
     ensure that the EAP peer can be made aware of the restriction so
     that the peer and authenticator can behave consistently.

3.9.  Authorization Issues

   In a typical network access scenario (dial-in, wireless LAN, etc.)
   access control mechanisms are typically applied. These mechanisms
   include user authentication as well as authorization for the offered
   service.

   As a part of the authentication process, the AAA network determines
   the user's authorization profile.  The user authorizations are
   transmitted by the backend authentication server to the EAP
   authenticator (also known as the Network Access Server or
   authenticator) included with the AAA-Token, which also contains the
   AAA-Key, in Phase 1b of the EAP conversation.  Typically, the profile
   is determined based on the user identity, but a certificate presented
   by the user may also provide authorization information.

   The backend authentication server is responsible for making a user
   authorization decision, answering the following questions:

[a]  Is this a legitimate user for this particular network?

[b]  Is this user allowed the type of access he or she is requesting?

[c]  Are there any specific parameters (mandatory tunneling, bandwidth,
     filters, and so on) that the access network should be aware of for
     this user?

[d]  Is this user within the subscription rules regarding time of day?

[e]  Is this user within his limits for concurrent sessions?

[f]  Are there any fraud, credit limit, or other concerns that indicate
     that access should be denied?

   While the authorization decision is in principle simple, the process
   is complicated by the distributed nature of AAA decision making.
   Where brokering entities or proxies are involved, all of the AAA
   devices in the chain from the authenticator to the home AAA server
   are involved in the decision.  For instance, a broker can disallow
   access even if the home AAA server would allow it, or a proxy can add
   authorizations (e.g., bandwidth limits).

   Decisions can be based on static policy definitions and profiles as
   well as dynamic state (e.g. time of day or limits on the number of
   concurrent sessions).  In addition to the Accept/Reject decision made
   by the AAA chain, parameters or constraints can be communicated to
   the authenticator.

   The criteria for Accept/Reject decisions or the reasons for choosing
   particular authorizations are typically not communicated to the
   authenticator, only the final result.  As a result, the authenticator
   has no way to know what the decision was based on.  Was a set of
   authorization parameters sent because this service is always provided
   to the user, or was the decision based on the time/day and the
   capabilities of the requesting authenticator device?

   Within EAP, "fast handoff" is defined as a conversation in which the
   EAP exchange (phase 1a) and associated AAA passthrough is bypassed,
   so as to reduce latency.  Depending on the fast handoff mechanism,
   AAA-Key transport (phase 1b) may also be bypassed or it may be
   provided in a pre-emptive manner as in [IEEE-03-084] and [I-D.irtf-
   aaaarch-handoff].

   As we will discuss, the introduction of fast handoff creates a new
   class of security vulnerabilities as well as requirements for the
   secure handling of authorization context.

3.10.  Correctness In Fast Handoff

   Bypassing all or portions of the AAA conversation creates challenges
   in ensuring that authorization is properly handled. These include:

[a]  Consistent application of session time limits.  A fast handoff
     should not automatically increase the available session time,
     allowing a user to endlessly extend their network access by
     changing the point of attachment.

[b]  Avoidance of privilege elevation.  A fast handoff should not result
     in a user being granted access to services which they are not
     entitled to.

[c]  Consideration of dynamic state.  In situations in which dynamic
     state is involved in the access decision (day/time, simultaneous
     session limit) it should be possible to take this state into
     account either before or after access is granted. Note that
     consideration of network-wide state such as simultaneous session
     limits can typically only be taken into account by the backend
     authentication server.

[d]  Encoding of restrictions.  Since a authenticator may not be aware
     of the criteria considered by a backend authentication server when
     allowing access, in order to ensure consistent authorization during
     a fast handoff it may be necessary to explicitly encode the
     restrictions within the authorizations provided in the AAA-Token.

[e]  State validity.  The introduction of fast handoff should not render
     the authentication server incapable of keeping track of network-
     wide state.

   A fast handoff mechanism capable of addressing these concerns is said
   to be "correct".  One condition for correctness is as follows: For a
   fast handoff to be "correct" it MUST establish on the new device the
   same context as would have been created had the new device completed
   a AAA conversation with the authentication server.

   A properly designed fast handoff scheme will only succeed if it is
   "correct" in this way.  If a successful fast handoff would establish
   "incorrect" state, it is preferable for it to fail, in order to avoid
   creation of incorrect context.

   Some backend authentication server and authenticator configurations
   are incapable of meeting this definition of "correctness".  For
   example, if the old and new device differ in their capabilities, it
   may be difficult to meet this definition of correctness in a fast
   handoff mechanism that bypasses AAA.  Backend authentication servers
   often perform conditional evaluation, in which the authorizations
   returned in an Access-Accept message are contingent on the
   authenticator or on dynamic state such as the time of day or number
   of simultaneous sessions.  For example, in a heterogeneous
   deployment, the backend authentication server might return different
   authorizations depending on the authenticator making the request, in
   order to make sure that the requested service is consistent with the
   authenticator capabilities.

   If differences between the new and old device would result in the
   backend authentication server sending a different set of messages to
   the new device than were sent to the old device, then if the fast
   handoff mechanism bypasses AAA, then the fast handoff cannot be
   carried out correctly.

   For example, if some authenticator devices within a deployment
   support dynamic VLANs while others do not, then attributes present in
   the Access-Request (such as the authenticator-IP-Address,
   authenticator-Identifier, Vendor-Identifier, etc.) could be examined
   to determine when VLAN attributes will be returned, as described in
   [RFC3580].   VLAN support is defined in [IEEE8021Q].  If a fast
   handoff bypassing the backend authentication server were to occur
   between a authenticator supporting dynamic VLANs and another
   authenticator which does not, then a guest user with access
   restricted to a guest VLAN could be given unrestricted access to the
   network.

   Similarly, in a network where access is restricted based on the day
   and time, Service Set Identifier (SSID), Calling-Station-Id or other
   factors, unless the restrictions are encoded within the
   authorizations, or a partial AAA conversation is included, then a
   fast handoff could result in the user bypassing the restrictions.

   In practice, these considerations limit the situations in which fast
   handoff mechanisms bypassing AAA can be expected to be successful.
   Where the deployed devices implement the same set of services, it may
   be possible to do successful fast handoffs within such mechanisms.
   However, where the supported services differ between devices, the
   fast handoff may not succeed.  For example, [RFC2865], section 1.1
   states:

      "A authenticator that does not implement a given service MUST NOT
      implement the RADIUS attributes for that service.  For example, a
      authenticator that is unable to offer ARAP service MUST NOT
      implement the RADIUS attributes for ARAP.  A authenticator MUST
      treat a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead."

   Note that this behavior only applies to attributes that are known,
   but not implemented.  For attributes that are unknown, section of 5
   of [RFC2865] states:

      "A RADIUS server MAY ignore Attributes with an unknown Type.  A
      RADIUS client MAY ignore Attributes with an unknown Type."

   In order to perform a correct fast handoff, if a new device is
   provided with RADIUS context for a known but unavailable service,
   then it MUST process this context the same way it would handle a
   RADIUS Access-Accept requesting an unavailable service.  This MUST
   cause the fast handoff to fail.  However, if a new device is provided
   with RADIUS context that indicates an unknown attribute, then this
   attribute MAY be ignored.

   Although it may seem somewhat counter-intuitive, failure is indeed
   the "correct" result where a known but unsupported service is
   requested. Presumably a correctly configured backend authentication
   server would not request that a device carry out a service that it
   does not implement.  This implies that if the new device were to
   complete a AAA conversation that it would be likely to receive
   different service instructions.  In such a case, failure of the fast
   handoff is the desired result.  This will cause the new device to go
   back to the AAA server in order to receive the appropriate service
   definition.

   In practice, this implies that fast handoff mechanisms which bypass
   AAA are most likely to be successful within a homogeneous device
   deployment within a single administrative domain. For example, it
   would not be advisable to carry out a fast handoff bypassing AAA
   between a authenticator providing confidentiality and another
   authenticator that does not support this service.  The correct result
   of such a fast handoff would be a failure, since if the handoff were
   blindly carried out, then the user would be moved from a secure to an
   insecure channel without permission from the backend authentication
   server.  Thus the definition of a "known but unsupported service"
   MUST encompass requests for unavailable security services.  This
   includes vendor-specific attributes related to security, such as
   those described in [RFC2548].

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 8 Apr 2004 22:23:50 -0700

It is often difficult to exactly define various security relationships, but
here is an attempt at some terminology:

A security association (SA) is state shared explicitly for the purpose of
providing secure communication between parties.  The state contains the key
material as well as the cryptographic and other parameters required for
securing the communication.  SAs are often (perhaps always?) established
dynamically.

Security Anchor is information required to bind data to a particular
cryptographic key or to verify the binding of data to a particular
cryptographic key.   Examples of anchors are shared secret keys and public
key pairs.   Security anchors enable security association establishment and
other security services.  

Based on the above I modified the text inline below:

[email-masked] wrote:
> I'm not posting this as an issue or resolution yet, since the
> text needs quite a bit more work.  But here is the strawman
> text of Section 3. Comments welcome.
> 
> 3.  Security Associations
> 
[Joe] Use security relationships instead of security association

>      allows them to authenticate each other.

[Joe] EAP Security Anchor is information shared between peer and EAP server,
which allows them to authenticate to each other.

>      functionality in some EAP methods.  Not all EAP methods

[Joe] All key deriving methods establish some sort of SA during their
operation.  In many cases the SA is transient and used solely for the
purpose of establishing key material which provides a security anchor for
future service or application SAs. Some EAP methods maintain the SA state
for the purpose of "fast resume"

>      this SA for pre-emptive key distribution.

[Joe] The EAP-Key security anchor is shared key material exported as the MSK
and EMSK from the EAP method.  From this EAP-Key security anchor application
specific security anchors are derived for the purpose of establishing
service or application SAs 
  
>      authenticate each other and protect the communications between  

[Joe] In general this is OK.  The two must share an anchor as well.  The
RADIUS SA is actually ambiguous between security association and security
anchor.  I suppose in the RADIUS case the are either the same or each RADIUS
exchange is a new SA.
 
>      and they are created as a result of phases 1-2 of the
>      conversation (see Section 1.3).
> 
[Joe] I've been using the term application, but I think service is a good
alternative.

> 3.1.  EAP SA (peer - EAP server)

[Joe] Security Anchor

> 3.2.  EAP Method SA (peer - EAP server)

[Joe] An EAP method typically establishes a security association during its
operation.  This SA is often transient in nature and torn down after the
EAP-Key material is exchanged.  The key material used to form the EAP Method
SA is never exported out of the method, only the MSK and EMSK established
through the EAP Method SA are exported from the method.
 
(The rest of the text is probably fine, but it may contains more detail than
necessary and is somewhat out of scope.)

>    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),
>       o  If the client has multiple different credentials
>          (certificates and corresponding private keys), a pointer to
> those credentials 
> 
>    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

[Joe] The EAP-Key security anchor is shared key material exported as the MSK
and EMSK from the EAP method.  From this EAP-Key security anchor application
(service) specific security anchors are derived for the purpose of
establishing service or application SAs.  Additional information is
associated with the EMSK and the MSK to form the security anchor including a
name for the MSK/EMSK and attributes determined during the EAP method
execution such as the Peer and Server identities.  

(I'm not sure it makes sense to list the contents of Sas in general)

>    memory, this SA need not necessarily contain any information.

(I'm not sure it makes sense to list the contents of Sas in general)

>    actual communications (session keys, selected TLS

[Joe] ( I don't understand why there is a section 3.5 and 3.6.  It seems to
inconsistent with the earlier text.  I think this should be combined into a
single section that talks about Application specific SAs with link layer
encryption as an example. Perhaps we should move all the examples to the
appendix)

> 3.5.  Secure Association SAs

[Joe] Application (Service) security associations are established between
parties using application specific security anchors derived from the EAP-Key
security anchor.  These security associations are established in an
application specific way.  The most widely used application for EAP key
material is link layer secure communication.  The following sections
describe some general detail of the SA used for this purpose.  

(somewhere in the document we need a general description on how key must be
derived and recommendations on how they be used. It probably doesn't belong
in this section.)

> 3.5.1.  Unicast Secure Association SA

[Joe] 3.5.1 Link Layer unicast application security association

>       o  the negotiated unicast capabilities and unicast ciphersuite.

[Joe] (Replace AAA-Key below with application (service) key )
 
>    demonstrate mutual possession of the AAA-Key derived and
>    transported in phase 1; securely negotiate the session
>    capabilities (including unicast ciphersuites), and derive fresh
>    unicast transient session keys.  The AAA-Key SA (phase 1b) is
>    therefore used to create the unicast Secure Association SA (phase
>    2a), and in the process the phase 2a unicast Secure Association SA
>    is bound to ports on the EAP peer and authenticator.  However in
>    order for a phase 2a security association to be established, it is
>    not necessary for the phase 1a exchange to be rerun each time. 
> This enables the EAP 
> exchange to be
>    are calculated and when they are installed.  Except where
>    explicitly specified by the semantics of the unicast Secure
>    Association protocol, it should not be assumed that the
>    installation of a new phase 2a SA necessarily implies deletion of
> the old phase 2a SA. 
> 
>    On some media (e.g. 802.11) a port on an EAP peer may only
>    establish phase 2a and 2b SAs with a single port of an
>    authenticator within a given Local Area Network (LAN).  This
>    implies that the successful negotiation of phase 2a and/or 2b SAs
> between an EAP peer 
> port and a

[Joe] (do we really need to talk about multicast Sas? What does this add?)

>    prevent a brute force attack.

[Joe] ( this section is very specific to the application of link layer
security and should be identified as such.)
 
>    The service SA stores information about the service being
> provided.    This includes: 
> 
>    provided is naturally divided into several different
>    subconversations with different parameters.
> 
> When processing an incoming message, the correct SA is looked
> up based on the SPIs.
> 
> o IPsec SAs/SPD
> 
>    - Traffic selectors
> 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.
> 
>      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). 
>