Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (26)
IKEv2 does not include a mechanism to negotiate authentication methods, unlike IKEv1. This causes SA establishment failures when peers have multiple credentials of different types and the other side only supports some of them. SUPPORTED_AUTH_METHODS is introduced to resolve this ambiguity by allowing peers to advertise their capabilities.
Post-quantum and hybrid signature schemes (e.g., composite signatures) motivated this extension, as they introduce additional complexity in selecting compatible authentication algorithms when multiple options exist.
The SUPPORTED_AUTH_METHODS notification is co-located with the CERTREQ payload in the same message to simplify the receiver's task of linking announced authentication methods with the specific trust anchors, enabling the Cert Link mechanism.
When the SUPPORTED_AUTH_METHODS notification is too large for IKE_SA_INIT (risking IP fragmentation), the responder may defer it to an IKE_INTERMEDIATE exchange, which supports IKE fragmentation (RFC 7383) and avoids IP-layer fragmentation that IKE_SA_INIT cannot use.
If multiple SUPPORTED_AUTH_METHODS notifications are included in a single message, all their announcements form a single ordered list, unless overridden by another extension.
If the initiator doesn't support this extension, it ignores the SUPPORTED_AUTH_METHODS notification received in IKE_SA_INIT as an unknown status notify, per standard IKEv2 behavior. Sending and using the notification are optional for both initiator and responder.
The 'Digital Signature' (14) authentication method supersedes older signature methods (RSA, DSS, ECDSA variants 1, 3, 9, 10, 11). When announcing support for digital signatures, the multi-octet format with AlgorithmIdentifier is used rather than the 3-octet format applicable to the legacy methods.
The 'Generic Secure Password Authentication Method' (12) is intentionally excluded from announcement via SUPPORTED_AUTH_METHODS because it is negotiated separately via the RFC 6467 framework in IKE_SA_INIT.
If for any reason the responder doesn't resend CERTREQ payload(s) in the IKE_INTERMEDIATE exchange, the initiator MUST NOT abort negotiation. Instead, it MAY link Announcements to CAs from IKE_SA_INIT or MAY ignore Announcements containing CA links.
If peers negotiate secure password authentication (per RFC 6467), they MUST NOT send the SUPPORTED_AUTH_METHODS notification, since the secure password method is negotiated separately and no other authentication methods are involved.
If the initiator includes IDi/IDr payloads in an IKE_INTERMEDIATE request to help the responder select appropriate authentication methods, those payloads MUST be identical to the IDi/IDr payloads sent later in the IKE_AUTH request.
If the initiator sends IDi/IDr in an IKE_INTERMEDIATE request, it is RECOMMENDED that the responder sends back the list of authentication methods in the response to that exchange.
If the responder has sent CERTREQ payload(s) in IKE_SA_INIT and any Announcement in the SUPPORTED_AUTH_METHODS notification has a non-zero Cert Link field, the responder SHOULD resend the same CERTREQ payload(s) in the IKE_INTERMEDIATE response containing the notification.
Implementations MUST ignore announcements whose semantics they don't understand. This ensures forward compatibility as new authentication methods with new announcement formats are defined.
When multiple IKE_INTERMEDIATE exchanges take place during IKE SA establishment, it is RECOMMENDED that the responder use the last IKE_INTERMEDIATE exchange (just before IKE_AUTH) to send the list of supported authentication methods.
When using Multiple Authentication Exchanges (RFC 4739), peers MAY include multiple SUPPORTED_AUTH_METHODS notifications (one per authentication round), ordered by preference of performing authentication rounds.
An empty SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT response signals to the initiator that the responder will send the actual list in a subsequent IKE_INTERMEDIATE exchange. The initiator MAY start an IKE_INTERMEDIATE exchange for this sole purpose.
SUPPORTED_AUTH_METHODS is a new IKEv2 Notify Message Type (value 16443) that carries a list of authentication methods supported by the sending party, ordered by preference. Protocol ID is set to 0 and SPI Size is set to 0. The notification data contains a variable-length list of announcements.
The Cert Link field in 3-octet and multi-octet announcements contains a non-zero value N to indicate that the announced method is intended only for the N-th trust anchor from the CERTREQ payload(s). If zero, the method may be used with any CA. If no CERTREQ was received, the field MUST be ignored and treated as zero.
The responder sends SUPPORTED_AUTH_METHODS in the IKE_SA_INIT response; the initiator sends it in the IKE_AUTH request. If the notification fits, it is sent in IKE_SA_INIT; if too large, the responder may send an empty notification in IKE_SA_INIT to signal that the actual list will follow in an IKE_INTERMEDIATE exchange.
This document registers a new entry in the IANA 'IKEv2 Notify Message Status Types' registry: value 16443 assigned to SUPPORTED_AUTH_METHODS.
An on-path attacker who can break some announced authentication methods online may remove all stronger method announcements, coercing peers to use a weaker method and potentially enabling a person-in-the-middle attack. Implementations should consider this threat when configuring allowed authentication methods.
Announcing authentication methods reveals peers' capabilities to eavesdroppers. An active on-path attacker can strip all announcements except NULL Authentication, encouraging peers to use it — but this is only effective if NULL authentication is already permitted by local policy, so it is not a true downgrade attack.
The 2-octet announcement format is used for authentication methods not concerned with public key cryptography. It consists of a Length octet (value 2) followed by an Auth Method octet. Applicable for Shared Key Message Integrity Code (2) and NULL Authentication (13).
The 3-octet announcement format is used for public key authentication methods. It consists of Length (value 3), Auth Method, and Cert Link octets. The Cert Link field links the announcement to the N-th trust anchor from the CERTREQ payload(s), or 0 to allow any CA.
The multi-octet announcement format (Length > 3) is used for the 'Digital Signature' (14) authentication method. It contains Length, Auth Method, Cert Link, and a variable-length DER-encoded ASN.1 AlgorithmIdentifier identifying the specific signature algorithm.