idnits 2.17.1 draft-badra-tls-identity-protection-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 27, 2012) is 4413 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: 'EAPIP' is mentioned on line 111, but not defined == Missing Reference: 'CORELLA' is mentioned on line 120, but not defined == Missing Reference: 'Google' is mentioned on line 129, but not defined == Missing Reference: 'Hajjeh' is mentioned on line 306, but not defined == Unused Reference: 'RFC2119' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'I-D.agl-tls-encryptedclientcerts' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'I-D.hajjeh-tls-identity-protection' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'I-D.urien-badra-eap-tls-identity-protection' is defined on line 348, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 10 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 March 27, 2012 5 Expires: September 28, 2012 7 SCSV for TLS Client Credential Protection 8 draft-badra-tls-identity-protection-02.txt 10 Abstract 12 This document defines a special Signaling Cipher Suite Value (SCSV) 13 "TLS_IDENTITY_PROTECTION_SCSV" to add client credential protection to 14 the TLS protocol. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 28, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. The cipher suite TLS_IDENTITY_PROTECTION_SCSV . . . . . . . . . 4 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 54 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Contributor's Address . . . . . . . . . . . . . . . . . . . . . 8 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 1. Introduction 63 The TLS [RFC5246] authentication is usually based on either preshared 64 keys or public key certificates. If a public key certificate is used 65 to authenticate the TLS client, the TLS client credentials are sent 66 in clear text over the wire. Thus, any observer can determine the 67 credentials used by the client; learn who is reaching the network, 68 when, and from where, and hence correlate the client credentials to 69 the connection location. 71 Credentials protection and privacy are the right to informational 72 self-determination, i.e., individuals must be able to determine for 73 themselves when, how, to what extent and for what purpose information 74 about them is communicated to others. 76 TLS client credential protection may also be done through a DHE 77 exchange before establishing an ordinary handshake with identity 78 information. This wouldn't however be secure enough against active 79 attackers, which will be able to disclose the client's credentials. 80 Moreover, it wouldn't be favorable for some environments (e.g., 81 performance-constrained environments with limited CPU power), due to 82 the additional cryptographic computations and round trips. 84 TLS client credential protection may also be possible, assuming that 85 the client permits renegotiation after the first server 86 authentication [RFC5246]: The client and the server establish a TLS 87 session with only server-side authentication and then perform a new 88 full TLS Handshake with mutual authentication; the client credentials 89 transferred in this stage thus are protected by the secure channel 90 established in the first TLS Handshake. This solution doesn't 91 require a change to TLS. However, this solution requires more 92 asymmetric cryptographic computations, which in many environments (in 93 particular for less powerful mobile nodes) are the rate limiting step 94 in TLS, and therefore, the renegotiation has negative performance 95 consequences. In fact, renegotiation requires another round of an 96 asymmetric encryption/decryption, which means the double number of 97 asymmetric en-/decryption operations (e.g., with an RSA key) for TLS 98 Handshake message processing, for both server and client. Moreover, 99 renegotiation requires twice the number of messages and roundtrips 100 than a single TLS handshake, thus significantly increasing the 101 overall delay in the session setup. Additionally, the server is 102 forced to complete a full first TLS handshake before it becomes able 103 to confirm whether the client has a valid certificate or not. This 104 increased misbalance in processing load in the failure case might 105 open an opportunity for misbehaving clients to perform resource 106 exhaustion attacks against such servers. 108 TLS client credential protection may as well be done by allowing the 109 client and the server to add a TLS extension to their Hello messages 110 in order to negotiate specific crypto algorithms, and use these to 111 protect the client certificate [EAPIP]. However, both the SSLv3 and 112 TLS 1.0/TLS 1.1 specifications require implementations to ignore data 113 following the ClientHello (i.e., extensions) if they do not 114 understand it. However, some SSLv3 and TLS 1.0 implementations 115 incorrectly fail the handshake in such a case. This means that 116 clients that offer extensions may encounter handshake failures. 118 TLS client credential protection may be established by changing the 119 order of the messages that the client sends after receiving 120 ServerHelloDone [CORELLA]. It consists of sending the 121 ChangeCipherSpec message before the Certificate and the 122 CertificateVerify messages and after the ClientKeyExchange message. 123 The ChangeCipherSpec message is sent to notify the receiving party 124 that subsequent messages will be protected under the cipher suite and 125 keys negotiated during the TLS Handshake. However, at its 126 publication date, this solution required a major change to the TLS 127 state machine as well as a new TLS version. Currently, it is 128 possible to change the order of the message by defining new TLS 129 extensions [Google]. 131 TLS client credential protection may be done by a signalling 132 mechanism based on a set of cipher suites [Hajjeh]. 134 This document defines a special Signaling Cipher Suite Value (SCSV) 135 "TLS_IDENTITY_PROTECTION_SCSV", with code point {0xXX, 0xXX}, to add 136 client credential protection to the TLS protocol. If a client offers 137 the SCSV and the server replies with the ServerHello, the client MUST 138 send the ChangeCipherSpec message before the Certificate and the 139 CertificateVerify messages and after the ClientKeyExchange message. 141 Current TLS specifications note that if the client certificate 142 already contains a suitable DH or ECDH public key, then Yc is 143 implicit and does not need to be sent again and consequently, the 144 client key exchange message will be sent, but it MUST be empty. Even 145 if the client key exchange message is used to carry the Yc, using the 146 same Yc will allow traceability. Consequently, static Diffie-Hellman 147 SHOULD NOT be used with this document. 149 2. The cipher suite TLS_IDENTITY_PROTECTION_SCSV 151 The TLS_IDENTITY_PROTECTION_SCSV is not a true cipher suite (it does 152 not correspond to any valid set of algorithms) and cannot be 153 negotiated. By including this cipher suite in the ClientHello 154 message, the TLS clients will be able to determine for themselves 155 when, how, to what extent and for what purpose information about them 156 is communicated to others. 158 Clients that choose to protect their credentials MUST provide the 159 TLS_IDENTITY_PROTECTION_SCSV SCSV in their ClientHello. 161 When a ClientHello is received, the server MUST check if it includes 162 the TLS_IDENTITY_PROTECTION_SCSV: 164 o If the server does not support the client credential protection 165 described here, the server MUST abort the handshake (by sending a 166 fatal handshake_failure alert). 168 o If the server supports the client credential protection described 169 here, the server MUST request a certificate from the client. If 170 the server does not receive a client certificate in response to 171 the subsequent certificate request, then it MAY abort the session 172 by sending a fatal handshake failure alert. 174 A TLS server who supports the TLS_IDENTITY_PROTECTION_SCSV MUST 175 compute the verify_data as follows: 177 verify_data 178 PRF(master_secret, finished_label, Hash(handshake_messages + { 0xXX,0xXX })) 179 [0..verify_data_length-1]; 181 where "+" denotes concatenation. 183 { 0xXX,0xXX } 184 The code of TLS_IDENTITY_PROTECTION_SCSV SCSV. 186 When a ServerHello is received, the client MUST send the 187 ChangeCipherSpec message before the Certificate and the 188 CertificateVerify messages and after the ClientKeyExchange message. 189 The ChangeCipherSpec message is sent to notify the receiving party 190 that subsequent messages will be protected under the cipher suite and 191 keys negotiated during the TLS Handshake. 193 Client Server 195 ClientHello --------> 196 ServerHello 197 Certificate 198 CertificateRequest 199 <-------- ServerHelloDone 200 ClientKeyExchange 201 ChangeCipherSpec 202 ChangeCipherSpec 203 <-------- Finished 204 Certificate 205 CertificateVerify 206 Finished --------> 207 Application Data <-------> Application Data 209 Once a client received and validated the Finished message from the 210 server, it MUST send the Certificate and the CertificateVerify 211 messages to the server. If the client unsuccessfully validated the 212 Finished received from the server, the client MUST abort the 213 handshake (by sending a fatal decrypt_error alert). 215 3. IANA Considerations 217 IANA is requested to add the TLS cipher suite number 0xXX,0xXX with 218 name TLS_IDENTITY_PROTECTION_SCSV to the TLS Cipher Suite registry. 220 4. Security Considerations 222 The security considerations described throughout [RFC5246] apply here 223 as well. 225 Actives attacks and eavesdroppers are impossible because the client 226 MUST terminate the connection immediately upon failure to receive a 227 valid Finished from the server without sending the Certificate and 228 CertificateVerify messages. Such clients MUST generate a fatal 229 "decrypt_error" alert prior to terminating the connection. 231 In order for the client to be protected against man-in-the-middle 232 attacks, the client SHOULD verify that the server provided a valid 233 certificate and that the received public key belongs to the server. 235 Because the question of whether this is the correct certificate is 236 outside of TLS, applications that do implement credential protection 237 cipher suites SHOULD enable the client to carefully examine the 238 certificate presented by the server to determine if it meets its 239 expectations. Particularly, the client MUST check its understanding 240 of the server hostname against the server's identity as presented in 241 the server Certificate message. 243 In the absence of an application profile specifying otherwise, the 244 matching is performed according to the following rules: 246 o The client MUST use the server hostname it used to open the 247 connection (or the hostname specified in the TLS "server_name" 248 extension [RFC6066]) as the value to compare against the server 249 name as expressed in the server certificate. The client MUST NOT 250 use any form of the server hostname derived from an insecure 251 remote source (e.g., insecure DNS lookup). CNAME canonicalization 252 is not done. 254 o If a subjectAltName extension of type dNSName is present in the 255 certificate, it MUST be used as the source of the server's 256 identity. 258 o Matching is case-insensitive. 260 o A "*" wildcard character MAY be used as the left-most name 261 component in the certificate. For example, *.example.com would 262 match a.example.com, foo.example.com, etc., but would not match 263 example.com. 265 o If the certificate contains multiple names (e.g., more than one 266 dNSName field), then a match with any one of the fields is 267 considered acceptable. 269 If the match fails, the client MUST either ask for explicit user 270 confirmation or terminate the connection and indicate the server's 271 identity is suspect. 273 Additionally, the client MUST verify the binding between the identity 274 of the server to which it connects and the public key presented by 275 this server. The client SHOULD implement the algorithm in Section 6 276 of [RFC5280] for general certificate validation, but MAY supplement 277 that algorithm with other validation methods that achieve equivalent 278 levels of verification (such as comparing the server certificate 279 against a local store of already-verified certificates and identity 280 bindings). 282 If the client has external information as to the expected identity of 283 the server, the hostname check MAY be omitted. 285 It will depend on the application whether or not the server will have 286 external knowledge of what the client's identity ought to be and what 287 degree of assurance it needs to obtain of it. In any case, the 288 server typically will have to check that the client has a valid 289 certificate chained to an application-specific trust anchor it is 290 configured with, following the rules of [RFC5280], before it 291 successfully finishes the TLS handshake. 293 One widely accepted layering principle is to decouple service 294 authorization from client authentication on access. We therefore 295 recommend that authorization decisions be performed and communicated 296 at the application layer after the TLS handshake has been completed. 298 5. Acknowledgements 300 The author would like to acknowledge Martin Rex and the TLS mailing 301 list members for their comments on the document. 303 In August 2000, Francisco Corella proposed adding identity protection 304 to TLS by changing the order of TLS messages. 306 This document borrows text from RFC5746 and from [Hajjeh] as well. 308 6. Contributor's Address 310 Ibrahim Hajjeh 311 Ineovation 312 France 314 EMail: ibrahim.hajjeh@ineovation.fr 316 7. References 318 7.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 324 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 326 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 327 Housley, R., and W. Polk, "Internet X.509 Public Key 328 Infrastructure Certificate and Certificate Revocation List 329 (CRL) Profile", RFC 5280, May 2008. 331 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 332 Extension Definitions", RFC 6066, January 2011. 334 7.2. Informative References 336 [I-D.agl-tls-encryptedclientcerts] 337 Langley, A., "Transport Layer Security (TLS) Encrypted 338 Client Certificates", 339 draft-agl-tls-encryptedclientcerts-00 (work in progress), 340 October 2011. 342 [I-D.hajjeh-tls-identity-protection] 343 Hajjeh, I. and M. Badra, "Credential Protection 344 Ciphersuites for Transport Layer Security (TLS)", 345 draft-hajjeh-tls-identity-protection-09 (work in 346 progress), November 2009. 348 [I-D.urien-badra-eap-tls-identity-protection] 349 Urien, P. and M. Badra, "Identity Protection within EAP- 350 TLS", draft-urien-badra-eap-tls-identity-protection-01 351 (work in progress), October 2006. 353 Author's Address 355 Mohamad Badra 356 DU 358 Email: mbadra@gmail.com