idnits 2.17.1 draft-ietf-tls-oob-pubkey-04.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 (July 16, 2012) is 4303 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) -- Looks like a reference, but probably isn't: '1' on line 301 -- Looks like a reference, but probably isn't: '2' on line 304 -- Looks like a reference, but probably isn't: '3' on line 305 -- Looks like a reference, but probably isn't: '4' on line 306 -- Looks like a reference, but probably isn't: '5' on line 307 -- Looks like a reference, but probably isn't: '7' on line 312 -- Looks like a reference, but probably isn't: '6' on line 311 == Unused Reference: 'RFC6091' is defined on line 432, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-11 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track J. Gilmore 5 Expires: January 17, 2013 6 S. Weiler 7 SPARTA, Inc. 8 T. Kivinen 9 AuthenTec 10 H. Tschofenig 11 Nokia Siemens Networks 12 July 16, 2012 14 Out-of-Band Public Key Validation for Transport Layer Security 15 draft-ietf-tls-oob-pubkey-04.txt 17 Abstract 19 This document specifies a new 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 This document introduces the support for raw public keys in TLS. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 17, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. New TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 4 73 4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 5 74 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 6 77 4.4. Certificate Payload . . . . . . . . . . . . . . . . . . . 6 78 4.5. Other TLS Messages . . . . . . . . . . . . . . . . . . . . 6 79 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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] does 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 defines an extension to 123 indicate the support for raw public keys. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 3. New TLS Extensions 133 In order to indicate the support for multiple certificate types two 134 new extensions are defined by this specification with the following 135 semantic: 137 cert-send: The certificate payload in this message contains a 138 certificate of the type indicated by this extension. 140 cert-receive: By including this extension an entity indicates that 141 it is able to recieve and process the indicated certificate types. 142 This list is sorted by preference. 144 enum { X.509(0), RawPublicKey(1), (255) } CertType; 146 CertType cert-receive <1..2^8-1>; 148 CertType cert-send; 150 Figure 1: New TLS Extension Structures 152 No new cipher suites are required for use with raw public keys. All 153 existing cipher suites that support a key exchange method compatible 154 with the key in the certificate can be used in combination with raw 155 public key certificate types. 157 4. TLS Handshake Extension 159 This section describes the semantic of the 'cert-send' and the 'cert- 160 receive' extensions for the different handshake messages. 162 4.1. Client Hello 164 To allow a TLS client to indicate that it is able to receive a 165 certificate of a specific type it MAY include the 'cert-receive' 166 extension in the client hello message. To indicate the ability to 167 process a raw public key by the server the TLS client MUST include 168 the 'cert-receive' with the value one (1) (indicating "RawPublicKey") 169 in the list of supported certificate types. If a TLS client only 170 supports X.509 certificates it MAY include this extension to indicate 171 support for it. 173 Future documents may define additional certificate types that require 174 addition values to be registered. 176 Note: No new cipher suites are required to use raw public keys. All 177 existing cipher suites that support a key exchange method compatible 178 with the defined extension can be used. 180 4.2. Server Hello 182 If the server receives a client hello that contains the 'cert- 183 receive' extension then two outcomes are possible. The server MUST 184 either select a certificate type from client-provided list or 185 terminate the session with a fatal alert of type 186 "unsupported_certificate". In the former case the procedure in 187 Section 4.4 MUST be followed. 189 4.3. Certificate Request 191 The Certificate Request payload sent by the TLS server to the TLS 192 client MUST be accompanied by a 'cert-receive' extension, which 193 indicates to the TLS client the certificate type the server supports. 195 4.4. Certificate Payload 197 Certificate payloads MUST be accompanied by a 'cert-send' extension, 198 which indicates the certificate format found in the Certificate 199 payload itself. 201 The list of supported certificate types to choose from MUST have been 202 obtained via the 'cert-receive' extension. This ensures that a 203 Certificate payload only contains a certificate type that is also 204 supported by the recipient. 206 When the 'RawPublicKey' certificate type is selected then the 207 SubjectPublicKeyInfo structure MUST be placed into the Certificate 208 payload. The type of the asymmetric key MUST match the selected key 209 exchange algorithm. 211 4.5. Other TLS Messages 213 All the other handshake messages are identical to the TLS 214 specification. 216 5. Examples 218 Figure 2, Figure 3, and Figure 4 illustrate example message 219 exchanges. 221 The first example shows an exchange where the TLS client indicates 222 its ability to process two certificate types, namely raw public keys 223 and X.509 certificates via the 'cert-receive' extension (see [1]). 224 When the TLS server receives the client hello it processes the cert- 225 receive extension and since it also has a raw public key it indicates 226 in [2] that it had choosen to place the SubjectPublicKeyInfo 227 structure into the Certificate payload (see [3]). The client uses 228 this raw public key in the TLS handshake and an out-of-band 229 technique, such as DANE, to verify its validatity. 231 client_hello, 232 cert-receive=(RawPublicKey, X.509) -> // [1] 234 <- server_hello, 235 cert-send=RawPublicKey, // [2] 236 certificate, // [3] 237 server_key_exchange, 238 server_hello_done 240 client_key_exchange, 241 change_cipher_spec, 242 finished -> 244 <- change_cipher_spec, 245 finished 247 Application Data <-------> Application Data 249 Figure 2: Example with Raw Public Key provided by the TLS Server 251 In our second example the TLS client and the TLS server use raw 252 public keys. This is a use case envisioned for smart object 253 networking. The TLS client in this case is an embedded device that 254 only supports raw public keys and therefore it indicates this 255 capability via the 'cert-receive' extension in [1]. As in the 256 previously shown example the server fulfills the client's request and 257 provides a raw public key into the Certificate payload back to the 258 client (see [2] and [3]). The TLS server, however, demands client 259 authentication and for this reason a Certificate_Request payload is 260 added [4], which comes with an indication of the supported 261 certificate types by the server, see [5]. The TLS client, who has a 262 raw public key pre-provisioned, returns it in the Certificate payload 263 [7] to the server with the indication about its content [6]. 265 client_hello, 266 cert-receive=(RawPublicKey) -> // [1] 268 <- server_hello, 269 cert-send=RawPublicKey,// [2] 270 certificate, // [3] 271 certificate_request, // [4] 272 cert-receive=(RawPublicKey, X.509) // [5] 273 server_key_exchange, 274 server_hello_done 276 cert-send=RawPublicKey, // [6] 277 certificate, // [7] 278 client_key_exchange, 279 change_cipher_spec, 280 finished -> 282 <- change_cipher_spec, 283 finished 285 Application Data <-------> Application Data 287 Figure 3: Example with Raw Public Key provided by the TLS Server and 288 the Client 290 In our last example we illustrate a combination of raw public key and 291 X.509 usage. The client uses a raw public key for client 292 authentication but the server provides an X.509 certificate. This 293 exchange starts with the client indicating its ability to process 294 X.509 certificates. The server provides the X.509 certificate using 295 that format in [3] with the indication present in [2]. For client 296 authentication, however, the server indicates in [5] that it is able 297 to support raw public keys as well as X.509 certificates. The TLS 298 client provides a raw public key in [7] and the indication in [6]. 300 client_hello, 301 cert-receive=(X.509) -> // [1] 303 <- server_hello, 304 cert-send=X.509,// [2] 305 certificate, // [3] 306 certificate_request, // [4] 307 cert-receive=(RawPublicKey, X.509) // [5] 308 server_key_exchange, 309 server_hello_done 311 cert-send=RawPublicKey, // [6] 312 certificate, // [7] 313 client_key_exchange, 314 change_cipher_spec, 315 finished -> 317 <- change_cipher_spec, 318 finished 320 Application Data <-------> Application Data 322 Figure 4: Hybrid Certificate Example 324 6. Security Considerations 326 The transmission of raw public keys, as described in this document, 327 provides benefits by lowering the over-the-air transmission overhead 328 since raw public keys are quite naturally smaller than an entire 329 certificate. There are also advantages from a codesize point of view 330 for parsing and processing these keys. The crytographic procedures 331 for assocating the public key with the possession of a private key 332 also follows standard procedures. 334 The main security challenge is, however, how to associate the public 335 key with a specific entity. This information will be needed to make 336 authorization decisions. Without a secure binding, man-in-the-middle 337 attacks may be the consequence. This document assumes that such 338 binding can be made out-of-band and we list a few examples in 339 Section 1. DANE [I-D.ietf-dane-protocol] offers one such approach. 340 If public keys are obtained using DANE, these public keys are 341 authenticated via DNSSEC. Pre-configured keys is another out of band 342 method for authenticating raw public keys. While pre-configured keys 343 are not suitable for a generic Web-based e-commerce environment such 344 keys are a reasonable approach for many smart object deployments 345 where there is a close relationship between the software running on 346 the device and the server-side communication endpoint. Regardless of 347 the chosen mechanism for out-of-band public key validation an 348 assessment of the most suitable approach has to be made prior to the 349 start of a deployment to ensure the security of the system. 351 7. IANA Considerations 353 This document defines two new TLS extension, 'cert-send' and 'cert- 354 receive', and their values need to be added to the TLS ExtensionType 355 registry created by RFC 5246 [RFC5246]. 357 The values in these new extensions contains an 8-bit CertificateType 358 field, for which a new registry, named "Certificate Types", is 359 established in this document, to be maintained by IANA. The registry 360 is segmented in the following way: 362 1. The value (0) is defined in this document. 364 2. Values from 2 through 223 decimal inclusive are assigned using 365 the 'Specification Required' policy defined in RFC 5226 366 [RFC5226]. 368 3. Values from 224 decimal through 255 decimal inclusive are 369 reserved for 'Private Use', see [RFC5226]. 371 8. Acknowledgements 373 The feedback from the TLS working group meeting at IETF#81 has 374 substantially shaped the document and we would like to thank the 375 meeting participants for their input. The support for hashes of 376 public keys has been moved to [I-D.ietf-tls-cached-info] after the 377 discussions at the IETF#82 meeting and the feedback from Eric 378 Rescorla. 380 We would like to thank the following persons for their review 381 comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, 382 Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Paul Hoffman, 383 Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John Bradley, and 384 James Manger. 386 9. References 387 9.1. Normative References 389 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 390 Housley, R., and W. Polk, "Internet X.509 Public Key 391 Infrastructure Certificate and Certificate Revocation List 392 (CRL) Profile", RFC 5280, May 2008. 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, March 1997. 397 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 398 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 400 9.2. Informative References 402 [Defeating-SSL] 403 Marlinspike, M., "New Tricks for Defeating SSL in 404 Practice", February 2009, . 408 [I-D.ietf-core-coap] 409 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 410 "Constrained Application Protocol (CoAP)", 411 draft-ietf-core-coap-10 (work in progress), June 2012. 413 [I-D.ietf-dane-protocol] 414 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 415 of Named Entities (DANE) Transport Layer Security (TLS) 416 Protocol: TLSA", draft-ietf-dane-protocol-23 (work in 417 progress), June 2012. 419 [I-D.ietf-tls-cached-info] 420 Santesson, S. and H. Tschofenig, "Transport Layer Security 421 (TLS) Cached Information Extension", 422 draft-ietf-tls-cached-info-11 (work in progress), 423 December 2011. 425 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 426 (LDAP): The Protocol", RFC 4511, June 2006. 428 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 429 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 430 May 2008. 432 [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys 433 for Transport Layer Security (TLS) Authentication", 434 RFC 6091, February 2011. 436 Authors' Addresses 438 Paul Wouters 439 Red Hat 441 Email: paul@nohats.ca 443 John Gilmore 444 PO Box 170608 445 San Francisco, California 94117 446 USA 448 Phone: +1 415 221 6524 449 Email: gnu@toad.com 450 URI: https://www.toad.com/ 452 Samuel Weiler 453 SPARTA, Inc. 454 7110 Samuel Morse Drive 455 Columbia, Maryland 21046 456 US 458 Email: weiler@tislabs.com 460 Tero Kivinen 461 AuthenTec 462 Eerikinkatu 28 463 HELSINKI FI-00180 464 FI 466 Email: kivinen@iki.fi 468 Hannes Tschofenig 469 Nokia Siemens Networks 470 Linnoitustie 6 471 Espoo 02600 472 Finland 474 Phone: +358 (50) 4871445 475 Email: Hannes.Tschofenig@gmx.net 476 URI: http://www.tschofenig.priv.at