--- 1/draft-ietf-ace-dtls-authorize-13.txt 2020-10-29 02:13:23.436770517 -0700 +++ 2/draft-ietf-ace-dtls-authorize-14.txt 2020-10-29 02:13:23.496772028 -0700 @@ -1,24 +1,24 @@ ACE Working Group S. Gerdes Internet-Draft O. Bergmann Intended status: Standards Track C. Bormann -Expires: March 12, 2021 Universitaet Bremen TZI +Expires: May 2, 2021 Universitaet Bremen TZI G. Selander Ericsson AB L. Seitz Combitech - September 08, 2020 + October 29, 2020 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) - draft-ietf-ace-dtls-authorize-13 + draft-ietf-ace-dtls-authorize-14 Abstract This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 12, 2021. + This Internet-Draft will expire on May 2, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -732,25 +732,25 @@ or Section 3.3, respectively, the client is authorized to access resources covered by the access token it has uploaded to the authz- info resource hosted by the resource server. With the successful establishment of the DTLS channel, the client and the resource server have proven that they can use their respective keying material. An access token that is bound to the client's keying material is associated with the channel. According to Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one access token for each client. New access tokens issued by the - authorization server replace previously issued access tokens for the - respective client. The resource server therefore must have a common - understanding with the authorization server how access tokens are - ordered. The authorization server may, e.g., specify a "cti" claim - for the access token (see Section 5.8.3 of + authorization server SHOULD replace previously issued access tokens + for the respective client. The resource server therefore needs a + common understanding with the authorization server how access tokens + are ordered. The authorization server may, e.g., specify a "cti" + claim for the access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz]) to employ a strict order. Any request that the resource server receives on a DTLS channel that is tied to an access token via its keying material MUST be checked against the authorization rules that can be determined with the access token. The resource server MUST check for every request if the access token is still valid. If the token has expired, the resource server MUST remove it. Incoming CoAP requests that are not authorized with respect to any access token that is associated with the client MUST be rejected by the resource server with 4.01 @@ -1070,23 +1070,23 @@ nodes. Profile ID: TBD (suggested: 1) Change Controller: IESG Reference: [RFC-XXXX] 10. Acknowledgments - Thanks to Jim Schaad for his contributions and reviews of this - document. Special thanks to Ben Kaduk for his thorough reviews of - this document. + Special thanks to Jim Schaad for his contributions and reviews of + this document and to Ben Kaduk for his thorough reviews of this + document. Thanks also to Paul Kyzivat for his review. Ludwig Seitz worked on this document as part of the CelticNext projects CyberWI, and CRITISEC with funding from Vinnova. 11. References 11.1. Normative References [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and @@ -1095,22 +1095,22 @@ Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 (work in progress), June 2020. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", draft-ietf-ace-oauth- params-13 (work in progress), April 2020. [I-D.ietf-cbor-7049bis] Bormann, C. and P. Hoffman, "Concise Binary Object - Representation (CBOR)", draft-ietf-cbor-7049bis-14 (work - in progress), June 2020. + Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work + in progress), September 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, .