draft-ietf-opsawg-mud-tls-01.txt   draft-ietf-opsawg-mud-tls-02.txt 
OPSAWG WG T. Reddy OPSAWG WG T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: April 8, 2021 Citrix Expires: April 24, 2021 Citrix
B. Anderson B. Anderson
Cisco Cisco
October 5, 2020 October 21, 2020
Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices
draft-ietf-opsawg-mud-tls-01 draft-ietf-opsawg-mud-tls-02
Abstract Abstract
This memo extends the Manufacturer Usage Description (MUD) This memo extends the Manufacturer Usage Description (MUD)
specification to incorporate (D)TLS profile parameters. This allows specification to incorporate (D)TLS profile parameters. This allows
a network security service to identify unexpected (D)TLS usage, which a network security service to identify unexpected (D)TLS usage, which
can indicate the presence of unauthorized software or malware on an can indicate the presence of unauthorized software or malware on an
endpoint. endpoint.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 8, 2021. This Internet-Draft will expire on April 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 2, line 15 skipping to change at page 2, line 15
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5
4. (D)TLS 1.3 Handshake . . . . . . . . . . . . . . . . . . . . 6 4. (D)TLS 1.3 Handshake . . . . . . . . . . . . . . . . . . . . 6
4.1. Full (D)TLS 1.3 Handshake Inspection . . . . . . . . . . 6 4.1. Full (D)TLS 1.3 Handshake Inspection . . . . . . . . . . 6
4.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 7
5. (D)TLS Profile YANG Module . . . . . . . . . . . . . . . . . 7 5. (D)TLS Profile of a IoT device . . . . . . . . . . . . . . . 7
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 9 5.1. Tree Structure of the (D)TLS profile Extension to the ACL
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10 YANG Model . . . . . . . . . . . . . . . . . . . . . . . 9
6. Processing of the MUD (D)TLS Profile . . . . . . . . . . . . 16 5.2. The (D)TLS profile Extension to the ACL YANG Model . . . 10
7. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 17 5.3. IANA (D)TLS profile YANG Module . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5.4. MUD (D)TLS Profile Extension . . . . . . . . . . . . . . 18
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 6. Processing of the MUD (D)TLS Profile . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 21 10.1. (D)TLS Profile YANG Modules . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 10.2. TLS Version registry . . . . . . . . . . . . . . . . . . 25
10.3. DTLS version registry . . . . . . . . . . . . . . . . . 26
10.4. (D)TLS Parameters registry . . . . . . . . . . . . . . . 26
10.5. MUD Extensions registry . . . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Encryption is necessary to enhance the privacy of end users using IoT Encryption is necessary to enhance the privacy of end users using IoT
devices. TLS [RFC8446] and DTLS [I-D.ietf-tls-dtls13] are the devices. TLS [RFC8446] and DTLS [I-D.ietf-tls-dtls13] are the
dominant protocols providing encryption for IoT device traffic. dominant protocols (counting all (D)TLS versions) providing
Unfortunately, in conjunction with IoT applications' rise of encryption for IoT device traffic. Unfortunately, in conjunction
encryption, malware is also using encryption which thwarts network- with IoT applications' rise of encryption, malware authors are also
based analysis such as deep packet inspection (DPI). Other using encryption which thwarts network-based analysis such as deep
mechanisms are needed to detect malware running on an IoT device. packet inspection (DPI). Other mechanisms are thus needed to help
detecting malware running on an IoT device.
Malware frequently uses its own libraries for its activities, and Malware frequently uses proprietary libraries for its activities, and
those libraries are re-used much like any other software engineering those libraries are reused much like any other software engineering
project. [malware] indicates that there are observable differences in project. [malware] indicates that there are observable differences in
how malware uses encryption compared with how non-malware uses how malware uses encryption compared with how non-malware uses
encryption. There are several interesting findings specific to encryption. There are several interesting findings specific to
(D)TLS which were found common to malware: (D)TLS which were found common to malware:
o Older and weaker cryptographic parameters (e.g., o Older and weaker cryptographic parameters (e.g.,
TLS_RSA_WITH_RC4_128_SHA). TLS_RSA_WITH_RC4_128_SHA).
o TLS server name indication (SNI) extension and server certificates o TLS server name indication (SNI) extension [RFC6066] and server
are composed of subjects with characteristics of a domain certificates are composed of subjects with characteristics of a
generation algorithm (DGA) (e.g., www.33mhwt2j.net). domain generation algorithm (DGA) (e.g., 'www.33mhwt2j.net').
o Higher use of self-signed certificates compared with typical o Higher use of self-signed certificates compared with typical
legitimate software. legitimate software.
o Discrepancies in the SNI TLS extension and the DNS names in the o Discrepancies in the SNI TLS extension and the DNS names in the
SubjectAltName (SAN) X.509 extension in the server certificate SubjectAltName (SAN) X.509 extension in the server certificate
message. message.
o Discrepancies in the key exchange algorithm and the client public o Discrepancies in the key exchange algorithm and the client public
key length in comparison with legitimate flows. As a reminder, key length in comparison with legitimate flows. As a reminder,
skipping to change at page 4, line 10 skipping to change at page 4, line 17
Certificate message thereby hiding the server identity from any Certificate message thereby hiding the server identity from any
intermediary. In TLS 1.3, the server certificate validation intermediary. In TLS 1.3, the server certificate validation
functions should be executed within an on-path TLS proxy, if such functions should be executed within an on-path TLS proxy, if such
a proxy exists. a proxy exists.
o Support new communication patterns. An IoT device can learn a new o Support new communication patterns. An IoT device can learn a new
capability, and the new capability can change the way the IoT capability, and the new capability can change the way the IoT
device communicates with other devices located in the local device communicates with other devices located in the local
network and Internet. There would be an inaccurate policy if an network and Internet. There would be an inaccurate policy if an
IoT device rapidly changes the IP addresses and domain names it IoT device rapidly changes the IP addresses and domain names it
communicates with while the MUD ACLs were slower to update. In communicates with while the MUD ACLs were slower to update (see
such a case, observable (D)TLS profile parameters can be used to [clear-as-mud]). In such a case, observable (D)TLS profile
permit intended use and to block malicious behavior from the IoT parameters can be used to permit intended use and to block
device. malicious behavior from the IoT device.
This document extends MUD [RFC8520] to model observable (D)TLS The YANG module specified in Section 5 of this document is an
profile parameters. Using these (D)TLS profile parameters, an active extension of YANG Data Model for Network Access Control Lists (ACLs)
MUD-enforcing network security service (e.g., firewall) can identify [RFC8519] to enhance MUD [RFC8520] to model observable (D)TLS profile
MUD non-compliant (D)TLS behavior indicating outdated cryptography or parameters. Using these (D)TLS profile parameters, an active MUD-
enforcing network security service (e.g., firewall) can identify MUD
non-compliant (D)TLS behavior indicating outdated cryptography or
malware. This detection can prevent malware downloads, block access malware. This detection can prevent malware downloads, block access
to malicious domains, enforce use of strong ciphers, stop data to malicious domains, enforce use of strong ciphers, stop data
exfiltration, etc. In addition, organizations may have policies exfiltration, etc. In addition, organizations may have policies
around acceptable ciphers and certificates for the websites the IoT around acceptable ciphers and certificates for the websites the IoT
devices connect to. Examples include no use of old and less secure devices connect to. Examples include no use of old and less secure
versions of TLS, no use of self-signed certificates, deny-list or versions of TLS, no use of self-signed certificates, deny-list or
accept-list of Certificate Authorities, valid certificate expiration accept-list of Certificate Authorities, valid certificate expiration
time, etc. These policies can be enforced by observing the (D)TLS time, etc. These policies can be enforced by observing the (D)TLS
profile parameters. Network security services can use the IoT profile parameters. Network security services can use the IoT
device's (D)TLS profile parameters to identify legitimate flows by device's (D)TLS profile parameters to identify legitimate flows by
skipping to change at page 5, line 19 skipping to change at page 5, line 26
visibility on the devices where they are installed, whereas the visibility on the devices where they are installed, whereas the
network has broader visibility. Installing host security agents may network has broader visibility. Installing host security agents may
not be a viable option on IoT devices, and network-based security is not be a viable option on IoT devices, and network-based security is
an efficient means to protect such IoT devices. If the IoT device an efficient means to protect such IoT devices. If the IoT device
supports a MUD (D)TLS profile, the (D)TLS profile parameters of the supports a MUD (D)TLS profile, the (D)TLS profile parameters of the
IoT device can be used by a middlebox to detect and block malware IoT device can be used by a middlebox to detect and block malware
communication, while at the same time preserving the privacy of communication, while at the same time preserving the privacy of
legitimate uses of encryption. The middlebox need not proxy (D)TLS legitimate uses of encryption. The middlebox need not proxy (D)TLS
but can passively observe the parameters of (D)TLS handshakes from but can passively observe the parameters of (D)TLS handshakes from
IoT devices and gain visibility into TLS 1.2 parameters and partial IoT devices and gain visibility into TLS 1.2 parameters and partial
visibility into TLS 1.3 parameters. Malicious agents can try to use visibility into TLS 1.3 parameters.
the (D)TLS profile parameters of legitimate agents to evade
detection, but it becomes a challenge to mimic the behavior of Malicious agents can try to use the (D)TLS profile parameters of
various IoT device types and IoT device models from several legitimate agents to evade detection, but it becomes a challenge to
manufacturers. In other words, malware developers will have to mimic the behavior of various IoT device types and IoT device models
develop malicious agents per IoT device type, manufacturer and model, from several manufacturers. In other words, malware developers will
infect the device with the tailored malware agent and will have keep have to develop malicious agents per IoT device type, manufacturer
up with updates to the device's (D)TLS profile parameters over time. and model, infect the device with the tailored malware agent and will
Furthermore, the malware's command and control server certificates have keep up with updates to the device's (D)TLS profile parameters
need to be signed by the same certifying authorities trusted by the over time. Furthermore, the malware's command and control server
IoT devices. Typically, IoT devices have an infrastructure that certificates need to be signed by the same certifying authorities
supports a rapid deployment of updates, and malware agents will have trusted by the IoT devices. Typically, IoT devices have an
a near-impossible task of similarly deploying updates and continuing infrastructure that supports a rapid deployment of updates, and
to mimic the TLS behavior of the IoT device it has infected. malware agents will have a near-impossible task of similarly
However, if the IoT device has reached end-of-life and the IoT deploying updates and continuing to mimic the TLS behavior of the IoT
manufcaturer will not issue a firmware or software update to the device it has infected. However, if the IoT device has reached end-
Thing or will not update the MUD file, the "is-supported" attribute of-life and the IoT manufcaturer will not issue a firmware or
defined in Section 3.6 of [RFC8520] can be used by the MUD manager to software update to the Thing or will not update the MUD file, the
identify the IoT manufcaturer no longer supports the device. The "is-supported" attribute defined in Section 3.6 of [RFC8520] can be
end-of-life of a device does not necessarily mean that it is used by the MUD manager to identify the IoT manufcaturer no longer
supports the device.
The end-of-life of a device does not necessarily mean that it is
defective; rather, it denotes a need to replace and upgrade the defective; rather, it denotes a need to replace and upgrade the
network to next-generation devices for additional functionality. The network to next-generation devices for additional functionality. The
network security service will have to rely on other techniques network security service will have to rely on other techniques
discussed in Section 8 to identify malicious connections until the discussed in Section 8 to identify malicious connections until the
device is replaced. device is replaced.
Compromised IoT devices are typically used for launching DDoS attacks Compromised IoT devices are typically used for launching DDoS attacks
(Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris (Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris
and Transport Layer Security (TLS) re-negotiation can be blocked if and Transport Layer Security (TLS) re-negotiation can be blocked if
the victim's server certificate is not be signed by the same the victim's server certificate is not be signed by the same
skipping to change at page 6, line 36 skipping to change at page 6, line 44
To obtain more visibility into negotiated TLS 1.3 parameters, a To obtain more visibility into negotiated TLS 1.3 parameters, a
middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a
(D)TLS proxy for the IoT devices owned and managed by the IT team in (D)TLS proxy for the IoT devices owned and managed by the IT team in
the Enterprise network and the (D)TLS proxy must meet the security the Enterprise network and the (D)TLS proxy must meet the security
and privacy requirements of the organization. In other words, the and privacy requirements of the organization. In other words, the
scope of middlebox acting as a (D)TLS proxy is restricted to scope of middlebox acting as a (D)TLS proxy is restricted to
Enterprise network owning and managing the IoT devices. The Enterprise network owning and managing the IoT devices. The
middlebox would have to follow the behaviour detailed in Section 9.3 middlebox would have to follow the behaviour detailed in Section 9.3
of [RFC8446] to act as a compliant (D)TLS 1.3 proxy. of [RFC8446] to act as a compliant (D)TLS 1.3 proxy.
To further increase privacy, encrypted client hello To further increase privacy, Encrypted Client Hello (ECH) extension
[I-D.ietf-tls-esni] prevents passive observation of the TLS Server [I-D.ietf-tls-esni] prevents passive observation of the TLS Server
Name Indication extension. To effectively provide that privacy Name Indication extension and other potentially sensitive fields,
protection, SNI encryption needs to be used in conjunction with DNS such as the ALPN [RFC7301]. To effectively provide that privacy
protection, ECH extension needs to be used in conjunction with DNS
encryption (e.g., DoH). A middlebox (e.g., firewall) passively encryption (e.g., DoH). A middlebox (e.g., firewall) passively
inspecting an encrypted SNI (D)TLS handshake cannot observe the inspecting ECH extension cannot observe the encrypted SNI nor observe
encrypted SNI nor observe the encrypted DNS traffic. the encrypted DNS traffic.
4.2. Encrypted DNS 4.2. Encrypted DNS
A common usage pattern for certain type of IoT devices (e.g., light A common usage pattern for certain type of IoT devices (e.g., light
bulb) is for it to "call home" to a service that resides on the bulb) is for it to "call home" to a service that resides on the
public Internet, where that service is referenced through a domain public Internet, where that service is referenced through a domain
name (A or AAAA record). As discussed in Manufacturer Usage name (A or AAAA record). As discussed in Manufacturer Usage
Description Specification [RFC8520], because these devices tend to Description Specification [RFC8520], because these devices tend to
require access to very few sites, all other access should be require access to very few sites, all other access should be
considered suspect. If an IoT device is pre-configured to use public considered suspect. If an IoT device is pre-configured to use public
DoH/DoT server, the MUD policy enforcement point is moved to that DoH/DoT server, the MUD policy enforcement point is moved to that
public server, which cannot enforce the MUD policy based on domain public server, which cannot enforce the MUD policy based on domain
names (Section 8 of [RFC8520]). If the DNS query is not accessible names (Section 8 of [RFC8520]). If the DNS query is not accessible
for inspection, it becomes quite difficult for the infrastructure to for inspection, it becomes quite difficult for the infrastructure to
suspect anything. Thus the use of a public DoH/DoT server is suspect anything. Thus the use of a public DoH/DoT server is
incompatible with MUD in general. A local DoH/DoT server is incompatible with MUD in general. A local DoH/DoT server is
necessary to allow MUD policy enforcement on the local network necessary to allow MUD policy enforcement on the local network
[I-D.reddy-add-enterprise]. [I-D.reddy-add-enterprise].
5. (D)TLS Profile YANG Module 5. (D)TLS Profile of a IoT device
This document specifies a YANG module for representing (D)TLS This document specifies a YANG module for representing (D)TLS
profile. The (D)TLS profile YANG module provides a method for profile. The (D)TLS profile YANG module provides a method for
network security services to observe the (D)TLS profile parameters in network security services to observe the (D)TLS profile parameters in
the (D)TLS handshake to permit intended use and to block malicious the (D)TLS handshake to permit intended use and to block malicious
behavior. This module uses the common YANG types defined in behavior. This module uses the cryptographic types defined in
[RFC6991], the rules defined in [RFC8519], and the cryptographic [I-D.ietf-netconf-crypto-types]. See [RFC7925] for (D)TLS 1.2 and
types defined in [I-D.ietf-netconf-crypto-types]. See [RFC7925] for [I-D.ietf-uta-tls13-iot-profile] for DTLS 1.3 recommendations related
(D)TLS 1.2 and [I-D.ietf-uta-tls13-iot-profile] for DTLS 1.3 to IoT devices, and [RFC7525] for additional (D)TLS 1.2
recommendations related to IoT devices, and [RFC7525] for additional recommendations.
(D)TLS 1.2 recommendations.
A companion YANG module is defined to include a collection of (D)TLS
parameters and (D)TLS versions maintained by IANA: "iana-tls-profile"
(Section 5.3).
The (D)TLS parameters in each (D)TLS profile include the following: The (D)TLS parameters in each (D)TLS profile include the following:
o Profile name o Profile name
o (D)TLS versions supported by the IoT device. o (D)TLS versions supported by the IoT device.
o List of supported cipher suites. For (D)TLS1.2, [RFC7925] o List of supported cipher suites. For (D)TLS1.2, [RFC7925]
recommends AEAD ciphers for IoT devices. recommends AEAD ciphers for IoT devices.
skipping to change at page 9, line 15 skipping to change at page 9, line 28
The (D)TLS profile does not include parameters like compression The (D)TLS profile does not include parameters like compression
methods for data compression, [RFC7525] recommends disabling TLS- methods for data compression, [RFC7525] recommends disabling TLS-
level compression to prevent compression-related attacks. In TLS level compression to prevent compression-related attacks. In TLS
1.3, only the "null" compression method is allowed (Section 4.1.2 of 1.3, only the "null" compression method is allowed (Section 4.1.2 of
[RFC8446]). [RFC8446]).
Note: The TLS and DTLS IANA registries are available from Note: The TLS and DTLS IANA registries are available from
<https://www.iana.org/assignments/tls-parameters/tls-parameters.txt> <https://www.iana.org/assignments/tls-parameters/tls-parameters.txt>
and <https://www.iana.org/assignments/tls-extensiontype-values/tls- and <https://www.iana.org/assignments/tls-extensiontype-values/tls-
extensiontype-values.txt>. The values for all the parameters in the extensiontype-values.txt>. The values for all the parameters in the
YANG module excluding the supported_versions parameter are defined in YANG module excluding the are defined in the TLS and DTLS IANA
the TLS and DTLS IANA registries. The TLS and DTLS IANA registry registries excluding the supported_tls_versions and
supported_dtls_versions parameters. The TLS and DTLS IANA registry
does not maintain (D)TLS version numbers. does not maintain (D)TLS version numbers.
5.1. Tree Structure 5.1. Tree Structure of the (D)TLS profile Extension to the ACL YANG
Model
This document augments the "ietf-mud" MUD YANG module defined in This document augments the "ietf-acl" ACL YANG module defined in
[RFC8520] for signaling the IoT device (D)TLS profile. This document [RFC8519] for signaling the IoT device (D)TLS profile. This document
defines the YANG module "iana-opsawg-mud-tls-profile", which has the defines the YANG module "ietf-acl-tls", which has the following tree
following tree structure: structure:
module: iana-opsawg-mud-tls-profile module: ietf-acl-tls
augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
+--rw client-profile +--rw client-profile {match-on-tls-dtls}?
+--rw tls-dtls-profiles* [profile-name] +--rw client-profile
+--rw profile-name string +--rw tls-dtls-profiles* [profile-name]
+--rw supported_tls_versions* tls-version +--rw profile-name string
+--rw supported_dtls_versions* dtls-version +--rw supported-tls-versions* ianatp:tls-version
+--rw cipher-suites* [cipher aead] +--rw supported-dtls-versions* ianatp:dtls-version
| +--rw cipher cipher-algorithm +--rw cipher-suites* [cipher aead]
| +--rw aead aead-algorithm | +--rw cipher ianatp:cipher-algorithm
+--rw extension-types* extension-type | +--rw aead ianatp:aead-algorithm
+--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms +--rw extension-types*
+--rw SPKI | ianatp:extension-type
| +--rw SPKI-pin-sets* SPKI-pin-set +--rw acceptlist-ta-certs*
| +--rw SPKI-hash-algorithm? iha:hash-algorithm-type | ct:trust-anchor-cert-cms
+--rw psk-key-exchange-modes* psk-key-exchange-mode {tls-1_3 or dtls-1_3}? +--rw SPKI
+--rw supported-groups* supported-group | +--rw SPKI-pin-sets* ianatp:SPKI-pin-set
+--rw signature-algorithms-cert* signature-algorithm {tls-1_3 or dtls-1_3}? | +--rw SPKI-hash-algorithm? iha:hash-algorithm-type
+--rw signature-algorithms* signature-algorithm +--rw psk-key-exchange-modes*
+--rw application-protocols* application-protocol | ianatp:psk-key-exchange-mode
+--rw cert-compression-algorithms* cert-compression-algorithm {tls-1_3 or dtls-1_3}? | {tls-1-3 or dtls-1-3}?
+--rw certificate_authorities* certificate_authority {tls-1_3 or dtls-1_3}? +--rw supported-groups*
| ianatp:supported-group
+--rw signature-algorithms-cert*
| ianatp:signature-algorithm
| {tls-1-3 or dtls-1-3}?
+--rw signature-algorithms*
| ianatp:signature-algorithm
+--rw application-protocols*
| ianatp:application-protocol
+--rw cert-compression-algorithms*
| ianatp:cert-compression-algorithm
| {tls-1-3 or dtls-1-3}?
+--rw certificate_authorities*
ianatp:certificate_authority
{tls-1-3 or dtls-1-3}?
5.2. YANG Module 5.2. The (D)TLS profile Extension to the ACL YANG Model
<CODE BEGINS> file "iana-opsawg-mud-tls-profile@2020-09-25.yang" <CODE BEGINS> file "ietf-acl-tls@2020-10-07.yang"
module iana-opsawg-mud-tls-profile { module ietf-acl-tls {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-opsawg-mud-tls-profile"; namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls";
prefix mud-tls-profile; prefix ietf-acl-tls;
import ietf-crypto-types { import iana-tls-profile {
prefix ct; prefix ianatp;
reference "draft-ietf-netconf-crypto-types-01: reference
Common YANG Data Types for Cryptography"; "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS
} Profiles for IoT Devices";
}
import ietf-crypto-types {
prefix ct;
reference
"RFC CCCC: Common YANG Data Types for Cryptography";
}
import iana-hash-algs {
prefix iha;
reference
"RFC IIII: Common YANG Data Types for
Hash algorithms";
}
import ietf-access-control-list {
prefix acl;
reference
"RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)";
}
import iana-hash-algs { organization
prefix iha; "IETF OPSAWG (Operations and Management Area Working Group)";
reference contact
"RFC XXXX: Common YANG Data Types for Hash algorithms"; "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
} WG List: opsawg@ietf.org
import ietf-access-control-list { Author: Konda, Tirumaleswar Reddy
prefix acl; TirumaleswarReddy_Konda@McAfee.com
reference ";
"RFC 8519: YANG Data Model for Network Access description
Control Lists (ACLs)"; "This YANG moudle defines a component that augments the
} IETF description of an access list to allow (D)TLS profile
as matching criteria.
organization Copyright (c) 2020 IETF Trust and the persons identified as
"IETF Operations and Management Area Working Group Working Group"; authors of the code. All rights reserved.
contact
"Editor: Konda, Tirumaleswar Reddy
<mailto:TirumaleswarReddy_Konda@McAfee.com>";
description Redistribution and use in source and binary forms, with or
"This module contains YANG definition for the IoT device without modification, is permitted pursuant to, and subject
(D)TLS profile. to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Copyright (c) 2019 IETF Trust and the persons identified as This version of this YANG module is part of RFC XXXX; see
authors of the code. All rights reserved. the RFC itself for full legal notices.";
Redistribution and use in source and binary forms, with or revision 2020-10-07 {
without modification, is permitted pursuant to, and subject description
to the license terms contained in, the Simplified BSD License "Initial revision";
set forth in Section 4.c of the IETF Trust's Legal Provisions reference
Relating to IETF Documents "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS
(http://trustee.ietf.org/license-info). Profiles for IoT Devices";
This version of this YANG module is part of RFC XXXX; see }
the RFC itself for full legal notices.";
revision 2019-06-12 { feature tls-1-2 {
description
"TLS Protocol Version 1.2 is supported.";
reference
"RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2";
}
feature tls-1-3 {
description
"TLS Protocol Version 1.3 is supported.";
reference
"RFC 8446: The Transport Layer Security (TLS) Protocol
Version 1.3";
}
feature dtls-1-2 {
description
"DTLS Protocol Version 1.2 is supported.";
reference
"RFC 6346: Datagram Transport Layer Security Version 1.2";
}
feature dtls-1-3 {
description
"DTLS Protocol Version 1.3 is supported.";
reference
"draft-ietf-tls-dtls13: Datagram Transport Layer Security 1.3";
}
feature match-on-tls-dtls {
description
"The networking device can support matching on (D)TLS parameters.";
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
if-feature "match-on-tls-dtls";
description
"(D)TLS specific matches.";
container client-profile {
description
"A grouping for (D)TLS profiles.";
container client-profile {
description
"A grouping for DTLS profiles.";
list tls-dtls-profiles {
key "profile-name";
description
"A list of (D)TLS version profiles supported by the client.";
leaf profile-name {
type string {
length "1..64";
}
description
"The name of (D)TLS profile; space and special
characters are not allowed.";
}
leaf-list supported-tls-versions {
type ianatp:tls-version;
description
"TLS versions supported by the client";
}
leaf-list supported-dtls-versions {
type ianatp:dtls-version;
description
"DTLS versions supported by the client";
}
list cipher-suites {
key "cipher aead";
leaf cipher {
type ianatp:cipher-algorithm;
description
"Cipher";
}
leaf aead {
type ianatp:aead-algorithm;
description
"AEAD";
}
description
"Cipher Suites";
}
leaf-list extension-types {
type ianatp:extension-type;
description
"Extension Types";
}
leaf-list acceptlist-ta-certs {
type ct:trust-anchor-cert-cms;
description
"A list of trust anchor certificates used by the client.";
}
container SPKI {
description
"A grouping for SPKI.";
leaf-list SPKI-pin-sets {
type ianatp:SPKI-pin-set;
description
"A list of SPKI pin sets pre-configured on the client
to validate self-signed server certificate or
raw public key.";
}
leaf SPKI-hash-algorithm {
type iha:hash-algorithm-type;
description
"cryptographic hash algorithm used to generate the
SPKI pinset.";
}
}
leaf-list psk-key-exchange-modes {
if-feature "tls-1-3 or dtls-1-3";
type ianatp:psk-key-exchange-mode;
description
"pre-shared key exchange modes";
}
leaf-list supported-groups {
type ianatp:supported-group;
description
"A list of named groups supported by the client.";
}
leaf-list signature-algorithms-cert {
if-feature "tls-1-3 or dtls-1-3";
type ianatp:signature-algorithm;
description
"A list signature algorithms the client can validate
in X.509 certificates.";
}
leaf-list signature-algorithms {
type ianatp:signature-algorithm;
description
"A list signature algorithms the client can validate
in the CertificateVerify message.";
}
leaf-list application-protocols {
type ianatp:application-protocol;
description
"A list application protocols supported by the client";
}
leaf-list cert-compression-algorithms {
if-feature "tls-1-3 or dtls-1-3";
type ianatp:cert-compression-algorithm;
description
"A list certificate compression algorithms
supported by the client";
}
leaf-list certificate_authorities {
if-feature "tls-1-3 or dtls-1-3";
type ianatp:certificate_authority;
description
"A list of the distinguished names of certificate authorities
acceptable to the client";
}
}
}
}
}
}
<CODE ENDS>
5.3. IANA (D)TLS profile YANG Module
<CODE BEGINS> file "iana-tls-profile@2020-10-07.yang"
module iana-tls-profile {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile";
prefix ianatp;
organization
"IANA";
contact
" Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States
Tel: +1 310 301 5800
E-Mail: iana@iana.org>";
description description
"Initial revision"; "This module contains YANG definition for the (D)TLS profile.
}
typedef extension-type { Copyright (c) 2020 IETF Trust and the persons identified as
type uint16; authors of the code. All rights reserved.
description "Extension type";
}
typedef supported-group { Redistribution and use in source and binary forms, with or
type uint16; without modification, is permitted pursuant to, and subject
description "Named group (DHE or ECDHE)"; to the license terms contained in, the Simplified BSD License
} set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
typedef SPKI-pin-set { This version of this YANG module is part of RFC XXXX; see
type binary; the RFC itself for full legal notices.";
description "Subject Public Key Info pin set";
}
typedef signature-algorithm { revision 2020-10-07 {
type uint16; description
description "Signature algorithm"; "Initial revision";
} reference
"RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS Profiles
for IoT Devices";
}
typedef psk-key-exchange-mode { typedef extension-type {
type uint8; type uint16;
description "pre-shared key exchange mode"; description
} "Extension type";
}
typedef client-public-key-length { typedef supported-group {
type uint8; type uint16;
description "client public key length"; description
} "Named group (DHE or ECDHE)";
}
typedef application-protocol { typedef SPKI-pin-set {
type string; type binary;
description "application protocol"; description
} "Subject Public Key Info pin set";
}
typedef cert-compression-algorithm { typedef signature-algorithm {
type uint16; type uint16;
description "certificate compression algorithm"; description
} "Signature algorithm";
typedef certificate_authority { }
type binary;
description "Distinguished Name of Certificate authority";
}
typedef cipher-algorithm { typedef psk-key-exchange-mode {
type uint8; type uint8;
description "Cipher Algorithm"; description
} "pre-shared key exchange mode";
typedef aead-algorithm { }
type uint8;
description "AEAD Algorithm";
}
typedef tls-version { typedef application-protocol {
type string;
description
"application protocol";
}
typedef cert-compression-algorithm {
type uint16;
description
"certificate compression algorithm";
}
typedef certificate_authority {
type string;
description
"Distinguished Name of Certificate authority";
}
typedef cipher-algorithm {
type uint8;
description
"Cipher Algorithm";
}
typedef aead-algorithm {
type uint8;
description
"AEAD Algorithm";
}
typedef tls-version {
type enumeration { type enumeration {
enum tls-1.2 { enum tls-1.2 {
value 1; value 1;
description description
"TLS Protocol Version 1.2."; "TLS Protocol Version 1.2.";
reference reference
"RFC 5246: The Transport Layer Security (TLS) Protocol "RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2"; Version 1.2";
} }
enum tls-1.3 { enum tls-1.3 {
value 2; value 2;
description description
"TLS Protocol Version 1.3."; "TLS Protocol Version 1.3.";
reference reference
"RFC 8446: The Transport Layer Security (TLS) Protocol "RFC 8446: The Transport Layer Security (TLS) Protocol
Version 1.3"; Version 1.3";
} }
} }
description description
"Indicates the TLS version."; "Indicates the TLS version.";
} }
typedef dtls-version { typedef dtls-version {
type enumeration { type enumeration {
enum dtls-1.2 { enum dtls-1.2 {
value 1; value 1;
description description
"DTLS Protocol Version 1.2."; "DTLS Protocol Version 1.2.";
reference reference
"RFC 6346: Datagram Transport Layer Security 1.2"; "RFC 6346: Datagram Transport Layer Security 1.2";
} }
enum dtls-1.3 { enum dtls-1.3 {
value 2; value 2;
description description
"DTLS Protocol Version 1.3."; "DTLS Protocol Version 1.3.";
reference reference
"draft-ietf-tls-dtls13: Datagram Transport Layer Security 1.3"; "RFC DDDD: Datagram Transport Layer Security 1.3";
} }
}
description
"Indicates the DTLS version.";
} }
description
"Indicates the DTLS version.";
} }
<CODE ENDS>
feature tls-1_2 { 5.4. MUD (D)TLS Profile Extension
description
"TLS Protocol Version 1.2 is supported.";
reference
"RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2";
}
feature tls-1_3 { This document augments the "ietf-mud" MUD YANG module to indicate
description whether the device supports (D)TLS profile. If the "ietf-mud-tls"
"TLS Protocol Version 1.3 is supported."; extension is supported by the device, MUD file is assumed to
reference implement the "match-on-tls-dtls" ACL model feature defined in this
"RFC 8446: The Transport Layer Security (TLS) Protocol specification. Furthermore, only "accept" or "drop" actions SHOULD
Version 1.3"; be included with the (D)TLS profile similar to the actions allowed in
} Section 2 of [RFC8520].
feature dtls-1_2 { This document defines the YANG module "ietf-mud-tls", which has the
description following tree structure:
"DTLS Protocol Version 1.2 is supported.";
reference
"RFC 6346: Datagram Transport Layer Security Version 1.2";
}
feature dtls-1_3 { module: ietf-mud-tls
description augment /ietf-mud:mud:
"DTLS Protocol Version 1.3 is supported."; +--rw is-tls-dtls-profile-supported? boolean
reference
"draft-ietf-tls-dtls13: Datagram Transport Layer Security 1.3";
}
grouping client-profile { The model is defined as follows:
description
"A grouping for (D)TLS profiles.";
container client-profile {
list tls-dtls-profiles {
key "profile-name";
description
"A list of (D)TLS version profiles supported by the client.";
leaf profile-name {
type string {
length "1..64";
}
description
"The name of (D)TLS profile; space and special
characters are not allowed.";
}
leaf-list supported_versions {
type uint16;
description
"(D)TLS versions supported by the client";
}
list cipher-suites {
key "cipher aead";
leaf cipher {
type cipher-algorithm;
description "Cipher";
}
leaf aead {
type aead-algorithm;
description "AEAD";
}
description "Cipher Suites";
}
leaf-list extension-types {
type extension-type;
description "Extension Types";
}
leaf-list acceptlist-ta-certs {
type ct:trust-anchor-cert-cms;
description
"A list of trust anchor certificates used by the client.";
}
container SPKI {
leaf-list SPKI-pin-sets {
type SPKI-pin-set;
description
"A list of SPKI pin sets pre-configured on the client
to validate self-signed server certificate or
raw public key.";
}
leaf SPKI-hash-algorithm {
type iha:hash-algorithm-type;
description
"cryptographic hash algorithm used to generate the
SPKI pinset.";
} <CODE BEGINS> file "iana-tls-mud@2020-10-20.yang"
}
leaf-list psk-key-exchange-modes { module ietf-mud-tls {
if-feature "tls-1_3 or dtls-1_3"; yang-version 1.1;
type psk-key-exchange-mode; namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls";
description prefix ietf-mud-tls;
"pre-shared key exchange modes";
} import ietf-mud {
leaf-list supported-groups { prefix ietf-mud;
type supported-group; }
description
"A list of named groups supported by the client."; organization
} "IETF OPSAWG (Operations and Management Area Working Group)";
leaf-list signature-algorithms-cert { contact
if-feature "tls-1_3 or dtls-1_3"; "WG Web: <https://datatracker.ietf.org/wg/opsawg/>
type signature-algorithm; WG List: opsawg@ietf.org
description
"A list signature algorithms the client can validate Author: Konda, Tirumaleswar Reddy
in X.509 certificates."; TirumaleswarReddy_Konda@McAfee.com
}
leaf-list signature-algorithms { ";
type signature-algorithm; description
description "Extension to a MUD module to indicate (D)TLS
"A list signature algorithms the client can validate profile support.";
in the CertificateVerify message.";
} revision 2020-10-19 {
leaf-list application-protocols { description
type application-protocol; "Initial revision.";
description reference
"A list application protocols supported by the client"; "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS
} Profiles for IoT Devices";
leaf-list cert-compression-algorithms { }
if-feature "tls-1_3 or dtls-1_3";
type cert-compression-algorithm; augment "/ietf-mud:mud" {
description description
"A list certificate compression algorithms "This adds a extension for a manufacturer
supported by the client"; to indicate whether (D)TLS profile is
} is supported by a device.";
leaf-list certificate_authorities { leaf is-tls-dtls-profile-supported {
if-feature "tls-1_3 or dtls-1_3"; type boolean;
type certificate_authority;
description description
"A list of the distinguished names of certificate authorities "This value will equal 'true' if a device supports
acceptable to the client"; (D)TLS profile.";
} }
}
} }
} <CODE ENDS>
}
augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" {
description
"MUD (D)TLS specific matches.";
uses client-profile;
}
}
6. Processing of the MUD (D)TLS Profile 6. Processing of the MUD (D)TLS Profile
The following text outlines the rules for a network security service The following text outlines the rules for a network security service
(e.g., firewall) to follow to process the MUD (D)TLS Profile: (e.g., firewall) to follow to process the MUD (D)TLS Profile:
o If the (D)TLS parameter observed in a (D)TLS session is not o If the (D)TLS parameter observed in a (D)TLS session is not
specified in the MUD (D)TLS profile and the parameter is specified in the MUD (D)TLS profile and the parameter is
recognized by the firewall, it can identify unexpected (D)TLS recognized by the firewall, it can identify unexpected (D)TLS
usage, which can indicate the presence of unauthorized software or usage, which can indicate the presence of unauthorized software or
skipping to change at page 17, line 18 skipping to change at page 21, line 11
used to reach servers listening on port 443 using TCP transport. used to reach servers listening on port 443 using TCP transport.
JSON encoding of YANG modelled data [RFC7951] is used to illustrate JSON encoding of YANG modelled data [RFC7951] is used to illustrate
the example. the example.
{ {
"ietf-mud:mud": { "ietf-mud:mud": {
"mud-version": 1, "mud-version": 1,
"mud-url": "https://example.com/IoTDevice", "mud-url": "https://example.com/IoTDevice",
"last-update": "2019-18-06T03:56:40.105+10:00", "last-update": "2019-18-06T03:56:40.105+10:00",
"cache-validity": 100, "cache-validity": 100,
"extensions": [
"ietf-mud-tls"
],
"ietf-mud-tls:is-tls-dtls-profile-supported": "true",
"is-supported": true, "is-supported": true,
"systeminfo": "IoT device name", "systeminfo": "IoT device name",
"from-device-policy": { "from-device-policy": {
"access-lists": { "access-lists": {
"access-list": [ "access-list": [
{ {
"name": "mud-7500-profile" "name": "mud-7500-profile"
} }
] ]
} }
skipping to change at page 17, line 49 skipping to change at page 21, line 46
"ipv6": { "ipv6": {
"protocol": 6 "protocol": 6
}, },
"tcp": { "tcp": {
"ietf-mud:direction-initiated": "from-device", "ietf-mud:direction-initiated": "from-device",
"destination-port": { "destination-port": {
"operator": "eq", "operator": "eq",
"port": 443 "port": 443
} }
}, },
"iana-opsawg-mud-tls-profile:client-profile" : { "ietf-acl-tls:client-profile" : {
"tls-dtls-profiles" : [ "tls-dtls-profiles" : [
{ {
"supported-tls-versions" : [2], "supported-tls-versions" : ["tls-1.3"],
"cipher-suites" : [ "cipher-suites" : [
{ {
"cipher": 19, "cipher": 19,
"aead": 1 "aead": 1
}, },
{ {
"cipher": 19, "cipher": 19,
"aead": 2 "aead": 2
} }
], ],
skipping to change at page 19, line 40 skipping to change at page 23, line 37
payload inspection for a connection destined to a specific service payload inspection for a connection destined to a specific service
due to privacy compliance requirements. In addition, mechanisms due to privacy compliance requirements. In addition, mechanisms
based on object security can be used by IoT devices to enable end-to- based on object security can be used by IoT devices to enable end-to-
end security and the middlebox will not have any access to the packet end security and the middlebox will not have any access to the packet
data. For example, Object Security for Constrained RESTful data. For example, Object Security for Constrained RESTful
Environments (OSCORE) [RFC8613] is a proposal that protects CoAP Environments (OSCORE) [RFC8613] is a proposal that protects CoAP
messages by wrapping them in the COSE format [RFC8152]. messages by wrapping them in the COSE format [RFC8152].
10. IANA Considerations 10. IANA Considerations
10.1. (D)TLS Profile YANG Modules
Each normative YANG module MUST be registered in both the "IETF XML Each normative YANG module MUST be registered in both the "IETF XML
Registry" [RFC3688] and the "YANG Module Names" registry [RFC6020]. Registry" [RFC3688] and the "YANG Module Names" registry [RFC6020].
This document requests IANA to register the following URIs in the This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" [RFC3688]: "ns" subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:iana-opsawg-mud-tls-profile URI: urn:ietf:params:xml:ns:yang:iana-tls-profile
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-acl-tls
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-mud-tls
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
IANA is requested to create an IANA-maintained YANG Module called
"iana-tls-profile", based on the contents of Section 5.3, which will
allow for new (D)TLS parameters and (D)TLS versions to be added to
"client-profile". The registration procedure will be Expert Review,
as defined by [RFC8126].
This document requests IANA to register the following YANG modules in This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC6020] within the "YANG the "YANG Module Names" subregistry [RFC6020] within the "YANG
Parameters" registry. IANA is requested to create an IANA-maintained Parameters" registry.
YANG Module called "iana-opsawg-mud-tls-profile", based on the
contents of Section 5, which will allow for new (D)TLS parameters and name: iana-tls-profile
(D)TLS versions. The registration procedure will be Expert Review or namespace: urn:ietf:params:xml:ns:yang:iana-tls-profile
maintained by IANA: Y
prefix: ianatp
reference: RFC XXXX
name: ietf-acl-tls
namespace: urn:ietf:params:xml:ns:yang:ietf-acl-tls
maintained by IANA: N
prefix: ietf-acl-tls
reference: RFC XXXX
name: ietf-mud-tls
namespace: urn:ietf:params:xml:ns:yang:ietf-mud-tls
maintained by IANA: N
prefix: ietf-mud-tls
reference: RFC XXXX
IANA is requested to create an the initial version of the IANA-
maintained YANG Module called "iana-tls-profile", based on the
contents of Section 5.3, which will allow for new (D)TLS parameters
and (D)TLS versions to be added. IANA is requested to add this note:
o tls-version and dtls-version values must not be directly added to
the iana-tls-profile YANG module. They must instead be
respectively added to the "TLS Version Codes", and "DTLS Version
Codes" registries.
o (D)TLS parameters must not be directly added to the iana-tls-
profile YANG module. They must instead be added to the "(D)TLS
Parameters" registry.
When a 'tls-version' or 'dtls-version' value is respectively added to
the "TLS Version Codes" or "DTLS Version Codes" registry, a new
"enum" statement must be added to the iana-tls-profile YANG module.
The following "enum" statement, and substatements thereof, should be
defined:
"enum": Replicates the label from the registry.
"value": Contains the IANA-assigned value corresponding to the
'tls-version' or 'dtls-version'.
"description": Replicates the description from the registry.
"reference": Replicates the reference from the registry and adds
the title of the document.
When a (D)TLS parameter is added to "(D)TLS Parameters" registry, a
new "type" statement must be added to the iana-tls-profile YANG
module. The following "type" statement, and substatements thereof,
should be defined:
"derived type": Replicates the parameter name from the registry.
"built-in type": Contains the built-in YANG type.
"description": Replicates the description from the registry.
When the iana-tls-profile YANG module is updated, a new "revision"
statement must be added in front of the existing revision statements.
IANA is requested to add this note to "TLS Version Codes", "DTLS
Version Codes", and "(D)TLS Parameters" registries:
When this registry is modified, the YANG module iana-tls-profile
must be updated as defined in [RFCXXXX].
The registration procedure for "ietf-acl-tls" YANG module will be
Specification Required, as defined by [RFC8126]. Specification Required, as defined by [RFC8126].
name: iana-opsawg-mud-tls-profile 10.2. TLS Version registry
namespace: urn:ietf:params:xml:ns:yang:iana-opsawg-mud-tls-profile
maintained by IANA: Y IANA is requested to create a new subregistry titled "TLS Version
prefix: mud-tls-profile Codes". Codes in this registry are used as valid values of 'tls-
reference: RFC XXXX version' parameter. Further assignments are to be made through
Expert Review [RFC8126].
+-----------+-------------+--------------------------+-----------+
| Value | Label | Description | Reference |
| | | | |
| | | | |
+-----------+-------------+--------------------------+-----------+
| 1 | tls-1.2 | TLS Protocol Version 1.2 | [RFC5246] |
+----------------------------------------------------+-----------+
| 2 | tls-1.3 | TLS Protocol Version 1.3 | [RFC8446] |
+----------------------------+-----------------------+-----------+
10.3. DTLS version registry
IANA is requested to create a new subregistry titled "DTLS Version
Codes". Codes in this registry are used as valid values of 'dtls-
version' parameter. Further assignments are to be made through
Expert Review [RFC8126].
+-----------+-------------+---------------------------+-------------------------+
| Value | Label | Description | Reference |
| | | | |
| | | | |
+-----------+-------------+---------------------------+-------------------------+
| 1 | dtls-1.2 | DTLS Protocol Version 1.2 | [RFC6346] |
+-----------------------------------------------------+-------------------------+
| 2 | dtls-1.3 | DTLS Protocol Version 1.3 | [draft-ietf-tls-dtls13] |
+----------------------------+------------------------+-------------------------+
10.4. (D)TLS Parameters registry
IANA is requested to create a new subregistry titled "(D)TLS
parameters". The values for all the (D)TLS parameters in the
registry are defined in the TLS and DTLS IANA registries
(<https://www.iana.org/assignments/tls-parameters/tls-parameters.txt>
and <https://www.iana.org/assignments/tls-extensiontype-values/tls-
extensiontype-values.txt>) excluding the supported_tls_versions and
supported_dtls_versions parameters. Further assignments are to be
made through Expert Review [RFC8126]. The registry is initially
populated with the following values:
+----------------------------+-------------+--------+---------------------------------------------+
| Parameter Name | YANG | JSON | |
| | Type | Type | Description |
| | | | |
+----------------------------+-------------+--------+---------------------------------------------+
| extension-type | uint16 | Number | Extension type |
+----------------------------+-------------+--------+---------------------------------------------+
| supported-group | uint16 | Number | Named group (DHE or ECDHE) |
+----------------------------+-------------+--------+---------------------------------------------+
| SPKI-pin-set | binary | String | Subject Public Key Info pin set |
+----------------------------+-------------+--------+---------------------------------------------+
| signature-algorithm | uint16 | Number | Signature algorithm |
+----------------------------+-------------+--------+---------------------------------------------+
| psk-key-exchange-mode | uint8 | Number | pre-shared key exchange mode |
+----------------------------+-------------+--------+---------------------------------------------+
| application-protocol | string | String | application protocol |
+----------------------------+-------------+--------+---------------------------------------------+
| cert-compression-algorithm | uint16 | Number | certificate compression algorithm |
+----------------------------+-------------+--------+---------------------------------------------+
| certificate_authority | string | String | Distinguished Name of Certificate authority |
+----------------------------+-------------+--------+---------------------------------------------+
| cipher-algorithm | uint8 | Number | Cipher Algorithm |
+----------------------------+-------------+--------+---------------------------------------------+
| aead-algorithm | uint8 | Number | AEAD Algorithm |
+----------------------------+-------------+--------+---------------------------------------------+
| tls-version | enumeration | String | TLS version |
+----------------------------+-------------+--------+---------------------------------------------+
| dtls-version | enumeration | String | DTLS version |
+----------------------------+-------------+--------+---------------------------------------------+
10.5. MUD Extensions registry
IANA is requested to create a new MUD Extension Name "ietf-mud-tls"
in the MUD Extensions IANA registry
<https://www.iana.org/assignments/mud/mud.xhtml>.
11. Acknowledgments 11. Acknowledgments
Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson,
Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair,
Ben Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick Ben Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick
Harper for the discussion and comments. Harper for the discussion and comments.
12. References 12. References
skipping to change at page 21, line 38 skipping to change at page 29, line 22
RFC 8701, DOI 10.17487/RFC8701, January 2020, RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/info/rfc8701>. <https://www.rfc-editor.org/info/rfc8701>.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
12.2. Informative References 12.2. Informative References
[clear-as-mud]
"Clear as MUD: Generating, Validating and Applying IoT
Behaviorial Profiles", October 2019,
<https://arxiv.org/pdf/1804.04358.pdf>.
[cryto-vulnerability] [cryto-vulnerability]
Perez, B., "Exploiting the Windows CryptoAPI Perez, B., "Exploiting the Windows CryptoAPI
Vulnerability", January 2020, Vulnerability", January 2020,
<https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/ <https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/
CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF>. CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF>.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-07 (work in Encrypted Client Hello", draft-ietf-tls-esni-07 (work in
progress), June 2020. progress), June 2020.
skipping to change at page 22, line 32 skipping to change at page 30, line 22
Anderson, B. and D. McGrew, "TLS Beyond the Browser: Anderson, B. and D. McGrew, "TLS Beyond the Browser:
Combining End Host and Network Data to Understand Combining End Host and Network Data to Understand
Application Behavior", October 2019, Application Behavior", October 2019,
<https://dl.acm.org/citation.cfm?id=3355601>. <https://dl.acm.org/citation.cfm?id=3355601>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014,
<https://www.rfc-editor.org/info/rfc7366>. <https://www.rfc-editor.org/info/rfc7366>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>. 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
 End of changes. 73 change blocks. 
348 lines changed or deleted 712 lines changed or added

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