idnits 2.17.1 draft-kivinen-ipsecme-oob-pubkey-00.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 (March 5, 2012) is 4434 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-01 -- 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: September 6, 2012 H. Tschofenig 7 Nokia Siemens Networks 8 March 5, 2012 10 More Raw Public Keys for IKEv2 11 draft-kivinen-ipsecme-oob-pubkey-00.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 September 6, 2012. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Secure DNS allows public keys to be associated with domain names for 69 usage with security protocols like Internet Key Exchange Version 2 70 (IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on 71 extensions in those protocols to be specified. 73 IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a 74 DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other 75 raw public keys types are, however, not supported. 77 The TLS Out-of-Band Public Key Validation specification 78 ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys 79 to TLS by re-using the SubjectPublicKeyInfo format from the X.509 80 Public Key Infrastructure Certificate profile [RFC5280]. 82 This document is similar than the TLS Out-of-Band Public Key 83 Validation specification, and applies the concept to IKEv2 to support 84 all public key formats defined by PKIX. This approach also allows 85 future public key extensions to be supported without the need to 86 introduce further enhancements to IKEv2. 88 To support new types of public keys in IKEv2 the following changes 89 are needed: 91 o A new Certificate Encoding format needs to be defined for carrying 92 the SubjectPublicKeyInfo structure. Section 2 specifies this new 93 encoding format. 94 o A new Certificate Encoding type needs to be allocated from the 95 IANA registry. Section 5 contains this request to IANA. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Certificate Encoding Payload 103 Section 3.6 of RFC 5996 defines the Certificate payload format as 104 shown in Figure 1. 106 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Next Payload |C| RESERVED | Payload Length | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Cert Encoding | | 112 +-+-+-+-+-+-+-+-+ | 113 ~ Certificate Data ~ 114 | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 Figure 1: Certificate Payload Format 119 o Certificate Encoding (1 octet) - This field indicates the type of 120 certificate or certificate-related information contained in the 121 Certificate Data field. 123 Certificate Encoding Value 124 ---------------------------------------------------- 125 Raw Public Key TBD 127 o Certificate Data (variable length) - Actual encoding of the 128 certificate data. The type of certificate is indicated by the 129 Certificate Encoding field. 131 When the certificate encoding type 'Raw Public Key' is used then the 132 Certificate Data only contains the SubjectPublicKeyInfo part of the 133 PKIX certificate. 135 In the case of the Certificate Request payload the Certification 136 Authority field MUST be empty if the "Raw Public Key" certificate 137 encoding is used. 139 3. Old Raw RSA Key Certificate Type 141 After this there are two ways of sending Raw RSA public keys in the 142 IKEv2: The already existing mechanisms, and the new format defined 143 here. The IKEv2 protocol already supports a method to indicate which 144 certificate encoding formats are supported, i.e. a peer can send one 145 or multiple Certificate Request payload with the certificate encoding 146 types it supports. From this list the recipient can see which 147 formats are supported and select one which is used to send 148 Certificate back. 150 If the peer has raw non-RSA public key, it has no other option than 151 to use the new format. If it has raw RSA public key, it can either 152 use the old format or the new format, and it SHOULD indicate support 153 for both by sending both certificate encoding types inside 154 Certificate Request payloads. 156 If a peer receives both old and new certificate endocing formats in 157 the Certificate Request payloads, it is RECOMMENDED for new 158 implementations to prefer this new format defined in this document, 159 so the old Raw RSA public key format could possibly be phased out in 160 the future. 162 To better support minimal implementations, it would be best to limit 163 the code complexity of those versions, and in such implementations it 164 might be better to implement only the new format as it supports all 165 types of raw public keys. 167 4. Security Considerations 169 An IKEv2 deployment using raw public keys needs to utilize an out-of- 170 band public key validation procedure to be confident in the 171 authenticity of the keys being used. One such mechanism is to use a 172 configuration mechanism for provisioning raw public keys into the 173 IKEv2 software. A suitable deployment is likely to be found with 174 smart objects. Yet another approach is to rely on secure DNS to 175 associate public keys to be associated with domain names. More 176 information can be found in DNS-Based Authentication of Named 177 Entitites (DANE) [RFC6394]. 179 This document does not change the assumptions made by the IKEv2 180 specifications since "Raw RSA Key" support is already available in 181 IKEv2. This document only generalizes the raw public key support. 183 5. IANA Considerations 185 This document allocates a new value from the IKEv2 Certificate 186 Encodings registry: 188 TBD Raw Public Key 190 6. Acknowledgements 192 This document copies parts from the similar TLS document 193 ([I-D.ietf-tls-oob-pubkey]). 195 7. References 196 7.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 202 Housley, R., and W. Polk, "Internet X.509 Public Key 203 Infrastructure Certificate and Certificate Revocation List 204 (CRL) Profile", RFC 5280, May 2008. 206 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 207 "Internet Key Exchange Protocol Version 2 (IKEv2)", 208 RFC 5996, September 2010. 210 7.2. Informative References 212 [I-D.ietf-tls-oob-pubkey] 213 Tschofenig, H., Gilmore, J., Wouters, P., Weiler, S., and 214 T. Kivinen, "TLS Out-of-Band Public Key Validation", 215 draft-ietf-tls-oob-pubkey-01 (work in progress), 216 January 2012. 218 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 219 Standards (PKCS) #1: RSA Cryptography Specifications 220 Version 2.1", RFC 3447, February 2003. 222 [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based 223 Authentication of Named Entities (DANE)", RFC 6394, 224 October 2011. 226 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 227 Obtaining Digital Signatures and Public-Key 228 Cryptosystems", February 1978. 230 Authors' Addresses 232 Tero Kivinen 233 AuthenTec 234 Eerikinkatu 28 235 HELSINKI FI-00180 236 FI 238 Email: kivinen@iki.fi 239 Paul Wouters 240 Red Hat 242 Email: pwouters@redhat.com 244 Hannes Tschofenig 245 Nokia Siemens Networks 246 Linnoitustie 6 247 Espoo 02600 248 Finland 250 Phone: +358 (50) 4871445 251 Email: Hannes.Tschofenig@gmx.net 252 URI: http://www.tschofenig.priv.at