Re: [OAUTH-WG] [EXT] Re: Token substitution in DPoP
It's not a huge burden but does add some non-zero complexity to the protocol as well as size to the proof. And in my mind anyway, doing so would sort of beg the question as to having some similar treatment for authz codes and refresh tokens. Which can, of course, also be done. But adds more complexity. And then there are other grant types to consider (even not doing anything with them demands some consideration of them). I question if the benefit is sufficient to account for the cost in added complexity etc.. But anyway, with all that rambling said, I do plan to have this as a general item for discussion in the upcoming interim meeting. Which I hope will be an easier forum to better hash it out. On Mon, Nov 23, 2020 at 6:03 AM Michael A Peck wrote: > I agree with having the DPoP proof cover the access token (unless there's > some burden on the clients doing so that I'm unaware of). > > That would also limit the ability to pre-compute DPoP proofs with future > timestamps (I sent an email to the list about this on 1 April) if an > attacker can perform some kind of attack (XSS?) that temporarily allows > executing code in the context of the client - as it would prevent > generating DPoP proofs for access tokens that have not yet been issued. > > DPoP key rotation (e.g. "generating and using a new DPoP key for each new > authorization code grant" as suggested in section 2 of the DPoP draft) is a > good idea but as Justin says depends on the clients actually doing it, with > no real enforcement mechanism. > > Mike > > On 11/23/20, 6:52 AM, "OAuth on behalf of Justin Richer" < > oauth-boun...@ietf.org on behalf of jric...@mit.edu> wrote: > > Correct, but the choice of using different keys is entirely in the > hands of the client, as the AS accepts whatever key the client presents in > its initial DPoP proof to bind to the token. If it’s on the client to > prevent this kind of thing, we should at least mention it in the security > considerations. If it’s something we want to prevent wholesale, we should > expand the signature coverage to the access token, or at least a hash of > the token. > > — Justin > > > On Nov 20, 2020, at 9:30 PM, Nikos Fotiou wrote: > > > > Hi, > > The token is granted to a client based on the authorization grant > and not the client's key. Therefore, a client may use a different key per > token. At least this is an approach we are following. > > > > Best, > > Nikos > > > > -Original Message- > > From: OAuth On Behalf Of Justin Richer > > Sent: Friday, November 20, 2020 9:26 PM > > To: oauth > > Subject: [OAUTH-WG] Token substitution in DPoP > > > > While working on an implementation of DPoP recently, I realized that > the value of the access token itself is not covered by the DPoP signature > at all. What I’m wondering is whether or not this constitutes an attack > surface that we care about here. Here’s how it works: > > > > > > Let’s say that a client creates a DPoP key and uses that key to > request two tokens, T1 and T2, for different users, Alice and Bob, > respectively. Alice is malicious and wants to get Bob’s stuff. Alice > manages to get a hold of Bob’s token value, T2, through some means. > Normally DPoP wouldn’t let Alice create a new request using T2 since Alice > doesn’t have the client’s key. However, if Alice gets the client to create > a request for her using T1, she can copy the signature from that request > onto a new request using T2. Since the signature doesn’t cover the token > value and the key is the same, the RS should accept both requests, right? > > > > An important aspect is that the parts needed to make this attack > work are a little weird: you’d need access to a valid signed request from > the client with T1 as well as access to a valid T2 attached to the same key > in order to make this substitution. However, this is effectively the same > attack area that bearer tokens have in a lot of ways, since it doesn’t > require the attacker gaining access to the singing key to generate or > modify a signature, nor does it require the attacker to generate or modify > an access token (merely obtain one). > > > > > > I’d like to understand if this is an actual attack against DPoP. If > it isn’t, how is it countered by DPoP today? If it is, do we discuss in the > DPoP draft? I didn’t see a mention of it there. If it’s not, should we > discuss it there? > > > > > > The old OAuth PoP draft mitigates this attack by putting the access > token itself inside the signature body instead of a second header. Another > option would be to include a hash of the token value (such as OIDC’s > “at_hash” method used in ID Tokens) in the DPoP payload. With either of > these approaches, Alice having access to T1, T2, and a signed message for > T1 does not allow her to use T2 effectively. > > > > — Justin > >
Re: [OAUTH-WG] Token substitution in DPoP
The extent of the weirdness needed leads me to feel that it's not a threat that's in scope. To copy the proof signature from a request with T1 onto a new request using T2, Alice would need access to the first request, which is made directly from client to RS. That's not possible for a web server client so the client would need to be running on Alice's machine/device. Such on device clients aren't typically going to be acting on behalf of multiple users. Or if they are, will need to do a lot more to securely segment the user execution environments from each other. Most of which is outside what can be done at this protocol application level. On Fri, Nov 20, 2020 at 12:26 PM Justin Richer wrote: > While working on an implementation of DPoP recently, I realized that the > value of the access token itself is not covered by the DPoP signature at > all. What I’m wondering is whether or not this constitutes an attack > surface that we care about here. Here’s how it works: > > > Let’s say that a client creates a DPoP key and uses that key to request > two tokens, T1 and T2, for different users, Alice and Bob, respectively. > Alice is malicious and wants to get Bob’s stuff. Alice manages to get a > hold of Bob’s token value, T2, through some means. Normally DPoP wouldn’t > let Alice create a new request using T2 since Alice doesn’t have the > client’s key. However, if Alice gets the client to create a request for her > using T1, she can copy the signature from that request onto a new request > using T2. Since the signature doesn’t cover the token value and the key is > the same, the RS should accept both requests, right? > > An important aspect is that the parts needed to make this attack work are > a little weird: you’d need access to a valid signed request from the client > with T1 as well as access to a valid T2 attached to the same key in order > to make this substitution. However, this is effectively the same attack > area that bearer tokens have in a lot of ways, since it doesn’t require the > attacker gaining access to the singing key to generate or modify a > signature, nor does it require the attacker to generate or modify an access > token (merely obtain one). > > > I’d like to understand if this is an actual attack against DPoP. If it > isn’t, how is it countered by DPoP today? If it is, do we discuss in the > DPoP draft? I didn’t see a mention of it there. If it’s not, should we > discuss it there? > > > The old OAuth PoP draft mitigates this attack by putting the access token > itself inside the signature body instead of a second header. Another option > would be to include a hash of the token value (such as OIDC’s “at_hash” > method used in ID Tokens) in the DPoP payload. With either of these > approaches, Alice having access to T1, T2, and a signed message for T1 does > not allow her to use T2 effectively. > > — Justin > ___ > 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
[OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interim - AS Issuer Identifier in Authorization Response
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20201123T163954Z
ATTENDEE;CN="Web Authorization Protocol Working Group";ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAILTO:oauth-cha...@ietf.org
ORGANIZER;CN="Web Authorization Protocol Working Group":MAILTO:oauth-cha...@ietf.org
DTSTART;TZID=America/New_York:20201207T12
DTEND;TZID=America/New_York:20201207T13
LOCATION:https://ietf.webex.com/ietf/j.php?MTID=mb02e9742d3d655d8686ff7ae6f850c72
TRANSP:OPAQUE
SEQUENCE:1606149594
UID:a356a2ef-086f-4e07-b634-f0e536f06b4b
DESCRIPTION:\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=mb02e9742d3d655d8686ff7ae6f850c72\nMeeting number (access code): 178 473 9389\n\nMeeting password: d3tYccTfm77\n\n\n\nTAP TO JOIN FROM A MOBILE DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1784739389## tel:%2B1-650-479-3208,,*01*1784739389%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=mb27f3910196e796554d5a75d3ceede42\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:1784739...@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeting number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\nDial sip:1784739389.i...@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\nhttps://collaborationhelp.cisco.com/article/WBX29055\n\n\nIMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.\n
X-ALT-DESC;FMTTYPE=text/html:\ntable {\n border-collapse: separate; width =100%; border: 0; border-spacing: 0;}\n\ntr {\n line-height: 18px;}\n\na, td {\n font-size: 14px; font-family: Arial; color: #333; word-wrap: break-word; word-break: normal; padding: 0;}\n\n.title {\n font-size: 28px;}\n\n.image {\n width: auto; max-width: auto;}\n\n.footer {\n width: 604px;}\n\n.main {\n\n}@media screen and (max-device-width: 800px) {\n .title {\n font-size: 22px !important; }\n .image {\n width: auto !important; max-width: 100% !important; }\n .footer {\n width: 100% !important; max-width: 604px !important\n }\n .main {\n width: 100% !important; max-width: 604px !important\n }\n}\n\n\n\n \n \n \n \n\n\n\n\n\n \n\n \n When it's time, join the Webex meeting here.\n \n\n\n\n \n Meeting number (access code): 178 473 9389\n \n\n \n Meeting password:d3tYccTfm77\n\n\n \n \n\n \n \n https://ietf.webex.com/ietf/j.php?MTID=mb02e9742d3d655d8686ff7ae6f850c72; style="color:#FF; font-size:20px; text-decoration:none;">Join meeting\n \n \n\n \n \n\n \n\n\n Tap to join from a mobile device (attendees only) +1-650-479-3208,,1784739389## Call-in toll number (US/Canada) Join by phone 1-650-479-3208 Call-in toll number (US/Canada) https://ietf.webex.com/ietf/globalcallin.php?MTID=mb27f3910196e796554d5a75d3ceede42; style="text-decoration:none;font-size:14px;color:#00AFF9">Global call-in numbers \n\n\n\nJoin from a video system or applicationDial 1784739...@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. \n\nJoin using Microsoft Lync or Microsoft Skype for BusinessDial 1784739389.i...@lync.webex.com\n\n \n \n\n \n\n\n Need help? Go to http://help.webex.com; style="color:#049FD9; text-decoration:none;">http://help.webex.com\n \n\n\n \n \n \n\n
SUMMARY:OAuth WG Interim - AS Issuer Identifier in Authorization Response
PRIORITY:5
CLASS:PUBLIC
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
Webex_Meeting.ics
Description: application/ics
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-12-07
The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2020-12-07 from 12:00 to 13:00 America/Toronto (17:00 to 18:00 UTC). Agenda: This meeting is to discuss the OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response document: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01 Regards, Rifaat & Hannes Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mb02e9742d3d655d8686ff7ae6f850c72 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [EXT] Re: Token substitution in DPoP
I agree with having the DPoP proof cover the access token (unless there's some burden on the clients doing so that I'm unaware of). That would also limit the ability to pre-compute DPoP proofs with future timestamps (I sent an email to the list about this on 1 April) if an attacker can perform some kind of attack (XSS?) that temporarily allows executing code in the context of the client - as it would prevent generating DPoP proofs for access tokens that have not yet been issued. DPoP key rotation (e.g. "generating and using a new DPoP key for each new authorization code grant" as suggested in section 2 of the DPoP draft) is a good idea but as Justin says depends on the clients actually doing it, with no real enforcement mechanism. Mike On 11/23/20, 6:52 AM, "OAuth on behalf of Justin Richer" wrote: Correct, but the choice of using different keys is entirely in the hands of the client, as the AS accepts whatever key the client presents in its initial DPoP proof to bind to the token. If it’s on the client to prevent this kind of thing, we should at least mention it in the security considerations. If it’s something we want to prevent wholesale, we should expand the signature coverage to the access token, or at least a hash of the token. — Justin > On Nov 20, 2020, at 9:30 PM, Nikos Fotiou wrote: > > Hi, > The token is granted to a client based on the authorization grant and not the client's key. Therefore, a client may use a different key per token. At least this is an approach we are following. > > Best, > Nikos > > -Original Message- > From: OAuth On Behalf Of Justin Richer > Sent: Friday, November 20, 2020 9:26 PM > To: oauth > Subject: [OAUTH-WG] Token substitution in DPoP > > While working on an implementation of DPoP recently, I realized that the value of the access token itself is not covered by the DPoP signature at all. What I’m wondering is whether or not this constitutes an attack surface that we care about here. Here’s how it works: > > > Let’s say that a client creates a DPoP key and uses that key to request two tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s token value, T2, through some means. Normally DPoP wouldn’t let Alice create a new request using T2 since Alice doesn’t have the client’s key. However, if Alice gets the client to create a request for her using T1, she can copy the signature from that request onto a new request using T2. Since the signature doesn’t cover the token value and the key is the same, the RS should accept both requests, right? > > An important aspect is that the parts needed to make this attack work are a little weird: you’d need access to a valid signed request from the client with T1 as well as access to a valid T2 attached to the same key in order to make this substitution. However, this is effectively the same attack area that bearer tokens have in a lot of ways, since it doesn’t require the attacker gaining access to the singing key to generate or modify a signature, nor does it require the attacker to generate or modify an access token (merely obtain one). > > > I’d like to understand if this is an actual attack against DPoP. If it isn’t, how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? I didn’t see a mention of it there. If it’s not, should we discuss it there? > > > The old OAuth PoP draft mitigates this attack by putting the access token itself inside the signature body instead of a second header. Another option would be to include a hash of the token value (such as OIDC’s “at_hash” method used in ID Tokens) in the DPoP payload. With either of these approaches, Alice having access to T1, T2, and a signed message for T1 does not allow her to use T2 effectively. > > — Justin > ___ > 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token substitution in DPoP
Correct, but the choice of using different keys is entirely in the hands of the client, as the AS accepts whatever key the client presents in its initial DPoP proof to bind to the token. If it’s on the client to prevent this kind of thing, we should at least mention it in the security considerations. If it’s something we want to prevent wholesale, we should expand the signature coverage to the access token, or at least a hash of the token. — Justin > On Nov 20, 2020, at 9:30 PM, Nikos Fotiou wrote: > > Hi, > The token is granted to a client based on the authorization grant and not the > client's key. Therefore, a client may use a different key per token. At least > this is an approach we are following. > > Best, > Nikos > > -Original Message- > From: OAuth On Behalf Of Justin Richer > Sent: Friday, November 20, 2020 9:26 PM > To: oauth > Subject: [OAUTH-WG] Token substitution in DPoP > > While working on an implementation of DPoP recently, I realized that the > value of the access token itself is not covered by the DPoP signature at all. > What I’m wondering is whether or not this constitutes an attack surface that > we care about here. Here’s how it works: > > > Let’s say that a client creates a DPoP key and uses that key to request two > tokens, T1 and T2, for different users, Alice and Bob, respectively. Alice is > malicious and wants to get Bob’s stuff. Alice manages to get a hold of Bob’s > token value, T2, through some means. Normally DPoP wouldn’t let Alice create > a new request using T2 since Alice doesn’t have the client’s key. However, if > Alice gets the client to create a request for her using T1, she can copy the > signature from that request onto a new request using T2. Since the signature > doesn’t cover the token value and the key is the same, the RS should accept > both requests, right? > > An important aspect is that the parts needed to make this attack work are a > little weird: you’d need access to a valid signed request from the client > with T1 as well as access to a valid T2 attached to the same key in order to > make this substitution. However, this is effectively the same attack area > that bearer tokens have in a lot of ways, since it doesn’t require the > attacker gaining access to the singing key to generate or modify a signature, > nor does it require the attacker to generate or modify an access token > (merely obtain one). > > > I’d like to understand if this is an actual attack against DPoP. If it isn’t, > how is it countered by DPoP today? If it is, do we discuss in the DPoP draft? > I didn’t see a mention of it there. If it’s not, should we discuss it there? > > > The old OAuth PoP draft mitigates this attack by putting the access token > itself inside the signature body instead of a second header. Another option > would be to include a hash of the token value (such as OIDC’s “at_hash” > method used in ID Tokens) in the DPoP payload. With either of these > approaches, Alice having access to T1, T2, and a signed message for T1 does > not allow her to use T2 effectively. > > — Justin > ___ > 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
