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

[Jim Schaad <[e-mail]>]

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

 

From: Mike Jones <[e-mail]> 
Sent: Tuesday, November 6, 2018 3:43 PM
To: Roman Danyliw <[e-mail]>; [e-mail]
Cc: Jim Schaad <[e-mail]>
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 <[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>
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

 

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.

 

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.]

 

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>
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].

 

[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>
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:[e-mail]> [e-mail]

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

 

                                                       Thanks again,

                                                       -- Mike