As promised I finally got finished with this review. 1. Need to decide if /token, /introspect and /authz-info are under /.well-defined or not. If they are then this needs to be noted and there needs to be an IANA action if this has not already been done for OAuth.
2. Add some of the actor terms to section 2- such as Resource Owner 3. Still unhappy about the lack of POP between C and AS. How does the AS know that the key it is binding to the token is the right one. The RS has no problems, but assumes that the AS did its job. 4. If I want to use the SCOPES field as defined by Carsten, then I do not want the current restriction that is being imposed on the scope parameter in Section 3 (?) Under "Scopes and Permissions". 5. In section 3.2 - s/so- called// - don't be pejorative. 6. In section 4 - 2nd paragraph before figure 1 - I want the ACE profile to provide one method to do this. There may be others that are specific to the profile however. 7. In section 4 - Under "ACE Profiles" - RECOMMENDS seems to be an odd thing to have here - this is not really a protocol recommendation is it? Are we allowing for JSON to be used rather than CBOR? The text here on what encodings to use could be made more declarative. Are we expecting any JSON use at this point for any profile define? If so then a list of tradeoffs for profile creators and how to detect would be in order rather than the big RECOMMENDS. 8. Section 5.1 - Awkward language "If the client should to act" 9. Section 5.3 - Is this really what you want to say is that one SHOULD authenticate C to the AS? I think this is a MUST. I question if this is really something that profiles should do rather than this document. I thought that the profiles were targeted at the C <-> RS conversation. 10. Section 5.4 appears to create a new endpoint that has not been discussed in other contexts. Is this intentional? 11. Section 5.5.1 - OK - I am reversing thinking. However I need to get a summary of what a profile is going to need to specify a long ways before I get to this point. Perhaps has part of the overview. One of the questions is going to be can the C-AS section of one profile be used with the C-RS of another profile and keep the same security guarantees. The overview is going to need to talk about this at some point. 12. Section 5.5.1 - I would like to add some additional parameters at this point. The first is a RS_Data field which is copied from the RS->C message verbatim. It allows for encrypted data to be passed from the RS to the AS as part of the request. Data type is COSE_Encrypt. 13. Section 5.5.1 - I would like to see an AS field documented here so th that the 4 corner model can work. 14. Section 5.5.1 - What is the default - use this for "aud"? How is a client supposed to know what to put here for a new RS? 15. Section 5.5.1 - on cnf - Use "It is RECOMMENDED that an AS reject a request with a symmetric key" as this is positive and where enforcement is done. 16. Figure 3 - This example no longer looks correct. the content type should be the same as for Figure 2. That is assuming it is really CoAP and not HTTP? 17. Figure 4 - need to check out if client_secret is a real secret or not - it seems odd to say don't use symmetric and then have an example of passing one. Could be something else as I don't have RFC 6749 w/ me. 18. The set of operations should start with the C->RS response structure from DTLS profile as this is really the first thing that happens. 19. Is there a reason for a client not being able to request a profile rather than having it be configured into the AS? 20. Section 5.5.2 - You are not being constant about encoding - this is saying MUST be CBOR while earlier it was only a recommendation, 21. Section 5.5.2 - Post figure 5 it says examples - but only one example exists. 22. Section 5.5.4.2 - Please make the abbreviations mandatory not optional. I don't really want to support both. 23. Section 5.5.4.4 - Please define profile as being part of a CWT so that it can be communicated to the RS in the event that more than one profile is supported. Optional if RS only does one. 24. Section 5.5.4.5 - I don't know if it would not be cleaner to have a cnf that is only for the client key info and an rs_cnf (defined for introspection) that is for dealing with the RS keys. That makes it cleaner when looking a the case of an AS->C or an AS->R->C message as the fields will be the same. 25. Section 5.5.4.5 - Figure 9 does not really make sense by itself. It needs to have some context because it looks the same as for a RS key. 26. Section 5.5.4.5 - Figure 10 is not formatted correctly as the map wrapping is missing on unprotected. Look @ section 3.3. RFC 6749 about scopes 27. Need to know how to think about the idea of a client doing an introspection. Is the response going to be different than a RS doing the query? I assume that the distinction would be based on the authentication and internal knowledge - does not need to be documented except for response differences. 28. Figure 14 needs to be updated 29. Section 5.6.2 - Need to add rs_cnf - if more than one key need to tell the RS what key to use. 30. Section 5.6.4 - I think this is a required item if introspection is going to be able to return a random symmetric key. Not needed otherwise. 31. Section 5.6.4 - last para - may want to state that this secret is established at the same time that the token is established. 32. Section 5.6.4 - establish MTI algorithms here? 33. Section 5.7 - I think that you need to add rs_cnf in the event of an RS w/ multiple keys so it knows which to use. usage would be optional. 34. Section 5.7 - last paragraph - should be JOSE and COSE not JSON and CBOR. 35. Section 5.7.1 - Why would the RS respond with the cti - given a lack of text it is not clear when the MAY would be triggered. 36. Section 5.7.1 - Not sure how much information is being leaked by having different error codes being returned in these situations. May only want to have one code. 37. Section 5.7.1 - under what circumstances is the introspection request not made? If the introspection request is done async how is the client token communicated back to the client? Would that be done as part of a later access. Seems to be dicey. 38. Random thought - Is there a requirement that the same method be used for both posting to /authz-info and to the resource? Could one use OSCOAP for one and DTLS for the other? Question is because we are profiling and the assumption is that profiles are whole. 39. Section 5.7.2 - Last bullet - should note that tokens need to be shared to the RS - AS may issue lots of tokens but if RS gets none then no expirations 40. Section 5.7.2 - Another "long running request" might be the case of sending back an ACK for a request followed by a 4.01 because the token expires before the request has finished processing. Re-doing introspection might also cause this sequence of messages 41. Section 6 - personal preference - remove the first sentence it is not useful. 42. Section 6 - Protection is from signature or MAC - but we are using AEAD for most of these. Should probably have a security consideration that AEAD is preferred to MAC in most cases because of confidentiality as well. 43. Section 6- the phrase 'long-term key shared with RS' implies to me that this is a symmetric key. May want different language to allow for people thinking of asymmetric keys as well. 44. Section 6 - Please explain to me how targeting multiple RS with an asymmetric key is a problem - change it form shared secret to symmetric key. 45. Section 6- I think you want to use a different term than token replay in this paragraph. If a RS is rebooted and loses all token information, there is nothing wrong with a C doing a replay of the token to the RS to get access to the resources as long as it is still valid. 46. Section 6 - Is the confidentiality protection a requirement for asymmetric keys as well? -- Oh - and it may not be a session key, the session key for DTLS is established later, it is just a POP value (or key if asymmetric) 47. Section 6 - Sentence structure of this paragraph is difficult. The AS does not use shorter key sizes, it will perhaps create shorter POP keys. However, even this may be a problem depending on how short they are. A tradeoff is going to occur here with the ability to record and later decrypt keys depending how short the keys are. 47. Section 6 - the next to last paragraph is a repeat - but probably clearer. 48. Section 6 - Please explain the reasoning behind the last paragraph. It does not make a great deal of sense to me. 49. Section 7 - I don't understand what you are trying to say with the last sentence in the second paragraph. Given that the AS still needs to do ACL control, this does not make sense to me. For now I skipped IANA considerations and the appendixes. Let me know if you would prefer that I place these items into the issue list on github or if you prefer doing it. Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
