diff options
Diffstat (limited to 'doc/rfc/rfc7670.txt')
| -rw-r--r-- | doc/rfc/rfc7670.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc7670.txt b/doc/rfc/rfc7670.txt new file mode 100644 index 0000000..80ec4c4 --- /dev/null +++ b/doc/rfc/rfc7670.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Kivinen +Request for Comments: 7670 INSIDE Secure +Updates: 7296 P. Wouters +Category: Standards Track Red Hat +ISSN: 2070-1721 H. Tschofenig + January 2016 + + + Generic Raw Public-Key Support for IKEv2 + +Abstract + + The Internet Key Exchange Version 2 (IKEv2) protocol did have support + for raw public keys, but it only supported RSA raw public keys. In + constrained environments, it is useful to make use of other types of + public keys, such as those based on Elliptic Curve Cryptography. + This document updates RFC 7296, adding support for other types of raw + public keys to IKEv2. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7670. + +Copyright Notice + + Copyright (c) 2016 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. + + + + +Kivinen, et al. Standards Track [Page 1] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Certificate Encoding Payload . . . . . . . . . . . . . . . . 3 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 + 6.2. Informative References . . . . . . . . . . . . . . . . . 5 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 + A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . 7 + A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . 8 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + +1. Introduction + + This document replaces an algorithm-specific version of raw public + keys of the Internet Key Exchange Version 2 (IKEv2) [RFC7296] with a + generic version of raw public keys that is algorithm agnostic. + + 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-key types are, however, not supported. In [RFC7296], this + feature was removed; this document reintroduces support for raw + public keys to IKEv2 in a more generic way. + + DNSSEC allows public keys to be associated with domain names for + usage with security protocols like IKEv2 and Transport Layer Security + (TLS) [RFC5246] but it relies on extensions in those protocols to be + specified. + + The Raw Public Keys in Transport Layer Security specification + ([RFC7250]) adds generic support for raw public keys to TLS by + reusing the SubjectPublicKeyInfo format from the X.509 Public-Key + Infrastructure Certificate profile [RFC5280]. + + This document is similar to the Raw Public Keys in Transport Layer + Security 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. + + + + + + + + +Kivinen, et al. Standards Track [Page 2] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + To support new types of public keys in IKEv2, the following changes + are needed: + + o A new Certificate Encoding format needs to be defined for carrying + the SubjectPublicKeyInfo structure. Section 3 specifies this new + encoding format. + + o A new Certificate Encoding that has been allocated by IANA. + Section 5 contains the details about the IANA registration. + + The base IKEv2 specification includes support for RSA and DSA + signatures, but the Signature Authentication in IKEv2 [RFC7427] + extended IKEv2 so that signature methods over any key type can be + used. Implementations using raw public keys SHOULD use the Digital + Signature method described in RFC 7427. + + When using raw public keys, the authenticated identity is not usually + the identity from the ID payload, but instead the public key itself + is used as the identity for the other end. This means that ID + payload contents might not be useful for authentication purposes. It + might still be used for policy decisions, for example to simplify the + policy lookup. Alternatively, the ID_NULL type [RFC7619] can be used + to indicate that the ID payload is not relevant to this + authentication. + +2. Terminology + + 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]. + +3. Certificate Encoding Payload + + Section 3.6 of RFC 7296 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 + + + +Kivinen, et al. Standards Track [Page 3] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + To support raw public keys, the field values are as follows: + + o Certificate Encoding (1 octet) - This field indicates the type of + certificate or certificate-related information contained in the + Certificate Data field. + + Certificate Encoding Value + ---------------------------------------------------- + Raw Public Key 15 + + o Certificate Data (variable length) - Actual encoding of the + certificate data. + + 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 very simple encoding, as most of the ASN.1 part can be included + literally and recognized by block comparison. See Appendix A of + [RFC7250] for a detailed breakdown. In addition, Appendix A of this + document has several examples. + + In addition to the Certificate payload, the Cert Encoding for Raw + Public Key can be used in the Certificate Request payload. In that + case, the Certification Authority field MUST be empty if the "Raw + Public Key" certificate encoding is used. + + For RSA keys, the implementations MUST follow the public-key + processing rules of Section 1.2 of the Additional Algorithms and + Identifiers for RSA Cryptography for PKIX ([RFC4055]) even when the + SubjectPublicKeyInfo is not part of a certificate but is instead sent + as a Certificate Data field. This means that RSASSA-PSS and + RSASSA-PSS-params inside the SubjectPublicKeyInfo structure MUST be + sent when applicable. + +4. Security Considerations + + 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 way to achieve this goal is + to use a configuration mechanism for provisioning raw public keys + into the IKEv2 software. "Smart object" deployments are likely to + use such preconfigured public keys. + + Another approach is to rely on secure DNS to associate public keys + with domain names using the IPSECKEY DNS RRtype [RFC4025]. More + information can be found in DNS-Based Authentication of Named + Entities (DANE) [RFC6394]. + + + + +Kivinen, et al. Standards Track [Page 4] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + This document does not change the security assumptions made by the + IKEv2 specification since "Raw RSA Key" support was already available + in IKEv2 in [RFC5996]. This document only generalizes raw public-key + support. + +5. IANA Considerations + + This document allocates a new value from the IKEv2 Certificate + Encodings registry: + + 15 Raw Public Key + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [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, DOI 10.17487/RFC5280, May 2008, + <http://www.rfc-editor.org/info/rfc5280>. + + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, <http://www.rfc-editor.org/info/rfc7296>. + + [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in + the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, + DOI 10.17487/RFC7427, January 2015, + <http://www.rfc-editor.org/info/rfc7427>. + + [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication + Method in the Internet Key Exchange Protocol Version 2 + (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, + <http://www.rfc-editor.org/info/rfc7619>. + +6.2. Informative References + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February + 2003, <http://www.rfc-editor.org/info/rfc3447>. + + + +Kivinen, et al. Standards Track [Page 5] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March + 2005, <http://www.rfc-editor.org/info/rfc4025>. + + [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional + Algorithms and Identifiers for RSA Cryptography for use in + the Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile", RFC 4055, + DOI 10.17487/RFC4055, June 2005, + <http://www.rfc-editor.org/info/rfc4055>. + + [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using + the Elliptic Curve Digital Signature Algorithm (ECDSA)", + RFC 4754, DOI 10.17487/RFC4754, January 2007, + <http://www.rfc-editor.org/info/rfc4754>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, + "Elliptic Curve Cryptography Subject Public Key + Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, + <http://www.rfc-editor.org/info/rfc5480>. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, DOI 10.17487/RFC5996, September 2010, + <http://www.rfc-editor.org/info/rfc5996>. + + [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based + Authentication of Named Entities (DANE)", RFC 6394, + DOI 10.17487/RFC6394, October 2011, + <http://www.rfc-editor.org/info/rfc6394>. + + [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., + Weiler, S., and T. Kivinen, "Using Raw Public Keys in + Transport Layer Security (TLS) and Datagram Transport + Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, + June 2014, <http://www.rfc-editor.org/info/rfc7250>. + + [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for + Obtaining Digital Signatures and Public-Key + Cryptosystems", February 1978. + + + + + + +Kivinen, et al. Standards Track [Page 6] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + +Appendix A. Examples + + This appendix provides examples of the actual payloads sent on the + wire. + +A.1. ECDSA Example + + This first example uses the 256-bit ECDSA private/public key pair + defined in Section 8.1 of the IKEv2 ECDSA document [RFC4754]. + + The public key is as follows: + + o Algorithm: id-ecPublicKey (1.2.840.10045.2.1) + + o Fixed curve: secp256r1 (1.2.840.10045.3.1.7) + + o Public key x coordinate: + + cb28e099 9b9c7715 fd0a80d8 e47a7707 + 9716cbbf 917dd72e 97566ea1 c066957c + + o Public key y coordinate: + + 2b57c023 5fb74897 68d058ff 4911c20f + dbe71e36 99d91339 afbb903e e17255dc + + The SubjectPublicKeyInfo ASN.1 object is as follows: + + 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 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. + + + + + + + + +Kivinen, et al. Standards Track [Page 7] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + The final encoded SubjectPublicKeyInfo object is as follows: + + 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 + + This will result in the final IKEv2 Certificate Payload: + + 00000000: NN00 0060 0f30 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 + + Where NN is the next payload type (i.e., the type of payload that + immediately follows this Certificate payload). + +A.2. RSA Example + + This second example uses a random 1024-bit RSA key. + + The public key is as follows: + + o Algorithm: rsaEncryption (1.2.840.113549.1.1.1) + + o Modulus n (1024 bits, decimal): + + 1323562071162740912417075551025599045700 + 3972512968992059076067098474693867078469 + 7654066339302927451756327389839253751712 + 9485277759962777278073526290329821841100 + 9721044682579432931952695408402169276996 + 5181887843758615443536914372816830537901 + 8976615344413864477626646564638249672329 + 04996914356093900776754835411 + + o Modulus n (1024 bits, hexadecimal): + + bc7b4347 49c7b386 00bfa84b 44f88187 9a2dda08 d1f0145a + f5806c2a ed6a6172 ff0dc3d4 cd601638 e8ca348e bdca5742 + 31cadc97 12e209b1 fddba58a 8c62b369 038a3d1e aa727c1f + 39ae49ed 6ebc30f8 d9b52e23 385a4019 15858c59 be72f343 + fb1eb87b 16ffc5ab 0f8f8fe9 f7cb3e66 3d8fe9f9 ecfa1230 + 66f36835 8ceaefd3 + + + +Kivinen, et al. Standards Track [Page 8] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + o Exponent e (17 bits, decimal): 65537 + + o Exponent e (17 bits, hexadecimal): 10001 + + The SubjectPublicKeyInfo ASN.1 object is as follows: + + 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 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 the beginning of the sequence, and the 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 a negative number). After the + modulus, there follows the tag (02) and length (03) of the exponent, + and the last 3 bytes are the exponent. + + The final encoded SubjectPublicKeyInfo object is as follows: + + 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 + + + + + + +Kivinen, et al. Standards Track [Page 9] + +RFC 7670 Generic Raw Public-Key Support for IKEv2 January 2016 + + + This will result in the final IKEv2 Certificate Payload: + + 00000000: NN00 00a7 0f30 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 + + Where NN is the next payload type (i.e., the type of the payload that + immediately follows this Certificate payload). + +Acknowledgements + + This document reproduces some parts of the similar TLS document + ([RFC7250]). + +Authors' Addresses + + Tero Kivinen + INSIDE Secure + Eerikinkatu 28 + Helsinki FI-00180 + Finland + + Email: kivinen@iki.fi + + + Paul Wouters + Red Hat + + Email: pwouters@redhat.com + + + Hannes Tschofenig + + Email: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + + + + + + +Kivinen, et al. Standards Track [Page 10] + |