[Ace] Question about the response to an unauthorized request

[Cigdem Sengul]

Hello Ludwig,

This is UMA. The ticket is a way for RS to register client’s request with
AS, giving it the ability to communicate other scopes etc related to
request.

Client presents the ticket to AS to obtain an access token. (So ticket is
not an access token).

I brought UMA ticket up to respond Jim’s original question of:
“Jim is suggesting to add hints to the audience and scope the resource
server expects for accessing this resource.”

The ticket is a reference to audience/scopes the rs communicated to as with
respect to the request.

I already touched upon the feasibility of this in ACE given that rs and as
may not be always connected.

More info:
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-08.html#permission-endpoin

t
 Thanks,


On Monday, November 6, 2017, Ludwig Seitz > wrote:

> On 2017-11-05 18:37, Cigdem Sengul wrote:
>
>> In the case of rogue requestor being the client, it does not have
>> visibility into what is included in the permission ticket ( ticket is a
>> reference returned by rs to be presented at as). It may dos Rs with
>> requests, which rs may implement a solution like rate limiting (not
>> described in uma).
>>
>> The as api for rs is protected via an oauth2 token (PAT) which rs must
>> present for permission registration (as well as for other functions). This
>> Pat allows as to map es’s request to a particular Ro. Rs can only ask for
>> permissions for the resources and scopes it already registered with the As.
>>
>> Hope I was able to clarify.
>>
>> Thanks,
>> —Cigdem
>>
>>
> Just for even more clarity: What you (or is it UMA?) call ticket is
> equivalent to the OAuth access tokens?
>
> /Ludwig
>
> --
> 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] Question about the response to an unauthorized request

[Cigdem Sengul]

In the case of rogue requestor being the client, it does not have
visibility into what is included in the permission ticket ( ticket is a
reference returned by rs to be presented at as). It may dos Rs with
requests, which rs may implement a solution like rate limiting (not
described in uma).

The as api for rs is protected via an oauth2 token (PAT) which rs must
present for permission registration (as well as for other functions). This
Pat allows as to map es’s request to a particular Ro. Rs can only ask for
permissions for the resources and scopes it already registered with the As.

Hope I was able to clarify.

Thanks,
—Cigdem

On Wednesday, October 25, 2017, Jim Schaad <i...@augustcellars.com> wrote:

> So you would be doing based on something like the address of the requestor
> or the content of the request.  I would complete understand the first
> half.  Is there any way to prevent a rouge requestor from asking for
> information – or are you just relying on a closed system?
>
>
>
> *From:* Cigdem Sengul [mailto:cigdem.sen...@gmail.com
> <javascript:_e(%7B%7D,'cvml','cigdem.sen...@gmail.com');>]
> *Sent:* Wednesday, October 25, 2017 2:19 PM
> *To:* Jim Schaad <i...@augustcellars.com
> <javascript:_e(%7B%7D,'cvml','i...@augustcellars.com');>>
> *Cc:* Ludwig Seitz <ludwig.se...@ri.se
> <javascript:_e(%7B%7D,'cvml','ludwig.se...@ri.se');>>; ace@ietf.org
> <javascript:_e(%7B%7D,'cvml','ace@ietf.org');>
> *Subject:* Re: [Ace] Question about the response to an unauthorized
> request
>
>
>
> UMA assumes that  resource server knows “which authorization server to
> approach for the permission ticket and on which resource owner's behalf”
> deriving “the necessary information using cues provided by the structure of
> the API where the resource request was made, rather than by an access
> token. “
>
> On Wednesday, October 25, 2017, Jim Schaad <i...@augustcellars.com
> <javascript:_e(%7B%7D,'cvml','i...@augustcellars.com');>> wrote:
>
> How does the RS make an informed decision about who the client is given
> that it is a tokenless access request?
>
>
>
>
>
>
>
> *From:* Ace [mailto:ace-boun...@ietf.org] *On Behalf Of *Cigdem Sengul
> *Sent:* Wednesday, October 25, 2017 7:28 AM
> *To:* Ludwig Seitz <ludwig.se...@ri.se>
> *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 <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] Question about the response to an unauthorized request

[Jim Schaad]

So you would be doing based on something like the address of the requestor or 
the content of the request.  I would complete understand the first half.  Is 
there any way to prevent a rouge requestor from asking for information – or are 
you just relying on a closed system?

 

From: Cigdem Sengul [mailto:cigdem.sen...@gmail.com] 
Sent: Wednesday, October 25, 2017 2:19 PM
To: Jim Schaad <i...@augustcellars.com>
Cc: Ludwig Seitz <ludwig.se...@ri.se>; ace@ietf.org
Subject: Re: [Ace] Question about the response to an unauthorized request

 

UMA assumes that  resource server knows “which authorization server to approach 
for the permission ticket and on which resource owner's behalf” deriving “the 
necessary information using cues provided by the structure of the API where the 
resource request was made, rather than by an access token. “

On Wednesday, October 25, 2017, Jim Schaad <i...@augustcellars.com 
<mailto:i...@augustcellars.com> > wrote:

How does the RS make an informed decision about who the client is given that it 
is a tokenless access request?

 

 

 

From: Ace [mailto:ace-boun...@ietf.org 
<javascript:_e(%7B%7D,'cvml','ace-boun...@ietf.org');> ] On Behalf Of Cigdem 
Sengul
Sent: Wednesday, October 25, 2017 7:28 AM
To: Ludwig Seitz <ludwig.se...@ri.se 
<javascript:_e(%7B%7D,'cvml','ludwig.se...@ri.se');> >
Cc: ace@ietf.org <javascript:_e(%7B%7D,'cvml','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 <ludwig.se...@ri.se 
<javascript:_e(%7B%7D,'cvml','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 <tel:%2B46%280%2970-349%2092%2051> 

___
Ace mailing list
Ace@ietf.org <javascript:_e(%7B%7D,'cvml','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] Question about the response to an unauthorized request

[Cigdem Sengul]

UMA assumes that  resource server knows “which authorization server to
approach for the permission ticket and on which resource owner's behalf”
deriving “the necessary information using cues provided by the structure of
the API where the resource request was made, rather than by an access
token. “

On Wednesday, October 25, 2017, Jim Schaad <i...@augustcellars.com> wrote:

> How does the RS make an informed decision about who the client is given
> that it is a tokenless access request?
>
>
>
>
>
>
>
> *From:* Ace [mailto:ace-boun...@ietf.org
> <javascript:_e(%7B%7D,'cvml','ace-boun...@ietf.org');>] *On Behalf Of *Cigdem
> Sengul
> *Sent:* Wednesday, October 25, 2017 7:28 AM
> *To:* Ludwig Seitz <ludwig.se...@ri.se
> <javascript:_e(%7B%7D,'cvml','ludwig.se...@ri.se');>>
> *Cc:* ace@ietf.org <javascript:_e(%7B%7D,'cvml','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 <ludwig.se...@ri.se
> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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] Question about the response to an unauthorized request

[Jim Schaad]

I don’t think that this is going to reveal any more information to an attacker 
than would be available to an attacker that just asks the resource server for a 
resource w/o a token.  Currently that is expected to return the same 
information.  

 

One approach that would be good to note is that it might be reasonable to hide 
this information behind a security wall so that it is required that the client 
gets secure access to the RD before any additional information about the 
resource can be obtained.

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Grace Lewis
Sent: Wednesday, October 25, 2017 8:26 AM
To: Cigdem Sengul <cigdem.sen...@gmail.com>; Ludwig Seitz <ludwig.se...@ri.se>
Cc: ace@ietf.org
Subject: Re: [Ace] Question about the response to an unauthorized request

 

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 <ace-boun...@ietf.org <mailto:ace-boun...@ietf.org> > on behalf of 
Cigdem Sengul <cigdem.sen...@gmail.com <mailto:cigdem.sen...@gmail.com> >
Date: Wednesday, October 25, 2017 at 10:27 AM
To: Ludwig Seitz <ludwig.se...@ri.se <mailto:ludwig.se...@ri.se> >
Cc: "ace@ietf.org <mailto:ace@ietf.org> " <ace@ietf.org <mailto: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 <ludwig.se...@ri.se 
<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 <tel:%2B46%280%2970-349%2092%2051> 

___
Ace mailing list
Ace@ietf.org <mailto: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] Question about the response to an unauthorized request

[Jim Schaad]

How does the RS make an informed decision about who the client is given that it 
is a tokenless access request?

 

 

 

From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Cigdem Sengul
Sent: Wednesday, October 25, 2017 7:28 AM
To: Ludwig Seitz <ludwig.se...@ri.se>
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 <ludwig.se...@ri.se 
<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 <tel:%2B46%280%2970-349%2092%2051> 

___
Ace mailing list
Ace@ietf.org <mailto: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] 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 <ace-boun...@ietf.org> on behalf of Cigdem Sengul 
<cigdem.sen...@gmail.com>
Date: Wednesday, October 25, 2017 at 10:27 AM
To: Ludwig Seitz <ludwig.se...@ri.se>
Cc: "ace@ietf.org" <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 
<ludwig.se...@ri.se<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<tel:%2B46%280%2970-349%2092%2051>

___
Ace mailing list
Ace@ietf.org<mailto: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] Question about the response to an unauthorized request

[Cigdem Sengul]

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  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#se
> ction-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

[Ace] Question about the response to an unauthorized request

[Ludwig Seitz]

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