Re: [Ace] Review of draft-ietf-ace-oauth-authz-06
Thanks Jim for a great review. Here comment a late comment on the .well-known comment I have done some research and my opinion is to not create .well-known resources. When reading up on well-known I can see that two ways of using is has evolved. The first one is to have a path under .well-known (e.g. /.well-known/ace) that returns a set of links to the endpoints defined by the specification. (When reading the .well-known RFC (RFC5785) this is how I interpret it). In this case it would be easy to add .well-known support later on (maybe for both vanilla OAuth and the ACE flavor). The second solution I have seen is to place yourendpoints under the .well-known prefix (e.g. /.well-known/ace/token) this is how EST does it /.well-known/est/simpleenroll, /.well-known/est/cacerts etc. I don’t think to mandate this solution is a good solution for the simple reason that the path becomes long and requires several unnecessary bytes. Looking at the OAuth 2.0 framework I can see that they have not registered .well-known paths and also phrased the language around endpoints slightly differently. In the ace framework text we talk about the '/token' endpoint, the slash gives the reader the impression that this is a specific location while OAuth talks about the 'token' endpoint i.e. giving the impression that the path can be anything. I therefor suggest that we to start with change '/token' to 'token', '/introspection' to 'introspection' and '/authz-info' to 'authz-info' //Samuel On Tue, Aug 8, 2017 at 5:02 PM, Ludwig Seitz wrote: > On 2017-08-07 19:57, Jim Schaad wrote: > > 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. >>> >>> I'm not sure what problem that would solve. That C binds the token to a >>> key it doesn't own? What benefit would C have from that? >>> >>> If C wants to relay a token to a "friend" it could always share the >>> pop-key with said friend. >>> >> >> If I can fool C into thinking that my key is it's key, when the process is >> finished the RS has an access token with the privileges of C, but with my >> key. I now can do anything that C would be able to do. This would only >> need to be done the first time the AC sees the key as it could keep track >> that the key is associated with C for later requests. >> >> > Ok, we could fix this by requiring that the key used by C when > authenticating to AS is the one that is used as PoP key. > > > 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". >>> >>> I'm just reiterating the definition of the scope parameter from the >>> OAuth spec. I think Carsten's approach can be modified to fit into that >>> spec. >>> >> >> A sentence that says that other methods of doing scopes is permitted would >> satisfy my desires. >> > > I would favor a solution that says that scopes are strings by default, > unless the AS and the RS specifically agree on something else. That way an > implementation does not have to deal with binary data by default. > > 7. In section 5 - 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. >>> > Yes the intention is to allow profiles to specify JSON (or something >>> else) as data format instead of CBOR. >>> >> >> If one were to be using JSON why would one not just use OAuth rather than >> ACE? If JSON is really going to be a legal option then I think it should >> be >> fully fleshed out as part of this document. Otherwise you might end up >> with >> MTI problems. >> > > Sounds reasonable to me, I'll propose that change > > > >> 10. Section 5.4 appears to create a new endpoint that has not been discussed in other contexts. Is this intentional? >>> >>> No that's just an existing OAuth endpoint. Since I've had mostly on >>> client credentials in mind, this endpoint wasn't discussed that much. >>> >>> My impression is that this endpoint would mostly be used by >>> non-constrained clients (towards the obviously non-constrained AS), and >>> therefore it wouldn't need an ACE profiling, it could just be used as >>> specified in OAuth. >>> >> >> You might think about moving the out-of-scope statement closer to the >> front >> of the section so that is clearer. >> >> > Ok I will
Re: [Ace] Review of draft-ietf-ace-oauth-authz-06
On 2017-08-07 19:57, Jim Schaad wrote: 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. I'm not sure what problem that would solve. That C binds the token to a key it doesn't own? What benefit would C have from that? If C wants to relay a token to a "friend" it could always share the pop-key with said friend. If I can fool C into thinking that my key is it's key, when the process is finished the RS has an access token with the privileges of C, but with my key. I now can do anything that C would be able to do. This would only need to be done the first time the AC sees the key as it could keep track that the key is associated with C for later requests. Ok, we could fix this by requiring that the key used by C when authenticating to AS is the one that is used as PoP key. 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". I'm just reiterating the definition of the scope parameter from the OAuth spec. I think Carsten's approach can be modified to fit into that spec. A sentence that says that other methods of doing scopes is permitted would satisfy my desires. I would favor a solution that says that scopes are strings by default, unless the AS and the RS specifically agree on something else. That way an implementation does not have to deal with binary data by default. 7. In section 5 - 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. Yes the intention is to allow profiles to specify JSON (or something else) as data format instead of CBOR. If one were to be using JSON why would one not just use OAuth rather than ACE? If JSON is really going to be a legal option then I think it should be fully fleshed out as part of this document. Otherwise you might end up with MTI problems. Sounds reasonable to me, I'll propose that change 10. Section 5.4 appears to create a new endpoint that has not been discussed in other contexts. Is this intentional? No that's just an existing OAuth endpoint. Since I've had mostly on client credentials in mind, this endpoint wasn't discussed that much. My impression is that this endpoint would mostly be used by non-constrained clients (towards the obviously non-constrained AS), and therefore it wouldn't need an ACE profiling, it could just be used as specified in OAuth. You might think about moving the out-of-scope statement closer to the front of the section so that is clearer. Ok I will try to clarify this. 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. The summary of what a profile needs to specify is collected in Appendix C currently. This appendix reiterates points that are spread out (in contextually appropriate places) in the main body of the spec. You should have an early pointer to this so people know it is there and read it then. Done. 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. This seems to be a "it depends" issue. We should have some text on this, the security considerations seem the right place to me for this. Creating issue. I think that this should be part of the "main" text and goes to what St Johns (I think it was him) brought up at the mic where it needs to be clear someplace what the security assumptions/requirements are for each leg of the conversation are that a profile needs to be sure to include. And how using different profiles might interact. Note that in discussion with Hannes today, he came up with the very reasonable scenario of C<->AS with DTLS/CoAP and C<->RS with TLS/MQTT. 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. Are you referring to the "nonce" that can be part of the AS discovery message? I'm not sure if that should go in this document or in a separate draft. What does the group think? I am referring to mor
Re: [Ace] Review of draft-ietf-ace-oauth-authz-06
Responses in line, I have trimmed things which did not seem to need a response. Jim > -Original Message- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Ludwig Seitz > Sent: Monday, August 7, 2017 6:04 AM > To: ace@ietf.org > Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz-06 > > On 2017-08-04 23:41, Jim Schaad wrote: > > As promised I finally got finished with this review. > > Thank you for your very thorough review Jim. Comments inline (note that > there are a few questions as well). > > /Ludwig > > > > > > 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. > > I've added an issue to our issue tracker on this. However I would think that > this is something that would need to apply to OAuth as well. I would agree that it makes sense to have OAuth deal with this issue as well. It is probably less of an issue for /token if the client always gets this from the RS and does not try to find it on its own. The /authz-info point is probably more significant. Be sure to catch Olaf's comment on using a resource type as another way to identify this. > > > > 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. > > I'm not sure what problem that would solve. That C binds the token to a > key it doesn't own? What benefit would C have from that? > > If C wants to relay a token to a "friend" it could always share the > pop-key with said friend. If I can fool C into thinking that my key is it's key, when the process is finished the RS has an access token with the privileges of C, but with my key. I now can do anything that C would be able to do. This would only need to be done the first time the AC sees the key as it could keep track that the key is associated with C for later requests. > > > > 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". > > I'm just reiterating the definition of the scope parameter from the > OAuth spec. I think Carsten's approach can be modified to fit into that > spec. A sentence that says that other methods of doing scopes is permitted would satisfy my desires. > > > > 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. > > You mean section 5 right? Yes - this should have been section 5. > > Yes the intention is to allow profiles to specify JSON (or something > else) as data format instead of CBOR. If one were to be using JSON why would one not just use OAuth rather than ACE? If JSON is really going to be a legal option then I think it should be fully fleshed out as part of this document. Otherwise you might end up with MTI problems. > > 10. Section 5.4 appears to create a new endpoint that has not been > > discussed in other contexts. Is this intentional? > > No that's just an existing OAuth endpoint. Since I've had mostly on > client credentials in mind, this endpoint wasn't discussed that much. > > My impression is that this endpoint would mostly be used by > non-constrained clients (towards the obviously non-constrained AS), and > therefore it wouldn't need an ACE profiling, it could just be used as > specified in OAuth. You might think about moving the out-of-scope statement closer to the front of the section so that is clearer. > > > > > 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. > > The summary of what a profile needs to specify is collected in Appendix > C currently. This appendix reiterates points that are spread out (in > contextually appropriate places) in the main body of the spec. You should have an early pointer to this so people know it is there and rea
Re: [Ace] Review of draft-ietf-ace-oauth-authz-06
On 2017-08-04 23:41, Jim Schaad wrote: As promised I finally got finished with this review. Thank you for your very thorough review Jim. Comments inline (note that there are a few questions as well). /Ludwig 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. I've added an issue to our issue tracker on this. However I would think that this is something that would need to apply to OAuth as well. 2. Add some of the actor terms to section 2- such as Resource Owner Ok, will do 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. I'm not sure what problem that would solve. That C binds the token to a key it doesn't own? What benefit would C have from that? If C wants to relay a token to a "friend" it could always share the pop-key with said friend. 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". I'm just reiterating the definition of the scope parameter from the OAuth spec. I think Carsten's approach can be modified to fit into that spec. 5. In section 3.2 - s/so- called// - don't be pejorative. Ok, I'll rephrase that 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. I've already made that change in the "insertDiscovery" branch (https://github.com/LudwigSeitz/ace-oauth/tree/insertDiscovery). 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. You mean section 5 right? Yes the intention is to allow profiles to specify JSON (or something else) as data format instead of CBOR. 8. Section 5.1 - Awkward language "If the client should to act" Yeah that whole section needed a review. Fixed. 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. My intention for the profiles is that they specify the communication (and communication security protocols). This MUST cover C <-> RS and MAY include AS <-> *any*. I agree there should be a default fallback for the MAY parts. Adding issue. 10. Section 5.4 appears to create a new endpoint that has not been discussed in other contexts. Is this intentional? No that's just an existing OAuth endpoint. Since I've had mostly on client credentials in mind, this endpoint wasn't discussed that much. My impression is that this endpoint would mostly be used by non-constrained clients (towards the obviously non-constrained AS), and therefore it wouldn't need an ACE profiling, it could just be used as specified in OAuth. 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. The summary of what a profile needs to specify is collected in Appendix C currently. This appendix reiterates points that are spread out (in contextually appropriate places) in the main body of the spec. 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. This seems to be a "it depends" issue. We should have some text on this, the security considerations seem the right place to me for this. Creating issue. 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. Are you referring to the "nonce" that can be part of the AS discovery message? I'm not sure if that should go in this document or in a separate draft. What does the group think? 13. Section 5.5.1 - I would like to see an AS field documented here so th that the 4 corner model can work. Could you be more specific about the
Re: [Ace] Review of draft-ietf-ace-oauth-authz-06
Jim Schaad writes: > 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. Another option would be more flexible: You could have a well-defined (and IANA-registered) resource type that allows linking to the token- introspect and authz-info endpoints. In the /.well-known/core of as.example.com, you would find ;rt="auth-request" or, in a resource directory, you could link to as.example.com's token endpoint as follows: ;rt="auth-request";anchor="coaps://as.example.com/" Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
