idnits 2.17.1 draft-krishnan-cgaext-send-cert-eku-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-16 == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-04 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'SIDR-ARCH') Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track A. Kukec 5 Expires: September 10, 2009 University of Zagreb 6 K. Ahmed 7 Microsoft 8 March 9, 2009 10 Certificate profile and certificate management for SEND 11 draft-krishnan-cgaext-send-cert-eku-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 10, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for 50 performing router authorization. This document specifies a 51 certificate profile for SEND based on Resource Certificates along 52 with extended key usage values required for SEND. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Certificate Management in SEND . . . . . . . . . . . . . . . . 5 59 3.1. Motivations for using RPKI . . . . . . . . . . . . . . . . 5 60 4. Certificate profile . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Extended Key Usage Values . . . . . . . . . . . . . . . . 6 62 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Requirements notation 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2. Introduction 76 Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for 77 performing router authorization. It uses the X.509 extension for IP 78 addresses to verify whether the router is authorized to advertise the 79 mentioned IP addresses. 81 The SEND specification does not describe the set of extensions that 82 need to be supported and the revocation mechanisms for SEND 83 certificates. This document uses the Resource Certificates specified 84 in [RES-CERTS] in order to provide this information. 86 Also, since the IP addresses extension does not mention what 87 functions the subject of the certificate can perform for the IP 88 addresses, it becomes impossible to know the reason for which the 89 certificate was issued. In order to facilitate issuance of 90 certificates for specific functions, this document utilizes the 91 ExtKeyUsageSyntax field of the X.509 certificate to mention the 92 purpose for which the certificate was issued. This document 93 specifies three extended key usage values, one for routers, one for 94 proxies, and one for address owners, for use with SEND. 96 3. Certificate Management in SEND 98 A certification path in SEND is transported in Certification Path 99 Advertisement (CPA) message sent from a router to SEND host. CPA 100 message is sent in reply to the Certification Path Solicitation 101 message (CPS) message. The certification path sent in CPA message is 102 a path between a router and SEND host's trust anchor and it might be 103 potentially voluminous. Thus, CPA and CPS messages are kept separate 104 from the rest of SEND messages. 106 SEND specification does not define any certificate management 107 routines (certificate issuance and revocation). The only two 108 routines described in SEND specification are the Certificate path 109 validation and IP address extension verification. 111 3.1. Motivations for using RPKI 113 This draft recommends that the SEND PKI be made part of the bigger 114 RPKI [SIDR-ARCH]. The main advantages of this model are: 116 o It is a global model suitable for mobile users. The RPKI has 117 default trust anchors that are widely used and available for 118 mobile users. 120 o The RPKI project (certificate management and certificate profile) 121 has been adopted by all the RIRs and IANA. SEND could simply 122 adopt well-known and already accepted RPKI mechanisms. 124 4. Certificate profile 126 End entity certificates issued in support of SeND MUST comply with 127 the RPKI resource profile [RES-CERTS]. CA certificates used to 128 verify these router (EE) certificates also MUST comply with this 129 profile. This implies that these CA certificates MUST contain at an 130 RFC 3779 address extension representing the address space allocations 131 held by the service provider represented by the CA. 133 Relying parties (e.g., user devices that implement SeND and process 134 these router certificates) MUST be configured with one or more trust 135 anchors, to enable validation of the router certificates. These 136 trust anchors MAY be the default trust anchors defined for the RPKI, 137 or they MAY be self-signed (CA) certificates associated with the 138 service providers operating the routers in question. In either case, 139 it is RECOMMENDED that the RPKI trust anchor representation defined 140 in [RES-CERTS] be employed. 142 Because of the flexibility afforded service through (local) trust 143 anchor configuration, certificates used for SeND support can be 144 issued prior to issuance of RPKI certificates under the global 145 address allocation hierarchy. Note, however, that a CA certificate 146 issued independently of the global RPKI will have to be reissued in 147 order to integrate a local PKI with the global RPKI. 149 In addition to conforming to the Resource Certificate Profile as 150 specified in [RES-CERTS] the SEND certificate MUST support the 151 Extended Key Usage extension. The Extended Key Usage extension is 152 described in section 5.1. It MUST be marked as critical. 154 4.1. Extended Key Usage Values 156 The Internet PKI document [RFC5280] specifies the extended key usage 157 X.509 certificate extension. The extension indicates one or more 158 purposes for which the certified public key may be used. The 159 extended key usage extension can be used in conjunction with key 160 usage extension, which indicates the intended purpose of the 161 certified public key. 163 The extended key usage extension syntax is repeated here for 164 convenience: 166 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 168 KeyPurposeId ::= OBJECT IDENTIFIER 170 This specification defines three KeyPurposeId values: one for 171 authorizing routers, one for authorizing proxies, and one for address 172 owners. 174 The inclusion of the router authorization value indicates that the 175 certificate has been issued for allowing the router to advertise 176 prefix(es) that are mentioned using the X.509 extensions for IP 177 addresses and AS identifiers [RFC3779] 179 The inclusion of the proxy authorization value indicates that the 180 certificate has been issued for allowing the proxy to perform 181 proxying of neighbor discovery messages for the prefix(es) that are 182 mentioned using the X.509 extensions for IP addresses and AS 183 identifiers [RFC3779] 185 The inclusion of the owner authorization value indicates that the 186 certificate has been issued for allowing the node to use the 187 address(es) or prefix(es) that are mentioned using the X.509 188 extensions for IP addresses and AS identifiers [RFC3779] 190 Inclusion of multiple values indicates that the certified public key 191 is appropriate for use by a node performing more than one of these 192 functions. 194 send-kp OBJECT IDENTIFIER ::= 195 { iso(1) identified-organization(3) dod(6) internet(1) 196 security(5) mechanisms(5) TBA1 } 198 id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 } 200 id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 } 202 id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 } 204 The extended key usage extension MAY, at the option of the 205 certificate issuer, be either critical or non-critical. 207 Certificate-using applications MAY require the extended key usage 208 extension to be present in a certificate, and they MAY require a 209 particular KeyPurposeId value to be present (such as id-kp-sendRouter 210 or id-kp-sendProxy) within the extended key usage extension. If 211 multiple KeyPurposeId values are included, the certificate-using 212 application need not recognize all of them, as long as the required 213 KeyPurposeId value is present. 215 5. Backward Compatibility 217 The disadvantages of this model are related to the fact that the SEND 218 specification was developed before the standardization of the RPKI. 219 Hence, SEND is not completely compliant with the RPKI specifications 220 since it defines its own IP prefix validation routine and it is not 221 suitable for the use with CRLs, while the RPKI suports only CRLs. 222 This means that SEND implementations supporting this profile will not 223 be able to interoperate with legacy SEND implementations. 225 6. Security Considerations 227 The certification authority needs to ensure that the correct values 228 for the extended key usage are inserted in each certificate that is 229 issued. Relying parties may accept or reject a particular 230 certificate for an intended use based on the information provided in 231 these extensions. Incorrect representation of the information in the 232 extended key usage field can cause the relying party to reject an 233 otherwise appropriate certificate or accept a certificate that ought 234 to be rejected. 236 7. Acknowledgements 238 The authors would like to thank Steve Kent, Richard Barnes, Sandy 239 Murphy, Marcelo Bagnulo, and Gabriel Montenegro for reviewing earlier 240 versions of this document and suggesting text to make the document 241 better. 243 8. Normative References 245 [RES-CERTS] 246 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 247 X.509 PKIX Resource Certificates", 248 draft-ietf-sidr-res-certs-16 (work in progress), 249 February 2009. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 255 Addresses and AS Identifiers", RFC 3779, June 2004. 257 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 258 Neighbor Discovery (SEND)", RFC 3971, March 2005. 260 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 261 Housley, R., and W. Polk, "Internet X.509 Public Key 262 Infrastructure Certificate and Certificate Revocation List 263 (CRL) Profile", RFC 5280, May 2008. 265 [SIDR-ARCH] 266 Lepinski, M. and S. Kent, "An Infrastructure to Support 267 Secure Internet Routing", draft-ietf-sidr-arch-04 (work in 268 progress), November 2008. 270 Authors' Addresses 272 Suresh Krishnan 273 Ericsson 274 8400 Decarie Blvd. 275 Town of Mount Royal, QC 276 Canada 278 Phone: +1 514 345 7900 x42871 279 Email: suresh.krishnan@ericsson.com 281 Ana Kukec 282 University of Zagreb 283 Unska 3 284 Zagreb 285 Croatia 287 Email: ana.kukec@fer.hr 289 Khaja Ahmed 290 Microsoft 292 Email: khaja@windows.microsoft.com