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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf