draft-ietf-opsawg-mud-23.txt   draft-ietf-opsawg-mud-24.txt 
Network Working Group E. Lear Network Working Group E. Lear
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R. Droms Intended status: Standards Track R. Droms
Expires: December 4, 2018 Google Expires: December 7, 2018 Google
D. Romascanu D. Romascanu
June 02, 2018 June 05, 2018
Manufacturer Usage Description Specification Manufacturer Usage Description Specification
draft-ietf-opsawg-mud-23 draft-ietf-opsawg-mud-24
Abstract Abstract
This memo specifies a component-based architecture for manufacturer This memo specifies a component-based architecture for manufacturer
usage descriptions (MUD). The goal of MUD is to provide a means for usage descriptions (MUD). The goal of MUD is to provide a means for
end devices to signal to the network what sort of access and network end devices to signal to the network what sort of access and network
functionality they require to properly function. The initial focus functionality they require to properly function. The initial focus
is on access control. Later work can delve into other aspects. is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2018. This Internet-Draft will expire on December 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Our work begins with the device emitting a Universal Resource Locator Our work begins with the device emitting a Universal Resource Locator
(URL) [RFC3986]. This URL serves both to classify the device type (URL) [RFC3986]. This URL serves both to classify the device type
and to provide a means to locate a policy file. and to provide a means to locate a policy file.
MUD URLs MUST use the HTTPS scheme [RFC7230]. MUD URLs MUST use the HTTPS scheme [RFC7230].
In this memo three means are defined to emit the MUD URL, as follows: In this memo three means are defined to emit the MUD URL, as follows:
o A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to o A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to
inform the DHCP server. The DHCP server may take further actions, inform the DHCP server. The DHCP server may take further actions,
such as act as the MUD manager or otherwise pass it along to the such as act as the MUD manager or otherwise pass the MUD URL along
MUD manager. to the MUD manager.
o An X.509 constraint. The IEEE has developed [IEEE8021AR] that o An X.509 constraint. The IEEE has developed [IEEE8021AR] that
provides a certificate-based approach to communicate device provides a certificate-based approach to communicate device
characteristics, which itself relies on [RFC5280]. The MUD URL characteristics, which itself relies on [RFC5280]. The MUD URL
extension is non-critical, as required by IEEE 802.1AR. Various extension is non-critical, as required by IEEE 802.1AR. Various
means may be used to communicate that certificate, including means may be used to communicate that certificate, including
Tunnel Extensible Authentication Protocol (TEAP) [RFC7170]. Tunnel Extensible Authentication Protocol (TEAP) [RFC7170].
o Finally, a Link Layer Discovery Protocol (LLDP) frame is defined o Finally, a Link Layer Discovery Protocol (LLDP) frame is defined
[IEEE8021AB]. [IEEE8021AB].
skipping to change at page 19, line 14 skipping to change at page 19, line 14
https://things.example.org/product_abc123/v5 https://things.example.org/product_abc123/v5
https://www.example.net/mudfiles/temperature_sensor/ https://www.example.net/mudfiles/temperature_sensor/
https://example.com/lightbulbs/colour/v1 https://example.com/lightbulbs/colour/v1
A manufacturer may construct a MUD URL in any way, so long as it A manufacturer may construct a MUD URL in any way, so long as it
makes use of the "https" schema. makes use of the "https" schema.
7. The MUD YANG Model 7. The MUD YANG Model
<CODE BEGINS>file "ietf-mud@2018-06-02.yang" <CODE BEGINS>file "ietf-mud@2018-06-05.yang"
module ietf-mud { module ietf-mud {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud";
prefix ietf-mud; prefix ietf-mud;
import ietf-access-control-list { import ietf-access-control-list {
prefix acl; prefix acl;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
skipping to change at page 20, line 16 skipping to change at page 20, line 16
identified as the document authors. All rights reserved. identified as the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-06-02 { revision 2018-06-05 {
description description
"Initial proposed standard."; "Initial proposed standard.";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
typedef direction { typedef direction {
type enumeration { type enumeration {
enum to-device { enum to-device {
skipping to change at page 26, line 34 skipping to change at page 26, line 34
specified by inet:host See the previous section relating to specified by inet:host See the previous section relating to
resolution. resolution.
Note when using either of these with a MUD file, because access is Note when using either of these with a MUD file, because access is
associated with a particular Thing, MUD files MUST NOT contain either associated with a particular Thing, MUD files MUST NOT contain either
a src-dnsname in an ACL associated with from-device-policy or a dst- a src-dnsname in an ACL associated with from-device-policy or a dst-
dnsname associated with to-device-policy. dnsname associated with to-device-policy.
8.3. The ietf-acldns Model 8.3. The ietf-acldns Model
<CODE BEGINS>file "ietf-acldns@2018-06-02.yang" <CODE BEGINS>file "ietf-acldns@2018-06-05.yang"
module ietf-acldns { module ietf-acldns {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-acldns"; namespace "urn:ietf:params:xml:ns:yang:ietf-acldns";
prefix ietf-acldns; prefix ietf-acldns;
import ietf-access-control-list { import ietf-access-control-list {
prefix acl; prefix acl;
} }
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
skipping to change at page 27, line 15 skipping to change at page 27, line 15
Author: Ralph Droms Author: Ralph Droms
rdroms@gmail.com rdroms@gmail.com
Author: Dan Romascanu Author: Dan Romascanu
dromasca@gmail.com dromasca@gmail.com
"; ";
description description
"This YANG module defines a component that augments the "This YANG module defines a component that augments the
IETF description of an access list to allow DNS names IETF description of an access list to allow DNS names
as matching criteria."; as matching criteria.";
revision 2018-06-02 { revision 2018-06-05 {
description description
"Base version of dnsname extension of ACL model"; "Base version of dnsname extension of ACL model";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
grouping dns-matches { grouping dns-matches {
description description
"Domain names for matching."; "Domain names for matching.";
skipping to change at page 36, line 26 skipping to change at page 36, line 26
-in mudfile -binary -outform DER -binary \ -in mudfile -binary -outform DER -binary \
-certfile intermediatecert -out mudfile.p7s -certfile intermediatecert -out mudfile.p7s
Note: A MUD file may need to be re-signed if the signature expires. Note: A MUD file may need to be re-signed if the signature expires.
13.2. Verifying a MUD file signature 13.2. Verifying a MUD file signature
Prior to processing the rest of a MUD file, the MUD manager MUST Prior to processing the rest of a MUD file, the MUD manager MUST
retrieve the MUD signature file by retrieving the value of "mud- retrieve the MUD signature file by retrieving the value of "mud-
signature" and validating the signature across the MUD file. The Key signature" and validating the signature across the MUD file. The Key
Usage Extension in the signing certificate MUST have the bit Usage Extension in the signing certificate MUST be present and have
digitalSignature(0) set. The subject of this certificate MUST be the bit digitalSignature(0) set. When the id-pe-mudsigner extension
equal to that of the value of id-pe-mudsigner when that extension is is present in a device's X.509 certificate, the MUD signature file
present in the device certificate. If these conditions are not met, MUST have been generated by a certificate whose subject matches the
or if it cannot validate the chain of trust to a known trust anchor, contents of that id-pe-mudsigner extension. If these conditions are
the MUD manager MUST cease processing the MUD file until an not met, or if it cannot validate the chain of trust to a known trust
anchor, the MUD manager MUST cease processing the MUD file until an
administrator has given approval. administrator has given approval.
The purpose of the signature on the file is to assign accountability The purpose of the signature on the file is to assign accountability
to an entity, whose reputation can be used to guide administrators on to an entity, whose reputation can be used to guide administrators on
whether or not to accept a given MUD file. It is already common whether or not to accept a given MUD file. It is already common
place to check web reputation on the location of a server on which a place to check web reputation on the location of a server on which a
file resides. While it is likely that the manufacturer will be the file resides. While it is likely that the manufacturer will be the
signer of the file, this is not strictly necessary, and may not be signer of the file, this is not strictly necessary, and may not be
desirable. For one thing, in some environments, integrators may desirable. For one thing, in some environments, integrators may
install their own certificates. For another, what is more important install their own certificates. For another, what is more important
skipping to change at page 38, line 19 skipping to change at page 38, line 19
in the introduction, a deployment may choose to ignore a MUD policy in the introduction, a deployment may choose to ignore a MUD policy
in its entirety, but simply taken into account the MUD URL as a in its entirety, but simply taken into account the MUD URL as a
classifier to be used as part of a local policy decision. classifier to be used as part of a local policy decision.
Finally, please see directly below regarding device lifetimes and use Finally, please see directly below regarding device lifetimes and use
of domain names. of domain names.
16. Security Considerations 16. Security Considerations
Based on how a MUD URL is emitted, a Thing may be able to lie about Based on how a MUD URL is emitted, a Thing may be able to lie about
what it is, thus gaining additional network access. This happens what it is, thus gaining additional network access. This can happen
when a device emits a MUD URL using DHCP or LLDP, and is either in a number of ways when a device emits a MUD URL using DHCP or LLDP,
inappropriately admitted to a class such as "same-manufacturer" or such as being inappropriately admitted to a class such as "same-
given access to a device such as "my-controller", where such access manufacturer", given access to a device such as "my-controller", or
being permitted access to an Internet resource, where such access
would otherwise be disallowed. Whether that is the case will depend would otherwise be disallowed. Whether that is the case will depend
on the deployment. Implementations SHOULD be configurable to on the deployment. Implementations SHOULD be configurable to
disallow additive access for devices using MUD-URLs that not emitted disallow additive access for devices using MUD-URLs that are not
in a secure fashion such as in a certificate. Similarly, emitted in a secure fashion such as in a certificate. Similarly,
implementations SHOULD NOT grant elevated permissions (beyond those implementations SHOULD NOT grant elevated permissions (beyond those
of devices presenting no MUD policy) to devices which do not strongly of devices presenting no MUD policy) to devices which do not strongly
bind their identity to their L2/L3 transmissions. When insecure bind their identity to their L2/L3 transmissions. When insecure
methods are used by the MUD Manager, the classes SHOULD NOT contain methods are used by the MUD Manager, the classes SHOULD NOT contain
devices that use both insecure and secure methods, in order to devices that use both insecure and secure methods, in order to
prevent privilege escalation attacks, and MUST NOT contain devices prevent privilege escalation attacks, and MUST NOT contain devices
with the same MUD-URL that are derived from both strong and weak with the same MUD-URL that are derived from both strong and weak
authentication methods. authentication methods.
Devices may forge source (L2/L3) information. Deployments should Devices may forge source (L2/L3) information. Deployments should
skipping to change at page 39, line 12 skipping to change at page 39, line 13
changes, the MUD manager SHOULD seek administrator approval (it changes, the MUD manager SHOULD seek administrator approval (it
should do this in any case). In all circumstances, the MUD manager should do this in any case). In all circumstances, the MUD manager
MUST maintain a cache of trusted CAs for this purpose. When such a MUST maintain a cache of trusted CAs for this purpose. When such a
rogue is discovered, it SHOULD be removed. rogue is discovered, it SHOULD be removed.
Additional mitigations are described below. Additional mitigations are described below.
When certificates are not present, Things claiming to be of a certain When certificates are not present, Things claiming to be of a certain
manufacturer SHOULD NOT be included in that manufacturer grouping manufacturer SHOULD NOT be included in that manufacturer grouping
without additional validation of some form. This will be relevant without additional validation of some form. This will be relevant
when it makes use of primitives such as "manufacturer" for the whenthe MUD manager makes use of primitives such as "manufacturer"
purpose of accessing Things of a particular type. Similarly, network for the purpose of accessing Things of a particular type. Similarly,
management systems may be able to fingerprint the Thing. In such network management systems may be able to fingerprint the Thing. In
cases, the MUD URL can act as a classifier that can be proven or such cases, the MUD URL can act as a classifier that can be proven or
disproven. Fingerprinting may have other advantages as well: when disproven. Fingerprinting may have other advantages as well: when
802.1AR certificates are used, because they themselves cannot change, 802.1AR certificates are used, because they themselves cannot change,
fingerprinting offers the opportunity to add artifacts to the MUD fingerprinting offers the opportunity to add artifacts to the MUD
string in the form of the reserved field discussed in Section 10. string in the form of the reserved field discussed in Section 10.
The meaning of such artifacts is left as future work. The meaning of such artifacts is left as future work.
MUD managers SHOULD NOT accept a usage description for a Thing with MUD managers SHOULD NOT accept a usage description for a Thing with
the same MAC address that has indicated a change of the URL authority the same MAC address that has indicated a change of the URL authority
without some additional validation (such as review by a network without some additional validation (such as review by a network
administrator). New Things that present some form of unauthenticated administrator). New Things that present some form of unauthenticated
skipping to change at page 57, line 23 skipping to change at page 57, line 23
] ]
} }
} }
] ]
} }
Appendix C. A Sample Extension: DETNET-indicator Appendix C. A Sample Extension: DETNET-indicator
In this sample extension we augment the core MUD model to indicate In this sample extension we augment the core MUD model to indicate
whether the device implements DETNET. If a device claims not to use whether the device implements DETNET. If a device claims not to use
NETNET, but then later attempts to do so, a notification or exception DETNET, but then later attempts to do so, a notification or exception
might be generated. Note that this example is intended only for might be generated. Note that this example is intended only for
illustrative purposes. illustrative purposes.
Extension Name: "Example-Extension" (to be used in the extensions list) Extension Name: "Example-Extension" (to be used in the extensions list)
Standard: this document (but do not register the example) Standard: this document (but do not register the example)
This extension augments the MUD model to include a single node, using This extension augments the MUD model to include a single node, using
the following sample module that has the following tree structure: the following sample module that has the following tree structure:
module: ietf-mud-detext-example module: ietf-mud-detext-example
augment /ietf-mud:mud: augment /ietf-mud:mud:
+--rw is-detnet-required? boolean +--rw is-detnet-required? boolean
The model is defined as follows: The model is defined as follows:
<CODE BEGINS>file "ietf-mud-detext-example@2018-06-02.yang" <CODE BEGINS>file "ietf-mud-detext-example@2018-06-05.yang"
module ietf-mud-detext-example { module ietf-mud-detext-example {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example"; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-detext-example";
prefix ietf-mud-detext-example; prefix ietf-mud-detext-example;
import ietf-mud { import ietf-mud {
prefix ietf-mud; prefix ietf-mud;
} }
organization organization
"IETF OPSAWG (Ops Area) Working Group"; "IETF OPSAWG (Ops Area) Working Group";
skipping to change at page 58, line 21 skipping to change at page 58, line 21
Author: Ralph Droms Author: Ralph Droms
rdroms@gmail.com rdroms@gmail.com
Author: Dan Romascanu Author: Dan Romascanu
dromasca@gmail.com dromasca@gmail.com
"; ";
description description
"Sample extension to a MUD module to indicate a need "Sample extension to a MUD module to indicate a need
for DETNET support."; for DETNET support.";
revision 2018-06-02 { revision 2018-06-05 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Manufacturer Usage Description "RFC XXXX: Manufacturer Usage Description
Specification"; Specification";
} }
augment "/ietf-mud:mud" { augment "/ietf-mud:mud" {
description description
"This adds a simple extension for a manufacturer "This adds a simple extension for a manufacturer
 End of changes. 16 change blocks. 
29 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/