--- 1/draft-ietf-ace-cwt-proof-of-possession-03.txt 2018-11-06 01:13:25.014919166 -0800 +++ 2/draft-ietf-ace-cwt-proof-of-possession-04.txt 2018-11-06 01:13:25.046919932 -0800 @@ -1,25 +1,25 @@ ACE M. Jones Internet-Draft Microsoft Intended status: Standards Track L. Seitz -Expires: December 31, 2018 RISE SICS +Expires: May 10, 2019 RISE SICS G. Selander Ericsson AB S. Erdtman Spotify H. Tschofenig ARM Ltd. - June 29, 2018 + November 6, 2018 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) - draft-ietf-ace-cwt-proof-of-possession-03 + draft-ietf-ace-cwt-proof-of-possession-04 Abstract This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs. @@ -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 December 31, 2018. + This Internet-Draft will expire on May 10, 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 @@ -235,22 +235,21 @@ subsequently be encrypted for use in the "Encrypted_COSE_Key" member: { /kty/ 1 : /Symmetric/ 4, /alg/ 3 : /HMAC256/ 5, /k/ -1 : h'6684523ab17337f173500e5728c628547cb37df e68449c65f885d1b73b49eae1A0B0C0D0E0F10' } The COSE_Key representation is used as the plaintext when encrypting - the key. The COSE_Key could, for instance, be encrypted using a - COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm. + the key. The following example CWT Claims Set of a CWT (using CBOR diagnostic notation, with linebreaks for readability) illustrates the use of an encrypted symmetric key as the "Encrypted_COSE_Key" member value: { /iss/ 1 : "coaps://server.example.com", /sub/ 2 : "24400320", /aud/ 3: "s6BhdRkqt3", /exp/ 4 : 1311281970, @@ -316,24 +315,22 @@ 4. Security Considerations All of the security considerations that are discussed in [RFC8392] also apply here. In addition, proof of possession introduces its own unique security issues. Possessing a key is only valuable if it is kept secret. Appropriate means must be used to ensure that unintended parties do not learn private key or symmetric key values. Applications utilizing proof of possession SHOULD also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it - provides additional protections. Proof of possession can be used by - recipients to reject messages from unauthorized senders. Audience - restriction can be used by recipients to reject messages intended for - different recipients. + provides additional protections. Audience restriction can be used by + recipients to reject messages intended for different recipients. A recipient might not understand the "cnf" claim. Applications that require the proof-of-possession keys communicated with it to be understood and processed MUST ensure that the parts of this specification that they use are implemented. CBOR Web Tokens with proof-of-possession keys are used in context of an architecture, such as the ACE OAuth Framework [I-D.ietf-ace-oauth-authz], in which protocols are used by a presenter to request these tokens and to subsequently use them with @@ -482,30 +478,31 @@ preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required. 7.2.2. Initial Registry Contents o Confirmation Method Name: "COSE_Key" o Confirmation Method Description: COSE_Key Representing Public Key o JWT Confirmation Method Name: "jwk" o Confirmation Key: 1 - o Confirmation Value Type(s): map + o Confirmation Value Type(s): COSE_Key structure o Change Controller: IESG o Specification Document(s): Section 3.2 of [[ this document ]] o Confirmation Method Name: "Encrypted_COSE_Key" o Confirmation Method Description: Encrypted COSE_Key o JWT Confirmation Method Name: "jwe" o Confirmation Key: 2 - o Confirmation Value Type(s): array (with an optional COSE_Encrypt - or COSE_Encrypt0 tag) + o Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0 + structure (with an optional corresponding COSE_Encrypt or + COSE_Encrypt0 tag) o Change Controller: IESG o Specification Document(s): Section 3.3 of [[ this document ]] o Confirmation Method Name: "kid" o Confirmation Method Description: Key Identifier o JWT Confirmation Method Name: "kid" o Confirmation Key: 3 o Confirmation Value Type(s): binary string o Change Controller: IESG o Specification Document(s): Section 3.4 of [[ this document ]] @@ -543,22 +540,22 @@ [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . 8.2. Informative References [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-12 - (work in progress), May 2018. + Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16 + (work in progress), October 2018. [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token @@ -586,20 +583,25 @@ Thanks to the following people for their reviews of the specification: Roman Danyliw, Michael Richardson, and Jim Schaad. Ludwig Seitz and Goeran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. Document History [[ to be removed by the RFC Editor before publication as an RFC ]] + -04 + + o Addressed additional WGLC comments by Jim Schaad and Roman + Danyliw. + -03 o Addressed review comments by Jim Schaad, see https://www.ietf.org/ mail-archive/web/ace/current/msg02798.html o Removed unnecessary sentence in the introduction regarding the use any strings that could be case-sensitive. o Clarified the terms Presenter and Recipient.