draft-ietf-ace-cwt-proof-of-possession-05.txt   draft-ietf-ace-cwt-proof-of-possession-06.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: May 13, 2019 RISE SICS Expires: August 25, 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.
November 9, 2018 February 21, 2019
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-05 draft-ietf-ace-cwt-proof-of-possession-06
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 May 13, 2019. This Internet-Draft will expire on August 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 50 skipping to change at page 2, line 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This specification describes how a CBOR Web Token (CWT) [RFC8392] can This specification describes how a CBOR Web Token (CWT) [RFC8392] can
declare that the presenter of the CWT possesses a particular proof- declare that the presenter of the CWT possesses a particular proof-
of-possession (PoP) key. Proof of possession of a key is also of-possession (PoP) key. Proof of 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)" [RFC7800], but using CBOR Semantics for JSON Web Tokens (JWTs)" [RFC7800], but using CBOR
[RFC7049] and CWTs [RFC8392] rather than JSON [RFC7159] and JWTs [RFC7049] and CWTs [RFC8392] rather than JSON [RFC8259] and JWTs
[JWT]. [JWT].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
recipient using COSE_Encrypt or COSE_Encrypt0. recipient using COSE_Encrypt or COSE_Encrypt0.
The following example (using CBOR diagnostic notation, with The following example (using CBOR diagnostic notation, with
linebreaks for readability) illustrates a symmetric key that could linebreaks for readability) illustrates a symmetric key that could
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' e68449c65f885d1b73b49eae1'
} }
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 key.
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,
/iat/ 5 : 1311280970, /iat/ 5 : 1311280970,
/cnf/ 8 : { /cnf/ 8 : {
/COSE_Encrypt0/ 2 : [ /COSE_Encrypt0/ 2 : [
/protected header / h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/, /protected header/ h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
/unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'}, /unprotected header/ { / iv / 5: h'636898994FF0EC7BFCF6D3F95B'},
/ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E /ciphertext/ h'0573318A3573EB983E55A7C2F06CADD0796C9E584F1D0E3E
A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F' A8C5B052592A8B2694BE9654F0431F38D5BBC8049FA7F13F'
] ]
} }
} }
The example above was generated with the key: The example above was generated with the key:
h'6162630405060708090a0b0c0d0e0f10' h'6162630405060708090a0b0c0d0e0f10'
skipping to change at page 10, line 33 skipping to change at page 10, line 33
are identified by Key IDs, care must be taken to keep the keys for are identified by Key IDs, care must be taken to keep the keys for
the different kinds of CWTs segregated so that an attacker cannot the different kinds of CWTs segregated so that an attacker cannot
cause the wrong PoP key to be used by using a valid Key ID for the cause the wrong PoP key to be used by using a valid Key ID for the
wrong kind of CWT. wrong kind of CWT.
7. IANA Considerations 7. IANA Considerations
The following registration procedure is used for all the registries The following registration procedure is used for all the registries
established by this specification. established by this specification.
Values are registered on a Specification Required [RFC5226] basis Values are registered on a Specification Required [RFC8126] basis
after a three-week review period on the cwt-reg-review@ietf.org after a three-week review period on the cwt-reg-review@ietf.org
mailing list, on the advice of one or more Designated Experts. mailing list, on the advice of one or more Designated Experts.
However, to allow for the allocation of values prior to publication, However, to allow for the allocation of values prior to publication,
the Designated Experts may approve registration once they are the Designated Experts may approve registration once they are
satisfied that such a specification will be published. [[ Note to satisfied that such a specification will be published. [[ Note to
the RFC Editor: The name of the mailing list should be determined in the RFC Editor: The name of the mailing list should be determined in
consultation with the IESG and IANA. Suggested name: cwt-reg- consultation with the IESG and IANA. Suggested name: cwt-reg-
review@ietf.org. ]] review@ietf.org. ]]
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
skipping to change at page 13, line 18 skipping to change at page 13, line 18
[IANA.CWT.Claims] [IANA.CWT.Claims]
IANA, "CBOR Web Token Claims", IANA, "CBOR Web Token Claims",
<http://www.iana.org/assignments/cwt>. <http://www.iana.org/assignments/cwt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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-16 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-21
(work in progress), October 2018. (work in progress), February 2019.
[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
(JWT)", RFC 7519, DOI 10.17487/RFC7159, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005, 2.0-os, March 2005,
<http://docs.oasis-open.org/security/saml/v2.0/>. <http://docs.oasis-open.org/security/saml/v2.0/>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
Acknowledgements Acknowledgements
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 ]]
-06
o Corrected nits identified by Roman Danyliw.
-05 -05
o Added text suggested by Jim Schaad describing considerations when o Added text suggested by Jim Schaad describing considerations when
using the Key ID confirmation method. using the Key ID confirmation method.
-04 -04
o Addressed additional WGLC comments by Jim Schaad and Roman o Addressed additional WGLC comments by Jim Schaad and Roman
Danyliw. 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.
o Clarified text about the confirmation claim. o Clarified text about the confirmation claim.
 End of changes. 18 change blocks. 
22 lines changed or deleted 27 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/