The IETF has recently been asked to review a lower layer (802.16e) for
compatibility with RFC 3748 and the Key Management Framework. There may
be other such review requests. As a result, we need to develop review
criteria. Here is a strawman.
Lower Layer Review Criteria
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?
Does the specification include requirements for the security properties of
EAP methods (e.g. list of requirements comparable to RFC 4017)?
EAP Key Management Framework
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 specification suggest use of a AAA protocol that negotiates
cryptographic algorithms? (e.g. Diameter or RADIUS/IPsec?)
Does the specification 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 specification 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?
3. Is freshness guaranteed even where one of the peer or authenticator
cannot generate high entropy random numbers?
Does the specification 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 specification require 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 specification 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 specification 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 specification require EAP key management extensions? If so, are
they specified?
Does the lower layer utilize cleartext passwords?
Does the specification 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 specification enable the EAP peer and authenticator to identify
each other?
Does the specification address the authorization and correctness issues
detailed in the EAP Key Framework Section 5?
Does the specification synchronize authorization state between the
peer and authenticator? For example, are key usage restrictions
communicated?
Does the lower layer refer to or require AAA extensions? If so, are they
specified?
Session keys
Requirement: "Confidentiality of session keys must be maintained."
Does the specification suggest use of a AAA protocol that maintains
confidentiality of the AAA-Key even where a proxy is present?
(e.g. Diameter EAP w/redirect)
Does the lower layer maintain confidentiality of session keys?
1. Does the lower layer disclose keying material used in the
derivation of session keys to parties other than the EAP peer,
authenticator and server?
2. Does the lower layer disclose session keys to parties
other than the EAP peer and authenticator?
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 keys to use for a given session?
Does the specification provide for unique naming of keys?
Does the key naming mechanism depend on the key itself? If so, has the
specification taken into account recent work on hash collisions?
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?
Can compromise of a single authenticator result in compromise of
other authenticators?
Are the session keys used by different authenticators required to be
cryptographically independent?
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 specification enable the peer and authenticator
to securely confirm EAP and session key context, including:
a. Key lifetimes
b. Authenticator and peer identities
c. Restrictions on key usage, where applicable
Does the specification discuss the use of EAP methods that support
the "Channel Binding" claim of RFC 3748, Section 7.2.1?
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap