eap Mailing List: RE: Rewrite of Key Framework Section 3

[Joseph Salowey (jsalowey]

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:

eap-admin [at] frascone.com 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
> 
>    EAP key management involves five types of security associations   
> (SAs): 
> 
[Joe] Use security relationships instead of security association

> [1]  EAP SA.  This is an SA between the peer and EAP server, which
>      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.

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

[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"

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

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

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

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

[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 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
> 

[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)

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

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

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

[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

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

[Joe] (Replace AAA-Key below with application (service) key )
 
>    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.
> 

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

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

[Joe] ( this section is very specific to the application of link layer
security and should be identified as such.)
 
> 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. 
>