<?xml version="1.0" encoding="US-ASCII"?>
<!-- vim: set ts=2 expandtab: -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!-- <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"> --> 
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC4944 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY RFC5055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5055.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC6066 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!-- <!ENTITY RFC6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml"> --> 
<!ENTITY RFC7043 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7043.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7250.xml">

<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-resource-directory-02.xml">
<!-- <!ENTITY I-D.ietf-lwig-tls-minimal SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lwig-tls-minimal-01.xml">-->
<!ENTITY RFC7452 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7452.xml">
<!ENTITY I-D.ietf-dice-profile SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dice-profile.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-fossati-core-server-name-id-00.txt" ipr="trust200902">
  <front>
    <title abbrev="SN-ID in Certificates"> Introducing Server Name Identifiers in Certificates </title>
    <author fullname="Thomas Fossati" initials="T.F." surname="Fossati">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>3 Ely Road</street>
          <city>Milton, Cambridge</city>
          <code>CB24 6DD</code>
          <country>Great Britain</country>
        </postal>
        <email>thomas.fossati@nokia.com</email>
      </address>
    </author>

    <author fullname="Hannes Tschofenig" initials="H.T." surname="Tschofenig">
      <organization>ARM Ltd.</organization>
      <address>
        <postal>
          <street>110 Fulbourn Rd</street>
          <city>Cambridge</city>
          <code>CB1 9NJ</code>
          <country>Great Britain</country>
        </postal>
        <email>Hannes.tschofenig@gmx.net </email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>

    <date year="2016"/>

    <area>APPS</area>
    <workgroup>CORE</workgroup>

    <keyword>CoAP, TLS, Internet of Things</keyword>

    <abstract>
      <t>TBD.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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
          <xref target="RFC7452"/>.) If TLS/DTLS is used to mutually authenticate the device and the
        cloud server, then the guidance in <xref target="I-D.ietf-dice-profile"/> - which, in turn,
        takes <xref target="RFC7252"/> recommendations into account - should be followed.</t>

      <t>Let us take the CoAP protocol as an example. According to Section 9.1.3.3 of <xref
          target="RFC7252"/>, a DTLS client that receives a certificate from the DTLS 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 [...].". A 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, as stated in Section 4.2.1.6 of <xref target="RFC5280"/>. 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.</t>

      <t>The Server Name Indication (SNI) extension <xref target="RFC6066"/> defined for TLS/DTLS
        allows a client to tell a server the name of the server it is contacting. This is a feature
        useful when the server is part of a hosting solution where multiple virtual servers are
        using a single underlying network address. Section 3 of <xref target="RFC6066"/> only allows
        FQDN hostname of the server in the ServerName field.</t>

      <t>When a TLS/DTLS server has an FQDN registered in the DNS then the use of certificates work
        well with TLS/DTLS to secure protocols like HTTP or CoAP. While the DNS can be taken for
        granted in the Web, many IoT deployments do not mandate its presence. There are even IoT
        deployments where the server infrastructure is located in a residential environment in which
        IoT devices interact with the server solely in the local network (see also Section 2.1 of
          <xref target="RFC7452"/>).</t>

      <t>Since static configuration is not generally a viable option from a usability point of view,
        in order to cope with scenarios like the one described above there is a need to define some
        kind of stable, non-DNS-based identifier that can be used with certificates. Note that an alternative is to avoid using
        certificates altogether and to instead use raw public keys. With raw public keys, the raw public key
        itself is the identifier and some out-of-band validation technique is needed instead, as
        described in RFC 7250 <xref target="RFC7250"/>.</t>

      <t>This document specifies such identifiers for use with certificates.</t>


    </section>
    <!-- Introduction -->

    <!-- ************************************************************* -->

    <section title="Terminology and Requirements Language">
      <!--      <t>This specification requires the reader to be familiar with the terminology used in documents produced by the CoRE, TLS, and PKIX working groups.</t>
-->
      <t>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
          <xref target="RFC2119"/>.</t>
    </section>
    <!-- Terminology and Requirements Language -->

    <!-- ************************************************************* -->

<!-- 
        <section title="Syntax">
          <t>The following ABNF reuses ALPHA and DIGIT from <xref target="RFC5234" />.</t>
          <figure>
            <artwork align="center"><![CDATA[
  RD-char = ALPHA / DIGIT / "-" / "_" / "~" / "!" /
            "$" / "&" / "'" / "(" / ")" / "*" /
            "," / ";" / "="
  RD-ns = ALPHA *(ALPHA / DIGIT / "-")  ; the name-space
  RD-name = 1*RD-char
  RD-domain = 1*63RD-char
  RD-authority = [ RD-ns "+" ] RD-name [ "." RD-domain ] 
            ]]></artwork>
          </figure>
          <t>Note that RD-char is the set of chars allowed in URI reg-name from which the following two characters have been removed:
            <list style="symbols"> 
              <t>the dot ("."), which is used to introduce the domain component;</t>
              <t>the plus ("+"), which is used to encode namespace information along with the name in an unambiguous way.</t>
            </list>   
          </t>
          <t>If RD-ns is present, then the length of RD-ns and RD-name MUST be less then 63 chars.</t>
          <t>Percent encoding MUST NOT be used if not needed, i.e. it can be used only to encode non otherwise allowed chars.</t>
        </section>
        <section title="Examples">
          <t>
            <list style="symbols">
              <t>eui-64+01-23-45-67-89-ab-cd-ef</t>
              <t>imei+123456789012345</t>
              <t>imei+123456789012345:9876</t>
              <t>uuid+64d5ecfa-addc-4695-ac6e-36e8b18de4b9</t>
              <t>eui-64+01-23-45-67-89-ab-cd-ef.local</t>
              <t>name.domain:1234</t>
            </list>
          </t>
        </section>
--> 
    <section anchor="syntax" title="Syntax">

     <t>[Editor's Note: This is a strawman proposal for the identifier definition.]</t>

      <t>This section defines the syntax for the instance and the domain component, which are
        separated by the "@" sign. The structure for the name and the domain component are
        determined by the namespace prefix. We call this new construct the 'Server Name Identifier'
        (SN-ID).</t>

      <t>The following ABNF reuses ALPHA and DIGIT from <xref target="RFC5234"/>.</t>
      <t>
        <figure>
          <artwork align="center"><![CDATA[
  char = ALPHA / DIGIT / "-" / "_" / "~" / "!" /
            "$" / "&" / "'" / "(" / ")" / "*" /
            "," / ";" / "=" 
  ns = ALPHA *(ALPHA / DIGIT / "-")  
  name = 1*RD-char
  domain = 1*63RD-char
  authority = [ ns "." ] name [ "@" domain ] 
            ]]></artwork>
        </figure>
      </t>

      <t>Note that the "@" and the "." signs are illegal characters in the name and the ns
        components.</t>
      <t>Here are some examples: <list style="symbols">
          <t>eui64.01-23-45-67-89-ab-cd-ef</t>
          <t>imei.+123456789012345</t>
          <t>uuid.84c05e54-1d3c-48b6-bf12-c11c55f8fdac@foo</t>
        </list>
      </t>
    </section> 

    <!-- ************************************************************* -->

    <section title="Server Name Indication (SNI) Name Type and Server Name Syntax" anchor="SNI">
      <t>In order to encode the SN-ID in a ServerNameList, the extension_data field of the
        server_name extension is expanded to allow the SN-ID in a ServerName extension:</t>
      <t>
        <figure>
          <artwork align="center">
            <![CDATA[
struct {
    NameType name_type;
    select (name_type) {
        case host_name: HostName;
        case sn_id: AuthorityType;
    } name;
} ServerName;

enum {
    host_name(0),
    sn_id(1),
    (255)
} NameType;

opaque AuthorityType<1..2^16-1>;
]]></artwork>
        </figure>
      </t>

      <t>AuthorityType, the data structure associated with the authority declaration, is a
        variable-length vector that begins with a 16-bit length field indicating the length of the
        following authority. The value in the authority field 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 <xref target="syntax"/>.</t>
    </section>

    <!-- ************************************************************* -->

    <section title="Subject Alternative Name Extension">

      <t>As described in RFC 5280 <xref target="RFC5280"/> the subjectAltName may carry additional
        name types through the use of the otherName field. The format and semantics of the name are
        indicated through the OBJECT IDENTIFIER in the type-id field. The name itself is conveyed as
        value field in otherName. This document defines a new value for the type-id field.</t>

      <t>This section defines the SN-ID as a form of otherName from the GeneralName structure in
        SubjectAltName defined in <xref target="RFC5280"/>.</t>

      <t>
        <figure>
          <artwork align="center"><![CDATA[
   id-sn-id OBJECT IDENTIFIER ::= { id-pkix id-sn-id(TODO) }
          ]]></artwork>
        </figure>
      </t>

      <t>An X.509 server certificate intended to be used with this specification MUST contain an
        otherName SAN identified using a type-id of 'id-sn-id-san'.</t>

      <t>
        <figure>
          <artwork align="center"><![CDATA[
id-sn-id-san OBJECT IDENTIFIER ::= { id-sn-id 2 }
          ]]></artwork>
        </figure>
      </t>

      <t>The value field of the otherName MUST contain the SN-ID, as described in <xref
          target="syntax"/>, encoded as a IA5String.</t>

    </section>

    <!-- ************************************************************* -->

    <section anchor="client" title="Client Behaviour">

      <t>TLS/DTLS clients behave as follows: <list style="format %d)">
          <t>Clients MAY include an extension of type "server_name" in the (extended) client hello.
            A client supporting this specification MAY include one (and one only) ServerName element
            conveying the SN-ID.</t>
          <t>Process the Certificate message, verify the digitial signature and perform path
            validation (as described in Section 3.2 of RFC 5280).</t>
          <t>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-sn-id-san matches the authority requested via server_name.</t>
          <t>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" exchange.</t>
          <t>Send ClientKeyExchange and then CertificateVerify to complete the mutual authentication
            process.</t>
        </list>
      </t>
    </section>

    <!-- ************************************************************* -->

    <section anchor="server" title="Server Behaviour">

      <t>TLS/DTLS servers behave as follows: <list style="format %d)">
          <t>A server receiving the extended ClientHello carrying a server_name extension uses the
            given server_name (with the included SN-ID) to select the appropriate certificate. The
            selected certificate MUST include a SAN otherName with an id-sn-id-san type-id and
            value, which MUST match the requested ServerName; <list style="format %c)">
              <t>If no certificate can be selected, the server MUST terminate the handshake by
                sending a fatal-level unrecognized_name(112) alert. <cref>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.</cref></t>
              <t>If a matching certificate exist, the server SHALL include an extension of type
                "server_name" in the (extended) ServerHello message with an empty value.</t>
            </list></t>
          <t>The server MUST send the selected certificate to the client in the Certificate message.</t>
          <t>Server MAY request a client certificate via a CertificateRequest message and conclude
            its negotiation with a ServerHelloDone message.</t>
          <t>When server receives the Certificate message from the client it MUST process the
            Certificate message, verify the digitial signature of the certificate and perform path
            validation (as described in Section 3.2 of RFC 5280). <list style="format %c)">
              <t>If the client certificate processing fails then the server MUST tear down the
                exchange.</t>
              <t>If the client certificate processing is successful then the server finalizes the
                TLS handshake.</t>
            </list>
          </t>
          <t>The server application running on top of the TLS/DTLS stack MUST check the included
            client identity against the access control policy at the server. It is important to note
            that this verification check is done outside the TLS/DTLS stack; failure to do it at the
            application layer may result in unauthorized access.</t>
        </list></t>
      <!--
      <t><cref>TODO What happens if the client sends also a PSK ciphersuite and the server agrees?</cref></t>
      <t><cref>FIXME Add para that states "all other requirements given in CoAP are still valid".</cref></t>
      <t><cref>FIXME Remember to use established TLS notation, e.g. ClientHello.random, etc.</cref></t>
      -->
    </section>

    <!-- ************************************************************* -->

    <section title="Example">

      <t>In this section we discuss a more complete scenario where the mechanism described in this
        document is practical. Consider the following setup where IoT devices are located in a small
        home network with a Resource Directory (RD) <xref target="I-D.ietf-core-resource-directory"
        /> helping with discovery.</t>

      <t>A resource directory is an entity that acts as a centralized store where protocol endpoints
        can register their resources and thereby make them available to others. Other devices subsequently use the resource directory to lookup 
devices and their resources.</t> 
  
      <t>The RD
        defines the concept of an "endpoint name" which identifies a given endpoint within a
        "domain". Endpoint (EP) is a term used to describe a web server or client in <xref
          target="RFC7252"/>. In the context of <xref target="I-D.ietf-core-resource-directory"/> an
        endpoint is used to describe a web server that registers resources to the resource
        directory. An endpoint is identified by its endpoint name, which is included during
        registration, and is unique within the associated domain of the registration.</t>

      <t>Imagine various IoT devices registering their resources with the pre-configured RD (or dynamically discoverd RD). Section
        5.2 of <xref target="I-D.ietf-core-resource-directory"/> contains a description of
        registration procedure using CoAP and offers examples. The resource server stores, among
        other things, the endpoint name and (optionally) a domain.</t>

      <t>Once the resources are registered nodes may use the resource directory to discover the
        resources offered by others. Section 7 of <xref target="I-D.ietf-core-resource-directory"/>
        describes the discovery procedure and lists examples. A node may, for example, search for
        resources of type 'temperature' and learns the network addresses of the nodes hosting those
        resources as well as their endpoint name (and, if available, their domain).</t>

      <t>Once the network address has been obtained, direct communication between the two entities
        can be initiated. During the subsequent DTLS exchange to secure CoAP the server hosting the resources
        offers his certificates and the client executes the steps outlined in <xref target="client"
        /> to match the endpoint name (and optionally the domain) learned through the resource
        directory with the SN-ID provided in the server certificate. Note that it is not envisioned
        that the client compares the input to the discovery procedure with the SN-ID. In this
        example the input to the discovery procedure with the resource directory was the resource
        type, i.e., the 'temperature' string. It is therefore assumed that the client trusts the
        resource directory to return genuine mappings from abstract search terms to specific servers
        hosting those resources.</t>
    </section>

    <!-- ************************************************************* -->

    <section title="IANA Considerations">

      <t>TBD: This document requires registration of various identifiers into existing
        registries,namely <list style="symbols">
          <t>id-sn-id</t>
          <t>OtherName.type-id::id-sn-id-san</t>
          <t>NameType::sn-id</t>
          <t>ServerName.name::Authority</t>
        </list>
      </t>
    </section>
    <!-- IANA Considerations -->

    <!-- ************************************************************* -->

    <section title="Security Considerations">
      <t>It's the responsibility of the CA issuing the certificate to verify the content of the
        certificate before issuing a new certificate. In particular, the CA MUST ensure uniqueness
        of the issued certificates and that the included SN-ID is indeed correct. This should
        exclude the threat of a (possibly rogue) node to successfully impersonate another node's
        identity.</t>

      <t>Security considerations from Section 11.1 of <xref target="RFC6066"/> fully apply.</t>
    </section>
    <!-- Security Considerations -->

    <!-- ************************************************************* -->

    <section title="Acknowledgements">
      <t>We would like to thank Martin Thomson, Carsten Bormann, Andrew McGregor, and Zach Shelby
        for their feedback during IETF 92.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References"> &RFC2119; &RFC5234;
      &RFC5280; &RFC6066; &RFC7252; &I-D.ietf-core-resource-directory;
      &I-D.ietf-dice-profile;
      <!-- 
      <reference anchor="EUI-64">
        <front>
          <title>Guidelines for 64-bit Global Identifier (EUI-64)</title>
          <author>
            <organization>IEEE</organization>
          </author>
          <date month="November" year="2012" />
        </front>
      </reference> 
-->
    </references>

    <references title="Informative References"> &RFC7452; &RFC7250; </references>
  </back>
</rfc>
