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