Network Working Group J. Schaad Internet-Draft August Cellars Intended status: Experimental October 22, 2018 Expires: April 25, 2019 Use of a CWT identifier as a Confirmation Method draft-schaad-cnf-cwt-id-00 Abstract TBD Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 April 25, 2019. Copyright Notice Copyright (c) 2018 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Schaad Expires April 25, 2019 [Page 1] Internet-Draft CWT ID Confirmation October 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. CWT Id Confirmation Method . . . . . . . . . . . . . . . . . 3 4. CWT Id in AS Response . . . . . . . . . . . . . . . . . . . . 3 5. Processing Rules for the Issuer of a CWT Id Confirmation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Processing Rules for the CWT Id Confirmation Method . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction In many cases an authorization in the form of a COSE Web Token (CWT) [RFC8392] will be issued in the ACE OAuth [I-D.ietf-ace-oauth-authz] framework with a minimal set of privileges and a Proof-of-Possession claim [I-D.ietf-ace-cwt-proof-of-possession]. It may then become necessary to issue a new token for a shorter period with more capabilities, but use the same information for validation. In these cases it makes sense to issue a new authorization token which refers the the first token to provide the additional capabilities. This document defines a new confirmation type that allows this type of referencing to be done. This differs from the refresh token in that the new token will be limited to the duration of the existing CWT, while a new POP CWT would be issued when using a refresh token. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology o "Relying Party" is used in this document to refer to the party which is relying on the contents of a CWT in order to make a security decision. In other OAuth documents, this is normally referred to as the XXXXXX. Schaad Expires April 25, 2019 [Page 2] Internet-Draft CWT ID Confirmation October 2018 o "Referenced CWT" is used to denote the CWT which is referred to or referenced by a referencing CWT. The referenced CWT has a confirmation type with the POP keying information in it. o "Referencing CWT" is used to denote the CWT which is making a reference to a second CWT. The referencing CWT contains the confirmation type defined in this document. 3. CWT Id Confirmation Method The CWT Id confirmation method is identified by TBD1 in the 'cnf' element (defined in [I-D.ietf-ace-cwt-proof-of-possession]. For use in documentation the string value of 'cwtid' is to be used to refer to this confirmation type. The CWT Id confirmation method uses the type of CBOR map and has the following fields: o Issuer is an optional field in the map. If present the issuer field contains the 'iss' field of CWT which is being referenced. If absent, the issuer is the same entity which issued the referencing CWT. When encoded, this field uses TBD2 as the map key. o CWT Id is a required field in the map. The field contains the 'cwtid' field of the referenced CWT. When encoded, this field uses TBD3 as the map key. An example of what this would look like is: / cnf /: { / cwtid /: 'CWTID 1234', / iss /: "Entry-Level AS" } 4. CWT Id in AS Response Since the CWT Id is currently only provided to the RS as part of the token, for an AS which supports this option the CWT Id additionally needs to be provided to the Client. This document therefore defines two new fields to go into C-AS response messages: "iss" provides the issuer name of the CWT. This field is only present for an AS which would allow a second AS to refer to the CWT. "cwtid" contains the CWT Id for the issued token. Schaad Expires April 25, 2019 [Page 3] Internet-Draft CWT ID Confirmation October 2018 5. Processing Rules for the Issuer of a CWT Id Confirmation Method When an AS is going to issue a CWT it MUST perform the following steps or their equivalent: 1. If the issued CWT will refer to a CWT issued by a different AS, the issuing AS MUST be configured to permit this. 2. The AS MUST validate that the entity for which this CWT is being issued for is the same entity that is the subject of the referenced CWT. This can be done by causing the client to perform a POP operation with the referenced CWTs POP key information or by querying the AS which issued the referenced CWT. If the same AS is being used for both CWTs, then the AS can consult a database of clients and CWTs to check for identity matching. 3. The issued CWT should refer to the original POP CWT. The chain of trust SHOULD NOT be transitive through another CWT. 6. Processing Rules for the CWT Id Confirmation Method When a relying party receives a referencing CWT it MUST perform the following steps or their equivalent as part of making a security decision: 1. The referencing CWT MUST have the authentication checked on it. If the authentication fails, the CWT MUST be rejected. 2. If the CWT Id confirmation type contains an issuer field, configuration information MUST be checked that the referencing CWT issuer is permitted to use the referenced CWT issuer. If the reference is not permitted, then the CWT MUST be rejected. 3. If the referenced CWT is expired, the referencing CWT MUST be rejected. 4. The claims in the referenced CWT are copied from the referenced CWT to the referencing CWT if the claim does not exist in the referencing CWT. 5. The modified CWT is then processed in a normal manner. 7. Security Considerations As the security of the set of CWTs is going rest on the underlying POP CWT, loss of the key will allow any CWT which references the Schaad Expires April 25, 2019 [Page 4] Internet-Draft CWT ID Confirmation October 2018 orignal CWT to be used by a third party. All entities which have the secret portion of the key need to protect that portion of the key. The use of this feature assumes a specific model of evaluating the rules for access control. Specifically, it assumes that if there are multiple access tokens, satisfying the conditions for any of the tokens means that access is going to be granted. This model is in contrast to one where if any of the access tokens was a deny, then access to to the resource would be denied. 8. IANA Considerations There are some items that need to be registered. Figure out what they are and put them here. 9. Normative References [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-03 (work in progress), June 2018. [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-16 (work in progress), October 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . Author's Address Schaad Expires April 25, 2019 [Page 5] Internet-Draft CWT ID Confirmation October 2018 Jim Schaad August Cellars Email: ietf@augustcellars.com Schaad Expires April 25, 2019 [Page 6]