Subject: [Dtls-iot] Constrained Servers (ticket#16)

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 18 Dec 2014 12:49:07 +0100

Hi all,

I have been trying to resolve the comments related to the constrained
server discussion and the changes are as follows (see latest document
version at
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-08.txt):

- Expanded the text for the constrained client and moved text around
(see Section 4.1).

- Added new text for the constrained server case to Section 4.2 (see
also below) based on the recent email exchange (link:
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00529.html).

- Updated Section 9 "Session Resumption", Section 14 "Random Number
Generation", and Section 16 "Server Name Indication). I copied the
relevant section into this email.

Ciao
Hannes

----------

4.2.  Constrained TLS/DTLS Servers

   Section 4.1 illustrates deployment models where the TLS/DTLS client
   is constrained and efforts need to be taken to improve memory
   utilization, bandwidth consumption, reduce performance impacts, etc.
   In this section we look at cases where constrained devices run TLS/
   DTLS servers to secure access to an application layer protocol
   server, like a CoAP or HTTP server.  Running server functionality on
   a constrained node is typically more demanding since servers have to
   listen and wait for incoming requests.  Therefore, they will have
   fewer possibilities to enter sleeping cycles.  Nevertheless, there
   are legitimate reasons to deploy servers as constrained devices.

   A deployment with constrained servers has to overcome several
   challenges.  Later we will explain how these challenges has been
   solved using CoAP as an example.  Other protocols may offer similar
   capabilities.  While the requirements for the TLS/DTLS protocol
   profile change only slightly when run on a constrained server (in
   comparison to running it on a constrained client) several other eco-
   system factor will impact deployment.

   The challenges are:

   Discovery and Reachability:

      Before initiating a connection to a constrained server a client
      first needs to discover that server and, once discovered, it needs
      to maintain reachability with that device.

      In CoAP the discovery of resources offered by servers is
      accomplished by sending a unicast or multicast CoAP GET to a well-
      known URI.  The CORE Link format specification [RFC6690] describes
      the use case (see Section 1.2.1), and reserves the URI (see
      Section 7.1).  Section 7 of the CoAP specification [RFC7252]
      describes the discovery procedure.  RFC 7390 [RFC7390] describes
      use case for discovering CoAP servers using multicast (see
      Section 3.3), and specifies the protocol processing rules for CoAP
      group communications (see Section 2.7).

   Authentication:

      The next challenge concerns the provisioning of authentication
      credentials to the clients as well as servers.  In Section 4.1 we
      assumed that credentials (and other configuration information) are
      provisioned to the device and that those can be used with the
      authorization servers.  Of course, this leads to a very static
      relationship between the clients and their server-side
      infrastructure but poses fewer challenges from a deployment point
      of view, as described in Section 2 of
      [I-D.iab-smart-object-architecture] these different communication
      patterns.  In any case, engineers and product designers have to
      determine how the relevant credentials are distributed to the
      respective parties.  For example, shared secrets may need to be
      provisioned to clients and the constrained servers for subsequent
      use of TLS/DTLS PSK.  In other deployments, certificates, private
      keys, and trust anchors for use with certificate-based
      authentication may need to be utilized.

      Practical solutions either use pairing (also called imprinting) or
      a trusted third party.  With pairing two devices execute a special
      protocol exchange that is unauthenticated to establish an shared
      key (for example using an unauthenticated Diffie-Hellman exchange)
      key.  To avoid man-in-the-middle attacks an out-of-band channel is
      used to verify that nobody has tampered with the exchanged
      protocol messages.  This out-of-band channel can come in many
      forms, including:

      *  Human involvement by comparing hashed keys, entering passkeys,
         scanning QR codes

      *  The use of alternative wireless communication channels (e.g.,
         infra-red communication in addition to WiFi)

      *  Proximity-based information

      More details about these different pairing/imprinting techniques
      can be found in the smart object security workshop report
      [RFC7397] and various position papers submitted to that topic,
      such as [ImprintingSurvey].  The use of a trusted third party
      follows a different approach and is subject to ongoing
      standardization efforts in the 'Authentication and Authorization
      for Constrained Environments (ACE)' working group.

   Authorization

      The last challenge is the ability for the constrained server to
      make an authorization decision when clients access protected
      resources.  Pre-provisioning access control information to
      constrained servers may be one option but works only in a small
      scale, less dynamic environment.  For a more fine-grained and
      dynamic access control the reader is referred to the ongoing work
      in the ACE working group.

9.  Session Resumption

   Session resumption is a feature of the core TLS/DTLS specifications
   that allows a client to continue with an earlier established session
   state.  The resulting exchange is shown in Figure 8.  In addition,
   the server may choose not to do a cookie exchange when a session is
   resumed.  Still, clients have to be prepared to do a cookie exchange
   with every handshake.  The cookie exchange is not shown in the
   figure.

         Client                                               Server
         ------                                               ------

         ClientHello                   -------->
                                                          ServerHello
                                                   [ChangeCipherSpec]
                                       <--------             Finished
         [ChangeCipherSpec]
         Finished                      -------->
         Application Data              <------->     Application Data

                    Figure 8: DTLS Session Resumption.

   Constrained clients MUST implement session resumption to improve the
   performance of the handshake.  This will lead to a reduced number of
   message exchanges, lower computational overhead (since only symmetric
   cryptography is used during a session resumption exchange), and
   session resumption requires less bandwidth.

   For cases where the server is constrained (but not the client) the
   client MUST implement RFC 5077 [RFC5077].  RFC 5077 specifies a
   version of TLS/DTLS session resumption that does not require per-
   session state information to be maintained by the constrained server.
   This is accomplished by using a ticket-based approach.

   If both the client and the server are constrained devices both
   devices SHOULD implement RFC 5077 and MUST implement basic session
   resumption.

14.  Random Number Generation

   The TLS/DTLS protocol requires random numbers to be available during
   the protocol run.  For example, during the ClientHello and the
   ServerHello exchange the client and the server exchange random
   numbers.  Also, the use of the Diffie-Hellman exchange requires
   random numbers during the key pair generation.  Special care has to
   be paid when generating random numbers in embedded systems as many
   entropy sources available on desktop operating systems or mobile
   devices might be missing, as described in [Heninger].  Consequently,
   if not enough time is given during system start time to fill the
   entropy pool then the output might be predictable and repeatable, for
   example leading to the same keys generated again and again.

   It is important to note that sources contributing to the randomness
   pool on laptops, or desktop PCs are not available on many IoT device,
   such as mouse movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, etc.  Other sources have to be found or
   dedicated hardware has to be added.

   The ClientHello and the ServerHello messages contains the 'Random'
   structure, which has two components: gmt_unix_time and a random
   sequence of 28 random bytes. gmt_unix_time holds the current time and
   date in standard UNIX 32-bit format (seconds since the midnight
   starting Jan 1, 1970, GMT).  [I-D.mathewson-no-gmtunixtime] argues
   that the entire ClientHello.Random value (including gmt_unix_time)
   should be set to a cryptographically random sequence because of
   privacy concerns regarding device fingerprinting.  Since many IoT
   devices do not have access to a real-time clock this recommendation
   it is RECOMMENDED to follow the guidance outlined in
   [I-D.mathewson-no-gmtunixtime] regarding the content of the
   ClientHello.Random field.  However, for the ServerHello.Random
   structure it is RECOMMENDED to maintain the existing structure with
   gmt_unix_time followed by a random sequence of 28 random bytes since
   the client can use the received time information to securely obtain
   time information.  For constrained servers it cannot be assumed that
   they maintain accurate time information; these devices MUST include
   time information in the Server.Random structure when they actually
   obtain accurate time information that can be utilized by clients.
   Clients MUST only use time information obtained from servers they
   trust.

   IoT devices using TLS/DTLS MUST offer ways to generate quality random
   numbers.  Guidelines and requirements for random number generation
   can be found in RFC 4086 [RFC4086].

16.  Server Name Indication (SNI)

   The Server Name Indication extension defined in [RFC6066] defines a
   mechanism for a client to tell a TLS/DTLS server the name of the
   server it wants to contact.  This is a useful extension for many
   hosting environments where multiple virtual servers are run on single
   IP address.

   This specification RECOMMENDs the implementation of RFC 6066 unless
   it is known that a TLS/DTLS client does not interact with a server in
   a hosting environment.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 18 Dec 2014 14:49:18 +0000

Hi Hannes,

I took a quick scan of it and it looks very good.  The only minor suggestion that I have is if you could include a simple figure in section 4.2 (similar to your Figure 1 in section 4.1).  But this is only a Nice To Have suggestion and not a Must Have.

Best Regards,

Akbar

-----Original Message-----
From: dtls-iot [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, December 18, 2014 6:49 AM
To: [email-masked]
Subject: [Dtls-iot] Constrained Servers (ticket#16)

Hi all,

I have been trying to resolve the comments related to the constrained server discussion and the changes are as follows (see latest document version at
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-08.txt):

- Expanded the text for the constrained client and moved text around (see Section 4.1).

- Added new text for the constrained server case to Section 4.2 (see also below) based on the recent email exchange (link:
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00529.html).

- Updated Section 9 "Session Resumption", Section 14 "Random Number Generation", and Section 16 "Server Name Indication). I copied the relevant section into this email.

Ciao
Hannes

----------

   The challenges are:

   Authentication:

   Authorization

9.  Session Resumption

         Client                                               Server
         ------                                               ------

         ClientHello                   -------->
                                                          ServerHello
                                                   [ChangeCipherSpec]
                                       <--------             Finished
         [ChangeCipherSpec]
         Finished                      -------->

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Dec 2014 09:07:58 +0100

Thanks for the quick response, Akbar.

I am going to add a figure with version -09.

Ciao
Hannes

On 12/18/2014 03:49 PM, Rahman, Akbar wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>