Internet DRAFT - draft-fossati-core-server-name-id

draft-fossati-core-server-name-id







CORE                                                          T. Fossati
Internet-Draft                                                     Nokia
Intended status: Standards Track                           H. Tschofenig
Expires: September 1, 2016                                      ARM Ltd.
                                                       February 29, 2016


          Introducing Server Name Identifiers in Certificates
                draft-fossati-core-server-name-id-00.txt

Abstract

   TBD.

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 http://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 September 1, 2016.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Fossati & Tschofenig    Expires September 1, 2016               [Page 1]

Internet-Draft            SN-ID in Certificates            February 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Requirements Language . . . . . . . . . . . .   3
   3.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Server Name Indication (SNI) Name Type and Server Name Syntax   4
   5.  Subject Alternative Name Extension  . . . . . . . . . . . . .   4
   6.  Client Behaviour  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Server Behaviour  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     12.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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 [RFC7452].)  If TLS/
   DTLS is used to mutually authenticate the device and the cloud
   server, then the guidance in [I-D.ietf-dice-profile] - which, in
   turn, takes [RFC7252] recommendations into account - should be
   followed.

   Let us take the CoAP protocol as an example.  According to
   Section 9.1.3.3 of [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
   [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.

   The Server Name Indication (SNI) extension [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 [RFC6066] only allows FQDN
   hostname of the server in the ServerName field.



Fossati & Tschofenig    Expires September 1, 2016               [Page 2]

Internet-Draft            SN-ID in Certificates            February 2016


   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 [RFC7452]).

   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 [RFC7250].

   This document specifies such identifiers for use with certificates.

2.  Terminology and Requirements Language

   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 [RFC2119].

3.  Syntax

   [Editor's Note: This is a strawman proposal for the identifier
   definition.]

   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).

   The following ABNF reuses ALPHA and DIGIT from [RFC5234].

               char = ALPHA / DIGIT / "-" / "_" / "~" / "!" /
                         "$" / "&" / "'" / "(" / ")" / "*" /
                         "," / ";" / "="
               ns = ALPHA *(ALPHA / DIGIT / "-")
               name = 1*RD-char
               domain = 1*63RD-char
               authority = [ ns "." ] name [ "@" domain ]

   Note that the "@" and the "." signs are illegal characters in the
   name and the ns components.



Fossati & Tschofenig    Expires September 1, 2016               [Page 3]

Internet-Draft            SN-ID in Certificates            February 2016


   Here are some examples:

   o  eui64.01-23-45-67-89-ab-cd-ef

   o  imei.+123456789012345

   o  uuid.84c05e54-1d3c-48b6-bf12-c11c55f8fdac@foo

4.  Server Name Indication (SNI) Name Type and Server Name Syntax

   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:


                    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>;

   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 Section 3.

5.  Subject Alternative Name Extension

   As described in RFC 5280 [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.




Fossati & Tschofenig    Expires September 1, 2016               [Page 4]

Internet-Draft            SN-ID in Certificates            February 2016


   This section defines the SN-ID as a form of otherName from the
   GeneralName structure in SubjectAltName defined in [RFC5280].

          id-sn-id OBJECT IDENTIFIER ::= { id-pkix id-sn-id(TODO) }

   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'.

             id-sn-id-san OBJECT IDENTIFIER ::= { id-sn-id 2 }

   The value field of the otherName MUST contain the SN-ID, as described
   in Section 3, encoded as a IA5String.

6.  Client Behaviour

   TLS/DTLS clients behave as follows:

   1)  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.

   2)  Process the Certificate message, verify the digitial signature
       and perform path validation (as described in Section 3.2 of RFC
       5280).

   3)  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.

   4)  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.

   5)  Send ClientKeyExchange and then CertificateVerify to complete the
       mutual authentication process.

7.  Server Behaviour

   TLS/DTLS servers behave as follows:

   1)  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-



Fossati & Tschofenig    Expires September 1, 2016               [Page 5]

Internet-Draft            SN-ID in Certificates            February 2016


       id-san type-id and value, which MUST match the requested
       ServerName;

       a)  If no certificate can be selected, the server MUST terminate
           the handshake by sending a fatal-level unrecognized_name(112)
           alert.  [[CREF1: 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.]]

       b)  If a matching certificate exist, the server SHALL include an
           extension of type "server_name" in the (extended) ServerHello
           message with an empty value.

   2)  The server MUST send the selected certificate to the client in
       the Certificate message.

   3)  Server MAY request a client certificate via a CertificateRequest
       message and conclude its negotiation with a ServerHelloDone
       message.

   4)  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).

       a)  If the client certificate processing fails then the server
           MUST tear down the exchange.

       b)  If the client certificate processing is successful then the
           server finalizes the TLS handshake.

   5)  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.

8.  Example

   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) [I-D.ietf-core-resource-directory]
   helping with discovery.





Fossati & Tschofenig    Expires September 1, 2016               [Page 6]

Internet-Draft            SN-ID in Certificates            February 2016


   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.

   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 [RFC7252].  In the context of
   [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.

   Imagine various IoT devices registering their resources with the pre-
   configured RD (or dynamically discoverd RD).  Section 5.2 of
   [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.

   Once the resources are registered nodes may use the resource
   directory to discover the resources offered by others.  Section 7 of
   [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).

   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
   Section 6 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.

9.  IANA Considerations

   TBD: This document requires registration of various identifiers into
   existing registries,namely




Fossati & Tschofenig    Expires September 1, 2016               [Page 7]

Internet-Draft            SN-ID in Certificates            February 2016


   o  id-sn-id

   o  OtherName.type-id::id-sn-id-san

   o  NameType::sn-id

   o  ServerName.name::Authority

10.  Security Considerations

   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.

   Security considerations from Section 11.1 of [RFC6066] fully apply.

11.  Acknowledgements

   We would like to thank Martin Thomson, Carsten Bormann, Andrew
   McGregor, and Zach Shelby for their feedback during IETF 92.

12.  References

12.1.  Normative References

   [I-D.ietf-core-resource-directory]
              Shelby, Z. and C. Bormann, "CoRE Resource Directory",
              draft-ietf-core-resource-directory-02 (work in progress),
              November 2014.

   [I-D.ietf-dice-profile]
              Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the
              Internet of Things", draft-ietf-dice-profile-17 (work in
              progress), October 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
              RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.




Fossati & Tschofenig    Expires September 1, 2016               [Page 8]

Internet-Draft            SN-ID in Certificates            February 2016


   [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,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066, DOI
              10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
              RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

12.2.  Informative References

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,
              <http://www.rfc-editor.org/info/rfc7452>.

Authors' Addresses

   Thomas Fossati
   Nokia
   3 Ely Road
   Milton, Cambridge  CB24 6DD
   Great Britain

   Email: thomas.fossati@nokia.com


   Hannes Tschofenig
   ARM Ltd.
   110 Fulbourn Rd
   Cambridge  CB1 9NJ
   Great Britain

   Email: Hannes.tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at



Fossati & Tschofenig    Expires September 1, 2016               [Page 9]