idnits 2.17.1 draft-ietf-tls-oob-pubkey-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 date (January 7, 2012) is 4486 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 232, 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 No Hats Corporation 4 Intended status: Standards Track J. Gilmore 5 Expires: July 10, 2012 6 S. Weiler 7 SPARTA, Inc. 8 T. Kivinen 9 AuthenTec 10 H. Tschofenig 11 Nokia Siemens Networks 12 January 7, 2012 14 TLS Out-of-Band Public Key Validation 15 draft-ietf-tls-oob-pubkey-00.txt 17 Abstract 19 This document specifies a new TLS certificate type for exchanging raw 20 public keys in Transport Layer Security (TLS) and Datagram Transport 21 Layer Security (DTLS) for use with out-of-band authentication. 22 Currently, TLS authentication can only occur via PKIX or OpenPGP 23 certificates. By specifying a minimum resource for raw public key 24 exchange, implementations can use alternative authentication methods. 26 One such method is using DANE Resource Records secured by DNSSEC, 27 Another use case is to provide authentication functionality when used 28 with devices in a constrained environment that use whitelists and 29 blacklists, as is the case with sensors and other embedded devices 30 that are constrained by memory, computational, and communication 31 limitations where the usage of PKIX is not feasible. 33 The new certificate type specified can also be used to reduce the 34 latency of a TLS client that is already in possession of a validated 35 public key of the TLS server before it starts a (non-resumed) TLS 36 handshake. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on July 10, 2012. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 75 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Changes to the Handshake Message Contents . . . . . . . . . . 5 77 2.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.3. Certificate Request . . . . . . . . . . . . . . . . . . . 7 80 2.4. Other Handshake Messages . . . . . . . . . . . . . . . . . 8 81 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 1.1. Motivation 94 Traditionally, TLS server public keys are obtained in PKIX containers 95 in-band using the TLS connection and validated using trust anchors 96 based on a [PKIX] certification authority (CA). This method can add 97 a complicated trust relationship that is difficult to validate. 98 Examples of such complexity can be seen in [Defeating-SSL]. 100 Alternative methods are available that allow a TLS client to obtain 101 the TLS server public key: 103 o The TLS server public key is obtained from a DNSSEC secured RRset 104 using [DANE] 106 o The TLS server public key is obtained from a [PKIX] certificate 107 chain from an [LDAP] server 109 o The TLS server public key is provisioned by the operating system 110 and updated via software updates 112 o A TLS client has connected to the TLS server before and has cached 113 the TLS server certificate chain or TLS server public key for re- 114 use 116 [RFC5246] does not provide a mechanism for a TLS client to tell the 117 TLS server it is already in possession of the authenticated public 118 key. Therefore, a TLS server must always send a list of trusted CA 119 keys and its EE certificate containing its public key, even when the 120 TLS client does not require or desire that data for authentication. 122 [RFC6066] allows suppression of the certificate trust anchor chain, 123 but not suppression of the PKIX EE certificate container. These 124 certificate chains are large opaque blocks of data containing much 125 more than the public key of the TLS server. Since the TLS client 126 might only be able to validate the PKIX SubjectPublicKeyInfo via an 127 out-of-band method such as [DANE], it has to ignore any additional 128 information received that was sent by the server that it could not 129 validate. Furthermore, information that comes in via these 130 certificate chains could contain contradicting or additional 131 information that the TLS client cannot validate or trust, such as an 132 expiry date that conflicts with information obtained from DNS or 133 LDAP. This document specifies a method to suppress sending this 134 additional information. 136 Some small embedded devices use the UDP based [CoAP], a specialized 137 constrained networks and nodes for machine-to-machine applications. 139 These devices interact with a Web server to upload data such as 140 temperature sensor readings at a regular intervals. Constrained 141 Application Protocol (CoAP) [CoAP] can utilize DTLS for its 142 communication security. As part of the provisioning procedure, the 143 embeded device is configured with the address and public key of a 144 dedicated CoAP server to upload sensor data. Receiving PKIX 145 information [PKIX] from a webserver would be an unneccesarry burden 146 on a sensor networking deployment environment that requires pre- 147 configured client-server public keys. These devices often also lack 148 a real-time clock to perform any PKIX epixry checks. 150 1.2. Applicability 152 The Transport Layer Security (TLS) Protocol Version 1.2 is specified 153 in [RFC5246] and provides a framework for extensions to TLS as well 154 as considerations for designing such extensions. [RFC6066] defines 155 several new TLS extensions. This document extends the specifications 156 of those RFCs with one new TLS Certificate Type to facilitate 157 suppressing unneeded [PKIX] information from being sent during the 158 TLS handshake when this information is not required to authenticate 159 the TLS server. 161 1.3. Terminology 163 Most security-related terms in this document are to be understood in 164 the sense defined in [SECTERMS]; such terms include, but are not 165 limited to, "attack", "authentication", "authorization", 166 "certification authority", "certification path", "certificate", 167 "credential", "identity", "self-signed certificate", "trust", "trust 168 anchor", "trust chain", "validate", and "verify". 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 2. Changes to the Handshake Message Contents 176 This section describes the changes to the TLS handshake message 177 contents when raw public keys are to be used for authentication. 178 Figure 1 illustrates the exchange of messages as described in the 179 sub-sections below. The new "RawPublicKey" value in the cert_type 180 extension indicates the ability and desire to exchange raw public 181 keys, which are then exchanged as part of the certificate payloads. 183 client_hello, 184 cert_type="RawPublicKey" -> 186 <- server_hello, 187 cert_type="RawPublicKey", 188 certificate, 189 server_key_exchange, 190 certificate_request, 191 server_hello_done 193 certificate, 194 client_key_exchange, 195 certificate_verify, 196 change_cipher_spec, 197 finished -> 199 <- change_cipher_spec, 200 finished 202 Application Data <-------> Application Data 204 Figure 1: Example Message Flow 206 2.1. Client Hello 208 In order to indicate the support of out-of-bound raw public keys, 209 clients MUST include an extension of type "cert_type" to the extended 210 client hello message. The "cert_type" TLS extension, which is 211 defined in [RFC6091], is assigned the value of 9 from the TLS 212 ExtensionType registry. This value is used as the extension number 213 for the extensions in both the client hello message and the server 214 hello message. The hello extension mechanism is described in 215 [RFC5246]. 217 The "cert_type" TLS extension carries a list of supported certificate 218 types the client can use, sorted by client preference. This 219 extension MUST be omitted if the client only supports X.509 220 certificates. The "extension_data" field of this extension contains 221 a CertificateTypeExtension structure. Note that the 222 CertificateTypeExtension structure is being used both by the client 223 and the server, even though the structure is only specified once in 224 this document. 226 The [RFC6091] defined CertificateTypeExtension is extended as 227 follows: 229 enum { client, server } ClientOrServerExtension; 231 enum { X.509(0), OpenPGP(1), 232 RawPublicKey([TBD]), 233 (255) } CertificateType; 235 struct { 236 select(ClientOrServerExtension) 237 case client: 238 CertificateType certificate_types<1..2^8-1>; 239 case server: 240 CertificateType certificate_type; 241 } 242 } CertificateTypeExtension; 244 No new cipher suites are required to use raw public keys. All 245 existing cipher suites that support a key exchange method compatible 246 with the defined extension can be used. 248 2.2. Server Hello 250 If the server receives a client hello that contains the "cert_type" 251 extension and chooses a cipher suite then two outcomes are possible. 252 The server MUST either select a certificate type from the 253 certificate_types field in the extended client hello or terminate the 254 session with a fatal alert of type "unsupported_certificate". 256 The certificate type selected by the server is encoded in a 257 CertificateTypeExtension structure, which is included in the extended 258 server hello message using an extension of type "cert_type". Servers 259 that only support X.509 certificates MAY omit including the 260 "cert_type" extension in the extended server hello. 262 If the negotiated certificate type is RawPublicKey the TLS server 263 MUST send a CertificateTypeExtension structure with a PKIX [PKIX] 264 certificate containing ONLY the SubjectPublicKeyInfo. The public key 265 MUST match the selected key exchange algorithm. 267 2.3. Certificate Request 269 The semantics of this message remain the same as in the TLS 270 specification. However, if this message is sent, and the negotiated 271 certificate type is RawPublicKey, the "certificate_authorities" list 272 MUST be empty. 274 2.4. Other Handshake Messages 276 All the other handshake messages are identical to the TLS 277 specification. 279 3. Security Considerations 281 The TLS cert_type extension defined here lets a TLS client attempt to 282 supress the sending of server certificate as well as the 283 certification chain for that certificate. 285 A client using this cert_type needs to be confident in the 286 authenticity of the public key it is using. Since those public keys 287 were obtained out-of-band extension), the authentication must also be 288 out-of-band. 290 Depending on exactly how the public keys were obtained, it may be 291 appropriate to use authentication mechanisms tied to the public key 292 transport. For example, if public keys were obtained using [DANE] it 293 is appropriate to use DNSSEC to authenticate the public keys. 295 4. IANA Considerations 297 We request that IANA assign a TLS cert_type value for RawPublicKey. 299 5. Contributors 301 The following individuals made important contributions to this 302 document: Paul Hoffman. 304 6. Acknowledgements 306 This document is based on material from RFC 6066 for which the author 307 is Donald Eastlake 3rd. Contributions to that document also include 308 Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian 309 Farrel. 311 The feedback from the TLS working group meeting at IETF#81 has 312 substantially shaped the document and we would like to thank the 313 meeting participants for their input. The support for hashes of 314 public keys has been removed after the discussions at the IETF#82 315 meeting and the feedback from Eric Rescorla. 317 7. References 319 7.1. Normative References 321 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 322 Housley, R., and W. Polk, "Internet X.509 Public Key 323 Infrastructure Certificate and Certificate Revocation List 324 (CRL) Profile", RFC 5280, May 2008. 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 330 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 332 [SECTERMS] 333 Shirey, R., "Internet Security Glossary, Version 2", 334 RFC 4949, August 2007. 336 7.2. Informative References 338 [CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 339 "Constrained Application Protocol", 340 draft-ietf-core-coap-07 (work in progress), July 2011. 342 [DANE] Hoffman, P. and J. Schlyter, "Using Secure DNS to 343 Associate Certificates with Domain Names For TLS", 344 draft-ietf-dane-protocol-12 (work in progress), 345 September 2011. 347 [Defeating-SSL] 348 Marlinspike, M., "New Tricks for Defeating SSL in 349 Practice", February 2009, . 353 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 354 (LDAP): The Protocol", RFC 4511, June 2006. 356 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 357 Extension Definitions", RFC 6066, January 2011. 359 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 360 for Transport Layer Security (TLS) Authentication", 361 RFC 6091, February 2011. 363 Authors' Addresses 365 Paul Wouters 366 No Hats Corporation 368 Email: paul@nohats.ca 370 John Gilmore 371 PO Box 170608 372 San Francisco, California 94117 373 USA 375 Phone: +1 415 221 6524 376 Email: gnu@toad.com 377 URI: https://www.toad.com/ 379 Samuel Weiler 380 SPARTA, Inc. 381 7110 Samuel Morse Drive 382 Columbia, Maryland 21046 383 US 385 Email: weiler@tislabs.com 387 Tero Kivinen 388 AuthenTec 389 Eerikinkatu 28 390 HELSINKI FI-00180 391 FI 393 Email: kivinen@iki.fi 395 Hannes Tschofenig 396 Nokia Siemens Networks 397 Linnoitustie 6 398 Espoo 02600 399 Finland 401 Phone: +358 (50) 4871445 402 Email: Hannes.Tschofenig@gmx.net 403 URI: http://www.tschofenig.priv.at