idnits 2.17.1 draft-ietf-tls-oob-pubkey-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4197 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 425, but not defined -- Looks like a reference, but probably isn't: '1' on line 374 -- Looks like a reference, but probably isn't: '2' on line 378 -- Looks like a reference, but probably isn't: '3' on line 379 -- Looks like a reference, but probably isn't: '4' on line 380 -- Looks like a reference, but probably isn't: '5' on line 383 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-12 == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-13 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS P. Wouters, Ed. 3 Internet-Draft Red Hat 4 Intended status: Standards Track H. Tschofenig, Ed. 5 Expires: April 25, 2013 Nokia Siemens Networks 6 J. Gilmore 8 S. Weiler 9 SPARTA, Inc. 10 T. Kivinen 11 AuthenTec 12 October 22, 2012 14 Out-of-Band Public Key Validation for Transport Layer Security (TLS) 15 draft-ietf-tls-oob-pubkey-06.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 April 25, 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 Extension . . . . . . . . . . . . . . . . . . . . . . 4 73 4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 7 74 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 8 77 4.4. Other Handshake Messages . . . . . . . . . . . . . . . . . 8 78 4.5. Client authentication . . . . . . . . . . . . . . . . . . 8 79 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 [RFC6698]. 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 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 Extension 133 This section describes the changes to the TLS handshake message 134 contents when raw public key certificates are to be used. Figure 3 135 illustrates the exchange of messages as described in the sub-sections 136 below. The client and the server exchange the newly defined 137 certificate_type extension to indicate their ability and desire to 138 exchange raw public keys. These raw public keys, in the form of a 139 SubjectPublicKeyInfo structure, are then carried inside the 140 certificate payload. The SubjectPublicKeyInfo structure is defined 141 in Section 4.1 of RFC 5280. Note that the SubjectPublicKeyInfo block 142 does not only contain the raw keys, such as the public exponent and 143 the modulus of an RSA public key, but also an algorithm identifier. 144 The structure, as shown in Figure 1, is encoded in an ASN.1 format 145 and therefore contains length information as well. 147 SubjectPublicKeyInfo ::= SEQUENCE { 148 algorithm AlgorithmIdentifier, 149 subjectPublicKey BIT STRING } 151 Figure 1: SubjectPublicKeyInfo ASN.1 Structure. 153 The algorithm identifiers are Object Identifiers (OIDs). RFC 3279 154 [RFC3279], for example, defines the following OIDs shown in Figure 2. 156 Key Type | Document | OID 157 -----------------------+----------------------------+------------------- 158 RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 159 .......................|............................|................... 160 Digital Signature | | 161 Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 162 .......................|............................|................... 163 Elliptic Curve | | 164 Digital Signature | | 165 Algorithm (ECDSA) | Section 2.3.5 of RFC 3279 | 1.2.840.10045.2.1 166 -----------------------+----------------------------+------------------- 168 Figure 2: Example Algorithm Identifiers. 170 client_hello, 171 certificate_type -> 173 <- server_hello, 174 certificate_type, 175 certificate, 176 server_key_exchange, 177 certificate_request, 178 server_hello_done 179 certificate, 180 client_key_exchange, 181 certificate_verify, 182 change_cipher_spec, 183 finished -> 185 <- change_cipher_spec, 186 finished 188 Application Data <-------> Application Data 190 Figure 3: Basic Raw Public Key TLS Exchange. 192 The "certificate_type" TLS extension carries a list of supported 193 certificate types the client can send and receive, sorted by client 194 preference. Two values are defined for each certificate types to 195 differentiate whether a client or a server is able to process a 196 certificate of a specific type or can also send it. This extension 197 MUST be omitted if the client only supports X.509 certificates. The 198 "extension_data" field of this extension contains a CertTypeExtension 199 structure. 201 Note that the CertTypeExtension structure is being used both by the 202 client and the server, even though the structure is only specified 203 once in this document. 205 The structure of the CertTypeExtension is defined as follows: 207 enum { client, server } ClientOrServerExtension; 209 enum { X.509-Accept (0), 210 X.509-Offer (1), 211 RawPublicKey-Accept (2), 212 RawPublicKey-Offer (3), 213 (255) 214 } CertificateType; 216 struct { 217 select(ClientOrServerExtension) 218 case client: 219 CertificateType certificate_types<1..2^8-1>; 220 case server: 221 CertificateType certificate_type; 222 } 223 } CertTypeExtension; 225 Figure 4: CertTypeExtension Structure. 227 The '-Offer' postfix indicates that a TLS entity is able to send the 228 indicated certificate type to the other communication partner. The 229 '-Accept' postfix indicates that a TLS entity is able to receive the 230 indicated certificate type. 232 No new cipher suites are required to use raw public keys. All 233 existing cipher suites that support a key exchange method compatible 234 with the defined extension can be used. 236 4. TLS Handshake Extension 238 4.1. Client Hello 240 In order to indicate the support of out-of-band raw public keys, 241 clients MUST include an extension of type "certificate_type" to the 242 extended client hello message. The "certificate_type" TLS extension 243 is assigned the value of [TBD] from the TLS ExtensionType registry. 244 This value is used as the extension number for the extensions in both 245 the client hello message and the server hello message. The hello 246 extension mechanism is described in TLS 1.2 [RFC5246]. 248 4.2. Server Hello 250 If the server receives a client hello that contains the 251 "certificate_type" extension and chooses a cipher suite then two 252 outcomes are possible. The server MUST either select a certificate 253 type from the CertificateType field in the extended client hello or 254 terminate the session with a fatal alert of type 255 "unsupported_certificate". 257 The certificate type selected by the server is encoded in a 258 CertTypeExtension structure, which is included in the extended server 259 hello message using an extension of type "certificate_type". Servers 260 that only support X.509 certificates MAY omit including the 261 "certificate_type" extension in the extended server hello. 263 If the client supports the receiption of raw public keys and the 264 server is able to provide such a raw public key then the TLS server 265 MUST place the SubjectPublicKeyInfo structure into the Certificate 266 payload. The public key MUST match the selected key exchange 267 algorithm. 269 4.3. Certificate Request 271 The semantics of this message remain the same as in the TLS 272 specification. 274 4.4. Other Handshake Messages 276 All the other handshake messages are identical to the TLS 277 specification. 279 4.5. Client authentication 281 Client authentication by the TLS server is supported only through 282 authentication of the received client SubjectPublicKeyInfo via an 283 out-of-band method 285 5. Examples 287 Figure 5, Figure 6, and Figure 7 illustrate example exchanges. 289 The first example shows an exchange where the TLS client indicates 290 its ability to receive raw public keys. This client is quite 291 restricted since it is unable to process other certificate types sent 292 by the server. It also does not have credentials it could send. The 293 'certificate_type' extension indicates this in [1]. When the TLS 294 server receives the client hello it processes the certificate_type 295 extension. Since it also has a raw public key it indicates in [2] 296 that it had choosen to place the SubjectPublicKeyInfo structure into 297 the Certificate payload [3]. The client uses this raw public key in 298 the TLS handshake and an out-of-band technique, such as DANE, to 299 verify its validity. 301 client_hello, 302 certificate_type=(RawPublicKey-Accept) -> // [1] 304 <- server_hello, 305 certificate_type=(RawPublicKey-Offer), // [2] 306 certificate, // [3] 307 server_key_exchange, 308 server_hello_done 310 client_key_exchange, 311 change_cipher_spec, 312 finished -> 314 <- change_cipher_spec, 315 finished 317 Application Data <-------> Application Data 319 Figure 5: Example with Raw Public Key provided by the TLS Server 321 In our second example the TLS client as well as the TLS server use 322 raw public keys. This is a use case envisioned for smart object 323 networking. The TLS client in this case is an embedded device that 324 is configured with a raw public key for use with TLS and is also able 325 to process raw public keys sent by the server. Therefore, it 326 indicates these capabilities in the 'certificate_type' extension in 327 [1]. As in the previously shown example the server fulfills the 328 client's request, indicates this via the 'RawPublicKey-Offer'in the 329 certificate_type payload, and provides a raw public key into the 330 Certificate payload back to the client (see [3]). The TLS server, 331 however, demands client authentication and therefore a 332 certificate_request is added [4]. The certificate_type payload in 333 [2] indicates that the TLS server accepts raw public keys. The TLS 334 client, who has a raw public key pre-provisioned, returns it in the 335 Certificate payload [5] to the server. 337 client_hello, 338 certificate_type=(RawPublicKey-Offer, RawPublicKey-Accept) -> // [1] 340 <- server_hello, 341 certificate_type=(RawPublicKey-Offer, 342 RawPublicKey-Accept) // [2] 343 certificate, // [3] 344 certificate_request, // [4] 345 server_key_exchange, 346 server_hello_done 348 certificate, // [5] 349 client_key_exchange, 350 change_cipher_spec, 351 finished -> 353 <- change_cipher_spec, 354 finished 356 Application Data <-------> Application Data 358 Figure 6: Example with Raw Public Key provided by the TLS Server and 359 the Client 361 In our last example we illustrate a combination of raw public key and 362 X.509 usage. The client uses a raw public key for client 363 authentication but the server provides an X.509 certificate. This 364 exchange starts with the client indicating its ability to process 365 X.509 certificates provided by the server, and the ability to send 366 raw public keys. The server provides the X.509 certificate in [3] 367 with the indication present in [2]. For client authentication, 368 however, the server indicates in [2] that it is able to support raw 369 public keys and requests a certificate from the client in [4]. The 370 TLS client provides a raw public key in [5] after receiving and 371 processing the TLS server hello message. 373 client_hello, 374 certificate_type=(X.509-Accept, RawPublicKey-Offer) -> // [1] 376 <- server_hello, 377 certificate_type=(X.509-Offer, 378 RawPublicKey-Accept), // [2] 379 certificate, // [3] 380 certificate_request, // [4] 381 server_key_exchange, 382 server_hello_done 383 certificate, // [5] 384 client_key_exchange, 385 change_cipher_spec, 386 finished -> 388 <- change_cipher_spec, 389 finished 391 Application Data <-------> Application Data 393 Figure 7: Hybrid Certificate Example 395 6. Security Considerations 397 The transmission of raw public keys, as described in this document, 398 provides benefits by lowering the over-the-air transmission overhead 399 since raw public keys are quite naturally smaller than an entire 400 certificate. There are also advantages from a codesize point of view 401 for parsing and processing these keys. The crytographic procedures 402 for assocating the public key with the possession of a private key 403 also follows standard procedures. 405 The main security challenge is, however, how to associate the public 406 key with a specific entity. This information will be needed to make 407 authorization decisions. Without a secure binding, man-in-the-middle 408 attacks may be the consequence. This document assumes that such 409 binding can be made out-of-band and we list a few examples in 410 Section 1. DANE [RFC6698] offers one such approach. If public keys 411 are obtained using DANE, these public keys are authenticated via 412 DNSSEC. Pre-configured keys is another out of band method for 413 authenticating raw public keys. While pre-configured keys are not 414 suitable for a generic Web-based e-commerce environment such keys are 415 a reasonable approach for many smart object deployments where there 416 is a close relationship between the software running on the device 417 and the server-side communication endpoint. Regardless of the chosen 418 mechanism for out-of-band public key validation an assessment of the 419 most suitable approach has to be made prior to the start of a 420 deployment to ensure the security of the system. 422 7. IANA Considerations 424 This document defines a new TLS extension, "certificate_type", 425 assigned a value of [TBD] from the TLS ExtensionType registry defined 426 in [RFC5246]. This value is used as the extension number for the 427 extensions in both the client hello message and the server hello 428 message. The new extension type is used for certificate type 429 negotiation. 431 The "certificate_type" extension contains an 8-bit CertificateType 432 field, for which a new registry, named "TLS Certificate Types", is 433 established in this document, to be maintained by IANA. The registry 434 is segmented in the following way: 436 1. The values 0 - 3 are defined in Figure 4. 438 2. Values from 3 through 223 decimal inclusive are assigned via IETF 439 Consensus [RFC5226]. 441 3. Values from 224 decimal through 255 decimal inclusive are 442 reserved for Private Use [RFC5226]. 444 8. Acknowledgements 446 The feedback from the TLS working group meeting at IETF#81 has 447 substantially shaped the document and we would like to thank the 448 meeting participants for their input. The support for hashes of 449 public keys has been moved to [I-D.ietf-tls-cached-info] after the 450 discussions at the IETF#82 meeting and the feedback from Eric 451 Rescorla. 453 We would like to thank the following persons for their review 454 comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, 455 Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Paul Hoffman, 456 Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John Bradley, 457 Klaus Hartke, Stefan Jucker, and James Manger. 459 9. References 460 9.1. Normative References 462 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 463 Housley, R., and W. Polk, "Internet X.509 Public Key 464 Infrastructure Certificate and Certificate Revocation List 465 (CRL) Profile", RFC 5280, May 2008. 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 471 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 473 9.2. Informative References 475 [Defeating-SSL] 476 Marlinspike, M., "New Tricks for Defeating SSL in 477 Practice", February 2009, . 481 [I-D.ietf-core-coap] 482 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 483 "Constrained Application Protocol (CoAP)", 484 draft-ietf-core-coap-12 (work in progress), October 2012. 486 [I-D.ietf-tls-cached-info] 487 Santesson, S. and H. Tschofenig, "Transport Layer Security 488 (TLS) Cached Information Extension", 489 draft-ietf-tls-cached-info-13 (work in progress), 490 September 2012. 492 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 493 (LDAP): The Protocol", RFC 4511, June 2006. 495 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 496 Identifiers for the Internet X.509 Public Key 497 Infrastructure Certificate and Certificate Revocation List 498 (CRL) Profile", RFC 3279, April 2002. 500 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 501 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 502 May 2008. 504 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 505 of Named Entities (DANE) Transport Layer Security (TLS) 506 Protocol: TLSA", RFC 6698, August 2012. 508 Authors' Addresses 510 Paul Wouters (editor) 511 Red Hat 513 Email: paul@nohats.ca 515 Hannes Tschofenig (editor) 516 Nokia Siemens Networks 517 Linnoitustie 6 518 Espoo 02600 519 Finland 521 Phone: +358 (50) 4871445 522 Email: Hannes.Tschofenig@gmx.net 523 URI: http://www.tschofenig.priv.at 525 John Gilmore 526 PO Box 170608 527 San Francisco, California 94117 528 USA 530 Phone: +1 415 221 6524 531 Email: gnu@toad.com 532 URI: https://www.toad.com/ 534 Samuel Weiler 535 SPARTA, Inc. 536 7110 Samuel Morse Drive 537 Columbia, Maryland 21046 538 US 540 Email: weiler@tislabs.com 542 Tero Kivinen 543 AuthenTec 544 Eerikinkatu 28 545 HELSINKI FI-00180 546 FI 548 Email: kivinen@iki.fi