Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
> -Original Message- > From: Hannes Tschofenig <hannes.tschofe...@arm.com> > Sent: Wednesday, May 23, 2018 12:55 PM > To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-cwt-proof-of- > possess...@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > Hi Jim, > > A few remarks below. > > -Original Message- > From: Jim Schaad [mailto:i...@augustcellars.com] > Sent: 09 May 2018 05:51 > To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org > Cc: ace@ietf.org > 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. > > [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? > > [Hannes] I think we could get rid of that sentence. > > 3. Terminology: In the definition of Issuer please make 'its' clearer. It is not > clear whose claims are being bound. > > [Hannes] How about: > >Issuer > Party that creates the CWT and binds the claims to the proof-of- > possession key. It's better - 'binds claims about the subject' might be clearer > > > 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. > > [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. > > 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. > > [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. > > 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. > > [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. > > 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. > > [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. > > 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. > > [Hannes] In many deployments they may well not be present. That's > completely fin
Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Hi Jim, A few remarks below. -Original Message- From: Jim Schaad [mailto:i...@augustcellars.com] Sent: 09 May 2018 05:51 To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org Cc: ace@ietf.org 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. [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? [Hannes] I think we could get rid of that sentence. 3. Terminology: In the definition of Issuer please make 'its' clearer. It is not clear whose claims are being bound. [Hannes] How about: Issuer Party that creates the CWT and binds the claims to the proof-of- possession key. 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. [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. 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. [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. 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. [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. 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. [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. 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. [Hannes] In many deployments they may well not be present. That's completely fine. Fewer claims can sometimes be better. 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. [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). 10. In
Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
I have removed items where the proposed solution is probably sufficient. > -Original Message- > From: Mike Jones <michael.jo...@microsoft.com> > Sent: Sunday, May 20, 2018 4:34 AM > To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-cwt-proof-of- > possess...@ietf.org > Cc: ace@ietf.org > Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > Thanks for your useful comments, Jim. Replies are inline below. > > -Original Message- > From: Jim Schaad <i...@augustcellars.com> > Sent: Wednesday, May 9, 2018 6:51 AM > To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org > Cc: ace@ietf.org > 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. > > 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. > > 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. > > 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. 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 > subject to the recipient. I.e. it is an anonymous subject. > > I'
Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Thanks for your useful comments, Jim. Replies are inline below. -Original Message- From: Jim Schaad <i...@augustcellars.com> Sent: Wednesday, May 9, 2018 6:51 AM To: draft-ietf-ace-cwt-proof-of-possess...@ietf.org Cc: ace@ietf.org 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. 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. 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
