idnits 2.17.1 draft-ietf-csi-send-name-type-registry-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document updates RFC3971, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3971, updated by this document, for RFC5378 checks: 2003-10-17) -- 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 (June 3, 2010) is 5075 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 (-10) exists of draft-ietf-csi-send-cert-03 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-18 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gagliano 3 Internet-Draft Cisco Systems 4 Updates: 3971 (if approved) S. Krishnan 5 Intended status: Standards Track Ericsson 6 Expires: December 5, 2010 A. Kukec 7 University of Zagreb 8 June 3, 2010 10 Subject Key Identifier (SKI) SEND Name Type fields. 11 draft-ietf-csi-send-name-type-registry-06 13 Abstract 15 SEcure Neighbor Discovery (SEND) defines the Name Type field in the 16 ICMPv6 Trust Anchor option. This document specifies new Name Type 17 fields based on certificate Subject Key Identifiers (SKI). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 5, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Name Type fields in the ICMPv6 TA option defined in this 56 document . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Processing Rules for Routers . . . . . . . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Requirements notation 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119] . 69 2. Introduction 71 SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 72 certificates that include the [RFC3779] extension for IPv6 addresses 73 to certify a router's authority over an IPv6 prefix for the NDP 74 (Neighbor Discovery Protocol). The Trust Anchor (TA) Option in 75 section 6.4.3 of [RFC3971] allows the identification of the Trust 76 Anchor selected by the host. In that same section, two name types 77 were defined: the DER Encoded X.501 Name and a Fully Qualified Domain 78 Name (FQDN). 80 In any Public Key Infrastructure, the subject name of a certificate 81 is only unique within each CA. Consequently, a new option to 82 identify TAs across CAs is needed. 84 In [I-D.ietf-csi-send-cert] the certificate profile described in 85 [I-D.ietf-sidr-res-certs] is adopted for SEND. In these documents, 86 the Subject field in the certificates is declared to be meaningless 87 and the subjectAltName field is not allowed. On the other hand, the 88 Subject Key Identifier (SKI) extension for the X.509 certificates is 89 defined as mandatory and non-critical. 91 This document specifies new Name Type fields in the SEND TA option 92 that allows the use of the SKI X.509 extension to identify TA X.509 93 certificates. This document also defines experimental and reserved 94 Name Types values. 96 Finally, this document updates the [RFC3971] by changing the Name 97 Type field in the ICMPv6 Trust Anchor option registration procedures 98 from Standards Action to Standards Action or IESG Approval. 100 3. Name Type fields in the ICMPv6 TA option defined in this document 102 The following Name Type fields in the ICMPv6 TA option are defined: 104 Name Type Description 105 0 Reserved 106 3 SHA-1 Subject Key Identifier (SKI). 107 4 SHA-224 Subject Key Identifier (SKI). 108 5 SHA-256 Subject Key Identifier (SKI). 109 6 SHA-384 Subject Key Identifier (SKI). 110 7 SHA-512 Subject Key Identifier (SKI). 111 253-254 Experimental 112 255 Reserved 114 Name Type field values 0 and 255 are marked as reserved. This means 115 that they are not available for allocation. 117 When the Name Type field is set to 3, the Name Type field contains a 118 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string 119 of the subject public key, as described in Section 3.9.2 of 120 [I-D.ietf-sidr-res-certs]. Implementations MAY support SHA-1 SKI 121 name type. 123 When the Name Type field is set to 4,5,6 or 7, the hash function will 124 respectively be: SHA-224, SHA-256, SHA-384 or SHA-512. 125 Implementations MAY support SHA-224, SHA-256, SHA-284 and SHA-512 SKI 126 name types. 128 Name Type fields 253 and 254 are marked as experimental, following 129 [RFC3692]. 131 4. Processing Rules for Routers 133 As specified in [RFC3971], a TA is identified by the SEND TA option. 134 If the TA option is represented as a SKI, then the SKI MUST be equal 135 to the X.509 SKI extension in the trust anchor's certificate. The 136 router SHOULD include the TA option(s) in the advertisement for which 137 the certification path was found. Also, following [RFC3971] 138 specification, if the router is unable to find a path to the 139 requested anchor, it SHOULD send an advertisement without any 140 certificate. In this case, the router SHOULD include the TA options 141 that were solicited. 143 5. IANA Considerations 145 IANA is requested to update the Name Type field in the ICMPv6 Trust 146 Anchor option registry by adding the following values: 148 +---------+----------------------------------------------------+ 149 | Value | Description | 150 +---------+----------------------------------------------------+ 151 | 0 | Reserved ( Section 3 ) | 152 | 3 | SHA-1 Subject Key Identifier (SKI) ( Section 3 ) | 153 | 4 | SHA-224 Subject Key Identifier (SKI) ( Section 3 ) | 154 | 5 | SHA-256 Subject Key Identifier (SKI) ( Section 3 ) | 155 | 6 | SHA-384 Subject Key Identifier (SKI) ( Section 3 ) | 156 | 7 | SHA-512 Subject Key Identifier (SKI) ( Section 3 ) | 157 | 253-254 | Experimental use ( Section 3 ) | 158 | 255 | Reserved ( Section 3 ) | 159 +---------+----------------------------------------------------+ 161 Table 1: New Name Type field values in the ICMPv6 TA option 163 IANA is also requested to modify the registration procedures for the 164 Name Type field in the ICMPv6 Trust Anchor option registry to 165 Standard Action or IESG Approval [RFC5226]. 167 6. Security Considerations 169 The hash functions referenced in this document to calculate the SKI 170 have reasonable random properties in order to provide reasonably 171 unique identifiers. Two identical identifiers in the same validation 172 path will cause the router to stop fetching certificates once the 173 first certificate has been fetched. In the case that the upward 174 certificate was configured as TA by a host, the router will send to 175 this host an incomplete list of certificates, causing the SEND 176 validation to fail. 178 For experimental values of the Name Type field, the guidance given in 179 [RFC3692] about the use of experimental values needs to be followed. 181 7. Normative References 183 [I-D.ietf-csi-send-cert] 184 Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 185 profile and certificate management for SEND", 186 draft-ietf-csi-send-cert-03 (work in progress), 187 March 2010. 189 [I-D.ietf-sidr-res-certs] 190 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 191 X.509 PKIX Resource Certificates", 192 draft-ietf-sidr-res-certs-18 (work in progress), May 2010. 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, March 1997. 197 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 198 Considered Useful", BCP 82, RFC 3692, January 2004. 200 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 201 Addresses and AS Identifiers", RFC 3779, June 2004. 203 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 204 Neighbor Discovery (SEND)", RFC 3971, March 2005. 206 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 207 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 208 May 2008. 210 Authors' Addresses 212 Roque Gagliano 213 Cisco Systems 214 Avenue des Uttins 5 215 Rolle, 1180 216 Switzerland 218 Email: rogaglia@cisco.com 220 Suresh Krishnan 221 Ericsson 222 8400 Decarie Blvd. 223 Town of Mount Royal, QC 224 Canada 226 Phone: +1 514 345 7900 x42871 227 Email: suresh.krishnan@ericsson.com 229 Ana Kukec 230 University of Zagreb 231 Unska 3 232 Zagreb 233 Croatia 235 Email: ana.kukec@fer.hr