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
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 PayloadSection 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]