idnits 2.17.1 draft-thomson-tls-care-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 8, 2014) is 3701 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track March 8, 2014 5 Expires: September 9, 2014 7 Client Authentication Request Extension for (D)TLS 8 draft-thomson-tls-care-00 10 Abstract 12 This document describes an extension to Transport Layer Security 13 (TLS) and Datagram TLS (DTLS) that allows a client to indicate that 14 it wants to provide a client certificate. 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 9, 2014. 33 Copyright Notice 35 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 52 2. Client Authentication and TLS Renegotiation . . . . . . . . . 2 53 3. Client Authentication Request Extension . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 In Transport Layer Security (TLS) [RFC5246] and Datagram TLS (DTLS) 63 [RFC5764] the server decides whether or not to request a certificate 64 from clients. 66 In TLS versions 1.2 and earlier, the Certificate message from a 67 client is not encrypted and is therefore not confidential. TLS 68 renegotiation is frequently used to provide confidentiality for 69 client credentials, since renegotiation handshakes are encrypted with 70 the TLS session keys. 72 A client that is aware of a need to authenticate can initial 73 renegotiation, but is unable to induce a CertificateRequest from the 74 server. The decision to request client authentication is one that 75 can only be made by a server. 77 This document defines a client authentication request extension that 78 can be used by a client to request that the server send a 79 CertificateRequest in its handshake. 81 1.1. Conventions and Terminology 83 At times, this document falls back on shorthands for establishing 84 interoperability requirements on implementations: the capitalized 85 words "MUST", "SHOULD" and "MAY". These terms are defined in 86 [RFC2119]. 88 2. Client Authentication and TLS Renegotiation 90 Renegotiation has the potential to create confusion at higher layers 91 about the security properties that apply to the byte stream. This is 92 especially difficult when there are protocol constructs that span the 93 ChangeCipherSpec messages that represent a switch between states. 95 For that reason, a client can initiate a new connection when it 96 detects a need to authenticate, initiating renegotiation to establish 97 authentication credentials immediately after the initial handshake. 99 Since the server only conditionally requests client authentication 100 and it has no context with which to decide that authentication is 101 needed, the client needs to provide some indication that it might 102 need to be authentication. The second, renegotiation handshake can 103 contain the client authentication request extension (Section 3) to 104 provide this indication. As long as no application data is sent on 105 the connection prior to completing renegotiation and sending the 106 corresponding ChangeCipherSpec, there is no possibility for confusion 107 over the security properties of application content. 109 This behavior could need to be triggered by a higher level protocol. 110 This document does not define how that happens. 112 3. Client Authentication Request Extension 114 A new extension type ("client_authentication_request(TBD)") is 115 defined. If a client includes this extension in its ClientHello to 116 indicate that it wishes the server to issue a CertificateRequest. 118 enum { 119 client_authentication_request(TBD), (65535) 120 } ExtensionType; 122 The "extension_data" field of this extension MUST be empty. 124 A server that supports client authentication based on certificates 125 can use the presence of this extension to decide to include a 126 CertificateRequest. The server MAY choose to ignore this extension. 128 A server MUST NOT send this extension to a client. 130 4. Security Considerations 132 This document is entirely about security. 134 5. IANA Considerations 136 IANA has allocated a TLS extension code point of (TBD) for this 137 extension. 139 6. Acknowledgements 141 Eric Rescorla helped identify the problem and formulate this 142 mechanism. 144 7. Normative References 146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 147 Requirement Levels", BCP 14, RFC 2119, March 1997. 149 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 150 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 152 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 153 Security (DTLS) Extension to Establish Keys for the Secure 154 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 156 Author's Address 158 Martin Thomson 159 Mozilla 160 Suite 300 161 650 Castro Street 162 Mountain View, CA 94041 163 US 165 Email: martin.thomson@gmail.com