The authentication method could be a consideration. For instance, if a responder is only allowing peers to authenticate with PSK or EAP authentication, it's pretty pointless to send any CERTREQ
payloads in the IKE_SA_INIT
response (although, there is no real harm in it either). Similarly, is it useless to send a CERT
payload when authenticating with a PSK.
Unlike TLS, IKEv2 doesn't use CERTREQ
s to trigger/request public key/certificate authentication. Even if public key authentication is used, the payloads are optional, and e.g. PSK authentication may be used even if a certificate request is received (given the peer allows it). Their main purpose is to help the peer select a certificate if it has multiple available (or to express preference for a specific type of certificate encoding). Note that some implementations might not send certificates if they didn't receive any certificate requests.
CERT
payloads are optional too. Trusted end-entity certificates could be locally installed, or the peers could use plain public keys that are stored locally or e.g. fetched via DNS and validated via DNSSEC (see RFC 4025). It really depends on what trust anchors the peers use and where these are stored (e.g. using a PKI will require sending intermediate CA certificates in addition to the end-entity certificate if only the root CA certificate is locally trusted). Before IKEv2 fragmentation was specified (RFC 7383), omitting the certificates or certificate requests was sometimes even necessary to avoid IP fragmentation of the IKE_AUTH
message due to the relatively large payloads.