idnits 2.17.1 draft-ietf-tls-oob-pubkey-03.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 (April 25, 2012) is 4382 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 192, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-09 == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-19 == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-11 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS P. Wouters 3 Internet-Draft No Hats Corporation 4 Intended status: Standards Track J. Gilmore 5 Expires: October 27, 2012 6 S. Weiler 7 SPARTA, Inc. 8 T. Kivinen 9 AuthenTec 10 H. Tschofenig 11 Nokia Siemens Networks 12 April 25, 2012 14 TLS Out-of-Band Public Key Validation 15 draft-ietf-tls-oob-pubkey-03.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 public key validation. 22 Currently, TLS authentication can only occur via X.509-based Public 23 Key Infrastructure (PKI) or OpenPGP certificates. By specifying a 24 minimum resource for raw public key exchange, implementations can use 25 alternative public key validation methods. 27 One such alternative public key valiation method is offered by the 28 DNS-Based Authentication of Named Entities (DANE) together with DNS 29 Security. Another alternative is to utilize pre-configured keys, as 30 is the case with sensors and other embedded devices. The usage of 31 raw public keys, instead of X.509-based certificates, leads to a 32 smaller code footprint. 34 The support for raw public keys is introduced into TLS via a new non- 35 PKIX certificate type. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on October 27, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.3. Certificate Request . . . . . . . . . . . . . . . . . . . . 7 77 3.4. Other Handshake Messages . . . . . . . . . . . . . . . . . 7 78 3.5. Client authentication . . . . . . . . . . . . . . . . . . . 7 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 81 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 85 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 Traditionally, TLS server public keys are obtained in PKIX containers 91 in-band using the TLS handshake and validated using trust anchors 92 based on a [PKIX] certification authority (CA). This method can add 93 a complicated trust relationship that is difficult to validate. 94 Examples of such complexity can be seen in [Defeating-SSL]. 96 Alternative methods are available that allow a TLS client to obtain 97 the TLS server public key: 99 o The TLS server public key is obtained from a DNSSEC secured 100 resource records using DANE [I-D.ietf-dane-protocol]. 102 o The TLS server public key is obtained from a [PKIX] certificate 103 chain from an Lightweight Directory Access Protocol (LDAP) [LDAP] 104 server. 106 o The TLS client and server public key is provisioned into the 107 operating system firmware image, and updated via software updates. 109 Some smart objects use the UDP-based Constrained Application Protocol 110 (CoAP) [I-D.ietf-core-coap] to interact with a Web server to upload 111 sensor data at a regular intervals, such as temperature readings. 112 CoAP [I-D.ietf-core-coap] can utilize DTLS for securing the client- 113 to-server communication. As part of the manufacturing process, the 114 embeded device may be configured with the address and the public key 115 of a dedicated CoAP server, as well as a public key for the client 116 itself. The usage of X.509-based PKIX certificates [PKIX] may not 117 suit all smart object deployments and would therefore be an 118 unneccesarry burden. 120 The Transport Layer Security (TLS) Protocol Version 1.2 [RFC5246] 121 provides a framework for extensions to TLS as well as guidelines for 122 designing such extensions. This document uses the TLS Certificate 123 Type extension point to define a new non-X.509 certificate type for 124 carrying raw public keys. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. TLS Handshake Extension 134 This section describes the changes to the TLS handshake message 135 contents when raw public key certificates are to be used. Figure 1 136 illustrates the exchange of messages as described in the sub-sections 137 below. The new "RawPublicKey" value in the cert_type extension 138 indicates the ability and desire to exchange raw public keys, which 139 are then exchanged as part of the certificate payloads. Note that 140 the certificate payloads only contain the SubjectPublicKeyInfo 141 structure instead of the entire certificate. 143 client_hello, 144 cert_type="RawPublicKey" -> 146 <- server_hello, 147 cert_type="RawPublicKey", 148 certificate, 149 server_key_exchange, 150 certificate_request, 151 server_hello_done 153 certificate, 154 client_key_exchange, 155 certificate_verify, 156 change_cipher_spec, 157 finished -> 159 <- change_cipher_spec, 160 finished 162 Application Data <-------> Application Data 164 Figure 1: Example Message Flow 166 3.1. Client Hello 168 In order to indicate the support of out-of-band raw public keys, 169 clients MUST include an extension of type "cert_type" to the extended 170 client hello message. The "cert_type" TLS extension, which is 171 defined in [RFC6091], is assigned the value of 9 from the TLS 172 ExtensionType registry. This value is used as the extension number 173 for the extensions in both the client hello message and the server 174 hello message. The hello extension mechanism is described in 175 [RFC5246]. 177 The "cert_type" TLS extension carries a list of supported certificate 178 types the client can use, sorted by client preference. This 179 extension MUST be omitted if the client only supports X.509 180 certificates. The "extension_data" field of this extension contains 181 a CertificateTypeExtension structure. Note that the 182 CertificateTypeExtension structure is being used both by the client 183 and the server, even though the structure is only specified once in 184 this document. 186 The [RFC6091] defined CertificateTypeExtension is extended as 187 follows: 189 enum { client, server } ClientOrServerExtension; 191 enum { X.509(0), OpenPGP(1), 192 RawPublicKey([TBD]), 193 (255) } CertificateType; 195 struct { 196 select(ClientOrServerExtension) 197 case client: 198 CertificateType certificate_types<1..2^8-1>; 199 case server: 200 CertificateType certificate_type; 201 } 202 } CertificateTypeExtension; 204 No new cipher suites are required to use raw public keys. All 205 existing cipher suites that support a key exchange method compatible 206 with the defined extension can be used. 208 3.2. Server Hello 210 If the server receives a client hello that contains the "cert_type" 211 extension and chooses a cipher suite then two outcomes are possible. 212 The server MUST either select a certificate type from the 213 CertificateType field in the extended client hello or terminate the 214 session with a fatal alert of type "unsupported_certificate". 216 The certificate type selected by the server is encoded in a 217 CertificateTypeExtension structure, which is included in the extended 218 server hello message using an extension of type "cert_type". Servers 219 that only support X.509 certificates MAY omit including the 220 "cert_type" extension in the extended server hello. 222 If the negotiated certificate type is RawPublicKey the TLS server 223 MUST place the SubjectPublicKeyInfo structure into the Certificate 224 payload. The public key MUST match the selected key exchange 225 algorithm. 227 3.3. Certificate Request 229 The semantics of this message remain the same as in the TLS 230 specification. 232 3.4. Other Handshake Messages 234 All the other handshake messages are identical to the TLS 235 specification. 237 3.5. Client authentication 239 Client authentication by the TLS server is supported only through 240 authentication of the received client SubjectPublicKeyInfo via an 241 out-of-band method 243 4. Security Considerations 245 The transmission of raw public keys, as described in this document, 246 provides benefits by lowering the over-the-air transmission overhead 247 since raw public keys are quite naturally smaller than an entire 248 certificate. There are also advantages from a codesize point of view 249 for parsing and processing these keys. The crytographic procedures 250 for assocating the public key with the possession of a private key 251 also follows standard procedures. 253 The main security challenge is, however, how to associate the public 254 key with a specific entity. This information will be needed to make 255 authorization decisions. Without a secure binding, man-in-the-middle 256 attacks may be the consequence. This document assumes that such 257 binding can be made out-of-band and we list a few examples in 258 Section 1. DANE [I-D.ietf-dane-protocol] offers one such approach. 259 If public keys are obtained using DANE, these public keys are 260 authenticated via DNSSEC. Pre-configured keys is another out of band 261 method for authenticating raw public keys. While pre-configured keys 262 are not suitable for a generic Web-based e-commerce environment such 263 keys are a reasonable approach for many smart object deployments 264 where there is a close relationship between the software running on 265 the device and the server-side communication endpoint. Regardless of 266 the chosen mechanism for out-of-band public key validation an 267 assessment of the most suitable approach has to be made prior to the 268 start of a deployment to ensure the security of the system. 270 5. IANA Considerations 272 This document requests IANA to assign a TLS cert_type value for 273 RawPublicKey. The cert_type registry is established with [RFC6091]. 275 6. Contributors 277 The following individuals made important contributions to this 278 document: Paul Hoffman. 280 7. Acknowledgements 282 The feedback from the TLS working group meeting at IETF#81 has 283 substantially shaped the document and we would like to thank the 284 meeting participants for their input. The support for hashes of 285 public keys has been moved to [I-D.ietf-tls-cached-info] after the 286 discussions at the IETF#82 meeting and the feedback from Eric 287 Rescorla. 289 We would like to thank Martin Rex, Bill Frantz, Zach Shelby, Carsten 290 Bormann, Cullen Jennings, Rene Struik, Alper Yegin, and Jim Schaad. 292 8. References 294 8.1. Normative References 296 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 297 Housley, R., and W. Polk, "Internet X.509 Public Key 298 Infrastructure Certificate and Certificate Revocation List 299 (CRL) Profile", RFC 5280, May 2008. 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 305 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 307 8.2. Informative References 309 [Defeating-SSL] 310 Marlinspike, M., "New Tricks for Defeating SSL in 311 Practice", February 2009, . 315 [I-D.ietf-core-coap] 316 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 317 "Constrained Application Protocol (CoAP)", 318 draft-ietf-core-coap-09 (work in progress), March 2012. 320 [I-D.ietf-dane-protocol] 321 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 322 of Named Entities (DANE) Protocol for Transport Layer 323 Security (TLS)", draft-ietf-dane-protocol-19 (work in 324 progress), April 2012. 326 [I-D.ietf-tls-cached-info] 327 Santesson, S. and H. Tschofenig, "Transport Layer Security 328 (TLS) Cached Information Extension", 329 draft-ietf-tls-cached-info-11 (work in progress), 330 December 2011. 332 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 333 (LDAP): The Protocol", RFC 4511, June 2006. 335 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 336 for Transport Layer Security (TLS) Authentication", 337 RFC 6091, February 2011. 339 Authors' Addresses 341 Paul Wouters 342 No Hats Corporation 344 Email: paul@nohats.ca 346 John Gilmore 347 PO Box 170608 348 San Francisco, California 94117 349 USA 351 Phone: +1 415 221 6524 352 Email: gnu@toad.com 353 URI: https://www.toad.com/ 354 Samuel Weiler 355 SPARTA, Inc. 356 7110 Samuel Morse Drive 357 Columbia, Maryland 21046 358 US 360 Email: weiler@tislabs.com 362 Tero Kivinen 363 AuthenTec 364 Eerikinkatu 28 365 HELSINKI FI-00180 366 FI 368 Email: kivinen@iki.fi 370 Hannes Tschofenig 371 Nokia Siemens Networks 372 Linnoitustie 6 373 Espoo 02600 374 Finland 376 Phone: +358 (50) 4871445 377 Email: Hannes.Tschofenig@gmx.net 378 URI: http://www.tschofenig.priv.at