Network Working Group R. Gagliano Internet-Draft LACNIC Intended status: Standards Track S. Krishnan Expires: August 20, 2010 Ericsson A. Kukec University of Zagreb February 16, 2010 Certificate profile and certificate management for SEND draft-ietf-csi-send-cert-02 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 Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2010. Copyright Notice Copyright (c) 2010 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 Gagliano, et al. Expires August 20, 2010 [Page 1] Internet-Draft SEND certificate profile and management February 2010 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Gagliano, et al. Expires August 20, 2010 [Page 2] Internet-Draft SEND certificate profile and management February 2010 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SEND Certificate profile . . . . . . . . . . . . . . . . . . . 6 5. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 7 6. Trust Anchor Material . . . . . . . . . . . . . . . . . . . . 8 7. Extended Key Usage Values . . . . . . . . . . . . . . . . . . 9 8. CRL profile and revocation . . . . . . . . . . . . . . . . . . 11 8.1. OCSP Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 12. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Appendix A: Router Authorization Certificate certificate example . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Gagliano, et al. Expires August 20, 2010 [Page 3] Internet-Draft SEND certificate profile and management February 2010 1. 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]. Gagliano, et al. Expires August 20, 2010 [Page 4] Internet-Draft SEND certificate profile and management February 2010 2. Introduction SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 certificates that include the [RFC3779] extension for IPv6 addresses to certify a router's authority over an IPv6 prefix for the Neighbor Discovery (ND) Protocol. SEND specification defines neither the certificate profile nor any certificate management routines. It specifies only the certificate path validation and the IP address extension verification procedures. This document defines the certificate profile, as well as certificate issuance and revocation routines for SEND. The SIDR WG in the IETF is working on a Certificate Profile for the Resource Public Key Infrastructure (RPKI). The RPKI represents the centralized model referred in Section 6.2 of [RFC3971]. Consequently, SEND will use the SIDR certificate profile and certificate validation detailed in [I-D.ietf-sidr-res-certs]. Since the RFC 3779 IPv6 addresses 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 (optional in RPKI Certificates) of the X.509 certificate to mention the purpose why the certificate was issued. This document specifies three extended key usage values, one for routers, one for proxies, and one for address owners, for use with SEND. In RFC 3971 two deployment models were described: centralized and decentralized. With the advance of RPKI standardization we introduce two different deployment models: local and public deployment models. Gagliano, et al. Expires August 20, 2010 [Page 5] Internet-Draft SEND certificate profile and management February 2010 3. Terminology Certified IPv6 address space IPv6 address space included in an X.509v3 certificate using RFC 3779 extension for IPv6 addresses. End Entity (EE) user of PKI certificates and/or end user system that is the subject of a certificate; ISP Internet Service Provider. NIR National Internet Registry. RIR Regional Internet Registry. RPKI Resource PKI established in accordance with [I-D.ietf-sidr-arch]. RPKI certificates Certificates defined in [I-D.ietf-sidr-res-certs]. SEND certificates Certificates described in [RFC3971] and extended in this document. They are end- entity certificates that belong either to SEND routers or Secure Proxy ND nodes: * Router Authorization Certificates. * Secure Proxy ND certificates for ND Proxy, Mobile IPv6 Home Agent or Proxy Mobile Access Gateway [I-D.ietf-csi-proxy-send]. Gagliano, et al. Expires August 20, 2010 [Page 6] Internet-Draft SEND certificate profile and management February 2010 4. SEND Certificate profile SEND certificates MUST comply with the RPKI resource profile [I-D.ietf-sidr-res-certs]. A Router Authorization Certificate example is included in the Appendix A. In sections 2, 3.9.10 and 3.9.11 of [I-D.ietf-sidr-res-certs] it is stated that RFC 3779 resource extensions MUST be critical and MUST be present in all Resource Certificates. SEND certificates MUST include the IP Resources extension for IPv6 Address Family (AFI=0002) described in section 3.9.10 of [I-D.ietf-sidr-res-certs] and MUST be the only resource extension present. The IPv6 resource extension MUST NOT specify the "inherit" element. Certified IPv6 address space SHOULD be expressed using either addressPrefix or addressesOrRange elements. Gagliano, et al. Expires August 20, 2010 [Page 7] Internet-Draft SEND certificate profile and management February 2010 5. Deployment Models RFC 3971 describes two deployment models:centralized and decentralized. These models were differentiated by having one or many trust anchor. In this document we introduced 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 represent 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 local SEND deployment without the need of RPKI deployment in its ISP). This model requires the use of local trust anchors and configuring islands of trust. This model MAY include ULA addresses. The public SEND deployment models represent those cases where SEND deployment is linked to RPKI deployment as described in [I-D.ietf-sidr-arch]. Trust anchor material MAY be part of a different administrative domain (i.e. RIR, NIR or ISPs). It is a global model suitable for mobile users. Gagliano, et al. Expires August 20, 2010 [Page 8] Internet-Draft SEND certificate profile and management February 2010 6. Trust Anchor Material Relying parties (e.g., user devices that implement SEND and process these router certificates) MUST be configured with one or more trust anchors to enable validation of the routers' certificates. The trust anchor material MAY be either a CA certificate (which MAY be self- signed) containing an RFC 3779 address extension or it MAY be trust anchor material as defined in [I-D.ietf-sidr-ta]. In a local SEND deployment model, it is possible to use as trust anchor material 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. By using the trust anchor model described in [I-D.ietf-sidr-ta], relying parties will use as trust anchor material the ETA (External Trust Anchor) certificate, which does not list any address space. This configuration allows network renumbering without the need for issuing trust anchor material in both the local and the public model. In this case the Relying party MUST obtain an RTA (RPKI Trust Anchor) certificate from the publication point of the ETA certificate as defined at [I-D.ietf-sidr-ta]. The identification for the Trust Anchor Material will be included in the Name Type Field of the ICMP Trust Anchor Option as described in RFC 3971 and MUST always to refer to a certificate that includes a RFC 3779 address extension. Gagliano, et al. Expires August 20, 2010 [Page 9] Internet-Draft SEND certificate profile and management February 2010 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 key usage extension, which indicates the intended purpose of the certified public key. The Extended Key Usage extension is defined as optional in [I-D.ietf-sidr-res-certs] 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 three KeyPurposeId values: one for authorizing routers, one for authorizing proxies, and one for address owners. The inclusion of the router authorization value indicates that the certificate has been issued for allowing the router to advertise prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] The inclusion of the proxy authorization value indicates that the certificate has been issued for allowing the proxy to perform proxying of neighbor discovery messages for the prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] The inclusion of the owner authorization value indicates that the certificate has been issued for allowing the node to use the address(es) or prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] Inclusion of multiple values indicates that the certified public key is appropriate for use by a node performing more than one of these functions. send-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) TBA } id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 } Gagliano, et al. Expires August 20, 2010 [Page 10] Internet-Draft SEND certificate profile and management February 2010 id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 } id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 } As described in [I-D.ietf-sidr-res-certs], the extended key usage extension, if present, MUST be non-critical. Certificate-using applications MAY 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-sendProxy) within the extended key usage extension. If multiple KeyPurposeId values are included, the certificate-using application need not recognize all of them, as long as the required KeyPurposeId value is present. Gagliano, et al. Expires August 20, 2010 [Page 11] Internet-Draft SEND certificate profile and management February 2010 8. CRL profile and revocation RPKI requires the use of CRLs [I-D.ietf-sidr-res-certs]. The host will obtain the necessary CRLs and perform the certificate validation method described in [I-D.ietf-sidr-res-certs]. 8.1. OCSP Considerations By addopting the [I-D.ietf-sidr-res-certs] as the certificate profile for SEND, the use of the OCSP protocol is not allowed by the RPKI Certicate Policies [I-D.ietf-sidr-cp]. As CRLs are expected to be small, the fetching of the required CRLs are not expected to demand important bandwith. Gagliano, et al. Expires August 20, 2010 [Page 12] Internet-Draft SEND certificate profile and management February 2010 9. IANA Considerations This memo includes no request to IANA. Gagliano, et al. Expires August 20, 2010 [Page 13] Internet-Draft SEND certificate profile and management February 2010 10. 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. Gagliano, et al. Expires August 20, 2010 [Page 14] Internet-Draft SEND certificate profile and management February 2010 11. Acknowledgements The author would like to thank the contributions from Stephen Kent. Gagliano, et al. Expires August 20, 2010 [Page 15] Internet-Draft SEND certificate profile and management February 2010 12. Normative References [I-D.ietf-csi-proxy-send] Krishnan, S., Laganier, J., and M. Bonola, "Secure Proxy ND Support for SEND", draft-ietf-csi-proxy-send-01 (work in progress), July 2009. [I-D.ietf-sidr-arch] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-09 (work in progress), October 2009. [I-D.ietf-sidr-cp] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource PKI (RPKI)", draft-ietf-sidr-cp-08 (work in progress), January 2010. [I-D.ietf-sidr-res-certs] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", draft-ietf-sidr-res-certs-17 (work in progress), September 2009. [I-D.ietf-sidr-ta] Michaelson, G., Kent, S., and G. Huston, "A Profile for Trust Anchor Material for the Resource Certificate PKI", draft-ietf-sidr-ta-02 (work in progress), September 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC3971] Arkko, J., 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. Gagliano, et al. Expires August 20, 2010 [Page 16] Internet-Draft SEND certificate profile and management February 2010 Appendix A. Appendix A: Router Authorization Certificate certificate example Certificate: Data: Version: 3 (0x2) Serial Number: 29 (0x1d) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=EXAMPLE-CA-2342342652346 Validity Not Before: Feb 15 23:06:53 2010 GMT Not After : Feb 15 23:06:53 2011 GMT Subject: CN=SEND-EXAMPLE-123432 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:bf:64:da:82:fb:b6:fd:a6:2d:c4:3a:10:d7:2c: 7b:8c:22:0a:30:b7:45:b1:7d:ae:c0:fd:f1:06:04: 5b:4a:6c:21:e7:de:15:cb:9a:07:c8:c4:80:6f:55: cd:71:33:01:04:9f:87:57:db:d5:b3:c7:91:c5:81: 28:7f:a8:eb:b1:53:80:3a:01:8a:7c:97:d2:d3:41: 92:f4:68:db:3b:86:64:12:24:1e:e1:84:f8:33:5c: 0f:fa:ae:8a:a0:1f:e7:b7:4e:5a:ad:0a:a0:a1:2d: 42:5a:54:10:37:e2:13:84:88:ed:70:e4:76:6c:d6: 75:ab:8a:5c:c9:42:39:60:55:49:c2:66:ee:e7:64: a1:67:fa:69:27:de:f6:2f:55:4d:09:89:29:75:c0: 61:02:41:7e:99:4f:81:1d:78:5a:45:8b:1c:9c:85: 87:76:51:a3:24:3b:0e:63:72:e8:b9:c5:81:32:91: 46:bb:87:81:82:5d:14:48:60:4a:ae:79:4f:f4:7e: bd:ce:cf:01:de:19:e0:34:1a:12:fe:10:9d:1e:a6: 91:8b:28:ca:d6:83:71:8a:f3:39:fa:7a:49:c6:36: b5:66:39:3a:a3:f8:02:70:a1:7a:8c:92:55:bd:b6: 84:cf:18:02:78:82:4f:2f:8e:f1:08:db:54:02:e0: c5:e9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Certificate Policies: critical Policy: 1.3.6.1.5.5.7.14.2 X509v3 Authority Key Identifier: keyid:F7:EB:16:AB:D2:43:E3:72:16:41: E0:B7:99:CA:1F:A4:37:C3:74:FB Authority Information Access: CA Issuers - URI:rsync://rsync.lacnic.net/ EXAMPLE-CA-2342342652346/EXAMPLE-CA.cer Gagliano, et al. Expires August 20, 2010 [Page 17] Internet-Draft SEND certificate profile and management February 2010 X509v3 CRL Distribution Points: URI:rsync://rsync.example.exampledomain/ EXAMPLE-CA-2342342652346/EXAMPLE-CA.crl X509v3 Subject Key Identifier: 5F:AB:EC:98:8A:E1:47:41:55:4F:67:57:98: 22:CE:99:85:8F:2A:85 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: 1.3.6.1.5.5.TBA.1 sbgp-ipAddrBlock: critical IPv6: 2001:db8:CAFE:BEBE::/64 Signature Algorithm: sha256WithRSAEncryption 6f:ec:08:b2:5f:2c:84:6b:99:4c:fe:7d:00:db:fa:c1:90:a2: de:34:0a:31:b0:f6:f1:95:d9:4a:ef:09:79:90:51:84:a9:5a: a1:5a:a2:cd:09:69:e2:cb:ff:da:f1:34:32:bd:cc:b5:c8:7e: b1:fa:46:78:93:a5:cc:d5:1b:03:30:42:c4:ab:55:d7:e5:0d: 74:de:e8:f3:00:6b:68:df:0d:64:ba:58:49:d0:0b:5d:a5:7c: 82:ec:5c:95:18:fe:67:f5:25:21:9c:07:8e:ba:81:80:c8:c2: 95:e6:0a:ea:bd:4b:a2:fc:10:53:cf:c9:16:83:83:88:7c:06: 39:04:dd:49:4e:75:b5:4b:6b:8d:4c:9f:d7:59:33:c3:95:c4: 7f:48:f5:83:da:37:e0:c1:a5:5d:09:7d:65:78:b6:77:a7:f9: 49:59:f8:83:3e:14:dd:e0:86:e1:5e:fa:6d:42:ee:dd:eb:c0: f6:4b:0a:31:f1:37:1b:77:12:79:99:1b:2f:d5:e7:7f:2f:a2: 6e:54:71:17:17:0d:a4:7b:7d:5a:6e:40:02:1d:5c:6a:06:ab: 5d:33:ea:b6:8a:1b:f6:85:16:ef:d4:00:db:54:e8:ac:53:b8: 0f:39:d8:a4:3e:9b:87:41:f3:f5:05:d6:a0:44:cc:82:bc:b9: fd:72:40:ff Gagliano, et al. Expires August 20, 2010 [Page 18] Internet-Draft SEND certificate profile and management February 2010 Authors' Addresses Roque Gagliano LACNIC Rambla Rep Mexico 6125 Montevideo, 11400 Uruguay Phone: +598 2 4005633 Email: roque@lacnic.net 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 University of Zagreb Unska 3 Zagreb Croatia Email: ana.kukec@fer.hr Gagliano, et al. Expires August 20, 2010 [Page 19]