Host Identity Protocol Certificates
obsoletes
- rfc-6253 — Host Identity Protocol Certificates
updates
- rfc-7401 — Host Identity Protocol Version 2 (HIPv2)
Extracted elements (28)
Hash-and-URL (type 3), LDAP URL (type 5), and Distinguished Name (type 7) encodings are provided to reduce HIP control packet size at the cost of requiring the receiver to resolve external references or check a local cache, rather than embedding the full certificate.
Support for SPKI certificates was removed from RFC 6253 in this update (RFC 8002). Types 2, 4, 6, and 8, previously assigned to SPKI, are now marked Obsoleted. This is the sole technical change from RFC 6253.
The CERT parameter intentionally does not specify certificate semantics or use cases; these are left to documents that use the CERT parameter. This allows the parameter to be reused across different HIP scenarios without coupling the transport mechanism to specific trust models.
Hash and URL encoding (type 3) follows Section 3.6 of RFC 7296 (IKEv2). LDAP URL encoding (type 5) follows RFC 4516. Distinguished Name encoding (type 7) uses the string representation defined in RFC 4514.
In a managed PKI environment that is not HIP-aware and cannot compute HITs, HIP hosts must send their identity certificates along with the chain of intermediate CAs. The remote peer computes peer HITs based on the certificate public keys rather than receiving them pre-computed.
A CERT group specifies a group of related CERT parameters that SHOULD be interpreted in a certain order (e.g., for expressing certificate chains). CERT parameters with the same group number indicate a logical grouping.
Any HIP certificate serial number appearing on the Certificate Revocation List (CRL) is treated as invalid regardless of the reason code. The certificateHold reason code is not supported.
CERT parameters MUST be placed in ascending order within a HIP control packet according to their CERT group field. A HIP packet MUST NOT contain more than one incomplete CERT group that continues in the next HIP control packet.
Certificates MUST use the signature and hash algorithms defined in RFC 7401.
Each HIP control packet MAY contain multiple CERT parameters, each carrying one certificate. These parameters MAY be related or unrelated.
If the Initiator does not send all required certificates, the Responder MAY signal this by sending a HIP NOTIFY with NOTIFICATION parameter error type CREDENTIALS_REQUIRED.
Padding bytes in the CERT parameter MUST be zeroed by the sender, and their values SHOULD NOT be checked by the receiver.
The CERT ID acts as a sequence number to identify certificates in a CERT group. The numbers in the CERT ID field MUST start from 1 up to CERT count.
Using the CERT parameter in the first Initiator (I1) packet is NOT RECOMMENDED because it can increase processing times of I1s, which can be problematic when processing storms of I1s.
When HIP communications are established using a managed PKI with intermediate CAs, the chain of intermediate CAs up to the root CA or a CA trusted by the remote peer SHOULD be sent in a CERT group as specified in Section 2.
When the certificate is issued for a HIP host identified by a HIT and an HI, the respective HIT SHOULD be placed into the Subject Alternative Name (SAN) extension using the GeneralName form iPAddress, and the full HI is presented as the subject's public key info.
When the Host Identifier (HI) is used to sign the certificate, the respective HIT SHOULD be placed into the Issuer Alternative Name (IAN) extension using the GeneralName form iPAddress as defined in RFC 5280.
Error type CREDENTIALS_REQUIRED (value 48) is sent via HIP NOTIFY when the Responder is unwilling to establish an association because the Initiator did not send required credentials.
Error type INVALID_CERTIFICATE (value 50) is sent via HIP NOTIFY in response to a failed certificate verification. Notification Data MAY contain the CERT group and CERT ID octets of the failing CERT parameter.
HITs are represented as IPv6 addresses (per RFC 7343) when used as issuer or subject in X.509 v3 certificates. The Issuer Alternative Name and Subject Alternative Name extensions carry HITs as IP Address GeneralName forms.
The CERT parameter (type 768) is a container for digital certificates carried in HIP control packets. It includes CERT group, CERT count, CERT ID, and CERT type fields, followed by the certificate data and optional padding. It is a non-critical parameter protected by the HIP SIGNATURE field.
The defined CERT type values are: 0 (Reserved), 1 (X.509 v3), 2 (Obsoleted), 3 (Hash and URL of X.509 v3), 4 (Obsoleted), 5 (LDAP URL of X.509 v3), 6 (Obsoleted), 7 (Distinguished Name of X.509 v3), 8 (Obsoleted). Types 2, 4, 6, and 8 previously covered SPKI certificates, now obsoleted.
IANA maintains the 'HIP Certificate Types' subregistry under 'Host Identity Protocol (HIP) Parameters'. The 8-bit unsigned integer field defines certificate types. New values from unassigned space are assigned through IETF Review. This document obsoletes RFC 6253 as the reference and removes SPKI types (2, 4, 6, 8).
This document defines two new entries in the 'NOTIFY Message Types' subregistry under 'Host Identity Protocol (HIP) Parameters': CREDENTIALS_REQUIRED (48) and INVALID_CERTIFICATE (50).
Although CERT is allowed in I1 packets, it is NOT RECOMMENDED because it increases I1 processing time and can be exploited during I1 storm attacks. Additionally, the Responder may drop the CERT parameter in I1 without processing it.
Certificate grouping across multiple consecutive packets may allow attacks similar to IP-layer fragmentation attacks, such as sending fragments out of order or skipping fragments to exhaust victim CPU or memory. Hosts SHOULD implement mechanisms to discard certificate groups with outstanding certificates when state space is scarce.
Checking URL and LDAP entries for certificate retrieval (CERT types 3, 5, and 7) may allow denial-of-service attacks where the target host is subjected to bogus processing work.
The CERT parameter wire format is a TLV with 16-bit Type (768) and 16-bit Length fields, followed by 8-bit CERT group, 8-bit CERT count, 8-bit CERT ID, 8-bit CERT type, variable-length Certificate, and variable-length zero-padded Padding to align to 8-byte boundaries. Length excludes Type, Length, and Padding.