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 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". 16. section 4 - Are audience restrictions not done in CWT? 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. 19. Update IANA considerations w/ input from IANA and the CWT document. 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
