eap Mailing List: Re: Issue 307: Rewrite of Section 7, Security Requirements

[Bernard Aboba (aboba]

Here is a proposed resolution:

The overall recommendation is to delete Section 7.  Here are the details:

Section 7.1 appears to have been taken from [RFC3748] Section 7.10.  It is
therefore redundant and can be deleted.

Section 7.2 relates not to requirements but rather to the security
vulnerabilities inherent in RADIUS and Diameter usage.  It therefore
should be incorporated into Section 6, Security Considerations (See Issue
294).  One this is done, this section can be deleted.

Section 2.3, 4, 7.3 all include requirements relating to the Secure
Association Protocol.  The recommendation is to consolidate this material
into Section 4, while deleting Section 7.3, and replacing Section 2.3 with
the following:

"2.3.  Secure Association Phase

   The Secure Association phase (phase 2), if it occurs, begins after
   the completion of EAP authentication (phase 1a) and key transport
   (phase 1b).

   Secure Association Protocols typically include the following
   features:

[1]  Generation of fresh unicast and multicast transient session keys.

[2]  Integrity and replay protection.  This ensures that the Secure
     Association Protocol messages cannot be forged, modified or
     replayed.

[3]  Secure capabilities negotiation.  This enables security-relevant
     parameters such as cryptographic algorithms to be securely
     negotiated.

[3]  Key management and naming.  This enables security associations to
     be created and deleted, and for key state to be kept synchronized
     between the peer and authenticator.

[4]  Mutual proof of possession of EAP keying material between the peer
     and authenticator.  This enables the EAP peer and authenticator to
     confirm authorization.

   Aspects of the Secure Association Protocol are discussed in more
   detail in Section 4."

Replace Section 4 with the following:

"4.  Key Management

   EAP as defined in [RFC3748] supports key derivation, but not key
   management.  While EAP methods may derive keying material, EAP does
   provide for the management of exported or derived keys.  For example,
   EAP does not support negotiation of the key lifetime of exported or
   derived keys, nor does it support rekey.  Although EAP methods may
   support "fast reconnect" as defined in [RFC3748] Section 7.2.1, rekey
   of exported keys cannot occur without reauthentication.  In order to
   provide method independence, key management of exported or derived
   keys SHOULD NOT be provided within EAP methods.

   Since neither EAP nor EAP methods provide key management support, it
   is RECOMMENDED that key management facilities be provided within the
   Secure Association Protocol.  This includes:

[a]  Entity Naming.  A basic feature of a Secure Association Protocol is
     the explicit naming of the parties engaged in the exchange.
     Explicit identification of the parties is critical, since without
     this the parties engaged in the exchange are not identified and the
     scope of the EAP keying parameters negotiated during the EAP
     exchange is undefined.  As shown in Figure 3, both the peer and NAS
     may have more than one physical or virtual port.  As a result, the
     peer and authenticator SHOULD identify themselves in a manner that
     is independent of their attached ports.

[b]  Mutual proof of possession of EAP keying material.  The Secure
     Association Protocol MUST demonstrate possession of the keying
     material transported between the backend authentication server and
     authenticator (.e.g. AAA-Key), and show that both the peer and
     authenticator have been authenticated and authorized.  Since mutual
     proof of possession is not the same as mutual authentication, the
     peer cannot verify authenticator assertions (including the
     authenticator identity) as a result of this exchange.

[c]  Secure capabilities negotiation.  In order to protect against
     spoofing during the discovery phase, ensure selection of the "best"
     ciphersuite, and protect against forging of negotiated security
     parameters, the Secure Association Protocol MUST support secure
     capabilities negotiation.  This includes the secure negotiation of
     usage modes, session parameters (such as security association
     identifiers (SAIDs) and key lifetimes), ciphersuites and required
     filters, including confirmation of security-relevant capabilities
     discovered during phase 0.  As part of secure capabilities
     negotiation, the Secure Association Protocol MUST support integrity
     and replay protection of all messages.

[d]  Key naming and selection.  Where key caching is supported, it may
     be possible for the EAP peer and authenticator to share more than
     one key of a given type.  As a result, the Secure Association
     Protocol MUST explicitly name the keys used in the proof of
     possession exchange, so as to prevent confusion when more than one
     set of keying material could potentially be used as the basis for
     the exchange.  Use of the key naming mechanism described in this
     document is RECOMMENDED.

     In order to support the correct processing of phase 2 security
     associations, the Secure Association (phase 2) protocol MUST
     support 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.  The
     phase 2 Secure Association Protocol also MUST support transient
     session key activation and SHOULD support deletion, so that
     establishment and re-establishment of transient session keys can be
     synchronized between the parties.

[e]  Generation of fresh transient session keys (TSKs).  Where the lower
     layer supports caching of exported EAP keying material, the EAP
     peer lower layer may initiate a new session using keying material
     that was derived in a previous session.  Were the TSKs to be
     derived from a portion of the exported EAP keying material, this
     would result in reuse of the session keys which could expose the
     underlying ciphersuite to attack.

     As a result, in lower layers where caching of EAP keying material
     is supported, the Secure Association Protocol phase is REQUIRED,
     and MUST support the derivation of fresh unicast and multicast
     TSKs, even when the keying material provided by the backend
     authentication server is not fresh.  This is typically supported
     via the exchange of nonces or counters, which are then mixed with
     the exported keying material in order to generate  fresh unicast
     (phase 2a) and possibly multicast (phase 2b) session keys.  By not
     using EAP keying material directly to protect data, the Secure
     Association Protocol protects it against compromise.

[f]  Key lifetime management.  This includes explicit key lifetime
     negotiation or seamless rekey.  EAP does not support negotiation of
     key lifetimes, nor does it support rekey without reauthentication.
     As a result, the Secure Association Protocol may handle rekey and
     determination of the key lifetime.  Where key caching is supported,
     secure negotiation of key lifetimes is RECOMMENDED.  Lower layers
     that support rekey, but not key caching, may not require key
     lifetime negotiation.  To take an example from IKE, the difference
     between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were
     negotiated. In IKEv2, each end of the SA is responsible for
     enforcing its own lifetime policy on the SA and rekeying the SA
     when necessary.

[g]  Key resynchronization.  It is possible for the peer or
     authenticator to reboot or reclaim resources, clearing portions or
     all of the key cache.  Therefore, key lifetime negotiation cannot
     guarantee that the key cache will remain synchronized, and the peer
     may not be able to determine before attempting to use a key whether
     it exists within the authenticator cache.  It is therefore
     RECOMMENDED for the Secure Association Protocol to provide a
     mechanism for key state resynchronization.  Since in this situation
     one or more of the parties initially do not possess a key with
     which to protect the resynchronization exchange, securing this
     mechanism may be difficult.

[h]  Key scope synchronization.  Since the Discovery phase is handled
     out-of-band, EAP does not provide a mechanism by which the peer can
     determine the authenticator identity.  As a result, where the
     authenticator has multiple ports and key caching is supported, the
     EAP peer may not be able to determine the scope of validity of the
     exported EAP keying material.  Similarly, where the EAP peer has
     multiple ports, the authenticator may not be able to determine
     whether a peer has authorization to use a particular key.  To allow
     key scope determination, the Secure Association Protocol SHOULD
     provide a mechanism by which the peer can determine the scope of
     the key cache on each authenticator, and by which the authenticator
     can determine the scope of the key cache on a peer.  This includes
     negotiation of restrictions on key usage.

[i]  Direct operation.  Since the phase 2 Secure Association Protocol is
     concerned with the establishment of security associations between
     the EAP peer and authenticator, including the derivation of
     transient session keys, only those parties have "a need to know"
     the transient session keys. The Secure Association Protocol MUST
     operate directly between the peer and authenticator, and MUST NOT
     be passed-through to the backend authentication server, or include
     additional parties.

[j]  Bi-directional operation While some ciphersuites only require a
     single set of transient session keys to protect traffic in both
     directions, other ciphersuites require a unique set of transient
     session keys in each direction. The phase 2 Secure Association
     Protocol SHOULD provide for the derivation of unicast and multicast
     keys in each direction, so as not to require two separate phase 2
     exchanges in order to create a bi-directional phase 2 security
     association."

After deleting Sections 7.1, 7.2 and 7.3, all that remains of Section 7 is
Section 7.4 (Ciphersuite Requirements).  This section can be incorporated into
Section 1.4.4 (Ciphersuite Independence):

"1.4.4.  Ciphersuite Independence

   Ciphersuite Independence is a consequence of the principles of Mode
   Independence and Media Independence.

   While EAP methods may negotiate the ciphersuite used in protection of
   the EAP conversation, the ciphersuite used for the protection of the
   data exchanged after EAP authentication has completed is negotiated
   between the peer and authenticator within the lower layer, outside of
   EAP.

   For example, within PPP, the ciphersuite is negotiated within the
   Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
   authentication is completed.  Within [IEEE-802.11i], the AP
   ciphersuites are advertised in the Beacon and Probe Responses prior
   to EAP authentication, and are securely verified during a 4-way
   handshake exchange.

   Since the ciphersuites used to protect data depend on the lower
   layer, requiring EAP methods have knowledge of lower layer
   ciphersuites would compromise the principle of Media Independence.
   Since ciphersuite negotiation occurs in the lower layer, there is no
   need for ciphersuite negotiation within EAP, and EAP methods generate
   keying material that is ciphersuite-independent.

   Algorithms for deriving TSKs MUST NOT depend on the EAP
   method, although algorithms for TEK derivation MAY be specific
   to the EAP method.

   In order to allow a ciphersuite to be usable within the EAP keying
   framework, a specification MUST be provided describing how TSKs
   suitable for use with the ciphersuite are
   derived from exported EAP keying parameters.

   Advantages of ciphersuite-independence include:

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

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

Simplified configuration
     The ciphersuite is negotiated between the peer and authenticator
     outside of EAP.  Where the authenticator operates in "pass-through"
     mode, the EAP server is not a party to this negotiation, nor is it
     involved in the data flow between the EAP peer and authenticator.
     As a result, the EAP server may not have knowledge of the
     ciphersuites and negotiation policies implemented by the peer and
     authenticator, or be aware of the ciphersuite negotiated between
     them.  For example, since ECP negotiation occurs after
     authentication, when run over PPP, the EAP peer and server may not
     anticipate the negotiated ciphersuite and therefore this
     information cannot be provided to the EAP method."

The only remaining paragraph from Section 7.4 can be added to Section
2.5.1:

"  TSKs MUST be cryptographically separate from each other.  Similarly,
   TEKs MUST be cryptographically separate from each other.  In
   addition, the TSKs MUST be cryptographically separate from the TEKs."