idnits 2.17.1 draft-richardson-anima-idevid-cert-00.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 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 3, 2015) is 3068 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3280' is mentioned on line 179, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'RFC791' is mentioned on line 112, but not defined == Missing Reference: 'RFC3513' is mentioned on line 113, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Missing Reference: 'RFC2050' is mentioned on line 121, but not defined ** Obsolete undefined reference: RFC 2050 (Obsoleted by RFC 7020) -- Looks like a reference, but probably isn't: '0' on line 202 -- Looks like a reference, but probably isn't: '1' on line 204 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational November 3, 2015 5 Expires: May 6, 2016 7 X509.v3 certificate extension for authorization of device ownership 8 draft-richardson-anima-idevid-cert-00 10 Abstract 12 This document details an X.509 extension to provide authorization and 13 indication of ownership of a constrained device containing 802.1AR 14 IDevID. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 6, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Autonomous System Identifier Delegation Extension . . . . . . 4 53 2.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2.1. Criticality . . . . . . . . . . . . . . . . . . . . . 5 56 2.2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.2.3. Type IDevID . . . . . . . . . . . . . . . . . . . . . 5 58 2.2.4. Elements asnum, rdi, and Type ASIdentifierChoice . . 5 59 2.2.5. Element inherit . . . . . . . . . . . . . . . . . . . 6 60 2.2.6. Element asIdsOrRanges . . . . . . . . . . . . . . . . 6 61 2.2.7. Type ASIdOrRange . . . . . . . . . . . . . . . . . . 6 62 2.2.8. Element id . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.9. Element range . . . . . . . . . . . . . . . . . . . . 6 64 2.2.10. Type IDevIDRange . . . . . . . . . . . . . . . . . . 6 65 2.2.11. Elements min and max . . . . . . . . . . . . . . . . 6 66 2.2.12. Type IDevId . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Autonomous System Identifier Delegation Extension 68 Certification . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . 7 72 6. Appendix C -- Example of an AS Identifier Delegation 73 Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 This document defines two X.509 v3 certificate extensions that 80 authorize the transfer of the right-to-use for a set of devices 81 identified by 802.1AR IDevID from a production Factory through 82 national and regional distributors (VARs) to Plant Owners/Operators. 83 This extension binds a list of IDevID identifiers to the subject 84 (private key holder) of a certificate. The issuer of the certificate 85 is an entity (e.g., a Factory) that has produced the device to to 86 transfer ownership set of IDevID to the subject of the certificate. 87 These certificates provide a scalable, no-touch means of verifying 88 the ownership of a constrainted device. The constrained is 89 initialized with the trusted certificate of the Factory at the 90 Factory. This process may be used by enrollment protocols such as 91 1x, PANA, EAP-TLS and RPL to validate that the network infrastructure 92 being presented is the legitimate infrastructure for the constrainted 93 device. 95 Sections 2 specify several rules about the encoding of the extensions 96 defined in this specification that MUST be followed. These encoding 97 rules serve the following purposes. First, they result in a unique 98 encoding of the extension's value; two instances of an extension can 99 be compared for equality octet-by-octet. Second, they achieve the 100 minimal size encoding of the information. Third, they allow relying 101 parties to use one-pass algorithms when performing certification path 102 validation; in particular, the relying parties do not need to sort 103 the information, or to implement extra code in the subset checking 104 algorithms to handle several boundary cases (adjacent, overlapping, 105 or subsumed ranges). 107 1.1. Terminology 109 It is assumed that the reader is familiar with the terms and concepts 110 described in "Internet X.509 Public Key Infrastructure Certificate 111 and Certificate Revocation List (CRL) Profile" [RFC3280], "INTERNET 112 PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing 113 Architecture" [RFC3513], "INTERNET REGISTRY IP ALLOCATION GUIDELINES" 114 [RFC2050], and related regional Internet registry address management 115 policy documents. Some relevant terms include: 117 allocate - the transfer of custodianship of a resource to an 118 intermediate organization (see [RFC2050]). 120 assign - the transfer of custodianship of a resource to an end 121 organization (see [RFC2050]). 123 Autonomous System (AS) - a set of routers under a single technical 124 administration with a uniform policy, using one or more interior 125 gateway protocols and metrics to determine how to route packets 126 within the autonomous system, and using an exterior gateway protocol 127 to determine how to route packets to other autonomous systems. 129 Autonomous System number - a 32-bit number that identifies an 130 autonomous system. 132 delegate - transfer of custodianship (that is, the right-to-use) of 133 an IP address block or AS identifier through issuance of a 134 certificate to an entity. 136 initial octet - the first octet in the value of a DER encoded BIT 137 STRING [X.690]. 139 IDevID - a variable octet identifier written as in hexadecimal. 140 While there is no length limit to the IDevID, a Factory is expected 141 to pick a particularly length and stick to that length so that the 142 IDevID can be aggregated by simple integer enumeration. 144 subsequent octets - the second through last octets in the value of a 145 DER encoded BIT STRING [X.690]. 147 trust anchor - a certificate that is to be trusted when performing 148 certification path validation (see [RFC3280]). 150 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 151 SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in 152 this document, are to be interpreted as described in [RFC2119]. 154 2. Autonomous System Identifier Delegation Extension 156 This extension conveys the delegation of ownership of a device 157 identified by an 802.1AR Device ID to an entity by binding those 158 IDevID to a public key belonging to the entity. 160 2.1. Context 162 802.1AR defines a mechanism by which a manufacturer may place a 163 certificate that attests to the a device's identity into the device 164 at manufacturer time. This mechanism permits a device to 165 cryptographically identify itself to a network. The device, however 166 is unable to know to which network it belongs. This extension 167 permits the manufacturer, using the same trusted anchor to delegate 168 ownership of the device to the end user (possibly via a series of 169 intermediaries, such as a supplier chain). The use of such a 170 certificate chain can be easily verified by the device, and 171 therefore, combined with 802.1AR, permits mutual authentication of 172 devices and network entities. 174 2.2. Specification 176 The OID for this extension is id-pe-iDevID. 178 id-pe-iDevID OBJECT IDENTIFIER ::= { id-pe IANA-TBD } 179 where [RFC3280] defines: 181 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 182 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 184 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 186 Figure 1: OID 188 2.2.1. Criticality 190 This extension SHOULD be CRITICAL. The intended use of this 191 extension is to connote an ownership of the device specified in the 192 extension. A CA marks the extension as CRITICAL to convey the notion 193 that a relying party must understand the semantics of the extension 194 to make use of the certificate for the purpose it was issued. Newly 195 created applications that use certificates containing this extension 196 are expected to recognize the extension. 198 2.2.2. Syntax 200 id-pe-iDevID OBJECT IDENTIFIER ::= { id-pe IANA_TBD } 202 IDevID ::= SEQUENCE { idevnum [0] EXPLICIT 203 IDevIDChoice OPTIONAL, 204 rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL 205 } 207 IDevIDChoice ::= CHOICE { inherit NULL, -- inherit from issuer -- 208 iDevIdsOrRanges SEQUENCE OF iDevIdOrRange 209 } 211 IDevIdOrRange ::= CHOICE { id IDevId, range IDevRange } 212 IDevRange ::= SEQUENCE { min IDevId, max IDevId } 213 IDevId ::= INTEGER 215 Figure 2: OID 217 2.2.3. Type IDevID 219 The IDevID type is a SEQUENCE containing one or more forms of Device 220 Identifiers-- IDevID numbers (in the idevnum element) or routing 221 domain identifiers (in the rdi element). When the IDevID type 222 contains multiple forms of identifiers, the idevnum entry MUST 223 precede the rdi entry. IDevID numbers are used by 802.1AR and are 224 specified there. 226 2.2.4. Elements asnum, rdi, and Type ASIdentifierChoice 228 The idevnum and rdi elements are both of type IDevIDChoice. The 229 IDevIDChoice type is a CHOICE of either the inherit or asIdsOrRanges 230 element. 232 XXX - But I don't think we need this CHOICE 234 2.2.5. Element inherit 236 If the IDevIDChoice choice contains the inherit element, then the set 237 of authorized IDevIDs is taken from the issuer's certificate, or from 238 the issuer's issuer's certificate, recursively, until a certificate 239 containing an IDevIDChoice containing an iDevIdsOrRanges element is 240 located. If no authorization is being granted for a particular form 241 of IDevID, then there MUST NOT be a corresponding idevnum/rdi member 242 in the IDevID sequence. 244 2.2.6. Element asIdsOrRanges 246 The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types. Any 247 pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap. Any 248 contiguous series of AS identifiers MUST be combined into a single 249 range whenever possible. The AS identifiers in the asIdsOrRanges 250 element MUST be sorted by increasing numeric value. 252 2.2.7. Type ASIdOrRange 254 The ASIdOrRange type is a CHOICE of either a single integer (IDevId) 255 or a single sequence (IdevIDRange). 257 2.2.8. Element id 259 The id element has type ASId. 261 2.2.9. Element range 263 The range element has type ASRange. 265 2.2.10. Type IDevIDRange 267 The IDevIDRange type is a SEQUENCE consisting of a min and a max 268 element, and is used to specify a range of IDevID identifier values. 270 2.2.11. Elements min and max 272 The min and max elements have type IDevID. The min element is used 273 to specify the value of the minimum IDevID identifier in the range, 274 and the max element specifies the value of the maximum IDevID 275 identifier in the range. 277 2.2.12. Type IDevId 279 The IDevId type is an INTEGER. XXX - this will need work 281 2.3. Autonomous System Identifier Delegation Extension Certification 283 Path Validation 285 Certification path validation of a certificate containing the 286 autonomous system identifier delegation extension requires additional 287 processing. As each certificate in a path is validated, the AS 288 identifiers in the autonomous system identifier delegation extension 289 of that certificate MUST be subsumed by the AS identifiers in the 290 autonomous system identifier delegation extension in the issuer's 291 certificate. Validation MUST fail when this is not the case. A 292 certificate that is a trust anchor for certification path validation 293 of certificates containing the autonomous system identifier 294 delegation extension, as well as all certificates along the path, 295 MUST each contain the autonomous system identifier delegation 296 extension. The initial set of allowed AS identifiers is taken from 297 the trust anchor certificate. 299 3. Security Considerations 301 This specification describes an X.509 extension. Since X.509 302 certificates are digitally signed, no additional integrity service is 303 necessary. Certificates with these extensions need not be kept 304 secret, and unrestricted and anonymous access to these certificates 305 has no security implications. 307 However, security factors outside the scope of this specification 308 will affect the assurance provided to certificate users. This 309 section highlights critical issues that should be considered by 310 implementors, administrators, and users. 312 This extensions represent authorization information, i.e., a right- 313 to-use/ownership statement for a device. They were developed to 314 support zero-touch autonomic configuration of constrained devices in 315 a sensor network. As a result of this capability model, the Subject 316 field is largely irrelevant for security purposes, contrary to common 317 PKI conventions. 319 4. Acknowledgments 321 This document was cribbed extensively from RFC3779, however, errors 322 were introduced here. 324 5. Appendix A -- ASN.1 Module 326 This normative appendix will describes the IDevID extensions used by 327 conforming PKI components in ASN.1 syntax. 329 6. Appendix C -- Example of an AS Identifier Delegation Extension 331 A critical X.509 v3 certificate extension that specifies: 333 7. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 Author's Address 340 Michael C. Richardson 341 Sandelman Software Works 342 470 Dawson Avenue 343 Ottawa, ON K1Z 5V7 344 CA 346 Email: mcr+ietf@sandelman.ca 347 URI: http://www.sandelman.ca/