 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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 the IESG call. An RFC editor note or even an assurance the typos will be fixed 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 the server name indication extension in RFC 4366? Otherwise the server requires 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 Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu