idnits 2.17.1 draft-lear-brski-pop-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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 110: '... this memo SHOULD NOT be used, as th...' RFC 2119 keyword, line 126: '...t. The response MUST be a voucher-brs...' RFC 2119 keyword, line 222: '... The registrar MUST have included th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 171 has weird spacing: '...gleaned direc...' -- The document date (October 20, 2018) is 2015 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 (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft O. Friel 4 Intended status: Standards Track Cisco Systems 5 Expires: April 23, 2019 October 20, 2018 7 Proof of Possession to Devices for Onboarding 8 draft-lear-brski-pop-00 10 Abstract 12 This memo specifies a RESTful interface for local deployments to 13 demonstrate proof of possession to a device or to a manufacturer 14 authorized signing authority (MASA). This covers the case where a 15 MASA would not otherwise have knowledge of where a device is 16 deployed, or when a MASA may not be required. Such knowledge is 17 important to onboard certain classes of devices, such as those on 18 IEEE 802.11 networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 23, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. The Yang Model . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Changes from Earlier Versions . . . . . . . . . . . . . . . . 7 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to 67 provision credentials to be used as credentials to operationally 68 access networks. In the initial model, the manufacturer authorized 69 signing authority is assumed to either have knowledge of whether a 70 device is intended to be provisioned on a particular network, or to 71 be able to simply sign all requests. The necessary knowledge to 72 handle the first case is not always easy to come by, and particularly 73 useful to have when a device is trying to determine which network to 74 join, when there is a choice. Such is the case with IEEE 802.11 75 networks, for example. 77 Absent that knowledge, should a MASA automatically issue a voucher, 78 the device may onboard to the first BRSKI-aware network, which may 79 well be the wrong one. 81 In addition, some manufacturers may prefer not to require the 82 existence of a MASA. In these circumstances proof of possession to 83 the device is required. 85 This memo specifies a RESTful request that devices and registrars 86 employ as an alternative to [I-D.ietf-anima-bootstrapping-keyinfra], 87 in which two additional optional objects may be specified. Three new 88 objects are defined: 90 1. A simple binary claim that registrar administrator knows this 91 device to belong on the particular deployment network. This 92 object should be conveyed from the registrar to the MASA. 94 2. A cryptographic claim as such. This would typically be some sort 95 of scanned label or information received as part of a bill of 96 materials that contains some signed evidence of delivery of the 97 end device to the deployment. This option may be conveyed from 98 the register to the MASA, or when the MASA needn't be contacted, 99 to the device. 101 3. A statement indicating that the MASA server needn't be contacted 102 at all, and that the device will accept a certificate with the 103 cryptographic claim specified in this memo. This permits offline 104 registration. 106 Note that this interface is optional. There may well be cases where 107 a MASA already has sufficient knowledge to onboard a device to the 108 correct network. Particularly where the manufacturer requires online 109 registration, when such integration exists, the mechanisms defined in 110 this memo SHOULD NOT be used, as they would be superfluous. 112 When this model is used, in order to avoid any interoperability 113 problems, a new RESTful endpoint is defined as follows: 115 "/.well-known/est/request-voucher-with-possession" 117 The new endpoint is handled precisely as described in Section 5.2 of 118 [I-D.ietf-anima-bootstrapping-keyinfra], with the exception voucher 119 is formed as described below in Section 2. 121 If the device has indicated that the MASA server needn't be 122 contacted, then the registrar may generate an unsigned voucher 123 response. However, in this case, the registrar must include a valid 124 claim object that has been hashed with an 8-32 bit nonce, immediately 125 succeeded by a non-NULL-terminated key that is provided in UTF8 126 format. The response MUST be a voucher-brski-pop-request-artifact 127 rather than a voucher-artifact. 129 2. The Yang Model 131 file "ietf-brski-possession@2018-10-11.yang" 132 module ietf-brski-possession { 133 yang-version 1.1; 134 namespace "urn:ietf:params:xml:ns:yang:ietf-brski-possession"; 135 prefix mr; 137 import ietf-restconf { 138 prefix rc; 139 description 140 "This import statement is only present to access 141 the yang-data extension defined in RFC 8040."; 142 reference "RFC 8040: RESTCONF Protocol"; 143 } 144 import ietf-voucher { 145 prefix v; 146 description "This module defines the format for a voucher, 147 which is produced by a pledge's manufacturer or 148 delegate (MASA) to securely assign a pledge to 149 an 'owner', so that the pledge may establish a secure 150 conn ection to the owner's network infrastructure"; 152 reference "RFC 8366: Voucher Profile for Bootstrapping Protocols"; 153 } 155 import ietf-voucher-request { 156 prefix rv; 157 description 158 "Voucher request is what we will augment"; 159 reference "draft-ietf-anima-bootstrapping-keyinfra"; 160 } 162 organization 163 "TBD"; 164 contact 165 "Author: Eliot Lear 166 "; 167 description 168 "This module to provide additional information about 169 how a device may be claimed by a particular deployment. 170 The owner is asserting that this information has not merely 171 been gleaned directly in-band from the device, 172 but rather he or she can confirm ownership independently. 174 Copyright (c) 2018 IETF Trust and the persons identified as 175 authors of the code. All rights reserved. 177 Redistribution and use in source and binary forms, with or without 178 modification, is permitted pursuant to, and subject to the license 179 terms contained in, the Simplified BSD License set forth in Section 180 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 181 (http://trustee.ietf.org/license-info). 183 This version of this YANG module is part of RFC XXXX; see the RFC 184 itself for full legal notices."; 186 revision 2018-10-11 { 187 description 188 "Initial version"; 189 reference "RFC XXXX: Proof of possession for BRSKI"; 190 } 191 rc:yang-data voucher-brski-pop-request-artifact { 192 uses rv:voucher-request-grouping { 193 augment "voucher" { 194 description 195 "trying to add one more thing into this voucher."; 196 leaf out-of-band-claim { 197 when 'not(../no-masa-required) and not(../possession-claim)'; 198 type binary; 199 description 200 "If this value is true, then the adminsitrator of the 201 registrar is claiming that the device being claimed 202 has been purchased or otherwise acquired for this 203 deployment, and that the information has not merely 204 been automatically gleaned directly from the device."; 205 } 206 leaf possession-claim { 207 when 'not(../no-masa-required) and not(../out-of-band-claim)'; 208 type string; 209 description 210 "In the context of a voucher-request, this node contains 211 a naked key that the MASA will validate. If valid, the 212 MASA will sign a voucher. The form of this key is left 213 to the manufacturer, and is opaque to the registrar"; 214 } 215 leaf no-masa-required { 216 when 'not(../possession-claim)and not(../out-of-band-claim)'; 217 type binary; 218 description 219 "If true, then the device will not bother to validate 220 the provisional TLS connection, but instead assume it 221 to be valid. Only the pledge may set this value. 222 The registrar MUST have included the possession-claim 223 object."; 224 } 225 } 226 } 227 } 228 rc:yang-data voucher-with-pop-artifact { 229 uses v:voucher-artifact-grouping { 230 refine "voucher/pinned-domain-cert" { 231 mandatory false; 232 } 233 refine "voucher/assertion" { 234 mandatory false; 235 } 236 augment "voucher" { 237 description 238 "Add leaf node for returning a hashed proof of 239 possession."; 240 leaf hashed-proof-of-possession { 241 type binary; 242 mandatory true; 243 description 244 "A hash of the provided nonce and a key obtained 245 by the registrar. The format is the nonce followed 246 immediately by the key."; 247 } 249 leaf hash-type { 250 type enumeration { 251 enum SHA256 { 252 description 253 "The type of hash is SHA256."; 254 } 255 } 256 description 257 "If not present, assume SHA256. Otherwise, whatever 258 augmented value is present. This is for algorithmic 259 agility."; 260 } 261 } 262 } 263 } 264 } 266 268 3. Examples 270 TBD. 272 4. IANA Considerations 274 The following YANG name space should be registered: 276 o "urn:ietf:params:xml:ns:yang:ietf-brski-possession" 278 5. Security Considerations 280 There will be many. 282 6. Acknowledgments 284 None yet. 286 7. Changes from Earlier Versions 288 Draft -00: 290 o Initial revision 292 8. Normative References 294 [I-D.ietf-anima-bootstrapping-keyinfra] 295 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 296 S., and K. Watsen, "Bootstrapping Remote Secure Key 297 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 298 keyinfra-16 (work in progress), June 2018. 300 Authors' Addresses 302 Eliot Lear 303 Cisco Systems 304 Richtistrasse 7 305 Wallisellen CH-8304 306 Switzerland 308 Phone: +41 44 878 9200 309 Email: lear@cisco.com 311 Owen Friel 312 Cisco Systems 313 170 W. Tasman Dr. 314 San Jose, CA 95134 315 United States 317 Email: ofriel@cisco.com