Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
On Tue, Nov 26, 2019 at 7:20 AM Daniel Fett wrote: > Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen: > > Depending on its implementation the client might simply extract all data > > contained in the Client Information Response and use it for > > authorizations with the specific AS. > > We were able to confirm that one popular open-source library behaves in > > this exact way. It stores the redirect URI contained in the Client > > Information Response and uses it for Authorization Requests with the > > A-AS although it differs from the redirect URI in the Client > > Registration Request. > > The client uses untrusted, unverified data to make its decision on what > redirect URI to use. > > Nonetheless, we should definitely mention this in the BCP! > RFC 7591 basically says that the AS can replace/substitute/augment any of the client registration info and leaves it up to the client as to how to handle differences from what was requested. There are quite a few things that just wouldn't make sense for the AS to change and some like redirect URI that could potentially be dangerous. Perhaps the BCP should mention the situation and recommend that a client not proceed if the redirect URIs (and others?) don't align with what was requested. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: New Version Notification for draft-fett-oauth-dpop-03.txt
On Mon, Dec 2, 2019 at 4:35 PM Richard Backman, Annabelle wrote: > > Session cookies serve the same purpose in web apps as access tokens for > APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments of > web apps or the techniques used to secure web apps are ok for APIs as well. > > "Security issues" is a loaded term, but if you mean that there are > practical risks that are not addressed by bearer tokens (whether they be > session cookies or access tokens) then yes, I think we both agree that > there are. Otherwise we wouldn't be discussing PoP, sender-constrained > tokens, etc. TLS-based solutions mitigate some risks, while leaving others > unmitigated. Depending on your use case and threat model, these risks may > or may not present practical threats. For my use cases, they do. > > Ultimately I'd like to mitigate these risks for both service APIs and web > applications. My focus is on service APIs for a couple reasons: > > 1. Interoperability is more important when the sender and recipient aren't > necessarily owned by a single entity. I can do proprietary things in > JavaScript if I want to just as I can in client SDKs, but this breaks down > if my API implements a standard protocol and is expected to work with > off-the-shelf clients and/or implementations from other vendors. > > 2. Web applications are just a special subset of service APIs that happens > to be accessed via a browser. A solution for service APIs ought to be > reusable for web applications, or at least serve as a foundation for their > solution. > > >- Have you seen this kind of proxies intercepting the connection from > on-prem service deployments to service provider? I’m asking because I > thought the main use case was to intercept employees PC internet traffic. > > I'm working from second-hand knowledge here, but like most things in the > enterprise world, it depends. Separating employee device outbound traffic > from internal service outbound traffic requires some level of > sophistication, be it in network topology, routing rules, or configuration > rules on the TLIS appliance. > > Yeah, many major enterprises have these kinds of inspection services, Take a look at the following example: https://www.zscaler.com/resources/data-sheets/zscaler-internet-access.pdf > >- Are you saying this kind of proxy does not support mutual TLS at > all? > > From what I understand, at the very least mTLS is not universally > supported. There may be some vendors that support it, but it's not > guaranteed. The documentation for Symantec's SSL Visibility product [1] > indicates that sessions using client certificates will be rejected unless > they are exempted based on destination whitelisting Yes, that is my experience too. > (which is problematic when the destination may be a general-purpose cloud > service provider). > Is there a use case that would require you to do that? If I have a service that is hosted on AWS, then the exception would be for my service, not for AWS in general. Regards, Rifaat > > > On the other hand, I would expect these kind of proxy to understand a > lot about the protocols running through it, otherwise they cannot fulfil > their task of inspecting this traffic. > > Maybe, maybe not. In any case there's a difference between understanding > HTTP or SMTP or P2P-protocol-du-jour and understanding the > application-level protocol running on top of HTTP. There hasn't been any > need for these proxies to understand OAuth 2.0 thus far. > > [1]: > https://origin-symwisedownload.symantec.com/resources/webguides/sslv/45/Content/Topics/troubleshooting/Support_for_Client_Cert.htm > – > Annabelle Richard Backman > AWS Identity > > > On 12/1/19, 7:41 AM, "Torsten Lodderstedt" 40lodderstedt@dmarc.ietf.org> wrote: > > > Annabelle, > > > Am 27.11.2019 um 02:46 schrieb Richard Backman, Annabelle < > richa...@amazon.com>: > > > > Torsten, > > > > I'm not tracking how cookies are relevant to the discussion. > > I’m still trying to understand why you and others argue mTLS cannot be > used in public cloud deployments (and thus focus on application level PoP). > > Session cookies serve the same purpose in web apps as access tokens > for APIs but there are much more web apps than APIs. I use the analogy to > illustrate that either there are security issues with cloud deployments of > web apps or the techniques used to secure web apps are ok for APIs as well. > > Here are the two main arguments and my conclusions/questions: > > 1) mTLS it’s not end 2 end: although that’s true from a connection > perspective, there are solutions employed to secure the last hop(s) between > TLS terminating proxy and service (private net, VPN, TLS). That works and > is considered secure enough for (session) cookies, it should be the same > for access tokens. > > 2) TLS terminating proxies do not forward cert
Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
Am 03.12.19 um 10:21 schrieb Christian Mainka:
> Hi,
>
> according to [1], countermeasure (1) describes to
>
>> configure [the] authorization servers to return an AS identitifier
> ("iss") and the "client_id" for which a code or token was issued in the
> authorization response.
>
> So if an MixUp attack is running, the victim contacts A-AS but is
> redirected to to H-AS [2].
> The AS adds - according to the countermeasure - two additional
> parameters to the authorization response: client_id and issuer. Both
> values are set by H-AS, so it returns H-issuer and H-client_id.
I asked for clarification because I would assume that the mix-up attack
is twharted at this point. The client would see H-issuer instead of
A-issuer, to which it sent the user.
I agree that the client_id is not of much value here.
-Daniel
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
Hi,
according to [1], countermeasure (1) describes to
> configure [the] authorization servers to return an AS identitifier
("iss") and the "client_id" for which a code or token was issued in the
authorization response.
So if an MixUp attack is running, the victim contacts A-AS but is
redirected to to H-AS [2].
The AS adds - according to the countermeasure - two additional
parameters to the authorization response: client_id and issuer. Both
values are set by H-AS, so it returns H-issuer and H-client_id.
But: during the registration of the client on A-AS (rfc7591), it can return:
HTTP/1.1 201 Created
{
"client_id": "H-client_id",
"redirect_uris": [
"https://client.example.org/honest-callback;,
}
So if the client receives the client_id in the authorization response,
it is unable to distinguish to which AS the client_id belongs to - they
have the same values.
This does not hold for the issuer parameter in the authorization
response, because it is set by H-AS and independent of and not set
during the Dynamic Client Registration Protocol.
So basically, it is the same problem as with the redirect_uri.
Regards
Christian
[1]:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.4.2
[2]: Step 4 in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.4.1
On 02.12.19 11:26, Daniel Fett wrote:
> Am 02.12.19 um 10:05 schrieb Christian Mainka:
>> I think this problem is not only restricted to the redirect_uri.
>> Regarding countermeasure (1), also the A-AS can return the same
>> client_id as the client uses on the H-AS.
>>
>> TL;DR: In countermeasure (1), only the issuer prevents MixUp, the
>> client_id parameter can be faked as well during the registration of the
>> client (especially if Dynamic Client Registration is used).
> What would be the issuer identifiers of A-AS and H-AS in this case be,
> as seen by the client?
>
> -Daniel
>
>
>
--
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany
Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany
Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Meeting Minutes
Here are the meeting minutes from the Singapore IETF meeting: https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 Tony was our scribe. Thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
