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

[Mike Jones <[e-mail]>]

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

                                                       -- Mike

From: Ace <[e-mail]> On Behalf Of Mike Jones
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw <[e-mail]>; [e-mail]
Cc: Jim Schaad <[e-mail]>
Subject: Re: [Ace] 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Roman Danyliw
Sent: Friday, July 13, 2018 12:56 AM
To: [e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

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



                                                       Thanks again,

                                                       -- Mike