< draft-marin-ace-wg-coap-eap-06.txt		draft-marin-ace-wg-coap-eap-07.txt >
	ACE Working Group R. Marin		ACE Working Group R. Marin
	Internet-Draft D. Garcia		Internet-Draft University of Murcia
	Intended status: Experimental University of Murcia		Intended status: Standards Track D. Garcia
	Expires: April 27, 2018 October 24, 2017		Expires: July 25, 2021 University of Oviedo
			January 21, 2021
	EAP-based Authentication Service for CoAP		EAP-based Authentication Service for CoAP
	draft-marin-ace-wg-coap-eap-06		draft-marin-ace-wg-coap-eap-07
	Abstract		Abstract
	This document describes an authentication service that uses EAP		This document describes an authentication service that uses EAP
	transported by means of CoAP messages with two purposes:		transported by means of CoAP messages with the following purposes:
	o Authenticate two CoAP endpoints.		o Authenticate 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		o Bootstrap key material to protect CoAP messages exchanged between
	them.		them.
			o Enable the establishment of Security Associations between them.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 27, 2018.		This Internet-Draft will expire on July 25, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. General Architecture . . . . . . . . . . . . . . . . . . . . 3		2. General Architecture . . . . . . . . . . . . . . . . . . . . 3
	3. General Flow Operation . . . . . . . . . . . . . . . . . . . 3		3. General Flow Operation . . . . . . . . . . . . . . . . . . . 4
	3.1. EAP in CoAP with AUTH option . . . . . . . . . . . . . . 4		3.1. EAP over CoAP: Running an OSCORE Security Association . . 4
	3.2. CoAP-EAP with DTLS . . . . . . . . . . . . . . . . . . . 7		3.2. The SeqNum Option . . . . . . . . . . . . . . . . . . . . 7
	3.3. CoAP as EAP lower-layer . . . . . . . . . . . . . . . . . 10		4. Key Derivation for protecting CoAP messages . . . . . . . . . 8
	3.4. Optimization Considerations . . . . . . . . . . . . . . . 11		4.1. Deriving the OSCORE Security Context . . . . . . . . . . 8
	4. Key Derivation for protecting CoAP messages . . . . . . . . . 11		5. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Deriving COAP_PSK . . . . . . . . . . . . . . . . . . . . 11		6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 12		6.1. CoAP as EAP lower-layer . . . . . . . . . . . . . . . . . 11
	5. Generating AUTH option . . . . . . . . . . . . . . . . . . . 13		6.2. Size of the EAP lower-layer vs EAP method size . . . . . 12
	6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 14		6.3. Controller as the CoAP Client . . . . . . . . . . . . . . 12
	7. Future Work: CoAP Intermediaries . . . . . . . . . . . . . . 15		6.4. Possible Optimizations . . . . . . . . . . . . . . . . . 12
	8. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 16		6.4.1. Empty Token . . . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		6.4.2. Removing SeqNum Option . . . . . . . . . . . . . . . 13
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6.4.3. Further re-authentication . . . . . . . . . . . . . . 14
	10.1. Authorization . . . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10.2. Cryptographic suite selection . . . . . . . . . . . . . 18		7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
	10.3. Additional Security Consiederation . . . . . . . . . . . 18		7.2. Cryptographic suite selection . . . . . . . . . . . . . . 14
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7.3. Freshness of the key material . . . . . . . . . . . . . . 15
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12.1. Normative References . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	12.2. Informative References . . . . . . . . . . . . . . . . . 20		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
			10.1. Normative References . . . . . . . . . . . . . . . . . . 15
			10.2. Informative References . . . . . . . . . . . . . . . . . 18
			Appendix A. CoAP-EAP with DTLS . . . . . . . . . . . . . . . . . 18
			A.1. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The goal of this document is to describe an authentication service		The goal of this document is to describe an authentication service
	that uses the Extensible Authentication Protocol (EAP) [RFC3748].		that uses the Extensible Authentication Protocol (EAP) [RFC3748].
	The authentication service is built on top of the Constrained		The authentication service is built on top of the Constrained
	Application Protocol (CoAP) [RFC7252] and allows authenticating two		Application Protocol (CoAP) [RFC7252] and allows authenticating two
	CoAP endpoints by using EAP without the need of additional protocols		CoAP endpoints by using EAP without the need of additional protocols
	to bootstrap a security association between them.		to bootstrap a security association between them.
	In particular, the document describes how CoAP can be used as EAP		In particular, the document describes how CoAP can be used as a
	lower-layer [RFC3748] to transport EAP between a CoAP server (EAP		constrained link-layer independent EAP lower-layer [RFC3748] to
	peer) and the CoAP client (EAP authenticator) using CoAP messages.		transport EAP between a CoAP server (EAP peer) and the CoAP client
	The CoAP client may contact with a backend AAA infrastructure to		(EAP authenticator) using CoAP messages. The CoAP client MAY contact
	complete the EAP negotiation as described in the EAP specification		with a backend AAA infrastructure to complete the EAP negotiation as
	[RFC3748].		described in the EAP specification [RFC3748].
	The assumption is that the EAP method transported in CoAP MUST		The assumption is that the EAP method transported in CoAP MUST
	generate cryptographic material [RFC5247] . In this way, the CoAP		generate cryptographic material [RFC5247] . In this way, the CoAP
	messages can be protected. There are two approaches that we have		messages can be protected. There are two approaches that we have
	considered in this document:		considered in this document:
	o To define a new AUTH option that includes an authentication tag		o To define how the OSCORE security association can be established
	generated with the cryptographic material exported during an EAP		based on the cryptographic material generated from the EAP
	authentication. This new option is used to protect the integrity		authentication.
	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		o To establish a DTLS security association using the exported
	cryptographic material after a successful EAP authentication.		cryptographic material after a successful EAP authentication.
	[I-D.ohba-core-eap-based-bootstrapping]		[I-D.ohba-core-eap-based-bootstrapping]
	This document also provides some comments about implementation of a		This document also provides some comments about implementation of a
	proof-of-concept of this preliminary idea		proof-of-concept of this preliminary idea
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. General Architecture		2. General Architecture
	The Figure 1 shows the architecture defined in this document.		The Figure 1 shows the architecture defined in this document.
	Basically a node acting as the EAP peer wants to be authenticated by		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		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		a model where the EAP peer will act as CoAP server for this service
	and the EAP authenticator will act as CoAP client and may interact		and the EAP authenticator will act as CoAP client and MAY interact
	with a backend AAA infrastructure. Nevertheless, a model where the		with a backend AAA infrastructure, which will place the EAP server
	EAP peer act as CoAP client and the EAP authenticator as CoAP server		and contain the information required to authenticate the CoAP client.
	will be also analyzed in the future.		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 server can be also analyzed in the future.
	+------------+ +------------+ +--------------+		+------------+ +------------+ +--------------+
	| EAP peer/ | | EAP auth./ | | EAP server/ |		| EAP peer/ | | EAP auth./ | | EAP server/ |
	| CoAP server|+------+| CoAP client|+-----+| AAA server |		| CoAP server|+------+| CoAP client|+-----+| AAA server |
	+------------+ CoAP +------------+ AAA +--------------+		+------------+ CoAP +------------+ AAA +--------------+
	Figure 1: CoAP EAP Architecture		Figure 1: CoAP EAP Architecture
	3. General Flow Operation		3. General Flow Operation
	The authentication service uses the CoAP protocol as transport layer		The authentication service uses CoAP as transport layer for EAP. In
	for EAP. CoAP becomes an EAP lower-layer (in EAP terminology). In		other words, CoAP becomes an EAP lower-layer (in EAP terminology).
	general, it is assumed that, since the EAP authenticator may need to		In general, it is assumed that, since the EAP authenticator may
	implement an AAA client to interact with the AAA infrastructure, this		implement an AAA client to interact with the AAA infrastructure, this
	endpoint will have more resources. We describe two different		endpoint will have more resources or, at least, it is not a so
	sequence flow. First, it is shown in Figure 2 where the AUTH option		constrained device. We describe two different sequence flow. First,
	is used at the end of EAP authentication. Second diagram (see		it is shown in Figure 2 where the OSCORE is used at the end of EAP
	Figure 3) shows the flow when DTLS is used to protect CoAP messages		authentication. The diagram in Figure 5 shows the flow when DTLS is
	at the end of the EAP authentication. As an example, both diagrams		used to protect CoAP messages at the end of the EAP authentication.
	show the usage of the EAP-PSK method [RFC4764] as authentication		As an example, both diagrams show the usage of a generic EAP method
	mechanism. (NOTE: any EAP method which is able to export		that we call EAP-X as authentication mechanism. (NOTE: any EAP
	cryptographic material should be valid).		method which is able to export cryptographic material should be
			valid).
	3.1. EAP in CoAP with AUTH option		3.1. EAP over CoAP: Running an OSCORE Security Association
	If the EAP peer discovers the presence of the EAP authenticator and		When the EAP peer discovers the presence of the EAP authenticator and
	wants to start the authentication, it can send a Non-Confirmable		wants to start the authentication, it can send a Non-Confirmable
	"POST /auth" request to the node (Step 0). This message, will carry		"POST /b" request to the node (Step 0). This message, will carry an
	an option developed from this work [RFC7967] called no response. The		option developed from the work on [RFC7967] called no response. The
	rationale of these options is avoiding having to listen to a response		rationale of this option is to avoid waiting for a response if it is
	if is not needed. So the use of this option will allow us to signal		not needed. So the use of this option will allow signaling the
	the intention of the EAP-Peer to start the authentication process.		intention of the EAP peer to start the authentication process, as a
	Immediately after that, the EAP authenticator will start the		trigger mechanism. Immediately after that, the EAP authenticator
	authentication service. It is worth noting that the EAP		will start the authentication service. It is worth noting that the
	authenticator may decide to start the authentication without waiting		EAP authenticator MAY decide to start the authentication without
	for a "POST /auth" message.		waiting for the trigger message if it has knowledge about the
			presence of the EAP peer, for instance, through a previous
			authentication (re-authentication).
	In any case, to perform the authentication service, the CoAP client		In any case, to perform the authentication service, the CoAP client
	(EAP authenticator) sends a Confirmable "POST /auth" request to the		(EAP authenticator) sends a Confirmable "POST /b" request to the CoAP
	CoAP Server (Step 1). POST message indicates to the CoAP server the		Server (Step 1). This POST message contains a new option SeqNum that
	creation of a resource for the EAP-based authentication service. The		holds a sequence number randomly chosen by the CoAP client. This
	CoAP server assigns a resource and answers with an Acknowledgment		SeqNum is used to provide ordered and reliable delivery of messages
	with the piggy-backed resource identifier (Uri-Path) (Step 2). It is		involved during the whole authentication. In general, when a CoAP
	assumed that the CoAP server will only have an ongoing authentication		request with EAP message is received, the CoAP client considers a
	and will not process simultaneous EAP authentications in parallel to		valid message if only if its sequence number is the expected value.
	save resources. Moreover if after a period of time (TBD) no further
	message is received from the CoAP client, the CoAP server will free		The sequence number is monotonically incremented by 1 so that the
	the created state. In this moment, the CoAP server has started a		CoAP server can know what it is the next expected sequence number.
	resource for the EAP authentication, whose resource identifier value
	will be used together with the Token option value to relate all the		After receiving the first POST, the CoAP server assigns a resource
	EAP conversation between both CoAP endpoints.		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. In
			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 is
			forwarded by the EAP authenticator, when EAP is in pass-through mode,
			to the local AAA server that 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
			together to 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		From now on, the EAP authenticator and the EAP peer will exchange EAP
	packets transported in the CoAP message payload (Steps		packets related to the EAP method, transported in the CoAP message
	3,4,5,6,7,8,9). The EAP authenticator will use POST method to send		payload (Steps 3,4,5,6). The EAP authenticator will use the POST
	EAP requests to the EAP peer. The EAP peer will use a Piggy-backed		method to send EAP requests to the EAP peer. The EAP peer will use a
	response in the Acknowledgement message to carry the EAP response.		Piggy-backed response in the Acknowledgment message to carry the EAP
	At the end of the message exchanges, if everything has gone well, the		response. At the end of the message exchanges, if everything has
	EAP authenticator is able to send an EAP Success message and both		gone well, the EAP authenticator is able to send an EAP Success
	CoAP endpoints will share a Master Session Key (MSK) ([RFC5295])		message and both CoAP endpoints will share a Master Session Key (MSK)
	If the new defined AUTH option is used, an authentication tag is		([RFC5295])
	generated with a new key named COAP_PSK, derived from the MSK. The
	Acknowledgment message from the CoAP server will also include an AUTH
	option so that the CoAP client can verify that the CoAP server
	obtained the MSK. This is shown in Steps 9 and 10. From that point
	any exchange (for example, Steps 11 and 12) between both CoAP
	endpoints are protected with the AUTH option. Finally, the CoAP
	client MAY send a Confirmable DELETE request to remove all the state
	related with the authentication service in the CoAP server (Steps 13
	and 14). The CoAP server may decide to remove the state after period
	of time in case not receiving a DELETE request. This may be easier
	if the EAP authenticator sends a session lifetime option (TBD) in the
	Step 9 (where the EAP Success is sent).
	On the contrary, if DTLS is used (see Figure 3), a DTLS_PSK is		To establish a security association that will confirm to the EAP peer
			that EAP authenticator received the MSK from the AAA sever, 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. This is shown in Steps 7 and 8. From
			that point any exchange between both CoAP endpoints are protected
			with OSCORE. Before sending the EAP success to the EAP peer, the EAP
			authenticator is able to 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 4.1
			On the contrary, if DTLS is used (see Figure 5), a DTLS_PSK is
	derived from the MSK. Moreover, exchanges between both CoAP		derived from the MSK. Moreover, exchanges between both CoAP
	endpoints are protected with DTLS from that point.		endpoints are protected with DTLS from that point.
	EAP peer EAP Auth.		EAP peer EAP Auth.
	(COAP server) (COAP client)		(CoAP server) (CoAP client)
	------------- -------------		------------- -------------
	| |		| |
	| NON [0x6af5] |		| NON [0x6af5] |
	| No-Response (0x1A) |		| POST /b |
	0) | (Token 0xFA5B45FF4723BB43) |		| No-Response |
	| POST /auth |		0) | Token (0xab) |
	|---------------------------------------->|		|---------------------------------------->|
	| |		| |
	| |		| CON [0x7654] |
	| CON [0x73DE] |		| POST /b |
	| (Token 0x78728FD4AC3190FF) |		| SeqNum(x) |
	| POST /auth |		| Token (0xac) |
	| Payload nonce_c |		| Payload EAP Req/Id |
	1) |<----------------------------------------|		1) |<----------------------------------------|
	| |		| |
	| ACK [0x73DE] |		| ACK [0x7654] |
	| (Token 0x78728FD4AC3190FF) |		| SeqNum(x) |
	| 2.01 Created |		| Token (0xac) |
	| Uri-Path [auth/5] |		| 2.01 Created |
	| Payload nonce_s |		| Uri-Path [/b/5] |
	2) |---------------------------------------->|		| Payload EAP Rep/Id |
	| |		2) |---------------------------------------->|
	| CON [0x7654] |		| |
	| (Token 0x78728FD4AC3190FF) |		| CON [0x8694] |
	| Payload EAP Req/Id |		| POST /b/5 |
	| POST /auth/5 |		| SeqNum(x+1) |
			| Token (0xac) |
	3) |<----------------------------------------|		| Payload EAP-X MSG 1 |
	| |		3) |<----------------------------------------|
	| ACK [0x7654] |		| |
	| (Token 0x78728FD4AC3190FF) |		| ACK [0x8694] |
	| 2.04 Changed |		| Token (0xac) |
	| Payload EAP Res/Id |		| SeqNum(x+1) |
	4) |---------------------------------------->|		| 2.04 Changed |
	| |		| Payload EAP-X MSG 2 |
	| CON [0x7654] |		4) |---------------------------------------->|
	| (Token 0x78728FD4AC3190FF) |		....
	| Payload EAP-PSK MSG 1 |
	| POST /auth/5 |
	5) |<----------------------------------------|
	| |
	| ACK [0x7654] |
	| (Token 0x78728FD4AC3190FF) |
	| 2.04 Changed |
	| Payload EAP-PSK MSG 2 |
	6) |---------------------------------------->|
	| |
	| CON [0x9869] |
	| (Token 0x78728FD4AC3190FF) |
	| Payload EAP-PSK MSG 3 |
	| POST /auth/5 |
	7) |<----------------------------------------|
	| |
	| ACK [0x9869] |
	| (Token 0x78728FD4AC3190FF) |
	| 2.04 Changed |
	| Payload EAP-PSK MSG 4 |
	8) |---------------------------------------->|
	MSK | | MSK
	| | CON [0x7811] | |
	COAP_PSK| (Token 0x78728FD4AC3190FF) |COAP_PSK
	| AUTH option |
	| Payload EAP Success | (*)
	| POST /auth/5 |
	9) |<----------------------------------------|
	| |
	(*) | ACK [0x7811] |
	| (Token 0x78728FD4AC3190FF) |
	| AUTH option |
	| 2.04 Changed |
	10) |---------------------------------------->|
	.............
	| |
	| CON [0x7511] |
	| (Token 0x55566AF7464646BC) | (*)
	| AUTH option |
	| GET /temp |
	11) |<----------------------------------------|
	| |
	| ACK [0x7511] |
	(*) | (Token 0x55566AF7464646BC) |
	| AUTH option |
	| 2.05 Content |
	| "22.5C" |
	12) |---------------------------------------->|
	................
	| |
	| CON [0x7600] |
	| (Token 0x678443AA678BC690) | (*)
	| AUTH option |
	| DELETE /auth/5 |
	13) |<----------------------------------------|
	| |
	| ACK [0x7500] |
	(*) | (Token 0x678443AA678BC690) |
	| AUTH option |
	| 2.02 Deleted |
	14) |---------------------------------------->|
	(*) Protected with AUTH option
	Figure 2: CoAP-EAP with AUTH 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. The Steps 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-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, new AUTH option is
	not needed. A successful DTLS negotiation confirms the possession of
	DTLS_PSK that, in turn, corroborates that both entities participated
	in the EAP authentication.
	EAP peer EAP Auth.		| |
	(COAP server) (COAP client)		| CON [0x9869] |
	------------- -------------		| POST /b/5 |
	| |		| SeqNum(x+n/2)|
	| NON [0x6af5] |		| Token (0xac) |
	| No-Response (0x1A) |		| Payload EAP-X MSG (n-1) |
	0) | (Token 0xFA5B45FF4723BB43) |		5) |<----------------------------------------|
	| POST /auth |		| |
	|---------------------------------------->|		| ACK [0x9869] |
	| |		| SeqNum(x+n/2) |
	| CON [0x73DE] |		| Token (0xac) |
	| (Token 0x78728FD4AC3190FF) |		| 2.04 Changed |
	| POST /auth |		| Payload EAP-X MSG (n) | MSK
	| Payload nonce_c |		6) |---------------------------------------->| |
	1) |<----------------------------------------|		| | V
	| |		| CON [0x7811] | OSCORE
	| ACK [0x73DE] |		| POST /b/5 | CONTEXT
	| (Token 0x78728FD4AC3190FF) |		| SeqNum(x+n/2+1) |
	| 2.01 Created |		| Token (0xac) | (*)
	| Uri-Path [auth/5] |		| OSCORE Option |
	| Payload nonce_s |		| EAP success |
	2) |---------------------------------------->|		MSK 7) |<----------------------------------------|
	| |		| | |
	| CON [0x7654] |		V (*) | ACK [0x7811] |
	| (Token 0x78728FD4AC3190FF) |		OSCORE | SeqNum(x+n/2+1) |
	| Payload EAP Req/Id |		CONTEXT | Token (0xac) |
	| POST /auth/5 |		| OSCORE Option |
	3) |<----------------------------------------|		| 2.04 Changed |
	| |		8) |---------------------------------------->|
	| ACK [0x7654] |
	| (Token 0x78728FD4AC3190FF) |
	| 2.04 Changed |
	| Payload EAP Res/Id |
	4) |---------------------------------------->|
	| |
	| CON [0x7654] |
	| (Token 0x78728FD4AC3190FF) |
	| Payload EAP-PSK MSG 1 |
	| POST /auth/5 |
	5) |<----------------------------------------|
	| |
	| ACK [0x7654] |
	| (Token 0x78728FD4AC3190FF) |
	| 2.04 Changed |
	| Payload EAP-PSK MSG 2 |
	6) |---------------------------------------->|
	| |
	| CON [0x9869] |
	| (Token 0x78728FD4AC3190FF) |
	| Payload EAP-PSK MSG 3 |
	| POST /auth/5 |
	7) |<----------------------------------------|
	| |
	| ACK [0x9869] |
	| (Token 0x78728FD4AC3190FF) |
	| 2.04 Changed |
	| Payload EAP-PSK MSG 4 |
	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) |---------------------------------------->|
	.............		(*) Protected with OSCORE
	| |		Figure 2: CoAP-EAP with OSCORE option
	| CON [0x7511] |
	| (Token 0xAA763D82F623B7FF) | (*)
	| GET /temp |
	12) |<----------------------------------------|
	| |
	| ACK [0x7511] |
	(*) | (Token 0xAA763D82F623B7FF) |
	| 2.05 Content |
	| "22.5C" |
	13) |---------------------------------------->|
	................
	| |		3.2. The SeqNum Option
	| CON [0x7600] |
	| (Token 0x678443AA678BC690) | (*)
	| DELETE /auth/5 |
	14) |<----------------------------------------|
	| |
	| ACK [0x7500] |
	(*) | (Token 0x678443AA678BC690) |
	| 2.02 Deleted |
	15) |---------------------------------------->|
	(*) Protected with DTLS		A new SeqNum option is defined in this document for establishing the
			ordering guarantee of the EAP exchange. Following guidelines in
			[RFC7252] this option is:
	Figure 3: EAP over CoAP with DTLS		1. Format opaque (sequence of bytes).
	3.3. CoAP as EAP lower-layer		2. Critical
	In this section we discuss the suitability of the CoAP protocol as		3. Safe to Forward
	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		4. No cacheable and Not part of the Cache-Key
	reliable.
	o Lower layer error detection. EAP relies on lower layer error		5. Not repeatable
	detection (e.g., CRC, Checksum, MIC, etc.)		The number of the option will be determined by this previous
			decisions.
	o Lower layer security. EAP does not require security services from		1. Critical (C = 1)
	the lower layers.
	o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020		2. Safe to Forward (1)
	octets or greater.
	o Possible duplication. EAP stipulates that, while desirable, it		3. NoCacheKey (111)
	does not require for the lower layers to provide non-duplication.
	o Ordering guarantees. EAP relies on lower layer ordering		The number of the SeqNum option will fit this pattern: xxx11111
	guarantees for correct operation.
	Next we go over the previous points to verify that CoAP does fits the		0 1 2 3 4 5 6 7
	EAP lower layer requirements. Regarding the unreliable transport,		+---+---+---+---+---+---+---+---+
	although EAP assumes a non reliable transport, CoAP does provide a		| | NoCacheKey| U | C |
	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		Figure 3: Auth Option Number Mask
	considered suitable as lower-layer.
	3.4. Optimization Considerations		The option number is TBD.
	Here we consider two possible optimizations for reducing the message		The resultant SeqNum option is:
	length:
	o A first optimization would be to reduce the URI of the		+-----+---+---+---+---+--------+--------+--------+---------+
	bootstrapping service. For example, the /auth URI could be		| No. | C | U | N | R | Name | Format | Length | Default |
	reduced to /a.		+-----+---+---+---+---+--------+--------+--------+---------+
			| TBD | x | | x | | SeqNum | uint | 0-16 | (none) |
			+-----+---+---+---+---+--------+--------+--------+---------+
	o Another optimization would be to use a zero length CoAP token in		C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
	the exchange.
	Some use cases as LoRA Networks [I-D.pelov-core-cosol] might take		Figure 4: SeqNum option
	advantage of these reductions to improve the performance of the
	bootstrapping process.
	4. Key Derivation for protecting CoAP messages		4. Key Derivation for protecting CoAP messages
	As a result of a successful EAP authentication, both CoAP server and		As a result of a successful EAP authentication, both CoAP server and
	CoAP client share a Master Key Session (MSK). The assumption is that		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		MSK is a fresh key so any derived key from the MSK will be also
	fresh. We have considered the derivation of either COAP_PSK or		fresh. We have considered the derivation of either the OSCORE
	DTLS_PSK.		Security Context or pre-shared key that can be used for a DTLS
			negotiation (DTLS_PSK) (in the Appendix)
	4.1. Deriving COAP_PSK
	A key COAP_PSK is derived from the MSK to generate the authentication
	tag included in the AUTH 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 entities can be
	protected 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: We
	understand that this would not be the standard way of protecting CoAP
	but instead a new way of protecting CoAP messages).
	COAP_PSK is a 16-byte length key which is computed in the following
	way:
	COAP_PSK = KDF(MSK, "IETF_COAP_PSK" || nonce_c || nonce_s, 64,
	length)
	where:
	o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses
	AES-CMAC-128 as building block.
	o The MSK exported by the EAP method.		4.1. Deriving the OSCORE Security Context
	o "IETF_COAP_PSK" is the ASCII code representation of the non-NULL		Key material needed to derive the OSCORE Security Context, from the
	terminated string (excluding the double quotes around it). This		MSK can be done as follows. First, HKDF SHA-256 [RFC5869] is
	value is concatenated with the value of the Token Option value.		mandatory to implement. We assume the use of the default algorithms
			HKDF SHA-256 and AES-CCM-16-64-128. The extract phase of HKDF
			produces a pseudo-random key ( that we refer to here as RK) that is
			used to generate the OSCORE Security Context in the Expand phase.
			The derivation is done as follows:
	o nonce_c is the random value sent by the EAP Authenticator to the		RK = HMAC-SHA-256(MSK)
	EAP Peer in the POST Message.
	o nonce_s is the random value sent by the EAP Peer to the EAP		Where:
	Authenticator in the Acknowledgment to the POST Message.
	o 64 is the length of the MSK.		o MSK is the Master Session Key derived from the EAP method.
	o length is the length of the label "IETF_COAP_PSK" (13 bytes).		o RK is the Random Key that is generated from the MSK in the Extract
			phase.
	4.2. Deriving DTLS_PSK		Discussions about the use of the MSK for the key derivation are done
			in Section Section 7.
	In the second alternative, a DTLS_PSK is derived from the MSK between		Based on the RK generated from the MSK, we can now generate the
	both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length		Master Secret and Master Salt. The key derivation is performed as
	and it will derived as follows:		follows:
	DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" || nonce_c || nonce_s, 64,		Master_Secret = HKDF(RK, "IETF_OSCORE_MASTER_SECRET", length)
	length). This value is concatenated with the value of the Token
	Option value.
	where:		where:
	o MSK is exported by the EAP method.		o The RK is exported in the Extract Phase, previously commented.
	o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL
	terminated string (excluding the double quotes around it).
	o nonce_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		o "IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of
	Authenticator in the Acknowledgment to the POST Message.		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 Master_Secret. We set the length to
			32 bytes
	o length is the length of the label "IETF_DTLS_PSK" (13 bytes).		The Master Salt can be derived as follows:
	As mentioned in [RFC4279], a PSK identity is needed. We are		Master_Salt = HKDF(PK, "IETF_OSCORE_MASTER_SALT", length)
	considering the usage of the Token Option value chosen during the EAP
	authentication as identity. In any case, this still needs further
	investigation.
	5. Generating AUTH option		where:
	A new AUTH option is defined in this document for authentication		o The RK is exported in the Extract Phase, previously commented.
	purposes. Following guidelines in [RFC7252] this option is:
	1. Format opaque (sequence of bytes).		o "IETF_OSCORE_MASTER_SALT" is the ASCII code representation of the
			non-NULL terminated string (excluding the double quotes around
			it).
	2. Elective.		o length is the length of the Master Salt. We set the length to 8
			bytes.
	3. Unsafe to Forward.		The ID Context can be set to the Identity of the EAP peer.
	4. No cacheable.		5. Use Case Scenario
	The number of the option will be determined by this previous		In the following, we explain a basic example about the usage of CoAP-
	decisions.		EAP. There are 5 entities involved in the scenario:
	1. Elective (C = 0)		o 2 nodes (A and B), which are constrained devices.
	2. Unsafe to Forward (0)		o 1 node D, which is considered a no so constrained device, such a
			phone, or a tablet or even a laptop.
	3. NoCacheKey (111)		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.
	The number of the AUTH option will fit this pattern: xxx11100		o 1 AAA server (AAA). The AAA is an Authentication, Authorization
			and Accounting Server, which is not constrained.
	0 1 2 3 4 5 6 7		Any node wanting to join the domain managed by the controller, MUST
	+---+---+---+---+---+---+---+---+		perform an CoAP-EAP authentication with the controller C. This
	| | NoCacheKey| U | C |		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.
	Figure 4: Auth Option Number Mask		Let us assume that the node 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 establish a 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.
	First available option number is 01011100 (92).		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 does NOT
			require the usage of CoAP-EAP. The details of this phase are out of
			scope of this document, but ACE framework can be used for this
			purpose [I-D.ietf-ace-oauth-authz]
	The resultant AUTH option is:		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
	| No. | C | U | N | R | Name | Format | Length | Default |		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
	| 92 | | | x | | AUTH | opaque | 128 | (none) |		no need to contact the external AAA server nor performing EAP
	+-----+----+---+---+---+-----------+--------+--------+---------+		authentication.
	Figure 5: AUTH Option		6. Discussion
	C, U, N and R columns indicate the properties, Critical, UnSafe,		6.1. CoAP as EAP lower-layer
	NoCacheKey and Repeatable, respectively.
	To generate the value of the AUTH option, we use AES-CMAC-128 as		In this section we discuss the suitability of the CoAP protocol as
	authentication algorithm. Thus, the AUTH option content will have an		EAP lower layer, and review the requisites imposed by the EAP
	authentication tag of 16 bytes.		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:
	AUTH Option value = AES-CMAC-128(COAP_PSK, MSG, MSG_LENGTH)		o Unreliable transport. EAP does not assume that lower layers are
			reliable.
	where:		o Lower layer error detection. EAP relies on lower layer error
			detection (e.g., CRC, Checksum, MIC, etc.)
	o COAP_PSK is the key derived in the CoAP Security Association		o Lower layer security. EAP does not require security services from
	process.		the lower layers.
	o MSG is the CoAP message including AUTH option filled with zeros.		o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020
			octets or greater.
	o MSG_LENGTH. Length of the CoAP message.		o Possible duplication. EAP stipulates that, while desirable, it
			does not require for the lower layers to provide non-duplication.
	After applying AES-CMAC-128 function, the AUTH option value will be		o Ordering guarantees. EAP relies on lower layer ordering
	set in the AUTH option replacing the zeros.		guarantees for correct operation.
	6. Implementation		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 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.
	At the time of writing this document, we have developed a proof-of-		Regarding the Token, we consider the use of a constant value using a
	concept based on libcoap ([libCoAP]) in PC platform and started the		small 1 byte Token. In fact, the EAP server will not send a new EAP
	development of a simulation with COOJA network simulator for Contiki		request until it has processed the expected EAP response.
	([Contiki]).		Additionally, we are under the assumption that there will a single
			EAP authentication between the constrained device and the same
			Controller.
	So far, we have implemented an authentication tag by using AES-CMAC-		6.2. Size of the EAP lower-layer vs EAP method size
	128. However this authentication tag has been included in the
	payload of two final messages after sending the EAP Success. The
	implementation of the AUTH 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 used the most significative 16
	bytes of the MSK as input key. Since AES-CMAC-PRF-128 eliminates
	this limitation, we will implement this version instead.
	We are using (for the PC version) libeap in wpa-supplicant and		Using CoAP as EAP lower layer guarantees a constrained transport for
	hostapd open source software ([hostapd]) to implement the EAP stack		EAP in constrained environments. However, it is a fair to ask about
	and, in particular, the EAP-PSK method.		the level of improvement taking into account the overload represented
			by the EAP method. In fact, if the EAP method is very taxing in the
			number 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 also improving 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 any new
			lightweight EAP method.
	7. Future Work: CoAP Intermediaries		6.3. Controller as the CoAP Client
	Architecture explained in Figure 1 assumes that EAP peer can		Due to the constrained capacities of the devices, to relieve them of
	communicate with the EAP authenticator. In certain scenarios, EAP		the retransmission tasks, we set the Controller as the CoAP client,
	authenticator may not be reachable from the EAP peer if the EAP		for the main exchange following the recommendations of the
	authenticator is placed several hops-away. In this scenario,		[I-D.ietf-lwig-coap] document to simplify the constrained device
	described in Figure 6, we are considering the usage a new service		implementation.
	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		6.4. Possible Optimizations
			6.4.1. Empty Token
	o CoAP proxy		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.
	o CoAP stateless proxy		6.4.2. Removing SeqNum Option
	Proof-of-concept implementations of the CoAP relay and CoAP proxy and		An alternative to consider would be to try to rely on the Message ID
	CoAP stateless proxy are evaluated. The strategy is similar to the		values as a way of achieving the order delivery throughout the
	one described in PANA Relay ([RFC6345]) or DTLS Relay		authentication exchange. Here we have two approximations: 1)
	([I-D.kumar-dice-dtls-relay]). Unlike CoAP proxy, the CoAP relay is		Removing the option from the ACKs and 2) removing the option
	not intended to keep any state (stateless behavior) and the EAP peer		completely.
	is not assumed to be aware of the presence 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.
	+------------+ +------------+ +--------------+		1. Since the ACKs are piggybacked by design, there is only 1 ongoing
	| EAP peer/ | | CoAP | | EAP auth |		authentication process and the EAP exchange is done in a lockstep
	| CoAP server|+------+|intermediary|+------+| CoaP client |		fashion, when we get a response we will get the same Message ID
	+------------+ CoAP +------------+ CoAP +--------------+		of the request and we can confirm the SeqNum of the Request.
	|
	AAA |
	|
	+--------------+
	| EAP server/ |
	| AAA server |
	+--------------+
	Figure 6: CoAP EAP Intermediary Architecture		2. An alternative to consider would be to try to solely rely on the
			Message ID values as a way of achieving the order delivery
			throughout the authentication exchange. Here we also have two
			approaches: A) To expect randomly generated Message IDs and B)
			set the Message ID to increase monotonically by 1.
	Once the EAP peer has been authenticated, CoAP intermediary should		A. Regarding the use of the Message ID, their values in the
	not be needed anymore for this EAP peer.		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 to the 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,
			and the previous Message IDs during the current bootstrapping
			to identify old messages. In general, a request is
			considered valid in terms of the 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 been received), 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.
	Development of this new service may modify the "Unsafe to Forward"		B. This case would avoid having to keep track of the already
	flag of the AUTH option.		used Message IDs, monotonically increasing by 1 the message
			ID value once the first is randomly picked by the Controller.
	8. Use Case Scenario		6.4.3. Further re-authentication
	In the following, we explain a basic example about the usage of CoAP-		Since the initial bootstrapping is usually taxing, it is assumed to
	EAP. There are 5 entities involved in the scenario:		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.
	o 2 nodes (A and B), which are constrained devices.		7. Security Considerations
	o 1 node D, which is considered a no so constrained device, such as		There are some aspects to be considered such as how authorization is
	a phone, or a tablet or even a laptop.		managed, how the cryptographic suite is selected and how the trust in
			the Controller is established.
	o 1 controller (C). The controller manages a domain where nodes can		7.1. Authorization
	be deployed. It can be considered a more powerful machine than
	the nodes, however it may have some constrained resources.
	o 1 AAA server (AAA). The AAA is an Authentication, Authorization		Authorization is part of the bootstrapping. It serves to establish
	and Accounting Server, which is not constrained.		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.
	Any node wanting to join the domain managed by the controller, must		7.2. Cryptographic suite selection
	perform an CoAP-EAP authentication with the controller C. This
	authentication, as depicted in Figure 6, 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 is the following. The node A wants to communicate with		How the cryptographic suit is selected is also important. To reduce
	node B (e.g. to active a light switch). The overall process is		the overhead of the protocol we use a default cryptographic suite.
	divided in three phases. Let's start with node A. In the first		As OSCORE is assumed to run after the EAP authentication, the same
	phase, the node A (EAP peer) does not yet belong to the controller		default crypto-suite is used in this case as explained in the Key
	C's domain. Then, it communicates with controller C (EAP		Derivation Section Section 4 The cryptographic suite is not
	authenticator) and authenticates with CoAP-EAP, which, in turn,		negotiated. If the cryptographic suite to be used by the node is
	communicates with the AAA server to complete the authentication		different from default, the AAA server will send the specific
	process. If the authentication is successful, key material is		parameters to the Authenticator. If the cryptographic suite is not
	distributed to the controller C and derived by node A. This key		supported, the key derivation process would result in a security
	material allows node A to establish a security association with		association failure.
	controller C. Some authorization information 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
	establish this 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		7.3. Freshness of the key material
	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 does not
	require the usage of CoAP-EAP. The details of this phase are out of
	scope of this document.
	In the third phase, the node A can access node B with the credentials		In this design, we do not exchange nonces to provide freshness to the
	and information obtained from the controller C in the second phase.		keys derived from the MSK. This is done under the assumption that
	This access can be repeated without contacting the controller, while		the MSK and EMSK keys derived are fresh key material by the
	the credentials given to A are still valid. The details of this		specifications of the EAP KMF. Since only one session key is derived
	phase are out of scope of this document.		from the MSK we do not have to concern ourselves with the generation
			of additional key material. In case we need to refresh the MSK, a
			re-authentication can be done, by running process again, using a more
			lightweight mechanism to derive additional key material such as ERP
			[RFC6696].
	It is worth noting that first phase with CoAP-EAP is only required to		8. IANA Considerations
	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.
	Another use case is the following. Node D wants to communicate with		This document has no actions for IANA.
	node A (e.g. to obtain a temperature measurement). To do that, first
	of all, node D must join the controller C's domain. To do that it
	performs a CoAP-EAP authentication and authorization with the
	controller C (first phase). If everything ends with success, the
	node D can request access to node A to C (second phase). Then if
	node D is authorized can access to node A (third phase). So, in the
	end, node D also implements CoAP-EAP as any other constrained node.
	9. Acknowledgments		9. Acknowledgments
	We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan		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		for the first review of this document. Also, we would like to thank
	Ivan Jimenez-Sanchez for the first proof-of-concept implementation of		Ivan Jimenez-Sanchez for the first proof-of-concept implementation of
	this idea.		this idea.
	We also thank for their valuables comments to Alexander Pelov and		We also thank for their valuables comments to Alexander Pelov and
	Laurent Toutain, specially for the potential optimizations of CoAP-		Laurent Toutain, specially for the potential optimizations of CoAP-
	EAP.		EAP.
	This work has been partly funded by European Commission through the		10. References
	FP7-SMARTIE-609062 EU Project.
	10. 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. 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 delivered in RADIUS attributes such as NAS-Filter-Rules,
	Framed-MTU, Session-Timeout, etc. 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. 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 support the protocol all implementations MUST at least support
	AES-CMAC-PRF-128 as the KDF and AES-CMAC-128 as default. 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 that the node
	joining the security domain can in fact trust the Controller. This
	issue is elaborated in the EAP KMF[RFC5247] . 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.
	11. IANA Considerations		10.1. Normative References
	This document has no actions for IANA.		[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.
	12. References		[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.
	12.1. Normative References		[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]		[I-D.kumar-dice-dtls-relay]
	Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay		Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay
	for Constrained Environments", draft-kumar-dice-dtls-		for Constrained Environments", draft-kumar-dice-dtls-
	relay-02 (work in progress), October 2014.		relay-02 (work in progress), October 2014.
	[I-D.ohba-core-eap-based-bootstrapping]		[I-D.ohba-core-eap-based-bootstrapping]
	Das, S. and Y. Ohba, "Provisioning Credentials for CoAP		Das, S. and Y. Ohba, "Provisioning Credentials for CoAP
	Applications using EAP", draft-ohba-core-eap-based-		Applications using EAP", draft-ohba-core-eap-based-
	bootstrapping-01 (work in progress), March 2012.		bootstrapping-01 (work in progress), March 2012.
	skipping to change at page 19, line 46 ¶		skipping to change at page 17, line 5 ¶
	Authentication Code-Pseudo-Random Function-128 (AES-CMAC-		Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
	PRF-128) Algorithm for the Internet Key Exchange Protocol		PRF-128) Algorithm for the Internet Key Exchange Protocol
	(IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006,		(IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006,
	<https://www.rfc-editor.org/info/rfc4615>.		<https://www.rfc-editor.org/info/rfc4615>.
	[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A		[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
	Pre-Shared Key Extensible Authentication Protocol (EAP)		Pre-Shared Key Extensible Authentication Protocol (EAP)
	Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,		Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
	<https://www.rfc-editor.org/info/rfc4764>.		<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		[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
	Authentication Protocol (EAP) Key Management Framework",		Authentication Protocol (EAP) Key Management Framework",
	RFC 5247, DOI 10.17487/RFC5247, August 2008,		RFC 5247, DOI 10.17487/RFC5247, August 2008,
	<https://www.rfc-editor.org/info/rfc5247>.		<https://www.rfc-editor.org/info/rfc5247>.
	[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,		[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
	"Specification for the Derivation of Root Keys from an		"Specification for the Derivation of Root Keys from an
	Extended Master Session Key (EMSK)", RFC 5295,		Extended Master Session Key (EMSK)", RFC 5295,
	DOI 10.17487/RFC5295, August 2008,		DOI 10.17487/RFC5295, August 2008,
	<https://www.rfc-editor.org/info/rfc5295>.		<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		[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
	A. Yegin, "Protocol for Carrying Authentication for		A. Yegin, "Protocol for Carrying Authentication for
	Network Access (PANA) Relay Element", RFC 6345,		Network Access (PANA) Relay Element", RFC 6345,
	DOI 10.17487/RFC6345, August 2011,		DOI 10.17487/RFC6345, August 2011,
	<https://www.rfc-editor.org/info/rfc6345>.		<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		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A		[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
	RADIUS Attribute, Binding, Profiles, Name Identifier		RADIUS Attribute, Binding, Profiles, Name Identifier
	Format, and Confirmation Methods for the Security		Format, and Confirmation Methods for the Security
	Assertion Markup Language (SAML)", RFC 7833,		Assertion Markup Language (SAML)", RFC 7833,
	DOI 10.17487/RFC7833, May 2016,		DOI 10.17487/RFC7833, May 2016,
	<https://www.rfc-editor.org/info/rfc7833>.		<https://www.rfc-editor.org/info/rfc7833>.
	[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.		[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
	Bose, "Constrained Application Protocol (CoAP) Option for		Bose, "Constrained Application Protocol (CoAP) Option for
	No Server Response", RFC 7967, DOI 10.17487/RFC7967,		No Server Response", RFC 7967, DOI 10.17487/RFC7967,
	August 2016, <https://www.rfc-editor.org/info/rfc7967>.		August 2016, <https://www.rfc-editor.org/info/rfc7967>.
	12.2. Informative References		10.2. Informative References
	[Contiki] "Contiki: The Open Source OS for the Internet of Things",		[cantcoap]
	March 2014.		Mills, A., "Cantcoap implementation of CoAP", January
			2013.
	[hostapd] "hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS		[coap-eap]
	Authenticator", March 2014.		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.
	[libCoAP] "C-Implementation of CoAP", January 2013.		[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.
			Appendix 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 of 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		Authors' Addresses
	Rafa Marin-Lopez		Rafa Marin-Lopez
	University of Murcia		University of Murcia
	Campus de Espinardo S/N, Faculty of Computer Science		Campus de Espinardo S/N, Faculty of Computer Science
	Murcia 30100		Murcia 30100
	Spain		Spain
	Phone: +34 868 88 85 01		Phone: +34 868 88 85 01
	Email: rafa@um.es		Email: rafa@um.es
	Dan Garcia Carrillo		Dan Garcia Carrillo
	University of Murcia		University of Oviedo
	Campus de Espinardo S/N, Faculty of Computer Science		Calle Luis Ortiz Berrocal S/N, Edificio Polivalente
	Murcia 30100		Gijon, Asturias 33203
	Spain		Spain
	Phone: +34 868 88 78 82		Email: garciadan@uniovi.es
	Email: dan.garcia@um.es
End of changes. 122 change blocks.
	634 lines changed or deleted		637 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/