idnits 2.17.1 draft-ietf-tls-oob-pubkey-05.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 4201 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 417, but not defined -- Looks like a reference, but probably isn't: '1' on line 366 -- Looks like a reference, but probably isn't: '2' on line 370 -- Looks like a reference, but probably isn't: '3' on line 371 -- Looks like a reference, but probably isn't: '4' on line 372 -- Looks like a reference, but probably isn't: '5' on line 375 ** 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-05.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 No new cipher suites are required to use raw public keys. All 228 existing cipher suites that support a key exchange method compatible 229 with the defined extension can be used. 231 4. TLS Handshake Extension 233 4.1. Client Hello 235 In order to indicate the support of out-of-band raw public keys, 236 clients MUST include an extension of type "certificate_type" to the 237 extended client hello message. The "certificate_type" TLS extension 238 is assigned the value of [TBD] from the TLS ExtensionType registry. 239 This value is used as the extension number for the extensions in both 240 the client hello message and the server hello message. The hello 241 extension mechanism is described in TLS 1.2 [RFC5246]. 243 4.2. Server Hello 245 If the server receives a client hello that contains the 246 "certificate_type" extension and chooses a cipher suite then two 247 outcomes are possible. The server MUST either select a certificate 248 type from the CertificateType field in the extended client hello or 249 terminate the session with a fatal alert of type 250 "unsupported_certificate". 252 The certificate type selected by the server is encoded in a 253 CertTypeExtension structure, which is included in the extended server 254 hello message using an extension of type "certificate_type". Servers 255 that only support X.509 certificates MAY omit including the 256 "certificate_type" extension in the extended server hello. 258 If the client supports the receiption of raw public keys and the 259 server is able to provide such a raw public key then the TLS server 260 MUST place the SubjectPublicKeyInfo structure into the Certificate 261 payload. The public key MUST match the selected key exchange 262 algorithm. 264 4.3. Certificate Request 266 The semantics of this message remain the same as in the TLS 267 specification. 269 4.4. Other Handshake Messages 271 All the other handshake messages are identical to the TLS 272 specification. 274 4.5. Client authentication 276 Client authentication by the TLS server is supported only through 277 authentication of the received client SubjectPublicKeyInfo via an 278 out-of-band method 280 5. Examples 282 Figure 5, Figure 6, and Figure 7 illustrate example message 283 exchanges. 285 The first example shows an exchange where the TLS client indicates 286 its ability to process two certificate types, namely raw public keys 287 and X.509 certificates via the 'certificate_type' extension in [1]. 288 When the TLS server receives the client hello it processes the 289 certificate_type extension and since it also has a raw public key it 290 indicates in [2] that it had choosen to place the 291 SubjectPublicKeyInfo structure into the Certificate payload (see 292 [3]). The client uses this raw public key in the TLS handshake and 293 an out-of-band technique, such as DANE, to verify its validatity. 295 client_hello, 296 certificate_type=(RawPublicKey-Accept) -> // [1] 298 <- server_hello, 299 certificate_type=(RawPublicKey-Offer), // [2] 300 certificate, // [3] 301 server_key_exchange, 302 server_hello_done 304 client_key_exchange, 305 change_cipher_spec, 306 finished -> 308 <- change_cipher_spec, 309 finished 311 Application Data <-------> Application Data 313 Figure 5: Example with Raw Public Key provided by the TLS Server 315 In our second example both the TLS client and the TLS server use raw 316 public keys. This is a use case envisioned for smart object 317 networking. The TLS client in this case is an embedded device that 318 only supports raw public keys and therefore it indicates this 319 capability via the 'certificate_type' extension in [1]. As in the 320 previously shown example the server fulfills the client's request and 321 provides a raw public key into the Certificate payload back to the 322 client (see [3]). The TLS server, however, demands client 323 authentication and therefore a certificate_request is added [4]. The 324 certificate_type payload indicates the TLS server supported 325 certificate types, see [2], and particularly that the TLS server is 326 also able to process raw public keys sent by the client. The TLS 327 client, who has a raw public key pre-provisioned, returns it in the 328 Certificate payload [5] to the server. 330 client_hello, 331 certificate_type=(RawPublicKey-Offer, RawPublicKey-Accept) -> // [1] 333 <- server_hello, 334 certificate_type=(RawPublicKey-Offer, 335 RawPublicKey-Accept) // [2] 336 certificate, // [3] 337 certificate_request, // [4] 338 server_key_exchange, 339 server_hello_done 341 certificate, // [5] 342 client_key_exchange, 343 change_cipher_spec, 344 finished -> 346 <- change_cipher_spec, 347 finished 349 Application Data <-------> Application Data 351 Figure 6: Example with Raw Public Key provided by the TLS Server and 352 the Client 354 In our last example we illustrate a combination of raw public key and 355 X.509 usage. The client uses a raw public key for client 356 authentication but the server provides an X.509 certificate. This 357 exchange starts with the client indicating its ability to process 358 X.509 certificates provided by the server, and the ability to send 359 raw public keys. The server provides the X.509 certificate using 360 that format in [3] with the indication present in [2]. For client 361 authentication, however, the server indicates in [2] that it is able 362 to support raw public keys. The TLS client provides a raw public key 363 in [5] after receiving and processing the TLS server hello message. 365 client_hello, 366 certificate_type=(X.509 Receive, RawPublicKey-Offer) -> // [1] 368 <- server_hello, 369 certificate_type=(X.509 Send, 370 RawPublicKey-Accept), // [2] 371 certificate, // [3] 372 certificate_request, // [4] 373 server_key_exchange, 374 server_hello_done 375 certificate, // [5] 376 client_key_exchange, 377 change_cipher_spec, 378 finished -> 380 <- change_cipher_spec, 381 finished 383 Application Data <-------> Application Data 385 Figure 7: Hybrid Certificate Example 387 6. Security Considerations 389 The transmission of raw public keys, as described in this document, 390 provides benefits by lowering the over-the-air transmission overhead 391 since raw public keys are quite naturally smaller than an entire 392 certificate. There are also advantages from a codesize point of view 393 for parsing and processing these keys. The crytographic procedures 394 for assocating the public key with the possession of a private key 395 also follows standard procedures. 397 The main security challenge is, however, how to associate the public 398 key with a specific entity. This information will be needed to make 399 authorization decisions. Without a secure binding, man-in-the-middle 400 attacks may be the consequence. This document assumes that such 401 binding can be made out-of-band and we list a few examples in 402 Section 1. DANE [RFC6698] offers one such approach. If public keys 403 are obtained using DANE, these public keys are authenticated via 404 DNSSEC. Pre-configured keys is another out of band method for 405 authenticating raw public keys. While pre-configured keys are not 406 suitable for a generic Web-based e-commerce environment such keys are 407 a reasonable approach for many smart object deployments where there 408 is a close relationship between the software running on the device 409 and the server-side communication endpoint. Regardless of the chosen 410 mechanism for out-of-band public key validation an assessment of the 411 most suitable approach has to be made prior to the start of a 412 deployment to ensure the security of the system. 414 7. IANA Considerations 416 This document defines a new TLS extension, "certificate_type", 417 assigned a value of [TBD] from the TLS ExtensionType registry defined 418 in [RFC5246]. This value is used as the extension number for the 419 extensions in both the client hello message and the server hello 420 message. The new extension type is used for certificate type 421 negotiation. 423 The "certificate_type" extension contains an 8-bit CertificateType 424 field, for which a new registry, named "TLS Certificate Types", is 425 established in this document, to be maintained by IANA. The registry 426 is segmented in the following way: 428 1. The values 0 - 3 are defined in Figure 4. 430 2. Values from 3 through 223 decimal inclusive are assigned via IETF 431 Consensus [RFC5226]. 433 3. Values from 224 decimal through 255 decimal inclusive are 434 reserved for Private Use [RFC5226]. 436 8. Acknowledgements 438 The feedback from the TLS working group meeting at IETF#81 has 439 substantially shaped the document and we would like to thank the 440 meeting participants for their input. The support for hashes of 441 public keys has been moved to [I-D.ietf-tls-cached-info] after the 442 discussions at the IETF#82 meeting and the feedback from Eric 443 Rescorla. 445 We would like to thank the following persons for their review 446 comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, 447 Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Paul Hoffman, 448 Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John Bradley, 449 Klaus Hartke, Stefan Jucker, and James Manger. 451 9. References 452 9.1. Normative References 454 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 455 Housley, R., and W. Polk, "Internet X.509 Public Key 456 Infrastructure Certificate and Certificate Revocation List 457 (CRL) Profile", RFC 5280, May 2008. 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 463 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 465 9.2. Informative References 467 [Defeating-SSL] 468 Marlinspike, M., "New Tricks for Defeating SSL in 469 Practice", February 2009, . 473 [I-D.ietf-core-coap] 474 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 475 "Constrained Application Protocol (CoAP)", 476 draft-ietf-core-coap-12 (work in progress), October 2012. 478 [I-D.ietf-tls-cached-info] 479 Santesson, S. and H. Tschofenig, "Transport Layer Security 480 (TLS) Cached Information Extension", 481 draft-ietf-tls-cached-info-13 (work in progress), 482 September 2012. 484 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 485 (LDAP): The Protocol", RFC 4511, June 2006. 487 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 488 Identifiers for the Internet X.509 Public Key 489 Infrastructure Certificate and Certificate Revocation List 490 (CRL) Profile", RFC 3279, April 2002. 492 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 493 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 494 May 2008. 496 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 497 of Named Entities (DANE) Transport Layer Security (TLS) 498 Protocol: TLSA", RFC 6698, August 2012. 500 Authors' Addresses 502 Paul Wouters (editor) 503 Red Hat 505 Email: paul@nohats.ca 507 Hannes Tschofenig (editor) 508 Nokia Siemens Networks 509 Linnoitustie 6 510 Espoo 02600 511 Finland 513 Phone: +358 (50) 4871445 514 Email: Hannes.Tschofenig@gmx.net 515 URI: http://www.tschofenig.priv.at 517 John Gilmore 518 PO Box 170608 519 San Francisco, California 94117 520 USA 522 Phone: +1 415 221 6524 523 Email: gnu@toad.com 524 URI: https://www.toad.com/ 526 Samuel Weiler 527 SPARTA, Inc. 528 7110 Samuel Morse Drive 529 Columbia, Maryland 21046 530 US 532 Email: weiler@tislabs.com 534 Tero Kivinen 535 AuthenTec 536 Eerikinkatu 28 537 HELSINKI FI-00180 538 FI 540 Email: kivinen@iki.fi