idnits 2.17.1 draft-rgaglian-csi-send-name-type-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 10, 2009) is 5275 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-00 == Outdated reference: A later version (-22) exists of draft-ietf-sidr-res-certs-17 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gagliano 3 Internet-Draft LACNIC 4 Intended status: Standards Track S. Krishnan 5 Expires: May 14, 2010 Ericsson 6 A. Kukec 7 University of Zagreb 8 November 10, 2009 10 SEND Name Type field Registry 11 draft-rgaglian-csi-send-name-type-registry-01 13 Abstract 15 SEcure Neighbor Discovery (SEND) defines the Name Type field in the 16 Trust Anchor option. This document requesto to IANA the creation and 17 management of a registry for this field. This document also 18 specifies a new Name Type field based on a certificate Subject Key 19 Identifier (SKI). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 14, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. SEND SKI trust anchor Name Type field. . . . . . . . . . . . . 5 76 3.1. Processing Rules for Router . . . . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 79 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 91 certificates that include [RFC3779] extension for IPv6 addresses to 92 certify a router authority over an IPv6 prefix for NDP (Neighbor 93 Discovery Protocol). The Trust Anchor Option in section 6.4.3 of RFC 94 3971 allows the identification of the Trust Anchor (TA) selected by 95 the host. In that section, two name types were defined, the DER 96 Encoded X.501 Name and a Fully Qualified Domain Name (FQDN). This 97 document requesto to IANA the creation and management of a registry 98 for this field. 100 In any Public Key Infrastructure, the subject name of a certificate 101 is only unique within each CA. A new option to identify TAs across 102 CAs is needed. 104 In [I-D.ietf-csi-send-cert] the certificate profile described in 105 [I-D.ietf-sidr-res-certs] is adopted for SEND. In these documents, 106 the Subject field the certificates are declared to be meaningless and 107 the subjectAltName field is not allowed. On the other hand, the 108 Subject Key Identifier (SKI) extension for the X.509 certificates is 109 defined as mandatory and non-critical. 111 This document specifies a new Name Type field in the SEND TA option 112 that allows to use of the SKI X.509 extension to identify TA X.509 113 certificates. 115 3. SEND SKI trust anchor Name Type field. 117 Name Type 119 3 SHA-1 Subject Key Identifier (SKI) 121 The Key Identifier used here is the 160-bit SHA-1 hash of the value 122 of the DER-encoded ASN.1 bit string of the subject public key, as 123 described in Section 4.2.1.2 of [RFC5280]. 125 3.1. Processing Rules for Router 127 As described in RFC 3971, a TA is identified by the SEND TA option. 128 If the TA option is represented as a SHA-1 SKI, then the SKI must be 129 equal to the SKI in the anchor's certificate calculated as described 130 in [draft-ietf-sidr-res-certs-17]. The router SHOULD include the TA 131 option(s) in the advertisement for which the certification path was 132 found. 134 If the router is unable to find a path to the requested anchor, it 135 SHOULD send an advertisement without any certificate. In this case, 136 the router SHOULD include the TA options that were solicited. 138 4. IANA Considerations 140 IANA will maintains the registry of Name Type field in the ICMP Trust 141 Anchor option. The registry records Name Type fields for the ICMP 142 Trust Anchor option (15) defined in the RFC 3971. 144 The following Name Type fields are defined: 146 1 DER Encoded X.501 Name (RFC 3971). 148 2 FQDN (RFC 3971) 150 3 SHA-1 Subject Key Identifier (SKI) (Section 3) 152 New assignments of Name Type field is through Standards Action. 154 5. Security Considerations 156 No security considerations. 158 6. Normative References 160 [I-D.ietf-csi-send-cert] 161 Krishnan, S., Kukec, A., and R. Gagliano, "Certificate 162 profile and certificate management for SEND", 163 draft-ietf-csi-send-cert-00 (work in progress), July 2009. 165 [I-D.ietf-sidr-res-certs] 166 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 167 X.509 PKIX Resource Certificates", 168 draft-ietf-sidr-res-certs-17 (work in progress), 169 September 2009. 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, March 1997. 174 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 175 Addresses and AS Identifiers", RFC 3779, June 2004. 177 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 178 Neighbor Discovery (SEND)", RFC 3971, March 2005. 180 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 181 Housley, R., and W. Polk, "Internet X.509 Public Key 182 Infrastructure Certificate and Certificate Revocation List 183 (CRL) Profile", RFC 5280, May 2008. 185 Authors' Addresses 187 Roque Gagliano 188 LACNIC 189 Rambla Rep Mexico 6125 190 Montevideo, 11400 191 Uruguay 193 Email: roque@lacnic.net 195 Suresh Krishnan 196 Ericsson 197 8400 Decarie Blvd. 198 Town of Mount Royal, QC 199 Canada 201 Phone: +1 514 345 7900 x42871 202 Email: suresh.krishnan@ericsson.com 204 Ana Kukec 205 University of Zagreb 206 Unska 3 207 Zagreb 208 Croatia 210 Email: ana.kukec@fer.hr