idnits 2.17.1 draft-kivinen-ipsecme-oob-pubkey-14.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 (October 16, 2015) is 3107 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) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Kivinen 3 Internet-Draft INSIDE Secure 4 Updates: 7296 (if approved) P. Wouters 5 Intended status: Standards Track Red Hat 6 Expires: April 18, 2016 H. Tschofenig 7 October 16, 2015 9 Generic Raw Public Key Support for IKEv2 10 draft-kivinen-ipsecme-oob-pubkey-14.txt 12 Abstract 14 The Internet Key Exchange Version 2 (IKEv2) protocol did have support 15 for raw public keys, but it only supported RSA Raw public keys. In 16 constrained environments it is useful to make use of other types of 17 public keys, such as those based on Elliptic Curve Cryptography. 18 This document updates RFC 7296, adding support for other types of raw 19 public keys to IKEv2. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 18, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Certificate Encoding Payload . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 7.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 65 A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . 7 66 A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 This document replaces an algorithm-specific version of raw public 72 keys of Internet Key Exchange Version 2 (IKEv2) [RFC7296] with a 73 generic version of raw public keys that is algorithm agnostic. 75 In [RFC5996] IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a 76 DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other 77 raw public key types are, however, not supported. In [RFC7296] this 78 feature was removed, and this document adds support for raw public 79 keys back to IKEv2 in a more generic way. 81 DNSSEC allows public keys to be associated with domain names for 82 usage with security protocols like IKEv2 and Transport Layer Security 83 (TLS) [RFC5246] but it relies on extensions in those protocols to be 84 specified. 86 The Raw Public Keys in Transport Layer Security specification 87 ([RFC7250]) adds generic support for raw public keys to TLS by re- 88 using the SubjectPublicKeyInfo format from the X.509 Public Key 89 Infrastructure Certificate profile [RFC5280]. 91 This document is similar to the Raw Public Keys in Transport Layer 92 Security specification and applies the concept to IKEv2 to support 93 all public key formats defined by PKIX. This approach also allows 94 future public key extensions to be supported without the need to 95 introduce further enhancements to IKEv2. 97 To support new types of public keys in IKEv2 the following changes 98 are needed: 100 o A new Certificate Encoding format needs to be defined for carrying 101 the SubjectPublicKeyInfo structure. Section 3 specifies this new 102 encoding format. 104 o A new Certificate Encoding type needs to be allocated from the 105 IANA registry. Section 5 contains this request to IANA. 107 The base IKEv2 specification includes support for RSA and DSA 108 signatures, but the Signature Authentication in IKEv2 [RFC7427] 109 extended IKEv2 so that signature methods over any key type can be 110 used. Implementations using raw public keys SHOULD use the Digital 111 Signature method described in the RFC7427. 113 When using raw public keys, the authenticated identity is not usually 114 the identity from the ID payload, but instead the public key itself 115 is used as identity for the other end. This means that ID payload 116 contents might not be useful for authentication purposes. It might 117 still be used for policy decisions, for example to simplify the 118 policy lookup etc. Alternatively, the ID_NULL type [RFC7619] can be 119 used to indicate that the ID payload is not relevant to this 120 authentication. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. Certificate Encoding Payload 130 Section 3.6 of RFC 7296 defines the Certificate payload format as 131 shown in Figure 1. 133 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Next Payload |C| RESERVED | Payload Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Cert Encoding | | 139 +-+-+-+-+-+-+-+-+ | 140 ~ Certificate Data ~ 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1: Certificate Payload Format. 146 To support raw public keys, the field values are as follows: 148 o Certificate Encoding (1 octet) - This field indicates the type of 149 certificate or certificate-related information contained in the 150 Certificate Data field. 152 Certificate Encoding Value 153 ---------------------------------------------------- 154 Raw Public Key TBD 156 o Certificate Data (variable length) - Actual encoding of the 157 certificate data. 159 In order to provide a simple and standard way to indicate the key 160 type when the encoding type is 'Raw Public Key', the 161 SubjectPublicKeyInfo structure of the PKIX certificate is used. This 162 is a very simple encoding, as most of the ASN.1 part can be included 163 literally, and recognized by block comparison. See [RFC7250] 164 Appendix A for a detailed breakdown. In addition, Appendix A has 165 several examples. 167 In addition to the Certificate payload, the Cert Encoding for Raw 168 Public Key can be used in the Certificate Request payload. In that 169 case the Certification Authority field MUST be empty if the "Raw 170 Public Key" certificate encoding is used. 172 For RSA keys, the implementations MUST follow the public key 173 processing rules of section 1.2 of the Additional Algorithms and 174 Identifiers for RSA Cryptography for PKIX ([RFC4055]) even when the 175 SubjectPublicKeyInfo is not part of a certificate, but rather sent as 176 a Certificate Data field. This means that RSASSA-PSS and RSASSA-PSS- 177 params inside the SubjectPublicKeyInfo structure MUST be sent when 178 applicable. 180 4. Security Considerations 182 An IKEv2 deployment using raw public keys needs to utilize an out-of- 183 band public key validation procedure to be confident in the 184 authenticity of the keys being used. One way to achieve this goal is 185 to use a configuration mechanism for provisioning raw public keys 186 into the IKEv2 software. "Smart object" deployments are likely to 187 use such preconfigured public keys. 189 Another approach is to rely on secure DNS to associate public keys 190 with domain names using the IPSECKEY DNS RRtype [RFC4025]. More 191 information can be found in DNS-Based Authentication of Named 192 Entities (DANE) [RFC6394]. 194 This document does not change the security assumptions made by the 195 IKEv2 specification since "Raw RSA Key" support was already available 196 in IKEv2 in [RFC5996]. This document only generalizes raw public key 197 support. 199 5. IANA Considerations 201 This document allocates a new value from the IKEv2 Certificate 202 Encodings registry: 204 TBD Raw Public Key 206 6. Acknowledgements 208 This document reproduces some parts of the similar TLS document 209 ([RFC7250]). 211 7. References 213 7.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 217 RFC2119, March 1997, 218 . 220 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 221 Housley, R., and W. Polk, "Internet X.509 Public Key 222 Infrastructure Certificate and Certificate Revocation List 223 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 224 . 226 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 227 Kivinen, "Internet Key Exchange Protocol Version 2 228 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 229 2014, . 231 [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in 232 the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, 233 DOI 10.17487/RFC7427, January 2015, 234 . 236 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 237 Method in the Internet Key Exchange Protocol Version 2 238 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 239 . 241 7.2. Informative References 243 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 244 Standards (PKCS) #1: RSA Cryptography Specifications 245 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 246 2003, . 248 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 249 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 250 2005, . 252 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 253 Algorithms and Identifiers for RSA Cryptography for use in 254 the Internet X.509 Public Key Infrastructure Certificate 255 and Certificate Revocation List (CRL) Profile", RFC 4055, 256 DOI 10.17487/RFC4055, June 2005, 257 . 259 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 260 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 261 RFC 4754, DOI 10.17487/RFC4754, January 2007, 262 . 264 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 265 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 266 RFC5246, August 2008, 267 . 269 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 270 "Elliptic Curve Cryptography Subject Public Key 271 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 272 . 274 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 275 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 276 5996, DOI 10.17487/RFC5996, September 2010, 277 . 279 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 280 Authentication of Named Entities (DANE)", RFC 6394, DOI 281 10.17487/RFC6394, October 2011, 282 . 284 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 285 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 286 Transport Layer Security (TLS) and Datagram Transport 287 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 288 June 2014, . 290 [RSA] R. Rivest, , A. Shamir, , and L. Adleman, "A Method for 291 Obtaining Digital Signatures and Public-Key 292 Cryptosystems", February 1978. 294 Appendix A. Examples 296 This appendix provides examples of the actual payloads sent on the 297 wire. 299 A.1. ECDSA Example 301 This first example uses the 256-bit ECDSA private/public key pair 302 defined in section 8.1 of the IKEv2 ECDSA document [RFC4754]. 304 The public key is as follows: 306 o Algorithm : id-ecPublicKey (1.2.840.10045.2.1) 308 o Fixed curve: secp256r1 (1.2.840.10045.3.1.7) 310 o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707 311 9716cbbf 917dd72e 97566ea1 c066957c 313 o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f 314 dbe71e36 99d91339 afbb903e e17255dc 316 The SubjectPublicKeyInfo ASN.1 object is as follows: 318 0000 : SEQUENCE 319 0002 : SEQUENCE 320 0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1) 321 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 322 0017 : BIT STRING (66 bytes) 323 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 324 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 325 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 326 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 327 00000040: 55dc 329 The first byte (00) of the bit string indicates that there is no 330 "number of unused bits", and the second byte (04) indicates 331 uncompressed form ([RFC5480]). Those two octets are followed by the 332 values of X and Y. 334 The final encoded SubjectPublicKeyInfo object is as follows: 336 00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 337 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 338 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 339 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 340 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 341 00000050: d913 39af bb90 3ee1 7255 dc 343 This will result in the final IKEv2 Certificate Payload: 345 00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d 346 00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004 347 00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 348 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 349 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 350 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc 352 Where NN is the next payload type (i.e., the type of the payload that 353 immediately follows this Certificate payload). 355 Note to the RFC editor / IANA, replace the XX above with the newly 356 allocated Raw Public Key number (in hex notation), and remove this 357 note. 359 A.2. RSA Example 361 This second example uses a random 1024-bit RSA key. 363 The public key is as follows: 365 o Algorithm : rsaEncryption (1.2.840.113549.1.1.1) 367 o Modulus n (1024 bits, decimal): 368 1323562071162740912417075551025599045700 369 3972512968992059076067098474693867078469 370 7654066339302927451756327389839253751712 371 9485277759962777278073526290329821841100 372 9721044682579432931952695408402169276996 373 5181887843758615443536914372816830537901 374 8976615344413864477626646564638249672329 375 04996914356093900776754835411 377 o Modulus n (1024 bits, hexadecimal): bc7b4347 49c7b386 00bfa84b 378 44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638 379 e8ca348e bdca5742 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e 380 aa727c1f 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343 381 fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 66f36835 382 8ceaefd3 384 o Exponent e (17 bits, decimal): 65537 386 o Exponent e (17 bits, hexadecimal): 10001 388 The SubjectPublicKeyInfo ASN.1 object is as follows: 390 0000 : SEQUENCE 391 0003 : SEQUENCE 392 0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1) 393 0016 : NULL 394 0018 : BIT STRING (141 bytes) 395 00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386 396 00000010: 00bf a84b 44f8 8187 9a2d da08 d1f0 145a 397 00000020: f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638 398 00000030: e8ca 348e bdca 5742 31ca dc97 12e2 09b1 399 00000040: fddb a58a 8c62 b369 038a 3d1e aa72 7c1f 400 00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019 401 00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab 402 00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230 403 00000080: 66f3 6835 8cea efd3 0203 0100 01 405 The first byte (00) of the bit string indicates that there is no 406 "number of unused bits". Inside that bit string there is an ASN.1 407 sequence having 2 integers. The second byte (30) indicates that this 408 is beginning of the sequence, and the next byte (81) indicates the 409 length does not fit in 7 bits, but requires one byte, so the length 410 is in the next byte (89). Then starts the first integer with tag 411 (02) and length (81 81). After that we have the modulus (prefixed 412 with 0 so it will not be a negative number). After the modulus there 413 follows the tag (02) and length (03) of the exponent, and the last 3 414 bytes are the exponent. 416 The final encoded SubjectPublicKeyInfo object is as follows: 418 00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101 419 00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43 420 00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda 421 00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3 422 00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc 423 00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d 424 00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e 425 00000070: 2338 5a40 1915 858c 59be 72f3 43fb 1eb8 426 00000080: 7b16 ffc5 ab0f 8f8f e9f7 cb3e 663d 8fe9 427 00000090: f9ec fa12 3066 f368 358c eaef d302 0301 428 000000a0: 0001 430 This will result in the final IKEv2 Certificate Payload: 432 00000000: NN00 00a7 XX30 819f 300d 0609 2a86 4886 433 00000010: f70d 0101 0105 0003 818d 0030 8189 0281 434 00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8 435 00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a 436 00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca 437 00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62 438 00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc 439 00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72 440 00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb 441 00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea 442 000000a0: efd3 0203 0100 01 444 Where NN is the next payload type (i.e., the type of the payload that 445 immediately follows this Certificate payload). 447 Note to the RFC editor / IANA, replace the XX above with the newly 448 allocated Raw Public Key number, and remove this note. 450 Authors' Addresses 452 Tero Kivinen 453 INSIDE Secure 454 Eerikinkatu 28 455 HELSINKI FI-00180 456 FI 458 Email: kivinen@iki.fi 460 Paul Wouters 461 Red Hat 463 Email: pwouters@redhat.com 465 Hannes Tschofenig 467 Email: Hannes.Tschofenig@gmx.net 468 URI: http://www.tschofenig.priv.at