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/