idnits 2.17.1 draft-kivinen-ipsecme-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 : ---------------------------------------------------------------------------- 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 18, 2013) is 3842 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) == Outdated reference: A later version (-04) exists of draft-kivinen-ipsecme-ikev2-rfc5996bis-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.kivinen-ipsecme-ikev2-rfc5996bis' ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-09 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Maintenance and Extensions T. Kivinen 3 (ipsecme) INSIDE Secure 4 Internet-Draft P. Wouters 5 Intended status: Standards Track Red Hat 6 Expires: April 21, 2014 H. Tschofenig 7 Nokia Siemens Networks 8 October 18, 2013 10 More Raw Public Keys for IKEv2 11 draft-kivinen-ipsecme-oob-pubkey-05.txt 13 Abstract 15 The Internet Key Exchange Version 2 (IKEv2) protocol currently only 16 supports raw RSA keys. In some environments it is useful to make use 17 of other types of public keys, such as those based on Elliptic Curve 18 Cryptography. This documents adds 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 21, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . 6 65 A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . . 6 66 A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Secure DNS allows public keys to be associated with domain names for 72 usage with security protocols like Internet Key Exchange Version 2 73 (IKEv2) [I-D.kivinen-ipsecme-ikev2-rfc5996bis] and Transport Layer 74 Security (TLS) but it relies on extensions in those protocols to be 75 specified. 77 In [RFC5996] IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a 78 DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other 79 raw public keys types are, however, not supported. In 80 [I-D.kivinen-ipsecme-ikev2-rfc5996bis] this feature was removed, and 81 this document adds support for raw public keys back to IKEv2 in more 82 generic way. 84 The TLS Out-of-Band Public Key Validation specification 85 ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys 86 to TLS by re-using the SubjectPublicKeyInfo format from the X.509 87 Public Key Infrastructure Certificate profile [RFC5280]. 89 This document is similar than the TLS Out-of-Band Public Key 90 Validation specification, and applies the concept to IKEv2 to support 91 all public key formats defined by PKIX. This approach also allows 92 future public key extensions to be supported without the need to 93 introduce further enhancements to IKEv2. 95 To support new types of public keys in IKEv2 the following changes 96 are needed: 98 o A new Certificate Encoding format needs to be defined for carrying 99 the SubjectPublicKeyInfo structure. Section 3 specifies this new 100 encoding format. 101 o A new Certificate Encoding type needs to be allocated from the 102 IANA registry. Section 5 contains this request to IANA. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Certificate Encoding Payload 112 Section 3.6 of RFC 5996bis defines the Certificate payload format as 113 shown in Figure 1. 115 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Next Payload |C| RESERVED | Payload Length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Cert Encoding | | 121 +-+-+-+-+-+-+-+-+ | 122 ~ Certificate Data ~ 123 | | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Figure 1: Certificate Payload Format. 128 o Certificate Encoding (1 octet) - This field indicates the type of 129 certificate or certificate-related information contained in the 130 Certificate Data field. 132 Certificate Encoding Value 133 ---------------------------------------------------- 134 Raw Public Key TBD 136 o Certificate Data (variable length) - Actual encoding of the 137 certificate data. The type of certificate is indicated by the 138 Certificate Encoding field. 140 In order to provide a simple and standard way to indicate the key 141 type when the encoding type is 'Raw Public Key', the 142 SubjectPublicKeyInfo structure of the PKIX certificate is used. This 143 is a a very simple encoding, as most of the ASN.1 part can be 144 included literally, and recognized by block comparison. See 145 [I-D.ietf-tls-oob-pubkey] Appendix A for a detailed breakdown. In 146 addition, Appendix A has a few examples. 148 In the case of the Certificate Request payload the Certification 149 Authority field MUST be empty if the "Raw Public Key" certificate 150 encoding is used. 152 Note, that we do follow public key processing rules of the section 153 1.2 of the Additional Algorithms and Identifiers for RSA Cryptography 154 for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part 155 of the certificate, but sent here. This means RSASSA-PSS and RSASSA- 156 PSS-params inside the SubjectPublicKeyInfo needs to be followed. 158 4. Security Considerations 160 An IKEv2 deployment using raw public keys needs to utilize an out-of- 161 band public key validation procedure to be confident in the 162 authenticity of the keys being used. One such mechanism is to use a 163 configuration mechanism for provisioning raw public keys into the 164 IKEv2 software. A suitable deployment is likely to be found with 165 smart objects. Yet another approach is to rely on secure DNS to 166 associate public keys to be associated with domain names using the 167 IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS- 168 Based Authentication of Named Entities (DANE) [RFC6394]. 170 This document does not change the assumptions made by the IKEv2 171 specifications since "Raw RSA Key" support was already available in 172 IKEv2. This document only generalizes the raw public key support. 174 5. IANA Considerations 176 This document allocates a new value from the IKEv2 Certificate 177 Encodings registry: 179 TBD Raw Public Key 181 6. Acknowledgements 183 This document copies parts from the similar TLS document 184 ([I-D.ietf-tls-oob-pubkey]). 186 7. References 188 7.1. Normative References 190 [I-D.kivinen-ipsecme-ikev2-rfc5996bis] 191 Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 192 Kivinen, "Internet Key Exchange Protocol Version 2 193 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-01 (work 194 in progress), October 2013. 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 200 Housley, R., and W. Polk, "Internet X.509 Public Key 201 Infrastructure Certificate and Certificate Revocation List 202 (CRL) Profile", RFC 5280, May 2008. 204 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 205 "Internet Key Exchange Protocol Version 2 (IKEv2)", 206 RFC 5996, September 2010. 208 7.2. Informative References 210 [I-D.ietf-tls-oob-pubkey] 211 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 212 T. Kivinen, "Out-of-Band Public Key Validation for 213 Transport Layer Security (TLS)", 214 draft-ietf-tls-oob-pubkey-09 (work in progress), 215 July 2013. 217 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 218 Standards (PKCS) #1: RSA Cryptography Specifications 219 Version 2.1", RFC 3447, February 2003. 221 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 222 Material in DNS", RFC 4025, March 2005. 224 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 225 Algorithms and Identifiers for RSA Cryptography for use in 226 the Internet X.509 Public Key Infrastructure Certificate 227 and Certificate Revocation List (CRL) Profile", RFC 4055, 228 June 2005. 230 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 231 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 232 RFC 4754, January 2007. 234 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 235 "Elliptic Curve Cryptography Subject Public Key 236 Information", RFC 5480, March 2009. 238 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 239 Authentication of Named Entities (DANE)", RFC 6394, 240 October 2011. 242 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 243 Obtaining Digital Signatures and Public-Key 244 Cryptosystems", February 1978. 246 Appendix A. Examples 248 This appendix provides examples of the actual packets sent on the 249 wire. 251 A.1. ECDSA Example 253 This first example uses the 256-bit ECDSA private/public key pair 254 defined in the section 8.1. of the IKEv2 ECDSA document [RFC4754]. 256 The public key is as followed: 258 o Algorithm : id-ecPublicKey (1.2.840.10045.2.1) 259 o Fixed curve: secp256r1 (1.2.840.10045.3.1.7) 260 o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707 261 9716cbbf 917dd72e 97566ea1 c066957c 262 o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f 263 dbe71e36 99d91339 afbb903e e17255dc 265 The SubjectPublicKeyInfo ASN.1 object is as follows: 267 0000 : SEQUENCE 268 0002 : SEQUENCE 269 0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1) 270 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 271 0017 : BIT STRING (66 bytes) 272 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 273 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 274 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 275 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 276 00000040: 55dc 278 The first byte (00) of the bit string indicates that there is no 279 "number of unused bits", and the second byte (04) indicates 280 uncompressed form ([RFC5480]). Those two octets are followed by the 281 values of X and Y. 283 The final encoded SubjectPublicKeyInfo object is as follows: 285 00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 286 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 287 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 288 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 289 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 290 00000050: d913 39af bb90 3ee1 7255 dc 292 This will result the final IKEv2 Certificate Payload to be: 294 00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d 295 00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004 296 00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 297 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 298 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 299 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc 301 Where the NN will be the next payload type (i.e. that value depends 302 on what is the next payload after this certificate payload). 304 Note to the RFC editor / IANA, replace the XX above with the newly 305 allocated Raw Public Key number, and remove this note. 307 A.2. RSA Example 309 This second example uses random 1024-bit RSA key. 311 The public key is as followed: 313 o Algorithm : rsaEncryption (1.2.840.113549.1.1.1) 314 o Modulus n (1024 bits, decimal): 315 1323562071162740912417075551025599045700 316 3972512968992059076067098474693867078469 317 7654066339302927451756327389839253751712 318 9485277759962777278073526290329821841100 319 9721044682579432931952695408402169276996 320 5181887843758615443536914372816830537901 321 8976615344413864477626646564638249672329 322 04996914356093900776754835411 323 o Modulus n (1024 bits, hexadecimal): bc7b4347 49c7b386 00bfa84b 324 44f88187 9a2dda08 d1f0145a f5806c2a ed6a6172 ff0dc3d4 cd601638 325 e8ca348e bdca5742 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e 326 aa727c1f 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343 327 fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 66f36835 328 8ceaefd3 329 o Exponent e (17 bits, decimal): 65537 330 o Exponent e (17 bits, hexadecimal): 10001 332 The SubjectPublicKeyInfo ASN.1 object is as follows: 334 0000 : SEQUENCE 335 0003 : SEQUENCE 336 0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1) 337 0016 : NULL 338 0018 : BIT STRING (141 bytes) 339 00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386 340 00000010: 00bf a84b 44f8 8187 9a2d da08 d1f0 145a 341 00000020: f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638 342 00000030: e8ca 348e bdca 5742 31ca dc97 12e2 09b1 343 00000040: fddb a58a 8c62 b369 038a 3d1e aa72 7c1f 344 00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019 345 00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab 346 00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230 347 00000080: 66f3 6835 8cea efd3 0203 0100 01 349 The first byte (00) of the bit string indicates that there is no 350 "number of unused bits". Inside that bit string there is an ASN.1 351 sequence having 2 integers. The second byte (30) indicates that this 352 is beginning of the sequence, and then next byte (81) indicates the 353 length does not fit in 7-bits, but requires one byte, so the length 354 is in the next byte (89). Then starts the first integer with tag 355 (02) and length (81 81). After that we have the modulus (prefixed 356 with 0 so it will not be negative number). After the modulus there 357 is new tag (02) and length (03) of the exponent, and the last 3 bytes 358 are the exponent. 360 The final encoded SubjectPublicKeyInfo object is as follows: 362 00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101 363 00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43 364 00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda 365 00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3 366 00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc 367 00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d 368 00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e 369 00000070: 2338 5a40 1915 858c 59be 72f3 43fb 1eb8 370 00000080: 7b16 ffc5 ab0f 8f8f e9f7 cb3e 663d 8fe9 371 00000090: f9ec fa12 3066 f368 358c eaef d302 0301 372 000000a0: 0001 374 This will result the final IKEv2 Certificate Payload to be: 376 00000000: NN00 00a7 XX30 819f 300d 0609 2a86 4886 377 00000010: f70d 0101 0105 0003 818d 0030 8189 0281 378 00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8 379 00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a 380 00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca 381 00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62 382 00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc 383 00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72 384 00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb 385 00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea 386 000000a0: efd3 0203 0100 01 388 Where the NN will be the next payload type (i.e. that value depends 389 on what is the next payload after this certificate payload). 391 Note to the RFC editor / IANA, replace the XX above with the newly 392 allocated Raw Public Key number, and remove this note. 394 Authors' Addresses 396 Tero Kivinen 397 INSIDE Secure 398 Eerikinkatu 28 399 HELSINKI FI-00180 400 FI 402 Email: kivinen@iki.fi 404 Paul Wouters 405 Red Hat 407 Email: pwouters@redhat.com 409 Hannes Tschofenig 410 Nokia Siemens Networks 411 Linnoitustie 6 412 Espoo 02600 413 Finland 415 Phone: +358 (50) 4871445 416 Email: Hannes.Tschofenig@gmx.net 417 URI: http://www.tschofenig.priv.at