Generic Raw Public-Key Support for IKEv2
updates
- rfc-7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (15)
RFC 5996 supported only PKCS #1 encoded RSA raw public keys in IKEv2; RFC 7296 removed that support entirely. This document reintroduces raw public keys in a generic, algorithm-agnostic form using the SubjectPublicKeyInfo structure from PKIX so that all current and future public-key types (e.g., ECDSA) are automatically supported without further IKEv2 changes.
The SubjectPublicKeyInfo format from RFC 5280 (X.509 PKIX) is reused for carrying raw public keys, mirroring the approach taken by RFC 7250 for TLS. This provides a simple, standard way to indicate key type using existing ASN.1 structures that can be recognized by block comparison.
When using raw public keys in IKEv2, the authenticated identity is typically the public key itself rather than the ID payload contents. The ID payload may still be used for policy lookup, or ID_NULL (RFC 7619) may be used to signal it is not relevant to authentication.
RFC 5996 supported PKCS #1 RSA raw public keys in IKEv2; RFC 7296 removed this feature. Implementations that previously relied on the RFC 5996 RSA raw key encoding must migrate to the new SubjectPublicKeyInfo-based encoding (value 15) defined here.
The base IKEv2 specification (RFC 7296) includes support for RSA and DSA signatures, but RFC 7427 extended IKEv2 to allow signature methods over any key type. Raw public key users should ensure they negotiate the RFC 7427 Digital Signature method for compatibility with non-RSA/DSA key types.
For RSA keys, implementations MUST follow the public-key processing rules of RFC 4055 Section 1.2 even when SubjectPublicKeyInfo is sent as Certificate Data rather than within a full certificate. RSASSA-PSS and RSASSA-PSS-params inside the SubjectPublicKeyInfo MUST be sent when applicable.
Implementations using raw public keys in IKEv2 SHOULD use the Digital Signature authentication method described in RFC 7427, which supports signature methods over any key type.
When the 'Raw Public Key' certificate encoding is used in a Certificate Request payload, the Certification Authority field MUST be empty.
A new Certificate Encoding value of 15 ('Raw Public Key') is defined for the IKEv2 Certificate payload. The Certificate Data field carries a SubjectPublicKeyInfo ASN.1 structure encoding the raw public key.
IANA allocated value 15 ('Raw Public Key') in the IKEv2 Certificate Encodings registry. This is the only registry action performed by this document.
IKEv2 deployments using raw public keys must use an out-of-band public-key validation procedure to ensure key authenticity. Recommended approaches include pre-configuration (e.g., 'smart object' deployments) or secure DNS using the IPSECKEY DNS RR type (RFC 4025) combined with DANE (RFC 6394).
This document does not change the security assumptions of the IKEv2 specification, since 'Raw RSA Key' support was already present in RFC 5996. The change is a generalization of existing raw public-key support to additional key types, not a new security model.
For ECDSA keys, the SubjectPublicKeyInfo BIT STRING begins with 0x00 (no unused bits) followed by 0x04 (uncompressed point format per RFC 5480), then the X and Y coordinates. The full SubjectPublicKeyInfo includes OIDs for id-ecPublicKey and the named curve.
For RSA keys, the SubjectPublicKeyInfo BIT STRING begins with 0x00 (no unused bits), followed by an ASN.1 SEQUENCE containing two INTEGERs: the modulus (prefixed with 0x00 to avoid sign ambiguity) and the public exponent. The OID rsaEncryption (1.2.840.113549.1.1.1) with NULL parameters precedes the BIT STRING.
The IKEv2 Certificate payload (from RFC 7296 Section 3.6) carries a 1-octet Cert Encoding field set to 15 for Raw Public Key, followed by a variable-length Certificate Data field containing the DER-encoded SubjectPublicKeyInfo structure. For example, a 256-bit ECDSA key produces a 91-byte SubjectPublicKeyInfo and a 96-byte Certificate payload.