This is a combined reply from the team at the SEI that is looking at ACE for tactical environments
1.) Currently the framework requires the use of CBOR as data object format and of parameter name abbreviations. Some comments voiced the opinion that these requirements should be relaxed and the choice left to the profiles. I see the following options: a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED) b.) Remove all requirements (i.e. data format totally up to the profiles) c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing profiles to specify something else) What does the group think we should do? * Regarding the use of CBOR, Option c seems to be the best compromise between a and b. However, given that the goal of ACE is small, compact data formats that lead to small bandwidth and processing requirements, wouldn’t it make sense to require CBOR? Disclaimer that we are not familiar with all other IETF options: What would be other alternatives that provide the same small, compact data format? 2.) Should the work on Client Token (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) be in the draft or moved out to a separate document? Background: We designed Client Token to address the use cases where the client has intermittent connectivity and needs to receive information from the AS. * No real opinion here. It really depends on where the group thinks that it is applicable to things other than ACE and/or it is really optional and not an integral part of ACE. 3.) What is the relationship to the Token Binding Work at OAuth (https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ? 3-bis.) To me it seems like this could go into a profile of the ACE framework. Would someone be willing to write such a draft? * Not very familiar with the token binding work. 4.) What parameters to put into the response to an unauthorized request (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)? Jim Schaad suggested to add information about the audience and scope the RS expects to grant access to the given resource (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) We have had some discussion on this topic already, but I have not seen a conclusive "decision" by the group (if such a thing can exist) as to what to do. * For tactical environments (or any environment with higher security requirements than the home, for example) providing additional information to a potentially unauthorized request is not a good idea. However, we do understand that this may make sense in other use cases. The suggestion made before along the lines of “It should be up to the deployment what it wants to reveal” would make sense, as long as it is not required. Thus, in our case, we would NOT implement it. But, there are likely other use cases in which it would be useful to do so. 5.) Francesca suggested to allow the AS to return a list of possible profiles to the client in response to an access token request. Currently only one profile is selected and optionally returned by the AS (it could even be implicit and not be returned at all). Background: The way I was thinking this should work was that both the client and the RS need to be registered at the AS in order for the exchanges to work. I made the assumption (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) that the AS would already know which profiles both C and RS support, and thus just select the ideal one. What does the group think, should we instead allow for a list of profiles and let the client select which one to use? * Again, from the point of view of tactical environments, because we “enforce” pairing between Client and the AS, the AS should have enough knowledge to decide which profile to use. But, what if there is more than one profile that works for both. Does the AS really have enough information to select the “ideal”? In that case, something like what Francesca is suggesting would make sense. However, I think it would be useful for us to better understand the use cases for multiple profiles to see if it really makes sense. The potential need for this negotiation is understood, but it also makes the whole process longer and more complex. Unless we have good use cases, and an understanding that this might be the norm rather than the exception, then it would make sense to add to ACE. If not, maybe an experimental RFC? ______________________________________________ Grace A. Lewis, Ph.D. Principal Researcher Carnegie Mellon Software Engineering Institute Software Solutions Division (SSD) Tactical Technologies Group (TTG) 4500 Fifth Ave. Pittsburgh, PA 15213 Phone: (412) 268-5851 http://www.sei.cmu.edu/staff/glewis From: Ace <[email protected]> on behalf of Ludwig Seitz <[email protected]> Date: Tuesday, November 14, 2017 at 4:59 AM To: "[email protected]" <[email protected]> Subject: [Ace] Questions about draft-ietf-ace-oauth-authz Hello ACE, during the IETF 100 session there were a number of questions on draft-ietf-ace-oauth-authz that I would like to bring to the list for feedback: 1.) Currently the framework requires the use of CBOR as data object format and of parameter name abbreviations. Some comments voiced the opinion that these requirements should be relaxed and the choice left to the profiles. I see the following options: a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED) b.) Remove all requirements (i.e. data format totally up to the profiles) c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing profiles to specify something else) What does the group think we should do? 2.) Should the work on Client Token (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) be in the draft or moved out to a separate document? Background: We designed Client Token to address the use cases where the client has intermittent connectivity and needs to receive information from the AS. 3.) What is the relationship to the Token Binding Work at OAuth (https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ? 3-bis.) To me it seems like this could go into a profile of the ACE framework. Would someone be willing to write such a draft? 4.) What parameters to put into the response to an unauthorized request (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)? Jim Schaad suggested to add information about the audience and scope the RS expects to grant access to the given resource (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) We have had some discussion on this topic already, but I have not seen a conclusive "decision" by the group (if such a thing can exist) as to what to do. 5.) Francesca suggested to allow the AS to return a list of possible profiles to the client in response to an access token request. Currently only one profile is selected and optionally returned by the AS (it could even be implicit and not be returned at all). Background: The way I was thinking this should work was that both the client and the RS need to be registered at the AS in order for the exchanges to work. I made the assumption (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) that the AS would already know which profiles both C and RS support, and thus just select the ideal one. What does the group think, should we instead allow for a list of profiles and let the client select which one to use? Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
