Review of draft-cam-winget-eap-fast-05.txt Publication Request ------------------- A request has been made from an individual submitter to publish EAP FAST as an Informational RFC. The document has gone to IETF last call: http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg03074.html Review Criteria --------------- EAP FAST is a deployed EAP method for which an EAP type code has already been allocated. Nevertheless, in carrying out the review, it seems appropriate to start with an RFC 3748 compliance review, as described here: http://www.drizzle.com/~aboba/EAP/template.txt In addition to reviewing RFC 3748 compliance, I have also appended additional comments relating to specification clarity and security issues. RFC 3748 Compliance Review -------------------------- 1. Does the method document its security properties in a sufficient manner, as required by Section 7.2 of RFC 3748? 1a. Mechanism. Is the mechanism explained? Yes. EAP-FAST supports certificate and shared-secret authentication mechanisms within TLS, and tunneled authentication methods within the TLS tunnel. 1b. Security claims. Are the claimed and not claimed properties listed? The document includes a Security Claims section 7.7. 1c. Justifications for the claims? Is an explanation or reference provided to each of the claims? The security claims are addressed in more detail within the document. For example, Section 7.1 deals with mutual authentication, confidentiality and integrity protection; Section 7.2 deals with method negotiation; Section 7.4.1 deals with user identity protection; 7.4.2 deals with Dictionary Attack Resistance; 7.4.3 with man-in-the-middle attacks; section 3.2 deals with ciphersuite negotiation; 3.2.1 and 3.2.2 deal with session resume; 3.5 deals with fragmentation. However, not enough detail is provided on the Tunnel PAC in Section 3.2.2 in order to evaluate its security properties. For example, the text is 1d. Key strength. Is the key strength documented? The key strength is based on the TLS key strength. However, there is no section in the security considerations section providing details. My recommendation would be to add text similar to what is included in RFC 2716bis: " BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57]. [RFC3766] Section 5 advises use of the following required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. Based on the table below, a 2048-bit RSA key is required to provide 128-bit equivalent key strength: Attack Resistance RSA or DH Modulus DSA subgroup (bits) size (bits) size (bits) ----------------- ----------------- ------------ 70 947 128 80 1228 145 90 1553 153 100 1926 184 150 4575 279 200 8719 373 250 14596 475" References [RFC3766] Orman. H. and P. Hoffman, "Determining Strengths for Public Keys Used for Exchanging Symmetric Keys", RFC 3766, April 2004. [SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006. 1e. Indication of vulnerabilities. Are the known vulnerabilities documented? Version number modification attacks are described in Section 3.1; they can be detected after the fact using the Crypto-Binding TLV described in Section 4.2.8. Tunneled EAP methods can be susceptible to man-in-the-middle attacks. Man-in-the-middle attacks due to tunneling are discussed in Section 7.4.3; the problem is dealt with by the crypto-binding exchange described in Section 5. Man-in-the-middle attacks are also possible during the PAC provisioning phase. However, PAC provisioning is outside the scope of this particular specification and is described in another document: [I-D.cam-winget-eap-fast-provisioning] Cam-Winget, N., "Dynamic Provisioning using EAP-FAST", draft-cam-winget-eap-fast-provisioning-02 (work in progress), March 2006. [Note: it seems unreasonable to require the documentation of unknown vulnerabilities :-) The "known" may of course be "known to reviewer" or "known to author" or "known to the community", but that appears to be best we can do.] 2. Compliance with EAP packet formats 2a. Does the method comply with the packet formats defined in Section 4 of RFC 3748? Yes. The basic EAP-FAST header is similar to EAP-TLS, RFC 2716. 3. Compliance with EAP behaviour 3a. Does the method comply with Success/Failure usage as defined in Sections 2, 2.2, and 4.2? Yes. 3b. Does the method comply with sequence usage as defined in Section 2.1 of RFC 3748? Yes. EAP-FAST supports authentication via multiple EAP methods in series; all inner methods must succeed for authentication to be considered successful. This is allowed within RFC 3748. 3c. Does the method comply with request/response processing rules as defined in Section 4.1 of RFC 3748? Yes. 3d. Does the method comply with retransmission rules as defined in Section 4.3 of RFC 3748? Yes. 3e. Does the method comply with the usage defined for Identity, as defined in Section 5.1 of RFC 3748? Yes. 3f. Does the method comply with the usage defined for Notification, as defined in Section 5.2 of RFC 3748? Yes. 3g. Does the method comply with the usage defined for Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748? Yes. 3h. Does the method comply with the MIC usage requirements from Sections 3.1, 7.5, and 7.8 of RFC 3748? As with other TLS-based EAP methods, the MIC does not cover the EAP header. This potentially leaves EAP FAST vulnerable to a type code substitution attack; however, no other EAP method utilizes the same MSK/EMSK generation mechanism so such an attack would fail based on existing TLS-based EAP methods. 4. Compliance with IANA requirements 4a. Does the method comply with EAP-based IANA requirements defined in Section 6 of RFC 3748? That is, if it requests the allocation of new numbers in the EAP namespace [not applicable if the numbers have already been allocated], is the type of the document and process appropriate for the desired action? No type code allocation is requested for EAP FAST. 4b. Does the method comply with other IANA requirements in the IETF standards track RFCs? For instance, does the method attempt to allocate TLS extensions (which would only be possible for standards track RFCs)? This specification relies on the TLS Ticket extension which has been published as RFC 4507: [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006. 5. Compliance with the EAP Key Management Framework 5a. Description of key hierarchy. Is the key hierarchy documented? Does the specification describe how the MSK and EMSK are calculated? Are the MSK and EMSK cryptogprahically independent? The key hierarchy is documented in Section 5. The MSK and EMSK (defined in Section 5.4) are cryptographically independent. 5b. Does the specification describe how the Peer-ID and Server-ID are determined (if supported)? No. From the text of Section 3.2.2 it is hard to tell if the Peer-Id and Server-Id are supported for the case of PAC authentication. For the certificate authentication case where both the Peer-Id and Server-Id are supported, I'd recommend addition of text similar to what is in RFC 2716bis: " The EAP-TLS peer name (Peer-Id) represents the Network Access Identifier (NAI) [RFC4282] to be used for access control and accounting purposes. The Peer-Id and Server-Id are determined from the subject or altSubjectName fields in the peer and server certificates. As noted in [RFC3280] Section 4.1.2.6: The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension... If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). Where the subject field is not empty, the Peer-Id and Server-Id are obtained from the Common Name (CN) field of the DN. Where subject naming information is present only in the subjectAltName extension, the Peer-Id and Server-Id are obtained from the subjectAltName." 5c. Does the specification define the Session-Id? No. I Recommend addition of the following text: Session-Id = 0x2B || client.random || server.random client.random = Nonce generated by the TLS client. server.random = Nonce generated by the TLS server. Other Comments -------------- Section 1 "establishing a Transport Layer Security (TLS) tunnel as defined in [RFC2246] or [RFC4346]" Since [RFC4346] obsoletes [RFC2246], why do we need to mention both? Section 3.2 It is RECOMMENDED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in [I-D.cam- winget-eap-fast-provisioning]. I think you need some additional text to limit the situations in which anonymous DH can be used within TLS, if you want the security claims of Section 7.7 to be true in all circumstances. For example, using anonymous DH with an inner method subject to dictionary attack (such as EAP-MSCHAPv2) would not be a good idea. Section 3.2.1 To support session resumption, the server and peer must minimally cache the Session ID, master secret and ciphersuite. Here "Session ID" refers to TLS, not the EAP Session-Id. I might recommend using the term "sessionId" for the TLS session identifier. Section 3.2.2 This section describes how EAP-FAST implements the TLS Ticket Extension [RFC4507], yet it is not clear whether the Tunnel PAC conforms to the recommendations in that document. While a detailed description of the tunnel PAC is not necessary to achieve interoperability, it is needed to understand the security properties provided by EAP FAST: 1. PAC-Key: this is a 32-octet key used by the peer to establish the EAP-FAST Phase 1 tunnel. This key is used to derive the TLS premaster secret as described in Section 5.1. The PAC-Key is randomly generated by the EAP Server to produce a strong entropy 32-octet key. The PAC-Key is a secret and MUST be treated accordingly. For example a PAC-Key must be delivered protected by a secure channel and stored securely. [BA] Is it required that the PAC-Key be delivered encrypted within a ticket including authorization so that it is bound to the context? Or can it be delivered in the clear, allowing its transfer to another entity? 2. PAC-Opaque: this is a variable length field that is sent to the EAP Server during the EAP-FAST Phase 1 tunnel establishment. The PAC-Opaque can only be interpreted by the EAP Server to recover the required information for the server to validate the peer's identity and authentication. For example, the PAC-Opaque includes the PAC-Key and may contain the PAC's peer identity. The PAC-Opaque format and contents are specific to the PAC issuing server. The PAC-Opaque may be presented in the clear, so an attacker MUST NOT be able to gain useful information from the PAC-Opaque itself. The server issuing the PAC-Opaque must ensure it is protected with strong cryptographic keys and algorithms. [BA] What do EAP FAST implementations actually include within the PAC Opaque? Is the Peer Identity included, providing binding of the PAC-Key to the context? Is the PAC-Opaque encrypted or not? 3. PAC-Info: this is a variable length field used to provide at minimum, the authority identity of PAC issuer. Other useful but not mandatory information, such as the PAC-Key lifetime, may also be conveyed by the PAC issuing server to the peer during PAC provisioning or refreshment. [BA] What do EAP FAST implementations include in the PAC-Info? Is the lifetime included? What about the identity of the issuer? Section 3.3 The TLV exchange may include the execution of zero or more EAP methods within the protected tunnel as described in Section 3.3.1. [BA] Presumably, an inner EAP method is required if anonymous DH is selected, no? _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf