| IP Security Maintenance and Extensions (ipsecme) | T. Kivinen |
| Internet-Draft | INSIDE Secure |
| Intended status: Standards Track | P. Wouters |
| Expires: November 07, 2014 | Red Hat |
| H. Tschofenig | |
| May 06, 2014 |
More Raw Public Keys for IKEv2
draft-kivinen-ipsecme-oob-pubkey-07.txt
The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 07, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Secure DNS allows public keys to be associated with domain names for usage with security protocols like Internet Key Exchange Version 2 (IKEv2) [I-D.kivinen-ipsecme-ikev2-rfc5996bis] and Transport Layer Security (TLS) but it relies on extensions in those protocols to be specified.
In [RFC5996] IKEv2 had support for PKCS #1 encoded RSA keys, i.e., a DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other raw public keys types are, however, not supported. In [I-D.kivinen-ipsecme-ikev2-rfc5996bis] this feature was removed, and this document adds support for raw public keys back to IKEv2 in more generic way.
The TLS Out-of-Band Public Key Validation specification ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys to TLS by re-using the SubjectPublicKeyInfo format from the X.509 Public Key Infrastructure Certificate profile [RFC5280].
This document is similar than the TLS Out-of-Band Public Key Validation specification, and applies the concept to IKEv2 to support all public key formats defined by PKIX. This approach also allows future public key extensions to be supported without the need to introduce further enhancements to IKEv2.
To support new types of public keys in IKEv2 the following changes are needed:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Section 3.6 of RFC 5996bis defines the Certificate payload format as shown in Figure 1.
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | |
+-+-+-+-+-+-+-+-+ |
~ Certificate Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Certificate Payload Format.
Certificate Encoding Value ---------------------------------------------------- Raw Public Key TBD
In order to provide a simple and standard way to indicate the key type when the encoding type is 'Raw Public Key', the SubjectPublicKeyInfo structure of the PKIX certificate is used. This is a a very simple encoding, as most of the ASN.1 part can be included literally, and recognized by block comparison. See [I-D.ietf-tls-oob-pubkey] Appendix A for a detailed breakdown. In addition, Appendix A has a few examples.
In the case of the Certificate Request payload the Certification Authority field MUST be empty if the "Raw Public Key" certificate encoding is used.
Note, that we do follow public key processing rules of the section 1.2 of the Additional Algorithms and Identifiers for RSA Cryptography for PKIX ([RFC4055]) even when the SubjectPublicKeyInfo is not part of the certificate, but sent here. This means RSASSA-PSS and RSASSA-PSS-params inside the SubjectPublicKeyInfo needs to be followed.
An IKEv2 deployment using raw public keys needs to utilize an out-of-band public key validation procedure to be confident in the authenticity of the keys being used. One such mechanism is to use a configuration mechanism for provisioning raw public keys into the IKEv2 software. A suitable deployment is likely to be found with smart objects. Yet another approach is to rely on secure DNS to associate public keys to be associated with domain names using the IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-Based Authentication of Named Entities (DANE) [RFC6394].
This document does not change the assumptions made by the IKEv2 specifications since "Raw RSA Key" support was already available in IKEv2. This document only generalizes the raw public key support.
This document allocates a new value from the IKEv2 Certificate Encodings registry:
TBD Raw Public Key
This document copies parts from the similar TLS document ([I-D.ietf-tls-oob-pubkey]).
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. |
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [I-D.kivinen-ipsecme-ikev2-rfc5996bis] | Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", Internet-Draft draft-kivinen-ipsecme-ikev2-rfc5996bis-01, October 2013. |
This appendix provides examples of the actual packets sent on the wire.
This first example uses the 256-bit ECDSA private/public key pair defined in the section 8.1. of the IKEv2 ECDSA document [RFC4754].
The public key is as followed:
0000 : SEQUENCE 0002 : SEQUENCE 0004 : OBJECT IDENTIFIER id-ecPublicKey (1.2.840.10045.2.1) 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 0017 : BIT STRING (66 bytes) 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 00000040: 55dc
The SubjectPublicKeyInfo ASN.1 object is as follows:
The first byte (00) of the bit string indicates that there is no "number of unused bits", and the second byte (04) indicates uncompressed form ([RFC5480]). Those two octets are followed by the values of X and Y.
00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 00000050: d913 39af bb90 3ee1 7255 dc
The final encoded SubjectPublicKeyInfo object is as follows:
00000000: NN00 0060 XX30 5930 1306 072a 8648 ce3d 00000010: 0201 0608 2a86 48ce 3d03 0107 0342 0004 00000020: cb28 e099 9b9c 7715 fd0a 80d8 e47a 7707 00000030: 9716 cbbf 917d d72e 9756 6ea1 c066 957c 00000040: 2b57 c023 5fb7 4897 68d0 58ff 4911 c20f 00000050: dbe7 1e36 99d9 1339 afbb 903e e172 55dc
This will result the final IKEv2 Certificate Payload to be:
Where the NN will be the next payload type (i.e. that value depends on what is the next payload after this certificate payload).
Note to the RFC editor / IANA, replace the XX above with the newly allocated Raw Public Key number, and remove this note.
This second example uses random 1024-bit RSA key.
The public key is as followed:
0000 : SEQUENCE 0003 : SEQUENCE 0005 : OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1) 0016 : NULL 0018 : BIT STRING (141 bytes) 00000000: 0030 8189 0281 8100 bc7b 4347 49c7 b386 00000010: 00bf a84b 44f8 8187 9a2d da08 d1f0 145a 00000020: f580 6c2a ed6a 6172 ff0d c3d4 cd60 1638 00000030: e8ca 348e bdca 5742 31ca dc97 12e2 09b1 00000040: fddb a58a 8c62 b369 038a 3d1e aa72 7c1f 00000050: 39ae 49ed 6ebc 30f8 d9b5 2e23 385a 4019 00000060: 1585 8c59 be72 f343 fb1e b87b 16ff c5ab 00000070: 0f8f 8fe9 f7cb 3e66 3d8f e9f9 ecfa 1230 00000080: 66f3 6835 8cea efd3 0203 0100 01
The SubjectPublicKeyInfo ASN.1 object is as follows:
The first byte (00) of the bit string indicates that there is no "number of unused bits". Inside that bit string there is an ASN.1 sequence having 2 integers. The second byte (30) indicates that this is beginning of the sequence, and then next byte (81) indicates the length does not fit in 7-bits, but requires one byte, so the length is in the next byte (89). Then starts the first integer with tag (02) and length (81 81). After that we have the modulus (prefixed with 0 so it will not be negative number). After the modulus there is new tag (02) and length (03) of the exponent, and the last 3 bytes are the exponent.
00000000: 3081 9f30 0d06 092a 8648 86f7 0d01 0101 00000010: 0500 0381 8d00 3081 8902 8181 00bc 7b43 00000020: 4749 c7b3 8600 bfa8 4b44 f881 879a 2dda 00000030: 08d1 f014 5af5 806c 2aed 6a61 72ff 0dc3 00000040: d4cd 6016 38e8 ca34 8ebd ca57 4231 cadc 00000050: 9712 e209 b1fd dba5 8a8c 62b3 6903 8a3d 00000060: 1eaa 727c 1f39 ae49 ed6e bc30 f8d9 b52e 00000070: 2338 5a40 1915 858c 59be 72f3 43fb 1eb8 00000080: 7b16 ffc5 ab0f 8f8f e9f7 cb3e 663d 8fe9 00000090: f9ec fa12 3066 f368 358c eaef d302 0301 000000a0: 0001
The final encoded SubjectPublicKeyInfo object is as follows:
00000000: NN00 00a7 XX30 819f 300d 0609 2a86 4886 00000010: f70d 0101 0105 0003 818d 0030 8189 0281 00000020: 8100 bc7b 4347 49c7 b386 00bf a84b 44f8 00000030: 8187 9a2d da08 d1f0 145a f580 6c2a ed6a 00000040: 6172 ff0d c3d4 cd60 1638 e8ca 348e bdca 00000050: 5742 31ca dc97 12e2 09b1 fddb a58a 8c62 00000060: b369 038a 3d1e aa72 7c1f 39ae 49ed 6ebc 00000070: 30f8 d9b5 2e23 385a 4019 1585 8c59 be72 00000080: f343 fb1e b87b 16ff c5ab 0f8f 8fe9 f7cb 00000090: 3e66 3d8f e9f9 ecfa 1230 66f3 6835 8cea 000000a0: efd3 0203 0100 01
This will result the final IKEv2 Certificate Payload to be:
Where the NN will be the next payload type (i.e. that value depends on what is the next payload after this certificate payload).
Note to the RFC editor / IANA, replace the XX above with the newly allocated Raw Public Key number, and remove this note.