idnits 2.17.1 draft-kivinen-ipsecme-oob-pubkey-01.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, 2012) is 4202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-04 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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) AuthenTec 4 Internet-Draft P. Wouters 5 Intended status: Informational Red Hat 6 Expires: April 19, 2013 H. Tschofenig 7 Nokia Siemens Networks 8 October 16, 2012 10 More Raw Public Keys for IKEv2 11 draft-kivinen-ipsecme-oob-pubkey-01.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 19, 2013. 38 Copyright Notice 40 Copyright (c) 2012 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. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3 57 3. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Secure DNS allows public keys to be associated with domain names for 70 usage with security protocols like Internet Key Exchange Version 2 71 (IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on 72 extensions in those protocols to be specified. 74 IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a 75 DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other 76 raw public keys types are, however, not supported. 78 The TLS Out-of-Band Public Key Validation specification 79 ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys 80 to TLS by re-using the SubjectPublicKeyInfo format from the X.509 81 Public Key Infrastructure Certificate profile [RFC5280]. 83 This document is similar than the TLS Out-of-Band Public Key 84 Validation specification, and applies the concept to IKEv2 to support 85 all public key formats defined by PKIX. This approach also allows 86 future public key extensions to be supported without the need to 87 introduce further enhancements to IKEv2. 89 To support new types of public keys in IKEv2 the following changes 90 are needed: 92 o A new Certificate Encoding format needs to be defined for carrying 93 the SubjectPublicKeyInfo structure. Section 2 specifies this new 94 encoding format. 95 o A new Certificate Encoding type needs to be allocated from the 96 IANA registry. Section 5 contains this request to IANA. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Certificate Encoding Payload 104 Section 3.6 of RFC 5996 defines the Certificate payload format as 105 shown in Figure 1. 107 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Next Payload |C| RESERVED | Payload Length | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Cert Encoding | | 113 +-+-+-+-+-+-+-+-+ | 114 ~ Certificate Data ~ 115 | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1: Certificate Payload Format 120 o Certificate Encoding (1 octet) - This field indicates the type of 121 certificate or certificate-related information contained in the 122 Certificate Data field. 124 Certificate Encoding Value 125 ---------------------------------------------------- 126 Raw Public Key TBD 128 o Certificate Data (variable length) - Actual encoding of the 129 certificate data. The type of certificate is indicated by the 130 Certificate Encoding field. 132 When the certificate encoding type 'Raw Public Key' is used then the 133 Certificate Data only contains the SubjectPublicKeyInfo part of the 134 PKIX certificate. 136 In the case of the Certificate Request payload the Certification 137 Authority field MUST be empty if the "Raw Public Key" certificate 138 encoding is used. 140 3. Old Raw RSA Key Certificate Type 142 After this there are two ways of sending Raw RSA public keys in the 143 IKEv2: The already existing mechanism (Raw RSA Key, encoding value 144 11), and the new format defined here. The IKEv2 protocol already 145 supports a method to indicate what certificate encoding formats are 146 supported, i.e. a peer can send one or multiple Certificate Request 147 payload with the certificate encoding types it supports. From this 148 list the recipient can see what formats are supported and select one 149 which is used to send Certificate back. 151 If the peer has non-RSA raw public key, it has no other option than 152 to use the new format. If it has RSA raw public key, it can either 153 use the old format or the new format, and it SHOULD indicate support 154 for both by sending both certificate encoding types inside 155 Certificate Request payloads. 157 If a peer receives both old and new certificate encoding formats in 158 the Certificate Request payloads, it is RECOMMENDED for 159 implementations to prefer new format defined in this document, so the 160 old Raw RSA public key format could possibly be phased out in the 161 future. 163 To better support minimal implementations, it would be best to limit 164 the code complexity of those versions, and such implementations might 165 choose to implement only the new format, which supports all types of 166 raw public keys. 168 4. Security Considerations 170 An IKEv2 deployment using raw public keys needs to utilize an out-of- 171 band public key validation procedure to be confident in the 172 authenticity of the keys being used. One such mechanism is to use a 173 configuration mechanism for provisioning raw public keys into the 174 IKEv2 software. A suitable deployment is likely to be found with 175 smart objects. Yet another approach is to rely on secure DNS to 176 associate public keys to be associated with domain names using the 177 IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS- 178 Based Authentication of Named Entities (DANE) [RFC6394]. 180 This document does not change the assumptions made by the IKEv2 181 specifications since "Raw RSA Key" support is already available in 182 IKEv2. This document only generalizes the raw public key support. 184 5. IANA Considerations 186 This document allocates a new value from the IKEv2 Certificate 187 Encodings registry: 189 TBD Raw Public Key 191 6. Acknowledgements 193 This document copies parts from the similar TLS document 194 ([I-D.ietf-tls-oob-pubkey]). 196 7. References 197 7.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 203 Housley, R., and W. Polk, "Internet X.509 Public Key 204 Infrastructure Certificate and Certificate Revocation List 205 (CRL) Profile", RFC 5280, May 2008. 207 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 208 "Internet Key Exchange Protocol Version 2 (IKEv2)", 209 RFC 5996, September 2010. 211 7.2. Informative References 213 [I-D.ietf-tls-oob-pubkey] 214 Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. 215 Tschofenig, "Out-of-Band Public Key Validation for 216 Transport Layer Security", draft-ietf-tls-oob-pubkey-04 217 (work in progress), July 2012. 219 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 220 Standards (PKCS) #1: RSA Cryptography Specifications 221 Version 2.1", RFC 3447, February 2003. 223 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 224 Material in DNS", RFC 4025, March 2005. 226 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 227 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 228 RFC 4754, January 2007. 230 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 231 Authentication of Named Entities (DANE)", RFC 6394, 232 October 2011. 234 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 235 Obtaining Digital Signatures and Public-Key 236 Cryptosystems", February 1978. 238 Appendix A. Examples 240 This appendix provides examples of the actual packets sent on the 241 wire. This uses the 256-bit ECDSA private/public key pair defined in 242 the section 8.1. of the IKEv2 ECDSA document [RFC4754]. 244 The public key is as followed: 246 o Algorithm : id-ecPublicKey (1.2.840.10045.2.1) 247 o Fixed curve: secp256r1 (1.2.840.10045.3.1.7) 248 o Public key x coordinate : cb28e099 9b9c7715 fd0a80d8 e47a7707 249 9716cbbf 917dd72e 97566ea1 c066957c 250 o Public key y coordinate : 2b57c023 5fb74897 68d058ff 4911c20f 251 dbe71e36 99d91339 afbb903e e17255dc 253 The SubjectPublicKeyInfo ASN.1 object is as follows: 255 0000 : SEQUENCE 256 0002 : SEQUENCE 257 0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1) 258 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 259 0017 : BIT STRING (66 bytes) 260 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 261 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 262 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 263 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 264 00000040: 55dc 266 The first byte (00) of the bit string indicates that there is no 267 "number of unused bits", and the second byte (04) indicates 268 uncompressed form. Those two octets are followed by the values of X 269 and Y. 271 The final encoded SubjectPublicKeyInfo object is as follows: 273 00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 274 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 275 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 276 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 277 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 278 00000050: d913 39af bb90 3ee1 7255 dc 280 This will result the final IKEv2 Certificate Payload to be: 282 00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d 283 00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004 284 00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 285 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 286 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 287 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc 289 Where the NN will be the next payload type (i.e. that value depends 290 on what is the next payload after this certificate payload). 292 Note to the RFC editor / IANA, replace the XX above with the newly 293 allocated Raw Public Key number, and remove this note. 295 Authors' Addresses 297 Tero Kivinen 298 AuthenTec 299 Eerikinkatu 28 300 HELSINKI FI-00180 301 FI 303 Email: kivinen@iki.fi 305 Paul Wouters 306 Red Hat 308 Email: pwouters@redhat.com 310 Hannes Tschofenig 311 Nokia Siemens Networks 312 Linnoitustie 6 313 Espoo 02600 314 Finland 316 Phone: +358 (50) 4871445 317 Email: Hannes.Tschofenig@gmx.net 318 URI: http://www.tschofenig.priv.at