--- 1/draft-ietf-ace-oscore-profile-15.txt 2021-01-28 09:13:15.900737623 -0800 +++ 2/draft-ietf-ace-oscore-profile-16.txt 2021-01-28 09:13:15.972739466 -0800 @@ -1,24 +1,24 @@ ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track L. Seitz -Expires: July 30, 2021 Combitech +Expires: August 1, 2021 Combitech G. Selander Ericsson AB M. Gunnarsson RISE - January 26, 2021 + January 28, 2021 OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework - draft-ietf-ace-oscore-profile-15 + draft-ietf-ace-oscore-profile-16 Abstract This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Status of This Memo @@ -29,21 +29,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 July 30, 2021. + This Internet-Draft will expire on August 1, 2021. Copyright Notice Copyright (c) 2021 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 @@ -74,23 +74,23 @@ 5. Secure Communication with AS . . . . . . . . . . . . . . . . 23 6. Discarding the Security Context . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9.1. ACE Profile Registry . . . . . . . . . . . . . . . . . . 26 9.2. OAuth Parameters Registry . . . . . . . . . . . . . . . . 26 9.3. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 27 9.4. OSCORE Security Context Parameters Registry . . . . . . . 27 9.5. CWT Confirmation Methods Registry . . . . . . . . . . . . 28 - 9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 28 + 9.6. JWT Confirmation Methods Registry . . . . . . . . . . . . 29 9.7. Expert Review Instructions . . . . . . . . . . . . . . . 29 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 31 Appendix A. Profile Requirements . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction This memo specifies a profile of the ACE framework [I-D.ietf-ace-oauth-authz]. In this profile, a client and a resource @@ -163,21 +163,23 @@ policy that is used as input to processing requests from those clients. This profile requires a client to retrieve an access token from the AS for the resource it wants to access on an RS, by sending an access token request to the token endpoint, as specified in section 5.8 of [I-D.ietf-ace-oauth-authz]. The access token request and response MUST be confidentiality-protected and ensure authenticity. This profile RECOMMENDS the use of OSCORE between client and AS, to reduce the number of libraries the client has to support, but other - protocols (such as TLS or DTLS) can be used as well. + protocols fulfilling the security requirements defined in section 5 + of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as + well. Once the client has retrieved the access token, it generates a nonce N1, defined in this specification (see Section 4.1.1). The client also generates its own OSCORE Recipient ID ID1 (see Section 3.1 of [RFC8613]), for use with the keying material associated to the RS. The client posts the token, N1 and its Recipient ID to the RS using the authz-info endpoint and mechanisms specified in section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor. When using this profile, the communication with the authz-info endpoint is not protected, except for update of access rights. @@ -1008,22 +1010,23 @@ information using the access token associated to the Security Context. The RS then must verify that the authorization information covers the resource and the action requested. 5. Secure Communication with AS As specified in the ACE framework (section 5.9 of [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client) and the AS communicates via the introspection or token endpoint. The use of CoAP and OSCORE ([RFC8613]) for this communication is - RECOMMENDED in this profile; other protocols (such as HTTP and DTLS - or TLS) MAY be used instead. + RECOMMENDED in this profile; other protocols fulfilling the security + requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such + as HTTP and DTLS or TLS) MAY be used instead. If OSCORE is used, the requesting entity and the AS are expected to have pre-established security contexts in place. How these security contexts are established is out of scope for this profile. Furthermore the requesting entity and the AS communicate through the introspection endpoint as specified in section 5.9 of [I-D.ietf-ace-oauth-authz] and through the token endpoint as specified in section 5.8 of [I-D.ietf-ace-oauth-authz]. 6. Discarding the Security Context