ACE Working Group                                         R. Marin-Lopez
Internet-Draft                                      University of Murcia
Intended status: Standards Track                      D. Garcia-Carrillo
Expires: November 28, 2021                          University of Oviedo
                                                            May 27, 2021


               EAP-based Authentication Service for CoAP
                     draft-ietf-ace-wg-coap-eap-01

Abstract

   This document describes an authentication service that uses EAP
   transported employing CoAP messages with following purposes: 1)
   Authenticate a CoAP-enabled device that enters a new security domain
   managed by a domain Controller, 2) Derive key material to protect
   CoAP messages exchanged between them, enabling the establishment of a
   security association between them, and 3) Optionally, to generate key
   material for other types of Security Associations.

   Generally speaking, this document is specifying an EAP lower layer
   based on CoAP, to bring the benefits of EAP to IoT.

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 https://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 November 28, 2021.

Copyright Notice

   Copyright (c) 2021 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
   (https://trustee.ietf.org/license-info) in effect on the date of



Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 1]


Internet-Draft                  CoAP-EAP                        May 2021


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  General Architecture  . . . . . . . . . . . . . . . . . . . .   3
   3.  General Flow Operation  . . . . . . . . . . . . . . . . . . .   4
     3.1.  EAP over CoAP flow of operation . . . . . . . . . . . . .   5
     3.2.  Message processing of EAP over CoAP . . . . . . . . . . .   8
     3.3.  EAP over CoAP operation casuistics  . . . . . . . . . . .   8
   4.  Key Derivation for protecting CoAP messages . . . . . . . . .  11
     4.1.  Deriving the OSCORE Security Context  . . . . . . . . . .  12
     4.2.  Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . .  13
   5.  Examples of Use Case Scenario . . . . . . . . . . . . . . . .  13
     5.1.  Example 1:  CoAP-EAP in ACE . . . . . . . . . . . . . . .  14
     5.2.  Example 2: Multi-domain with AAA infrastructures  . . . .  15
     5.3.  Example 3: Single domain with AAA infrastructure  . . . .  15
     5.4.  Example 4: Single domain without AAA infrastructure . . .  16
     5.5.  Other use cases . . . . . . . . . . . . . . . . . . . . .  16
       5.5.1.  CoAP-EAP for network access control . . . . . . . . .  16
       5.5.2.  CoAP-EAP for service authentication . . . . . . . . .  16
   6.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  CoAP as EAP lower layer . . . . . . . . . . . . . . . . .  17
     6.2.  Size of the EAP lower layer vs EAP method size  . . . . .  18
     6.3.  Controller as the CoAP Client . . . . . . . . . . . . . .  18
     6.4.  Possible Optimizations  . . . . . . . . . . . . . . . . .  18
       6.4.1.  Empty Token . . . . . . . . . . . . . . . . . . . . .  19
       6.4.2.  Further re-authentication . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     7.1.  Authorization . . . . . . . . . . . . . . . . . . . . . .  19
     7.2.  Cryptographic suite selection . . . . . . . . . . . . . .  19
     7.3.  Freshness of the key material . . . . . . . . . . . . . .  20
     7.4.  Additional Security Consideration . . . . . . . . . . . .  20
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     10.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23






Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 2]


Internet-Draft                  CoAP-EAP                        May 2021


1.  Introduction

   The goal of this document is to describe an authentication service
   that uses the Extensible Authentication Protocol (EAP) [RFC3748].
   The authentication service is built on top of the Constrained
   Application Protocol (CoAP) [RFC7252] and allows authenticating two
   CoAP endpoints by using EAP, to establish a security association
   between them.

   In particular, this document describes how CoAP can be used as a
   constrained, link-layer independent, EAP lower layer [RFC3748] to
   transport EAP messages between a CoAP server (EAP peer) and a CoAP
   client (EAP authenticator) using CoAP messages.  The CoAP client MAY
   contact with a backend AAA infrastructure to complete the EAP
   negotiation as described in the EAP specification [RFC3748].

   The assumption is that the EAP method transported in CoAP MUST
   generate cryptographic material [RFC5247].  In this way, the CoAP
   messages can be protected after the authentication.  The general flow
   of operation of CoAP-EAP establishes an OSCORE security association
   specifically for the service.  In addition, using the key material
   derived from the authentication, we specify the establishment of
   other security associations depending on the security requirements of
   the services:

   o  OSCORE [RFC8613] security association can be established based on
      the cryptographic material generated from the EAP authentication.

   o  A DTLS security association can be established using the exported
      cryptographic material after a successful EAP authentication.

   This document also indicates how to establish a security association
   for other types of technologies that rely on CoAP.

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

2.  General Architecture

   Figure 1 shows the architecture defined in this document.  Basically,
   a node acting as the EAP peer wants to be authenticated by using EAP.
   At the time of writing this document, we have considered a model
   where the entity acting as EAP peer will also act as a CoAP server
   for this service and the entity acting as EAP authenticator will act
   as a CoAP client and MAY interact with a backend AAA infrastructure,



Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 3]


Internet-Draft                  CoAP-EAP                        May 2021


   which will place the EAP server and contain the information required
   to authenticate the CoAP client.  The rationale behind this decision,
   as we will expand later, is that EAP requests go always from the EAP
   authenticator to the EAP peer.  Accordingly, the EAP responses go
   from the EAP peer to the EAP authenticator.

                   +------------+        +------------+
                   | EAP peer/  |        | EAP auth./ |
                   | CoAP server|+------+| CoAP client|
                   +------------+  CoAP  +------------+


                      Figure 1: CoAP EAP Architecture

3.  General Flow Operation

   The authentication service uses CoAP as transport for EAP.  In other
   words, CoAP becomes an EAP lower layer in EAP terminology.  In
   general, it is assumed that, since the EAP authenticator MAY
   implement an AAA client to interact with the AAA infrastructure, this
   endpoint will have more resources or, at least, will not be so
   constrained device.  We show the sequence flow in Figure 2 where we
   depict the usage of a generic EAP method that we call EAP-X as an
   authentication mechanism.  (NOTE: any EAP method that can export
   cryptographic material is valid.  For example, EAP-MD5 cannot be used
   since it does not export key material).

   The first step to run CoAP-EAP is for the IoT device to discover the
   Controller, and that it implements the CoAP-EAP service.  To do so,
   we rely on the discovery mechanism of CoAP.  The URI of the CoAP-EAP
   service is set to "/b" to save bytes over the air.  Alternatively, if
   the Controller is aware of the presence of the IoT device (e.g., due
   to a previous authentication) this process can be avoided, and the
   Controller can directly start the authentication process.

   The first message is used to trigger the authentication process.
   This message is sent by the IoT device, acting as a CoAP client.
   This message uses the No-Response Option [RFC7967] to avoid the
   response from the Controller to this message.  After this, the
   exchange continues with the Controller acting as a CoAP client and
   the IoT device acting as a CoAP server.  This is because the IoT
   device could be a constrained node, and following the recommendations
   of [I-D.ietf-lwig-coap] to simplify the implementation of the IoT
   device, the Controller takes the responsibility of handling the
   retransmissions.  In the next section, we refer to the IoT device as
   the EAP peer and the Controller as the EAP authenticator to elaborate
   the specifics of the flow of operation.




Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 4]


Internet-Draft                  CoAP-EAP                        May 2021


3.1.  EAP over CoAP flow of operation

   If the EAP peer discovers the presence of the EAP authenticator and
   wants to start the authentication, it can send a Non-Confirmable
   "POST /b" request to the node (Step 0).  This message will carry an
   option developed in the work of [RFC7967] called 'No-Response'.  The
   rationale of this option is to avoid waiting for a response if it is
   not needed.  So the use of this option will allow signalling the
   intention the EAP peer to start the authentication process.
   Immediately after that, the EAP authenticator will start
   authentication service.  It is worth noting that the EAP
   authenticator MAY decide to start the authentication without waiting
   for the trigger if it knows about the presence of the peer.  For
   instance, through a previous authentication.

   In any case, to perform the authentication service, the CoAP client
   (EAP authenticator) sends a Confirmable "POST /b" request to the CoAP
   Server (Step 1).  After receiving the first POST, the CoAP server
   assigns a resource and answers with an Acknowledgment with the piggy-
   backed response containing the resource identifier (Location-Path)
   (Step 2).  The name of the resource MAY be represented following the
   naming "/b/x".  Where "b" is the general name of the bootstrapping
   service; "x" represents the resource established to process the
   following message of the authentication.  This CoAP server can select
   this value as pleased, as long as, it serves to process the following
   message adequately.  It is assumed that the CoAP server will only
   have an ongoing authentication with that particular CoAP client and
   will not process simultaneous EAP authentications in parallel (with
   the same EAP authenticator) to save resources.

   In this exchange (Step 1 and 2), the EAP Req/Id and Rep/Id messages
   are exchanged between the EAP authenticator and the EAP peer.  Upon
   the reception of the EAP Req/Id message, the EAP authenticator
   forwards this message, when EAP is in pass-through mode, to the local
   AAA server.  The AAA server is in charge of steering the
   conversation, choosing the EAP method to be used (e.g.  EAP-X) if the
   user is local, or sending the EAP messages to the home AAA of the EAP
   peer.  At this point, the CoAP server has created a resource for the
   EAP authentication.  The resource identifier value will be used to
   relate the EAP conversation between both CoAP endpoints.

   NOTE: Since only an ongoing EAP authentication is permitted per EAP
   authenticator/EAP client, and EAP is a lock-step protocol, a Token of
   a constant value can be used throughout the authentication process.
   An empty Token could be considered to reduce bytes.

   From now on, the EAP authenticator and the EAP peer will exchange EAP
   packets related to the EAP method, transported in the CoAP message



Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 5]


Internet-Draft                  CoAP-EAP                        May 2021


   payload (Steps 3,4,5,6).  The EAP authenticator will use the POST
   method to send EAP requests to the EAP peer.  The EAP peer will use a
   Piggy-backed response in the Acknowledgment message to carry the EAP
   response.  When all the message exchange is completed, if everything
   has gone well, the EAP authenticator can send an EAP Success message,
   and both CoAP endpoints will share a Master Session Key (MSK)
   ([RFC5295])

   To establish a security association that will confirm to the EAP peer
   that EAP authenticator received the MSK from the AAA server, as well
   as to the EAP authenticator that the EAP peer derived the MSK
   correctly, both entities engage in the establishment of a security
   association.  In the context of constrained devices [RFC7228] and
   networks, we consider protocols that are designed for these cases.
   Concretely, we show here in the diagram the establishment of the
   OSCORE security association (Steps 7 and 8).  From that point, any
   exchange between both CoAP endpoints is protected with OSCORE.
   Before sending the EAP success to the EAP peer, the EAP authenticator
   can derive the OSCORE Security Context, to confirm the establishment
   of the security association.  The details of the establishment of the
   OSCORE Security Context are discussed in Section Section 4.1.  The
   protection of the EAP Success is not a requirement.  Here, we specify
   this exchange as protected by the lower layer with OSCORE.  The
   purpose is double, we can avoid forgery of this message and we are
   using the exchange to perform the key confirmation through the
   establishment of the OSCORE security association.  Adding to the
   previous consideration about the EAP Success, this message does not
   prevent the operation of the device from continuing as long as there
   is an alternate success indication that both the EAP peer and
   authentication can rely on to continue [RFC3748].  This indication
   can happen in two ways: 1) the reception of the CoAP message without
   EAP and with an OSCORE option (following the normal operational
   communication between both entities) is an indication that the
   controller considers the EAP authentication finished. 2) the IoT
   device knows that the EAP authentication went well if an MSK is
   available.  Both entities need to prove the possession of the MSK as
   mentioned in the EAP KMF.

         EAP peer                                  EAP Auth.
         (CoAP server)                             (CoAP client)
         -------------                             -------------
              |                                         |
              | NON [0x6af5] POST /b                    |
              | Token (0xab)                            |
           0) | No-Response                             |
              |---------------------------------------->|
              |                                         |
              |                    CON [0x7654] POST /b |



Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 6]


Internet-Draft                  CoAP-EAP                        May 2021


              |                            Token (0xac) |
              |                      Payload EAP Req/Id |
           1) |<----------------------------------------|
              |                                         |
              | ACK [0x7654]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/x]       |
              | Payload EAP Rep/Id                      |
           2) |---------------------------------------->|
              |                                         |
              |                CON [0x8694] POST /b/x   |
              |                            Token (0xac) |
              |                     Payload EAP-X MSG 1 |
           3) |<----------------------------------------|
              |                                         |
              | ACK [0x8694]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/y]       |
              | Payload EAP-X MSG 2                     |
           4) |---------------------------------------->|
                                 ....
              |                CON [0x9869] POST /b/y   |
              |                            Token (0xac) |
              |                 Payload EAP-X MSG (n-1) |
           5) |<----------------------------------------|
              |                                         |
              | ACK [0x9869]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/z]       |
              | Payload EAP-X MSG (n)                   |  MSK
           6) |---------------------------------------->|   |
              |                                         |   V
              |                CON [0x7811] POST /b/z   |OSCORE
              |                          Token (0xac)   |CONTEXT
              |                         OSCORE Option   | (*)
              |                   Payload EAP success   |
    MSK    7) |<----------------------------------------|
     |        |                                         |
     V    (*) | ACK [0x7811]                            |
   OSCORE     | Token (0xac)                            |
   CONTEXT    | OSCORE Option                           |
           8) |---------------------------------------->|
              (*) Protected with OSCORE



                   Figure 2: CoAP-EAP flow of operation




Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 7]


Internet-Draft                  CoAP-EAP                        May 2021


3.2.  Message processing of EAP over CoAP

   In this section, we introduce how the service is processed by the two
   entities involved in the exchange.

   For the CoAP server, each time a new CoAP request arrives, containing
   the EAP message as payload, does the following:

   1.  Send the EAP message to the EAP state machine

   2.  If the EAP state machine processes the request correctly:

       A.  A new resource is created. (e.g. b/y)

       B.  The current resource is deleted. (e.g. b/x)

       C.  A response is sent back to the client specifying the new
           resource

   3.  If the EAP state machine returns an error:

       A.  The CoAP service will send an error message. (e.g: 4.00 Bad
           Request)

   When the EAP authenticator (CoAP client) receives an EAP message from
   the EAP peer (CoAP server), it will send it to the EAP server, and
   vice-versa.  In any case, the EAP exchange is initiated by the EAP
   authenticator, sending the EAP Request/Identity message to the EAP
   peer and the ongoing authentication will be tracked by a
   bootstrapping state where all the relevant information for the
   application is stored, such as the current URI for the exchange (or
   the expected URI for the next exchange).  From that point on, the
   processing of the messages continues as follows:

   1.  If the ongoing message is an EAP request, is sent to the EAP
       peer.  If it is an EAP response, it is sent to the EAP server.

   2.  If a CoAP response containing the new resource and the EAP
       response arrives, the new CoAP resource is updated.

   3.  If an error arrives, the CoAP client will rely on CoAP
       retransmission behavior.

3.3.  EAP over CoAP operation casuistics

   In this section, we introduce a couple of cases where a message is
   lost and retransmitted later, to show how the service will react.
   The first one shows what would happen if a piggybacked response with



Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 8]


Internet-Draft                  CoAP-EAP                        May 2021


   a new resource identifier is lost.  This case is illustrated in
   Figure 3.  The second shows what would happen if an old request
   message arrives even though the process of authentication continued
   due to normal retransmission behaviour.  This is illustrated in
   Figure 4.

   For the first case, when a piggybacked response message containing
   the Location-Path of the new resource is lost, the CoAP client will
   retransmit.  This will cause the CoAP server to recognize the message
   as retransmission due to the MSG-ID, and re-send the lost message.

         EAP peer                                  EAP Auth.
         (CoAP server)                             (CoAP client)
         -------------                             -------------
              |                                         |
              | NON [0x6af5] POST /b                    |
              | Token (0xab)                            |
           0) | No-Response                             |
              |---------------------------------------->|
              |                                         |
              |                    CON [0x7654] POST /b |
              |                            Token (0xac) |
              |                      Payload EAP Req/Id |
           1) |<----------------------------------------|
              |                                         |
              | ACK [0x7654]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/x]       |
              | Payload EAP Rep/Id                      |
           2) |---------------------------->X           |
              |                                         |
              |                    CON [0x7654] POST /b |
              |                            Token (0xac) |
              |                      Payload EAP Req/Id |
           1) |<----------------------------------------|
              |                                         |
              | ACK [0x7654]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/x]       |
              | Payload EAP Rep/Id                      |
           2) |---------------------------------------->|


                    Figure 3: Casuistic - Response Lost

   In the second case, when a message is lost, but due to the ongoing
   workings of CoAP retransmission, the flow of operation continues as




Marin-Lopez & Garcia-CarExpires November 28, 2021               [Page 9]


Internet-Draft                  CoAP-EAP                        May 2021


   expected.  If said lost message arrives later, how this message is
   handled will depend on which layer deals with it.

   1.  If the message is handled by the CoAP messaging layer, which
       means it will not go up to the service application:

       A.  As the server recognizes the old message, due to internal
           tracking, it can send a stored copy of the response.

       B.  Then the client would recognize the MSGID as old and that he
           got the response already, and simply dropping it.

   2.  If the messaging layer does not recognize the message as old, and
       takes care of it, it will try to send it to the service
       application:

       A.  This will cause an error, since a resource of a previous step
           of the authentication is deleted

       B.  The error code (e.g., 4.04 Not Found) with the same MSGID is
           sent back to the CoAP client.

       C.  The CoAP client would recognize the MSGID as old and simply
           drop it.



























Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 10]


Internet-Draft                  CoAP-EAP                        May 2021


        EAP peer                                  EAP Auth.
         (CoAP server)                             (CoAP client)
         -------------                             -------------
              |                                         |
              | NON [0x6af5] POST /b                    |
              | Token (0xab)                            |
           0) | No-Response                             |
              |---------------------------------------->|
              |                                         |
              |                    CON [0x7654] POST /b |
              |                            Token (0xac) |
              |                      Payload EAP Req/Id |
           1) |<----------------------------------------|
              |                                         |
              | ACK [0x7654]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/x]       |
              | Payload EAP Rep/Id                      |
           2) |---------------------------------------->|
              |                                         |
              |                CON [0x8694] POST /b/x   |
              |                            Token (0xac) |
              |                     Payload EAP-X MSG 1 |
           3) |<----------------------------------------|
              |                                         |
              | ACK [0x8694]                            |
              | Token (0xac)                            |
              | 2.01 Created Location-Path [/b/y]       |
              | Payload EAP-X MSG 2                     |
           4) |---------------------------------------->|
              |                                         |
              |                    CON [0x7654] POST /b |
              |                            Token (0xac) |
              |                      Payload EAP Req/Id |(Old message)
           1) |<----------------------------------------|

                     Figure 4: Casuistic - Old message

4.  Key Derivation for protecting CoAP messages

   As a result of a successful EAP authentication, both the CoAP server
   and CoAP client share a Master Key Session (MSK).  The assumption is
   that MSK is a fresh key, so any key derived from the MSK will be also
   fresh.  To complete the CoAP-EAP exchange, as part of the design, it
   is expected the establishment of an OSCORE security association
   specifically for the CoAP-EAP service.  The security level for the
   CoAP-EAP exchanges with OSCORE is with integrity.  Additionally, we
   considered the derivation of either the OSCORE Security Context or a



Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 11]


Internet-Draft                  CoAP-EAP                        May 2021


   pre-shared key that can be used for a DTLS negotiation (DTLS_PSK) for
   further communications depending on the security requirements of the
   services provided by the AS.  The OSCORE security context generated
   for CoAP-EAP could be generalized to enable further OSCORE secured
   communications between the IoT device and the AS services that
   require the use of OSCORE.

4.1.  Deriving the OSCORE Security Context

   Key material needed to derive the OSCORE Security Context, from the
   MSK can be done as follows:

   The Master Secret can be derived by using AES-CMAC-PRF-128 [RFC4615],
   which, in turn, uses AES-CMAC-128 [RFC4493].  The Master Secret can
   be derived as follows:

   Master_Secret = KDF(MSK, "IETF_OSCORE_MASTER_SECRET", 64, length)

   where:

   o  The AES-CMAC-PRF-128 is defined in [RFC4615].  This function uses
      AES-CMAC-128 as a building block.

   o  The MSK exported by the EAP method, which by design is a fresh key
      material.  Discussions about the use of the MSK for the key
      derivation are done in Section Section 7.

   o  "IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of
      the non-NULL terminated string (excluding the double quotes around
      it).

   o  64 is the length of the MSK.

   o  length is the length of the label "IETF_OSCORE_MASTER_SECRET" (25
      bytes).

   The Master Salt, similarly to the Master Secret, can be derived as
   follows:

   Master_Salt = KDF(MSK, "IETF_OSCORE_MASTER_SALT", 64, length)

   where:

   o  The AES-CMAC-PRF-128 is defined in [RFC4615].  This function uses
      AES-CMAC-128 as a building block.






Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 12]


Internet-Draft                  CoAP-EAP                        May 2021


   o  The MSK exported by the EAP method, which by design is a fresh key
      material.  Discussions about the use of the MSK for the key
      derivation are done in Section Section 7.

   o  "IETF_OSCORE_MASTER_SALT" is the ASCII code representation of the
      non-NULL terminated string (excluding the double quotes around
      it).

   o  64 is the length of the MSK.

   o  length is the length of the label "IETF_OSCORE_MASTER_SALT" (23
      bytes).

   The ID Context can be set to the identity of the EAP peer.

4.2.  Deriving DTLS_PSK

   In the second alternative, a DTLS_PSK is derived from the MSK between
   both CoAP endpoints.  The length of the DTLS_PSK will depend on the
   cipher-suite.  For AES-128, the DTLS_PSK will have a 16-byte length
   and it will be derived as follows:

   DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" , 64, length).  This value is
   concatenated with the value of the Token Option value.

   where:

   o  MSK is exported by the EAP method.

   o  "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL
      terminated string (excluding the double quotes around it).

   o  64 is the length of the MSK.

   o  length is the length of the label "IETF_DTLS_PSK" (13 bytes).

5.  Examples of Use Case Scenario

   For a device to act as a trustworthy entity within a security domain,
   certain key material is needed to be shared between the IoT device
   and AS.  In ACE, the process of Client registration and provisioning
   of credentials to the client is not specified.  The process of Client
   registration and provisioning can be achieved by using CoAP-EAP.
   Once the process of authentication with EAP is completed, a fresh key
   material is shared between the IoT device and the AS.

   Next, we elaborate on examples of different use case scenarios about
   the usage of CoAP-EAP.  Generally, we are dealing with 4 entities:



Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 13]


Internet-Draft                  CoAP-EAP                        May 2021


   o  2 nodes (A and B), which are constrained devices.  They are the
      EAP peers.

   o  1 controller (C).  The controller manages a domain where nodes can
      be deployed.  It can be considered a more powerful machine than
      the nodes.  In this scenario, the Controller (and EAP
      Authenticator), can be co-located with the AS.

   o  1 AAA server (AAA) - Optional.  The AAA is an Authentication,
      Authorization and Accounting Server, which is not constrained.

   Generally, any node wanting to join the domain managed by the
   controller MUST perform a CoAP-EAP authentication with the controller
   C.  This authentication MAY involve an external AAA server.  This
   means that A and B, once deployed, will perform this CoAP-EAP once as
   a bootstrapping phase to establish a security association with
   controller C.  Moreover, any other entity, which wants to join and
   establish communications with nodes under controller C's domain must
   also do the same.  By using EAP, we can have the flexibility of
   having different types of credentials.  For instance, if we have a
   device that is not battery dependent, and not very constrained, we
   could use a heavier authentication method.  With very constrained
   devices and networks we might need to resort to more lightweight
   authentication methods (e.g., EAP-PSK, EAP-EDHOC, etc.) being able to
   adapt to different types of devices according to policies or devices
   capabilities.

5.1.  Example 1: CoAP-EAP in ACE

   Next, we exemplify how CoAP-EAP can be used to perform the Client
   registration in a general way, to allow two IoT devices (A and B) to
   communicate and interact after a successful client registration.

   Node A wants to communicate with node B (e.g. to activate a light
   switch).  The overall process is divided into three phases.  Let's
   start with node A.  In the first phase, the node A (EAP peer) does
   not yet belong to controller C's domain.  Then, it communicates with
   controller C (EAP authenticator) and authenticates with CoAP-EAP,
   which, optionally, communicates with the AAA server to complete the
   authentication process.  If the authentication is successful, key
   material is distributed to controller C and derived by node A.  This
   key material allows node A to establish a security association with
   the controller (C).  Some authorization information may be also
   provided in this step.  If authentication and authorization are
   correct, node A is enrolled in controller C's domain for a period of
   time.  In particular, [RFC5247] recommends 8 hours, though the AAA
   server can establish this lifetime.  In the same manner, B needs to




Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 14]


Internet-Draft                  CoAP-EAP                        May 2021


   perform the same process with CoAP-EAP to be part of the controller
   C's domain.

   In the second phase, when node A wants to talk with node B, it
   contacts controller C for authorization to access node B and obtain
   all the required information to do that securely (e.g. keys, tokens,
   authorization information, etc.).  This phase does NOT require the
   usage of CoAP-EAP.  The details of this phase are out of the scope of
   this document, and the ACE framework is used for this purpose
   [I-D.ietf-ace-oauth-authz].

   In the third phase, the node A can access node B with the credentials
   and information obtained from the controller C in the second phase.
   This access can be repeated without contacting the controller, while
   the credentials given to A are still valid.  The details of this
   phase are out of scope of this document.

   It is worth noting that first phase with CoAP-EAP is ONLY required to
   join the controller C's domain.  Once it is performed with success,
   the communications are local to the controller C's domain so there is
   no need to contact the external AAA server nor performing EAP
   authentication.

5.2.  Example 2: Multi-domain with AAA infrastructures

   We assume we have a device (A) of the domain acme.org, which uses a
   specific kind of credential (e.g., AKA) and intends to join the um.es
   domain.  This user does not belong to this domain, for which first it
   performs a client registration using CoAP-EAP.  For this, it
   interacts with the Domain Controller acting as EAP authenticator,
   which in turn communicates with a AAA infrastructure (acting as AAA
   client).  Through the local AAA server to communicate with the home
   AAA server to complete the authentication and integrate the device as
   a trustworthy entity into the domain of controller C.  In this
   scenario, the AS under the role of the Controller receives the key
   material from the AAA infrastructure

5.3.  Example 3: Single domain with AAA infrastructure

   A University Campus, we have several Faculty buildings and each one
   has its own criteria or policies in place to manage IoT devices under
   an AS.  All buildings belong to the same domain (e.g., um.es).  All
   these buildings are managed with a AAA infrastructure.  A new device
   (A) with credentials from the domain (e.g., um.es) will be able to
   perform the device registration with a Controller (C) of any building
   as long as they are managed by the same general domain.





Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 15]


Internet-Draft                  CoAP-EAP                        May 2021


5.4.  Example 4: Single domain without AAA infrastructure

   In another case, without a AAA infrastructure, we have a Controller
   that has co-located the EAP server and using EAP standalone mode we
   can manage all the devices within the same domain locally.  Client
   registration of a node (A) with Controller (C) can also be performed
   in the same manner, transparent to the IoT device.  In this scenario,
   the communication with a AAA server is not used, nevertheless, we
   have the capacity of adapting to more complex scenarios such as the
   ones previously described.

5.5.  Other use cases

5.5.1.  CoAP-EAP for network access control

   One of the first steps for an IoT device life-cycle is to perform the
   authentication to gain access to the network.  To do so, the device
   first has to be authenticated and granted authorization to gain
   access to the network.  Additionally, security parameters such as
   credentials can be derived from the authentication process allowing
   the trustworthy operation of the IoT device in a particular network
   by joining the security domain.  By using EAP, we are able to achieve
   this with flexibility and scalability, because of the different EAP
   methods available and the ability to rely on AAA infrastructures if
   needed to support multi-domain scenarios, which is a key feature when
   the IoT devices deployed under the same security domain, belong to
   different organizations.  Given that EAP is also used for network
   access control, we can adapt this service for other technologies.
   For instance, to provide network access control to very constrained
   technologies (e.g., LoRa network).  In this specific case, we could
   leverage the compression by SCHC for CoAP.

5.5.2.  CoAP-EAP for service authentication

   It is not uncommon that the infrastructure where the device is
   deployed and the services of the IoT device are managed by different
   organizations.  Therefore, in addition to the authentication for
   network access control, we have to consider the possibility of a
   secondary authentication to access different services.  This process
   of authentication, for example, will provide with the necessary key
   material to establish a secure channel and interact with the entity
   in charge of granting access to different services.

6.  Discussion







Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 16]


Internet-Draft                  CoAP-EAP                        May 2021


6.1.  CoAP as EAP lower layer

   In this section, we discuss the suitability of the CoAP protocol as
   EAP lower layer, and review the requisites imposed by the EAP
   protocol to any protocol that transports EAP.  The assumptions EAP
   makes about its lower layers can be found in section 3.1 of
   [RFC3748], which are enumerated next:

   o  Unreliable transport.  EAP does not assume that lower layers are
      reliable.

   o  Lower layer error detection.  EAP relies on lower layer error
      detection (e.g., CRC, Checksum, MIC, etc.)

   o  Lower layer security.  EAP does not require security services from
      the lower layers.

   o  Minimum MTU.  Lower layers need to provide an EAP MTU size of 1020
      octets or greater.

   o  Possible duplication.  EAP stipulates that, while desirable, it
      does not require for the lower layers to provide non-duplication.

   o  Ordering guarantees.  EAP relies on lower layer ordering
      guarantees for correct operation.

   Regarding unreliable transport, although EAP assumes a non-reliable
   transport, CoAP does provide a reliability mechanism through the use
   of Confirmable messages.  For the error detection, CoAP goes on top
   of UDP which provides a checksum mechanism over its payload.  Lower
   layer security services are not required.  About the minimum MTU of
   1020 octets, CoAP assumes an upper bound of 1024 for its payload
   which covers the requirements of EAP.  Regarding message ordering,
   every time a new message arrives at the bootstrapping service hosted
   by the IoT device, a new resource is created and this is indicated in
   a 2.01 Created response code along with the name of the new resource
   via Location-Path or Location-Query.  This way the application
   indicates that its state has advanced.  The name of the resource MAY
   be represented following the naming "/b/x".  Where "b" is the general
   name of the bootstrapping service; "x" represents the resource
   established to refer to the ongoing authentication exchange.

   NOTE: This document does not assume any specific naming schema.  The
   only requisite that both CoAP client and server MUST agree, is the
   establishment of a nomenclature indicates that the next URI used to
   refer to a resource, univocally points to the next expected EAP
   exchange.




Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 17]


Internet-Draft                  CoAP-EAP                        May 2021


   Regarding the Token, we consider the use of a constant value.  This
   is because the EAP server will not send a new EAP request until it
   has processed the expected EAP response.  Additionally, we are under
   the assumption that there will a single EAP authentication between
   the constrained device and the same Controller.  This would also
   enable the possibility of using an Empty Token to reduce the number
   of bytes.

   As we can see, CoAP can fulfil the requirements of EAP to be
   considered suitable as lower layer.

6.2.  Size of the EAP lower layer vs EAP method size

   Regarding the impact an EAP lower layer will have to the total byte
   size of the whole exchange, there is a comparison with another
   network layer based EAP lower layer, PANA [RFC5191] in [coap-eap].
   Authors compared focusing EAP lower layer (alone) and taking into
   account EAP.  On the one hand, at the EAP lower layer level, the
   usage of CoAP gives important benefits.  On the other hand, when
   taking into account the EAP method overload, this reduction is less
   but still significant if the EAP method is lightweight (we used EAP-
   PSK as a representative example of a lightweight EAP method).  If the
   EAP method is very taxing the improvement achieved in the EAP lower
   layer is less significant.  This leads to the conclusion that
   possible next steps in this field could be also improving or
   designing new EAP methods that can be better adapted to the
   requirements of constrained devices and networks.  However, we cannot
   ignore the impact of the EAP lower layer itself and try to propose
   something lightweight as CoAP.  We consider that may be other EAP
   methods such as EAP-AKA or new lightweight EAP methods such as EAP-
   EDHOC [I-D.ingles-eap-edhoc] that can benefit from a CoAP-based EAP
   lower layer, as well as new ones that may be proposed in the future
   with IoT constraints in mind.

6.3.  Controller as the CoAP Client

   Due to the constrained capacities of the devices, to relieve them of
   the retransmission tasks, we set the Controller as the CoAP client,
   for the main exchange following the recommendations of the
   [I-D.ietf-lwig-coap] document to simplify the constrained device
   implementation.

6.4.  Possible Optimizations








Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 18]


Internet-Draft                  CoAP-EAP                        May 2021


6.4.1.  Empty Token

   Assuming that the bootstrapping service runs before any other
   service, and that no other service will run concurrently until it has
   finished, we could use an Empty Token value to save resources, since
   there will be no other endpoint or CoAP exchange.

6.4.2.  Further re-authentication

   Since the initial bootstrapping is usually taxing, it is assumed to
   be done only once over a long period of time.  If further re-
   authentications for refreshing the key material are necessary, there
   are other methods that can be used to perform these re-
   authentications.  For example, the EAP re-authentication (ERP)
   [RFC6696] can be used to avoid repeating the entire EAP exchange in
   few exchanges.

7.  Security Considerations

   There are some aspects to be considered such as how authorization is
   managed, how the cryptographic suite is selected and how the trust in
   the Controller is established.

7.1.  Authorization

   Authorization is part of bootstrapping.  It serves to establish
   whether the node can join and the set of conditions it has to adhere.
   The authorization data received from the AAA server can be delivered
   by the AAA protocol (e.g.  Diameter).  Providing more fine-grained
   authorization data can be with the transport of SAML in RADIUS
   [RFC7833].  After bootstrapping, additional authorization to operate
   in the security domain, e.g., access services offered by other nodes,
   can be taken care of by the solutions proposed in the ACE WG.

7.2.  Cryptographic suite selection

   How the cryptographic suite is selected is also important.  To reduce
   the overhead of the protocol we use a default cryptographic suite.
   As OSCORE is assumed to run after the EAP authentication, the same
   default crypto-suite is used in this case as explained in the Key
   Derivation Section Section 4 The cryptographic suite is not
   negotiated.  If the cryptographic suite to be used by the node is
   different from the default, the AAA server will send the specific
   parameters to the Authenticator.  If the cryptographic suite is not
   supported, the key derivation process would result in a security
   association failure.





Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 19]


Internet-Draft                  CoAP-EAP                        May 2021


7.3.  Freshness of the key material

   In this design, we do not exchange nonces to provide freshness to the
   keys derived from the MSK.  This is done under the assumption that
   the MSK and EMSK keys derived following the EAP KMF [RFC5247] are
   fresh key material by the specifications of the EAP KMF.  Since only
   one session key is derived from the MSK we do not have to concern
   ourselves with the generation of additional key material.  In case
   another session has to be established, a re-authentication can be
   done, by running the process again, or using a more lightweight EAP
   method to derive additional key material such as ERP [RFC6696].

7.4.  Additional Security Consideration

   Other security-related concerns can be how to ensure that the node
   joining the security domain can in fact trust the Controller.  This
   issue is elaborated in the EAP KMF [RFC5247].  To summarizing, the
   node knows it can trust the Controller because the key that is used
   to establish the security association is derived from the MSK.  If
   the Controller has the MSK, it is clear the AAA Server of the node
   trusts the Controller, which confirms it is a trusted party.

8.  IANA Considerations

   TBD.

9.  Acknowledgments

   We would like to thank as the reviewers of this work: Carsten
   Bormann, Benjamin Kaduk, Alexandre Petrescu, Pedro Moreno-Sanchez and
   Eduardo Ingles-Sanchez.

   We would also like to thank Gabriel Lopez-Millan for the first review
   of this document and we would like to thank Ivan Jimenez-Sanchez for
   the first proof-of-concept implementation of this idea.

   And thank for their valuables comments to Alexander Pelov and Laurent
   Toutain, especially for the potential optimizations of CoAP-EAP.

10.  References

10.1.  Normative References









Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 20]


Internet-Draft                  CoAP-EAP                        May 2021


   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE) using the OAuth 2.0
              Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36
              (work in progress), November 2020.

   [I-D.ietf-lwig-coap]
              Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP
              Implementation Guidance", draft-ietf-lwig-coap-06 (work in
              progress), July 2018.

   [I-D.ingles-eap-edhoc]
              Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP
              method based on EDHOC Authentication", draft-ingles-eap-
              edhoc-01 (work in progress), November 2020.

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

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
              2006, <https://www.rfc-editor.org/info/rfc4493>.

   [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol
              (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006,
              <https://www.rfc-editor.org/info/rfc4615>.

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <https://www.rfc-editor.org/info/rfc5191>.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, DOI 10.17487/RFC5247, August 2008,
              <https://www.rfc-editor.org/info/rfc5247>.




Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 21]


Internet-Draft                  CoAP-EAP                        May 2021


   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              DOI 10.17487/RFC5295, August 2008,
              <https://www.rfc-editor.org/info/rfc5295>.

   [RFC6696]  Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
              "EAP Extensions for the EAP Re-authentication Protocol
              (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
              <https://www.rfc-editor.org/info/rfc6696>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

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

   [RFC7833]  Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
              RADIUS Attribute, Binding, Profiles, Name Identifier
              Format, and Confirmation Methods for the Security
              Assertion Markup Language (SAML)", RFC 7833,
              DOI 10.17487/RFC7833, May 2016,
              <https://www.rfc-editor.org/info/rfc7833>.

   [RFC7967]  Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
              Bose, "Constrained Application Protocol (CoAP) Option for
              No Server Response", RFC 7967, DOI 10.17487/RFC7967,
              August 2016, <https://www.rfc-editor.org/info/rfc7967>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

10.2.  Informative References

   [coap-eap]
              Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP-
              Based Bootstrapping Service for the Internet of Things -
              https://www.mdpi.com/1424-8220/16/3/358", March 2016.







Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 22]


Internet-Draft                  CoAP-EAP                        May 2021


Authors' Addresses

   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 01
   Email: rafa@um.es


   Dan Garcia-Carrillo
   University of Oviedo
   Calle Luis Ortiz Berrocal S/N, Edificio Polivalente
   Gijon, Asturias  33203
   Spain

   Email: garciadan@uniovi.es
































Marin-Lopez & Garcia-CarExpires November 28, 2021              [Page 23]