[Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
We should be consistent across examples about whether the use of CBOR
diagnostic notation also requires a disclaimer about "with linebreaks
for readability".
Section 2
Presenter
Party that proves possession of a private key (for asymmetric key
cryptography) or secret key (for symmetric key cryptography) to a
recipient.
nit: it might be worth either capitalizing Recipient to point to the
following item more clearly, or specifying "recipient of a CWT" for
parallelism with Recipient.
(If we do the former we should capitalize Presenter in the following
definition. But since we don't use the capitalized terms throughout the
text, it wouldn't be my own preference.)
Section 3.2
This example key expired in 2013. While the example will "always" be
expired for an archival document, it might be worth making it more
timely with respect to the publication date. (This holds for basically
all time values in the document's examples.)
Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
[I did not check that the example x and y coordinates are in fact points
on P256.]
The "COSE_Key" member MAY also be used for a COSE_Key representing a
symmetric key, provided that the CWT is encrypted so that the key is
not revealed to unintended parties. The means of encrypting a CWT is
explained in [RFC8392]. If the CWT is not encrypted, the symmetric
key MUST be encrypted as described in Section 3.3.
It's hard for me to escape the conclusion that this paragraph needs to
be a dedicated section with a bit more discussion about how exactly this
usage is performed and encoded.
Section 3.3
Is the /HMAC256/ the conventional diagnostic notation for alg value 5
(noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
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,
/iat/ 5 : 1311280970,
/cnf/ 8 : {
/COSE_Encrypt0/ 2 : [
Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
[I did not validate the COSE_Encrypt0 output]
Section 3.4
{
/iss/ 1 : "coaps://server.example.com",
/aud/ 3 : "coaps://client.example.org",
Is it in any way confusing to use client.example.org as opposed to, say,
resource.example.org as the audience?
/exp/ 4 : 1361398824,
/cnf/ 8 : {
/kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
/kid/ in the 'cnf' map has key 3, not 2.
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
I don't think this quite covers the needed properties, since we also
need some assurance that all parties are interpreting the kid value in
the same way. It may be possible to construct such a scenario via an
attacker replaying a stolen token or even just inadvertent confusion by
some party (quite plausible when we consider scenarios that involve the
same key being described by different 'kid' values in messages with
different recipients). In particular, if the situation arises where an
attacker is able to choose the 'kid' value that will be used, they could
deliberately cause a collision with a legitimate value used by some
other party.
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
nit: "going to be" or maybe even just "are protocol dependent".
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.
nit: is this "length of the key" or "length of the key ID"?
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.
While this recipient-dependence is probably unavoidable (as the
requisite namespacing would use more space on the wire than is
reasonable for many applications), it does merit some security
considerations text, noting that such messages are context-dependant and
could be misinterpreted if presented in a different context.
Audience restrictions, as m
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Comments inline.
-Original Message-
From: Benjamin Kaduk
Sent: Tuesday, July 30, 2019 8:56 AM
To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
Cc: ace@ietf.org
Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06
We should be consistent across examples about whether the use of CBOR
diagnostic notation also requires a disclaimer about "with linebreaks for
readability".
[JLS] I don't believe that this disclaimer needs to be present. Unlike the
JSON document where what is being presented is in fact JSON, what is being
presented here is simply a more user friendly readable version of the binary
data. (A different question would be if the hex should be presented but
that is not what the ACE group is doing in general.)
Section 2
Presenter
Party that proves possession of a private key (for asymmetric key
cryptography) or secret key (for symmetric key cryptography) to a
recipient.
nit: it might be worth either capitalizing Recipient to point to the
following item more clearly, or specifying "recipient of a CWT" for
parallelism with Recipient.
(If we do the former we should capitalize Presenter in the following
definition. But since we don't use the capitalized terms throughout the
text, it wouldn't be my own preference.)
Section 3.2
This example key expired in 2013. While the example will "always" be
expired for an archival document, it might be worth making it more timely
with respect to the publication date. (This holds for basically all time
values in the document's examples.)
Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
[I did not check that the example x and y coordinates are in fact points on
P256.]
The "COSE_Key" member MAY also be used for a COSE_Key representing a
symmetric key, provided that the CWT is encrypted so that the key is
not revealed to unintended parties. The means of encrypting a CWT is
explained in [RFC8392]. If the CWT is not encrypted, the symmetric
key MUST be encrypted as described in Section 3.3.
It's hard for me to escape the conclusion that this paragraph needs to be a
dedicated section with a bit more discussion about how exactly this usage is
performed and encoded.
Section 3.3
Is the /HMAC256/ the conventional diagnostic notation for alg value 5
(noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
[JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is
descriptive. I believe that this is completely consistent in RFC 8152.
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,
/iat/ 5 : 1311280970,
/cnf/ 8 : {
/COSE_Encrypt0/ 2 : [
Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
[I did not validate the COSE_Encrypt0 output]
Section 3.4
{
/iss/ 1 : "coaps://server.example.com",
/aud/ 3 : "coaps://client.example.org",
Is it in any way confusing to use client.example.org as opposed to, say,
resource.example.org as the audience?
/exp/ 4 : 1361398824,
/cnf/ 8 : {
/kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
/kid/ in the 'cnf' map has key 3, not 2.
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
I don't think this quite covers the needed properties, since we also need
some assurance that all parties are interpreting the kid value in the same
way. It may be possible to construct such a scenario via an attacker
replaying a stolen token or even just inadvertent confusion by some party
(quite plausible when we consider scenarios that involve the same key being
described by different 'kid' values in messages with different recipients).
In particular, if the situation arises where an attacker is able to choose
the 'kid' value that will be used, they could deliberately cause a collision
with a legitimate value used by some other party.
[JLS] I don't agree with that. It should be assumed by all implementations
that there will be collisions between kid values. Except in very specific
cases such as all of the kids being assigned by a group keying server, there
is no way for the assumption of a single kid value being assigned once on a
recipient basis will ever be a true statement.
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 des
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
On Jul 30, 2019, at 19:10, Jim Schaad wrote: > From: Benjamin Kaduk > > We should be consistent across examples about whether the use of CBOR > diagnostic notation also requires a disclaimer about "with linebreaks for > readability". > > [JLS] I don't believe that this disclaimer needs to be present. Unlike the > JSON document where what is being presented is in fact JSON, what is being > presented here is simply a more user friendly readable version of the binary > data. Right. But it is still useful for the reader to be able to look up how that notation works. CBOR diagnostic notation was originally defined in Section 6 of RFC 7049, precisely for the purpose of discussing CBOR data items in a human-readable way. Many current documents make use of some extensions of the original diagnostic notation, such as the use of whitespace in hex strings. These extensions are documented in Appendix G of RFC 8610, Extended Diagnostic Notation (EDN). This is what always should be referenced, and then no disclaimer is needed. Grüße, Carsten PS.: > (A different question would be if the hex should be presented but > that is not what the ACE group is doing in general.) I don’t think that showing a hex representation of the encoded bytes is needed either; CBOR should be well-known enough to readers of this document via CWT already. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Noting that there are several points that Jim left to the authors to reply
to, also inline...
On Tue, Jul 30, 2019 at 10:10:12AM -0700, Jim Schaad wrote:
> Comments inline.
>
> -Original Message-
> From: Benjamin Kaduk
> Sent: Tuesday, July 30, 2019 8:56 AM
> To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06
>
> We should be consistent across examples about whether the use of CBOR
> diagnostic notation also requires a disclaimer about "with linebreaks for
> readability".
>
> [JLS] I don't believe that this disclaimer needs to be present. Unlike the
> JSON document where what is being presented is in fact JSON, what is being
> presented here is simply a more user friendly readable version of the binary
> data. (A different question would be if the hex should be presented but
> that is not what the ACE group is doing in general.)
Taking it out is fine by me; I just want us to be internally consistent :)
> Section 2
>
>Presenter
> Party that proves possession of a private key (for asymmetric key
> cryptography) or secret key (for symmetric key cryptography) to a
> recipient.
>
> nit: it might be worth either capitalizing Recipient to point to the
> following item more clearly, or specifying "recipient of a CWT" for
> parallelism with Recipient.
> (If we do the former we should capitalize Presenter in the following
> definition. But since we don't use the capitalized terms throughout the
> text, it wouldn't be my own preference.)
>
> Section 3.2
>
> This example key expired in 2013. While the example will "always" be
> expired for an archival document, it might be worth making it more timely
> with respect to the publication date. (This holds for basically all time
> values in the document's examples.)
>
> Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
>
> [I did not check that the example x and y coordinates are in fact points on
> P256.]
>
>The "COSE_Key" member MAY also be used for a COSE_Key representing a
>symmetric key, provided that the CWT is encrypted so that the key is
>not revealed to unintended parties. The means of encrypting a CWT is
>explained in [RFC8392]. If the CWT is not encrypted, the symmetric
>key MUST be encrypted as described in Section 3.3.
>
> It's hard for me to escape the conclusion that this paragraph needs to be a
> dedicated section with a bit more discussion about how exactly this usage is
> performed and encoded.
>
> Section 3.3
>
> Is the /HMAC256/ the conventional diagnostic notation for alg value 5
> (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
>
> [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is
> descriptive. I believe that this is completely consistent in RFC 8152.
Er, I'm not sure what you're saying is best to use in the diagnostic
notation.
>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,
>/iat/ 5 : 1311280970,
>/cnf/ 8 : {
>/COSE_Encrypt0/ 2 : [
>
> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
>
> [I did not validate the COSE_Encrypt0 output]
>
> Section 3.4
>
> {
> /iss/ 1 : "coaps://server.example.com",
> /aud/ 3 : "coaps://client.example.org",
>
> Is it in any way confusing to use client.example.org as opposed to, say,
> resource.example.org as the audience?
>
> /exp/ 4 : 1361398824,
> /cnf/ 8 : {
> /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
>
> /kid/ in the 'cnf' map has key 3, not 2.
>
>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
>
> I don't think this quite covers the needed properties, since we also need
> some assurance that all parties are interpreting the kid value in the same
> way. It may be possible to construct such a scenario via an attacker
> replaying a stolen token or even just inadvertent confusion by some party
> (quite plausible when we consider scenarios that involve the same key being
> described by different 'kid' values in messages with different recipients).
> In particular, if the situation arises where an attacker is able to choose
> the 'kid' value that will be used, they could deliberately cause a collision
> with a legitimate value used by some other party.
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
I have deleted things I am not replying to.
-Original Message-
From: Benjamin Kaduk
Sent: Tuesday, July 30, 2019 3:03 PM
To: Jim Schaad
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06
Noting that there are several points that Jim left to the authors to reply
to, also inline...
On Tue, Jul 30, 2019 at 10:10:12AM -0700, Jim Schaad wrote:
> Comments inline.
>
> -Original Message-
> From: Benjamin Kaduk
> Sent: Tuesday, July 30, 2019 8:56 AM
> To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-cwt-proof-of-possession-06
>
> Section 3.3
>
> Is the /HMAC256/ the conventional diagnostic notation for alg value 5
> (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
>
> [JLS] HMAC 256/256 is the algorithm name while HMAC w/ SHA-256 is
> descriptive. I believe that this is completely consistent in RFC 8152.
Er, I'm not sure what you're saying is best to use in the diagnostic
notation.
[JLS] I would use the algorithm name if it was up to me. That is what I did
in the COSE documents.
> Section 3.4
>
> {
> /iss/ 1 : "coaps://server.example.com",
> /aud/ 3 : "coaps://client.example.org",
>
> Is it in any way confusing to use client.example.org as opposed to,
> say, resource.example.org as the audience?
>
> /exp/ 4 : 1361398824,
> /cnf/ 8 : {
> /kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
>
> /kid/ in the 'cnf' map has key 3, not 2.
>
>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
>
> I don't think this quite covers the needed properties, since we also
> need some assurance that all parties are interpreting the kid value in
> the same way. It may be possible to construct such a scenario via an
> attacker replaying a stolen token or even just inadvertent confusion
> by some party (quite plausible when we consider scenarios that involve
> the same key being described by different 'kid' values in messages with
different recipients).
> In particular, if the situation arises where an attacker is able to
> choose the 'kid' value that will be used, they could deliberately
> cause a collision with a legitimate value used by some other party.
>
> [JLS] I don't agree with that. It should be assumed by all
implementations
> that there will be collisions between kid values. Except in very
> specific cases such as all of the kids being assigned by a group
> keying server, there is no way for the assumption of a single kid
> value being assigned once on a recipient basis will ever be a true
statement.
Thanks; that's a good point, and this jogs loose some of the previous
discussions we had on the list about key IDs. (Looking back at the quoted
text from the document, I wonder if all readers will understand that
"cryptographic value derived from the key" needs to include enough bits of
cryptographic output to make the chance of brute-force/random collision
acceptably small.) It does still seem potentially useful to have agreement
among parties as to whether key IDs are arbitrary identifiers or
cryptographically derived, though my above discussion about scenarios and
consequences is flawed as you note.
[JLS] Yes I agree that it could do better about talking about lengths for
the purpose of non-collision. I don't think that I care much about the
issue of brute-forcing as even if there is a faked kid, the shared secret
would still need to be determined which is more difficult. And as below, I
don't think this is ever going to be a very big issue for the IoT world as
long enough kid values collides with as small as possible messages.
>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
>
> Section 5
>
> This sort of correlation can occur even for subsequent connections
> between the same two parties if observed by a passive observer (e.g.,
> in the case of a mobile client that changes location). I forget if we
> have strong enough guarantees on the use of transport-level encryption
> that would prevent such CWTs from being observed in this fashion.
>
> [JLS] No we don't. Most of the time we are sending CWTs in the clear
> and not over a transport-level encrypted channel.
I don't propose that we add or suggest remediation measures, but do think we
should
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Hello Ben,
thank you for your review. Comments inline.
@co-authors: Please check if you agree with my proposed resolutions.
/Ludwig
On 30/07/2019 17:56, Benjamin Kaduk wrote:
We should be consistent across examples about whether the use of CBOR
diagnostic notation also requires a disclaimer about "with linebreaks
for readability".
As far as I gather from the comments (especially from Carsten), we'd
solve this by referencing section 6 of RFC 7049. I will consult with my
co-authors, but I think this is the right solution.
Section 2
Presenter
Party that proves possession of a private key (for asymmetric key
cryptography) or secret key (for symmetric key cryptography) to a
recipient.
nit: it might be worth either capitalizing Recipient to point to the
following item more clearly, or specifying "recipient of a CWT" for
parallelism with Recipient.
(If we do the former we should capitalize Presenter in the following
definition. But since we don't use the capitalized terms throughout the
text, it wouldn't be my own preference.)
Ok I'll go for "recipient of a CWT"
Section 3.2
This example key expired in 2013. While the example will "always" be
expired for an archival document, it might be worth making it more
timely with respect to the publication date. (This holds for basically
all time values in the document's examples.)
Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
[I did not check that the example x and y coordinates are in fact points
on P256.]
I agree this should be updated.
The "COSE_Key" member MAY also be used for a COSE_Key representing a
symmetric key, provided that the CWT is encrypted so that the key is
not revealed to unintended parties. The means of encrypting a CWT is
explained in [RFC8392]. If the CWT is not encrypted, the symmetric
key MUST be encrypted as described in Section 3.3.
It's hard for me to escape the conclusion that this paragraph needs to
be a dedicated section with a bit more discussion about how exactly this
usage is performed and encoded.
This mirrors the corresponding procedure in RFC 7800. Would it be OK to
just refer to that document
(https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
Section 3.3
Is the /HMAC256/ the conventional diagnostic notation for alg value 5
(noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
I agree with Jim's suggestion to use HMAC256/256
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,
/iat/ 5 : 1311280970,
/cnf/ 8 : {
/COSE_Encrypt0/ 2 : [
Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
[I did not validate the COSE_Encrypt0 output]
COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
is not. We'd have to define it or write an explanatory comment.
Section 3.4
{
/iss/ 1 : "coaps://server.example.com",
/aud/ 3 : "coaps://client.example.org",
Is it in any way confusing to use client.example.org as opposed to, say,
resource.example.org as the audience?
I agree, and issuer feels like it should be "as.example.com".
/exp/ 4 : 1361398824,
/cnf/ 8 : {
/kid/ 2 : h'dfd1aa976d8d4575a0fe34b96de2bfad'
/kid/ in the 'cnf' map has key 3, not 2.
Will fix.
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
I don't think this quite covers the needed properties, since we also
need some assurance that all parties are interpreting the kid value in
the same way. It may be possible to construct such a scenario via an
attacker replaying a stolen token or even just inadvertent confusion by
some party (quite plausible when we consider scenarios that involve the
same key being described by different 'kid' values in messages with
different recipients). In particular, if the situation arises where an
attacker is able to choose the 'kid' value that will be used, they could
deliberately cause a collision with a legitimate value used by some
other party.
I will go with you suggestion (later in the discussion) to add some text
that implementers should expect kid collisions.
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 siz
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
On Aug 12, 2019, at 14:08, Ludwig Seitz wrote: > > As far as I gather from the comments (especially from Carsten), we'd solve > this by referencing section 6 of RFC 7049. I will consult with my co-authors, > but I think this is the right solution. That is not what I said. Grüße, Carsten signature.asc Description: Message signed with OpenPGP ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
On Mon, Aug 12, 2019 at 02:08:12PM +0200, Ludwig Seitz wrote:
> Hello Ben,
>
> thank you for your review. Comments inline.
>
> @co-authors: Please check if you agree with my proposed resolutions.
>
> /Ludwig
>
> On 30/07/2019 17:56, Benjamin Kaduk wrote:
> > We should be consistent across examples about whether the use of CBOR
> > diagnostic notation also requires a disclaimer about "with linebreaks
> > for readability".
>
> As far as I gather from the comments (especially from Carsten), we'd
> solve this by referencing section 6 of RFC 7049. I will consult with my
> co-authors, but I think this is the right solution.
I think Carsten's followup refers to
https://mailarchive.ietf.org/arch/msg/ace/y_fPgWe-m8B2OpJChQ1qhoURuPU which
says to refer to RFC 8610 (or Appendix G thereof). And to be clear, my
original point was just that we cannot have some examples say "with
linebreaks for readability" and some not, within the same document, but I
did not attempt to propose which variant to unify to.
> >
> > Section 2
> >
> > Presenter
> >Party that proves possession of a private key (for asymmetric key
> >cryptography) or secret key (for symmetric key cryptography) to a
> >recipient.
> >
> > nit: it might be worth either capitalizing Recipient to point to the
> > following item more clearly, or specifying "recipient of a CWT" for
> > parallelism with Recipient.
> > (If we do the former we should capitalize Presenter in the following
> > definition. But since we don't use the capitalized terms throughout the
> > text, it wouldn't be my own preference.)
> >
> Ok I'll go for "recipient of a CWT"
>
> > Section 3.2
> >
> > This example key expired in 2013. While the example will "always" be
> > expired for an archival document, it might be worth making it more
> > timely with respect to the publication date. (This holds for basically
> > all time values in the document's examples.)
> >
> > Value 2 for 'kty' should have diagnostic notation /EC2/, not /EC/.
> >
> > [I did not check that the example x and y coordinates are in fact points
> > on P256.]
>
> I agree this should be updated.
>
>
> >
> > The "COSE_Key" member MAY also be used for a COSE_Key representing a
> > symmetric key, provided that the CWT is encrypted so that the key is
> > not revealed to unintended parties. The means of encrypting a CWT is
> > explained in [RFC8392]. If the CWT is not encrypted, the symmetric
> > key MUST be encrypted as described in Section 3.3.
> >
> > It's hard for me to escape the conclusion that this paragraph needs to
> > be a dedicated section with a bit more discussion about how exactly this
> > usage is performed and encoded.
> >
>
> This mirrors the corresponding procedure in RFC 7800. Would it be OK to
> just refer to that document
> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
(Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in
the opposite order.)
Well, I still wouldn't like it. But I don't think I have grounds to block
the document from advancing if you just refer back to JWT.
>
> > Section 3.3
> >
> > Is the /HMAC256/ the conventional diagnostic notation for alg value 5
> > (noting that RFC 8152 calls it both "HMAC256/256" and "HMAC w/ SHA-256")?
> >
>
> I agree with Jim's suggestion to use HMAC256/256
Works for me. (This was an honest question, as opposed to those other
times when I think I know the answer already but want to leave open the
possibility of being wrong.)
>
> > 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,
> > /iat/ 5 : 1311280970,
> > /cnf/ 8 : {
> > /COSE_Encrypt0/ 2 : [
> >
> > Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
> >
> > [I did not validate the COSE_Encrypt0 output]
> >
>
> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
> is not. We'd have to define it or write an explanatory comment.
Maybe I'm confused about how the diagnostic notation works, but the
top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
iss/sub/aud/etc. in the preceding notation. If the rules are different for
map keys whose corresponding values are themselves structured data types,
then I should just unconfuse myself and we can move on with things...
>
> > Section 3.4
> >
> > {
> >/iss/ 1 : "coaps://server.example.com",
> >/aud/ 3 : "coaps://client.example.org",
> >
> > Is it in any way confusing to use client.example.org as opposed to, say,
> > resource.example.org as the audience?
>
> I agree, and issuer feels like it should be "as.example.com".
>
> >
> >/e
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
On 12/08/2019 23:59, Carsten Bormann wrote: On Aug 12, 2019, at 14:08, Ludwig Seitz wrote: As far as I gather from the comments (especially from Carsten), we'd solve this by referencing section 6 of RFC 7049. I will consult with my co-authors, but I think this is the right solution. That is not what I said. Grüße, Carsten Sorry, hasty copy-paste of the wrong reference (the right one came later in your email: Appendix G of RFC 8610). I blame Monday morning after the holidays ... /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Hi Ben,
fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24
(waiting for Mike to double-check and merge them).
As for those that are still open, comments are inline.
/Ludwig
On 13/08/2019 01:15, Benjamin Kaduk wrote:
The "COSE_Key" member MAY also be used for a COSE_Key representing a
symmetric key, provided that the CWT is encrypted so that the key is
not revealed to unintended parties. The means of encrypting a CWT is
explained in [RFC8392]. If the CWT is not encrypted, the symmetric
key MUST be encrypted as described in Section 3.3.
It's hard for me to escape the conclusion that this paragraph needs to
be a dedicated section with a bit more discussion about how exactly this
usage is performed and encoded.
This mirrors the corresponding procedure in RFC 7800. Would it be OK to
just refer to that document
(https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
(Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in
the opposite order.)
Well, I still wouldn't like it. But I don't think I have grounds to block
the document from advancing if you just refer back to JWT.
Göran and I have discussed this, and we agree that it is indeed
underspecified (e.g. which key is used to encrypt this "inner"
COSE_Encrypt0 contained in the cnf element?). Additionally I can
personally confirm that this is a headache to implement (and I haven't
even touched a constrained implementation).
We see two alternatives here:
1.) Remove the possibility to have a separate encrypted cnf element.
Instead mandate that the whole CWT should be encrypted if it contains a
secret key.
+ make spec easier (to implement) and doesn't requires a long
specification on how to handle this case
- breaks direct equivalence with RFC 7800
2.) Add some dedicated section that explains how the key for this inner
encrypted cnf element is selected and communicated to the RS.
+ The draft remains functionally equivalent to RFC 7800
- Increased draft complexity at questionable gain
- Possible implementer headaches, especially on constrained devices
There is an issue about this here:
https://github.com/cwt-cnf/i-d/issues/19
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,
/iat/ 5 : 1311280970,
/cnf/ 8 : {
/COSE_Encrypt0/ 2 : [
Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
[I did not validate the COSE_Encrypt0 output]
COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
is not. We'd have to define it or write an explanatory comment.
Maybe I'm confused about how the diagnostic notation works, but the
top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
iss/sub/aud/etc. in the preceding notation. If the rules are different for
map keys whose corresponding values are themselves structured data types,
then I should just unconfuse myself and we can move on with things...
Issue created here https://github.com/cwt-cnf/i-d/issues/20
Will fix.
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.
I'm not sure I understand the semantics being described here. Are we
saying that the issuer might give a presenter a CWT, and by the time the
presenter presents the CWT to the recipient, the recipient says "this is
no good" and denies the transaction in question, forcing the presenter
to go back to the issuer and try again? (How do we know that the issuer
would make any different choices the second time around?)
This risk always exists. In a constrained device world, the recipient
may already have cleared out the key referenced by the key ID, which
would force it to reject a CWT using this as proof-of-possession.
I'm not sure how to give good guidance in this case. The error message
delivered by the recipient rejecting the CWT might be helpful I suppose.
Do you think this merits some text?
It's not entirely clear to me that we need to add more text here, but if we
did, it would focus on what "decide not to use" means at a protocol level,
and perhaps how the CWT might not "fit the recipient's requirements" (e.g.,
the key id having fallen out of cache as you describe).
Issue created here: https://github.com/cwt-cnf/i-d/issues/21
Will fix.
from changing any elements conveyed within the CWT payload. Special
care has to be applied when carrying symmetric keys inside the CWT
since those not only require integrity protection but also
confidentiality protection.
Do we want to reiterate the common mechanisms for providing
confidentiality protection here, or just leave the existing t
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
-Original Message- From: Ludwig Seitz Sent: Sunday, August 25, 2019 11:40 PM To: Benjamin Kaduk Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06 Hi Ben, fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 (waiting for Mike to double-check and merge them). As for those that are still open, comments are inline. /Ludwig On 13/08/2019 01:15, Benjamin Kaduk wrote: >>> The "COSE_Key" member MAY also be used for a COSE_Key representing a >>> symmetric key, provided that the CWT is encrypted so that the key is >>> not revealed to unintended parties. The means of encrypting a CWT is >>> explained in [RFC8392]. If the CWT is not encrypted, the symmetric >>> key MUST be encrypted as described in Section 3.3. >>> >>> It's hard for me to escape the conclusion that this paragraph needs to >>> be a dedicated section with a bit more discussion about how exactly this >>> usage is performed and encoded. >>> >> >> This mirrors the corresponding procedure in RFC 7800. Would it be OK to >> just refer to that document >> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? > > (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in > the opposite order.) > Well, I still wouldn't like it. But I don't think I have grounds to block > the document from advancing if you just refer back to JWT. > Göran and I have discussed this, and we agree that it is indeed underspecified (e.g. which key is used to encrypt this "inner" COSE_Encrypt0 contained in the cnf element?). Additionally I can personally confirm that this is a headache to implement (and I haven't even touched a constrained implementation). [JLS] I am not sure that I understand why you believe that this is underspecified. The identification of the key used here has exactly the same characteristics as the key that would be used to encrypt the CWT itself. The configuration is going to be "Here is a signing key plus a key encryption key" as oppose to "Here is a CWT encryption key". I have not bothered to do an implementation of this only because I do not believe that it is a useful configuration for a constrained system. The need to do this only arises if one believes that either a) there is a need to be able to have a third party examine the token in transit or b) there is a need to have a higher degree of security for the token, but not for protecting the symmetric key. Despite the fact that I have not implemented this, I do not believe that it would be all that problematic to implement in general, and would be even easier to implement in a constrained system as only one format of CWT should ever be expected by a single small device so that the structure can be hard coded. [JLS] There is a potential case for the first of those options, having different authority servers that are passing things back and forth and a desire to do validation that the correct permissions exist. That is the client AS sends a request to the Resource AS which creates a token for the RS and the client AS wants to double check the permissions granted to the client. But I have not heard that anybody is planning to do such an implementation yet. So far everybody is combining the two AS roles into a single system. If you are ever in the second case, I would argue that you are better off using asymmetric keys all the way around. We see two alternatives here: 1.) Remove the possibility to have a separate encrypted cnf element. Instead mandate that the whole CWT should be encrypted if it contains a secret key. + make spec easier (to implement) and doesn't requires a long specification on how to handle this case - breaks direct equivalence with RFC 7800 [JLS] Given that we are starting to see people use CWTs in places where they used to be using JWTs, I would not want to put any additional problems in the way of this progression. If others want this construct because of the equivalence to JWT, then let's not break it. 2.) Add some dedicated section that explains how the key for this inner encrypted cnf element is selected and communicated to the RS. + The draft remains functionally equivalent to RFC 7800 - Increased draft complexity at questionable gain - Possible implementer headaches, especially on constrained devices There is an issue about this here: https://github.com/cwt-cnf/i-d/issues/19 [JLS] As I said above, I don't see why this is necessary. It is part and parcel of putting the keys that the AS is going to use on the RS Jim -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
Please see my review of the PR, Ludwig.
-Original Message-
From: Ludwig Seitz
Sent: Sunday, August 25, 2019 11:40 PM
To: Benjamin Kaduk
Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org
Subject: Re: AD review of draft-ietf-ace-cwt-proof-of-possession-06
Hi Ben,
fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24
(waiting for Mike to double-check and merge them).
As for those that are still open, comments are inline.
/Ludwig
On 13/08/2019 01:15, Benjamin Kaduk wrote:
>>> The "COSE_Key" member MAY also be used for a COSE_Key representing a
>>> symmetric key, provided that the CWT is encrypted so that the key is
>>> not revealed to unintended parties. The means of encrypting a CWT is
>>> explained in [RFC8392]. If the CWT is not encrypted, the symmetric
>>> key MUST be encrypted as described in Section 3.3.
>>>
>>> It's hard for me to escape the conclusion that this paragraph needs to
>>> be a dedicated section with a bit more discussion about how exactly this
>>> usage is performed and encoded.
>>>
>>
>> This mirrors the corresponding procedure in RFC 7800. Would it be OK to
>> just refer to that document
>> (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?
>
> (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in
> the opposite order.)
> Well, I still wouldn't like it. But I don't think I have grounds to block
> the document from advancing if you just refer back to JWT.
>
Göran and I have discussed this, and we agree that it is indeed
underspecified (e.g. which key is used to encrypt this "inner"
COSE_Encrypt0 contained in the cnf element?). Additionally I can
personally confirm that this is a headache to implement (and I haven't
even touched a constrained implementation).
We see two alternatives here:
1.) Remove the possibility to have a separate encrypted cnf element.
Instead mandate that the whole CWT should be encrypted if it contains a
secret key.
+ make spec easier (to implement) and doesn't requires a long
specification on how to handle this case
- breaks direct equivalence with RFC 7800
2.) Add some dedicated section that explains how the key for this inner
encrypted cnf element is selected and communicated to the RS.
+ The draft remains functionally equivalent to RFC 7800
- Increased draft complexity at questionable gain
- Possible implementer headaches, especially on constrained devices
There is an issue about this here:
https://github.com/cwt-cnf/i-d/issues/19
>>> 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,
>>> /iat/ 5 : 1311280970,
>>> /cnf/ 8 : {
>>> /COSE_Encrypt0/ 2 : [
>>>
>>> Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"?
>>>
>>> [I did not validate the COSE_Encrypt0 output]
>>>
>>
>> COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key
>> is not. We'd have to define it or write an explanatory comment.
>
> Maybe I'm confused about how the diagnostic notation works, but the
> top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches
> iss/sub/aud/etc. in the preceding notation. If the rules are different for
> map keys whose corresponding values are themselves structured data types,
> then I should just unconfuse myself and we can move on with things...
>
>
Issue created here https://github.com/cwt-cnf/i-d/issues/20
Will fix.
>>
>>> 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.
>>>
>>> I'm not sure I understand the semantics being described here. Are we
>>> saying that the issuer might give a presenter a CWT, and by the time the
>>> presenter presents the CWT to the recipient, the recipient says "this is
>>> no good" and denies the transaction in question, forcing the presenter
>>> to go back to the issuer and try again? (How do we know that the issuer
>>> would make any different choices the second time around?)
>>
>> This risk always exists. In a constrained device world, the recipient
>> may already have cleared out the key referenced by the key ID, which
>> would force it to reject a CWT using this as proof-of-possession.
>>
>> I'm not sure how to give good guidance in this case. The error message
>> delivered by the recipient rejecting the CWT might be helpful I suppose.
>> Do you think this merits some text?
>
> It's not entirely clear to me that we need to add more text here, but if we
> did, it would focus on what "decide not to use" means at a protocol level,
> and perhaps how the CWT might not "fit the recipient's requirements" (e.g.,
> the key id ha
Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
On 26/08/2019 18:07, Jim Schaad wrote: On 13/08/2019 01:15, Benjamin Kaduk wrote: The "COSE_Key" member MAY also be used for a COSE_Key representing a symmetric key, provided that the CWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a CWT is explained in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3. It's hard for me to escape the conclusion that this paragraph needs to be a dedicated section with a bit more discussion about how exactly this usage is performed and encoded. This mirrors the corresponding procedure in RFC 7800. Would it be OK to just refer to that document (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)? (Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in the opposite order.) Well, I still wouldn't like it. But I don't think I have grounds to block the document from advancing if you just refer back to JWT. Göran and I have discussed this, and we agree that it is indeed underspecified (e.g. which key is used to encrypt this "inner" COSE_Encrypt0 contained in the cnf element?). Additionally I can personally confirm that this is a headache to implement (and I haven't even touched a constrained implementation). [JLS] I am not sure that I understand why you believe that this is underspecified. Because the AD said so ;-) Seriously: I believe that this warrants more text, since it must be at least clarified that this construct assumes two pre-configured keys shared between AS and RS: one for encrypting the inner cnf element and one for integrity protecting the whole CWT. Despite the fact that I have not implemented this, I do not believe that it would be all that problematic to implement in general, and would be even easier to implement in a constrained system as only one format of CWT should ever be expected by a single small device so that the structure can be hard coded. Perhaps 'headache' was a hyperbole on my part, but there is definitely a code-complexity difference between "parsing CBOR" and "parsing CBOR, interrupt the parsing to decrypt stuff, continue parsing CBOR". [JLS] There is a potential case for the first of those options, having different authority servers that are passing things back and forth and a desire to do validation that the correct permissions exist. That is the client AS sends a request to the Resource AS which creates a token for the RS and the client AS wants to double check the permissions granted to the client. But I have not heard that anybody is planning to do such an implementation yet. So far everybody is combining the two AS roles into a single system. If you are ever in the second case, I would argue that you are better off using asymmetric keys all the way around. I can see this use case. That rules out my option 1. of removing this construct. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
