Diff: draft-ietf-ace-dtls-authorize-00.txt - draft-ietf-ace-dtls-authorize-01.txt

	draft-ietf-ace-dtls-authorize-00.txt	draft-ietf-ace-dtls-authorize-01.txt

	ACE Working Group S. Gerdes	ACE Working Group S. Gerdes
	Internet-Draft O. Bergmann	Internet-Draft O. Bergmann
	Intended status: Standards Track C. Bormann	Intended status: Standards Track C. Bormann

	Expires: December 10, 2017 Universitaet Bremen TZI	Expires: January 4, 2018 Universitaet Bremen TZI
	G. Selander	G. Selander
	Ericsson	Ericsson
	L. Seitz	L. Seitz
	RISE SICS	RISE SICS

	June 08, 2017	July 03, 2017

	Datagram Transport Layer Security (DTLS) Profile for Authentication and	Datagram Transport Layer Security (DTLS) Profile for Authentication and
	Authorization for Constrained Environments (ACE)	Authorization for Constrained Environments (ACE)

	draft-ietf-ace-dtls-authorize-00	draft-ietf-ace-dtls-authorize-01

	Abstract	Abstract

	This specification defines a profile for delegating client	This specification defines a profile for delegating client
	authentication and authorization in a constrained environment by	authentication and authorization in a constrained environment by
	establishing a Datagram Transport Layer Security (DTLS) channel	establishing a Datagram Transport Layer Security (DTLS) channel
	between resource-constrained nodes. The protocol relies on DTLS for	between resource-constrained nodes. The protocol relies on DTLS for
	communication security between entities in a constrained network. A	communication security between entities in a constrained network. A
	resource-constrained node can use this protocol to delegate	resource-constrained node can use this protocol to delegate
	management of authorization information to a trusted host with less	management of authorization information to a trusted host with less

	skipping to change at page 1, line 43 ¶	skipping to change at page 1, line 43 ¶
	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 http://datatracker.ietf.org/drafts/current/.	Drafts is at http://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 December 10, 2017.	This Internet-Draft will expire on January 4, 2018.

	Copyright Notice	Copyright Notice

	Copyright (c) 2017 IETF Trust and the persons identified as the	Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of	(http://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

	skipping to change at page 2, line 28 ¶	skipping to change at page 2, line 28 ¶
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Unauthorized Resource Request Message . . . . . . . . . . 5	2.1. Unauthorized Resource Request Message . . . . . . . . . . 5
	2.2. AS Information . . . . . . . . . . . . . . . . . . . . . 6	2.2. AS Information . . . . . . . . . . . . . . . . . . . . . 6
	2.3. Resource Access . . . . . . . . . . . . . . . . . . . . . 7	2.3. Resource Access . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Dynamic Update of Authorization Information . . . . . . . 8	2.4. Dynamic Update of Authorization Information . . . . . . . 8
	3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9	3. RawPublicKey Mode . . . . . . . . . . . . . . . . . . . . . . 9
	4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10	4. PreSharedKey Mode . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 11	4.1. DTLS Channel Setup Between C and RS . . . . . . . . . . . 11
	4.2. Updating Authorization Information . . . . . . . . . . . 13	4.2. Updating Authorization Information . . . . . . . . . . . 13

	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	5.1. Unprotected AS Information . . . . . . . . . . . . . . . 14	5.1. Unprotected AS Information . . . . . . . . . . . . . . . 14
	5.2. Use of Nonces for Replay Protection . . . . . . . . . . . 14	5.2. Use of Nonces for Replay Protection . . . . . . . . . . . 14
	5.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14	5.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . 14	7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	7.2. Informative References . . . . . . . . . . . . . . . . . 15	7.2. Informative References . . . . . . . . . . . . . . . . . 15
	7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16	7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16

	1. Introduction	1. Introduction

	This specification defines a profile of the ACE framework	This specification defines a profile of the ACE framework
	[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource	[I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource
	server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The	server use CoAP [RFC7252] over DTLS [RFC6347] to communicate. The
	client uses an access token, bound to a key (the proof-of-possession	client uses an access token, bound to a key (the proof-of-possession
	key) to authorize its access to the resource server. DTLS provides	key) to authorize its access to the resource server. DTLS provides
	communication security, proof of possession, and server	communication security, proof of possession, and server
	authentication. Optionally the client and the resource server may	authentication. Optionally the client and the resource server may
	also use CoAP over DTLS to communicate with the authorization server.	also use CoAP over DTLS to communicate with the authorization server.

	This specification supports the DTLS PSK handshake [RFC4279] and the	This specification supports the DTLS handshake with Raw Public Keys
	DTLS handshake with Raw Public Keys (RPK) [RFC7250].	(RPK) [RFC7250] and the DTLS PSK handshake [RFC4279].

	The DTLS PSK handshake [RFC4279] provides the proof-of-possession for
	the key tied to the access token. Furthermore the psk_identity
	parameter in the DTLS PSK handshake is used to transfer the access
	token from the client to the resource server.

	The DTLS RPK handshake [RFC7250] requires client authentication to	The DTLS RPK handshake [RFC7250] requires client authentication to
	provide proof-of-possession for the key tied to the access token.	provide proof-of-possession for the key tied to the access token.
	Here the access token needs to be transferred to the resource server	Here the access token needs to be transferred to the resource server
	before the handshake is initiated, as described in section 8.1 of	before the handshake is initiated, as described in section 8.1 of
	draft-ietf-ace-oauth-authz. [1]	draft-ietf-ace-oauth-authz. [1]


		The DTLS PSK handshake [RFC4279] provides the proof-of-possession for
		the key tied to the access token. Furthermore the psk_identity
		parameter in the DTLS PSK handshake is used to transfer the access
		token from the client to the resource server.

	Note: While the scope of this draft is on client and resource server	Note: While the scope of this draft is on client and resource server

	communicating using CoAP over DTLS, it is expected that it applies	communicating using CoAP over DTLS, it is expected that it applies
	also to CoAP over TLS, possibly with minor modifications.	also to CoAP over TLS, possibly with minor modifications.
	However, that is out of scope for this version of the draft.	However, that is out of scope for this version of the draft.

	1.1. Terminology	1.1. Terminology

	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

	skipping to change at page 10, line 46 ¶	skipping to change at page 10, line 46 ¶
	possession token and therefore MUST specify a symmetric key that was	possession token and therefore MUST specify a symmetric key that was
	previously generated by AS as a session key for the communication	previously generated by AS as a session key for the communication
	between C and RS.	between C and RS.

	Depending on the requested token type and algorithm in the Access	Depending on the requested token type and algorithm in the Access
	Token request, AS adds RS Information to the response that provides C	Token request, AS adds RS Information to the response that provides C
	with sufficient information to setup a DTLS channel with RS. For	with sufficient information to setup a DTLS channel with RS. For
	symmetric proof-of-possession keys (c.f.	symmetric proof-of-possession keys (c.f.
	[I-D.ietf-ace-oauth-authz]), C must ensure that the Access Token	[I-D.ietf-ace-oauth-authz]), C must ensure that the Access Token
	request is sent over a secure channel that guarantees authentication,	request is sent over a secure channel that guarantees authentication,

	message integrity and confidentiality. This could be, e.g., a DTLS	message integrity and confidentiality.
	channel (for "coaps") or an OSCOAP [I-D.ietf-core-object-security]
	exchange (for "coap").

	When AS authorizes C it returns an AS-to-Client response with the	When AS authorizes C it returns an AS-to-Client response with the
	profile parameter set to "coap_dtls" and a "cnf" parameter carrying a	profile parameter set to "coap_dtls" and a "cnf" parameter carrying a
	"COSE_Key" object that contains the symmetric session key to be used	"COSE_Key" object that contains the symmetric session key to be used
	between C and RS as illustrated in Figure 7.	between C and RS as illustrated in Figure 7.

	2.01 Created	2.01 Created
	Content-Format: application/cbor	Content-Format: application/cbor
	Location-Path: /token/asdjbaskd	Location-Path: /token/asdjbaskd
	Max-Age: 86400	Max-Age: 86400

	skipping to change at page 15, line 38 ¶	skipping to change at page 15, line 33 ¶

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

	7.2. Informative References	7.2. Informative References

	[I-D.ietf-ace-cbor-web-token]	[I-D.ietf-ace-cbor-web-token]
	Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,	Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,

	"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-05	"CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-07
	(work in progress), June 2017.	(work in progress), July 2017.

	[I-D.ietf-core-object-security]	[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security of CoAP (OSCOAP)", draft-ietf-core-	"Object Security of CoAP (OSCOAP)", draft-ietf-core-

	object-security-03 (work in progress), May 2017.	object-security-04 (work in progress), July 2017.

	[I-D.ietf-core-resource-directory]	[I-D.ietf-core-resource-directory]
	Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE	Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
	Resource Directory", draft-ietf-core-resource-directory-10	Resource Directory", draft-ietf-core-resource-directory-10
	(work in progress), March 2017.	(work in progress), March 2017.

	[I-D.ietf-cose-msg]	[I-D.ietf-cose-msg]
	Schaad, J., "CBOR Object Signing and Encryption (COSE)",	Schaad, J., "CBOR Object Signing and Encryption (COSE)",
	draft-ietf-cose-msg-24 (work in progress), November 2016.	draft-ietf-cose-msg-24 (work in progress), November 2016.


	skipping to change at page 16, line 32 ¶	skipping to change at page 16, line 28 ¶
	June 2014, <http://www.rfc-editor.org/info/rfc7250>.	June 2014, <http://www.rfc-editor.org/info/rfc7250>.

	[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-	[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
	CCM Elliptic Curve Cryptography (ECC) Cipher Suites for	CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
	TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,	TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
	<http://www.rfc-editor.org/info/rfc7251>.	<http://www.rfc-editor.org/info/rfc7251>.

	7.3. URIs	7.3. URIs

	[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-	[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-

	03#section-8.1	06#section-5.7.1

	[2] https://tools.ietf.org/html/rfc7252#section-9	[2] https://tools.ietf.org/html/rfc7252#section-9

	[3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-	[3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-
	03#section-8.1	03#section-8.1

	[4] https://tools.ietf.org/html/rfc6749#section-5.2	[4] https://tools.ietf.org/html/rfc6749#section-5.2

	[5] https://tools.ietf.org/html/draft-ietf-cose-msg-23#section-12.1.2	[5] https://tools.ietf.org/html/draft-ietf-cose-msg-23#section-12.1.2


End of changes. 11 change blocks.
	19 lines changed or deleted	17 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/