Chris Newman has filed an IETF DISCUSS comment on RFC 2716bis Section 2.4.
The text of this section reads as follows:
"2.4. Ciphersuite and Compression Negotiation EAP-TLS implementations MUST
support TLS v1.0. EAP-TLS implementations need not necessarily support all
TLS ciphersuites listed in [RFC4346]. Not all TLS ciphersuites are
supported by available TLS tool kits and licenses may be required in some
cases. To ensure interoperability, EAP-TLS peers and servers MUST support
the TLS [RFC4346] mandatory-to-implement ciphersuite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA. In addition, EAP-TLS servers SHOULD support
and be able to negotiate all of the following TLS ciphersuites:
TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA In addition, EAP-TLS peers SHOULD support the
following TLS ciphersuites defined in [RFC3268]:
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Since TLS
supports ciphersuite negotiation, peers completing the TLS negotiation will
also have selected a ciphersuite, which includes encryption and hashing
methods. Since the ciphersuite negotiated within EAP-TLS applies only to the
EAP conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate
the ciphersuites used to secure data. TLS also supports compression as well
as ciphersuite negotiation. However, during the EAP-TLS conversation the EAP
peer and server MUST NOT request or negotiate compression."
Here is the comment:
"Chris Newman:Discuss [2008-01-24]:I'd like to discuss the cipher suite issue
raised in my comment on theIESG call. An RFC editor note or even an assurance
the typos will befixed before publication would suffice to clear my discuss
position.Comment [2008-01-10]:In this excerpt:---- all of the following TLS
ciphersuites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA In addition, EAP-TLS peers SHOULD support the
following TLS ciphersuites defined in [RFC3268]:
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA----There are two
errors: 1. two of the cipher suites are listed twice.2. the RC4_128 cipher
suite is not defined in RFC 3268.Q: Would it be useful for this protocol to
recommend support for theserver name indication extension in RFC 4366?
Otherwise the serverrequires an IP address for each name it supports."
The proposed resolution to this comment is as follows:
With respect to the server name indication extension, I am not sure
that the IP address issue applies to EAP-TLS, which typically runs
over the link layer without IP. Or is there something I'm missing?
With respect to the ciphersuite comments, I suggest that the
text of Section 2.4 be changed to the following:
"2.4. Ciphersuite and Compression Negotiation EAP-TLS implementations MUST
support TLS v1.0. EAP-TLS implementations need not necessarily support all
TLS ciphersuites listed in [RFC4346]. Not all TLS ciphersuites are
supported by available TLS tool kits and licenses may be required in some
cases. To ensure interoperability, EAP-TLS peers and servers MUST support
the TLS [RFC4346] mandatory-to-implement ciphersuite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
EAP-TLS peers and servers SHOULD also support and be able
to negotiate the following TLS ciphersuites:
TLS_RSA_WITH_RC4_128_SHA [RFC4346]
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268] In addition, EAP-TLS servers
SHOULD support and be able to negotiate the following TLS ciphersuite:
TLS_RSA_WITH_RC4_128_MD5 [RFC4346] Since TLS supports ciphersuite
negotiation, peers completing the TLS negotiation will also have selected a
ciphersuite, which includes encryption and hashing methods. Since the
ciphersuite negotiated within EAP-TLS applies only to the EAP conversation,
TLS ciphersuite negotiation MUST NOT be used to negotiate the ciphersuites
used to secure data. TLS also supports compression as well as ciphersuite
negotiation. However, during the EAP-TLS conversation the EAP peer and server
MUST NOT request or negotiate compression."
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
