idnits 2.17.1 draft-thomson-httpbis-catch-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 (March 9, 2014) is 3700 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: 'RFC2617' is defined on line 161, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 166, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-10 Summary: 2 errors (**), 0 flaws (~~), 5 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 March 9, 2014 5 Expires: September 10, 2014 7 Client Authentication over TLS Connection Header 8 draft-thomson-httpbis-catch-00 10 Abstract 12 This document defines an HTTP header field that can be added to a 13 response to indicate to a client that a response will only be 14 provided over a TLS connection, and only if the client has provided a 15 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 September 10, 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 TLS. Some uses of client authentication 66 rely on Transport Layer Security (TLS) [RFC5246] renegotiation, 67 triggering renegotiation in response to a request for a particular 68 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 type of 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 kind of authentication scheme (auth-scheme 90 [I-D.ietf-httpbis-p7-auth]) for the "WWW-Authenticate" and "Proxy- 91 Authenticate" header fields is defined with the name 92 "ClientCertificate". 94 A challenge with this auth-scheme does not define the use of any 95 parameters other than "realm". Other parameters MAY be used to 96 provide a client with information it can use to select an appropriate 97 certificate. Unknown parameters MUST be ignored. 99 This challenge cannot be satisfied by constructing an Authorization 100 header field [I-D.ietf-httpbis-p7-auth], it can only be satisfied by 101 making the request on a TLS connection where an appropriate 102 certificate has been provided by the client. 104 A client can use this information as a trigger to open a new 105 connection and to use client authentication on that connection. The 106 client can use the mechanism in [I-D.thomson-tls-care] to prompt the 107 server to request a client certificate, to avoid the problem where 108 the server doesn't know to make this request. 110 3. Security Considerations 112 Clients that support this authentication scheme will create a new 113 connection each time that they see a challenge. This could be 114 exploited in order to generate additional load in terms of 115 connections on both server and client. 117 Using new connections for client authentication has additional 118 processing costs to the client in proving access to the private keys 119 associated with the client certificate; and to the server in proving 120 access to the private keys associated with their certificate twice in 121 the case that the client opts for confidentiality protection on the 122 client certificate. 124 HTTP/2 [I-D.ietf-httpbis-http2] allows clients to use the same 125 connection for multiple origins [RFC6454]. Certificate-based client 126 authentication as defined by this specification is bound to a single 127 origin. This could create issues whereby the security properties of 128 a connection could become confused. Clients MUST ensure that a 129 client-authenticated connection is only used for the origin for which 130 it was created. 132 4. IANA Considerations 134 IANA will [has] create[d] an entry in the HTTP Authentication Scheme 135 Registry with the following information: 137 ClientCertificate 139 RFCXXXX (this document) 141 This scheme does not rely on the Authorization header field. 143 5. Acknowledgements 145 Eric Rescorla helped identify the problem and formulate this 146 mechanism. Julian Reschke hasn't provided any contribution yet, but 147 he will. 149 6. References 151 6.1. Normative References 153 [I-D.ietf-httpbis-p7-auth] 154 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 155 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-26 156 (work in progress), February 2014. 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, March 1997. 161 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 162 Leach, P., Luotonen, A., and L. Stewart, "HTTP 163 Authentication: Basic and Digest Access Authentication", 164 RFC 2617, June 1999. 166 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 167 Specifications: ABNF", STD 68, RFC 5234, January 2008. 169 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 170 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 172 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 173 2011. 175 6.2. Informational References 177 [I-D.ietf-httpbis-http2] 178 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 179 Protocol version 2", draft-ietf-httpbis-http2-10 (work in 180 progress), February 2014. 182 [I-D.thomson-tls-care] 183 Thomson, M., draft-thomson-tls-care-00 (work in progress), 184 March 2014. 186 Author's Address 187 Martin Thomson 188 Mozilla 189 Suite 300 190 650 Castro Street 191 Mountain View, CA 94041 192 US 194 Email: martin.thomson@gmail.com