]> FreeRADIUS

aland@freeradius.org

Sandelman Software Works

mcr+ietf@sandelman.ca

Internet anima Working Group Internet-Draft This document describes a method by which an unconfigured device can use EAP to join a network on which further device onboarding, network attestation or other remediation can be done. While RFC 5216 supports EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. First, by defining the @eap.arpa domain, and second by showing how it can be used to provide quarantined network access for onboarding unauthenticated devices. About This Document Status information for this document may be found at . Discussion of this document takes place on the anima Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction There are a multitude of situations where a network device needs to join a new (wireless) network but where the device does not yet have the right credentials for that network. As the device does not have credentials, it cannot access networks which typically require authentication. However, since the device does not have network access, it cannot download a new configuration which contains updated credentials. The process by which a device acquires these credentials has become known as onboarding . There are many onboarding protocols, including , , , CSA MATTER, and OPC UA Part 21. Some of these protocols use WiFi Public frames, or provide for provisioning as part of EAP, such as . Other systems require pre-existing IP connectivity in order to configure credentials for a device, which causes a circular dependancy. This document defines a method where devices can use unauthenticated EAP in order to obtain network access, albeit in a captive portal . Once the device is in a captive portal, it has access to the full suite of Internet Protocol (IP) technologies, and can proceed with onboarding. We believe that the method defined here is clearer, safer, and easier to implement and deploy than alternatives. This method also allows for multiple onboarding technologies to co-exist, and for the technologies to evolve without requiring invasive upgrades to layer-2 infrastructure. The method detailed in this document uses the unauthenticated client mode of EAP-TLS. While defines EAP-TLS without a client certificate, that document defines no method by which unauthenticated EAP-TLS can be used. This draft addresses that issue. First, by defining the @eap.arpa domain, and second by showing how it can be used to provid network access for onboarding unauthenticated devices. Note that this specification does not specify the exact method used for onboarding devices! There are many possibilities, with some methods yet to be defined. Not all of them are enumerated here.

Terminology 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 when, and only when, they appear in all capitals, as shown here. The term supplicant is used to refer to the network device which is attempting to do EAP-TLS. The term pledge (from ) is used to refer to the network device which has successfully performed unauthenticated client mode EAP-TLS, and now has access to a network on which is may perform onboarding.

Protocol Details The onboarding is divided into the following phases:

• Discovery - the supplicant determines that a network can do onboarding,
• Authentication - the supplicant connects to the network as an unauthenticated device,
• Authorization - the network provides limited connectivity to the device/pledge,
• Onboarding - the device/pledge uses standard IP protocols to perform onboarding,
• Full network access - the device has provisioned credentials, and can proceed with normal network access.

Discovery The network should use 802.11u to signal that it can potentially perform onboarding, by using 802.11u and indicating that it supports the realm "eap.arpa". When a supplicant which requires onboarding sees this realm, it knows that the network may be suitable for onboarding. Note that not all such networks are suitable for onboarding using the technologies that a supplicant has. Some networks might have only a captive portal, intended for human use. This is the "coffee shop" case. There may be multiple such networks available, and only one (or none) may be willing to onboard this particular device. Further, the device does not necessarily trust any such network. There are situations where there may be many hundreds of networks which offer onboarding, and a supplicant device may need to try all of them until it finds a network to which it can successfully onboard. An example of such a situation is in a large (dozens to hundreds of floors) apartment building in a downtown core, where radio signals may leak from adjacent units, reflect off glass windows, come from other floors, and even cross the street from adjacent buildings. This document does not address this issue, but anticipates future work in 802.11u, perhaps involving some filtering mechanism using Bloom Filters. Supplicants MUST limit their actions in the onboarding network to the action of onboarding. If this process cannot be completed, the device MUST disconnect from the onboarding network, and try again, usually by selecting a different network. As soon as the device has been onboarded, the device MUST disconnect from the onboarding network, and use the provided configuration to authenticate and connect to a fully-capable network.

Authentication The supplicant presents itself as an unauthenticated peer, which is allowed by EAP-TLS Section 2.1.1. TLS 1.2 or TLS 1.3 may be used, but TLS 1.3 or higher is RECOMMENDED. The supplicant uses an identity of onboarding@eap.arpa, and provides no TLS client certificate. The use of the "eap.arpa" domain signals to the network that the device wishes to use unauthenticated EAP-TLS.

Authorization Upon receipt of a supplicant without any authentication, the AAA server returns instructions to the authenticator to place the new client into the quarantined or captive portal network. The exact method is network-dependent, but it is usually done with a dedicated VLAN which has limited network access.

Characteristics of the Quarantine Network The quarantine network SHOULD be segregated at layer-two (ethernet), and should not permit ethernet frames to any destination other than a small set of specified routers. Specifically, the layer infrastructure should prevent one pledge from attempting to connect to another pledge. For some onboarding protocols such as , only IPv6 Link-Local frames are needed. Such a network MUST provide a Join Proxy as specified in . For other onboarding protocols more capabilities may be needed, in particular there need for a DHCPv4 server may be critical for the device to believe it has connected correctly. This is particularly the case where a normal "smartphone" or laptop system will onboard via a captive portal. Once on the quarantine network, device uses other protocols to perform the onboarding action.

Captive Portal While this document imposes no requirements on the rest of the network, captive portals have been used for almost two decades. The administration and operation of captive portals is typically within the authority of administrators who are responsible for network access. As such, this document defines additional behavior on, and requirements for, captive portals, so long as those changes materially benefit the network access administrator.

Privacy Considerations Devices should take care to hide all identifying information from the onboarding network. Any identifying information MUST be sent encrypted via a method such as TLS.

Security Considerations Devices using an onboarding network MUST assume that the network is untrusted. All network traffic SHOULD be encrypted in order to prevent attackers from both eavesdropping, and from modifying any provisioning information. Similarly onboarding networks MUST assume that devices are untrusted, and could be malicious. Networks MUST make provisions to prevent Denial of Service (DoS) attacks, such as when many devices attempt to connect at the same time. Networks MUST limit network access to onboarding protocols only. Networks SHOULD also limit the bandwidth used by any device which is being onboarded. The configuration information is likely to be small (megabytes at most), and it is reasonable to require a second or two for this process to take place. Any device which cannot be onboarded within approximately 30 seconds SHOULD be disconnected. Such a delay signals either a malicious device / network, or a misconfigured device / network. If onboarding cannot be finished within a short timer, the device should choose another network.

Use of eap.arpa Supplicants MUST use the "eap.arpa" domain only for onboarding and related activities. Supplicant MUST use unauthenticated EAP-TLS. Networks which support onboarding via the "eap.arpa" domain MUST require that supplicants use unauthenticated EAP-TLS. The use of other EAP types MUST result in rejection, and a denial of all network access. The "eap.arpa" domain MUST NOT be used in any other context, such as in an NAI , etc. in any other protocol.

IANA Considerations The special-use domain "eap.arpa" should be registered in the .arpa registry (https://www.iana.org/domains/arpa). No A, AAAA, or PTR records are requested.

Domain Name Reservation Considerations This template is filled in, complying with section 5.

Users:

Human users are not expected to recognize this name as special.

Application Software:

Only writers of network connectivity sub-systems (WiFi) are expected to see this new domain. No other software (such browsers) should care about this name.

Name Resolution APIs and Libraries:

Name Resolution APIs and Libraries do not need to mark this name as special.

Caching DNS Servers:

DNS Caches do not need to do any special processing for this name.

Authoritative DNS Servers:

Authoritative DNS servers do not need any special processing.

DNS Server Operators: ; DNS Server Opreators do not need to do anything special.

DNS Registries/Registrars:

DNS Registrars presently do not registar any names in .arpa, and this name reservation will be no different.

Acknowledgements TBD.

Changelog 01 to 02: minor edits.

References Normative References RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282. This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length. Aalto University Denpel Informatique University of Oviedo This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completetion, and the knowledge imparted to the IoT devices after the setup is complete. n.d. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.