I am fairly new to this working group (and the IETF in general), so I
will probably need some guidance, but I would be happy to help better
defining mix-up preventions. I will start to work on an ID.

Best regards,
Karsten

On 29.08.2020 14:34, Torsten Lodderstedt wrote:
>> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen 
>> <karsten.meyerzuselhau...@hackmanit.de> wrote:
>>
>> Hi all,
>>
>> I think we all agree that proper countermeasures of mix-up attacks should 
>> definitely be part of the BCP and 2.1 due to the severe impact successful 
>> mix-up attacks have.
>> Theoretically speaking every client which supports multiple AS is 
>> potentially vulnerable to mix-up attacks. While in practice it might seem 
>> unlikely it is possible that one of the honest AS the client supports gets 
>> compromised and can be utilized for a mix-up attack. 
>>
>> In a previous thread of last November 
>> (https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/) I 
>> discussed why “use distinct redirect URIs for each AS” is not an effective 
>> countermeasure against mix-up attacks (if dynamic client registration is 
>> used). I would argue that this is especially important for mobile 
>> applications, SPAs, and other native applications because it is very common 
>> for them to use dynamic client registration. Many iOS applications now must 
>> support multiple AS since Apple forces the support for “Sign in with Apple” 
>> if any single sign-on provider is supported. This policy makes mix-up 
>> attacks applicable.
>>
>> I fully agree with Daniel, Brian, and Mike that it is important to define 
>> and register the “iss” parameter properly to ensure that both clients and AS 
>> understand and use it in the correct way. I understand that OAuth 2.1 is not 
>> meant to introduce and define new parameters but I strongly suggest that the 
>> “iss” parameter should be introduced and defined elsewhere so that it can be 
>> natively included in 2.1. In other words the “iss” parameter should be 
>> integrated in 2.1 the same way PKCE is: the initial definition of the 
>> parameter(s) is in another document (RFC 7636 in the case of PKCE) and then 
>> included in 2.1.
>>
>> What do you think would be the best place to define and register the “iss” 
>> parameter? Would it be worthwhile to reactivate and update 
>> “draft-ietf-oauth-mix-up-mitigation”?
> That’s a decision of the authors. Alternatively, a new small draft (referring 
> to the BCP’s attack description) should do the job as well. Mind to write an 
> ID? :-)
>
>> Best regards,
>>
>> Karsten
>>
>>
>>
>> On 18.06.2020 22:49, Mike Jones wrote:
>>> I support documenting the use of the issuer to mitigate mix-up attacks.  
>>> Note that while issuer was first defined by OpenID Connect, it became art 
>>> of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata.
>>>  
>>>                                                        -- Mike
>>>  
>>> From: OAuth <oauth-boun...@ietf.org> On Behalf Of Brian Campbell
>>> Sent: Thursday, June 18, 2020 1:32 PM
>>> To: Daniel Fett <f...@danielfett.de>
>>> Cc: oauth <oauth@ietf.org>
>>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited
>>>  
>>> In my (probably simplistic) understanding of things, the root underlying 
>>> issue that allows for mix-up in its variations is the lack of anything 
>>> identifying the AS in the authorization response. Following from that, 
>>> introducing and using an `iss` authorization response parameter has always 
>>> seemed like the most straightforward approach for mitigating the issue 
>>> (which was part of the draft-ietf-oauth-mix-up-mitigation but other 
>>> parameters were also included and, for reasons I'm not sure about, interest 
>>> in that work faded in favor of telling clients to use per AS redirect URIs) 
>>> . Though for the `iss` authorization response parameter to be effective, 
>>> all parties involved need to know about it and act on it. So I think it'd 
>>> need to be something more than a passing recommendation in the BCP. It 
>>> should be defined, registered, explained, etc.. Actually introducing a new 
>>> parameter is maybe going beyond the expected scope of the BCP (or 2.1). But 
>>> maybe that's ok, if we're at least more intentional about it. 
>>>  
>>> On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett <f...@danielfett.de> wrote:
>>> Hi all,
>>> I was wondering if we should move towards introducing and (more explicitly) 
>>> recommending the iss parameter in the security BCP, for the reasons laid 
>>> out below and in the article (which is now 
>>> athttps://danielfett.de/2020/05/04/mix-up-revisited/).
>>>  
>>> Any thoughts on this?
>>>  
>>> -Daniel
>>>  
>>> Am 04.05.20 um 19:34 schrieb Daniel Fett:
>>> Hi all,
>>>
>>> to make substantiated recommendations for FAPI 2.0, the security 
>>> considerations for PAR, and the security BCP, I did another analysis on the 
>>> threats that arise from mix-up attacks. I was interested in particular in 
>>> two questions:
>>>
>>>     • Does PAR help preventing mix-up attacks?
>>>     • Do we need JARM to prevent mix-up attacks?
>>> I wrote down several attack variants and configurations in the following 
>>> document: https://danielfett.github.io/notes/oauth/Mix-Up%20Revisited.html
>>>
>>> The key takeaways are:
>>>
>>>     • The security BCP needs to make clear that per-AS redirect URIs are 
>>> only sufficient if OAuth Metadata is not used to resolve multiple issuers. 
>>> Otherwise, per-Issuer redirect URIs or the iss parameter MUST be used.
>>>     • PAR-enabled authorization servers can protect the integrity better 
>>> and protect against Mix-Up Attacks better if they ONLY accept PAR requests.
>>>     • We should emphasize the importance of the iss parameter (or issuer) 
>>> in the authorization response. Maybe introduce this parameter in the 
>>> security BCP or another document?
>>>     • Sender-constrained access tokens help against mix-up attacks when the 
>>> access token is targeted.
>>>     • Sender-constraining the authorization code (PAR + PAR-DPoP?) might be 
>>> worth looking into.
>>> I would like to hear your thoughts!
>>>
>>> -Daniel
>>>
>>>  
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> 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
>> -- 
>> Karsten Meyer zu Selhausen
>> IT Security Consultant
>> Phone:       +49 (0)234 / 54456499
>> Web: 
>> https://hackmanit.de
>>  | IT Security Consulting, Penetration Testing, Security Training
>>
>> Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID 
>> Connect am 24.09 + 25.09:
>>
>> https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020
>>
>>
>> Hackmanit GmbH
>> Universitätsstraße 60 (Exzenterhaus)
>> 44789 Bochum
>>
>> Registergericht: Amtsgericht Bochum, HRB 14896
>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
>> Christian Mainka, Dr. Marcus Niemietz
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:  +49 (0)234 / 54456499
Web:    https://hackmanit.de | IT Security Consulting, Penetration Testing, 
Security Training

Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect 
am 24.09 + 25.09:
https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
Christian Mainka, Dr. Marcus Niemietz

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to