Resource Directory Names for Certificate Mode DTLS

Today, many Internet of Things (IoT) deployments consist of an IoT device that interacts with a cloud service infrastructure. (This deployment model is described in Section 2.2 of .) If TLS/DTLS is used to mutually authenticate the device and the cloud server, then the guidance in - which, in turn, takes recommendations into account - should be followed. In particular, according to Section 9.1.3.3 of , a client that receives a certificate from the server must check that the authority of the requested URI matches "at least one of the authorities of any CoAP URI found in a field of URI type in the SubjectAltName (SAN) set. If there is no SubjectAltName in the certificate, then the authority of the request URI must match the Common Name (CN) found in the certificate [...]." According to Section 4.2.1.6 of an URI that includes an authority - such as a 'coaps' URI - needs to include a fully qualified domain name (FQDN), or an IP literal as its host part. (So, an IoT device that wants to talk to a CoAP server at coaps://example.com will expect to receive a certificate with a matching URI in either the content of the SAN extension or the CN.) The combination of the two requirements above, together with text in Section 3 of which only allows FQDN hostname of the server in the ServerName field, basically binds Certificate Mode DTLS to either DNS, or static host tables containing FQDN's mappings, or some other system for lookup of registered names which is able to fully mimic the DNS naming scheme. While DNS can be taken for granted in the Web, CoAP networks do not mandate its presence. In fact, there are IoT deployments where the server infrastructure is located in a home or residential environment in which IoT devices interact with the server solely in the local network (see also Section 2.1 of ). Since static configuration is not generally a viable option, in order to cope with scenarios like the one described above there is a need to define some kind of stable, non-DNS, identifier that can be used for 'coaps' URIs in Certificate Mode DTLS as a fall-back in case DNS is not deployed, or not understood by CoAP endpoints.

There seem to be at least four challenges that need to be solved to make sure that the IoT device is indeed talking to a server whose X.509 certificate identity can be compared with the requested CoAP URI: what identifiers should be used in the certificate? What identifier should be contained in the hostname part of the endpoint URI? What identifier should be communicated in the SNI during the TLS/DTLS exchange? How can the identifier in the CoAP URI be mapped to an IP address? The way the Web solves these problems is by assuming that the name of an application service is based on a DNS domain name, as stated in . The identifiers used in the certificate and in the SNI are then FQDN's. In order to offer a solution for the CoAP space this document suggests the use of Resource Directory endpoint names (and domains) as an alternative to DNS names.

This specification requires the reader to be familiar with the terminology used in documents produced by the CoRE, TLS, and PKIX working groups. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

In CoAP networks, a Resource Directory (RD) is an entity that acts as a centralized store where protocol endpoints can register and lookup links to resources that are made available in the network. The RD defines the concept of an "endpoint name" which identifies a given Endpoint (i.e. web server) within a given "domain". Under the assumption of its uniqueness, an endpoint name/domain can be used as a stable host component for CoAP authorities.

An endpoint name is guaranteed to be unique within the associated domain. If the domain is elided during registration, the RD should assure its uniqueness within an implicit default domain.

The syntax for RD name authorities has been designed to satisfy the following requirements: full compatibility with URI reg-name syntax; support identifiers from different and independently administered sources (e.g. those defined in OMA spec, EUI-64 , etc.); allow for an optional "domain" under which a given name exists (for compatibility with current RD spec).

The following ABNF reuses 'port' from ; ALPHA and DIGIT from .

Note that RD-char is the set of chars allowed in reg-name (REQ#1) from which the two following characters have been removed: the dot ("."), which is used to introduce the domain component (REQ#3); the plus ("+"), which is used to encode namespace information along with the name in an unambiguous way (REQ#2). If RD-ns is present, then the length of RD-ns and RD-name MUST be less then 63 chars. Percent encoding MUST NOT be used if not needed, i.e. it can be used only to encode non otherwise allowed chars.

eui-64+01-23-45-67-89-ab-cd-ef imei+123456789012345 imei+123456789012345:9876 uuid+64d5ecfa-addc-4695-ac6e-36e8b18de4b9 eui-64+01-23-45-67-89-ab-cd-ef.local:1234 name.domain:1234

When RD-authority is used in a 'coaps' URI, its value is the same as the ServerName.name included (and successfully validated) by the client in the associated DTLS handshake (see ). Hence, there is no need to include explicit Uri-Host and Uri-Port Options in requests associated to the same security context This updates Sections 6.4 and 6.5 of [RFC7252]. If any of Uri-Host or Uri-Port is included in the request, then its value MUST match the corresponding value set in the established security context.

In order to encode RD authorities in a ServerNameList, the extension_data field of the server_name extension is expanded to allow a RDAuthority in a ServerName:

; ]]> RDAuthority, the data structure associated with the rd_authority NameType, is a variable-length vector that begins with a 16-bit length field indicating the length of the following RD authority. The RD authority is represented as a byte string using ASCII encoding. It MUST NOT contain any percent-encoded character other than for those characters not explicitly allowed by the grammar in .

This OID designates the OID arc for CoAP-related OIDs assigned by future IETF action, including those introduced by the present document:

A X.509 Server Certificate intended to be used for resources served by a RD authority MUST contain an otherName SAN identified using a type-id of 'id-rdauthority-san':

The value field of the otherName MUST contain an RD authority (), encoded as a IA5String.

Send extended ClientHello containing: server_name extension with one (and one only) ServerName, case-insensitive matching the authority of the URI to be requested; Any other potentially useful extension, e.g. client_certificate_url; Verify that the intended server name is indeed one of the identities bound to the presented certificate, by checking that the name in the SAN otherName of type id-rdauthority-san case-insensitive matches the authority requested via server_name; Upon receiving the CertificateRequest message, send the certificate via a Certificate message - or CertificateURL message, if the client_certificate_url extension has been successfully negotiated during the "hello" phase; Send ClientKeyExchange and then CertificateVerify to complete the mutual authentication process.

Server receives extended ClientHello carrying a server_name extension, and uses the given server_name (with a rd_authority NameType) to select the appropriate certificate. The selected certificate MUST include a SAN otherName with an id-rdauthority-san type-id and value, which MUST case-insensitive match the requested ServerName; If no certificate can be selected, the server MUST terminate the handshake by sending a fatal-level unrecognized_name(112) alert. Prefer a single, hard failure, path over soft failure, or worse: ignoring the error altogether. Rationale: do not waste time/energy; provide clear and prompt diagnostic to the peer. It doesn't look like the condition that could be exploited by a timing attack. If a matching certificate exist, the server SHALL include an extension of type "server_name" in the (extended) ServerHello message with an empty value. The server MUST send the selected certificate back to the client in the Certificate message. Server MUST then request the client certificate via a CertificateRequest message and conclude its negotiation with a ServerHelloDone message. When server receives the Certificate message from the client then, depending on the specific application security policy, it MAY want to match one of the identities of the client against a configured ACL, and decide whether to continue or to tear down the session TODO Which alert code to use if ACL check fails?. The server application running on top of DTLS MUST check the requested URI authority case-insensitive matches the requested server_name.

Need to register a few new IDs, not sure where (IANA, PKIX registry, TLS registry)? id-coap OtherName.type-id::id-rdauthority-san NameType::rd_authority ServerName.name::RDAuthority

It's the responsibility of the CA, by means of its Registration Authority component, to verify the identity of the requester before issuing a new certificate. In particular, the CA MUST ensure that no more than one certificate per SAN is valid at any given time. This should exclude the threat of a (possibly rogue) node to successfully impersonate another node's identity. Security considerations from Section 11.1 of fully apply.

TODO