idnits 2.17.1 draft-rgaglian-csi-send-ski-ta-nametype-00.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 : ---------------------------------------------------------------------------- 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 (October 6, 2009) is 5309 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 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: April 9, 2010 Ericsson 6 A. Kukec 7 University of Zagreb 8 October 6, 2009 10 Subject Key Identifier (SKI) name type for SEND TA option 11 draft-rgaglian-csi-send-ski-ta-nametype-00 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. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 9, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for 60 performing router authorization. This document specifies a SEND name 61 type to identify trust anchor X.509v3 certificates based on its 62 Subject Key Identifier. 64 Table of Contents 66 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. SEND SKI trust anchor identifier option . . . . . . . . . . . 6 69 3.1. Processing Rules for Router . . . . . . . . . . . . . . . 6 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Requirements notation 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 84 certificates that include [RFC3779] extension for IPv6 addresses to 85 certify a router authority over an IPv6 prefix for NDP (Neighbor 86 Discovery Protocol). The Tust Anchor Option in section 6.4.3 of RFC 87 3971 allows the identification of the trust anchor selected by the 88 host. In that section, two name types were defined, the DER Encoded 89 X.501 Name and a Fully Qualified Domain Name (FQDN). 91 In any Public Key Infraestructure, the subject name of a certificate 92 is only unique for each CA. A new option to identify trust anchors 93 accross CAs is needed. 95 In [draft-ietf-csi-send-cert-01] the certificate profile described in 96 [draft-ietf-sidr-res-certs-17] is selected for SEND. In these 97 documents, the Subject field the certificates are declared to be 98 meaningless and the subjectAltName field is not allowed. On the 99 other hand, the Subject Key Identifier (SKI) extension for the X.509 100 certificates is defined as mandatory and non-critical. 102 This document specifies a new option for SEND that allows to use of 103 the SKI X.509 extension to identify trust anchor material as 104 described in section X.X of RFC 3971. 106 3. SEND SKI trust anchor identifier option 108 Name Type 110 TBD SHA-1 Subject Key Identifier (SKI) 112 The Key Identifier used here is the 160-bit SHA-1 hash of the value 113 of the DER-encoded ASN.1 bit string of the subject public key, as 114 described in Section 4.2.1.2 of [RFC5280]. 116 3.1. Processing Rules for Router 118 As described in RFC 3971, The anchor is identified by the Trust 119 Anchor option. If the Trust Anchor option is represented as a SHA-1 120 SKI, then the SKI must be equal to the SKI in the anchor's 121 certificate calculated as described in 122 [draft-ietf-sidr-res-certs-17]. The router SHOULD include the Trust 123 Anchor option(s) in the advertisement for which the certification 124 path was found. 126 If the router is unable to find a path to the requested anchor, it 127 SHOULD send an advertisement without any certificates. In this case, 128 the router SHOULD include the Trust Anchor options that were 129 solicited. 131 4. IANA Considerations 133 This document defines a new Name Type for Neighbor Discovery Protocol 134 Trust Anchor option (15). 136 5. Security Considerations 138 TBD. 140 6. Normative References 142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 143 Requirement Levels", BCP 14, RFC 2119, March 1997. 145 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 146 Addresses and AS Identifiers", RFC 3779, June 2004. 148 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 149 Neighbor Discovery (SEND)", RFC 3971, March 2005. 151 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 152 Housley, R., and W. Polk, "Internet X.509 Public Key 153 Infrastructure Certificate and Certificate Revocation List 154 (CRL) Profile", RFC 5280, May 2008. 156 Authors' Addresses 158 Roque Gagliano 159 LACNIC 160 Rambla Rep Mexico 6125 161 Montevideo, 11400 162 UY 164 Email: roque@lacnic.net 166 Suresh Krishnan 167 Ericsson 168 8400 Decarie Blvd. 169 Town of Mount Royal, QC 170 Canada 172 Phone: +1 514 345 7900 x42871 173 Email: suresh.krishnan@ericsson.com 175 Ana Kukec 176 University of Zagreb 177 Unska 3 178 Zagreb 179 Croatia 181 Email: ana.kukec@fer.hr