Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

From: Roman Danyliw <[email-masked]>
Date: Tue, 8 May 2018 22:18:52 +0000

Hello!

Consistent with the feedback from the editor team at the London meeting, we are starting a working group last call (WGLC) for the "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" draft:

** draft-ietf-ace-cwt-proof-of-possession-02
** https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02

Please send comments to the mailing list -- feedback on issues or needed changes; as well as endorsements that this draft is ready.

This WGLC will end on Wednesday, May 23, 2018.

Thanks,
Roman and Jim

---

From: Jim Schaad <[email-masked]>
Date: Tue, 8 May 2018 21:51:11 -0700

I'll pull out the list of comments that I wrote a month ago but didn't start
that computer up recently.

1.  Are all of the authors necessary?  As a chair I need to justify a count
of more than 5 to the IESG.

2.  Is the last sentence in section 1 necessary?  Are you actually defining
any strings that could be case-sensitive?

3.  Terminology: In the definition of Issuer please make 'its' clearer.  It
is not clear whose claims are being bound.

4.  Terminology: I still think this is 'Presenter' is a very strange term to
use for this definition.  I would really like to see it be made something
that makes sense and then say the term is the same as this in JWT.  The term
has a model of use with it that I do not believe can be sustained even for
the ACE Oauth case but really not in other cases.

5.  Terminology: Recipient matches presenter, and it matches the OAuth model
and not a trust model world.   Relying party or service provider make far
more sense to me.

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.

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.

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.

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.

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.

11.  In section 3.1 P2 - We are back to the same argument that existed for a
CWT in general.  Not knowing that a CWT is for a specific application means
that it can be used in a different application and checking that the first
application would have done is ignored by the second one because it will
ignore fields it does not understand.

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.

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

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.

15.  The content of 'kid' is application specific.  Where is an application
going to define this such that it will work more generally.  The application
in the case of the ACE working group boils down to the world (minus a few
things).

16. section 4 - Are audience restrictions not done in CWT?

17. section 4 - this implies that POP cannot be replayed via asymmetric
keys.  Why would this be the case?

18. section 4 - prior to an issuer being able to create a CWT for a client
w/ an asymmetric key in it, the issuer MUST go through a POP protocol of
some type to validate that the client has possession of the key.  Issuers
may want to repeat this validation at some interval for re-verification.
They should also keep track of the keys and flag where the same public key
appears more than one for
 review.

19.  Update IANA considerations w/ input from IANA and the CWT document.

20.  Are keys big enough that it should be considered to move kid to the 2
byte range of identifiers?

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.

Jim

---

From: Mike Jones <[email-masked]>
Date: Sun, 20 May 2018 11:34:13 +0000

Thanks for your useful comments, Jim.  Replies are inline below.

-----Original Message-----
From: Jim Schaad <[email-masked]> 
Sent: Wednesday, May 9, 2018 6:51 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

I'll pull out the list of comments that I wrote a month ago but didn't start that computer up recently.

1.  Are all of the authors necessary?  As a chair I need to justify a count of more than 5 to the IESG.

The authors are the union of the set of authors of draft-jones-ace-cwt-proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both contained independently developed and largely parallel treatments of the CWT PoP confirmation subject.  Ludwig was the primary author of this text in the second, so he should definitely be retained as an editor.  I'll leave it up to the other authors of draft-ietf-ace-oauth-authz-04 to self-identify whether they materially contributed to the CWT PoP confirmation text or not.  Maybe we can delete those who don't self-identify as contributors.

2.  Is the last sentence in section 1 necessary?  Are you actually defining any strings that could be case-sensitive?

Sure - we can delete the text "Unless otherwise noted, all the protocol parameter names and values are case sensitive."  It's a holdover from RFC 7800 that doesn't apply here.

3.  Terminology: In the definition of Issuer please make 'its' clearer.  It is not clear whose claims are being bound.

We can change "its claims" to "the claims in the CWT".

4.  Terminology: I still think this is 'Presenter' is a very strange term to use for this definition.  I would really like to see it be made something that makes sense and then say the term is the same as this in JWT.  The term has a model of use with it that I do not believe can be sustained even for the ACE Oauth case but really not in other cases.

This is the standard term for this role in the industry.  For instance, Section 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version 1.0" http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key-cd-01.pdf defines "Presenter" with an equivalent meaning.

Also, for this reason, this is the same terminology used for this role in RFC 7800.  It is used pervasively throughout both this document and RFC 7800 - including in the diagrams in the introduction of RFC 7800.  I believe we would be doing a disservice to readers and implementers if we were to use a different term from that in RFC 7800 (and SAML) when the meaning is identical.

Same response as to 4.  We owe it to readers and implementers to keep the terminology consistent with RFC 7800 and industry practice.

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.

Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which is in the hands of the RFC Editor), it's dependent upon the profiling specification how the "sub" claim is used.  In some cases the subject and/or presenter will be identified with some combination of "iss" and/or "sub".  In other profiles, different representations will be appropriate, such as the use of the "subject_type" value in the RISC example in https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4.

Remember that in both JWT and CWT, the inclusion of *all* claims is left up to the profile.  The same is true of RFC 7800 and this spec (other than the use of the "cnf" claim).  We shouldn't tie the hands of profiles in a way that prevents them from using the representation of the presenter that is most natural for their use case.

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.

I'm fine adding language saying that in some use cases, such IoT use cases, explicit identification of the presenter may not be necessary because in some cases, the recipient already implicitly has this information.  And I can drop the "normally" language about "iss" and instead tone it down to talk about "in some use cases".

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.

Per my response to 7, I can replace the "normally" language with "in some use cases" language, so the spec isn't presuming what "normal" usage is.  This should be up to the profiles.

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.

Good point.  I can revise the text to be clear that confirmation is more general than confirmation via PoP key and that the conformation members defined and registered by this spec enable confirmation using a PoP key.

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.

In SAML, there are plenty of non-PoP confirmation methods and RFC 7800 (and this spec) was designed to enable a similar range of conformation methods to be registered and used.  For instance, SAML has an IP Address confirmation method.  (Yes, I understand that's of dubious value, but it's an easy to understand example.)  I can update the language to say that PoP keys confirm the identity of the presenter, whereas other confirmation methods may confirm other properties.

11.  In section 3.1 P2 - We are back to the same argument that existed for a CWT in general.  Not knowing that a CWT is for a specific application means that it can be used in a different application and checking that the first application would have done is ignored by the second one because it will ignore fields it does not understand.

This language is parallel to the language about understanding claims in JWT, CWT, and RFC 7800, by design.  In particular, the "MUST ignore not understood claims" language is the key to non-breaking extensibility.  Profiles can and will specify claim sets and validation rules for particular CWTs, just as they do for particular JWTs.  See the ID Token requirements in http://openid.net/specs/openid-connect-core-1_0.html#IDToken and the corresponding validation rules in http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation for an example of such a profile for JWTs.  Profiles for CWT and CWT PoP will be similarly specific.

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.

You're right that this could have been specified in a way that allows multiple keys in a "cnf" object but it is intended to simplify things for implementers and increase interoperability to by having just one.  Also, note that if multiple kinds of conformation keys are desired by a profile, the second sentence of paragraph 4 of https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02#section-3.1 already recommends how to achieve this.

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

I'll try to add something along these lines to the privacy considerations section.

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.

The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key ID is sent that doesn't correspond to the right PoP key, failures may occur.  I view that as usage bug - not a protocol problem.  If keys aren't consistently known and identified by both parties, there are lots of things that can go wrong, and this is only one such instance.  That said, I can try to say something about the need for keys to be consistently and known by both parties, if you think that would help.

15.  The content of 'kid' is application specific.  Where is an application going to define this such that it will work more generally.  The application in the case of the ACE working group boils down to the world (minus a few things).

Sure - its content is application-specific, but per my answer to 14, what matters is that keys are consistently identified between both participants.  Provided that's true, then it really doesn't matter whether a Key ID value is (a binary encoding of) "Jim's Key" or (a binary encoding of) "e762dcc3-bc8a-4125-844f-e5578695c834".

https://tools.ietf.org/html/rfc8392#section-3.1.3 defines how to do audience restriction for CWTs.  I can change the JWT reference to the equivalent CWT reference.

17. section 4 - this implies that POP cannot be replayed via asymmetric keys.  Why would this be the case?

I'm a little confused by this comment because paragraph 4 explicitly states that "Proof of possession via encrypted symmetric secrets is subject to replay attacks".  So yes, they can be replayed, so I don't understand what you're commenting about or what additional explanation you'd like to see.

18. section 4 - prior to an issuer being able to create a CWT for a client w/ an asymmetric key in it, the issuer MUST go through a POP protocol of some type to validate that the client has possession of the key.  Issuers may want to repeat this validation at some interval for re-verification.
They should also keep track of the keys and flag where the same public key appears more than one for  review.

I assume that you're asking that something along the lines of the above be added to the Security Considerations?  I'd be fine doing that.

Will do.

20.  Are keys big enough that it should be considered to move kid to the 2 byte range of identifiers?

I don't see any need to do this because the "cnf" identifier space is distinct from the CWT identifier space.  I really can't envision a scenario in which there will ever be 64 "cnf" values (32 single-byte positive integers and 32 single-byte negative integers).  It's a fair question, but as it see it, doing so would just add a byte for no practical reason.

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.

https://tools.ietf.org/html/rfc8152#section-5.2 says that "The COSE_Encrypt0 structure is a CBOR array."  But I can make the language more precise by saying that the value is a COSE_Encrypt or COSE_Encrypt0 value with optional matching CBOR tags.

Jim

Thanks again for your thorough review!

				-- Mike

---

From: Jim Schaad <[email-masked]>
Date: Sun, 20 May 2018 17:35:45 -0700

I have removed items where the proposed solution is probably sufficient.

> From: Mike Jones <[email-masked]>
> Sent: Sunday, May 20, 2018 4:34 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-ace-cwt-proof-of-
> [email-masked]
> Cc: [email-masked]
> I'll pull out the list of comments that I wrote a month ago but didn't
start that
> computer up recently.
> 
> 1.  Are all of the authors necessary?  As a chair I need to justify a
count of
> more than 5 to the IESG.
> 
> The authors are the union of the set of authors of draft-jones-ace-cwt-
> proof-of-possession-00 and draft-ietf-ace-oauth-authz-04, which both
> contained independently developed and largely parallel treatments of the
> CWT PoP confirmation subject.  Ludwig was the primary author of this text
in
> the second, so he should definitely be retained as an editor.  I'll leave
it up to
> the other authors of draft-ietf-ace-oauth-authz-04 to self-identify
whether
> they materially contributed to the CWT PoP confirmation text or not.
Maybe
> we can delete those who don't self-identify as contributors.
> 
> 4.  Terminology: I still think this is 'Presenter' is a very strange term
to use for
> this definition.  I would really like to see it be made something that
makes
> sense and then say the term is the same as this in JWT.  The term has a
> model of use with it that I do not believe can be sustained even for the
ACE
> Oauth case but really not in other cases.
> 
> This is the standard term for this role in the industry.  For instance,
Section
> 1.2 (Terminology) of "SAML V2.0 Holder-of-Key Assertion Profile Version
1.0"
> http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key-
> cd-01.pdf defines "Presenter" with an equivalent meaning.
> 
> Also, for this reason, this is the same terminology used for this role in
RFC
> 7800.  It is used pervasively throughout both this document and RFC 7800 -
> including in the diagrams in the introduction of RFC 7800.  I believe we
would
> be doing a disservice to readers and implementers if we were to use a
> different term from that in RFC 7800 (and SAML) when the meaning is
> identical.
> 
> Same response as to 4.  We owe it to readers and implementers to keep the
> terminology consistent with RFC 7800 and industry practice.
> 
the
> presenter?  I can see that a holder of the key may be implicitly (or
> Just as in https://tools.ietf.org/html/draft-ietf-secevent-token-13 (which
is
> in the hands of the RFC Editor), it's dependent upon the profiling
> specification how the "sub" claim is used.  In some cases the subject
and/or
> presenter will be identified with some combination of "iss" and/or "sub".
In
> other profiles, different representations will be appropriate, such as the
use
> of the "subject_type" value in the RISC example in
> https://tools.ietf.org/html/draft-ietf-secevent-token-13#section-2.1.4.
> 
> Remember that in both JWT and CWT, the inclusion of *all* claims is left
up
> to the profile.  The same is true of RFC 7800 and this spec (other than
the use
> of the "cnf" claim).  We shouldn't tie the hands of profiles in a way that
> prevents them from using the representation of the presenter that is most
> natural for their use case.

I think you have done a good job of arguing my case that this is something
that should be removed.  If it is appropriate to a specific profile then
that should be stated in that profile and not in the general document.

> 
> 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
> I'm fine adding language saying that in some use cases, such IoT use
cases,
> explicit identification of the presenter may not be necessary because in
> some cases, the recipient already implicitly has this information.  And I
can
> drop the "normally" language about "iss" and instead tone it down to talk
> about "in some use cases".

Again - this seems like a statement that should be made in a profile and not
in this document.  If you have some cases where this is true then it would
make sense to at least point to them because this seems to be completely
unsupported as a general rule.  One also has problems about why self-signed
statements should not be very explicitly stated as such given that the type
of trust to be placed in this may be significantly different.

> 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.
> 
> Per my response to 7, I can replace the "normally" language with "in some
> use cases" language, so the spec isn't presuming what "normal" usage is.
> This should be up to the profiles.

While that is better, it makes more sense to me to change this into text
which says.  If this claim is not present it means X, if it is present it
means Y.  Making this paragraph be two, one each for iss and sub and then
describe what is being explicit and what is being implicit means that it is
clear what is being done with each of these.

> Good point.  I can revise the text to be clear that confirmation is more
> general than confirmation via PoP key and that the conformation members
> defined and registered by this spec enable confirmation using a PoP key.
> 
identity
> of the presenter.  Why would that type of information be placed here where
> it is not useful.
> 
> In SAML, there are plenty of non-PoP confirmation methods and RFC 7800
> (and this spec) was designed to enable a similar range of conformation
> methods to be registered and used.  For instance, SAML has an IP Address
> confirmation method.  (Yes, I understand that's of dubious value, but it's
an
> easy to understand example.)  I can update the language to say that PoP
> keys confirm the identity of the presenter, whereas other confirmation
> methods may confirm other properties.

So the paragraph should read something along the lines of:

The "cnf" claim is used in the CWT to contain the data required to confirm
that the CWT is associated to a subject.  This document defines a method and
set of data that allows for the confirmation to be done by a
proof-of-possession key.  Other documents may define other methods and the
associated data members.  The "cnf" claim is analogous to the SAML 2.0
SubjectConformation element where one or more different subject confirmation
methods can be placed.

> This language is parallel to the language about understanding claims in
JWT,
> CWT, and RFC 7800, by design.  In particular, the "MUST ignore not
> understood claims" language is the key to non-breaking extensibility.
> Profiles can and will specify claim sets and validation rules for
particular CWTs,
> just as they do for particular JWTs.  See the ID Token requirements in
> http://openid.net/specs/openid-connect-core-1_0.html#IDToken and the
> corresponding validation rules in http://openid.net/specs/openid-connect-
> core-1_0.html#IDTokenValidation for an example of such a profile for JWTs.
> Profiles for CWT and CWT PoP will be similarly specific.

That is great if you want to use OR rules - this token can be used if A or B
is true.  This does not work at all if you want to use AND rules - this
token can only be used if A and B are true.  

However that is orthogonal to the issue that I have raised.  You say that
any token which has a sufficient set of fields is good for my application.
Not all profiles are designed so that as long as level 1 is fine and a
subset of level 2 that a token can be used to authorize at level 1.

> 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.
> 
> You're right that this could have been specified in a way that allows
multiple
> keys in a "cnf" object but it is intended to simplify things for
implementers
> and increase interoperability to by having just one.  Also, note that if
multiple
> kinds of conformation keys are desired by a profile, the second sentence
of
> paragraph 4 of https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-
> possession-02#section-3.1 already recommends how to achieve this.

> 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.
> 
> The Key ID is a hint to help identify which PoP key to use.  Yes, if a Key
ID is
> sent that doesn't correspond to the right PoP key, failures may occur.  I
view
> that as usage bug - not a protocol problem.  If keys aren't consistently
known
> and identified by both parties, there are lots of things that can go
wrong, and
> this is only one such instance.  That said, I can try to say something
about the
> need for keys to be consistently and known by both parties, if you think
that
> would help.

My problem is that if there are two different people with the same Key ID,
either intentionally or unintentionally, then using the key ID to identify
the key may allow the other person to masquerade as the first person.  I am
unworried about the instance of a failure to get a key based on a key id.
That is not the problem you are proposing to address.

> 
> 15.  The content of 'kid' is application specific.  Where is an
application going
> to define this such that it will work more generally.  The application in
the
> case of the ACE working group boils down to the world (minus a few
things).
> 
> Sure - its content is application-specific, but per my answer to 14, what
> matters is that keys are consistently identified between both
participants.
> Provided that's true, then it really doesn't matter whether a Key ID value
is (a
> binary encoding of) "Jim's Key" or (a binary encoding of) "e762dcc3-bc8a-
> 4125-844f-e5578695c834".

No, if the trust is   CWT -> KeyID -> Key then there is a step in the middle
that has not be trusted.  CWT->Key is an atomic trust operation as it is
cryptographically validated.

> 17. section 4 - this implies that POP cannot be replayed via asymmetric
keys.
> Why would this be the case?
> 
> I'm a little confused by this comment because paragraph 4 explicitly
states
> that "Proof of possession via encrypted symmetric secrets is subject to
> replay attacks".  So yes, they can be replayed, so I don't understand what
> you're commenting about or what additional explanation you'd like to see.
> 

The conclusion that I drew from this is that - you say symmetric keys have
replay attacks, but you don't say anything about asymmetric key having the
same attacks so they must not.

> I don't see any need to do this because the "cnf" identifier space is
distinct
> from the CWT identifier space.  I really can't envision a scenario in
which
> there will ever be 64 "cnf" values (32 single-byte positive integers and
32
> single-byte negative integers).  It's a fair question, but as it see it,
doing so
> would just add a byte for no practical reason.

I don't know that this is the correct metric to be using.  A single
confirmation method could register multiple keys to be used.  After all POP
is registering 3

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 May 2018 19:54:46 +0000

Hi Jim,

A few remarks below.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: 09 May 2018 05:51
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

[Hannes] As mentioned by Mike already, this was the result of a draft merger. The text initially came from an OAuth document (since this work had its history in the OAuth WG).

[Hannes] I think we could get rid of that sentence.

[Hannes] How about:

   Issuer
      Party that creates the CWT and binds the claims to the proof-of-
      possession key.

[Hannes] It is a strange term but we used it also in the OAuth JWT PoP document and hence it wouldn't make sense to change it now.

[Hannes] Same comment as above. I prefer to be in alignment with the OAuth work here. I am wondering whether we should also copy the figures from Section 1 of https://tools.ietf.org/html/rfc7800 to make the architecture clearer.

[Hannes] Mike provided his perspective on this issue already. CWT is similar to JWT a somewhat flexible building block. What claims should, must or may be included in a given deployment depends a bit on the use case. Not including the subject claim may be useful for privacy purposes, for example. In other cases you definitely want to convey that information.

[Hannes] I am not sure that this is always the case in an IoT deployment. For example, imagine if a technician accesses some industrial device then I want to have the information about the person accessing those devices in my audit trail.

[Hannes] In many deployments they may well not be present. That's completely fine. Fewer claims can sometimes be better.

[Hannes] How does this sound:

Section 3.1.  Confirmation Claim

FROM:

   The "cnf" claim is used in the JWT to contain members used to
   identify the proof-of-possession key.  Other members of the "cnf"
   object may be defined because a proof-of-possession key may not be
   the only means of confirming the authenticity of the token.  This is
   analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
   SubjectConfirmation element in which a number of different subject
   confirmation methods can be included (including proof-of-possession
   key information).

TO:

The "cnf" claim in the JWT is used to carry confirmation methods, some of
them use proof-of-possession keys while others do not. This design is
analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation
element in which a number of different subject confirmation methods can
be included (including proof-of-possession key information).

[Hannes] I believe this part would be clarified with my wording change to Section 3.1 as proposed in #9.

[Hannes] Mike provided a detailed response to this item already.

[Hannes] I believe we should not place such a restriction in there. A profile should place restrictions on the number of allowed "cnf" claims there. Changing the names of the claims, as a proposed alternative to get around this limit, appears a bit problematic since we have to register them in the IANA registry.
Hence, my proposal is to change the text

FROM:

  The "cnf" claim value MUST represent only a single proof-of-
   possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK
   Set URL) confirmation values defined below may be present.  Note that
   if an application needs to represent multiple proof-of-possession
   keys in the same JWT, one way for it to achieve this is to use other
   claim names, in addition to "cnf", to hold the additional proof-of-
   possession key information.

TO:

  The "cnf" claim value may contain one or multiple proof-of-
   possession keys. Hence, more than one "jwk", "jwe", and/or "jku" (JWK
   Set URL) confirmation values  may be present in a CWT.  A profile may impose
   further restrictions on the number of PoP keys that are present and
   also whether all or a only a subset of them needs to be utilized by in
   a given application domain.

~~~snip  ~~~

I will respond to the other questions in a second email; ran out of time.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Jim Schaad <[email-masked]>
Date: Thu, 24 May 2018 10:20:45 -0700

> From: Hannes Tschofenig <[email-masked]>
> Sent: Wednesday, May 23, 2018 12:55 PM
start that
count of
> more than 5 to the IESG.
> 
> [Hannes] As mentioned by Mike already, this was the result of a draft
> merger. The text initially came from an OAuth document (since this work
had
> its history in the OAuth WG).
> 
> 2.  Is the last sentence in section 1 necessary?  Are you actually
defining any
> strings that could be case-sensitive?
> 
> 3.  Terminology: In the definition of Issuer please make 'its' clearer.
It is not
> clear whose claims are being bound.
> 
> [Hannes] How about:
> 
>    Issuer

It's better - 'binds claims about the subject' might be clearer

to use for
makes
ACE
> [Hannes] It is a strange term but we used it also in the OAuth JWT PoP
> document and hence it wouldn't make sense to change it now.

If you really cannot change the term, then it might make sense to add some
description of other terminology that others might be familiar with.

> [Hannes] Same comment as above. I prefer to be in alignment with the
> OAuth work here. I am wondering whether we should also copy the figures
> from Section 1 of https://tools.ietf.org/html/rfc7800 to make the
> architecture clearer.
> 
the
> [Hannes] Mike provided his perspective on this issue already. CWT is
similar
> to JWT a somewhat flexible building block. What claims should, must or may
> be included in a given deployment depends a bit on the use case. Not
> including the subject claim may be useful for privacy purposes, for
example.
> In other cases you definitely want to convey that information.

I completely agree with your last sentence.  The sub would be omitted
because of privacy or not needed.  However having the subject be present and
the subject not being the presenter seems to be a very strange concept.
Here is a token issued by A where the subject is B and the key is held by C.

then it
the
> [Hannes] I am not sure that this is always the case in an IoT deployment.
For
> example, imagine if a technician accesses some industrial device then I
want
> to have the information about the person accessing those devices in my
> audit trail.

I could easily be wrong about the subject claim not being absent more often
that not.  However that still does not mean it would normally be about the
issuer rather than an anonymous subject.

normally be
> [Hannes] In many deployments they may well not be present. That's
> completely fine. Fewer claims can sometimes be better.
> 

s/JWT/CWT/

otherwise it looks better.

identity
> Section 3.1 as proposed in #9.

I'd want to see an updated version to know if that is true.

all of them
multiple
> [Hannes] I believe we should not place such a restriction in there. A
profile
> should place restrictions on the number of allowed "cnf" claims there.
> Changing the names of the claims, as a proposed alternative to get around
> this limit, appears a bit problematic since we have to register them in
the
> IANA registry.

That would be my preference.  I don't know how often it would be used but it
seems to be a better idea for some longer term CWTs

Jim

> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
recipient,
> please notify the sender immediately and do not disclose the contents to
any
> other person, use it for any purpose, or store or copy the information in
any
> medium. Thank you.