ACE Working Group R. Marin Internet-DraftD. Garcia Intended status: ExperimentalUniversity of Murcia Intended status: Standards Track D. Garcia Expires:April 27, 2018 October 24, 2017July 25, 2021 University of Oviedo January 21, 2021 EAP-based Authentication Service for CoAPdraft-marin-ace-wg-coap-eap-06draft-marin-ace-wg-coap-eap-07 Abstract This document describes an authentication service that uses EAP transported by means of CoAP messages withtwothe following purposes: o Authenticatetwo CoAP endpoints.a CoAP-enabled device that enters a new security domain against a AAA infrastructure through a domain Controller. o Bootstrap key material to protect CoAP messages exchanged between them. o Enable the establishment of Security Associations between them. 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 onApril 27, 2018.July 25, 2021. Copyright Notice Copyright (c)20172021 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. General Architecture . . . . . . . . . . . . . . . . . . . . 3 3. General Flow Operation . . . . . . . . . . . . . . . . . . .34 3.1. EAPin CoAP with AUTH optionover CoAP: Running an OSCORE Security Association . . 4 3.2. The SeqNum Option . . . . . . . . . . . .4 3.2. CoAP-EAP with DTLS. . . . . . . . 7 4. Key Derivation for protecting CoAP messages . . . . . . . . . 8 4.1. Deriving the OSCORE Security Context . . . . . . . . . . 8 5. Use Case Scenario . . . . .7 3.3. CoAP as EAP lower-layer. . . . . . . . . . . . . . . . . 103.4. Optimization Considerations6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 114. Key Derivation for protecting6.1. CoAPmessagesas EAP lower-layer . . . . . . . . .11 4.1. Deriving COAP_PSK. . . . . . . . 11 6.2. Size of the EAP lower-layer vs EAP method size . . . . . 12 6.3. Controller as the CoAP Client . . . . . . .11 4.2. Deriving DTLS_PSK. . . . . . . 12 6.4. Possible Optimizations . . . . . . . . . . . . . . . . . 125. Generating AUTH option6.4.1. Empty Token . . . . . . . . . . . . . . . . . . . . . 136. Implementation6.4.2. Removing SeqNum Option . . . . . . . . . . . . . . . 13 6.4.3. Further re-authentication . . . . . . . . . . . . . . 14 7.Future Work: CoAP IntermediariesSecurity Considerations . . . . . . . . . . . . . .15 8. Use Case Scenario. . . . . 14 7.1. Authorization . . . . . . . . . . . . . . . . .16 9. Acknowledgments. . . . . 14 7.2. Cryptographic suite selection . . . . . . . . . . . . . . 14 7.3. Freshness of the key material . . . .17 10. Security Considerations. . . . . . . . . . 15 8. IANA Considerations . . . . . . . . .17 10.1. Authorization. . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . .18 10.2. Cryptographic suite selection. . . . . . . . . . . . .18 10.3. Additional Security Consiederation. 15 10. References . . . . . . . . . .18 11. IANA Considerations. . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . .18 12. References. . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . .18 12.1. Normative References. . . . 18 Appendix A. CoAP-EAP with DTLS . . . . . . . . . . . . . . . . . 1812.2. Informative ReferencesA.1. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 without the need of additional protocols to bootstrap a security association between them. In particular, the document describes how CoAP can be used as a constrained link-layer independent EAP lower-layer [RFC3748] to transport EAP between a CoAP server (EAP peer) and the CoAP client (EAP authenticator) using CoAP messages. The CoAP clientmayMAY 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. There are two approaches that we have considered in this document: o To definea new AUTH option that includes an authentication tag generated withhow the OSCORE security association can be established based on the cryptographic materialexported during angenerated from the EAP authentication.This new option is used to protect the integrity of the CoAP message that carries the AUTH option. (NOTE: Encryption will be considered in the future).o To establish a DTLS security association using the exported cryptographic material after a successful EAP authentication. [I-D.ohba-core-eap-based-bootstrapping] This document also provides some comments about implementation of a proof-of-concept of this preliminary idea 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 The 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 EAP peer will act as CoAP server for this service and the EAP authenticator will act as CoAP client andmayMAY interact with a backend AAAinfrastructure.infrastructure, 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 and the EAP peer and the EAP responses from the EAP peer to the EAP authenticator. Nevertheless, a model where the EAP peer act as CoAP client and the EAP authenticator as CoAP serverwillcan be also analyzed in the future. +------------+ +------------+ +--------------+ | EAP peer/ | | EAP auth./ | | EAP server/ | | CoAP server|+------+| CoAP client|+-----+| AAA server | +------------+ CoAP +------------+ AAA +--------------+ Figure 1: CoAP EAP Architecture 3. General Flow Operation The authentication service usestheCoAPprotocolas transport layer for EAP. In other words, CoAP becomes an EAP lower-layer (in EAP terminology). In general, it is assumed that, since the EAP authenticator mayneed toimplement an AAA client to interact with the AAA infrastructure, this endpoint will have moreresources.resources or, at least, it is not a so constrained device. We describe two different sequence flow. First, it is shown in Figure 2 where theAUTH optionOSCORE is used at the end of EAP authentication.SecondThe diagram(seein Figure3)5 shows the flow when DTLS is used to protect CoAP messages at the end of the EAP authentication. As an example, both diagrams show the usage ofthe EAP-PSKa generic EAP method[RFC4764]that we call EAP-X as authentication mechanism. (NOTE: any EAP method which is able to export cryptographic material should be valid). 3.1. EAPin CoAP with AUTH option Ifover CoAP: Running an OSCORE Security Association When the EAP peer discovers the presence of the EAP authenticator and wants to start the authentication, it can send a Non-Confirmable "POST/auth"/b" request to the node (Step 0). This message, will carry an option developed fromthisthe work on [RFC7967] called no response. The rationale ofthese optionsthis option isavoiding having to listento avoid waiting for a response if it is not needed. So the use of this option will allowus to signalsignaling the intention of theEAP-PeerEAP peer to start the authenticationprocess.process, as a trigger mechanism. Immediately after that, the EAP authenticator will start the authentication service. It is worth noting that the EAP authenticatormayMAY decide to start the authentication without waiting for the trigger message if it has knowledge about the presence of the EAP peer, for instance, through a"POST /auth" message.previous authentication (re-authentication). In any case, to perform the authentication service, the CoAP client (EAP authenticator) sends a Confirmable "POST/auth"/b" request to the CoAP Server (Step 1). This POST messageindicatescontains a new option SeqNum that holds a sequence number randomly chosen by the CoAP client. This SeqNum is used to provide ordered and reliable delivery of messages involved during the whole authentication. In general, when a CoAPserverrequest with EAP message is received, thecreation ofCoAP client considers aresource forvalid message if only if its sequence number is theEAP-based authentication service.expected value. The sequence number is monotonically incremented by 1 so that the CoAP server can know what it is the next expected sequence number. After receiving the first POST, the CoAP server assigns a resource and answers with an Acknowledgment with the piggy-backed resource identifier (Uri-Path) (Step 2). It is assumed that the CoAP server will only have an ongoing authentication and will not process simultaneous EAP authentications in parallel to save resources.Moreover if after a period of time (TBD) no furtherIn these two messages, the EAP Req/Id and Rep/ID are exchanged between the EAP authenticator and the EAP peer. The EAP Req/Id message isreceived fromforwarded by theCoAP client,EAP authenticator, when EAP is in pass-through mode, to theCoAPlocal AAA serverwill freethat is in charge of steering thecreated state. Inconversation, 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 thismoment,point, the CoAP server hasstartedcreated a resource for the EAPauthentication, whoseauthentication. The resource identifier value will be used togetherwith the Token option valueto relate all the EAP conversation between both CoAP endpoints. Since, only an ongoing EAP authentication is permitted and EAP is a lock-step protocol a Token of a constant value and 1 byte can be used throughout the authentication process. This also allows to save bytes through the link. From now on, the EAP authenticator and the EAP peer will exchange EAP packets related to the EAP method, transported in the CoAP message payload (Steps3,4,5,6,7,8,9).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 theAcknowledgementAcknowledgment message to carry the EAP response. At the end of the message exchanges, if everything has gone well, the EAP authenticator is able to send an EAP Success message and both CoAP endpoints will share a Master Session Key (MSK) ([RFC5295])If the new defined AUTH option is used, an authentication tag is generated withTo establish anew key named COAP_PSK, derived fromsecurity association that will confirm to theMSK. The Acknowledgment messageEAP peer that EAP authenticator received the MSK from theCoAP server will also include an AUTH option soAAA sever, as well as to the EAP authenticator that theCoAP client can verifyEAP 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 theCoAP server obtaineddiagram theMSK.establishment of the OSCORE security association. This is shown in Steps97 and10.8. From that point any exchange(for example, Steps 11 and 12)between both CoAP endpoints are protected with OSCORE. Before sending theAUTH option. Finally, the CoAP client MAY send a Confirmable DELETE requestEAP success toremove allthestate related withEAP peer, theauthentication service inEAP authenticator is able to derive theCoAP server (Steps 13 and 14). The CoAP server may decideOSCORE Security Context, toremoveconfirm thestate after periodestablishment oftime in case not receiving a DELETE request. This may be easier iftheEAP authenticator sends a session lifetime option (TBD) insecurity association. The details of theStep 9 (whereestablishment of theEAP Success is sent).OSCORE Security Context are discussed in Section 4.1 On the contrary, if DTLS is used (see Figure3),5), a DTLS_PSK is derived from the MSK. Moreover, exchanges between both CoAP endpoints are protected with DTLS from that point. EAP peer EAP Auth.(COAP(CoAP server)(COAP(CoAP client) ------------- ------------- | | | NON [0x6af5] | |No-Response (0x1A)POST /b |0)|(Token 0xFA5B45FF4723BB43)No-Response | 0) |POST /authToken (0xab) | |---------------------------------------->| | | | CON [0x7654] | |CON [0x73DE]POST /b | |(Token 0x78728FD4AC3190FF)SeqNum(x) | |POST /authToken (0xac) | | Payloadnonce_cEAP Req/Id | 1) |<----------------------------------------| | | | ACK[0x73DE][0x7654] | |(Token 0x78728FD4AC3190FF)SeqNum(x) | | Token (0xac) | | 2.01 Created | | Uri-Path[auth/5][/b/5] | | Payloadnonce_sEAP Rep/Id | 2) |---------------------------------------->| | | | CON[0x7654] | | (Token 0x78728FD4AC3190FF) | | Payload EAP Req/Id[0x8694] | | POST/auth/5 | 3) |<----------------------------------------| | | | ACK [0x7654] | | (Token 0x78728FD4AC3190FF) | | 2.04 Changed | | Payload EAP Res/Id/b/5 |4) |---------------------------------------->|| SeqNum(x+1) | |CON [0x7654] | | (Token 0x78728FD4AC3190FF)Token (0xac) | | PayloadEAP-PSKEAP-X MSG 1 || POST /auth/5 | 5)3) |<----------------------------------------| | | | ACK[0x7654][0x8694] | | Token (0xac) | |(Token 0x78728FD4AC3190FF)SeqNum(x+1) | | 2.04 Changed | | PayloadEAP-PSKEAP-X MSG 2 |6)4) |---------------------------------------->| .... | | | CON [0x9869] | |(Token 0x78728FD4AC3190FF)POST /b/5 | |Payload EAP-PSK MSG 3SeqNum(x+n/2)| | Token (0xac) |POST /auth/5|7)Payload EAP-X MSG (n-1) | 5) |<----------------------------------------| | | | ACK [0x9869] | |(Token 0x78728FD4AC3190FF)SeqNum(x+n/2) | | Token (0xac) | | 2.04 Changed | | PayloadEAP-PSKEAP-X MSG4(n) |8) |---------------------------------------->|MSK 6) |---------------------------------------->| | |MSK| V | CON [0x7811] || COAP_PSK| (Token 0x78728FD4AC3190FF) |COAP_PSK | AUTH option | | Payload EAP Success | (*)OSCORE | POST/auth/5 | 9) |<----------------------------------------| | | (*)/b/5 |ACK [0x7811] | | (Token 0x78728FD4AC3190FF)CONTEXT || AUTH optionSeqNum(x+n/2+1) | |2.04 Changed | 10) |---------------------------------------->| ............. | | | CON [0x7511] | | (Token 0x55566AF7464646BC)Token (0xac) | (*) |AUTH optionOSCORE Option | |GET /tempEAP success |11)MSK 7) |<----------------------------------------| | | |ACK [0x7511] | (*) | (Token 0x55566AF7464646BC) | | AUTH option | | 2.05 Content | | "22.5C" | 12) |---------------------------------------->| ................ | | | CON [0x7600] | | (Token 0x678443AA678BC690) |V (*) |AUTH option | | DELETE /auth/5 | 13) |<----------------------------------------|ACK [0x7811] | OSCORE | SeqNum(x+n/2+1) |ACK [0x7500]CONTEXT |(*) | (Token 0x678443AA678BC690)Token (0xac) | |AUTH optionOSCORE Option | |2.02 Deleted2.04 Changed |14)8) |---------------------------------------->| (*) Protected withAUTH optionOSCORE Figure 2: CoAP-EAP withAUTHOSCORE option 3.2.CoAP-EAP with DTLS Other possibility at our disposal is to do a DTLS handshake after the MSKs generation and continue the communication between endpoints using CoAP through DTLS as we can see at Figure 3.TheSteps 0-8 are the same as the case with AUTH option, however, before continuing with Steps 10 and 11, the EAP authenticator starts the DTLS handshake with the EAP peer (Step 9'). To establish a DTLS Security Association, a key named DTLS-PSKSeqNum Option A new SeqNum option isderived from MSK (see Section 4 ). Indefined in thiscase the CoAP client can start DTLS before sendingdocument for establishing thelast message containingordering guarantee of the EAPSuccess. Once DTLS is established, any posterior CoAP exchange is protected. Thus, new AUTHexchange. Following guidelines in [RFC7252] this optionis not needed. A successful DTLS negotiation confirmsis: 1. Format opaque (sequence of bytes). 2. Critical 3. Safe to Forward 4. No cacheable and Not part of thepossessionCache-Key 5. Not repeatable The number ofDTLS_PSK that, in turn, corroborates that both entities participated intheEAP authentication. EAP peer EAP Auth. (COAP server) (COAP client) ------------- ------------- | | | NON [0x6af5] | | No-Response (0x1A) | 0) | (Token 0xFA5B45FF4723BB43) | | POST /auth | |---------------------------------------->| | | | CON [0x73DE] | | (Token 0x78728FD4AC3190FF) | | POST /auth | | Payload nonce_c |option will be determined by this previous decisions. 1. Critical (C = 1)|<----------------------------------------| | | | ACK [0x73DE] | | (Token 0x78728FD4AC3190FF) | | 2.01 Created | | Uri-Path [auth/5] | | Payload nonce_s | 2) |---------------------------------------->| | | | CON [0x7654] | | (Token 0x78728FD4AC3190FF) | | Payload EAP Req/Id | | POST /auth/5 | 3) |<----------------------------------------| | | | ACK [0x7654] | | (Token 0x78728FD4AC3190FF) | | 2.04 Changed | | Payload EAP Res/Id | 4) |---------------------------------------->| | | | CON [0x7654] | | (Token 0x78728FD4AC3190FF) | | Payload EAP-PSK MSG2. Safe to Forward (1) 3. NoCacheKey (111) The number of the SeqNum option will fit this pattern: xxx11111 0 1| | POST /auth/5 | 5) |<----------------------------------------| | | | ACK [0x7654] | | (Token 0x78728FD4AC3190FF) | | 2.04 Changed | | Payload EAP-PSK MSG2| 6) |---------------------------------------->| | | | CON [0x9869] | | (Token 0x78728FD4AC3190FF) | | Payload EAP-PSK MSG3| | POST /auth/5 | 7) |<----------------------------------------| | | | ACK [0x9869] | | (Token 0x78728FD4AC3190FF) | | 2.04 Changed | | Payload EAP-PSK MSG4 5 6 7 +---+---+---+---+---+---+---+---+ |8) |---------------------------------------->| MSK | | MSK | | | | DTLS_PSK| | DTLS_PSK | | | DTLS HANDSHAKE | | (Initiated by EAP Auth.) | 9') |<--------------------------------------->| | | | CON [0x7811] | | (Token 0x78728FD4AC3190FF) | | Payload EAP Success | (*) | POST /auth/5 | 10) |<----------------------------------------| | | | ACK [0x7811] | (*) | (Token 0x78728FD4AC3190FF) | | 2.04 Changed | 11) |---------------------------------------->| ............. | | | CON [0x7511] | | (Token 0xAA763D82F623B7FF) | (*) | GET /temp | 12) |<----------------------------------------| | | | ACK [0x7511]|(*)NoCacheKey| U |(Token 0xAA763D82F623B7FF)C | +---+---+---+---+---+---+---+---+ Figure 3: Auth Option Number Mask The option number is TBD. The resultant SeqNum option is: +-----+---+---+---+---+--------+--------+--------+---------+ |2.05 ContentNo. | C |"22.5C"U |13) |---------------------------------------->| ................N | R | Name |CON [0x7600]Format | Length |(Token 0x678443AA678BC690)Default |(*)+-----+---+---+---+---+--------+--------+--------+---------+ |DELETE /auth/5TBD |14) |<----------------------------------------|x | | x |ACK [0x7500]|(*)SeqNum |(Token 0x678443AA678BC690)uint | 0-16 |2.02 Deleted(none) |15) |---------------------------------------->| (*) Protected with DTLS+-----+---+---+---+---+--------+--------+--------+---------+ C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable Figure3: EAP over CoAP with DTLS 3.3. 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 the rfc [RFC3748], which are enumerated next: o Unreliable transport. EAP does lower layers are not assumed 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. Next we go over the previous points to verify that CoAP does fits the EAP lower layer requirements. Regarding the 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. About possible duplication, although not required, CoAP provides a message-ID value for deduplication purposes. Finally for the ordering guarantees needed by EAP, CoAP message-ID can be used for this purpose. As we can see, CoAP does fulfill the requirements of EAP to be considered suitable as lower-layer. 3.4. Optimization Considerations Here we consider two possible optimizations for reducing the message length: o A first optimization would be to reduce the URI of the bootstrapping service. For example, the /auth URI could be reduced to /a. o Another optimization would be to use a zero length CoAP token in the exchange. Some use cases as LoRA Networks [I-D.pelov-core-cosol] might take advantage of these reductions to improve the performance of the bootstrapping process.4: SeqNum option 4. Key Derivation for protecting CoAP messages As a result of a successful EAP authentication, both CoAP server and CoAP client share a Master Key Session (MSK). The assumption is that MSK is a fresh key so any derived key from the MSK will be also fresh. We have considered the derivation of eitherCOAP_PSKthe OSCORE Security Context orDTLS_PSK.pre-shared key that can be used for a DTLS negotiation (DTLS_PSK) (in the Appendix) 4.1. DerivingCOAP_PSK A key COAP_PSK is derived fromtheMSKOSCORE Security Context Key material needed togeneratederive theauthentication tag included inOSCORE Security Context, from theAUTH option. COAP_PSK is derived by using AES- CMAC-PRF-128 [RFC4615], which, in turn, uses AES-CMAC-128 [RFC4493]. In this case, rest of CoAP exchanges between both entitiesMSK can beprotected with integrity (NOTE: encryption will be considered in the future) with AUTH option without the need of using DTLS. Thus, all CoAP messages MUST include AUTH option from that point. (NOTE:done as follows. First, HKDF SHA-256 [RFC5869] is mandatory to implement. Weunderstand that this would not beassume thestandard wayuse ofprotecting CoAP but instead a new waythe default algorithms HKDF SHA-256 and AES-CCM-16-64-128. The extract phase ofprotecting CoAP messages). COAP_PSK isHKDF produces a16-byte lengthpseudo-random keywhich( that we refer to here as RK) that iscomputedused to generate the OSCORE Security Context in thefollowing way: COAP_PSK = KDF(MSK, "IETF_COAP_PSK" || nonce_c || nonce_s, 64, length) where: oExpand phase. TheAES-CMAC-PRF-128derivation isdefined in [RFC4615]. This function uses AES-CMAC-128done asbuilding block.follows: RK = HMAC-SHA-256(MSK) Where: oTheMSKexported by the EAP method. o "IETF_COAP_PSK" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it). This value is concatenated with the value of the Token Option value. o nonce_cis therandom value sent by the EAP Authenticator toMaster Session Key derived from the EAPPeer in the POST Message.method. ononce_sRK is therandom value sent by the EAP Peer toRandom Key that is generated from theEAP AuthenticatorMSK in theAcknowledgment to the POST Message. o 64 isExtract phase. Discussions about thelengthuse of theMSK. o length is the length ofMSK for thelabel "IETF_COAP_PSK" (13 bytes). 4.2. Deriving DTLS_PSK Inkey derivation are done in Section Section 7. Based on thesecond alternative, a DTLS_PSK is derivedRK generated from theMSK between both CoAP endpoints. So far, DTLS_PSK will have also 16 byte lengthMSK, we can now generate the Master Secret andit will derivedMaster Salt. The key derivation is performed as follows:DTLS_PSKMaster_Secret =KDF(MSK, "IETF_DTLS_PSK" || nonce_c || nonce_s, 64, length). This value is concatenated with the value of the Token Option value.HKDF(RK, "IETF_OSCORE_MASTER_SECRET", length) where: oMSKThe RK is exportedbyin theEAP method.Extract Phase, previously commented. o"IETF_DTLS_PSK""IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it). ononce_c is the random value sent by the EAP Authenticator to the EAP Peer in the POST Message. o nonce_s is the random value sent by the EAP Peer to the EAP Authenticator in the Acknowledgment to the POST Message. o 64 is the length of the MSK. olength is the length of thelabel "IETF_DTLS_PSK" (13 bytes). As mentioned in [RFC4279], a PSK identity is needed.Master_Secret. Weare considering the usage of the Token Option value chosen duringset theEAP authentication as identity. In any case, this still needs further investigation. 5. Generating AUTH option A new AUTH option is defined in this document for authentication purposes. Following guidelines in [RFC7252] this option is: 1. Format opaque (sequence of bytes). 2. Elective. 3. Unsafelength toForward. 4. No cacheable.32 bytes Thenumber of the option willMaster Salt can bedetermined by this previous decisions. 1. Elective (C = 0) 2. Unsafe to Forward (0) 3. NoCacheKey (111) The number of the AUTH option will fit this pattern: xxx11100 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | NoCacheKey| U | C | +---+---+---+---+---+---+---+---+ Figure 4: Auth Option Number Mask First available option number is 01011100 (92). The resultant AUTH option is: +-----+----+---+---+---+-----------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+----+---+---+---+-----------+--------+--------+---------+ | 92 | | | x | | AUTH | opaque | 128 | (none) | +-----+----+---+---+---+-----------+--------+--------+---------+ Figure 5: AUTH Option C, U, N and R columns indicate the properties, Critical, UnSafe, NoCacheKey and Repeatable, respectively. To generate the value of the AUTH option, we use AES-CMAC-128derived asauthentication algorithm. Thus, the AUTH option content will have an authentication tag of 16 bytes. AUTH Option valuefollows: Master_Salt =AES-CMAC-128(COAP_PSK, MSG, MSG_LENGTH)HKDF(PK, "IETF_OSCORE_MASTER_SALT", length) where: oCOAP_PSKThe RK isthe key derivedexported in theCoAP Security Association process.Extract Phase, previously commented. oMSG"IETF_OSCORE_MASTER_SALT" is theCoAP message including AUTH option filled with zeros. o MSG_LENGTH. Length of the CoAP message. After applying AES-CMAC-128 function, the AUTH option value will be set in the AUTH option replacing the zeros. 6. Implementation At the time of writing this document, we have developed a proof-of- concept based on libcoap ([libCoAP]) in PC platform and started the development of a simulation with COOJA network simulator for Contiki ([Contiki]). So far, we have implemented an authentication tag by using AES-CMAC- 128. However this authentication tag has been included in the payloadASCII code representation oftwo final messages after sendingtheEAP Success. The implementation ofnon-NULL terminated string (excluding theAUTH option will come soon. Moreover, we have used AES-CMAC-128 for COAP_PSK. Since this function does not allow a key longer than 16 bytes, we have useddouble quotes around it). o length is themost significative 16 byteslength of theMSK as input key. Since AES-CMAC-PRF-128 eliminates this limitation, we will implement this version instead.Master Salt. Weare using (forset thePC version) libeap in wpa-supplicant and hostapd open source software ([hostapd])length toimplement the EAP stack and, in particular, the EAP-PSK method. 7. Future Work: CoAP Intermediaries Architecture explained in Figure 1 assumes that EAP peer8 bytes. The ID Context cancommunicate with the EAP authenticator. In certain scenarios, EAP authenticator may notbereachable from the EAP peer if the EAP authenticator is placed several hops-away. In this scenario, described in Figure 6, we are considering the usage a new service that assists the authentication. This service acts as a intermediary of CoAP messages between the EAP peer and EAP authenticator. Currently we have a design of three different variants of this entity. o CoAP relay o CoAP proxy o CoAP stateless proxy Proof-of-concept implementations of the CoAP relay and CoAP proxy and CoAP stateless proxy are evaluated. The strategy is similar to the one described in PANA Relay ([RFC6345]) or DTLS Relay ([I-D.kumar-dice-dtls-relay]). Unlike CoAP proxy, the CoAP relay is not intendedset tokeep any state (stateless behavior) andtheEAP peer is not assumed to be awareIdentity of thepresence of the CoAP relay. The CoAP stateless proxy provides an approach between the previous two. It behaves as a proxy, but avoid generating any state related to the ongoing exchange. +------------+ +------------+ +--------------+ | EAP peer/ | | CoAP | | EAP auth | | CoAP server|+------+|intermediary|+------+| CoaP client | +------------+ CoAP +------------+ CoAP +--------------+ | AAA | | +--------------+ | EAP server/ | | AAA server | +--------------+ Figure 6: CoAP EAP Intermediary Architecture Once the EAP peer has been authenticated, CoAP intermediary should not be needed anymore for thisEAP peer.Development of this new service may modify the "Unsafe to Forward" flag of the AUTH option. 8.5. Use Case Scenario In the following, we explain a basic example about the usage of CoAP- EAP. There are 5 entities involved in the scenario: o 2 nodes (A and B), which are constrained devices. o 1 node D, which is considered a no so constrained device, suchasa phone, or a tablet or even a laptop. o 1 controller (C). The controller manages a domain where nodes can be deployed. It can be considered a more powerful machine than thenodes, however it may have some constrained resources.nodes. o 1 AAA server (AAA). The AAA is an Authentication, Authorization and Accounting Server, which is not constrained. Any node wanting to join the domain managed by the controller,mustMUST perform an CoAP-EAP authentication with the controller C. Thisauthentication, as depicted in Figure 6,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 the controller C. Moreover, any other entity (i.e. node D) , which wants to join and establish communications with nodes under the controller C's domain must also do the same.One use case isLet us assume that thefollowing. Thenode A wants to communicate with node B (e.g. to active a light switch). The overall process is divided in three phases. Let's start with node A. In the first phase, the node A (EAP peer) does not yet belong to the controller C's domain. Then, it communicates with controller C (EAP authenticator) and authenticates with CoAP-EAP, which, in turn, communicates with the AAA server to complete the authentication process. If the authentication is successful, key material is distributed to the controller C and derived by node A. This key material allows node A to establish a security association with controller C. Some authorization information coming from the AAA infrastructure may be also provided in this step. If authentication and authorization are correct, node A is enrolled in the controller C's domain during a period of time. In particular, [RFC5247] recommends 8 hours, though the AAA server can establishthisa different lifetime. In the same manner, B needs to 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 the controller C for authorization to access node B and obtain all the required information to do that in a secure manner (e.g. keys, tokens, authorization information, etc.). It doesnotNOT require the usage of CoAP-EAP. The details of this phase are out of scope of thisdocument.document, but ACE framework can be 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 isonlyONLY 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 AAAserver. Another use case isserver nor performing EAP authentication. 6. Discussion 6.1. CoAP as EAP lower-layer In this section we discuss thefollowing. Node D wantssuitability of the CoAP protocol as EAP lower layer, and review the requisites imposed by the EAP protocol tocommunicate with node A (e.g.any protocol that transports EAP. The assumptions EAP makes about its lower layers can be found in section 3.1 of the rfc [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 toobtain a temperature measurement). To doprovide an EAP MTU size of 1020 octets or greater. o Possible duplication. EAP stipulates that,firstwhile 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 the unreliable transport, although EAP assumes a non reliable transport, CoAP does provide a reliability mechanism through the use ofall, node D must joinConfirmable messages. For thecontroller C's domain. To do thaterror 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 for EAP. Regarding message ordering, we propose the use of a new CoAP option, the SeqNum option described in Section (Section 3.2), which will allow keep the order in which the different messages are exchanged. Regarding the Token, we consider the use of a constant value using a small 1 byte Token. In fact, the EAP server will not send a new EAP request until itperformshas processed the expected EAP response. Additionally, we are under the assumption that there will aCoAP-EAPsingle EAP authentication between the constrained device andauthorization withthecontroller C (first phase). If everything ends with success,same Controller. 6.2. Size of thenode D can request access to node AEAP lower-layer vs EAP method size Using CoAP as EAP lower layer guarantees a constrained transport for EAP in constrained environments. However, it is a fair toC (second phase). Thenask about the level of improvement taking into account the overload represented by the EAP method. In fact, ifnode Dthe EAP method isauthorized can access to node A (third phase). So,very taxing in theend, node Dnumber of messages and the bytes sent over the networks the improvement achieved in the EAP lower-layer may be less significant ([coap-eap]). However, if the EAP method is lightweight and suitable for constrained networks (e.g. EAP-PSK, as a representative example of a lightweight EAP method) a constrained EAP lower-layer brings more benefits. This leads to the conclusion that possible next steps in this field could be alsoimplements CoAP-EAPimproving or designing new EAP methods that can be better adapted to the requirements of constrained devices and networks. Therefore, others EAP methods such as EAP-AKA or new lightweight EAP methods such as EAP-EDHOC [I-D.ingles-eap-edhoc] may benefit from a CoAP-based EAP lower-layer, as well as anyothernew lightweight EAP method. 6.3. Controller as the CoAP Client Due to the constrainednode. 9. Acknowledgments Wecapacities 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 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 Emtpy Token value to save resources, since there will be no other endpoint or CoAP exchange. 6.4.2. Removing SeqNum Option An alternative to consider wouldlikebe tothank Pedro Moreno-Sancheztry to rely on the Message ID values as a way of achieving the order delivery throughout the authentication exchange. Here we have two approximations: 1) Removing the option from the ACKs andGabriel Lopez-Millan for2) removing thefirst reviewoption completely. 1. Since the ACKs are piggybacked by design, there is only 1 ongoing authentication process and the EAP exchange is done in a lockstep fashion, when we get a response we will get the same Message ID ofthis document. Also,the request and we can confirm the SeqNum of the Request. 2. An alternative to consider wouldlikebe tothank Ivan Jimenez-Sanchez fortry to solely rely on thefirst proof-of-concept implementationMessage ID values as a way ofthis idea. Weachieving the order delivery throughout the authentication exchange. Here we alsothank forhave two approaches: A) To expect randomly generated Message IDs and B) set the Message ID to increase monotonically by 1. A. Regarding the use of the Message ID, theirvaluables commentsvalues in the requests sent by the Controller are generated randomly, as suggested by CoAP. The Controller selects a new Message ID value each time a new request is sent toAlexander Pelovthe CoAP server, until the bootstrapping service finishes. Moreover, the Controller stores the last Message ID sent until correctly receiving the corresponding ACK. The CoAP server keeps track of the last received Message ID to identify retransmissions, andLaurent Toutain, specially forthepotential optimizationsprevious Message IDs during the current bootstrapping to identify old messages. In general, a request is considered valid in terms ofCoAP- EAP. This workthe Message ID if either this value matches the last value received, which means a retransmission of the last response is required, or the arrival of a new Message ID, which therefore represents a new message. If these rules do not apply (i.e., an old Message ID has beenpartly fundedreceived), the CoAP server silently discards the request. This is possible because the bootstrapping service is designed as lockstep, i.e. the Controller will not send a new request until it has received the expected response. When the bootstrapping exchange finishes successfully, the CoAP server can free the tracked Message IDs, except for the last received Message ID at the end of the bootstrapping, just in case a retransmission is required. B. This case would avoid having to keep track of the already used Message IDs, monotonically increasing byEuropean Commission through1 theFP7-SMARTIE-609062 EU Project. 10.message ID value once the first is randomly picked by the Controller. 6.4.3. 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 (EAP-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.10.1.7.1. Authorization Authorization is part of the 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(RADIUS in this case)can be deliveredin RADIUS attributes such as NAS-Filter-Rules, Framed-MTU, Session-Timeout, etc.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.10.2.7.2. Cryptographic suite selection How the cryptographic suit is selected is also important. To reduce the overhead of the protocol we use a default cryptographic suite.To supportAs OSCORE is assumed to run after theprotocol all implementations MUST at least support AES-CMAC-PRF-128 asEAP authentication, theKDF and AES-CMAC-128same default crypto-suite is used in this case asdefault.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 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.10.3. Additional Security Consiederation Other security related concerns can be how to ensure that7.3. Freshness of thenode joiningkey material In this design, we do not exchange nonces to provide freshness to thesecurity domain can in fact trustkeys derived from theController.MSK. Thisissueiselaborated indone under theEAP KMF[RFC5247] . Summarizing,assumption that thenode knows it can trustMSK and EMSK keys derived are fresh key material by theController, becausespecifications of the EAP KMF. Since only one session keythat is used to establish the security associationis derived from theMSK. If the Controller has the MSK, it is clearMSK we do not have to concern ourselves with theAAA Servergeneration of additional key material. In case we need to refresh thenode trusts the Controller, which confirms it isMSK, a re-authentication can be done, by running process again, using atrusted party. 11.more lightweight mechanism to derive additional key material such as ERP [RFC6696]. 8. IANA Considerations This document has no actions for IANA.12.9. Acknowledgments We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan for the first review of this document. Also, we would like to thank Ivan Jimenez-Sanchez for the first proof-of-concept implementation of this idea. We also thank for their valuables comments to Alexander Pelov and Laurent Toutain, specially for the potential optimizations of CoAP- EAP. 10. References12.1.10.1. Normative References [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. [I-D.kumar-dice-dtls-relay] Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay for Constrained Environments", draft-kumar-dice-dtls- relay-02 (work in progress), October 2014. [I-D.ohba-core-eap-based-bootstrapping] Das, S. and Y. Ohba, "Provisioning Credentials for CoAP Applications using EAP", draft-ohba-core-eap-based- bootstrapping-01 (work in progress), March 2012. [I-D.pelov-core-cosol] Pelov, A., Toutain, L., and Y. Delibie, "Constrained Signaling Over LP-WAN", draft-pelov-core-cosol-01 (work in progress), February 2016. [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>. [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>. [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>. [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, <https://www.rfc-editor.org/info/rfc4764>. [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>. [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>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>. [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011, <https://www.rfc-editor.org/info/rfc6345>. [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>.12.2.10.2. Informative References [cantcoap] Mills, A., "Cantcoap implementation of CoAP", January 2013. [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. [Contiki] Contiki, "Contiki: The Open Source OS for the Internet of Things", March 2014. [hostapd] hostapd, "hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator", March 2014.[libCoAP] "C-ImplementationAppendix A. CoAP-EAP with DTLS Other possibility at our disposal is to do a DTLS handshake after the MSKs generation and continue the communication between endpoints using CoAP through DTLS as we can see at Figure 5. The Steps 0-6 are the same as the case with OSCORE, however, before continuing with Steps 7 and 8, the EAP authenticator starts the DTLS handshake with the EAP peer (Step 6'). To establish a DTLS Security Association, a key named DTLS-PSK is derived from MSK (see Section 4 ). In this case the CoAP client can start DTLS before sending the last message containing the EAP Success. Once DTLS is established, any posterior CoAP exchange is protected. Thus, OSCORE in this instance is not needed for key confirmation, since a successful DTLS negotiation confirms the possession ofCoAP", January 2013.DTLS_PSK that, in turn, corroborates that both entities participated in the EAP authentication. EAP peer EAP Auth. (COAP server) (COAP client) ------------- ------------- | | | NON [0x6af5] | | POST /b | | No-Response | 0) | Token (0xab) | |---------------------------------------->| | | | CON [0x7654] | | POST /b | | SeqNum(x) | | Token (0xac) | | Payload EAP Req/Id | 1) |<----------------------------------------| | | | ACK [0x7654] | | SeqNum(x) | | Token (0xac) | | 2.01 Created | | Uri-Path [/b/5] | | Payload EAP Rep/Id | 2) |---------------------------------------->| | | | CON [0x8694] | | POST /b/5 | | SeqNum(x+1) | | Token (0xac) | | Payload EAP-X MSG 1 | 3) |<----------------------------------------| | | | ACK [0x8694] | | Token (0xac) | | SeqNum(x+1) | | 2.04 Changed | | Payload EAP-X MSG 2 | 4) |---------------------------------------->| .... | | | CON [0x9869] | | POST /b/5 | | SeqNum(x+n/2)| | Token (0xac) | | Payload EAP-X MSG (n-1) | 5) |<----------------------------------------| | | | ACK [0x9869] | | SeqNum(x+n/2) | | Token (0xac) | | 2.04 Changed | | Payload EAP-X MSG (n) | MSK 6)|---------------------------------------->| MSK | | | | DTLS_PSK| | DTLS_PSK | | | DTLS HANDSHAKE | | (Initiated by EAP Auth.) | 6') |<--------------------------------------->| | | | CON [0x7811] | | POST /b/5 | | Token (0xac) | | Payload EAP Success | (*) 7) |<----------------------------------------| | | | ACK [0x7811] | (*) | Token (0xac) | | 2.04 Changed | 8) |---------------------------------------->| (*) Protected with DTLS Figure 5: EAP over CoAP with DTLS A.1. Deriving DTLS_PSK In the second alternative, a DTLS_PSK is derived from the MSK between both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length and it will derived from the RK (generated as done in Section Section 4) as follows: DTLS_PSK = HKDF(RK, "IETF_DTLS_PSK" , length). This value is concatenated with the value of the Token Option value. where: o RK is the Random Key generated in the Extract phase, from the MSK. o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it). o length is the length of the DTLS_PSK (16 bytes). 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 ofMurcia Campus de EspinardoOviedo Calle Luis Ortiz Berrocal S/N,Faculty of Computer Science Murcia 30100Edificio Polivalente Gijon, Asturias 33203 SpainPhone: +34 868 88 78 82Email:dan.garcia@um.esgarciadan@uniovi.es