draft-reddy-add-enterprise-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-reddy-add-enterprise-00" ipr="trust200902">
  <front>
    <title abbrev="DoH/DoT in Enterprise Networks">DNS-over-HTTPS and
    DNS-over-TLS Server Deployment Considerations for Enterprise
    Networks</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="McAfee">McAfee, Inc.</organization>

      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560071</code>

          <country>India</country>
        </postal>

        <email>TirumaleswarReddy_Konda@McAfee.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Citrix">Citrix Systems, Inc.</organization>

      <address>
        <postal>
          <street></street>

          <country>USA</country>
        </postal>

        <email>dwing-ietf@fuggles.com</email>
      </address>
    </author>

    <date />

    <workgroup>ADD</workgroup>

    <abstract>
      <t>This document discusses DoH/DoT deployment considerations for
      Enterprise networks. It particularly sketches the required steps to use
      DNS-over-TLS (DoT) and/or DNS-over-HTTPS (DoH) server provided by the
      Enterprise network.</t>

      <t>One of the goals of the document is to assess to what extent existing
      tools can be used to provide such service.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t><xref target="RFC7626"></xref> discusses DNS privacy considerations
      in both "on the wire" (Section 2.4 of <xref target="RFC7626"></xref>)
      and "in the server" (Section 2.5 of <xref target="RFC7626"></xref>)
      contexts. In recent years there has also been an increase in the
      availability of "public resolvers" <xref target="RFC8499"></xref> which
      DNS clients may be pre-configured to use instead of the default network
      resolver for a variety of reasons (e.g., offer a good reachability,
      support an encrypted transport, provide a strong privacy policy, (lack
      of) filtering).</t>

      <t>If public (DoT) <xref target="RFC7858"></xref> or DNS-over-HTTPS
      (DoH) <xref target="RFC8484"></xref> servers are used instead of using
      local DNS servers, it can adversely impact Enterprise network-based
      security. Various network security services are provided by Enterprise
      networks to protect endpoints (e.g., laptops, printers, IoT devices),
      and to enforce enterprise policies. These policies may be necessary to
      protect employees, customers, or citizens. They are not the subject of
      this memo.</t>

      <t>Enterprise DNS servers in place for these purpose act on DNS requests
      originating from endpoints. However, if an endpoint uses public DoT or
      DoH servers, the desired enterprise protection and enforcement can be
      bypassed.</t>

      <t>In order to act on DNS requests from endpoints, network security
      services can block DoT traffic by dropping outgoing packets to
      destination port 853. Identifying DoH traffic is far more challenging
      than DoT traffic. Network security services may try to identify the
      well-known DoH resolvers by their domain name, and DNS-over-HTTPS
      traffic can be blocked by dropping outgoing packets to these domains.
      However, DoH traffic can not be fully identified without acting as a TLS
      proxy.</t>

      <t>If a network security service blocks access to the public DoH/DoT
      server, there are incompatibilities with the privacy profiles discussed
      in <xref target="RFC8310"></xref>: <list style="symbols">
          <t>If an endpoint has enabled strict privacy profile (Section 5 of
          <xref target="RFC8310"></xref>), the endpoint cannot resolve DNS
          names.</t>

          <t>If an endpoint has enabled opportunistic privacy profile (Section
          5 of <xref target="RFC8310"></xref>), the endpoint will either
          fallback to an encrypted connection without authenticating the DNS
          server provided by the local network or fallback to clear text DNS,
          and cannot exchange encrypted DNS messages. The fallback adversely
          impacts security and privacy as internal attacks are possible in
          Enterprise networks. For example, an internal attacker can modify
          the DNS responses to re-direct the client to malicious servers or
          pervasively monitor the DNS traffic. The reader may refer to Section
          3.2.1 of <xref target="I-D.arkko-farrell-arch-model-t"></xref> for a
          discussion on the need for more awareness about attacks from within
          closed domains.</t>
        </list></t>

      <t>To overcome the above threats, this document specifies mechanisms to
      configure endpoints to use Enterprise provided DoT and DoH servers, and
      bootstrap IoT devices and unmanaged endpoints to discover and
      authenticate the DoT and DoH servers provided by the Enterprise
      network.</t>

      <t>A common usage pattern for an IoT device is for it to "call home" to
      a service that resides on the public Internet, where that service is
      referenced through a domain name (A or AAAA record). As discussed in
      Manufacturer Usage Description Specification <xref target="RFC8520">
      </xref>, because these devices tend to require access to very few sites,
      all other access should be considered suspect. However, if the query is
      not accessible for inspection, it becomes quite difficult for the
      infrastructure to suspect anything.</t>

      <t>This document focuses on DoH/DoT deployment considerations for
      Enterprise networks, DoH/DoT sever discovery and deployment
      considerations for home networks are discussed in <xref
      target="I-D.btw-add-home"></xref>.</t>
    </section>

    <section anchor="notation" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and
      only when, they appear in all capitals, as shown here.</t>

      <t>This document makes use of the terms defined in <xref
      target="RFC8499"></xref> and <xref
      target="I-D.ietf-dnsop-terminology-ter"></xref>.</t>

      <t>'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS.</t>
    </section>

    <section anchor="depl" title="IT-owned devices">
      <t>If a device is managed by an enterprise's IT department, the device
      can be configured to use Enterprise-provided DoH/DoT servers. This
      configuration might be manual or rely upon whatever deployed device
      management tool in an Enterprise. For example, customizing Firefox using
      Group Policy to use the Enterprise DoH server is discussed in <xref
      target="Firefox-Policy"></xref> for Windows and MacOS, and setting
      Chrome policies is discussed in <xref target="Chrome-Policy"></xref> and
      <xref target="Chrome-DoH"></xref>.</t>
    </section>

    <section title="IoT Devices">
      <t>The solution described in this document is aimed in general at
      non-constrained IoT devices (i.e., class 2+ <xref
      target="RFC7228"></xref>) operating on a Enterprise network without a
      device management tool and require agentless or standardized approaches.
      The basis for trust, therefore, is quite different from that of a
      laptop, tablet, or smart phone. The following bootstrapping mechanisms
      can be used to securely provision IoT devices to use Enterprise provided
      DoT and DoH servers:<list style="symbols">
          <t>IoT devices supporting Bootstrapping Remote Secure Key
          Infrastructures (BRSKI) discussed in <xref
          target="I-D.ietf-anima-bootstrapping-keyinfra"></xref> can be
          bootstrapped with the Enterprise-provided DoH/DoT servers using the
          mechanism discussed in Section 5 of <xref
          target="I-D.reddy-add-iot-byod-bootstrap"></xref>.</t>

          <t><xref target="RFC8572"></xref> defines a bootstrapping strategy
          for enabling devices to securely obtain the required configuration
          information with no installer input. DHCP/RA <xref
          target="I-D.btw-add-home"></xref> can be used to discover the
          DoH/DoT information. If the insecurely discovered DoH/DoT
          information is not pre-configured in the IoT device, the client can
          validate the Policy Assertion Token signature (Section 7 <xref
          target="I-D.reddy-add-server-policy-selection"></xref>) using the
          owner certificate (Section 3.2 of <xref
          target="RFC8572"></xref>).</t>

          <t>When IoT devices connect to a network via EAP methods such as
          Tunnel Extensible Authentication Protocol (TEAP) <xref
          target="RFC7170"></xref>, it would be possible to extend these
          methods to return additional configuration elements as part of
          completion of the authentication transaction. One simple approach
          would be after successful completion of the EAP method in Phase 2
          for a TEAP server to return a new TLV that indicates the local
          DoH/DoT information.</t>

          <t>Not all of IoT devices support 802.1x supplicant and need an
          alternate mechanism to connect to the Enterprise network. To address
          this limitation, unique pre-shared keys are created for each IoT
          device and WPA-PSK is used <xref target="PSK"></xref>. In other
          words, WPA-PSK is used with unique pre-shared keys for different IoT
          devices to deal security issues.<list style="symbols">
              <t>The IoT device needs to be provisioned with a Pre-Shared Key
              (PSK) for mutual authentication. The PSK is only known to the
              IoT device and the WPA server. In this case, the bootstrapping
              mechanism discussed in Section 4 of <xref
              target="I-D.reddy-add-iot-byod-bootstrap"></xref> may be used to
              securely bootstrap IoT device with the authentication domain
              name (ADN) and DNS server certificate of the local network's
              DoH/ DoT server. It uses password-based authenticated key
              exchange (PAKE) scheme to authenticate the EST server and fetch
              the DoH/DoT server certificate. Note that provisioning massive
              number of IoT devices with PSK is not a scalable onboarding
              mechanism but will work in Small Office/Home Office (SOHO) and
              Small/Medium Enterprise (SME).</t>
            </list></t>

          <t>If Device Provisioning Protocol (DPP) <xref target="dpp"></xref>
          is used, the configurator can securely configure IoT devices with
          the local DoH/DoT server by extending the content of the
          configuration elements provided by the configurator. Because DPP can
          provide a private shared key for use with WPA-PSK, it can be
          combined with the above methods.</t>

          <t>The OMA LWM2M specification <xref target="oma"></xref> defines an
          architecture where a new device (LWM2M client) contacts a
          Bootstrap-server which is responsible for "provisioning" essential
          bootstrap information. The current standard defines the following
          four bootstrapping modes (1) Factory Bootstrap (2) Bootstrap from
          Smartcard (3) Client Initiated Bootstrap (4) Server Initiated
          Bootstrap. The bootstrap information can be extended to include the
          local DoH/DoT server details.</t>

          <t>The Open Connectivitiy Foundation <xref target="ocf"></xref>
          defines the onboarding process before a device is operational. Once
          the onboarding tool and the new device have authenticated and
          established secure communication, the onboarding tool can provision
          the IoT device with the local DoH/DoT server.</t>
        </list></t>

      <t>This document does not discuss opportunistic or leap-of-faith
      bootstrapping methods, they are susceptible to security issues (e.g.,
      IoT device can be configured with the attacker's DoH/DoT server or
      disable the use of DoH/DoT).</t>
    </section>

    <section title="BYOD">
      <t>The following mechanisms can be used to bootstrap BYOD (bring your
      own device) with the DoH/DoT server used by the Enterprise network:</t>

      <t><list style="symbols">
          <t>If mobile device management (MDM) <xref
          target="MDM-Apple"></xref> is used to secure BYOD, MDM can be used
          to configure OS/browser with the Enterprise provided DoH/DoT
          server.</t>

          <t>If an endpoint is on-boarded, for example, using Over-The-Air
          (OTA) enrollment <xref target="OTA"></xref> to provision the device
          with a certificate and configuration profile, the configuration
          profile can include the authentication domain name (ADN) of the
          DoH/DoT server. The OS/Browser can use the configuration profile to
          use the Enterprise provided DoH/DoT server. In this case, MDM is not
          installed on the device.</t>

          <t>If an endpoint uses the credentials (username and password)
          provided by the IT admin to mutually authenticate to the Enterprise
          WiFi Access Point (e.g., PEAP-MSCHAPv2 <xref target="PEAP"></xref>,
          EAP-pwd <xref target="RFC8146"></xref>, EAP-PSK <xref
          target="RFC4764"></xref>), the boostrapping mechanism discussed in
          Section 4 of <xref target="I-D.reddy-add-iot-byod-bootstrap"></xref>
          can be used to securely bootstrap the endpoint with the ADN and DNS
          server certificate of the local network's DoH/DoT server. <vspace
          blankLines="1" />The DNS client uses PAKE scheme to authenticate the
          EST server using the credentials to authenticate to the network. In
          this case, the endpoint is neither provisioned with a configuration
          profile or MDM is installed on the device. Many users have privacy
          and personal data sovereignty concerns with employers installing MDM
          on their personal devices; they are concerned that admin can glean
          personal information and could control how they use their devices.
          Yet when users do not install MDM on their devices, IT admins do not
          get visibility into the security posture of those devices.<vspace
          blankLines="1" />To overcome this problem, a host agent can
          cryptographically attest the security status associated with device,
          such as minimum passcode length, biometric login enabled, OS version
          etc. This approach is fast gaining traction especially with the
          advent of closed OS like <xref target="win10s">Windows 10 in S
          mode</xref> or <xref target="Chromebook">Chromebook</xref>, where
          applications are sandboxed (e.g., ransomware attack is not possbile)
          and applications can only be installed via the OS store.</t>
        </list></t>

      <t>When attached to the enterprise network yet needing to use the
      enterprise's DoH server only to access the internal-only DNS names, the
      client device can learn about domains for which the local network's
      resolver is authoritative via dnsZones key defined in Section 4.3 of
      <xref target="I-D.ietf-intarea-provisioning-domains"></xref> (as other
      DoH/DoT servers will be unaware of the internal-only DNS names).</t>
    </section>

    <section anchor="VPN" title="Roaming Enterprise Users">
      <section title="VPN tunnel">
        <t>In this Enterprise scenario (Section 1.1.3 of <xref
        target="RFC7296"></xref>), a roaming user connects to the Enterprise
        network through an VPN tunnel (e.g., IPsec, SSL, Wireguard). The
        split-tunnel Virtual Private Network (VPN) configuration allows the
        endpoint to access hosts that reside in the Enterprise network <xref
        target="RFC8598"></xref> using that tunnel; other traffic not destined
        to the Enterprise does not traverse the tunnel. In contrast, a
        non-split- tunnel VPN configuration causes all traffic to traverse the
        tunnel into the enterprise.</t>

        <t>When the VPN tunnel is IPsec, The DoH/DoT server hosted by the
        Enterprise network can be securely discovered by the endpoint using
        the INTERNAL_ENC_DNS IKEv2 Configuration Payload Attribute Type
        defined in <xref target="I-D.btw-add-ipsecme-ike"></xref>. For
        split-tunnel VPN configurations, the endpoint uses the
        Enterprise-provided DoT/DoH server to resolve internal-only domain
        names. For non-split-tunnel VPN configurations, the endpoint uses the
        Enterprise-provided DoT/DoH server to resolve both internal and
        external domain names.</t>

        <t>Other VPN tunnel types have similar configuration capabilities, not
        detailed here.</t>
      </section>

      <section title="Client Authentication">
        <t>When not on the local enterprise network (e.g., at home or coffee
        shop) yet needing to access the enterprise DoH/DoT server but not
        through a tunnel, roaming users can use client authentication to
        access the Enterprise provided DoH/DoT server. For example, Firefox
        DoH setting accepts user credentials <xref
        target="Firefox-TRR"></xref> to authenticate the client to access the
        DoH server. The exact client authentication mechanism to authenticate
        to the DoH/DoT server is outside the scope of this specification.</t>
      </section>
    </section>

    <section title="Upstream Encryption">
      <t>If the Enterprise network is using the local DoH/DoT server
      configured as a Forwarding DNS server <xref target="RFC8499"></xref>
      relying on the upstream resolver (e.g., at an ISP) to perform recursive
      DNS lookups, DNS messages exchanged between the local DoH/DoT server and
      recursive resolver MUST be encrypted. If the Enterprise network is using
      the local DoH/DoT server configured as a recursive DNS server, DNS
      messages exchanges between the recursive resolver and authoritative
      servers SHOULD be encrypted to conform to the requirements discussed in
      <xref target="I-D.ietf-dprive-phase2-requirements"></xref>. </t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security and privacy considerations in <xref
      target="I-D.reddy-add-iot-byod-bootstrap"></xref> need to be taken into
      consideration.</t>

      <t>The mechanism defined in <xref
      target="I-D.reddy-add-server-policy-selection"></xref> can be used by
      the DNS server to communicate its privacy statement URL and filtering
      policy to a DNS client. This communication is cryptographically signed
      to attest to its authenticity.</t>

      <t>The DNS client can validate the signatory (i.e., cryptographically
      attested by the Organization hosting the DoH/DoT server) and the user
      can review human-readable privacy policy information of the DNS server
      and assess whether the DNS server performs DNS-based content
      filtering.</t>

      <t>If the discovered DoH/DoT server does not meet the privacy preserving
      data policy and filtering requirements of the user, the user can
      instruct the DNS client to take appropriate actions. For example, the
      action can be to use the local DNS server only to access internal-only
      DNS names and use another DNS server (adhering with his/her
      expectations) for public domains.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document has no actions for IANA.</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Mohamed Boucadair, Sandeep Rao, Vinny Parla, Nancy
      Cam-Winget and Eliot Lear for the discussion and comments.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8484'?>

      <?rfc include='reference.RFC.7858'?>

      <?rfc include='reference.RFC.8310'?>

      <?rfc include='reference.I-D.reddy-add-iot-byod-bootstrap'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.8499'?>

      <?rfc include='reference.RFC.8598'?>

      <?rfc include='reference.RFC.8520'?>

      <?rfc include='reference.RFC.7170'?>

      <?rfc include='reference.RFC.7626' ?>

      <?rfc include='reference.RFC.8572' ?>

      <?rfc include='reference.RFC.8146' ?>

      <?rfc include='reference.RFC.4764' ?>

      <?rfc include='reference.RFC.7296' ?>

      <?rfc include='reference.RFC.7228' ?>

      <?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?>

      <?rfc include='reference.I-D.reddy-add-server-policy-selection'?>

      <?rfc include='reference.I-D.ietf-intarea-provisioning-domains'?>

      <?rfc include='reference.I-D.ietf-dprive-phase2-requirements'?>

      <?rfc include='reference.I-D.btw-add-ipsecme-ike'?>

      <?rfc include='reference.I-D.btw-add-home'?>

      <?rfc include='reference.I-D.ietf-dnsop-terminology-ter'?>

      <?rfc include='reference.I-D.arkko-farrell-arch-model-t'?>

      <reference anchor="Firefox-Policy"
                 target="https://github.com/mozilla/policy-templates/blob/master/README.md#dnsoverhttps">
        <front>
          <title>Policy templates for Firefox</title>

          <author></author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Firefox-TRR"
                 target="https://wiki.mozilla.org/Trusted_Recursive_Resolver">
        <front>
          <title>Trusted Recursive Resolver</title>

          <author></author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="dpp"
                 target="https://www.wi-fi.org/download.php?file=/sites/default/files/private/Device_Provisioning_Protocol_Specification_v1.1_1.pdf">
        <front>
          <title>Wi-Fi Device Provisioning Protocol (DPP)</title>

          <author fullname="" surname="Specifictaion version 1.1">
            <organization>Wi-Fi Alliance</organization>
          </author>

          <date month="" year="2018" />
        </front>

        <seriesInfo name="Wi-Fi Alliance" value="" />
      </reference>

      <reference anchor="oma"
                 target="http://www.openmobilealliance.org/release/LightweightM2M/V1_1_1-20190617-A/OMA-TS-LightweightM2M_Core-V1_1_1-20190617-A.pdf">
        <front>
          <title>Lightweight Machine to Machine Technical Specification:
          Core</title>

          <author fullname="" surname="Approved Version: 1.1.1 - 2019 06 17">
            <organization>Open Mobile Alliance</organization>
          </author>

          <date month="June" year="2019" />
        </front>

        <seriesInfo name="Open Mobile Alliance" value="" />
      </reference>

      <reference anchor="ocf"
                 target="https://openconnectivity.org/specs/OCF_Security_Specification_v1.0.0.pdf">
        <front>
          <title>OCF Security Specification</title>

          <author fullname="" surname="Version: 1.0.0">
            <organization>Open Connectivity Foundation</organization>
          </author>

          <date month="June" year="2017" />
        </front>

        <seriesInfo name="Open Connectivitiy Foundation" value="" />
      </reference>

      <reference anchor="Chrome-Policy"
                 target="https://support.google.com/chrome/a/answer/2657289?hl=en">
        <front>
          <title>Chrome policies for users or browsers</title>

          <author>
            <organization>The Unicode Consortium</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Chrome-DoH"
                 target="https://www.chromium.org/developers/dns-over-https">
        <front>
          <title>Chrome DNS over HTTPS (aka DoH)</title>

          <author>
            <organization>The Unicode Consortium</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="win10s"
                 target="https://www.microsoft.com/en-us/windows/s-mode">
        <front>
          <title>Windows 10 in S mode</title>

          <author>
            <organization>Microsoft</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="Chromebook"
                 target="https://support.google.com/chromebook/answer/3438631?hl=en">
        <front>
          <title>Chromebook security</title>

          <author>
            <organization>Microsoft</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="PSK"
                 target="https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.html">
        <front>
          <title>Identity PSK Feature Deployment Guide</title>

          <author>
            <organization>Cisco</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="MDM-Apple"
                 target="https://developer.apple.com/documentation/devicemanagement">
        <front>
          <title>Mobile Device Management</title>

          <author>
            <organization>Apple</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="OTA"
                 target="https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/OTASecurity.html">
        <front>
          <title>Over-the-Air Profile Delivery Concepts</title>

          <author>
            <organization>Apple</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <reference anchor="PEAP"
                 target="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9">
        <front>
          <title>[MS-PEAP]: Protected Extensible Authentication Protocol
          (PEAP)</title>

          <author>
            <organization>Microsoft</organization>
          </author>

          <date day="" month="" year="" />
        </front>
      </reference>

      <!---->
    </references>
  </back>
</rfc>