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

[Bernard Aboba (aboba]

Issue 307: Rewrite of Section 7, Security Requirements
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 3/31/2005
Reference:
Document: KEYING-07
Comment type: T
Priority: S
Section: 7
Rationale/Explanation of issue

Section 7 consists of requirements on EAP methods, AAA
protocols, Secure Association Protocols and Ciphersuites that is in no way
tied back to the security requirements and threat model.  One is left to
wonder whether these "requirements" were developed out of thin air, or
whether there is any basis/justification for them.

Here is a reprint of what is in Section 7 currently.  At this point, much
of it appears redundant, or seems to belong elsewhere in the document.
>From what I can see, the document wouldn't suffer that much if the entire
section were deleted and the important parts found a home elsewhere. Am I
missing something?

7.  Security Requirements

   This section summarizes the security requirements that must be met by
   EAP methods, AAA protocols,  Secure Association Protocols and
   Ciphersuites in order to address the security threats described in
   this document. These requirements MUST be met by specifications
   requesting publication as an RFC.  Each requirement provides a
   pointer to the sections of this document describing the threat that
   it mitigates.

[BA] I think the intent is to describe the security properties that
EAP extensions and/or AAA key management schemes require.  But isn't
that what draft-housley-aaa-key-mgmt is attempting to do?  If so,
why duplicate that here?

7.1.  EAP Method Requirements

   It is possible for the peer and EAP server to mutually authenticate
   and derive keys.  In order to provide keying material for use in a
   subsequently negotiated ciphersuite, an EAP method supporting key
   derivation MUST export a Master Session Key (MSK) of at least 64
   octets, and an Extended Master Session Key (EMSK) of at least 64
   octets.  EAP Methods deriving keys MUST provide for mutual
   authentication between the EAP peer and the EAP Server.

[BA] Isn't this already in [RFC3748]?

   The MSK and EMSK MUST NOT be used directly to protect data; however,
   they are of sufficient size to enable derivation of a AAA-Key
   subsequently used to derive Transient Session Keys (TSKs) for use
   with the selected ciphersuite.  Each ciphersuite is responsible for
   specifying how to derive the TSKs from the AAA-Key.

   The AAA-Key is derived from the keying material exported by the EAP
   method (MSK and EMSK).  This derivation occurs on the AAA server.  In
   many existing protocols that use EAP, the AAA-Key and MSK are
   equivalent, but more complicated mechanisms are possible.

[BA] Some of this seems useful, but why does it belong in this section?

   EAP methods SHOULD ensure the freshness of the MSK and EMSK even in
   cases where one party may not have a high quality random number
   generator.  A RECOMMENDED method is for each party to provide a nonce
   of at least 128 bits, used in the derivation of the MSK and EMSK.

[BA] Isn't this in [RFC3748] too?

   EAP methods export the MSK and EMSK and not Transient Session Keys so
   as to allow EAP methods to be ciphersuite and media independent.
   Keying material exported by EAP methods MUST be independent of the
   ciphersuite negotiated to protect data.

   Depending on the lower layer, EAP methods may run before or after
   ciphersuite negotiation, so that the selected ciphersuite may not be
   known to the EAP method.  By providing keying material usable with
   any ciphersuite, EAP methods can used with a wide range of
   ciphersuites and media.

[BA] This seems to duplicate the "ciphersuite independence" discussion.
Recommend it be moved there or deleted.


   It is RECOMMENDED that methods providing integrity protection of EAP
   packets include coverage of all the EAP header fields, including the
   Code, Identifier, Length, Type and Type-Data fields.

[BA] [RFC3748] discusses this issue -- I think this can be deleted.

   In order to preserve algorithm independence, EAP methods deriving
   keys SHOULD support (and document) the protected negotiation of the
   ciphersuite used to protect the EAP conversation between the peer and
   server.  This is distinct from the ciphersuite negotiated between the
   peer and authenticator, used to protect data.

[BA] [RFC3748] discusses this issue -- I think this can be deleted.

   The strength of Transient Session Keys (TSKs) used to protect data is
   ultimately dependent on the strength of keys generated by the EAP
   method.  If an EAP method cannot produce keying material of
   sufficient strength, then the TSKs may be subject to brute force
   attack.  In order to enable deployments requiring strong keys, EAP
   methods supporting key derivation SHOULD be capable of generating an
   MSK and EMSK, each with an effective key strength of at least 128
   bits.

[BA] I don't think this adds much value either.

   Methods supporting key derivation MUST demonstrate cryptographic
   separation between the MSK and EMSK branches of the EAP key
   hierarchy.  Without violating a fundamental cryptographic assumption
   (such as the non-invertibility of a one-way function) an attacker
   recovering the MSK or EMSK MUST NOT be able to recover the other
   quantity with a level of effort less than brute force.

   Non-overlapping substrings of the MSK MUST be cryptographically
   separate from each other.  That is, knowledge of one substring MUST
   NOT help in recovering some other non-overlapping substring without
   breaking some hard cryptographic assumption.  This is required
   because some existing ciphersuites form TSKs by simply splitting the
   AAA-Key to pieces of appropriate length.  Likewise, non-overlapping
   substrings of the EMSK MUST be cryptographically separate from each
   other, and from substrings of the MSK.  The EMSK MUST NOT be
   transported to, or shared with, additional parties.

[BA] These paragraphs do seem useful.  But why do they belong here?

   Since EAP does not provide for explicit key lifetime negotiation, EAP
   peers, authenticators and authentication servers MUST be prepared for
   situations in which one of the parties discards key state which
   remains valid on another party.

[BA] This probably belongs in the key management section 4.

   The development and validation of key derivation algorithms is
   difficult, and as a result EAP methods SHOULD reuse well established
   and analyzed mechanisms for MSK and EMSK key derivation (such as
   those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
   inventing new ones.

[BA] Isn't this in [RFC3748] as well?

7.1.1.  Requirements for EAP methods

   In order for an EAP method to meet the guidelines for EMSK usage it
   must meet the following requirements:

      o It MUST specify how to derive the EMSK

      o The key material used for the EMSK MUST be
        computationally independent of the MSK and TEKs.

      o The EMSK MUST NOT be used for any other purpose than the key
        derivation described in this document.

[BA] The key derivation has been removed, so this needs to be revised.

      o The EMSK MUST be secret and not known to someone observing
        the authentication mechanism protocol exchange.

      o The EMSK MUST NOT be exported from the EAP server.

      o The EMSK MUST be unique for each session.

      o The EAP mechanism SHOULD use a unique identifier suitable for
naming the EMSK.

[BA] I think the key naming section takes care of this.

7.1.2.  Requirements for EAP applications

   In order for an application to meet the guidelines for EMSK usage it
   must meet the following requirements:

      o New applications following this specification SHOULD NOT use the
        MSK.  If more than one application uses the MSK, then the
        cryptographic separation is not achieved.  Implementations SHOULD
        prevent such combinations.

[BA] Does this still belong here?

      o A peer MUST NOT use the EMSK directly for cryptographic
        protection of data.

[BA] This one does seem important.

7.2.  AAA Protocol Requirements

   AAA protocols suitable for use in transporting EAP MUST provide the
   following facilities:

Security services
     AAA protocols used for transport of EAP keying material MUST
     implement and SHOULD use per-packet integrity and authentication,
     replay protection and confidentiality.  These requirements are met
     by Diameter EAP [I-D.ietf-aaa-eap], as well as RADIUS over IPsec
     [RFC3579].

Session Keys
     AAA protocols used for transport of EAP keying material MUST
     implement and SHOULD use dynamic key management in order to derive
     fresh session keys, as in Diameter EAP [I-D.ietf-aaa-eap] and
     RADIUS over IPsec [RFC3579], rather than using a static key, as
     originally defined in RADIUS [RFC2865].

[BA] This seems excessive.  RADIUS over IPsec is a SHOULD in [RFC3579].
Isn't that enough?

Mutual authentication
     AAA protocols used for transport of EAP keying material MUST
     provide for mutual authentication between the authenticator and
     backend authentication server.  These requirements are met by
     Diameter EAP [I-D.ietf-aaa-eap] as well as by RADIUS EAP [RFC3579].

Authorization
     AAA protocols used for transport of EAP keying material SHOULD
     provide protection against rogue authenticators masquerading as
     other authenticators.  This can be accomplished, for example, by
     requiring that AAA agents check the source address of packets
     against the origin attributes (Origin-Host AVP in Diameter, NAS-IP-
     Address, NAS-IPv6-Address, NAS-Identifier in RADIUS).  For details,
     see [RFC3579] Section 4.3.7.

Key transport
     Since EAP methods do not export Transient Session Keys (TSKs) in
     order to maintain media and ciphersuite independence, the AAA
     server MUST NOT transport TSKs from the backend authentication
     server to authenticator.

Key transport specification
     In order to enable backend authentication servers to provide keying
     material to the authenticator in a well defined format, AAA
     protocols suitable for use with EAP MUST define the format and
     wrapping of the AAA-Token.

[BA] This seems to be belaboring the obvious.  How can AAA protocols
transport keys without defining their format?

EMSK transport
     Since the EMSK is a secret known only to the backend authentication
     server and peer, the AAA-Token MUST NOT transport the EMSK from the
     backend authentication server to the authenticator.

[BA] This seems to belong in the earlier section relating to EMSK usage.

AAA-Token protection
     To ensure against compromise, the AAA-Token MUST be integrity
     protected, authenticated, replay protected and encrypted in
     transit, using well-established cryptographic algorithms.

[BA] This seems redundant with the "security services" requirement above.

Session Keys
     The AAA-Token SHOULD be protected with session keys as in Diameter
     [RFC3588] or RADIUS over IPsec [RFC3579] rather than static keys,
     as in [RFC2548].

[BA] I think this is redundant with the earlier session key paragraph.

Key naming
     In order to ensure against confusion between the appropriate keying
     material to be used in a given Secure Association Protocol
     exchange, the AAA-Token SHOULD include explicit key names and
     context appropriate for informing the authenticator how the keying
     material is to be used.

[BA] Jari questioned this one earlier.  Do we need this?

Key Compromise
     Where untrusted intermediaries are present, the AAA-Token SHOULD
     NOT be provided to the intermediaries.  In Diameter, handling of
     keys by intermediaries can be avoided using Redirect functionality
     [RFC3588].

[BA] This probably belongs in the security considerations section rather
than here.

7.3.  Secure Association Protocol Requirements

[BA] This section seems redundant with an earlier discussion of what the
Secure
Association Protocol does (Section 2).  I think it should either be
combined with
that, or deleted.

   The Secure Association Protocol supports the following:

Entity Naming
     The peer and authenticator SHOULD identify themselves in a manner
     that is independent of their attached ports.

Mutual proof of possession
     The peer and authenticator MUST each demonstrate possession of the
     keying material transported between the backend authentication
     server and authenticator (AAA-Key).

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

[BA] This seems to overlap with the Housley document.

Creation and Deletion
     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

Integrity and Replay Protection
     The Secure Association Protocol MUST support integrity and replay
     protection of all messages.

[BA] Again, draft-housley already says this.

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.

[BA] What is wrong with having the SAP "passed through" as long as the
conversation is cryptographically secure?

Derivation of transient session keys
     The Secure Association Protocol negotiation MUST support derivation
     of unicast and multicast transient session keys suitable for use
     with the negotiated ciphersuite.

[BA] I think Section 2 already says this.

TSK freshness
     The Secure Association (phase 2) Protocol MUST support the
     derivation of fresh unicast and multicast transient session keys,
     even when the keying material provided by the backend
     authentication server is not fresh.  This is typically supported by
     including an exchange of nonces within the Secure Association
     Protocol.

[BA] I think Section 2 already says this.

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.

Secure capabilities negotiation
     The Secure Association Protocol MUST support secure capabilities
     negotiation.  This includes security parameters such as the
     security association identifier (SAID) and ciphersuites, as well as
     negotiation of the lifetime of the TSKs, AAA-Key and exported EAP
     keys.  Secure capabilities negotiation also includes confirmation
     of the capabilities discovered during the discovery phase (phase
     0), so as to ensure that the announced capabilities have not been
     forged.

Key Scoping
     The Secure Association Protocol MUST ensure the synchronization of
     key scope between the peer and authenticator.  This includes
     negotiation of restrictions on key usage.

[BA] I think Section 2 already says this.

7.4.  Ciphersuite Requirements

   Ciphersuites suitable for keying by EAP methods MUST provide the
   following facilities:

TSK derivation
     In order to allow a ciphersuite to be usable within the EAP keying
     framework, a specification MUST be provided describing how
     transient session keys suitable for use with the ciphersuite are
     derived from the AAA-Key.

EAP method independence
     Algorithms for deriving transient session keys from the AAA-Key
     MUST NOT depend on the EAP method.  However, algorithms for
     deriving TEKs MAY be specific to the EAP method.

[BA] I think this is already discussed in the Method Independence section.

Cryptographic separation
     The TSKs derived from the AAA-Key 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.

[BA] Why not put these cryptographic requirements in one section?