idnits 2.17.1 draft-thomson-httpbis-cant-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 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 (May 8, 2014) is 3641 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) == Unused Reference: 'RFC6454' is defined on line 167, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPBIS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track May 8, 2014 5 Expires: November 9, 2014 7 Client Authentication over New TLS Connection 8 draft-thomson-httpbis-cant-00 10 Abstract 12 This document defines an HTTP authentication scheme that can be added 13 to an error response to indicate to a client that a successful 14 response will only be provided over a new TLS connection, and only if 15 the client has provided a certificate on that connection. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 9, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 53 2. Client Certificate Challenge . . . . . . . . . . . . . . . . 2 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 6.2. Informational References . . . . . . . . . . . . . . . . 4 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 Client authentication in HTTP sometimes relies on certificate-based 65 authentication of clients in Transport Layer Security (TLS) 66 [RFC5246]. Some uses of client authentication rely on TLS 67 renegotiation, triggering renegotiation in response to a request for 68 a particular resource. 70 HTTP/2 [I-D.ietf-httpbis-http2] forbids the use of renegotiation, 71 except for at the very beginning of a connection. This makes 72 addressing some client authentication use cases difficult. 74 This document defines a new authentication scheme, 75 "ClientCertificate", for use in HTTP authentication challenges 76 [I-D.ietf-httpbis-p7-auth]. In combination with the 401 77 (Unauthorized) status code, this indicates that the resource requires 78 client authentication at the TLS layer in order to access it. 80 1.1. Conventions and Terminology 82 At times, this document falls back on shorthands for establishing 83 interoperability requirements on implementations: the capitalized 84 words "MUST", "SHOULD" and "MAY". These terms are defined in 85 [RFC2119]. 87 2. Client Certificate Challenge 89 A new authentication scheme ([I-D.ietf-httpbis-p7-auth]) for the 90 "WWW-Authenticate" and "Proxy-Authenticate" header fields is defined 91 with the name "ClientCertificate". 93 A challenge with this authentication scheme does not define any 94 parameters except "realm". The "realm" can be used to select an 95 appropriate certificate, or if a certificate is already in use, to 96 indicate the need for a different certificate. Other challenge 97 parameters MAY be used to provide a client with information it can 98 use to select an appropriate certificate. Unknown parameters MUST be 99 ignored. 101 This challenge cannot be satisfied by constructing an Authorization 102 header field [I-D.ietf-httpbis-p7-auth], it can only be satisfied by 103 making the request on a TLS connection where an appropriate 104 certificate has been provided by the client. 106 To effectively use this authentication scheme, a new connection is 107 needed for every protection space used by a given origin server. A 108 client can use the "ClientCertificate" challenge as a trigger to open 109 a new connection and to use client authentication on that connection. 110 The client can use the mechanism in [I-D.thomson-tls-care] to prompt 111 the server to request a client certificate, to avoid the problem 112 where the server doesn't know to make this request. 114 3. Security Considerations 116 Clients that support this authentication scheme will create a new 117 connection each time that they see a challenge. This could be 118 exploited in order to generate additional load in terms of 119 connections on both server and client. 121 Using new connections for client authentication has additional 122 processing costs to the client in proving access to the private keys 123 associated with the client certificate; and to the server in proving 124 access to the private keys associated with their certificate twice in 125 the case that the client opts for confidentiality protection on the 126 client certificate. 128 HTTP/2 [I-D.ietf-httpbis-http2] allows clients to use the same 129 connection for multiple canonical root URIs. Certificate-based 130 client authentication as defined by this specification is bound to a 131 single origin. This could create issues whereby the security 132 properties of a connection could become confused. Clients MUST 133 ensure that a client-authenticated connection is only used for the 134 origin for which it was created. 136 4. IANA Considerations 138 IANA is requested to create an entry in the HTTP Authentication 139 Scheme Registry with the following information: 141 ClientCertificate 143 This document 144 This scheme does not rely on the Authorization header field. 146 5. Acknowledgements 148 Eric Rescorla helped identify the problem and formulate this 149 mechanism. Julian Reschke and Michael Koeller provided excellent 150 feedback. 152 6. References 154 6.1. Normative References 156 [I-D.ietf-httpbis-p7-auth] 157 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 158 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-26 159 (work in progress), February 2014. 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 165 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 167 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 168 2011. 170 6.2. Informational References 172 [I-D.ietf-httpbis-http2] 173 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 174 Protocol version 2", draft-ietf-httpbis-http2-12 (work in 175 progress), April 2014. 177 [I-D.thomson-tls-care] 178 Thomson, M., draft-thomson-tls-care-00 (work in progress), 179 March 2014. 181 Author's Address 183 Martin Thomson 184 Mozilla 185 Suite 300 186 650 Castro Street 187 Mountain View, CA 94041 188 US 190 Email: martin.thomson@gmail.com