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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/