idnits 2.17.1 draft-balfanz-tls-obc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2011) is 4547 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'EncryptedClientCerts' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'WebOrigin' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Balfanz, Ed. 3 Internet-Draft D. Smetters 4 Expires: May 16, 2012 M. Upadhyay 5 A. Barth 6 Google Inc. 7 November 13, 2011 9 TLS Origin-Bound Certificates 10 draft-balfanz-tls-obc-01 12 Abstract 14 This document specifies a Transport Layer Security (TLS) extension 15 and associated semantics that allow clients and servers to negotiate 16 the use of origin-bound, self-signed certificates for TLS client 17 authentication. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 16, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 61 1.2. Extension Dependencies . . . . . . . . . . . . . . . . . . 3 62 2. Origin-Bound Certificates . . . . . . . . . . . . . . . . . . . 3 63 2.1. Certificate Creation . . . . . . . . . . . . . . . . . . . 4 64 2.1.1. Origin-Bound Certificate Extension . . . . . . . . . . 4 65 2.2. Certificate and Key Rotation . . . . . . . . . . . . . . . 5 66 3. Changes to The Handshake Message Contents . . . . . . . . . . . 5 67 3.1. Extension Definition . . . . . . . . . . . . . . . . . . . 5 68 3.2. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 71 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 6 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Third-Party Tracking . . . . . . . . . . . . . . . . . . . 7 74 4.2. Server Tracking . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3. Cookie Hardening . . . . . . . . . . . . . . . . . . . . . 7 76 4.4. Key Lengths . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 Transport Layer Security (TLS [RFC5246]) allows clients to 83 authenticate themselves using Client Certificates. In practice, 84 clients tend to ask for user consent before using Client 85 Certificates. This is to allay privacy concerns about user- 86 identifying information in the Client Certificate, and also to let 87 the user choose among possibly many certificates that can be used by 88 the client for the TLS session. 90 The user experience of obtaining this consent, along with that of 91 obtaining the certificates in the first place, has traditionally 92 presented a hurdle to user adoption. Additionally, operational 93 constraints on the server side can make it difficult for service 94 providers to switch from a cookie-based authentication scheme to 95 certificate-based TLS client authentication. 97 The TLS Origin-Bound Certificates extension (TLS-OBC) is a TLS 98 extension [RFC6066] that allows clients to use certificate-based 99 client authentication without having to obtain user consent before 100 using certificates. A client creates at most one (self-signed) 101 certificate of any given type (e.g., rsa_sign or ecdsa_sign) per web 102 origin [WebOrigin], and does not include user-identifying information 103 into such origin-bound certificates, thus making user consent and 104 user-assisted certificate selection unnecessary. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 1.2. Extension Dependencies 114 The client SHOULD use TLS-OBC during a TLS session only if it also 115 uses the TLS Encrypted Client Certificates [EncryptedClientCerts] 116 extension during that TLS session. 118 2. Origin-Bound Certificates 120 An origin-bound certificate is a self-issued certificate that the 121 client uses for TLS client authentication for a particular web origin 122 [WebOrigin]. Origin-bound certificates MUST be self-signed, i.e., a 123 private key corresponding to the certified public key MUST be used to 124 sign the certificate. 126 Clients MUST NOT re-use the same origin-bound certificate for more 127 than one web origin. 129 2.1. Certificate Creation 131 Clients create origin-bound certificates when asked to perform TLS 132 client authentication after negotiating the "ob_cert" extension with 133 a server from that origin (see Section 3.5), and they do not already 134 have a valid origin-bound certificate for that origin available for 135 use. 137 Clients SHOULD NOT re-use the same key pair for more than one origin- 138 bound certificate. To do so would violate the privacy properties 139 required by origin-bound certificates. 141 When creating an origin-bound certificate, it is RECOMMENDED that 142 clients use the PrintableString representation of "anonymous.invalid" 143 as the common name component of the Distinguished Name of both the 144 certificate's Issuer and Subject, with no other name components 145 present. 147 It is RECOMMENDED that clients pick a lifetime for the new 148 certificate between one month and one year (perhaps depending on an 149 assessment of how well the private key is protected on the host 150 platform). The client SHALL use the notBefore and notAfter fields in 151 the new certificate to record the lifetime of the new certificate. 153 2.1.1. Origin-Bound Certificate Extension 155 Origin-bound certificates MUST be X.509 v3 certificates, and MUST 156 include the origin-bound certificate extension (OID 157 1.3.6.1.4.1.11129.2.1.6), shown below. This extension MUST be marked 158 critical. 160 The data of the extension, "OriginBoundCertificate", will be the 161 ASCII Serialization of the certificate's web origin [WebOrigin] as an 162 IA5String. 164 id-ce-originBoundCertificate OBJECT IDENTIFIER ::= 165 { enterprises Google 2 1 6 } 167 OriginBoundCertificate ::= 168 IA5String 170 Figure 1 172 The server MAY reject the origin-bound certificate if it determines 173 that the web origin included in the "OriginBoundCertificate" 174 extension does not match the server's origin (for example, if it 175 doesn't match the host name specified in the Server Name Indication 176 TLS extension). It is, however, RECOMMENDED that the server merely 177 report the value of the web origin to the upper layers in the 178 protocol stack, and leave it up to those layers to make use of the 179 web origin value (e.g., to assist developers in debugging the 180 feature). 182 2.2. Certificate and Key Rotation 184 After a client has created an origin-bound certificate for a certain 185 web origin, the client SHOULD re-use the certificate for a period of 186 time, and then discard it. 188 The client MUST discard existing origin-bound certificate at or 189 before the notAfter time indicated in each certificate. 191 The client MAY opt to discard an existing origin-bound certificate at 192 any time of its choosing prior to the notAfter time indicated in the 193 certificate. In particular, the client may delete an existing 194 origin-bound certificate in response to a user request to clear 195 privacy-sensitive state from their user-agent, ensuring that a fresh 196 certificate will be generated the next time a user visits that 197 origin. 199 The client SHOULD use a new key pair when it generates a new origin- 200 bound certificate. 202 3. Changes to The Handshake Message Contents 204 3.1. Extension Definition 206 This document defines a new TLS extension, "ob_cert" (with tentative 207 extension type 13175, or 0x3377), which indicates that client and 208 server agree to allow the client to use an origin-bound certificate 209 to authenticate itself to the server. 211 To indicate support for origin-bound certificates, the client 212 includes an extension of type "ob_cert" in the Extended Client Hello 213 message. To indicate that a subsequent CertificateRequest message 214 requests an origin-bound certificate, the server includes the same 215 extension in its Extended Server Hello message. 217 The "ob_cert" TLS extension will be assigned a value from the TLS 218 ExtensionType registry, and will contain zero length 219 "extension_data". For testing, we will use the extension type value 220 of 0x3377. For this type value, the entire encoding of the extension 221 will be 33 77 00 00. 223 3.2. Client Hello 225 A client wishing to indicate support for origin-bound client 226 certificates MUST include the "ob_cert" in the extended Client Hello 227 message to a server from a particular web origin. 229 3.3. Server Hello 231 A server that receives a Client Hello message containing the 232 "ob_cert" extension MAY choose to include the same extension in the 233 extended Server Hello message. If it does, the client and server are 234 considered to have negotiated origin-bound client certificates for 235 the session. 237 3.4. Certificate Request 239 A server MAY choose to send a Certificate Request message to the 240 client. If the session uses origin-bound client certificates, the 241 server SHOULD use an empty "certificate_authorities" list. 243 A client that receives a Certificate Request during a session for 244 which origin-bound client certificates were negotiated MUST ignore 245 the "certificate_authorities" list. 247 3.5. Client Certificate 249 TLS [RFC5246] requires that a client that receives a Certificate 250 Request message must send a Client Certificate message in response 251 (which may or may not include client certificates). If client and 252 server negotiated origin-bound client certificates, then the client 253 SHOULD include an origin-bound certificate in the Client Certificate 254 message. 256 If a client includes an origin-bound certificate in the Client 257 Certificate message during a session for which origin-bound client 258 certificates were negotiated, the included certificate MUST 260 o be an origin-bound certificate for the web origin of the server, 261 and 263 o match a certificate type requested by the server in the 264 Certificate Request message. 266 If a client doesn't possess a certificate meeting the above 267 requirements, it SHOULD self-issue a certificate of a type requested 268 by the server in the Certificate Request message and include the 269 newly-generated certificate in the Client Certificate message. Only 270 if the client is not capable of providing a certificate of the 271 requested type SHOULD it include an empty "certificate_list" in the 272 Client Certificate message. 274 A server verifying a Client Certificate message in a handshake that 275 negotiated origin-bound client certificates MUST verify that the 276 certificate is self-signed, rather than being signed by any 277 particular CA. The server MUST verify that the public key in the 278 certificate corresponds to the key used to authenticate the client in 279 the handshake. The server SHOULD ignore the Issuer and Subject in 280 the presented certificate. The server MUST ignore the notBefore and 281 notAfter fields in the certificate. 283 Finally, the server MUST verify that the certificate contains the 284 origin-bound extension, and MAY verify that the origin identified in 285 that certificate matches the server (see Section 2.1.1). 287 4. Security Considerations 289 4.1. Third-Party Tracking 291 A third party might be able to track a client across multiple 292 sessions by observing the use of the same origin-bound certificate. 293 To alleviate this concern, clients SHOULD also implement the 294 Encrypted Client Certificates Extension [EncryptedClientCerts], and 295 use it concurrently with TLS-OBC. The Encrypted Client Certificates 296 Extension [EncryptedClientCerts] ensures that the origin-bound 297 certificate is sent after TLS established secrecy on the channel 298 between client and server. 300 4.2. Server Tracking 302 A client can prevent server tacking by deleting the origin-bound 303 certificate for the server's Web origin. This could happen, for 304 example, when the user elects to remove all cookies for that origin. 306 4.3. Cookie Hardening 308 One way TLS-OBC can be used to strengthen cookie-based authentication 309 is by "binding" cookies to an origin-bound certificate. The server, 310 when issuing a cookie for an HTTP session, would associate the 311 client's origin-bound certificate with the session (either by 312 encoding information about the certificate unforgeably in the cookie, 313 or by associating the certificate with the cookie's session through 314 some other means). That way, if and when a cookie gets stolen from a 315 client, it cannot be used over a TLS connection initiated by a 316 different client - the cookie thief would also have to steal the 317 private key associated with the client's origin-bound certificate, a 318 task considerably harder especially when we assume the existence of a 319 Trusted Platform Module or other Secure Element that can store the 320 origin-bound-certificate's private key. 322 4.4. Key Lengths 324 If the client uses RSA key pairs, the key length should be at least 325 1024 bits. For longer-lived origin-bound certificates, the key 326 length should be 2048 bits. 328 If the client uses ECDSA key pairs, the key length should be at least 329 160 bits. 331 5. References 333 [EncryptedClientCerts] 334 Langley, A., "TLS Encrypted Client Certificates", . 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 341 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 343 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 344 Extension Definitions", RFC 6066, January 2011. 346 [WebOrigin] 347 Barth, A., "The Web Origin Concept", 348 . 350 Authors' Addresses 352 Dirk Balfanz (editor) 353 Google Inc. 354 1600 Ampitheatre Parkway 355 Mountain View, CA 356 USA 358 Phone: 359 Email: balfanz@google.com 360 D K Smetters 361 Google Inc. 363 Mayank Upadhyay 364 Google Inc. 366 Adam Barth 367 Google Inc.