Skip to main content

Delegated Credentials to Host Encrypted DNS Forwarders on CPEs
draft-reddy-add-delegated-credentials-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Tirumaleswar Reddy.K , Mohamed Boucadair , Dan Wing , Shashank Jain
Last updated 2023-03-26
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-reddy-add-delegated-credentials-00
Network Working Group                                           T. Reddy
Internet-Draft                                                     Nokia
Intended status: Standards Track                            M. Boucadair
Expires: 27 September 2023                                        Orange
                                                                 D. Wing
                                                                  Citrix
                                                                 S. Jain
                                                                  McAfee
                                                           26 March 2023

     Delegated Credentials to Host Encrypted DNS Forwarders on CPEs
                draft-reddy-add-delegated-credentials-00

Abstract

   An encrypted DNS server is authenticated by a certificate signed by a
   Certificate Authority (CA).  However, for typical encrypted DNS
   server deployments on Customer Premise Equipment (CPEs), the
   signature cannot be obtained or requires excessive interactions with
   a Certificate Authority.

   This document explores the use of TLS delegated credentials for a DNS
   server deployed on a CPE.  This approach is meant to ease operating
   DNS forwarders in CPEs while allowing to make use of encrypted DNS
   capabilities.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 September 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Reddy, et al.           Expires 27 September 2023               [Page 1]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  CPEs, a Critical Componenet in Home Networks. . . . . . .   2
     1.2.  Proxied DNS In Local Networks . . . . . . . . . . . . . .   3
     1.3.  Hosting Encrypted DNS Forwarder in Local Networks . . . .   4
       1.3.1.  DDR/DNR Comparison and Naming Constraints . . . . . .   4
       1.3.2.  Delegated Certificate Issuance  . . . . . . . . . . .   5
     1.4.  Objectives & Scope  . . . . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Delegated Credentials . . . . . . . . . . . . . . . . . . . .   7
   4.  Legacy DNS Clients  . . . . . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

1.1.  CPEs, a Critical Componenet in Home Networks.

   Customer Premises Equipment (CPEs, also called Home Routers) are a
   critical component of the home network, and their security is
   essential to protecting the devices and data that are connected to
   them.  For example, the prpl Foundation [prpl] has developed a number
   of initiatives to promote home router security and hardening.  The
   prplWrt project [prplwrt] is an initiative in prpl Foundation that
   aims to improve the security and performance of open-source router
   firmware, such as OpenWrt [openwrt].  OpenWrt is an open-source
   operating system that is designed to run on a wide range of routers
   and embedded devices.  It now includes support for containerization
   technology such as Docker, making it possible to run containerized
   applications on a home router.  Further, DNS providers have optimized
   the encrypted DNS forwarder to run in a container in home routers.

Reddy, et al.           Expires 27 September 2023               [Page 2]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

1.2.  Proxied DNS In Local Networks

   Figure 1 shows various network setups where the CPE embeds a caching
   encrypted DNS forwarder.  Section 1.3.1 discusses the applicability
   of DDR as a function of the address used by the CPE for the
   verification of ownership.

   (a)

                         ,--,--,--.             ,--,--,--.
                      ,-'          `-.       ,-'   ISP    `-.
              Host---(      LAN      CPE----(    DNS Resolver)
                |     `-.          ,-'|      `-.          ,-'
                |        `--'--'--'   |       | `--'--'--'
                |                     |<=DNR=>|     |
                |<========DNR========>|       |     |
                |                     |             |
                |<=====Encrypted=====>|<=Encrypted=>|
                |         DNS         |     DNS     |

   (b)

                   ,--,--,--.             ,--,--,--.
                ,-'          `-.       ,-'   ISP    `-.      3rd Party
        Host---(      LAN      CPE----(                )--- DNS Resolver
          |     `-.          ,-'|      `-.          ,-'        |
          |        `--'--'--'   |       | `--'--'--'           |
          |                     |<=DNR=>|                      |
          |<========DNR========>|       |                      |
          |                     |                              |
          |<=====Encrypted=====>|<=========Encrypted DNS======>|
          |         DNS         |                              |

                  Figure 1: Proxied Encrypted DNS Sessions

   For all the cases shown in Figure 1, the CPE advertises itself as the
   default DNS server to the hosts it serves in the LAN.  The CPE relies
   upon DHCP or RA to advertise itself to internal hosts as the default
   encrypted DNS forwarder.  When receiving a DNS request it cannot
   handle locally, the CPE forwards the request to an upstream encrypted
   DNS.  The upstream encrypted DNS can be hosted by the ISP or provided
   by a third party.

   Such a forwarder presence is required for IPv4 service continuity
   purposes (e.g., Section 3.1 of [RFC8585]) or for supporting advanced
   services within a local network (e.g., malware filtering, parental
   control, Manufacturer Usage Description (MUD) [RFC8520] to only allow
   intended communications to and from an IoT device, and multicast DNS

Reddy, et al.           Expires 27 September 2023               [Page 3]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   proxy service for the ".local" domain [RFC6762]).  When the CPE
   behaves as a DNS forwarder, DNS communications can be decomposed into
   two legs to resolve queries:

   *  The leg between an internal host and the CPE.

   *  The leg between the CPE and an upstream DNS resolver.

1.3.  Hosting Encrypted DNS Forwarder in Local Networks

   This section discusses some deployment challenges to host an
   encrypted DNS forwarder within a local network.

1.3.1.  DDR/DNR Comparison and Naming Constraints

   DDR requires proving possession of an IP address, as the DDR
   certificate contains the server's IPv4 and IPv6 addresses and is
   signed by a certificate authority.  DDR is constrained to public IP
   addresses because (WebPKI) certificate authorities will not sign
   special-purpose IP addresses [RFC6890], most notably IPv4 private-use
   [RFC1918], IPv4 shared address [RFC6598], or IPv6 Unique-Local
   [RFC8190] address space.  A tempting solution is to use the CPE's WAN
   IP address for DDR and prove possession of that IP address.  However,
   the CPE's WAN IPv4 address will not be a public IPv4 address if the
   CPE is behind another layer of NAT (either Carrier Grade NAT (CGN) or
   another on-premise NAT), reducing the success of this mechanism to
   CPE's WAN IPv6 address.  If the ISP renumbers the subscriber's
   network suddenly (rather than slow IPv6 renumbering described in
   [RFC4192]) encrypted DNS service will be delayed until that new
   certificate is acquired.

   DNR requires proving possession of an FQDN as the encrypted
   resolver's certificate contains the FQDN.  The entity (e.g., ISP,
   network administrator) managing the CPE would assign a unique FQDN to
   the CPE.  There are two mechanisms for the CPE to obtain the
   certificate for the FQDN: using one of its WAN IP addresses or
   requesting its signed certificate from an Internet-facing server used
   for remote CPE management (e.g., the Auto Configuration Server (ACS)
   in the CPE WAN Management Protocol [TR-069]).  If using a CPE's WAN
   IP address, the CPE needs a public IPv4 or a global unicast IPv6
   address together with DNS A or AAAA records pointing to that CPE's
   WAN address to prove possession of the DNS name to obtain a WebPKI
   CA-signed certificate (that is, the CPE fulfills the DNS or HTTP
   challenge discussed in ACME [RFC8555]).  However, a CPE's WAN address
   will not be a public IPv4 address if the CPE is behind another layer
   of NAT (either a CGN or another on-premise NAT), reducing the success
   of this mechanism to a CPE's WAN IPv6 address.  If the subscribers
   IPv4 or IPv6 address is included in the certificate name (e.g., "dyn-

Reddy, et al.           Expires 27 September 2023               [Page 4]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   192-0-2-1.example.net") then DNR will experience IP renumbering
   complications identical to DDR, described above.  The former
   mechanism has the following limitations when ACME protocol is used
   for certificate issuance:

   *  Each CPE would have to create a different account for ordering a
      certificate.  When a large scale of CPEs (e.g., millions of
      devices) request certificate issuance for a large number of
      subdomains, it could be treated as an attacker by the certificate
      authorities to overwhelm it.

   *  The CPE would have to host an Internet-facing HTTP server or a DNS
      authoritative server to complete the HTTP or DNS challenge.

1.3.2.  Delegated Certificate Issuance

   The encrypted DNS forwarder is hosted on a CPE and provisioned by a
   service (e.g., ACS) in the operator's network.  Each CPE has a unique
   FQDN (e.g., "cpe-12345.example.com" where 12345 might be the customer
   number or part of the device's serial number).  The CPE generates a
   public and private key-pair, builds a certificate signing request
   (CSR), and sends the CSR to a service in the vendor managing the CPE.
   Upoon receipt of the CSR, the operator's service can utilize
   Automatic Certificate Management Environment (ACME) [RFC8555] to
   automate certificate management functions such as domain validation
   procedure, certificate issuance, and certificate revocation.

   The challenge with this technique is the service will have to
   communicate with the CA to issue certificates for millions of CPEs.
   If an external CA is unable to issue a certificate in time or replace
   an expired certificate, the service would no longer be able to
   present a valid certificate to a CPE.  When the service requests
   certificate issuance for a large number of subdomains (e.g., millions
   of CPEs), it may be treated as an attacker by the CA to overwhelm it.
   Furthermore, the short-lived certificates (e.g., certificates that
   expire after 90 days) issued by the CA will have to be renewed
   frequently.  With short-lived certificates, there is a smaller time
   window to renew a certificate and, therefore, a higher risk that a CA
   outage will negatively affect the uptime of the encrypted DNS
   forwarders on CPEs (and the services offered via these CPEs).

Reddy, et al.           Expires 27 September 2023               [Page 5]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

1.4.  Objectives & Scope

   This document discusses the use of delegated credentials
   [I-D.ietf-tls-subcerts] to host encrypted DNS resolvers, such as DoH
   [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ)
   [RFC9250] in managed CPEs by reducing the dependency on Certification
   Authority (CA).  The advantage of using delegated credentials on CPEs
   is that it completely removes the dependency on the CAs to provide a
   PKI certificate for each CPE.  The entity managing the CPE (e..g,
   ISP, CPE vendor, Security Service Provider) will provision it a with
   a delegated credential and renew the delegated credential before the
   expiry.

   Scope of this document is an encrypted DNS server deployed on a
   managed CPEs.

2.  Terminology

   This document makes use of the terms defined in [RFC8499].

   The following additional terms are used:

   DHCP:  refers to both DHCPv4 and DHCPv6.

   Do53:  refers to unencrypted DNS.

   DNR:  refers to the Discovery of Network-designated Resolvers
      procedure defined in [I-D.ietf-add-dnr].

   DDR:  refers to the Discovery of Designated Resolvers procedure
      defined in [I-D.ietf-add-ddr].

   Encrypted DNS:  refers to a scheme where DNS exchanges are
      transported over an encrypted channel.  Examples of encrypted DNS
      are DoH [RFC8484], DNS-over-TLS (DoT) [RFC7858], and DNS-over-QUIC
      (DoQ) [RFC9250].

   Managed CPE:  refers to a CPE that is managed by an ISP or CPE vendor
      or Security Service Provider.

   Unmanaged CPE:  refers to a CPE that is not managed by an ISP or CPE
      vendor or Security Service Provider.

   Delegated credential:  The certificate issued by the operator as
      described by [I-D.ietf-tls-subcerts].

Reddy, et al.           Expires 27 September 2023               [Page 6]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

3.  Delegated Credentials

   To reduce the dependency on external CAs, this document RECOMMENDS
   the use of delegation credentials [I-D.ietf-tls-subcerts] to be added
   to the TLS profile of encrypted DNS client and server
   implementations.

   A delegated credential (DC) is a digitally signed data structure with
   two semantic fields: a validity interval and a public key (along with
   its associated signature algorithm).  The signature on the delegated
   credential indicates a delegation from the certificate that is issued
   to the peer.

   The delegation allows a service in the operator managing the CPE to
   issue its own credentials within the scope of a certificate issued by
   an external CA.  These credentials only enable the CPE who is
   recipient of the delegation to terminate connections for names that
   the CA has authorized.  Furthermore, this mechanism allows the
   encrypted DNS forwarder on a CPE to use modern signature algorithms,
   such as Ed25519 [RFC8032] even if the CA does not support them.

   The signature on the delegated credential indicates a delegation from
   the certificate that is issued to a service in an infrastrcture owned
   by the CPE's operator.  The private key used to sign a credential
   corresponds to the public key of the service's X.509 end-entity
   certificate [RFC5280].  The delegated credential is cryptographically
   bound to the service's X.509 end-entity certificate with which the
   credential will be used.

   The basic sequence of steps involved is shown in Figure 2.

Reddy, et al.           Expires 27 September 2023               [Page 7]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   +------------+            +---------------+          +---------+
   | DNS Client |            | Encrypted DNS |          | Service |
   |            |            |   Forwarder   |          |         |
   +-----+------+            +--------+------+          +----+----+
         |                            |                      |
         |                            | Mutual Authentication|
         |                            +<-------------------->+
         |                            |                      |
         |                            | Credential(Public Key,
         |                            | time, signature)     |
         |                            +--------------------->+
         |                            |                      |
         |                            | Delegated credential |
         |                            | (signed using public |
         |                            | key)                 |
         |                            +<---------------------+
         |                            |                      |
         | ClientHello and            |                      |
         | delegated_credential extn  |                      |
         +--------------------------->+                      |
         |                            |                      |
         | Certificate and delegated  |                      |
         | credential                 |                      |
         |<---------------------------+                      |
         | .------------------------. |                      |
         +-|CertVerify (Validate the| |                      |
         | | delegated credential)  | |                      |
         | '------------------------' |                      |
         |                            |                      |

                     Figure 2: Typical Sequence Diagram

   1.  The DNS client provides an extension in its ClientHello that
       indicates support for delegated credentials.

   2.  The DNS forwarder sends the Certificate message providing both
       the certificate of the service as well as the delegated
       credential.

   3.  The DNS client uses information from the certificate to verify
       the delegated credential and that the DNS forwarder is asserting
       an expected identity.

Reddy, et al.           Expires 27 September 2023               [Page 8]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

4.  Legacy DNS Clients

   In order to also cover DNS clients that do not support delegation
   credentials or TLS 1.3 or later, server-side mechanisms that do not
   require changes to the client behavior are required (e.g., a PKCS#11
   interface or a remote signing mechanism, [KEYLESS] being examples) as
   discussed in Section 3.2 of [I-D.ietf-tls-subcerts].

   As depicted in Figure 3, a DNS forwarder may use delegated
   credentials for DNS clients that support them, while using a server-
   side mechanism to service local legacy DNS clients.

   +------------+     +---------------+       +---------+
   | DNS Client |     | Encrypted DNS |       | Service |
   |            |     | Forwarder-CPE |       |         |
   +------+-----+     +-------+-------+       +----+----+
          |                   |          (e.g., Managed by ISP)
          |                   |                    |
          |----ClientHello--->|                    |
          |<---ServerHello----|                    |
          |<---Certificate----|                    |
          |                   |<---remote sign---->|
          |<---CertVerify-----|                    |
          |        ...        |                    |

                 Figure 3: An Example of Remote key signing

5.  Security Considerations

   DNR-related security considerations are discussed in Section 7 of
   [I-D.ietf-add-dnr].  Likewise, DDR-related security considerations
   are discussed in Section 7 of [I-D.ietf-add-ddr].  The security
   considerations in [I-D.ietf-tls-subcerts] are to be taken into
   account.

6.  IANA Considerations

   This document does not require any IANA action.

7.  Acknowledgements

   Thanks to Neil Cook for the discussion and comments. .

8.  References

8.1.  Normative References

Reddy, et al.           Expires 27 September 2023               [Page 9]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   [I-D.ietf-add-ddr]
              Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", Work in
              Progress, Internet-Draft, draft-ietf-add-ddr-10, 5 August
              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-ddr-10>.

   [I-D.ietf-add-dnr]
              Boucadair, M., Reddy.K, T., Wing, D., Cook, N., and T.
              Jensen, "DHCP and Router Advertisement Options for the
              Discovery of Network-designated Resolvers (DNR)", Work in
              Progress, Internet-Draft, draft-ietf-add-dnr-14, 13 March
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-dnr-14>.

   [I-D.ietf-tls-subcerts]
              Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
              "Delegated Credentials for (D)TLS", Work in Progress,
              Internet-Draft, draft-ietf-tls-subcerts-15, 30 June 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              subcerts-15>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

8.2.  Informative References

   [KEYLESS]  "Sullivan, N. and D. Stebila, "An Analysis of TLS
              Handshake Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 ,
              2015", December 2018.

   [openwrt]  "OpenWrt", <https://openwrt.org/>.

   [prpl]     "Prpl Foundation", <https://prplfoundation.org/>.

   [prplwrt]  "Prpl WRT", <https://prplfoundation.org/project/prplwrt/>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/info/rfc1918>.

Reddy, et al.           Expires 27 September 2023              [Page 10]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              DOI 10.17487/RFC4192, September 2005,
              <https://www.rfc-editor.org/info/rfc4192>.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
              2012, <https://www.rfc-editor.org/info/rfc6598>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <https://www.rfc-editor.org/info/rfc6890>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8190]  Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
              "Updates to the Special-Purpose IP Address Registries",
              BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
              <https://www.rfc-editor.org/info/rfc8190>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,
              <https://www.rfc-editor.org/info/rfc8520>.

Reddy, et al.           Expires 27 September 2023              [Page 11]
Internet-Draft   Delegated Credentials for Encrypted DNS      March 2023

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

   [RFC8585]  Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
              "Requirements for IPv6 Customer Edge Routers to Support
              IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
              2019, <https://www.rfc-editor.org/info/rfc8585>.

   [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
              Dedicated QUIC Connections", RFC 9250,
              DOI 10.17487/RFC9250, May 2022,
              <https://www.rfc-editor.org/info/rfc9250>.

   [TR-069]   The Broadband Forum, "CPE WAN Management Protocol",
              December 2018, <https://www.broadband-
              forum.org/technical/download/TR-069.pdf>.

Authors' Addresses

   Tirumaleswar Reddy
   Nokia
   India
   Email: kondtir@gmail.com

   Mohamed Boucadair
   Orange
   35000 Rennes
   France
   Email: mohamed.boucadair@orange.com

   Dan Wing
   Citrix Systems, Inc.
   United States of America
   Email: dwing-ietf@fuggles.com

   Shashank Jain
   McAfee
   India
   Email: Shashank_Jain@mcafee.com

Reddy, et al.           Expires 27 September 2023              [Page 12]