Re: [Ace] Question about the response to an unauthorized request

[Grace Lewis]

Ludwig,

I do believe that this would reveal too much information to an attacker, 
especially if IoT devices are being deployed in “hostile environments.” While 
this may be appropriate in a home and potentially industry setting, it is 
certainly not appropriate in a more contested setting.

The UMA approach presented by Cigdem is an option, given that the RS is able to 
verify with the AS that the request comes from a client that is currently 
paired to the AS. However, I do agree that reachability to the AS may not 
always be possible.

If this is included as an option, the security considerations would need to be 
clearly noted.


  *   Grace

__
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  on behalf of Cigdem Sengul 

Date: Wednesday, October 25, 2017 at 10:27 AM
To: Ludwig Seitz 
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Question about the response to an unauthorized request

Hello,

To bring a different view, I wanted to mention Kantara UMA (User Managed 
Access) approach to this problem. (I participated in the UMA v2.0 development 
this year, so had the chance to be more familiar with the new drafts.)

In UMA,  the resource server must respond to a client's tokenless 
(unauthorized) access attempt by obtaining a permission ticket from the 
authorization server.
If RS is able to obtain a permission ticket from the AS, RS returns this ticket 
to the client also with  the AS uri to aid AS discovery.

UMA handles resources (resource sets, permissions etc.) differently but the 
permission requests (from RS to AS)  can be considered as signaling to the AS 
what audience/scope RS expects.

In ACE, there are limitations of course - i.e., RS may not always reach AS etc. 
 Nevertheless, it may be useful to think how other groups approach similar 
problems.

Best,
--Cigdem


On Mon, Oct 23, 2017 at 2:38 PM, Ludwig Seitz 
mailto:ludwig.se...@ri.se>> wrote:
Hello ACE,

Jim Schaad has brought up an interesting question [1] on 
draft-ietf-ace-oauth-authz [2]:

Currently when a client makes an unauthorized request to a resource server, it 
gets back the address of the authorization server and optionally a nonce (to 
prevent replay attacks).

Jim is suggesting to add hints to the audience and scope the resource server 
expects for accessing this resource.

I'm not sure whether that would not reveal too much information to a potential 
attacker.

What does the group think of this issue?

/Ludwig


[1] https://github.com/ace-wg/ace-oauth/issues/124
[2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Grace Lewis]

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

Hello ACE,

durin