idnits 2.17.1 draft-badra-tls-ciphersuite-identity-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2012) is 4406 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Hajjeh' is mentioned on line 249, but not defined == Missing Reference: 'RFC6066' is mentioned on line 171, but not defined == Unused Reference: 'RFC4492' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'I-D.hajjeh-tls-identity-protection' is defined on line 279, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group M. Badra 3 Internet-Draft DU 4 Intended status: Standards Track I. Hajjeh 5 Expires: September 28, 2012 INEOVATION 6 March 27, 2012 8 Credential Protection Ciphersuites for Transport Layer Security (TLS) 9 draft-badra-tls-ciphersuite-identity-protection-00 11 Abstract 13 This document defines a set of cipher suites to add client credential 14 protection to the Transport Layer Security (TLS) protocol. By 15 negotiating one of those ciphersuites, the TLS clients will be able 16 to determine for themselves when, how, to what extent and for what 17 purpose information about them is communicated to others. The 18 ciphersuites defined in this document can be used only when public 19 key certificates are used in the client authentication process. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 28, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 57 2. The Credential Protection Ciphersuites . . . . . . . . . . . . 3 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 TLS client credential protection may be done by a signalling 69 mechanism based on a set of cipher suites as described in [Hajjeh]. 71 This document specifies a set of cipher suites to add client 72 credential protection to the TLS protocol. These cipher suites reuse 73 existing key exchange algorithms with certificate-based 74 authentication, and reuse existing cipher and MAC algorithms from 75 [RFC5246], [RFC5288], and [RFC5932]. 77 1.1. Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. The Credential Protection Ciphersuites 85 The name of cipher suites defined in this document includes the text 86 "CP" to refer to the client credential protection. An example is 87 shown below. 89 CipherSuite Key Exchange Cipher Hash 90 TLS_CP_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA1 92 The client indicates its willingness to protect its credentials by 93 including one or more ciphersuites described here in the 94 ClientHello.cipher_suites. These cipher suites MUST be placed at the 95 top of the cipher suite list. 97 When one of the cipher suites defined through this document is 98 negotiated, the client MUST send the ChangeCipherSpec message before 99 the Certificate and the CertificateVerify messages and after the 100 ClientKeyExchange message. 102 Client Server 104 ClientHello --------> 105 ServerHello 106 Certificate 107 CertificateRequest 108 <-------- ServerHelloDone 109 ClientKeyExchange 110 ChangeCipherSpec 111 ChangeCipherSpec 112 <-------- Finished 113 Certificate 114 CertificateVerify 115 Finished --------> 116 Application Data <-------> Application Data 118 If no certificates are available, the client MUST NOT include any 119 credential protection cipher suite in the ClientHello.cipher_suites. 121 If the server selects a cipher suite with client credential 122 protection, the server MUST send a certificate appropriate for the 123 negotiated cipher suite's key exchange algorithm, and MUST request a 124 certificate from the client. If the server, agreeing on using a 125 credential protection cipher suite, does not receive a client 126 certificate in response to the subsequent certificate request, then 127 it MUST abort the session by sending a fatal handshake failure alert. 128 The client certificate MUST be appropriate for the negotiated cipher 129 suite's key exchange algorithm, and any negotiated extensions. 131 Current TLS specifications note that if the client certificate 132 already contains a suitable DH or ECDH public key, then Yc is 133 implicit and does not need to be sent again and consequently, the 134 client key exchange message will be sent, but it MUST be empty. Even 135 if the client key exchange message is used to carry the Yc, using the 136 same Yc will allow traceability. Consequently, static Diffie-Hellman 137 SHOULD NOT be used with this document. 139 3. Security Considerations 141 The security considerations described throughout [RFC5246] apply here 142 as well. 144 Active attackers can modify messages and insert, remove, or replace 145 cipher suites. An attacker could attempt to get the peers to 146 negotiate a cipher suite that does not provide client credential 147 protection. However, actives attacks and eavesdroppers are 148 impossible here because the client MUST terminate the connection 149 immediately upon failure to receive a valid Finished from the server 150 without sending the Certificate and CertificateVerify messages. Such 151 clients MUST generate a fatal "decrypt_error" alert prior to 152 terminating the connection. 154 In order for the client to be protected against man-in-the-middle 155 attacks, the client SHOULD verify that the server provided a valid 156 certificate and that the received public key belongs to the server. 158 Because the question of whether this is the correct certificate is 159 outside of TLS, applications that do implement credential protection 160 cipher suites SHOULD enable the client to carefully examine the 161 certificate presented by the server to determine if it meets its 162 expectations. Particularly, the client MUST check its understanding 163 of the server hostname against the server's identity as presented in 164 the server Certificate message. 166 In the absence of an application profile specifying otherwise, the 167 matching is performed according to the following rules: 169 o The client MUST use the server hostname it used to open the 170 connection (or the hostname specified in the TLS "server_name" 171 extension [RFC6066]) as the value to compare against the server 172 name as expressed in the server certificate. The client MUST NOT 173 use any form of the server hostname derived from an insecure 174 remote source (e.g., insecure DNS lookup). CNAME canonicalization 175 is not done. 177 o If a subjectAltName extension of type dNSName is present in the 178 certificate, it MUST be used as the source of the server's 179 identity. 181 o Matching is case-insensitive. 183 o A "*" wildcard character MAY be used as the left-most name 184 component in the certificate. For example, *.example.com would 185 match a.example.com, foo.example.com, etc., but would not match 186 example.com. 188 o If the certificate contains multiple names (e.g., more than one 189 dNSName field), then a match with any one of the fields is 190 considered acceptable. 192 If the match fails, the client MUST either ask for explicit user 193 confirmation or terminate the connection and indicate the server's 194 identity is suspect. 196 Additionally, the client MUST verify the binding between the identity 197 of the server to which it connects and the public key presented by 198 this server. The client SHOULD implement the algorithm in Section 6 199 of [RFC5280] for general certificate validation, but MAY supplement 200 that algorithm with other validation methods that achieve equivalent 201 levels of verification (such as comparing the server certificate 202 against a local store of already-verified certificates and identity 203 bindings). 205 If the client has external information as to the expected identity of 206 the server, the hostname check MAY be omitted. 208 It will depend on the application whether or not the server will have 209 external knowledge of what the client's identity ought to be and what 210 degree of assurance it needs to obtain of it. In any case, the 211 server typically will have to check that the client has a valid 212 certificate chained to an application-specific trust anchor it is 213 configured with, following the rules of [RFC5280], before it 214 successfully finishes the TLS handshake. 216 One widely accepted layering principle is to decouple service 217 authorization from client authentication on access. We therefore 218 recommend that authorization decisions be performed and communicated 219 at the application layer after the TLS handshake has been completed. 221 4. IANA Considerations 223 This section provides guidance to the IANA regarding registration of 224 values related to the credential protection cipher suites. 226 CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5 = { 0xXX,0xXX }; 227 CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA = { 0xXX,0xXX }; 228 CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX }; 229 CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX }; 230 CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX }; 231 CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA256 = { 0xXX,0xXX }; 232 CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA256 = { 0xXX,0xXX }; 233 CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA = { 0xXX,0xXX }; 234 CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA = { 0xXX,0xXX }; 235 CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA256 = { 0xXX,0xXX }; 236 CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA256 = { 0xXX,0xXX }; 237 CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_GCM_SHA256 = { 0xXX,0xXX }; 238 CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_GCM_SHA384 = { 0xXX,0xXX }; 239 CipherSuite TLS_CP_RSA_WITH_ARIA_128_CBC_SHA256 = { 0xXX,0xXX }; 240 CipherSuite TLS_CP_RSA_WITH_ARIA_256_CBC_SHA384 = { 0xXX,0xXX }; 241 CipherSuite TLS_CP_RSA_WITH_ARIA_128_GCM_SHA256 = { 0xXX,0xXX }; 242 CipherSuite TLS_CP_RSA_WITH_ARIA_256_GCM_SHA384 = { 0xXX,0xXX }; 244 5. Acknowledgements 246 In August 2000, Francisco Corella proposed adding client credential 247 protection to TLS by changing the order of TLS messages. 249 This document borrows text from [Hajjeh]. 251 6. References 253 6.1. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, March 1997. 258 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 259 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 260 for Transport Layer Security (TLS)", RFC 4492, May 2006. 262 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 263 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 265 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 266 Housley, R., and W. Polk, "Internet X.509 Public Key 267 Infrastructure Certificate and Certificate Revocation List 268 (CRL) Profile", RFC 5280, May 2008. 270 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 271 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 272 August 2008. 274 [RFC5932] Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites 275 for TLS", RFC 5932, June 2010. 277 6.2. Informative References 279 [I-D.hajjeh-tls-identity-protection] 280 Hajjeh, I. and M. Badra, "Credential Protection 281 Ciphersuites for Transport Layer Security (TLS)", 282 draft-hajjeh-tls-identity-protection-09 (work in 283 progress), November 2009. 285 Authors' Addresses 287 Mohamad Badra 288 DU 290 Email: mbadra@gmail.com 292 Ibrahim Hajjeh 293 INEOVATION 295 Email: ibrahim.hajjeh@ineovation.com