draft-ietf-ace-cwt-proof-of-possession-04.txt   draft-ietf-ace-cwt-proof-of-possession-05.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 10, 2019 RISE SICS Expires: May 13, 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 6, 2018 November 9, 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-04 draft-ietf-ace-cwt-proof-of-possession-05
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 10, 2019. This Internet-Draft will expire on May 13, 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 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Representations for Proof-of-Possession Keys . . . . . . . . 3 3. Representations for Proof-of-Possession Keys . . . . . . . . 3
3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4 3.1. Confirmation Claim . . . . . . . . . . . . . . . . . . . 4
3.2. Representation of an Asymmetric Proof-of-Possession Key . 5 3.2. Representation of an Asymmetric Proof-of-Possession Key . 5
3.3. Representation of an Encrypted Symmetric Proof-of- 3.3. Representation of an Encrypted Symmetric Proof-of-
Possession Key . . . . . . . . . . . . . . . . . . . . . 5 Possession Key . . . . . . . . . . . . . . . . . . . . . 5
3.4. Representation of a Key ID for a Proof-of-Possession Key 6 3.4. Representation of a Key ID for a Proof-of-Possession Key 6
3.5. Specifics Intentionally Not Specified . . . . . . . . . . 7 3.5. Specifics Intentionally Not Specified . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
6. Operational Considerations . . . . . . . . . . . . . . . . . 8 6. Operational Considerations . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. CBOR Web Token Claims Registration . . . . . . . . . . . 10 7.1. CBOR Web Token Claims Registration . . . . . . . . . . . 11
7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 10 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11
7.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 10 7.2. CWT Confirmation Methods Registry . . . . . . . . . . . . 11
7.2.1. Registration Template . . . . . . . . . . . . . . . . 10 7.2.1. Registration Template . . . . . . . . . . . . . . . . 11
7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 11 7.2.2. Initial Registry Contents . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Document History . . . . . . . . . . . . . . . . . . . . . . . . 13 Document History . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 [RFC7159] and JWTs
skipping to change at page 7, line 18 skipping to change at page 7, line 18
/exp/ 4 : 1361398824, /exp/ 4 : 1361398824,
/cnf/ 8 : { /cnf/ 8 : {
/kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad' /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
} }
} }
The content of the "kid" value is application specific. For The content of the "kid" value is application specific. For
instance, some applications may choose to use a cryptographic hash of instance, some applications may choose to use a cryptographic hash of
the public key value as the "kid" value. the public key value as the "kid" value.
Note that the use of a Key ID to identify a proof-of-possesion key
needs to be carefully circumscribed, as described below and in
Section 6. Where the Key ID is not a cryptographic value derived
from the key or where all of the parties involved are not validating
the cryptographic derivation, it is possible to get into situations
where the same Key ID is being used for multiple keys. The
implication of this is that a recipient may have multiple keys known
to it that have the same Key ID, and thus it might not know which
proof-of-possession key is associated with the CWT.
In the world of constrained Internet of Things (IoT) devices, there
is frequently a restriction on the size of Key IDs, either because of
table constraints or a desire to keep message sizes small. These
restrictions are going to protocol dependent. For example, DTLS can
use a Key ID of any size. However, if the key is being used with
COSE encrypted message, then the length of the key needs to be
minimized and may have a limit as small as one byte.
Note that the value of a Key ID is not always the same for different
parties. When sending a COSE encrypted message with a shared key,
the Key ID may be different on both sides of the conversation, with
the appropriate one being included in the message based on the
recipient of the message.
For symmetric keys, the Key ID is normally going to be generated by
the CWT issuer. This means that enforcing a rule that Key ID values
only match if CWTs have the same issuer works for matching Key IDs
between CWTs. In this case, the issuer can ensure that there are no
collisions between currently active symmetric keys for all CWTs that
it has issued. This allows for a recipient to use the pair of issuer
and Key ID for matching keys.
For asymmetric keys, the Key ID value is normally going to be
generated by the CWT recipient, thus the possibility of collisions is
greater. For instance, recipients might start by assigning a Key ID
of 0, given that Key IDs are frequently only needed to be unique and
meaningful to the recipient. This problem can be addressed in a
couple of different ways, depending on how the Key ID value is going
to be used:
o The issuer can assign a new unique Key ID the first time it sees
the key. Depending on the protocol being used, the new value may
then need to be transported to the presenter by the protocol used
to issue CWTs. In this case, the rule of requiring that the
issuer, Key ID pair be used for matching works.
o The issuer can use a different confirmation method if a collision
might be unavoidable.
o A recipient can decide not to use a CWT based on a created Key ID
if it does not fit the recipient's requirements.
o If an issuer is going to use the Key ID confirmation method and is
not going to guarantee that serial number uniqueness is going to
be preserved, the recipient needs to have that information
configured into it so that appropriate actions can be taken.
3.5. Specifics Intentionally Not Specified 3.5. Specifics Intentionally Not Specified
Proof of possession is often demonstrated by having the presenter Proof of possession is often demonstrated by having the presenter
sign a value determined by the recipient using the key possessed by sign a value determined by the recipient using the key possessed by
the presenter. This value is sometimes called a "nonce" or a the presenter. This value is sometimes called a "nonce" or a
"challenge". "challenge".
The means of communicating the nonce and the nature of its contents The means of communicating the nonce and the nature of its contents
are intentionally not described in this specification, as different are intentionally not described in this specification, as different
protocols will communicate this information in different ways. protocols will communicate this information in different ways.
skipping to change at page 13, line 26 skipping to change at page 14, line 41
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 ]]
-05
o Added text suggested by Jim Schaad describing considerations when
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. 8 change blocks. 
21 lines changed or deleted 82 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/