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
