eap Mailing List: Issue 294: Security Considerations & Requirements

[Bernard Aboba (aboba]

We have received a liaison request from 802.16e for a review of compliance
with RFC 3748 as well as the EAP Key Management framework.

In order to provide this review,  we need to come up with the
criteria,  much as we did for the RFC 3748 review required for EAP
methods.

Please take a look at these criteria and let me know what you think.

Assuming we think they make some sense, I'd like to propose we incorporate
them into a potential resolution of Issue 294.

--------------------------------------------------------------------------
Lower Layer Review

RFC 3748 Compatibility

Section 2.4: Does the lower layer enable peer to peer operation?
  a. Support for bi-directional session key derivation?
  b. Support for tie breaking?
  c. Support for peer and authenticator roles?

Section 3.1: Lower Layer Requirements
  a. Does the lower layer support error detection?
  b. Does the lower layer provide an EAP MTU of 1020 octets or greater?
  c. Does the lower layer support fragmentation and reassembly?
  d. Does the lower layer provide ordering guarantees?
  e. Does the lower layer provide non-duplication?

Housley Criteria (EAP Key management framework, Section 6.2)

   Algorithm independence
      Requirement: "Wherever cryptographic algorithms are chosen, the
      algorithms must be negotiable, in order to provide resilience
      against compromise of a particular cryptographic algorithm."

Does the lower layer negotiate cryptographic algorithms?

Does the lower layer suggest use of a AAA protocol that negotiates
cryptographic algorithms? (e.g. Diameter or RADIUS/IPsec?)

Does the lower layer require use of EAP methods
that support the "Protected Ciphersuite" claim in RFC 3748,
Section 7.2.1?

   Strong, fresh session keys
      Requirement: "Session keys must be demonstrated to be strong and
      fresh in all circumstances, while at the same time retaining
      algorithm independence."

Does the lower layer suggest use of a AAA protocol that generates
strong, fresh session keys to protect messages? (Diameter or
RADIUS/IPsec)?

Does the lower layer define the mechanisms by which session keys
are derived?

Do the mechanisms guarantee the freshness of transient session keys
in all circumstances?
  1. Does the lower layer determine the key lifetimes of the exported
     EAP keys and transient session keys so as to ensure they do not
     become stale?
  2. If the EAP exported keys are reused, does the lower layer
     guarantee freshness of transient session keys even where
     the peer or authenticator  cannot generate high entropy
     random numbers?

Does the lower layer require use of EAP methods that support
the "Key Derivation", "Key Strength", "Dictionary Attack
Resistance" and "Session Independence" security claims
defined in RFC 3748, Section 7.2.1?

Does the lower layer specify a minimum required key strength for
EAP methods?

   Replay protection
      Requirement: "All protocol exchanges must be replay protected."

Does the lower layer support integrity and replay protection?

Does the lower layer require use of EAP methods that support
the "Replay protection" and "Integrity protection" claims of
RFC 3748, Section 7.2.1?

   Authentication
      Requirements: "All parties need to be authenticated.  The
      confidentiality of the authenticator must be maintained.  No
      plaintext passwords are allowed."

Does the lower layer suggest use of a AAA protocol that
enables mutual authentication between the authenticator and
AAA server even where a proxy is present? (Diameter EAP w/redirect)

Does the lower layer provide for mutual authentication
between the EAP peer and authenticator?

Does the lower layer provide for the confidentiality
of the authenticator?

Does the lower layer prohibit cleartext passwords?

Does the lower layer require use of EAP methods that support
the "Mutual Authentication" security claim of RFC 3748,
Section 7.2.1.

   Authorization
      Requirement: "EAP peer and authenticator authorization must be
      performed."

Does the lower layer address the authorization and correctness issues
detailed in the EAP Key Framework Section 5?

Does the lower layer synchronize authorization state between the
peer and authenticator?

   Session keys
      Requirement: "Confidentiality of session keys must be maintained."

Does the lower layer suggest use of a AAA protocol that maintains
confidentiality of the AAA-Key even where a proxy is present?
(Diameter EAP w/redirect)

Does the lower layer maintain confidentiality of session keys?
   1. Does the lower layer disclose the AAA-Key to parties
      other than the EAP peer, authenticator and AAA server?
   2. Does the lower layer disclose session keys to parties
      other than the EAP peer and authenticator?
   3. Does the lower layer refer to or require EAP Key Management
      extensions? (e.g. things not in the EAP key mgmt framework)
   4.  Does the lower layer refer to or require AAA extensions?

   Ciphersuite negotiation
      Requirement: "The selection of the "best" ciphersuite must be
      securely confirmed."

Does the lower layer securely confirm the selection of the "best"
ciphersuite?

Does the lower layer require use of an EAP method that supports the
"Protected ciphersuite negotiation" security claim of RFC 3748,
Section 7.2.1?

   Unique naming
      Requirement: "Session keys must be uniquely named."

Does the lower layer support key caching?
  If so, does the lower layer enable determination of
  which of multiple AAA-Keys to use for a given session?

Does the lower layer provide for unique naming of keys?

Does the lower layer support use of AAA Key-Naming attributes if
present? (defined in Diameter EAP)

   Domino effect
      Requirement: "Compromise of a single authenticator cannot
      compromise any other part of the system, including session keys
      and long-term secrets."

Does the lower layer enable the peer to securely determine the identity
of the authenticator?

Does the lower layer ensure that exported EAP keys are used to
derive keys used by only one authenticator?

Does compromise of a single authenticator result in compromise of
other authenticators?

Does the lower layer require use of EAP methods that support the
"Session independence" claim of RFC 3748, Section 7.2.1?

   Key binding
      Requirement: "The key must be bound to the appropriate context."

Does the lower layer enable the peer and authenticator
to securely confirm EAP and session key context,  including:
    a. Key lifetimes
    b. NAS and peer identities
    c. Restrictions on key usage, where applicable

Does the lower layer enable the use of EAP methods that support the
"Channel Binding" claim of RFC 3748, Section 7.2.1?