Subject: [Ace] Questions about draft-ietf-ace-oauth-authz

From: Ludwig Seitz <[email-masked]>
Date: Tue, 14 Nov 2017 10:59:17 +0100

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Nov 2017 23:15:32 +0800

> On Nov 14, 2017, at 17:59, Ludwig Seitz <[email-masked]> wrote:
> 
> 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.
> c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing profiles to specify something else)
> 

Clearly (c) (RECOMMEND).
If is good to have a common way of doing this, but if a profile has a good reason to deviate, state that reason and deviate.

> 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 opinion on document splitting.

> 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
> 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.

It should be up to the deployment what it wants to reveal here.
So do provide a way to include this information, but do not require it.

> 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?

I’m not quite convinced about the use case, but I also don’t see much harm (this is a less-constrained, horizontal protocol).  SAM (AS) won’t necessarily be “closely familiar” with C, so C (or the CAM component of it) may be able to make a better choice.

Grüße, Carsten

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 17 Nov 2017 10:02:38 +0100

Ludwig Seitz <[email-masked]> writes:

> opinion that these requirements should be relaxed and the choice left
> to the profiles.

I am in favor for (a) but (c) would be the more flexible choice for a
future-proof framework.

> 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 opinion here.

> Jim Schaad suggested to add information about the audience and scope
> the RS expects to grant access to the given resource
> 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.

I suggest to add this information (as optional fields) to the
response so the client knows what to request from AS.

> 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).
>
> that the AS would already know which profiles both C and RS support,
> and thus just select the ideal one.
>

I think that negotiating the profile between C and AS is inevitable but
returning a list of profiles with the AS-to-Client response might be
difficult because there might be profile-specific claims that need to be
included as well.

I prefer a client-driven negotiation mechanism where the client may send
the list of profiles it supports, and the server picks one of this list
or returns an error if the resource server does not support any of
these. If the client does not send this list, AS just picks one as
described by Ludwig.

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 17 Nov 2017 10:38:51 +0100

> these. If the client does not send this list, AS just picks one as

Interesting point. We had a negotiation mechanism for profiles in an 
earlier version of the draft, and decided to pull it out again because 
it felt over-engineered, given the fact that the AS would know what 
profiles both C and RS support.

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 17 Nov 2017 15:47:36 +0100

see inline

On Tue, Nov 14, 2017 at 10:59 AM, Ludwig Seitz <[email-masked]> wrote:

> 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 vote for *c*

>
>
> 2.) Should the work on Client Token (https://tools.ietf.org/html/d
> raft-ietf-ace-oauth-authz-08#section-5.7.4) be in the draft or moved out
> to a separate document?
>
> client has intermittent connectivity and needs to receive information from
> the AS.
>

I vote for separate document for Client Token, I like the idea but I think
it comes as a natural extension to the framework.

>
> 3.) What is the relationship to the Token Binding Work at OAuth (
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ?
>

Agree

>
> 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)?
>

I liked Carstens comment  "It should be up to the deployment what it wants
to reveal here. So do provide a way to include this information, but do not
require it."
So +1 on that.

> conclusive "decision" by the group (if such a thing can exist) as to what
> to do.
>
> exchanges to work. I made the assumption (https://tools.ietf.org/html/d
> raft-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?
>

I think AS should return one profile, I would like to avoid negotiation,
for now at least.

>
>
> Regards,
>
> Ludwig
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Grace Lewis <[email-masked]>
Date: Wed, 22 Nov 2017 19:46:47 +0000

This is a combined reply from the team at the SEI that is looking at ACE for tactical environments

  *   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?

  *   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.

  *   Not very familiar with the token binding work.

  *   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.

  *   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-masked]> on behalf of Ludwig Seitz <[email-masked]>
Date: Tuesday, November 14, 2017 at 4:59 AM
To: "[email-masked]" <[email-masked]>
Subject: [Ace] Questions about draft-ietf-ace-oauth-authz

Hello ACE,

Regards,

Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace