Subject: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode

From: Brian Campbell <[email-masked]>
Date: Fri, 27 Dec 2019 12:03:30 -0700

We have a-sometimes used scenario where a client makes an
authorization/authentication request with a "token id_token" response type
and "form_post" response mode (nonce is also sent and exact redirect URI
matching is done at the AS). The access token is never exposed in any URLs
and access token injection is prevented by the at_hash claim in the id
token.

That seems to me like a legitimate and reasonable usage scenario. However,
it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the
Security BCP-to-be
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-3.1.2>,
which has:

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or any other response type issuing
   access tokens in the authorization response, such as "token id_token"
   and "code token id_token", unless the issued access tokens are
   sender-constrained and access token injection in the authorization
   response is prevented.

I know this particular text has been discussed over and over again so I
hate to revisit it. But based on the aforementioned scenario I think maybe
it still doesn't quite hit the mark. Access token injection is prevented.
The token leakage scenarios mentioned in that section are all avoided. And
while I know sender-constrained is recommended elsewhere in the draft, it's
not really a realistic option for the majority of deployments.

-- 
_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._

---

From: Mike Jones <[email-masked]>
Date: Fri, 27 Dec 2019 20:28:20 +0000

I agree with Brian. Please update the text to describe this already safe usage.

-- Mike

________________________________
From: OAuth <[email-masked]> on behalf of Brian Campbell <bcampbell=[email-masked]>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <[email-masked]>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode

We have a-sometimes used scenario where a client makes an authorization/authentication request with a "token id_token" response type and "form_post" response mode (nonce is also sent and exact redirect URI matching is done at the AS). The access token is never exposed in any URLs and access token injection is prevented by the at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3.1.2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cee48992fa75642e2cbf908d78aff8d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637130702523877347&sdata=LJfYSigLXqZjLNl%2Bx1ycBSHJn6UKJFXhr5As1zb1g98%3D&reserved=0>, which has:

I know this particular text has been discussed over and over again so I hate to revisit it. But based on the aforementioned scenario I think maybe it still doesn't quite hit the mark. Access token injection is prevented. The token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is recommended elsewhere in the draft, it's not really a realistic option for the majority of deployments.

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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 27 Dec 2019 21:41:36 +0100

As Brian said, we have discussed this several times and this text found consensus.

Using post reduces the attack surface but does not allow to bind the access token to the legitimate client. We are recommending sender constrained access tokens in the BCP. So recommending a flow that does not support sender constrained access tokens is a contradiction.

What do other WG members think?

> Am 27.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=[email-masked]>:
> 
> 
> That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Filip Skokan <[email-masked]>
Date: Fri, 27 Dec 2019 23:27:11 +0100

Encrypted JARM responses are in a very similar position. Access Token value is not part of the URL and the response itself is protected. Such response is usually only consumed by a server side application. Same as any form_post response. 

We could go into further clarifying the client application topology to enable these uses but i don’t think it’s worth it. Why make excuses to keep implicit issued access tokens around in when code flow is the way the WG has decided to go. (Here we go again...)

Best,
Filip

> 27. 12. 2019 v 21:41, Torsten Lodderstedt <torsten=[email-masked]>:
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 27 Dec 2019 16:01:29 -0700

I'm not suggesting that it should be a recommended flow. But recommending
against it, as the text does now, seems overreaching and unnecessary. I
know *consensus* was previously found on the text in -13 but best I can
recall that discussion was mostly around Nat advocating to allow room for
some future self-issued IDP type case and the conversation kind of got hung
up on that.

Here's some proposed text, which I think still largely captures the intent
of the BCP while not explicitly recommending against legitimate cases like
the one I brought here or Nat's or something like JARM.

   In order to avoid these issues, clients SHOULD NOT use the implicit
   grant (response type "token") or other response types issuing
   access tokens in the authorization response, unless access token
injection
   in the authorization response is prevented and the aforementioned token
leakage
   vectors are mitigated.

The draft already recommends sender-constrained access tokens elsewhere in
the document. It doesn't need to be repeated as a qualifying condition
around this SHOULD NOT.

I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully
is evident from several attempts at bringing/doing related work here) but I
do worry that the recommendation in the draft is sufficiently unachievable
to the vast majority that it might undermine the credibility of the
document. But I get the aspirational aspect of it and, other than some
suggested tweaks
<https://mailarchive.ietf.org/arch/msg/oauth/RKujONej-92dT5lr9cLu6hHnw8I>,
am resigned to see it stay in the document. But let's let that
recommendation stand on its own in the document and not also tie it to
other considerations.

On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> Using post reduces the attack surface but does not allow to bind the
> access token to the legitimate client. We are recommending sender
> constrained access tokens in the BCP. So recommending a flow that does not
> support sender constrained access tokens is a contradiction.
>
> ------------------------------
> *From:* OAuth <[email-masked]> on behalf of Brian Campbell
> <bcampbell=[email-masked]>
> *Sent:* Friday, December 27, 2019 11:03:30 AM
> *To:* oauth <[email-masked]>
> *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response
> types + form_post response mode
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3..1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cee48992fa75642e2cbf908d78aff8d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637130702523877347&sdata=LJfYSigLXqZjLNl%2Bx1ycBSHJn6UKJFXhr5As1zb1g98%3D&reserved=0>,
> which has:
>
> *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.*

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Dec 2019 01:00:01 +0100

Your proposal sounds reasonable on first sight. But thinking again, it would mean to keep token injection prevention in authorization responses a requirement while dropping the requirement for replay/injection prevention at resource servers. To me this feels inconsistent.

> Am 28.12.2019 um 00:02 schrieb Brian Campbell <bcampbell=[email-masked]>:
> 
> 
> I'm not suggesting that it should be a recommended flow. But recommending against it, as the text does now, seems overreaching and unnecessary. I know *consensus* was previously found on the text in -13 but best I can recall that discussion was mostly around Nat advocating to allow room for some future self-issued IDP type case and the conversation kind of got hung up on that. 
> 
> Here's some proposed text, which I think still largely captures the intent of the BCP while not explicitly recommending against legitimate cases like the one I brought here or Nat's or something like JARM. 
> 
>    access tokens in the authorization response, unless access token injection
>    in the authorization response is prevented and the aforementioned token leakage 
>    vectors are mitigated. 
> 
> The draft already recommends sender-constrained access tokens elsewhere in the document. It doesn't need to be repeated as a qualifying condition around this SHOULD NOT. 
> 
> I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other than some suggested tweaks, am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations.  
> 
> 
>> On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Sat, 28 Dec 2019 06:33:24 -0700

The requirement for replay/injection prevention at resource servers is
still there in section 3.2. This change only drops it as a specific
qualification on that SHOULD NOT for flows that send access tokens in the
authorization response. And instead focuses that qualification on the
additional risks that come with sending access tokens in the authorization
response. To me, this feels more consistent.

Looking again at section 3, I'd suggest also moving the fourth paragraph of
section 3.1.2 into section 3.2 so that the description of
sender-constrained is in the subsection that is about sender-constraining.

On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> Your proposal sounds reasonable on first sight. But thinking again, it
> would mean to keep token injection prevention in authorization responses a
> requirement while dropping the requirement for replay/injection prevention
> at resource servers. To me this feels inconsistent.
>
> Am 28..12.2019 um 00:02 schrieb Brian Campbell <bcampbell=
> [email-masked]>:
>
> 
>> That seems to me like a legitimate and reasonable usage scenario.
>> However, it would fall on the wrong side of the SHOULD NOT in Section
>> 3.1.2 of the Security BCP-to-be
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3...1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cee48992fa75642e2cbf908d78aff8d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637130702523877347&sdata=LJfYSigLXqZjLNl%2Bx1ycBSHJn6UKJFXhr5As1zb1g98%3D&reserved=0>,
>> which has:
>>

---

From: Mike Jones <[email-masked]>
Date: Sat, 28 Dec 2019 17:46:13 +0000

I agree with Brian's suggested text changes.

-- Mike
________________________________
From: Brian Campbell <[email-masked]>
Sent: Saturday, December 28, 2019 5:33:24 AM
To: Torsten Lodderstedt <torsten=[email-masked]>
Cc: Mike Jones <[email-masked]>; oauth <[email-masked]>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

The requirement for replay/injection prevention at resource servers is still there in section 3.2. This change only drops it as a specific qualification on that SHOULD NOT for flows that send access tokens in the authorization response. And instead focuses that qualification on the additional risks that come with sending access tokens in the authorization response. To me, this feels more consistent.

Looking again at section 3, I'd suggest also moving the fourth paragraph of section 3.1.2 into section 3.2 so that the description of sender-constrained is in the subsection that is about sender-constraining.

On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
Your proposal sounds reasonable on first sight. But thinking again, it would mean to keep token injection prevention in authorization responses a requirement while dropping the requirement for replay/injection prevention at resource servers. To me this feels inconsistent.

Am 28..12.2019 um 00:02 schrieb Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>:

I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is evident from several attempts at bringing/doing related work here) but I do worry that the recommendation in the draft is sufficiently unachievable to the vast majority that it might undermine the credibility of the document. But I get the aspirational aspect of it and, other than some suggested tweaks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FRKujONej-92dT5lr9cLu6hHnw8I&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=3fCGjTOAD43xXLzFaw3d6VC1kY43QvBfzNwdNfDckE0%3D&reserved=0>, am resigned to see it stay in the document. But let's let that recommendation stand on its own in the document and not also tie it to other considerations.

On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
As Brian said, we have discussed this several times and this text found consensus.

Am 27.12.2019 um 21:28 schrieb Mike Jones <Michael.Jones=[email-masked]<mailto:[email-masked]>>:

-- Mike

________________________________
From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types + form_post response mode

That seems to me like a legitimate and reasonable usage scenario. However, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3...1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342096923&sdata=mfnQwsGUZgz0PgEZoqOl%2BsszPYxncmFbgBaJs4qex38%3D&reserved=0>, which has:

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cfc28d513b04f489b371d08d78b9a9488%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637131368342106891&sdata=qO6%2BY%2FMoef0lyx4HwNLV8ID5DguAe3XjCQyxtvoFrPo%3D&reserved=0>

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.