idnits 2.17.1 draft-wouters-tls-oob-pubkey-01.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 date (October 31, 2011) is 4561 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: 'TBD' is mentioned on line 233, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 4949 (ref. 'SECTERMS') == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-07 == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-12 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF P. Wouters 3 Internet-Draft Xelerance 4 Intended status: Standards Track J. Gilmore 5 Expires: May 3, 2012 6 S. Weiler 7 SPARTA, Inc. 8 T. Kivinen 9 AuthenTec 10 H. Tschofenig 11 Nokia Siemens Networks 12 October 31, 2011 14 TLS out-of-band public key validation 15 draft-wouters-tls-oob-pubkey-01 17 Abstract 19 This document specifies a new TLS certificate type for exchanging raw 20 public keys or their fingerprints in Transport Layer Security (TLS) 21 and Datagram Transport Layer Security (DTLS) for use with out-of-band 22 authentication. Currently, TLS authentication can only occur via 23 PKIX or OpenPGP certificates. By specifying a minimum resource for 24 raw public key exchange, implementations can use alternative 25 authentication methods. 27 One such method is using DANE Resource Records secured by DNSSEC, 28 Another use case is to provide authentication functionality when used 29 with devices in a constrained environment that use whitelists and 30 blacklists, as is the case with sensors and other embedded devices 31 that are constrained by memory, computational, and communication 32 limitations where the usage of PKIX is not feasible. 34 The new certificate type specified can also be used to reduce the 35 latency of a TLS client that is already in possession of a validated 36 public key of the TLS server before it starts a (non-resumed) TLS 37 handshake. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 3, 2012. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 76 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Changes to the Handshake Message Contents . . . . . . . . . . 5 78 2.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6 79 2.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 7 80 2.3. Certificate Request . . . . . . . . . . . . . . . . . . . 8 81 2.4. Other Handshake Messages . . . . . . . . . . . . . . . . . 8 82 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 1.1. Motivation 95 Traditionally, TLS server public keys are obtained in PKIX containers 96 in-band using the TLS connection and validated using trust anchors 97 based on a [PKIX] certification authority (CA). This method can add 98 a complicated trust relationship that is difficult to validate. 99 Examples of such complexity can be seen in [Defeating-SSL]. 101 Alternative methods are available that allow a TLS client to obtain 102 the TLS server public key: 104 o The TLS server public key is obtained from a DNSSEC secured RRset 105 using [DANE] 107 o The TLS server public key is obtained from a [PKIX] certificate 108 chain from an [LDAP] server 110 o The TLS server public key is provisioned by the operating system 111 and updated via software updates 113 o A TLS client has connected to the TLS server before and has cached 114 the TLS server certificate chain or TLS server public key for re- 115 use 117 [RFC5246] does not provide a mechanism for a TLS client to tell the 118 TLS server it is already in possession of the authenticated public 119 key. Therefore, a TLS server must always send a list of trusted CA 120 keys and its EE certificate containing its public key, even when the 121 TLS client does not require or desire that data for authentication. 123 [RFC6066] allows suppression of the certificate trust anchor chain, 124 but not suppression of the PKIX EE certificate container. These 125 certificate chains are large opaque blocks of data containing much 126 more than the public key of the TLS server. Since the TLS client 127 might only be able to validate the PKIX SubjectPublicKeyInfo via an 128 out-of-band method such as [DANE], it has to ignore any additional 129 information received that was sent by the server that it could not 130 validate. Furthermore, information that comes in via these 131 certificate chains could contain contradicting or additional 132 information that the TLS client cannot validate or trust, such as an 133 expiry date that conflicts with information obtained from DNS or 134 LDAP. This document specifies a method to suppress sending this 135 additional information. 137 Some small embedded devices use the UDP based [CoAP], a specialized 138 constrained networks and nodes for machine-to-machine applications. 140 These devices interact with a Web server to upload data such as 141 temperature sensor readings at a regular intervals. [CoAP] can 142 utilize DTLS for its communication security. As part of the 143 provisioning procedure, the embeded device is configured with the 144 address and public key of a dedicated CoAP server to upload sensor 145 data. Receiving [PKIX] information from a webserver would be an 146 unneccesarry burden on a sensor networking deployment environment 147 that requires pre-configured client-server public keys. These 148 devices often also lack a real-time clock to perform any PKIX epixry 149 checks. 151 1.2. Applicability 153 The Transport Layer Security (TLS) Protocol Version 1.2 is specified 154 in [RFC5246] and provides a framework for extensions to TLS as well 155 as considerations for designing such extensions. [RFC6066] defines 156 several new TLS extensions. This document extends the specifications 157 of those RFCs with one new TLS Certificate Type to facilitate 158 suppressing unneeded [PKIX] information from being sent during the 159 TLS handshake when this information is not required to authenticate 160 the TLS server. 162 1.3. Terminology 164 Most security-related terms in this document are to be understood in 165 the sense defined in [SECTERMS]; such terms include, but are not 166 limited to, "attack", "authentication", "authorization", 167 "certification authority", "certification path", "certificate", 168 "credential", "identity", "self-signed certificate", "trust", "trust 169 anchor", "trust chain", "validate", and "verify". 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 2. Changes to the Handshake Message Contents 177 This section describes the changes to the TLS handshake message 178 contents when raw public keys are to be used for authentication. 179 Figure 1 illustrates the exchange of messages as described in the 180 sub-sections below. The new "RawPublicKey" value in the cert_type 181 extension indicates the ability and desire to exchange raw public 182 keys, which are then exchanged as part of the certificate payloads. 184 client_hello, 185 cert_type="RawPublicKey" -> 187 <- server_hello, 188 cert_type="RawPublicKey", 189 certificate, 190 server_key_exchange, 191 certificate_request, 192 server_hello_done 194 certificate, 195 client_key_exchange, 196 certificate_verify, 197 change_cipher_spec, 198 finished -> 200 <- change_cipher_spec, 201 finished 203 Application Data <-------> Application Data 205 Figure 1: Example Message Flow 207 2.1. Client Hello 209 In order to indicate the support of out-of-bound raw public keys, 210 clients MUST include an extension of type "cert_type" to the extended 211 client hello message. The "cert_type" TLS extension, which is 212 defined in [RFC6091], is assigned the value of 9 from the TLS 213 ExtensionType registry. This value is used as the extension number 214 for the extensions in both the client hello message and the server 215 hello message. The hello extension mechanism is described in 216 [RFC5246]. 218 The "cert_type" TLS extension carries a list of supported certificate 219 types the client can use, sorted by client preference. This 220 extension MUST be omitted if the client only supports X.509 221 certificates. The "extension_data" field of this extension contains 222 a CertificateTypeExtension structure. Note that the 223 CertificateTypeExtension structure is being used both by the client 224 and the server, even though the structure is only specified once in 225 this document. 227 The [RFC6091] defined CertificateTypeExtension is extended as 228 follows: 230 enum { client, server } ClientOrServerExtension; 232 enum { X.509(0), OpenPGP(1), 233 RawPublicKey([TBD]), RawPublicKeySHA256([TBD]), 234 (255) } CertificateType; 236 struct { 237 select(ClientOrServerExtension) 238 case client: 239 CertificateType certificate_types<1..2^8-1>; 240 case server: 241 CertificateType certificate_type; 242 } 243 } CertificateTypeExtension; 245 No new cipher suites are required to use raw public keys or 246 fingerprints of raw public keys. All existing cipher suites that 247 support a key exchange method compatible with the defined extension 248 can be used. 250 2.2. Server Hello 252 If the server receives a client hello that contains the "cert_type" 253 extension and chooses a cipher suite then two outcomes are possible. 254 The server MUST either select a certificate type from the 255 certificate_types field in the extended client hello or terminate the 256 session with a fatal alert of type "unsupported_certificate". 258 The certificate type selected by the server is encoded in a 259 CertificateTypeExtension structure, which is included in the extended 260 server hello message using an extension of type "cert_type". Servers 261 that only support X.509 certificates MAY omit including the 262 "cert_type" extension in the extended server hello. 264 If the negotiated certificate type is RawPublicKey the TLS server 265 MUST send a CertificateTypeExtension structure with a [PKIX] 266 certificate containing ONLY the SubjectPublicKeyInfo. The public key 267 MUST match the selected key exchange algorithm. 269 If the negotiated certificate type is RawPublicKeySHA256 the TLS 270 server MUST send a CertificateTypeExtension structure with a [PKIX] 271 certificate containing ONLY the SHA256 of the SubjectPublicKeyInfo. 272 The public key used to create the hash MUST match the selected key 273 exchange algorithm. 275 2.3. Certificate Request 277 The semantics of this message remain the same as in the TLS 278 specification. However, if this message is sent, and the negotiated 279 certificate type is RawPublicKey or RawPublicKeySHA256, the 280 "certificate_authorities" list MUST be empty. 282 2.4. Other Handshake Messages 284 All the other handshake messages are identical to the TLS 285 specification. 287 3. Security Considerations 289 The TLS cert_type extension defined here lets a TLS client attempt to 290 supress the sending of server certificate as well as the 291 certification chain for that certificate. 293 A client using this cert_type needs to be confident in the 294 authenticity of the public key it is using. Since those public keys 295 were obtained out-of-band extension), the authentication must also be 296 out-of-band. 298 Depending on exactly how the public keys were obtained, it may be 299 appropriate to use authentication mechanisms tied to the public key 300 transport. For example, if public keys were obtained using [DANE] it 301 is appropriate to use DNSSEC to authenticate the public keys. 303 4. IANA Considerations 305 We request that IANA assign a TLS cert_type value for RawPublicKey 306 and RawPublicKeySHA256 308 5. Contributors 310 The following individuals made important contributions to this 311 document: Paul Hoffman. 313 6. Acknowledgements 315 This document is based on material from RFC 6066 for which the author 316 is Donald Eastlake 3rd. Contributions to that document also include 317 Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian 318 Farrel. 320 The second version of this document was made after feedback from the 321 TLS working group at IETF-81 323 7. References 325 7.1. Normative References 327 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 328 Housley, R., and W. Polk, "Internet X.509 Public Key 329 Infrastructure Certificate and Certificate Revocation List 330 (CRL) Profile", RFC 5280, May 2008. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 336 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 338 [SECTERMS] 339 Shirey, R., "Internet Security Glossary, Version 2", 340 RFC 4949, August 2007. 342 7.2. Informative References 344 [CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 345 "Constrained Application Protocol", 346 draft-ietf-core-coap-07 (work in progress), July 2011. 348 [DANE] Hoffman, P. and J. Schlyter, "Using Secure DNS to 349 Associate Certificates with Domain Names For TLS", 350 draft-ietf-dane-protocol-12 (work in progress), 351 September 2011. 353 [Defeating-SSL] 354 Marlinspike, M., "New Tricks for Defeating SSL in 355 Practice", February 2009, . 359 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 360 (LDAP): The Protocol", RFC 4511, June 2006. 362 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 363 Extension Definitions", RFC 6066, January 2011. 365 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 366 for Transport Layer Security (TLS) Authentication", 367 RFC 6091, February 2011. 369 Authors' Addresses 371 Paul Wouters 372 Xelerance 373 4130 Ramsayville Road 374 Ottawa, On K1G 3N4 375 Canada 377 Phone: +1-647-722-5653 378 Email: paul@xelerance.com 379 URI: https://www.xelerance.com/ 381 John Gilmore 382 PO Box 170608 383 San Francisco, California 94117 384 USA 386 Phone: +1 415 221 6524 387 Email: gnu@toad.com 388 URI: https://www.toad.com/ 390 Samuel Weiler 391 SPARTA, Inc. 392 7110 Samuel Morse Drive 393 Columbia, Maryland 21046 394 US 396 Email: weiler@tislabs.com 398 Tero Kivinen 399 AuthenTec 400 Eerikinkatu 28 401 HELSINKI FI-00180 402 FI 404 Email: kivinen@iki.fi 405 Hannes Tschofenig 406 Nokia Siemens Networks 407 Linnoitustie 6 408 Espoo 02600 409 Finland 411 Phone: +358 (50) 4871445 412 Email: Hannes.Tschofenig@gmx.net 413 URI: http://www.tschofenig.priv.at