idnits 2.17.1 draft-richardson-opsawg-securehomegateway-mud-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 abstract seems to contain references ([I-D.ietf-opsawg-mud]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2018) is 2048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational J. Latour 5 Expires: March 21, 2019 CIRA Labs 6 F. Khan 7 Twelve Dot Systems 8 September 17, 2018 10 MUD processing and extensions for Secure Home Gateway Project 11 draft-richardson-opsawg-securehomegateway-mud-00 13 Abstract 15 This document details the mechanism used by the CIRA Secure Home 16 Gateway and CIRA MUD integration server to return MUD artifacts to 17 participating gateway systems. 19 The work in [I-D.ietf-opsawg-mud] creates a relationship between a 20 device's manufacturer and a border gateway that may need to enforce 21 policy. This document ads an additional relationship to a service 22 provider, trusted by the border gateway to enhance or modify the 23 stated security policy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 21, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 4. MUD file extensions . . . . . . . . . . . . . . . . . . . . . 3 63 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 64 4.2. YANG FILE . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 The initial extension from this document is to provide for a way to 74 mark a set of ACLs as being enabled even though the device has 75 quaranteed. {EDNOTE: more motivational text here} 77 The second issue addressed by the document is the question of whether 78 and when the MUD file should be specific to a specific version of the 79 device firmware. 81 The third issue is that an intermediary (ISP, or third-party security 82 service) may want to extend or amend a MUD file received from a 83 manufacturer. In order to maintain an audit trail of changes, a way 84 to encode the previous MUD URL and signature file (and status) is 85 provided. 87 2. Terminology 89 The major new term, compared to the MUD document is the term 91 quaranteed: a device which has shown behaviour forbidden by a MUD 92 file ACL, and has subsequently been denied further access to the 93 network. 95 3. Requirements Language 97 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 98 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 99 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 100 [RFC2119] and indicate requirement levels for compliant STuPiD 101 implementations. 103 4. MUD file extensions 105 4.1. Tree Diagram 107 module: cira-shg-mud 108 augment /m:mud: 109 +--rw quaranteed-device-policy 110 +--rw access-lists 111 +--rw access-list* [name] 112 +--rw name -> /acl:acls/acl/name 114 4.2. YANG FILE 116 file "cira-shg-mud@2017-12-11.yang" 117 module cira-shg-mud { 118 yang-version 1.1; 120 namespace 121 "urn:ietf:params:xml:ns:yang:ietf-shg-mud"; 122 prefix "shg"; 124 import ietf-mud { 125 prefix m; 126 description "This module defines the format for a MUD description"; 127 reference "RFC YYYY: MUD YANG"; 128 } 130 organization "CIRALabs Secure Home Gateway project."; 132 contact 133 "WG Web: 134 WG List: 135 Author: Michael Richardson 136 "; 138 description 139 "This module extends the RFCXXXX MUD format to include two 140 facilities: definition of an Access Control List appropriate 141 to enable device upgrade only, and provide for a history of 142 modifications by third-parties to the MUD file"; 144 revision "2017-12-11" { 145 description 146 "Initial version"; 147 reference 148 "RFC XXXX: MUD profile for Secure Home Gateway Project"; 149 } 151 augment "/m:mud" { 152 description 153 "Adds leaf nodes appropriate MUD usage in the 154 Secure Home Gateway"; 156 container quaranteed-device-policy { 157 description 158 "The policies that should be enforced on traffic 159 coming from the device when it is under quaranteen. 160 These policies are usually a subset of operational policies 161 and are intended to permit firmware updates only. 162 They are intended to keep the device safe (and the network safe 163 from the device) when the device is suspected of being 164 out-of-date, but still considered sufficiently intact to be 165 able to do a firmware update"; 166 uses m:access-lists; 167 } 168 } 170 } 172 174 5. Security Considerations 176 TBD. 178 6. IANA Considerations 180 TBD. 182 7. Acknowledgements 184 This work was supported by the Canadian Internet Registration 185 Authority (cira.ca). 187 8. Normative References 189 [I-D.ietf-opsawg-mud] 190 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 191 Description Specification", draft-ietf-opsawg-mud-25 (work 192 in progress), June 2018. 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, 196 DOI 10.17487/RFC2119, March 1997, 197 . 199 Authors' Addresses 201 Michael Richardson 202 Sandelman Software Works 204 Email: mcr+ietf@sandelman.ca 206 Jacques Latour 207 CIRA Labs 209 Email: Jacques.Latour@cira.ca 211 Faud Khan 212 Twelve Dot Systems 214 Email: faud.khan@twelvedot.com