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
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.
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].
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.
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.
[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>.
[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>.
[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
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:
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: