From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6494.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6494.txt (limited to 'doc/rfc/rfc6494.txt') diff --git a/doc/rfc/rfc6494.txt b/doc/rfc/rfc6494.txt new file mode 100644 index 0000000..c50f558 --- /dev/null +++ b/doc/rfc/rfc6494.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Gagliano +Request for Comments: 6494 Cisco Systems +Updates: 3971 S. Krishnan +Category: Standards Track Ericsson +ISSN: 2070-1721 A. Kukec + Enterprise Architects + February 2012 + + + Certificate Profile and Certificate Management for + SEcure Neighbor Discovery (SEND) + +Abstract + + SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for + performing router authorization. This document specifies a + certificate profile for SEND based on resource certificates along + with extended key usage values required for SEND. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6494. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Gagliano, et al. Standards Track [Page 1] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Notation ...........................................3 + 3. Terminology .....................................................3 + 4. SEND Certificate Profile ........................................4 + 4.1. Unconstrained Certified Subnet Prefixes ....................4 + 5. Deployment Models ...............................................5 + 6. Trust Anchor Material ...........................................5 + 7. Extended Key Usage Values .......................................6 + 8. CRL Profile and Revocation ......................................7 + 8.1. Online Certificate Status Protocol (OCSP) Considerations ...7 + 9. Certificate Validation ..........................................8 + 10. IANA Considerations ............................................8 + 11. Security Considerations ........................................8 + 12. Acknowledgements ...............................................8 + 13. References .....................................................9 + 13.1. Normative References ......................................9 + 13.2. Informative References ....................................9 + Appendix A. Router Authorization Certificate Example ..............10 + Appendix B. ASN.1 Module ..........................................11 + +1. Introduction + + SEcure Neighbor Discovery (SEND) [RFC3971] utilizes X.509v3 + certificates that include the [RFC3779] extension for IPv6 addresses + to certify a router's authorization to advertise the IPv6 prefix for + the Neighbor Discovery (ND) protocol. The SEND specification defines + a basic certificate profile for SEND. The certificate profile + defined in this document supersedes the profile for Router + Authorization Certificates specified in [RFC3971]. That is, + certificates used in SEND (by routers, proxies, or address owners) + MUST conform to this certificate profile and MAY conform to the + original profile in [RFC3971]. + + The Resource Public Key Infrastructure (RPKI) is the global PKI that + attests to the allocation of IP address space. The RPKI represents + the centralized model discussed in Section 6.2 of [RFC3971]. + Consequently, SEND will use the RPKI Certificate Profile and + certificate validation detailed in [RFC6487]. Consequently, the + certificate validation method described in [RFC3971] is updated with + the certificate validation method in [RFC6487]. + + Since the [RFC3779] IPv6 address extension does not mention what + functions the node can perform for the certified IPv6 space, it + becomes impossible to know the reason for which the certificate was + issued. In order to facilitate issuance of certificates for specific + functions, it is necessary to utilize the ExtKeyUsageSyntax field + + + +Gagliano, et al. Standards Track [Page 2] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + + (optional in RPKI certificates) of the X.509 certificate to mention + why the certificate was issued. This document specifies four + extended key usage values -- one for routers, two for proxies, and + one for address owners -- for use with SEND. + + In RFC 3971, two deployment models were described: centralized and + decentralized. This document describes the different deployment + models that can be used with the SEND certificates defined here. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Terminology + + Certified IPv6 address space IPv6 address space included in an + X.509v3 certificate using the extension + for IPv6 addresses [RFC3779]. + + End-entity (EE) An entity in the PKI that is not a + Certification Authority (CA). + + ISP Internet Service Provider. + + NIR National Internet Registry. + + RIR Regional Internet Registry. + + RPKI Resource PKI established in accordance + with [RFC6480]. + + RPKI certificates Certificates as defined in [RFC6487]. + + SEND certificates Certificates as described in [RFC3971] + and extended in this document. They + are end-entity certificates that belong + either to SEND routers, SEND hosts, or + SEND proxies: + + * Router Authorization Certificates as + defined in [RFC3971]. + + * Owner Authorization Certificates as + defined in [RFC3971]. + + + + + +Gagliano, et al. Standards Track [Page 3] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + + * Secure Proxy ND Certificates as + defined in [RFC6496]. + + SEND KeyPurposeId An Extended Key Usage (EKU) value for + SEND, such as the four introduced in + this document. + +4. SEND Certificate Profile + + SEND certificates MUST comply with the RPKI resource profile + described in [RFC6487]. A Router Authorization Certificate example + is included in Appendix A. + + In Sections 2, 4.9.10, and 4.9.11 of [RFC6487], it is stated that + RFC 3779 resource extensions MUST be marked as critical and MUST be + present in all resource certificates. SEND certificates MUST include + the IP Address Delegation extension [RFC3779]. This extension MUST + include at least one address block for the IPv6 Address Family + (AFI=0002), as described in Section 4.9.10 of [RFC6487]. SEND + certificates MUST NOT have more than one IP Address Delegation + extension. + +4.1. Unconstrained Certified Subnet Prefixes + + Section 7.3 of [RFC3971] defines the Unconstrained Certified subnet + prefixes category by using certificates containing either the null + prefix or no prefix extension at all. + + When using the RPKI Certificate Profile, prefix extensions are + mandatory and the null prefix MUST be validated. However, a + certificate may inherit its parent's prefix or range by using the + "inherit" element for the IPv6 Address Family Identifier (AFI) as + defined in [RFC3779]. The use of the "inherit" element is permitted + in [RFC6487]. + + Consequently, this document updates Section 7.3 of [RFC3971], adding + the following text under Unconstrained: + + Network operators that do not want to constrain routers to route + particular subnet prefixes, but rather inherit those prefixes from + the routers' parent certificates, should configure routers with + certificates containing the "inherit" element for the IPv6 AFI. + + + + + + + + + +Gagliano, et al. Standards Track [Page 4] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + +5. Deployment Models + + RFC 3971 describes two deployment models: centralized and + decentralized. These models were differentiated by having one trust + anchor or many trust anchors. In this document, we introduce two new + deployment models not based on the number of trust anchors but on the + localization of the SEND deployment. + + The local SEND deployment model represents those cases where SEND + deployment is confined to an administrative domain. In this + scenario, the deployment of SEND MAY be done independently of the + existence of deployment in the upper RPKI hierarchy (i.e., an end + user could perform local SEND deployment without the need for RPKI + deployment in its ISP). This model requires the use of local trust + anchors and configuring islands of trust. This model MAY include + Unique Local Addresses (ULAs) [RFC4193]. + + The public SEND deployment models represent those cases where SEND + deployment is linked to RPKI deployment as described in [RFC6480]. + Trust anchor material MAY be part of a different administrative + domain (i.e., RIRs, NIRs, or ISPs). It is a global model suitable + for mobile users. + + These two models are not mutually exclusive. It is entirely possible + to have a hybrid model that incorporates features from both of these + models. In one such hybrid deployment model, most IP address + resources (e.g., global unicast addresses) would be certified under + the global RPKI, while some others (e.g., ULAs) are certified under + local trust anchors. + +6. Trust Anchor Material + + Relying parties (e.g., end hosts that implement SEND and process + these router certificates) MUST be configured with one or more trust + anchors to enable validation of the routers' certificates. [RFC6495] + and Section 6.5 of [RFC3971] list the trust anchor configuration + options for end hosts using SEND. + + In the local SEND deployment model, it is possible to use as a trust + anchor a certificate that includes in its RFC 3779 address extension + the prefix ::/0. In this case, no new trust anchor material would be + needed when renumbering. However, if trying to move from the local + deployment model to the public deployment model, new trust anchor + material will have to be distributed to relying parties. + + + + + + + +Gagliano, et al. Standards Track [Page 5] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + +7. Extended Key Usage Values + + The Internet PKI document [RFC5280] specifies the extended key usage + X.509 certificate extension. The extension indicates one or more + purposes for which the certified public key may be used. The + extended key usage extension can be used in conjunction with the key + usage extension, which indicates the intended purpose of the + certified public key. The EKU extension is defined as optional in + [RFC6487] for end-entity certificates but MUST be present when + issuing end-entity certificates for SEND. + + The extended key usage extension syntax is repeated here for + convenience: + + ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId + + KeyPurposeId ::= OBJECT IDENTIFIER + + This specification defines four KeyPurposeId values: one for + authorizing routers (Router Authorization Certificates), two for + authorizing proxies (Secure Proxy ND Certificates), and one for + address owners (Owner Authorization Certificates). Additional + KeyPurposeId values may be specified in Standards Track documents. + + The inclusion of the router authorization value (id-kp-sendRouter) + indicates that the certificate has been issued for allowing the + router to generate Router Advertisement (RA) and Redirect messages + for any prefix(es) encompassed (as defined in Section 7.1 of + [RFC6487]) by the IP address space included in the X.509 extensions + for IP addresses. + + The inclusion of the proxied routing authorization value + (id-kp-sendProxiedRouter) indicates that the certificate has been + issued for allowing the proxy to perform proxying of RA and Redirect + messages for any prefix(es) encompassed by the IP address space + included in the X.509 extensions for IP addresses. + + The inclusion of the owner authorization value (id-kp-sendOwner) + indicates that the certificate has been issued for allowing the node + to use any address(es) that is/are encompassed by the IP address + space included in the X.509 extensions for IP addresses. For an + address in such a certificate, the node can assign the address to an + interface; send/receive traffic from/to this address; and send/ + respond to NS, NA, and RS messages related to that address. + + The inclusion of the proxied owner authorization value + (id-kp-sendProxiedOwner) indicates that the certificate has been + issued for allowing the proxy to perform proxying of Neighbor + + + +Gagliano, et al. Standards Track [Page 6] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + + Solicitation (NS), Neighbor Advertisement (NA), and Router + Solicitation (RS) messages for any address encompassed by the IP + address space included in the X.509 extensions for IP addresses. + + send-kp OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) kp(3) } + + id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } + + id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 } + + id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } + + id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 } + + As described in [RFC6487], the extended key usage extension, if + present, MUST be non-critical. + + Relying parties MUST require the extended key usage extension to be + present in a certificate, and they MAY require a particular + KeyPurposeId value to be present (such as id-kp-sendRouter or + id-kp-sendProxiedRouter) within the extended key usage extension. If + multiple KeyPurposeId values are included, the relying parties need + not recognize all of them, as long as the required KeyPurposeId value + is present. Relying parties MUST reject certificates that do not + contain at least one SEND KeyPurposeId, even if they include the + anyExtendedKeyUsage OID defined in [RFC5280]. + +8. CRL Profile and Revocation + + RPKI requires the use of Certificate Revocation Lists (CRLs) + [RFC6487]. The host will obtain the necessary CRLs and perform the + certificate validation method described in [RFC6487]. + +8.1. Online Certificate Status Protocol (OCSP) Considerations + + A host MAY use OCSP [RFC2560] to verify the revocation status of a + certificate. + + As [RFC6487] is adopted as the base certificate profile for SEND, the + host SHOULD NOT assume that certificates will include the URI of an + OCSP server as part of its Authority Information Access (AIA) + extension. This is particularly evident in the SEND public + deployment model, as OCSP services are not required by [RFC6484]. + + + + + + +Gagliano, et al. Standards Track [Page 7] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + +9. Certificate Validation + + This section updates Section 6.3.1 of [RFC3971] by introducing new + validations without introducing any conflict. + + The host MUST perform the certificate validation method described in + [RFC6487]. The validation of certificates that use the "inherit" + element where the existence of a parent prefix or range is required + is described in [RFC3779]. + + The host MUST verify that the KeyPurposeId value corresponding to the + Neighbor Discovery message type is present, as described in + Section 7. + +10. IANA Considerations + + This document makes use of object identifiers to identify EKUs and + the ASN.1 (Abstract Syntax Notation One) module found in Appendix B. + The EKUs and ASN.1 module OID are registered in an arc delegated by + IANA to the PKIX Working Group. + +11. Security Considerations + + The certification authority needs to ensure that the correct values + for the extended key usage are inserted in each certificate that is + issued. Relying parties may accept or reject a particular + certificate for an intended use based on the information provided in + these extensions. Incorrect representation of the information in the + extended key usage field can cause the relying party to reject an + otherwise appropriate certificate or accept a certificate that ought + to be rejected. In particular, since a SEND certificate attests that + its subject is authorized to play a given role in the SEND protocol, + certificates that contain incorrect EKU values can enable some of the + same attacks that SEND was meant to prevent. For example, if a + malicious host can obtain a certificate that authorizes it to act as + a router for a given prefix, then it can masquerade as a router for + that prefix, e.g., in order to attract traffic from local nodes. + +12. Acknowledgements + + The authors would like to thank Alberto Garcia, Stephen Kent, Sean + Turner, Roni Even, Richard Barnes, Alexey Melnikov, Jari Arkko, David + Harrington, and Tim Polk for their reviews and suggestions on the + earlier versions of this document. + + + + + + + +Gagliano, et al. Standards Track [Page 8] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + +13. References + +13.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. + Adams, "X.509 Internet Public Key Infrastructure Online + Certificate Status Protocol - OCSP", RFC 2560, June 1999. + + [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP + Addresses and AS Identifiers", RFC 3779, June 2004. + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate + Policy (CP) for the Resource Public Key Infrastructure + (RPKI)", BCP 173, RFC 6484, February 2012. + + [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for + X.509 PKIX Resource Certificates", RFC 6487, + February 2012. + + [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key + Identifier (SKI) SEcure Neighbor Discovery (SEND) Name + Type Fields", RFC 6495, February 2012. + +13.2. Informative References + + [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support + Secure Internet Routing", RFC 6480, February 2012. + + [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- + Martinez, "Secure Proxy ND Support for SEcure Neighbor + Discovery (SEND)", RFC 6496, February 2012. + + + + + + +Gagliano, et al. Standards Track [Page 9] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + +Appendix A. Router Authorization Certificate Example + + Certificate: + Data: + Version: 3 (0x2) + Serial Number: 249 (0xf9) + Signature Algorithm: sha256WithRSAEncryption + Issuer: CN=EXAMPLE-CA-2342342652346 + Validity + Not Before: Jul 2 10:06:32 2010 GMT + Not After : Jul 2 10:06:32 2011 GMT + Subject: CN=SEND-EXAMPLE-123432 + Subject Public Key Info: + Public Key Algorithm: rsaEncryption + Public-Key: (2048 bit) + Modulus: + 00:b7:06:0d:8e:f7:39:0a:41:52:93:59:a8:f5:63: + 3f:2e:3d:24:17:9d:19:aa:09:ff:c0:2a:f3:c6:99: + d7:34:0d:bf:f1:e9:73:b5:8f:dc:d4:91:d6:5d:cb: + 9c:b8:2b:41:63:c1:8f:f7:48:54:02:89:07:24:c3: + b0:6e:11:5a:7d:c0:38:88:4b:d9:3b:93:c7:ca:4d: + a4:00:a2:d3:6d:14:15:8f:15:08:4d:4e:b3:8a:cc: + de:2d:e0:7a:9b:c0:6e:14:f6:a7:ae:b9:e0:c5:18: + 60:75:3d:d3:50:00:47:0d:86:5b:1c:a0:85:81:af: + 2b:84:98:49:7d:60:a2:e8:4f:6d:40:ba:d5:fe:de: + de:41:53:c7:c4:f4:d3:1a:41:cd:dc:9f:08:43:33: + 48:00:57:e4:56:93:7d:dd:19:12:e8:bf:26:b3:4b: + 30:ac:b8:9c:b1:37:05:18:3c:7b:6b:26:d7:c9:15: + c9:4a:eb:1b:fa:92:38:46:27:44:96:8a:a1:12:c1: + 09:77:4a:7b:a5:07:88:a6:36:30:98:70:79:b6:44: + 7e:b1:c9:4c:5b:11:56:e8:14:50:f7:f8:e5:ed:f1: + ac:a4:31:46:36:77:05:c9:63:fe:c3:ab:54:e2:bd: + 79:1d:14:d1:c2:80:36:d3:be:e6:c7:a2:47:59:1b: + 75:9f + Exponent: 65537 (0x10001) + + X509v3 extensions: + X509v3 Authority Key Identifier: + keyid:4C:5D:56:82:15:8A:67:A6:8C:69:67:68:88 + :6F:15:E5:C9:96:58:EB + + X509v3 CRL Distribution Points: + + Full Name: + URI:rsync://rsync.example.exampledomain/ + EXAMPLE-CA-2342342652346/EXAMPLE-CA.crl + + + + + +Gagliano, et al. Standards Track [Page 10] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + + X509v3 Subject Key Identifier: + B8:69:EB:36:23:F1:C4:21:65:DD:13:76:EE:90:AF + :F7:CD:E3:61:CD + X509v3 Key Usage: critical + Digital Signature + sbgp-ipAddrBlock: critical + IPv6: + 2001:db8:cafe:bebe::/64 + + X509v3 Extended Key Usage: + 1.3.6.1.5.5.7.3.23 + Signature Algorithm: sha256WithRSAEncryption + 92:14:38:6e:45:83:1b:cb:7c:45:0d:bc:7f:6e:36:bf:82:cc: + 7e:00:91:ea:f4:24:43:cc:00:3c:3f:c2:99:0c:c6:b9:20:2e: + ca:dc:df:94:0d:c9:a1:75:c4:5c:39:a1:cf:9f:e1:40:9c:aa: + a9:80:76:d1:3a:91:d9:db:2f:cd:3c:05:50:52:eb:28:47:d0: + ab:d3:fd:6f:30:17:16:7f:c6:0f:2b:25:bb:db:29:d7:bb:4e: + f3:7c:2d:e1:04:b7:f0:bc:d5:8a:ba:8c:0d:39:22:48:02:d1: + 67:fb:35:5c:b6:83:03:63:7c:73:03:70:20:de:fb:d7:12:ed: + 6f:a1:ff:b2:a6:39:fb:55:9a:07:bd:68:40:0f:6f:d5:24:34: + cf:e8:dd:76:33:2a:d0:b9:1b:ae:a8:68:86:17:f8:13:35:0e: + f6:04:ec:2a:39:88:06:70:c6:e8:56:87:f7:35:54:2a:28:2c: + 92:47:a9:89:39:d7:72:24:21:9d:02:52:f9:7c:76:7f:e9:cd: + 09:6e:82:f4:da:6c:f9:72:b2:64:98:b5:0c:6a:38:8d:81:e5: + fc:50:46:6f:38:40:56:06:92:5a:e0:86:5d:55:f5:7b:85:b2: + 68:4f:49:72:e0:fa:2c:bf:9e:7d:aa:28:17:ca:04:b8:ae:69: + c9:04:28:12 + +Appendix B. ASN.1 Module + + SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-send-cert-extns(71) } + + DEFINITIONS IMPLICIT TAGS ::= + + BEGIN + + -- OID Arc + + id-kp OBJECT IDENTIFIER ::= + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) kp(3) } + + + + + + + + +Gagliano, et al. Standards Track [Page 11] + +RFC 6494 SEND Certificate Profile and Management February 2012 + + + -- Extended Key Usage Values + + id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 } + id-kp-sendProxiedRouter OBJECT IDENTIFIER ::= { id-kp 24 } + id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 } + id-kp-sendProxiedOwner OBJECT IDENTIFIER ::= { id-kp 26 } + + END + +Authors' Addresses + + Roque Gagliano + Cisco Systems + Avenue des Uttins 5 + Rolle 1180 + Switzerland + + EMail: rogaglia@cisco.com + + + Suresh Krishnan + Ericsson + 8400 Decarie Blvd. + Town of Mount Royal, QC + Canada + + Phone: +1 514 345 7900 x42871 + EMail: suresh.krishnan@ericsson.com + + + Ana Kukec + Enterprise Architects + 46/525 Collins St. + Melbourne, VIC 3000 + Australia + + EMail: ana.kukec@enterprisearchitects.com + + + + + + + + + + + + + + +Gagliano, et al. Standards Track [Page 12] + -- cgit v1.2.3