From: <Pasi.Eronen at nokia.com>
To: <emu at ietf.org>
Subject: [Emu] WGLC comments for draft-simon-emu-rfc2716bis
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
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
