Subject: [Emu] WGLC comments for draft-simon-emu-rfc2716bis

From: <[email-masked]>
Date: Mon, 11 Dec 2006 17:08:28 +0200

Roughly in order of importance:

1) Section 2.7: "An EAP-TLS server supporting privacy MUST NOT treat a
certificate list containing no entries as a terminal condition;
instead it MUST bring up the TLS session and then send a server_hello
followed by a certificate_request."

Not quite correct... The TLS server sends hello_request, then the
handshake proceeds as normally (client sends client_hello, server
sends server_hello, certificate, server_key_exchange,
certificate_request, and server_hello_done, and so on). Example 2 in
Appendix B also needs to be fixed.

2) Section 2.1 is very long and quite difficult to read. I have two
suggestions for clarifying it a bit: First, split the text to four
subsections: first covering the basic case, the second session
resumption, the third privacy support (current section 2.7), and the
fourth the error cases. Second, copy or move some/all of the message
sequence diagrams from Appendix B to here.

3) The document would be much shorter if it omitted text that applies
to all EAP methods. This text might have been necessary when RFC 2716
was published, but not is largely covered by RFC 3748. For example,
Sections 2.2, the non-EAP-TLS specific parts of Section 3, Section
4.4, and Section 4.5 seem largely redundant to me...

4) Section 2.4, "SHOULD NOT use the identity presented in the Identity
Response for access control or accounting purposes": is using
unauthenticated information for access control or accounting purposes
really something where we think "there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or
even useful"? (quoting from RFC2119)

5) Section 2.4, "SHOULD also examine the Server-id in order to
determine whether the EAP server can be trusted": if this is really an
appropriate SHOULD, it definitely needs more discussion.  If you don't
check the name (the most important piece of information!) in the
certificate, why bother checking the certificate at all, or details
such as revocation? 

6) Section 2.4: "For example, an EAP peer connecting to the "EXAMPLE"
SSID may wish to check whether the Server-Id matches the regular
expression "*.example.com", in addition to checking whether the server
certificate chains to the example.com CA."

I find this suggestion quite dubious. So if I break into
www.example.com and steal its private key, I should be able to
masquerade as EAP server for EXAMPLE SSID? Even though this text is
only an example, it's one with serious security considerations...

7) Section 4.2 "Where the subject field is not empty, the Peer-Id and
Server-Id are obtained from the Common Name (CN) field of the DN"

It's not guaranteed a DN always include the CN field, or that it
includes only one CN field, or that the CN alone (without the rest of
the DN) is a meaningful identifier. So probably the Peer-Id/Server-ID
should be the whole DN...?

8) Section 4.2: "A valid EAP-TLS client certificate SHOULD contain an
extendedKeyUsage value indicating support for Client Authentication
(1.3.6.1.5.5.7.3.2).  A valid EAP-TLS server certificate SHOULD
contain an extendedKeyUsage value indicating support for Server
Authentication (1.3.6.1.5.5.7.3.1)."

According to RFC 3280, 1.3.6.1.5.5.7.3.2" means "TLS WWW client
authentication". Although EAP-TLS does use TLS, we're not doing WWW
client authentication here, so is the recommendation to include this
EKU a good one? Is it consistent with what existing implementations
do? Would it be better to recommend the EKUs from RFC 4334?

9) The document specifies a mandatory-to-implement cipher suite, but
not a mandatory-to-implement TLS version (it just says "The version
offered by the client [or server] MUST correspond to TLS v1.0 or
later"). I guess most implementations today use TLS 1.0...?

10) The document doesn't have an IANA considerations section. It
probably should ask IANA to update reference to EAP type 13 to this
document, and say that there are no other IANA actions.

11) Section 3.3: the Start bit is never set in EAP Responses, right?

12) Section 4.1: The table about key sizes is not actually identical to
the one in RFC 3766 (the numbers for DSA are slightly different).

13) Page 25 (Acknowledgments): "Thanks to Terence Spies, Glen Zorn and
Narendra Gidwani of Microsoft for useful discussions of this problem
space."  I didn't know Glen has moved to Microsoft? :-)

14) Typos: 
- Section 5.1 "Lefkowetz" -> "Levkowetz".
- Section 4.2 "altSubjectName" -> "subjectAltName"

15) From idnits:
- Line 194 has weird spacing: '...ssionId  will ...'
- Line 197 has weird spacing: '...ered by  the c...'
- Unused Reference: 'FIPS' is defined on line 1023, but not referenced
- Unused Reference: 'RFC1321' is defined on line 1064, but not
referenced
- Unused Reference: 'RFC1570' is defined on line 1067, but not
referenced
- Unused Reference: 'RFC1661' is defined on line 1070, but not
referenced
- Unused Reference: 'RFC1962' is defined on line 1073, but not
referenced
- Unused Reference: 'RFC1968' is defined on line 1076, but not
referenced
- Unused Reference: 'RFC1990' is defined on line 1079, but not
referenced

Best regards,
Pasi

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 11 Dec 2006 22:38:21 -0800

Thank you for your detailed and thoughtful review comments.

>Appendix B also needs to be fixed.

Right.

>sequence diagrams from Appendix B to here.

The suggestion to split section 2.1 is a good one.

>4.4, and Section 4.5 seem largely redundant to me...

I agree that Sections 2.2, 4.4 and 4.5 could probably be deleted, since much 
of this material is now in RFC 3748.   Section 3.1 could also probably be 
deleted, since it is just reprising the EAP packet format.

>even useful"? (quoting from RFC2119)

Some EAP-TLS implementations do match the identity in the Response with the 
identity included in the certificate, though this is not a good idea.  The 
SHOULD was left here so as to be compatible with
RFC 3748 Section 5.1:

      It is RECOMMENDED that the Identity Response be used primarily for
      routing purposes and selecting which EAP method to use.  EAP
      Methods SHOULD include a method-specific mechanism for obtaining
      the identity, so that they do not have to rely on the Identity
      Response.

>certificate, why bother checking the certificate at all, or details

Some implementations may not have expectations relating to the server name 
and may just verify the server certificate chain.  Verifying the certificate 
chain and checking revocation provide benefits independent of checking the 
server name against a pre-configured template.

>only an example, it's one with serious security considerations...

If you compromised the private key corresponding to the server certificate, 
then you could put up a rogue AP utilizing the EXAMPLE SSID, and could 
convince the EAP-TLS peer that your rogue AP was genuine.  I believe that 
such an attack would work on quite a few EAP/802.11 implementations, 
assuming that your rogue AP advertised the same security properties as the 
original EXAMPLE SSID.

>should be the whole DN...?

Will have to think about this.

>do? Would it be better to recommend the EKUs from RFC 4334?

Existing implementations do require these EKUs.  The EKUs from RFC 4334 have 
never been implemented.  I think that one of the ideas behind RFC 4334 was 
to provide additional  information for certificate selection, but that would 
require modifications to the TLS code base which seems unlikely.  So it 
might make sense to omit mention of RFC 4334, or even recommend against 
using those EKUs, since existing EAP-TLS servers will probably ignore them.

>later"). I guess most implementations today use TLS 1.0...?

Yes, Most existing implementations do use TLS 1.0.

>document, and say that there are no other IANA actions.

OK.

>11) Section 3.3: the Start bit is never set in EAP Responses, right?

It isn't set in EAP Responses, correct.

>the one in RFC 3766 (the numbers for DSA are slightly different).

Thanks.  Will fix.

>space."  I didn't know Glen has moved to Microsoft? :-)

At the time RFC 2716 was published he did work for Microsoft, but that was 
quite a while ago.
Time to update the acknowledgements section ;)

>- Section 4.2 "altSubjectName" -> "subjectAltName"

Will fix.

>- Unused Reference: 'RFC1990' is defined on line 1079, but not

Will fix.

---

From: <[email-masked]>
Date: Tue, 12 Dec 2006 12:48:02 +0200

Bernard Aboba wrote:

> >4) Section 2.4, "SHOULD NOT use the identity presented in the
> >Identity Response for access control or accounting purposes": is
> >using unauthenticated information for access control or accounting
> >purposes really something where we think "there may exist valid
> >reasons in particular circumstances when the particular behavior is
> >acceptable or even useful"? (quoting from RFC2119)
> 
> Some EAP-TLS implementations do match the identity in the Response
> with the identity included in the certificate, though this is not a
> good idea.  The SHOULD was left here so as to be compatible with RFC
> 3748 Section 5.1:
> 
>       It is RECOMMENDED that the Identity Response be used 
>       primarily for routing purposes and selecting which EAP method 
>       to use.  EAP Methods SHOULD include a method-specific mechanism 
>       for obtaining the identity, so that they do not have to rely on 
>       the Identity Response.

It's not a big problem if some implementations require that the
Identity Response matches the certificate, but it *is *a big problem
if they don't match, and unauthenticated information from Identity
Response is used for access control purposes. But I don't think this
is what RFC3748's SHOULD is about...

How about rephrasing the text to something like this?

   Since the identity presented in the Identity Response need not be
   related to the identity presented in the peer certificate, EAP-TLS
   implementations SHOULD NOT require that they be identical.
   However, if they are not identical, the identity presented in the
   Identity Response is unauthenticated information, and SHOULD NOT be
   used for access control or accounting purposes.

> >determine whether the EAP server can be trusted": if this is really
> >an appropriate SHOULD, it definitely needs more discussion.  If you
> >don't check the name (the most important piece of information!) in
> >the certificate, why bother checking the certificate at all, or
> >details such as revocation?
> 
> Some implementations may not have expectations relating to the
> server name and may just verify the server certificate chain.
> Verifying the certificate chain and checking revocation provide
> benefits independent of checking the server name against a
> pre-configured template.

I'm aware that some implementations do this, but the document should
explain the security implications better. If you compare the name in
the certificate with the expected server name, an attacker fool you if
he breaks into that server and steals its private key. If you don't
check the name, the attacker can steal a private key corresponding to
any certificate issued by your trusted CA (which in case of large CA
could be millions of potential points of failure).

Best regards,
Pasi

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 12 Dec 2006 10:55:12 -0800

Here are some of the changes to deal with the privacy comment.  Let me know 
if this resolves the issue.

In Section 2.6:

   An EAP-TLS server supporting privacy MUST NOT treat a certificate
   list containing no entries as a terminal condition;  instead it MUST
   bring up the TLS session and then send a hello_request.  The
   handshake then proceeds normally; the client sends a client_hello and
   the server replies with a server_hello, certificate,
   server_key_exchange, certificate_request, server_hello_done, etc.
   For an example, see Appendix B.

The example:

      2. In the case where the peer and server support privacy and
      mutual authentication, the conversation will appear as follows:

      Authenticating Peer     Authenticator
      -------------------     -------------
                              <- EAP-Request/
                              Identity
      EAP-Response/
      Identity (AnonymousNAI) ->

                              <- EAP-Request/
                              EAP-Type=EAP-TLS
                              (TLS Start)
      EAP-Response/
      EAP-Type=EAP-TLS
      (TLS client_hello)->
                              <- EAP-Request/
                              EAP-Type=EAP-TLS
                              (TLS server_hello,
                               TLS certificate,
                       [TLS server_key_exchange,]
                        TLS certificate_request,
                           TLS server_hello_done)
      EAP-Response/
      EAP-Type=EAP-TLS
      (TLS certificate (no cert),
       TLS client_key_exchange,
       TLS change_cipher_spec,
       TLS finished) ->
                              <- EAP-Request/
                              EAP-Type=EAP-TLS
                              (TLS change_cipher_spec,
                                hello_request)
      EAP-Response/
      EAP-Type=EAP-TLS
      (TLS client_hello)->
                              <- EAP-Request/
                              EAP-Type=EAP-TLS
                              (TLS server_hello,
                               [TLS certificate,]
                       [TLS server_key_exchange,]
                        TLS certificate_request,
                           TLS server_hello_done)
      EAP-Response/
      EAP-Type=EAP-TLS
      (TLS certificate,
       TLS client_key_exchange,
       TLS certificate_verify,
       TLS change_cipher_spec,
       TLS finished) ->
                              <- EAP-Request/
                              EAP-Type=EAP-TLS
                              (TLS change_cipher_spec,
                               TLS finished)
      EAP-Response/
      EAP-Type=EAP-TLS ->
                              <- EAP-Success

A version of the document with most of the changes made is available here:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 12 Dec 2006 15:54:44 -0800

I think I have now incorporated most of these comments into a strawman -06 
document:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt

Let me know if I've missed something.

>From: <[email-masked]>
>To: <[email-masked]>
>Subject: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
>Date: Mon, 11 Dec 2006 17:08:28 +0200
>
>

---

From: <[email-masked]>
Date: Wed, 13 Dec 2006 09:52:13 +0200

Thanks for handling my comments so quickly! (If every author had this
fast turnaround times, IETF would get documents to RFCs in a fraction
of current time... :-)

About 1: the figure in 2.6 is not quite right yet. There should be 
a finished message after the first change_cipher_spec sent by the
server, and the certificate/server_key_exchange messages after the 
second server_hello are not optional.

About 2: I'd further suggest rephrasing the last two paragraphs of
2.1.1 along these lines (basic case first, session resumption second):
 
   If the peer supports EAP-TLS and is configured to use it, it MUST
   respond to the EAP-Request with an EAP-Response packet of EAP-
   Type=EAP-TLS.  If the preceding server_hello message sent by the
   EAP server in the preceeding EAP-Request packet did not indicate
   the resumption of a previous session, the data field of this packet
   MUST encapsulate one or more TLS records containing a TLS
   client_key_exchange, change_cipher_spec and finished messages.  If
   the EAP server sent a certificate_request message in the preceding
   EAP-Request packet, then unless the peer is configured for privacy
   (see Section 2.6) the peer MUST send, in addition, certificate and
   certificate_verify messages.  The former contains a certificate for
   the peer's signature public key, while the latter contains the
   peer's signed authentication response to the EAP server.  After
   receiving this packet, the EAP server will verify the peer's
   certificate and digital signature, if requested.

   If the preceding server_hello message sent by the EAP server in the
   preceding EAP-Request packet indicated the resumption of a previous
   session, then the peer MUST send only the change_cipher_spec and
   finished handshake messages.  The finished message contains the
   peer's authentication response to the EAP server.

(And maybe Section 2.6 could be moved to 2.1.4?)

About 7: This one is not there yet.

About 9: The document still doesn't specify mandatory-to-implement TLS
version (which is required in addition to mandatory-to-implement
cipher suite to get interoperability).

About 11: The S bit was removed from the bit diagram, but the text
"The S bit (EAP-TLS start) is set in an EAP-TLS Start message" is
still there.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]] 
> Sent: 13 December, 2006 01:55
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
> 
> I think I have now incorporated most of these comments into a 
> strawman -06 document:

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 13 Dec 2006 05:23:51 -0800

Thanks for reviewing the changes.   To fix the remaining issues, I've done 
another revision:
http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt

This includes:

1. Corrections to the example (hopefully correct this time).   Also moved 
2.6 to 2.1.4.
2. Rephrasing of the paragraphs as you suggested.
9. Added a statement on mandatory-to-implement TLS v1.0 to Section 2.4.
11. Removed mention of the 'S' bit from Section 3.2.
7. Changed Section 5.2 to the following:

"5.2.  Certificate Usage

   The EAP-TLS peer name (Peer-Id) represents the Network Access
   Identifier (NAI) [RFC4282] to be used for access control and
   accounting purposes.  The Server-Id represents the identity of the
   EAP server.

   In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
   or subjectAltName 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 subjectAltName field is present, the Peer-Id or Server-Id
   is set to the contents of the subjectAltName.  If subject naming
   information is present only in the subject field, then the Peer-Id or
   Server-Id is set to the Distinguished Name (DN).

   A valid EAP-TLS client certificate SHOULD contain an Extended Key
   Usage field indicating support for Client Authentication
   (1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage.
   A valid EAP-TLS server certificate SHOULD contain an Extended Key
   Usage field indicating support for Server Authentication
   (1.3.6.1.5.5.7.3.1) or the special keyPurposeID anyExtendedKeyUsage.

   Certificate extensions for use with EAP-TLS are discussed in
   "Certificate Extensions and Attributes Supporting Authentication in
   Point-to-Point Protocol (PPP) and Wireless Local Area Networks
   (WLAN)" [RFC4334].  These extensions enable certificate usage to be
   restricted to use with lower layers such as PPP or IEEE 802.11.  An
   EAP-TLS implementation MAY make these and other certificate fields
   available to the lower layer.

   The peer MUST verify the validity of the EAP server certificate, and
   SHOULD also examine the Server-id in order to determine whether the
   EAP server can be trusted.  Even though a server certificate chains
   to a trust anchor, this does not necessarily imply that it is valid
   for connection to a particular network.

   Comparing the Server-Id in the certificate to the expected server
   name limits the damage that will result from an attacker compromising
   a server private key.  If the peer does not check the Server-Id, then
   the peer would accept a compromised server certificate chaining to
   any of the configured trust anchors.

   The peer MAY also test whether the EAP server certificate is signed
   by a CA controlling the destination network and whether the Server-Id
   matches the format expected for that network.  For example, an EAP
   peer connecting to the "EXAMPLE" SSID may check whether the Server-Id
   matches the regular expression "*.example.com", in addition to
   checking whether the server certificate chains to the example.com CA."

-------------------------------------------------------------------------------------------------------
>To: <[email-masked]>, <[email-masked]>
>Date: Wed, 13 Dec 2006 09:52:13 +0200
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Dec 2006 08:40:56 -0800 (PST)

>    used for access control or accounting purposes.

Looks good.

OK.