Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)
updates
- rfc-3971 — SEcure Neighbor Discovery (SEND)
Extracted elements (24)
In the local SEND deployment model, using a trust anchor certificate that includes ::/0 in its RFC 3779 address extension means no new trust anchor material is needed when renumbering, though migration to the public model requires distributing new trust anchors.
The RFC 3779 IPv6 address extension does not specify the function for which a certificate was issued, making it impossible to determine the certificate's purpose. EKU values were introduced to allow issuance of certificates for specific SEND roles (router, proxy, address owner).
Two deployment models are defined — local (confined to an administrative domain, may be deployed independently of RPKI hierarchy, supports ULAs) and public (linked to global RPKI deployment, suitable for mobile users) — which are not mutually exclusive and may be combined in hybrid deployments.
Section 7.3 of RFC 3971 is updated to specify that operators not wishing to constrain routers to specific prefixes should configure routers with certificates containing the 'inherit' element for the IPv6 AFI, rather than using the null prefix approach.
The certificate profile defined in this document supersedes the Router Authorization Certificate profile in RFC 3971. Certificates used in SEND MUST conform to this profile and MAY also conform to the original RFC 3971 profile.
The certificate validation method described in RFC 3971 (Section 6.3.1) is updated by this document to use the validation method in RFC 6487, including validation of certificates using the 'inherit' element as described in RFC 3779.
A host MAY use OCSP (RFC 2560) to verify certificate revocation status, but SHOULD NOT assume that certificates will include the URI of an OCSP server as part of the Authority Information Access extension.
Relying parties (end hosts implementing SEND) MUST be configured with one or more trust anchors to enable validation of router certificates.
Relying parties MAY require a particular KeyPurposeId value (such as id-kp-sendRouter or id-kp-sendProxiedRouter) within the EKU extension. If multiple KeyPurposeId values are included, relying parties need not recognize all of them as long as the required value is present.
Relying parties MUST require the EKU extension to be present in a certificate and MUST reject certificates that do not contain at least one SEND KeyPurposeId, even if the anyExtendedKeyUsage OID is included.
SEND certificates MUST comply with the RPKI resource certificate profile described in RFC 6487. This supersedes the certificate profile for Router Authorization Certificates specified in RFC 3971.
SEND certificates MUST include the IP Address Delegation extension (RFC 3779), which MUST include at least one address block for the IPv6 Address Family (AFI=0002). SEND certificates MUST NOT have more than one IP Address Delegation extension.
The EKU extension, if present, MUST be non-critical, as described in RFC 6487.
The Extended Key Usage (EKU) extension is optional in RPKI certificates generally but MUST be present when issuing end-entity certificates for SEND.
The host MUST perform the certificate validation method described in RFC 6487, and MUST verify that the KeyPurposeId value corresponding to the Neighbor Discovery message type is present.
When using the RPKI Certificate Profile, the null prefix MUST be validated. A certificate may inherit its parent's prefix using the 'inherit' element for the IPv6 AFI as defined in RFC 3779.
Four SEND KeyPurposeId (Extended Key Usage) OID values are defined: id-kp-sendRouter ({ id-kp 23 }) for routers, id-kp-sendProxiedRouter ({ id-kp 24 }) for proxies performing RA/Redirect proxying, id-kp-sendOwner ({ id-kp 25 }) for address owners, and id-kp-sendProxiedOwner ({ id-kp 26 }) for proxies performing NS/NA/RS proxying.
id-kp-sendOwner (OID 1.3.6.1.5.5.7.3.25) authorizes a node to use any address encompassed by the certified IP address space, including assigning it to an interface and sending/receiving traffic and NS/NA/RS messages.
id-kp-sendProxiedOwner (OID 1.3.6.1.5.5.7.3.26) authorizes a proxy to perform proxying of Neighbor Solicitation (NS), Neighbor Advertisement (NA), and Router Solicitation (RS) messages for any address encompassed by the certified IP address space.
id-kp-sendRouter (OID 1.3.6.1.5.5.7.3.23) authorizes the router to generate Router Advertisement (RA) and Redirect messages for any prefix encompassed by the IP address space in the X.509 IP address extensions.
This document registers four Extended Key Usage OIDs in the PKIX Working Group arc delegated by IANA: id-kp-sendRouter (23), id-kp-sendProxiedRouter (24), id-kp-sendOwner (25), and id-kp-sendProxiedOwner (26). An ASN.1 module OID is also registered.
Certification authorities must ensure correct EKU values are inserted in each issued certificate, as relying parties accept or reject certificates for intended uses based on EKU content. Incorrect representation may cause rejection of appropriate certificates or acceptance of inappropriate ones.
Incorrect EKU values in SEND certificates can enable the same attacks SEND was designed to prevent. For example, a malicious host obtaining a certificate with id-kp-sendRouter for a given prefix can masquerade as a router for that prefix to attract traffic from local nodes.
The EKU extension uses the ASN.1 type ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId, where KeyPurposeId ::= OBJECT IDENTIFIER. SEND KeyPurposeId values are assigned under the PKIX kp arc (1.3.6.1.5.5.7.3).