Subject: Re: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

From: Mike Jones <[email-masked]>
Date: Tue, 6 Nov 2018 08:42:40 +0000

Thanks for the useful summary, Roman.  Replies are inline below prefixed by "Mike>".  I've just published draft -04<https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-04>, which contains the small number of changes described below.  I believe that this completes resolution of the WGLC feedback.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: [email-masked]
Subject: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

Hello!

This email is intended to summarize the outcome of the WGLC on draft-ietf-ace-cwt-proof-of-possession-02 to date.  This call was started on May 8 [1] and discussion occurred around two reviews of this -02 draft:

** Jim Schaad [Schaad], per https://www.ietf.org/mail-archive/web/ace/current/msg02747.html

** Roman Danyliw [Danyliw], per https://www.ietf.org/mail-archive/web/ace/current/msg02793.html

After discussion on the mailing list, -03 of the draft was produced.

Synthesizing the robust mailing list discussion, I see the following previously identified issues as still needing closure.  The nature of the resolution varies.  Given the volume of the discussion threads, I may have missed a response or failed to line up a text change in -03 to an issue.  Please correct the status of any given point of feedback below.

==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The following feedback was made about the -02 draft; changes to the relevant text was made in -03; but follow-up discussions on the mailing list doesn't indicate closure of the issue.  If the originator of the feedback (it looks like only Jim for this section) feels the issue is closed, please speak up.

[Schaad #6]  Under what circumstances would a 'sub' claim be present and it is not the presenter?  I can see that a holder of the key may be implicitly (or anonymously)  named, but putting something in the subject field which is not identifying the presenter is something that I would reject without a good presentation of why in the  document.

Mike> The draft is written as it is to both provide non-normative guidance for expected simple use cases, while also allowing flexibility for more complicated use cases.  In particular, in some profiles, the subject of the CWT and the presenter of the CWT for proof-of-possession purposes may be different parties.  The party presenting the CWT to the recipient would be in possession of the CWT because it communicated with the issuer but the subject can be different than the presenter.  That's why the subject language is written as a suggestion to profile writers, rather than normatively.  I'll note that this also aligned with the treatment in RFC 7800, which this draft mirrors, by design.

[Schaad #7]  I would disagree with the claim that if the 'sub' claim is missing then it would normally be the issuer.  For the world of IoT, I would expect that the subject would not be present because there is no need to identify the subject to the recipient.  I.e. it is an anonymous subject.

Mike> As with the previous issue, this section of the draft provides non-normative guidance for expected simple use cases, while not precluding profiling specifications from using the standard CWT claims in the manner that makes sense for their application.  The "iss" language here also intentionally parallels the RFC 7800 treatment of this claim.

[Schaad #8]  It is not clear to me that either of the sub and iss claims would normally be present.  They might be present but neither is needed.  The subject can be anonymous and the issuer is identified by the key used to validate the security on the CWT.

Mike> Your points above align with the design in the draft.  That's why both "iss" and "sub" are optional.  Their usage is profile-dependent, as it is in RFC 7800 (and CWT and JWT).

[Schaad #9]  In section 3.1 the first two sentences appear to be contradictory.  Members are used to identify the POP key.  Other things than a POP key can be used than a POP key.  If they are used to identify the POP key- why would they not deal with the POP key?  I think that you should do a separation and define the 'cnf' file which can hold any number of confirmation methods and then have a section on defining some POP cnf method field holders.

Mike> The apparently contradictory language in draft -02 was reworded in draft -03 to address this comment.  In particular, it now explicitly states that the "cnf" claim is used to carry confirmation methods, some of which identify proof-of-possession keys.  This aligns both with RFC 7800 and the SAML 2.0 SubjectConfirmation element design (both by intentionally, since there's no need to reinvent the wheel when an existing design already works well).

[Schaad #10]  In section 3.1 P1 - I am not sure why you have something here about confirming the authenticity of the token as oppose to confirming the identity of the presenter.  Why would that type of information be placed here where it is not useful.]

Mike> The referenced text was reworked between draft -02 and -03.

==[ change was proposed, but not made ]== The draft editors proposed a changes on the mailing list to address the issue but it did not appear in the -03 draft.

See the inline text of https://www.ietf.org/mail-archive/web/ace/current/msg02788.html for the proposed changes for [Schaad #12, 13, 16, 21].

[Schaad #12] I am unclear why there should be a restriction on the number of POP keys that can be in a 'cnf' object.  If there are multiple keys, then any or all of them are of equal value in doing the confirmation.  Just like there can be multiple confirmation methods and an application could choose to use any one of them.

Mike> This was discussed in the working group meeting at IETF 102 in Montreal and on the list.  The consensus appeared to be to stay with the existing design, which describes how to represent multiple PoP keys in the fourth paragraph of https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-3.1 (which again, is the same mechanism defined in RFC 7800).

[Schaad #13]  Not sure which section this belongs in, but the use of an COSE_Encrypt0 would be one way to combat tracking of identities based on the key value being used.  Different encrypted values could be sent to different servers and they would not necessarily know about use w/o internal collusion between them.  Similar effect by using an encrypted CWT.  Potentially requires use of TLS1.3 to protect the RPKs.  YMMV

Mike> The Privacy Considerations section talks about a common PoP key being a potential correlation handle and thus recommends that different PoP keys be used for different parties.  Encrypting a common key could prevent observers unable to decrypt the messages from learning that they key is shared but would not prevent correlation by parties that cooperate to compare their PoP keys.  So it's not clear to me that the suggestion above solves enough of the correlation problem that it's worth including in the draft.  If you disagree, please suggest text for an additional Privacy Considerations paragraph.

[Schaad #16] Section 4 - Are audience restrictions not done in CWT?  -- same issues as [Danyliw #12]

Mike> All claims in CWTs (and JWTs) are optional, including the "aud" (audience) claim.  Particular profiles can suggest and require particular claims, as this profile does.  I have deleted the unnecessary middle sentence, which [Danyliw #12] correctly pointed out broke up the logical flow of the exposition.  Thanks for pointing this out.

[Schaad #21] Section 6.2.2 - the value type is not an array for COSE_Encrypt or COSE_Encyrpt0, these are the values.  As written I could put in an array which is not one of those two structures and be valid.   Ditto for COSE_Key, although w/ slightly less justification.

Mike> Thanks.  I updated these value type declarations to use the actual required COSE_* types.

See the inline text of https://www.ietf.org/mail-archive/web/ace/current/msg02802.html  for the proposed change for [Danyliw #7].

[Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm" seems out of place.  What is this text explaining relative to the examples?

Mike> Thanks.  I deleted the confusing and unnecessary sentence.

==[ face to face discussion required ]== Certain issues were deemed sufficiently complex to required face-to-face discussion at IETF 102.

[Schaad #14]  I have real problems w/ the use of a KID for POP identification.  It may identify the wrong key or, if used for granting access, may have problems w/ identity collisions.  These need to be spelt out someplace to help people tracking down questions of why can't I verify w/ this CWT, I know it's right. -- See https://www.ietf.org/mail-archive/web/ace/current/msg02853.html for more detailed discussion -- related issue to [Danyliw #8].

Mike> The paragraph sentence of the Operational Considerations section at https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-6 was added in draft -03 to address exactly this issue, after extensive discussion and wordsmithing on the mailing list.

Regards,

Roman

[1] https://www.ietf.org/mail-archive/web/ace/current/msg02744.html

_______________________________________________

Ace mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ace

                                                       Thanks again,

                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Tue, 6 Nov 2018 09:57:01 +0000

FYI - I wrote about this new version at http://self-issued.info/?p=1933 and as @selfissued<https://twitter.com/selfissued>.

                                                       -- Mike

From: Ace <[email-masked]> On Behalf Of Mike Jones
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw <[email-masked]>; [email-masked]
Cc: Jim Schaad <[email-masked]>
Subject: Re: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

Hello!

[Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm" seems out of place..  What is this text explaining relative to the examples?

Regards,

Roman

Ace mailing list

                                                       Thanks again,

                                                       -- Mike

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 7 Nov 2018 07:55:44 +0000

Hi Mike!

Thanks for publishing -04.  The changes made in this version address the last of my WGLC comments per [Danyliw #7] and  [Danyliw #12].  More details below:

> From: Mike Jones [mailto:[email-masked]] 
> Sent: Tuesday, November 6, 2018 3:43 AM
> Subject: RE: Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession
>
> Thanks for the useful summary, Roman.  Replies are inline below 
> prefixed by "Mike>".  I've just published draft -04, which contains the 
> small number of changes described below.  I believe that this completes 
> resolution of the WGLC feedback.
>

[snip]

> Mike> All claims in CWTs (and JWTs) are optional, including the "aud" (audience) 
> claim.  Particular profiles can suggest and require particular claims, as this 
> profile does.  I have deleted the unnecessary middle sentence, which 
> [Danyliw #12] correctly pointed out broke up the logical flow of the exposition. 
> Thanks for pointing this out.

This change addresses my concerns.

[snip]

> [Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for 
> instance, be encrypted using a COSE_Encrypt0 representation using the 
> AES-CCM-16-64-128 algorithm" seems out of place.  What is this text 
> explaining relative to the examples?
>

This change addresses my concern.

Roman

---

From: Jim Schaad <[email-masked]>
Date: Thu, 8 Nov 2018 11:29:52 +0700

I do not believe that the big comment that I have left has been addressed.

From: Mike Jones <[email-masked]> 
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw <[email-masked]>; [email-masked]
Cc: Jim Schaad <[email-masked]>
Subject: RE: Summarizing WGLC discussion of
draft-ietf-ace-cwt-proof-of-possession

Thanks for the useful summary, Roman.  Replies are inline below prefixed by
"Mike>".  I've just published draft -04
<https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-04> ,
which contains the small number of changes described below.  I believe that
this completes resolution of the WGLC feedback.

-----Original Message-----
From: Ace <[email-masked] <mailto:[email-masked]> > On Behalf Of
Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Ace] Summarizing WGLC discussion of
draft-ietf-ace-cwt-proof-of-possession

Hello!

This email is intended to summarize the outcome of the WGLC on
draft-ietf-ace-cwt-proof-of-possession-02 to date.  This call was started on
May 8 [1] and discussion occurred around two reviews of this -02 draft:

** Jim Schaad [Schaad], per
<https://www.ietf.org/mail-archive/web/ace/current/msg02747.html>
https://www.ietf.org/mail-archive/web/ace/current/msg02747.html

** Roman Danyliw [Danyliw], per
<https://www.ietf.org/mail-archive/web/ace/current/msg02793.html>
https://www.ietf.org/mail-archive/web/ace/current/msg02793.html

Synthesizing the robust mailing list discussion, I see the following
previously identified issues as still needing closure.  The nature of the
resolution varies.  Given the volume of the discussion threads, I may have
missed a response or failed to line up a text change in -03 to an issue.
Please correct the status of any given point of feedback below.

==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The
following feedback was made about the -02 draft; changes to the relevant
text was made in -03; but follow-up discussions on the mailing list doesn't
indicate closure of the issue.  If the originator of the feedback (it looks
like only Jim for this section) feels the issue is closed, please speak up.

[Schaad #6]  Under what circumstances would a 'sub' claim be present and it
is not the presenter?  I can see that a holder of the key may be implicitly
(or anonymously)  named, but putting something in the subject field which is
not identifying the presenter is something that I would reject without a
good presentation of why in the  document.

Mike> The draft is written as it is to both provide non-normative guidance
for expected simple use cases, while also allowing flexibility for more
complicated use cases.  In particular, in some profiles, the subject of the
CWT and the presenter of the CWT for proof-of-possession purposes may be
different parties.  The party presenting the CWT to the recipient would be
in possession of the CWT because it communicated with the issuer but the
subject can be different than the presenter.  That's why the subject
language is written as a suggestion to profile writers, rather than
normatively.  I'll note that this also aligned with the treatment in RFC
7800, which this draft mirrors, by design.

Jim> I am not going to fight this, but this type of behavior is what makes
it really hard to try and do any sort of formal proofs with CWTs.  One
cannot model that the confirmation key is associated with a specific
identity since that identity could be in any one of 3 different fields or
implicit and one cannot know which of those is the correct one in the
generic case.

[Schaad #7]  I would disagree with the claim that if the 'sub' claim is
missing then it would normally be the issuer.  For the world of IoT, I would
expect that the subject would not be present because there is no need to
identify the subject to the recipient.  I.e. it is an anonymous subject.

Mike> As with the previous issue, this section of the draft provides
non-normative guidance for expected simple use cases, while not precluding
profiling specifications from using the standard CWT claims in the manner
that makes sense for their application.  The "iss" language here also
intentionally parallels the RFC 7800 treatment of this claim.

Jim > See above

[Schaad #8]  It is not clear to me that either of the sub and iss claims
would normally be present.  They might be present but neither is needed.
The subject can be anonymous and the issuer is identified by the key used to
validate the security on the CWT.

Mike> Your points above align with the design in the draft.  That's why both
"iss" and "sub" are optional.  Their usage is profile-dependent, as it is in
RFC 7800 (and CWT and JWT).

Jim > See above

[Schaad #9]  In section 3.1 the first two sentences appear to be
contradictory.  Members are used to identify the POP key.  Other things than
a POP key can be used than a POP key.  If they are used to identify the POP
key- why would they not deal with the POP key?  I think that you should do a
separation and define the 'cnf' file which can hold any number of
confirmation methods and then have a section on defining some POP cnf method
field holders.

Mike> The apparently contradictory language in draft -02 was reworded in
draft -03 to address this comment.  In particular, it now explicitly states
that the "cnf" claim is used to carry confirmation methods, some of which
identify proof-of-possession keys.  This aligns both with RFC 7800 and the
SAML 2.0 SubjectConfirmation element design (both by intentionally, since
there's no need to reinvent the wheel when an existing design already works
well).

[Schaad #10]  In section 3.1 P1 - I am not sure why you have something here
about confirming the authenticity of the token as oppose to confirming the
identity of the presenter.  Why would that type of information be placed
here where it is not useful.]

==[ change was proposed, but not made ]== The draft editors proposed a
changes on the mailing list to address the issue but it did not appear in
the -03 draft.  

See the inline text of
<https://www.ietf.org/mail-archive/web/ace/current/msg02788.html>
https://www.ietf.org/mail-archive/web/ace/current/msg02788.html for the
proposed changes for [Schaad #12, 13, 16, 21].

[Schaad #12] I am unclear why there should be a restriction on the number of
POP keys that can be in a 'cnf' object.  If there are multiple keys, then
any or all of them are of equal value in doing the confirmation.  Just like
there can be multiple confirmation methods and an application could choose
to use any one of them.

Mike> This was discussed in the working group meeting at IETF 102 in
Montreal and on the list.  The consensus appeared to be to stay with the
existing design, which describes how to represent multiple PoP keys in the
fourth paragraph of
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#sectio
n-3.1 (which again, is the same mechanism defined in RFC 7800).

Jim> fine.

[Schaad #13]  Not sure which section this belongs in, but the use of an
COSE_Encrypt0 would be one way to combat tracking of identities based on the
key value being used.  Different encrypted values could be sent to different
servers and they would not necessarily know about use w/o internal collusion
between them.  Similar effect by using an encrypted CWT.  Potentially
requires use of TLS1.3 to protect the RPKs.  YMMV

Mike> The Privacy Considerations section talks about a common PoP key being
a potential correlation handle and thus recommends that different PoP keys
be used for different parties.  Encrypting a common key could prevent
observers unable to decrypt the messages from learning that they key is
shared but would not prevent correlation by parties that cooperate to
compare their PoP keys.  So it's not clear to me that the suggestion above
solves enough of the correlation problem that it's worth including in the
draft.  If you disagree, please suggest text for an additional Privacy
Considerations paragraph.

Jim> I'll look at this again, but I am not sure that this is the correct
place to put it.

[Schaad #16] Section 4 - Are audience restrictions not done in CWT?  -- same
issues as [Danyliw #12]

Mike> All claims in CWTs (and JWTs) are optional, including the "aud"
(audience) claim.  Particular profiles can suggest and require particular
claims, as this profile does.  I have deleted the unnecessary middle
sentence, which [Danyliw #12] correctly pointed out broke up the logical
flow of the exposition.  Thanks for pointing this out.

[Schaad #21] Section 6.2.2 - the value type is not an array for COSE_Encrypt
or COSE_Encyrpt0, these are the values.  As written I could put in an array
which is not one of those two structures and be valid.   Ditto for COSE_Key,
although w/ slightly less justification. 

Mike> Thanks.  I updated these value type declarations to use the actual
required COSE_* types.

See the inline text of
<https://www.ietf.org/mail-archive/web/ace/current/msg02802.html>
https://www.ietf.org/mail-archive/web/ace/current/msg02802.html  for the
proposed change for [Danyliw #7].

==[ face to face discussion required ]== Certain issues were deemed
sufficiently complex to required face-to-face discussion at IETF 102.

[Schaad #14]  I have real problems w/ the use of a KID for POP
identification.  It may identify the wrong key or, if used for granting
access, may have problems w/ identity collisions.  These need to be spelt
out someplace to help people tracking down questions of why can't I verify
w/ this CWT, I know it's right. -- See
<https://www.ietf.org/mail-archive/web/ace/current/msg02853.html>
https://www.ietf.org/mail-archive/web/ace/current/msg02853.html for more
detailed discussion -- related issue to [Danyliw #8].

Mike> The paragraph sentence of the Operational Considerations section at
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#sectio
n-6 was added in draft -03 to address exactly this issue, after extensive
discussion and wordsmithing on the mailing list.

Jim> During the last F2F meeting I sent a paragraph which I consider to be
the minimal change which would be required.

Regards,

Roman

[1]  <https://www.ietf.org/mail-archive/web/ace/current/msg02744.html>
https://www.ietf.org/mail-archive/web/ace/current/msg02744.html

Ace mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/ace>
https://www.ietf.org/mailman/listinfo/ace 

                                                       Thanks again,

                                                       -- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 8 Nov 2018 07:41:30 +0000

Jim - am I right that the text you were suggesting be added to the "kid" treatment is that in the thread "[Ace] Text for KID in POP" which introduces the text in https://mailarchive.ietf.org/arch/msg/ace/v_Ci7kRMC0poffGmrSNYb5-sjrA and corrects it in https://mailarchive.ietf.org/arch/msg/ace/garcXUmWNHmEgZNS7FKT-AYBgMI?

I'll look at it again now...

                                                       Thanks,
                                                       -- Mike

From: Jim Schaad <[email-masked]>
Sent: Thursday, November 8, 2018 11:30 AM
To: Mike Jones <[email-masked]>; 'Roman Danyliw' <[email-masked]>; [email-masked]
Subject: RE: Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Subject: RE: Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession

Hello!

Jim> I am not going to fight this, but this type of behavior is what makes it really hard to try and do any sort of formal proofs with CWTs.  One cannot model that the confirmation key is associated with a specific identity since that identity could be in any one of 3 different fields or implicit and one cannot know which of those is the correct one in the generic case.

Jim > See above

Jim > See above

Jim> fine.

Jim> I'll look at this again, but I am not sure that this is the correct place to put it.

Jim> During the last F2F meeting I sent a paragraph which I consider to be the minimal change which would be required.

Regards,

Roman

Ace mailing list

                                                       Thanks again,

                                                       -- Mike