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

["Bernard Aboba" <bernard_aboba at hotmail.com>]

Thank you for your detailed and thoughtful review comments.

> 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.

Right.

> 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.

The suggestion to split section 2.1 is a good one.

> 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...

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.

> 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.

> 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?

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.

> 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...

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.

> 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...?

Will have to think about this.

> 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?

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.

> 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...?

Yes, Most existing implementations do 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.

OK.

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

It isn't set in EAP Responses, correct.

> 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).

Thanks.  Will fix.

> 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? :-)

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 ;)

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

Will fix.

> 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

Will fix.



_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu