idnits 2.17.1 draft-kivinen-ipsecme-oob-pubkey-04.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5996, 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 (Using the creation date from RFC5996, updated by this document, for RFC5378 checks: 2008-08-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 30, 2013) is 3921 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 normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-08 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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 Updates: RFC 5996 (if approved) Red Hat 6 Intended status: Standards Track H. Tschofenig 7 Expires: January 31, 2014 Nokia Siemens Networks 8 July 30, 2013 10 More Raw Public Keys for IKEv2 11 draft-kivinen-ipsecme-oob-pubkey-04.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 and obsoletes the old raw RSA key format. 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 January 31, 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. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Secure DNS allows public keys to be associated with domain names for 71 usage with security protocols like Internet Key Exchange Version 2 72 (IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on 73 extensions in those protocols to be specified. 75 IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a 76 DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other 77 raw public keys types are, however, not supported. 79 The TLS Out-of-Band Public Key Validation specification 80 ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys 81 to TLS by re-using the SubjectPublicKeyInfo format from the X.509 82 Public Key Infrastructure Certificate profile [RFC5280]. 84 This document is similar than the TLS Out-of-Band Public Key 85 Validation specification, and applies the concept to IKEv2 to support 86 all public key formats defined by PKIX. This approach also allows 87 future public key extensions to be supported without the need to 88 introduce further enhancements to IKEv2. 90 To support new types of public keys in IKEv2 the following changes 91 are needed: 93 o A new Certificate Encoding format needs to be defined for carrying 94 the SubjectPublicKeyInfo structure. Section 3 specifies this new 95 encoding format. 96 o A new Certificate Encoding type needs to be allocated from the 97 IANA registry. Section 6 contains this request to IANA. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. Certificate Encoding Payload 107 Section 3.6 of RFC 5996 defines the Certificate payload format as 108 shown in Figure 1. 110 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Next Payload |C| RESERVED | Payload Length | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Cert Encoding | | 116 +-+-+-+-+-+-+-+-+ | 117 ~ Certificate Data ~ 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Figure 1: Certificate Payload Format. 123 o Certificate Encoding (1 octet) - This field indicates the type of 124 certificate or certificate-related information contained in the 125 Certificate Data field. 127 Certificate Encoding Value 128 ---------------------------------------------------- 129 Raw Public Key TBD 131 o Certificate Data (variable length) - Actual encoding of the 132 certificate data. The type of certificate is indicated by the 133 Certificate Encoding field. 135 When the certificate encoding type 'Raw Public Key' is used then the 136 Certificate Data only contains the SubjectPublicKeyInfo part of the 137 PKIX certificate. 139 In the case of the Certificate Request payload the Certification 140 Authority field MUST be empty if the "Raw Public Key" certificate 141 encoding is used. 143 Note, that we do follow public key processing rules of the section 144 1.2 of the Additional Algorithms and Identifiers for RSA Cryptography 145 for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part 146 of the certificate, but sent here. This means RSASSA-PSS and RSASSA- 147 PSS-params inside the SubjectPublicKeyInfo needs to be followed. 149 4. Old Raw RSA Key Certificate Type 151 After this there would be two ways of sending Raw RSA public keys in 152 the IKEv2: The original IKEv2 mechanism (Raw RSA Key, encoding value 153 11), and the new format defined here. The old Raw RSA Key encoding 154 has not been widely used. The IKEv2 protocol already supports a 155 method to indicate what certificate encoding formats are supported, 156 i.e. a peer can send one or multiple Certificate Request payload with 157 the certificate encoding types it supports. From this list the 158 recipient can see what formats are supported and select one which is 159 used to send Certificate back. 161 Implementations conforming to this document MUST use the new format 162 defined here for the raw public keys, regardless of the key type. 163 This means that old Raw RSA Key encoding value 11 MUST NOT be used 164 for certificate or certificate request payloads. 166 Note, that recipients can simply process the old Raw RSA key 167 encodings just like any other unsupported or unknown certificate 168 encoding type, i.e. skip over it, recipients MUST NOT consider 169 receiving such payloads as fatal error (if other end sends such 170 payloads, it is completely possible that the peers do not have common 171 format for certificate encoding and the authentication will fail 172 because of that). 174 5. Security Considerations 176 An IKEv2 deployment using raw public keys needs to utilize an out-of- 177 band public key validation procedure to be confident in the 178 authenticity of the keys being used. One such mechanism is to use a 179 configuration mechanism for provisioning raw public keys into the 180 IKEv2 software. A suitable deployment is likely to be found with 181 smart objects. Yet another approach is to rely on secure DNS to 182 associate public keys to be associated with domain names using the 183 IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS- 184 Based Authentication of Named Entities (DANE) [RFC6394]. 186 This document does not change the assumptions made by the IKEv2 187 specifications since "Raw RSA Key" support is already available in 188 IKEv2. This document only generalizes the raw public key support and 189 obsoletes the old "Raw RSA Key" format. 191 6. IANA Considerations 193 This document allocates a new value from the IKEv2 Certificate 194 Encodings registry: 196 TBD Raw Public Key 198 This document also obsoletes the old value in the same registry, and 199 the entry for "Raw RSA Key" should be changed to: 201 11 Obsoleted (was Raw RSA Key) 203 7. Acknowledgements 205 This document copies parts from the similar TLS document 206 ([I-D.ietf-tls-oob-pubkey]). 208 8. References 210 8.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 216 Housley, R., and W. Polk, "Internet X.509 Public Key 217 Infrastructure Certificate and Certificate Revocation List 218 (CRL) Profile", RFC 5280, May 2008. 220 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 221 "Internet Key Exchange Protocol Version 2 (IKEv2)", 222 RFC 5996, September 2010. 224 8.2. Informative References 226 [I-D.ietf-tls-oob-pubkey] 227 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 228 T. Kivinen, "Out-of-Band Public Key Validation for 229 Transport Layer Security (TLS)", 230 draft-ietf-tls-oob-pubkey-08 (work in progress), 231 July 2013. 233 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 234 Standards (PKCS) #1: RSA Cryptography Specifications 235 Version 2.1", RFC 3447, February 2003. 237 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 238 Material in DNS", RFC 4025, March 2005. 240 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 241 Algorithms and Identifiers for RSA Cryptography for use in 242 the Internet X.509 Public Key Infrastructure Certificate 243 and Certificate Revocation List (CRL) Profile", RFC 4055, 244 June 2005. 246 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 247 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 248 RFC 4754, January 2007. 250 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 251 "Elliptic Curve Cryptography Subject Public Key 252 Information", RFC 5480, March 2009. 254 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 255 Authentication of Named Entities (DANE)", RFC 6394, 256 October 2011. 258 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 259 Obtaining Digital Signatures and Public-Key 260 Cryptosystems", February 1978. 262 Appendix A. Examples 264 This appendix provides examples of the actual packets sent on the 265 wire. This uses the 256-bit ECDSA private/public key pair defined in 266 the section 8.1. of the IKEv2 ECDSA document [RFC4754]. 268 The public key is as followed: 270 o Algorithm : id-ecPublicKey (1.2.840.10045.2.1) 271 o Fixed curve: secp256r1 (1.2.840.10045.3.1.7) 272 o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707 273 9716cbbf 917dd72e 97566ea1 c066957c 274 o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f 275 dbe71e36 99d91339 afbb903e e17255dc 277 The SubjectPublicKeyInfo ASN.1 object is as follows: 279 0000 : SEQUENCE 280 0002 : SEQUENCE 281 0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1) 282 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 283 0017 : BIT STRING (66 bytes) 284 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 285 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 286 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 287 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 288 00000040: 55dc 290 The first byte (00) of the bit string indicates that there is no 291 "number of unused bits", and the second byte (04) indicates 292 uncompressed form ([RFC5480]). Those two octets are followed by the 293 values of X and Y. 295 The final encoded SubjectPublicKeyInfo object is as follows: 297 00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 298 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 299 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 300 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 301 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 302 00000050: d913 39af bb90 3ee1 7255 dc 304 This will result the final IKEv2 Certificate Payload to be: 306 00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d 307 00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004 308 00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 309 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 310 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 311 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc 313 Where the NN will be the next payload type (i.e. that value depends 314 on what is the next payload after this certificate payload). 316 Note to the RFC editor / IANA, replace the XX above with the newly 317 allocated Raw Public Key number, and remove this note. 319 Authors' Addresses 321 Tero Kivinen 322 INSIDE Secure 323 Eerikinkatu 28 324 HELSINKI FI-00180 325 FI 327 Email: kivinen@iki.fi 329 Paul Wouters 330 Red Hat 332 Email: pwouters@redhat.com 333 Hannes Tschofenig 334 Nokia Siemens Networks 335 Linnoitustie 6 336 Espoo 02600 337 Finland 339 Phone: +358 (50) 4871445 340 Email: Hannes.Tschofenig@gmx.net 341 URI: http://www.tschofenig.priv.at