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?