Subject: review of draft-cam-winget-eap-fast-05.txt

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Nov 2006 20:45:39 -0800 (PST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf