[OAUTH-WG] Re: WGLC for Cross-Device Flows BCP

[Pieter Kasselman]

Thanks to Dean, Roy, Tim and Marco for the feedback in response to the working 
group last call for the cross-device security BCP. Your feedback helped to 
improve the draft, much appreciated.

All issues that were raised are addressed in the latest release which is 
available here: draft-ietf-oauth-cross-device-security-07 - Cross-Device Flows: 
Security Best Current 
Practice<https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/07/>

With gratitude

Pieter


From: OAuth  On Behalf Of Pieter Kasselman
Sent: Thursday, April 25, 2024 8:43 PM
To: Tim Cappalli ; rifaat.s.ietf 

Cc: oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

You don't often get email from 
pieter.kasselman=40microsoft@dmarc.ietf.org<mailto:pieter.kasselman=40microsoft@dmarc.ietf.org>.
 Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Thanks Tim, really appreciating the feedback.

I opened two issues to track your feedback here:


  1.  Editorial updates for FIDO Section: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/138
  2.  Consistent use of Smart TV: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/137

Once again thanks for your feedback.

Cheers

Pieter

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Tim Cappalli
Sent: Wednesday, April 24, 2024 8:13 PM
To: rifaat.s.ietf mailto:rifaat.s.i...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

You don't often get email from 
tim.cappalli=40okta@dmarc.ietf.org<mailto:tim.cappalli=40okta@dmarc.ietf.org>.
 Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Looks great! Some small proposed tweaks:

Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No 
preference on which one is used, but should be consistent.

6.2.3.1

Current text: "supports a new cross-device authentication protocol, called 
"hybrid""
Proposed text: "supports a new cross-device transport protocol, called "hybrid 
transports"

Propose adding the following at the end of the first paragraph: "CTAP 2.2 
hybrid transports is implemented by the client and authenticator platforms."

Current text: "The main device and authenticator"
Proposed text: "The main device (CTAP client) and authenticator"

Current text: "The user will receive a push notification on the authenticator."
Proposed text: "The user will typically receive a push notification on the 
device serving as the FIDO authenticator."

6.2.3.3
Current text: "Both the Consumption Device and the authenticator require BLE 
support."
Proposed text: "Both the Consumption Device and the authenticator require BLE 
support and also need access to the internet"

s/hybrid transport/hybrid transports

Current text: "The mobile phone must support CTAP 2.2+ to be used as a 
cross-device authenticator."
Proposed text: "The device serving as the FIDO authenticator must support CTAP 
2.2+ to be used as a cross-device authenticator."

tim

On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:

This message originated outside your organization.



We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html__;!!PwKahg!525wPy1_fpxaxk0Ic3TFoDq_1bASFewwEnh5LzytxLRyQ3DK4Yk5cIXmhgeed2ocAyWYCgh_FuutXE_aMzBQRlKp$>

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

[Pieter Kasselman]

Thanks Tim, really appreciating the feedback.

I opened two issues to track your feedback here:


  1.  Editorial updates for FIDO Section: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/138
  2.  Consistent use of Smart TV: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/137

Once again thanks for your feedback.

Cheers

Pieter

From: OAuth  On Behalf Of Tim Cappalli
Sent: Wednesday, April 24, 2024 8:13 PM
To: rifaat.s.ietf 
Cc: oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

You don't often get email from 
tim.cappalli=40okta@dmarc.ietf.org.
 Learn why this is important
Looks great! Some small proposed tweaks:

Nit: "SmartTV" and "Smart TV" are used interchangeably throughout the doc. No 
preference on which one is used, but should be consistent.

6.2.3.1

Current text: "supports a new cross-device authentication protocol, called 
"hybrid""
Proposed text: "supports a new cross-device transport protocol, called "hybrid 
transports"

Propose adding the following at the end of the first paragraph: "CTAP 2.2 
hybrid transports is implemented by the client and authenticator platforms."

Current text: "The main device and authenticator"
Proposed text: "The main device (CTAP client) and authenticator"

Current text: "The user will receive a push notification on the authenticator."
Proposed text: "The user will typically receive a push notification on the 
device serving as the FIDO authenticator."

6.2.3.3
Current text: "Both the Consumption Device and the authenticator require BLE 
support."
Proposed text: "Both the Consumption Device and the authenticator require BLE 
support and also need access to the internet"

s/hybrid transport/hybrid transports

Current text: "The mobile phone must support CTAP 2.2+ to be used as a 
cross-device authenticator."
Proposed text: "The device serving as the FIDO authenticator must support CTAP 
2.2+ to be used as a cross-device authenticator."

tim

On Mon, Apr 22, 2024 at 10:57 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:

This message originated outside your organization.



We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
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] WGLC for Cross-Device Flows BCP

[Pieter Kasselman]

Hi Dean, thanks for taking the time to review and provide feedback Dean, much 
appreciated.

I have opened issues to address each of the items highlighted.


  1.  Add verbiage to diagrams: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/124
  2.  Make examples consistent for Section 3.1.3: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/125
  3.  Clarify origin of QR Code: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/126
  4.  Editorial updates: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/127
  5.  FIDO Reference update: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/128
  6.  Update Guidance on using FIDO: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/129

Cheers

Pieter


From: OAuth  On Behalf Of Saxe, Dean
Sent: Monday, April 22, 2024 6:54 PM
To: rifaat.s.ietf ; oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

You don't often get email from 
deansaxe=40amazon@dmarc.ietf.org.
 Learn why this is important
Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com | M: 
206-659-7293

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>
Date: Monday, April 22, 2024 at 7:57 AM
To: oauth mailto:oauth@ietf.org>>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

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

Re: [OAUTH-WG] Cross-Device Flows: Security Best Current Practice Review

[Pieter Kasselman]

Thanks Roy, thanks for the review and feedback, much apprecioated.

I have opened two issues to add clarification and provide additional guidance 
to implementers.


  1.  Highlight edge cases of geolocation based on IP Address * Issue #123 * 
oauth-wg/oauth-cross-device-security 
(github.com)<https://github.com/oauth-wg/oauth-cross-device-security/issues/123>
  2.  Same device flow prevention * Issue #122 * 
oauth-wg/oauth-cross-device-security 
(github.com)<https://github.com/oauth-wg/oauth-cross-device-security/issues/122>

Cheers

Pieter

From: Roy Williams (E+P) 
Sent: Monday, April 22, 2024 5:42 PM
To: oauth@ietf.org
Cc: Pieter Kasselman 
Subject: Cross-Device Flows: Security Best Current Practice Review

I had promised at the 119 meeting that I would review this document and give 
feedback.  I have completed that document and other than two potential 
clarification points, I found it to be helpful.

The following two areas could be slightly improved:


  1.  At the end of section (5) there is a paragraph that talks about limiting 
Cross-device protocols on the same device.  It does not seem to be something 
that a client could\would know about when let's say YouTube TV requests auth 
and it ends up on Authenticator on the same device.  In theory this would then 
be the Authenticator Service's Job to determine this situation and respond with 
a well known pattern to drive the client to engage in a local oath call 
directly to authenticator.
  2.  In the case of 6.1.1 establishing proximity, there is a boundary (pun not 
intended) case where a device will shift between two different cellular 
providers.  The IETF's Drone effort were examining the same problem as the 
drone flies close to an international boundary and flips back and forth to 
roaming and not.  How to deal with this case or whether it is dependable is a 
question.  I know that Pieter is suggesting Fido2, but the way this section is 
written a Consumption device may be on a weak Wifi and the authentication 
device has shifted to Cellular.

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

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Pieter Kasselman]

I volunteered to review the OAuth 2.0 Protected Resource Metadata 
(https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html) at 
the IETF 119 meeting.

First, I would like to thank the authors, Mike, Phil and Aaron, for creating 
this draft. It solves an important problem and I believe this will find wide 
adoption. We are already referencing it in the OAuth Identity and Authorization 
Chaining Across Domains 
(https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/01/) draft 
for example.

Below are my comments, feedback, questions and the occasional suggestion. I 
tried to scrub items that were already brought up elsewhere in this thread, but 
may have missed one or two. Once again thanks for doing this important work.

Section 2

  1.  jwks_uri - The text only requires the "public key use" parameter if both 
signing and encryption keys are included. It was not clear to me what the 
assumed usage is if only a single key type is present (are they assumed to all 
be signing keys or all encryption keys). To avoid any possible confusion, why 
not make the "public key use" parameter mandatory even when only encryption or 
signature keys are included.
  2.  bearer_methods_supported - Reading the parameter name created a different 
expectation and only after reading the text was it clear that this was about 
the way in which the bearer token is presented, rather than different types or 
formats of tokens. Consider renaming this parameter to be a bit more 
descriptive. For example bearer_presentation_methods.
  3.  resource_signing_alg_values_supported - I was unsure whether this 
parameter was meant to describe signatures types that the resource server could 
verify, or whether this was for signature types it could generate (and 
presumably held keys for signature generation).

 *   Does it cover algorithms for both verification and generation?
 *   Given that this is an optional value, is it necessary to allow the 
value of "none". If no signing algorithms are supported, is a better approach 
to just not include this parameter (I reflect on security issues that may arise 
from alg:none type parameters)? If it has to be included, are there security 
considerations that can be called out regarding this parameter set to none?

  1.  Parameter names suggest URIs (jwks_uri, resource_policy_uri, 
resource_tos_uri), but the description always scopes this down to URLs. I 
suspect there is some history behind these parameter name choices, but was 
curious if there are ever a case when the parameter value is expected to not be 
a URL? If this parameter value is always a URL, should the parameter name be 
changes to reflect this (again, I suspect there are reasons for the current 
choices, but curious about the inconsistency)?

Section 3

  1.  I found paragraphs 1-3 of this section hard to parse. I think the intent 
here is to say that an application may be composed of different protected 
resources, and each of those may have their own protected resource metadata and 
then specify how that might be done.

 *   Although paragraph 2 describes the way to do it, and illustrates it 
with an example, it does not show the final result of such a construction. 
Would it be possible to include the final result of what the path would look 
like when inserting the "/.well-known/example-protected-resource" between the 
host and path components of the protected resource's resource identifier just 
to remove opportunity for misinterpretation (is this the same as the second 
example given in Section 3.1, if so, perhaps refer to that example)?

  1.  I was unsure how to interpret this sentence in paragraph 3: "An OAuth 2.0 
application using this specification MUST specify what well-known URI string it 
will use for this purpose."

 *   Is this meant to refer to the IANA registration in paragraph 1, or is 
there some other specification mechanism an OAuth application should use that 
consumers of the metadata can use to determine where to find the resource 
metadata?
 *   Is this related to the inclusion of the URL for the protected resource 
metadata as described in Section 5?

  1.  It looks like the validation rules in section 3.3 is intended as a 
mitigation for the attack described in section 7.3 (Impersonation Attacks). 
Perhaps add a sentence at the start of Section 3.3 to establish this connection 
for implementors less familiar with different types of attacks. For example: 
"The following validation rules mitigate against impersonation attacks 
described in section 7.3."

Section 4

  1.  Consider changing the first sentence to make it clear that the 
"protected_resources" metadata value is used as part of the Authorization 
Server Metadata.

 *   For example: "To support use cases in which the set of legitimate 
protected resources to use with the authorization server is fixed and 
enumerable, this specification defines the protected_resources metadata value, 
which 

[OAUTH-WG] Updating "Identity Chaining across Trust Domains" draft name

[Pieter Kasselman]

Following the working group adoption of the "Identity Chaining across Trust 
Domains" draft (see draft-ietf-oauth-identity-chaining-00 - Identity Chaining 
across Trust 
Domains), 
the editors thought it appropriate to update the name to "OAuth Identity and 
Authorization Chaining Across Domains" to align with OAuth naming conventions 
and reflect the use of OAuth authorization protocols. There is a PR tracking 
this update that can be viewed here 
https://github.com/oauth-wg/oauth-identity-chaining/pull/76 (update name with 
minor editorial changes for consistency).

If there are no strong objections, we will update the name and republish the 
draft on 16 February 2024.

Cheers

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

Re: [OAUTH-WG] Call for adoption - Identity Chaining

[Pieter Kasselman]

I support adoption.

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Tuesday, November 14, 2023 12:59 PM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Identity Chaining

All,

This is an official call for adoption for the Identity Chaining draft:
https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/

Please, reply on the mailing list and let us know if you are in favor or 
against adopting this draft as WG document, by Nov 28th.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Transaction Tokens

[Pieter Kasselman]

I support adoption.

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Tuesday, November 14, 2023 12:58 PM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Transaction Tokens

All,

This is an official call for adoption for the Transaction Tokens draft:
https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/

Please, reply on the mailing list and let us know if you are in favor or 
against adopting this draft as WG document, by Nov 28th.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-04.txt

[Pieter Kasselman]

Hi all,

We updated the cross-device security BCP based on guidance received at IETF 117 
as well as input during the OAuth Security Workshop (OSW) 2023. The additions 
include:

1. Introduction of normative SHOULD, RECOMMENDED and MAY when applied to 
actions the Authorization Server, Resource Server or Client may implement as 
discussed at IETF 117.
2. Added Cross-Device Session Transfer pattern based on input received at OSW 
2023
3. Added two additional mitigations:
a) User Education as a standalone mitigation.
b) Request Binding with Out-of-Band Data
4. Added additional examples based on attacks observed in the wild.
5. Renamed "Authenticated Flow" to the more descriptive 
"Authenticate-then-Initiate"
6. Adopted OpenID Foundation terminology from CIBA, using Consumption Device 
instead of Initiating Device
7. Added acknowledgements to recognise contributions from Maryam Mehrnezhad, 
Marco Pernpruner and Giada Sciarretta.
8. Editorial updates.

Apologies for the two quick releases in succession. There was a formatting 
issue in the -03 version that resulted in the document history not showing 
correctly, prompting an update to the -04 version.

Cheers

Pieter

-Original Message-
From: OAuth  On Behalf Of internet-dra...@ietf.org
Sent: Sunday, October 22, 2023 9:00 PM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-04.txt

Internet-Draft draft-ietf-oauth-cross-device-security-04.txt is now available.
It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   Cross-Device Flows: Security Best Current Practice
   Authors: Pieter Kasselman
Daniel Fett
Filip Skokan
   Name:draft-ietf-oauth-cross-device-security-04.txt
   Pages:   53
   Dates:   2023-10-22

Abstract:

   This document describes threats against cross-device flows along with
   near term mitigations, protocol selection guidance, and the
   analytical tools needed to evaluate the effectiveness of these
   mitigations.  It serves as a security guide to system designers,
   architects, product managers, security specialists, fraud analysts
   and engineers implementing cross-device flows.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-04.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-cross-device-security-04

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
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] Call for adoption - Protected Resource Metadata

[Pieter Kasselman]

I support adoption

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, August 23, 2023 8:02 PM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Protected Resource Metadata

All,

This is an official call for adoption for the Protected Resource Metadata draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor of 
adopting this draft as WG document, by Sep 6th.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials

[Pieter Kasselman]

I support adoption of this draft.

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Saturday, July 29, 2023 8:25 PM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - SD-JWT-based Verifiable Credentials

All,

This is an official call for adoption for the SD-JWT-based Verifiable 
Credentials draft discussed in SF.
https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/

Please, reply on the mailing list and let us know if you are in favor of 
adopting this draft as WG document, by August 11th.

Regards,
 Rifaat & Hannes

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

Re: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

[Pieter Kasselman]

I support adoption.

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Saturday, July 29, 2023 8:27 PM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Attestation-Based Client Authentication

All,

This is an official call for adoption for the Attestation-Based Client 
Authentication draft discussed in SF.
https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/

Please, reply on the mailing list and let us know if you are in favor of 
adopting this draft as WG document, by August 11th.

Regards,
 Rifaat & Hannes

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

Re: [OAUTH-WG] New Version Notification for draft-identity-chaining-00.txt

[Pieter Kasselman]

Hi folks

Following on from discussions at previous IETF meetings (starting at IETF 114) 
on identity chaining , Arndt, Kelly, Mike and I prepared a proposal that would 
allow for identity chaining across trust domains to support fine-grained 
authorization scenarios.

It was uploaded it as an individual draft and you can view it here: 
https://datatracker.ietf.org/doc/draft-identity-chaining/ .

Comment and feedback is most welcome. You can also open issues or suggest 
changes here https://github.com/arndt-s/ietf-identity-chaining:

Rifaat, would it be possible to get time on the agenda at IETF 117 to discuss 
this proposal?

Cheers

Pieter


-Original Message-
From: internet-dra...@ietf.org 
Sent: Monday, July 10, 2023 4:26 PM
To: Arndt Schwenkschuster ; Kelley Burgin 
; Michael Jenkins ; Mike 
Jenkins ; Pieter Kasselman 
; Pieter Kasselman 

Subject: New Version Notification for draft-identity-chaining-00.txt


A new version of I-D, draft-identity-chaining-00.txt has been successfully 
submitted by Arndt Schwenkschuster and posted to the IETF repository.

Name:   draft-identity-chaining
Revision:   00
Title:  Identity Chaining across Trust Domains
Document date:  2023-07-10
Group:  Individual Submission
Pages:  17
URL:https://www.ietf.org/archive/id/draft-identity-chaining-00.txt
Status: https://datatracker.ietf.org/doc/draft-identity-chaining/
Html:   https://www.ietf.org/archive/id/draft-identity-chaining-00.html
Htmlized:   https://datatracker.ietf.org/doc/html/draft-identity-chaining


Abstract:
   This specification defines a mechanism to preserve identity and call
   chain information across trust domains that use the OAuth 2.0
   Framework.




The IETF Secretariat


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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-02.txt

[Pieter Kasselman]

Hi folks, we updated the Cross-Device Flows: Security Best Current Practice 
based on feedback received after IETF 116.

Updates include:

- Introduced Cross-Device Consent Phishing as a label for the types of attacks 
described in this document.
- Updated labels for different types of flows (User-Transferred Session Data 
Pattern, Backchannel-Transferred Session Pattern, User-Transferred 
Authorization Data Pattern)
- Adopted consistent use of hyphenation in using "cross-device"
- Consistent use of "Authorization Device"
- Update Reference to Secure Signals Framework to reflect name change from 
Secure Signals and Events
- Described difference between proximity enforced and proximity-less 
cross-device flows
- Fixed typos and grammar edits
- Capitalised Initiating Device and Authorization Device
- General editorial pass

Rifaat, we would like to request a time on the agenda to discuss the pros/cons 
and any concerns that may arise from introducing normative requirements (see 
https://mailarchive.ietf.org/arch/msg/oauth/dhQQsJjHqMnmUdTaUsKyEQ3uuLw/ ), as 
well as outstanding open issues 
(https://github.com/oauth-wg/oauth-cross-device-security/issues) and propose 
proposed next steps for this draft.

Cheers

Pieter

-Original Message-
From: OAuth  On Behalf Of internet-dra...@ietf.org
Sent: Monday, July 10, 2023 10:20 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Web Authorization Protocol (OAUTH) WG 
of the IETF.

   Title   : Cross-Device Flows: Security Best Current Practice
   Authors     : Pieter Kasselman
 Daniel Fett
 Filip Skokan
   Filename: draft-ietf-oauth-cross-device-security-02.txt
   Pages   : 43
   Date: 2023-07-10

Abstract:
   This document describes threats against cross-device flows along with
   near term mitigations, protocol selection guidance and the analytical
   tools needed to evaluate the effectiveness of these mitigations.  It
   serves as a security guide to system designers, architects, product
   managers, security specialists, fraud analysts and engineers
   implementing cross-device flows.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-cross-device-security-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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-WG] Cross-device security BCP: Proposal to add normative requirements

[Pieter Kasselman]

Hi folks

The cross-device security BCP contain several non-normative recommendations 
(should, may, recommended). We (the editors) are considering making some of 
these normative (SHOULD, MAY, RECOMMENDED) to give clearer guidance and 
emphasise the desirability of implementing certain mitigations. It will also 
help emphasise/encourage implementation choices (e.g. implement several 
mitigations to achieve defence-in-depth).

The idea is to make non-normative should, may and recommended statements that 
apply to mitigations that authorization servers and clients may implement. We 
are not thinking of introducing in MUSTs at this point.

To make the discussion a little less abstract, we created a PR to show the 
changes we had in mind (see Capitalise SHOULD, MAY and RECOMMENDED where 
appropriate by PieterKas * Pull Request #75 * 
oauth-wg/oauth-cross-device-security 
(github.com)). 
Before making these changes, we wanted to get the perspective of other working 
group members:


  1.  Are there any concerns with adding normative requirements to the 
cross-device security BCP?
  2.  Are there any concerns with any of the proposed normative references in 
the PR (see Capitalise SHOULD, MAY and RECOMMENDED where appropriate by 
PieterKas * Pull Request #75 * oauth-wg/oauth-cross-device-security 
(github.com))?

Cheers

Pieter

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

[OAUTH-WG] Cross-device BCP: Alternative labels for different cross-device flow patterns

[Pieter Kasselman]

Hi folks,

After the previous IETF meeting, we got some feedback that the labels we chose 
to describe the three variants of cross device flows could be a little more 
descriptive. After some discussion between Daniel and myself, we would like to 
propose the following changes in how we label and describe the different of 
cross-device flow patterns to which the recommendations in the BCP apply.

User transferred -> User-Transferred Session Data
Client transferred -> Backchannel Transferred Session
Hybrid -> User-Transferred Authorization Data
Here are the descriptions for the new proposed labels

  1.  User-Transferred Session Data Pattern: In the first variant, the user 
initiates the authorization process with the authorization server by copying 
information from the initiating device to the authorization device, before 
authorizing an action. By transferring the data from the Initiating Device to 
the Authorization Device, the user transfers the authorization session. For 
example the user may read a code displayed on the Initiating Device and enter 
it on the Authorization Device, or they may scan a QR code displayed in the 
Initiating Device with the Authorization Device.
  2.  Backchannel-Transferred Session Pattern: In the second variant, the OAuth 
client on the Initiating Device is responsible for transferring the session and 
initiating authorization on the Authorization Device via a backchannel with the 
Authorization Server. For example the user may attempt an online purchase on an 
Initiating Device (e.g. a personal computer) and receive an authorization 
request on their Authentication Device (e.g. mobile phone).
  3.  User-Transferred Authorization Data: In the third variant, the OAuth 
client on the Initiating Device triggers the authorization request via a 
backchannel with the Authorization Server. Authorization data (e.g. an access 
code) is displayed on the Authorization Device, which the user enters on the 
Initiating Device. For example the user may attempt to access data in an 
enterprise application and receive an authorization code on their 
Authentication Device (e.g. mobile phone) that they enter on Initiating Device.
For reference, here are the current labels and their definitions for the three 
variants (from section 2 of draft-ietf-oauth-cross-device-security-01 - 
Cross-Device Flows: Security Best Current 
Practice):

1.  User transferred: In the first variant, the user initiates the 
authorization process with the authorization server by copying information from 
the initiating device to the authorization device, before authorizing an 
action.  For example the user may read a code displayed on the initiating 
device and enter it on the authorization device, or they may scan a QR code 
displayed in the initiating device with the authorization device.

2.  Client transferred: In the second variant, the OAuth client on the 
initiating device is responsible for initiating authorization on the 
authorization device via a backchannel with the authorization server.

3.  Hybrid: In the third variant, the OAuth client on the initiating device 
triggers the authorization request via a backchannel with the Authorization 
Server.  An access code is displayed on the Authorization device, which the 
user enters on the initiating device.

Are these new labels clearer than the previous ones or do you see some ways we 
can improve it further?
Cheers
Pieter

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

[OAUTH-WG] Collective name for attacks on cross-device flows: Cross-Device Consent Phishing (CDCP)

[Pieter Kasselman]

Hi folks, one of the discussion points at IETF 116 for the cross-device 
security BCP was finding a collective name for the exploits of the cross device 
flows we were seeing. We got several suggestions since then (see list below).

We are thinking of adopting the term "Cross-Device Consent Phishing (CDCP)" 
given that it describes the scope of the attacks (cross-device), the purpose of 
the attacks (obtaining user consent), and the technique (phishing, and other 
social engineering techniques).

Does this feel like a good descriptive name to adopt?

The list of names that was suggested over the last few months:


  1.  Cross-Device Consent Phishing
  2.  Illicit Consent Grant Attack
  3.  Attacker-in-the-Middle Attack
  4.  Authorization Context Manipulation Attack
  5.  Authorization Context Manipulation Exploit
  6.  "Cross-Device Authorization Exploit"
  7.  "Social Engineering Token Theft"
  8.  "Authorization Flow Manipulation Exploit"
  9.  Context Manipulation Authorization Exploit
  10. Zishing
  11. Azishing
  12. FlowJack
  13. AuthJack
  14. TokenJack
  15. Permitphishing,
  16. Authishing

Cheers

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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-01.txt

[Pieter Kasselman]

Thanks Karsten, I have seen implementations of the client transferred pattern 
where the user does not require the user to authenticate, they just have to 
provide approval (in effect possession/control of the device is considered 
sufficient), so I wrote the scenario focused on providing authorization. 
However it is a good point to add the authentication step, along with 
recommendations on the benefits of that step as well. I opened an issue to 
clarify (see Add clarification that authentication may be required prior to 
authorization for the client initiated pattern. · Issue #39 · 
oauth-wg/oauth-cross-device-security 
(github.com)<https://github.com/oauth-wg/oauth-cross-device-security/issues/39>)

Thanks for taking the time to read the draft and provide feedback.

Cheers

Pieter

From: OAuth  On Behalf Of Karsten Meyer zu Selhausen
Sent: Tuesday, March 14, 2023 10:21 AM
To: Pieter Kasselman ; 
oauth@ietf.org; i-d-annou...@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: 
draft-ietf-oauth-cross-device-security-01.txt


Hi Pieter,

I won't be able to attend IETF 116, so I ask my short question here:

Why is there a difference between step (D) in Figure 1 (user transferred 
pattern) and steps (D) + (E) in Figure 2 (client transferred pattern)?

Shouldn't the user authenticate to the authorization server and then grant the 
authorization in both patterns?



FYI: I also created a 
PR<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauth-wg%2Foauth-cross-device-security%2Fpull%2F38=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cdec7860d8f094683a8be08db2475dc2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143861971846150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=bAEpkPdnn7R%2FzoS9YuYwVi5LByH54OWlVVivdjFuT6c%3D=0>
 with some typo fixes and minor suggestions.

Best regards,
Karsten
On 13.03.2023 21:24, Pieter Kasselman wrote:

Hi folks, this updated version of the cross-device security BCP will be the 
basis for discussion in Yokohama. The draft was updated to:



1. Provide more granularity on different cross-device flow patterns

2. Include information on the limitations of some of the proposed mitigations 
(none of them are silver bullets and they are most effective when deployed as 
part of a defence-in-depth approach)

3. Updated and added additional use cases and exploit examples

3. Fixes for typos, grammar etc.



I also want to thank Aaron Parecki for helping us migrate the -00 draft to the 
Github repository.



Cheers



Pieter



-Original Message-

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>

Sent: Monday, March 13, 2023 6:29 PM

To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>

Cc: oauth@ietf.org<mailto:oauth@ietf.org>

Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-01.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Web Authorization Protocol (OAUTH) WG 
of the IETF.



   Title   : Cross-Device Flows: Security Best Current Practice

   Authors : Pieter Kasselman

 Daniel Fett

 Filip Skokan

   Filename: draft-ietf-oauth-cross-device-security-01.txt

   Pages   : 40

   Date: 2023-03-13



Abstract:

   This document describes threats against cross-device flows along with

   near term mitigations, protocol selection guidance and the analytical

   tools needed to evaluate the effectiveness of these mitigations.  It

   serves as a security guide to system designers, architects, product

   managers, security specialists, fraud analysts and engineers

   implementing cross-device flows.



The IETF datatracker status page for this Internet-Draft is:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-cross-device-security%2F=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=J4tksmhwl2n0sTgexdtIl8%2BO4fLAbcfRy9kWQ%2F%2BA4pY%3D=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-cross-device-security%2F=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cdec7860d8f094683a8be08db2475dc2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143861971846150%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=XQis7DH%2FrIaDMfIbwoC4wksippDhGaUtIMHRsAreKe4%3D=0>



There is also an HTML version available at:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-cross-device-s

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-01.txt

[Pieter Kasselman]

Hi folks, this updated version of the cross-device security BCP will be the 
basis for discussion in Yokohama. The draft was updated to:

1. Provide more granularity on different cross-device flow patterns
2. Include information on the limitations of some of the proposed mitigations 
(none of them are silver bullets and they are most effective when deployed as 
part of a defence-in-depth approach)
3. Updated and added additional use cases and exploit examples
3. Fixes for typos, grammar etc.

I also want to thank Aaron Parecki for helping us migrate the -00 draft to the 
Github repository. 

Cheers

Pieter

-Original Message-
From: OAuth  On Behalf Of internet-dra...@ietf.org
Sent: Monday, March 13, 2023 6:29 PM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Web Authorization Protocol (OAUTH) WG 
of the IETF.

   Title   : Cross-Device Flows: Security Best Current Practice
   Authors : Pieter Kasselman
 Daniel Fett
 Filip Skokan
   Filename: draft-ietf-oauth-cross-device-security-01.txt
   Pages   : 40
   Date: 2023-03-13

Abstract:
   This document describes threats against cross-device flows along with
   near term mitigations, protocol selection guidance and the analytical
   tools needed to evaluate the effectiveness of these mitigations.  It
   serves as a security guide to system designers, architects, product
   managers, security specialists, fraud analysts and engineers
   implementing cross-device flows.

The IETF datatracker status page for this Internet-Draft is:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-cross-device-security%2F=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=J4tksmhwl2n0sTgexdtIl8%2BO4fLAbcfRy9kWQ%2F%2BA4pY%3D=0

There is also an HTML version available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-cross-device-security-01.html=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8yOF0hi777CSOBrkEFqPiTRzhFde067zXxBW%2FPH7zgE%3D=0

A diff from the previous version is available at:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-oauth-cross-device-security-01=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=G5%2BH8H0thDW1202i30NgVR6MTqXivysbisDqXpXwXGo%3D=0

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=WYeoZK67zgwPLDektVwqS%2FI3%2FxAvRUZFD%2FLnAT9eWL4%3D=0

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

[OAUTH-WG] FW: New Version Notification for draft-kasselman-cross-device-security-02.txt

[Pieter Kasselman]

Hi All

Thanks for all the feedback prior to and during IETF 115 on the proposed "Cross 
Device Flows: Security Best Practice". I incorporated the feedback and 
published a new version here: 
https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/

Cheers

Pieter

-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, November 15, 2022 12:21 AM
To: Daniel Fett ; panva.ip ; Pieter 
Kasselman 
Subject: New Version Notification for 
draft-kasselman-cross-device-security-02.txt


A new version of I-D, draft-kasselman-cross-device-security-02.txt
has been successfully submitted by Pieter Kasselman and posted to the IETF 
repository.

Name:   draft-kasselman-cross-device-security
Revision:   02
Title:  Cross-Device Flows: Security Best Current Practice
Document date:  2022-11-15
Group:  Individual Submission
Pages:  29
URL:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-02.txtdata=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cfad1d8b6c6fa4d6184af08dac69f4009%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040684550332501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=amixgInI01SSxvKkAxxDaoghymly%2FuvkjRev%2FhXVWPg%3Dreserved=0
Status: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kasselman-cross-device-security%2Fdata=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cfad1d8b6c6fa4d6184af08dac69f4009%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040684550332501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Z4LMaYgjySr3zXc7fvbKAC8iKt56Pq5%2BcfGusqi6CAk%3Dreserved=0
Html:   
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-02.htmldata=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cfad1d8b6c6fa4d6184af08dac69f4009%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040684550332501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=lYTU38nt%2Fy%2BvT0%2Fgkvs1lKAwGY%2FGEH012sxm3MxBxrw%3Dreserved=0
Htmlized:   
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kasselman-cross-device-securitydata=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cfad1d8b6c6fa4d6184af08dac69f4009%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040684550332501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=R4XLp%2BwcEqy0cfuSP96c78I4YiwukiDiNgjwTiTnCh0%3Dreserved=0
Diff:   
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-kasselman-cross-device-security-02data=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cfad1d8b6c6fa4d6184af08dac69f4009%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638040684550332501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=MKeL%2Fbn58XqZdX2Cpp9tCKmyOJP3cbCuRLs7k5oZHdw%3Dreserved=0

Abstract:
   This document describes threats against cross-device flows along with
   near term mitigations, protocol selection guidance and the analytical
   tools needed to evaluate the effectiveness of these mitigations.  It
   serves as a security guide to system designers, architects, product
   managers, security specialists, fraud analysts and engineers
   implementing cross-device flows.


  


The IETF Secretariat


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

Re: [OAUTH-WG] [E] Re: Draft Proposal for a Cross Device Flow Security BCP

[Pieter Kasselman]

Thanks Bjorn, I have opened an issue and the fix will be in the next update. 
Much appreciated!

From: Hjelm, Bjorn 
Sent: Thursday, October 27, 2022 4:25 AM
To: Pieter Kasselman ; Daniel Fett 
; Filip Skokan 
Cc: oauth@ietf.org; Joseph Heenan 
Subject: Re: [E] Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security 
BCP

You don't often get email from 
bjorn.hj...@verizonwireless.com<mailto:bjorn.hj...@verizonwireless.com>. Learn 
why this is important<https://aka.ms/LearnAboutSenderIdentification>

As an editorial note, the text referenced (section 5.2.4) by Joseph, "If 
FIDO2/WebAuthn support is not available, Channel Initiated Backchannel 
Authentication (CIBA) provides an alternative.." should reference "Client 
Initiated Backchannel Authentication (CIBA)". This reference is correct in the 
other sections of the document.

BR,
Bjorn


On Tue, Oct 25, 2022 at 3:49 AM Joseph Heenan 
mailto:jos...@authlete.com>> wrote:
Hi Pieter / Daniel / Filip

It's great to see this document moving forward.

I may have missed it, but it may be worth being move explicit that one solution 
is to avoid using cross-device flows for same-device scenarios? It's sort of 
obvious, but questions like "well CIBA works for both cross-device and 
same-device, can't I save myself effort by only implementing CIBA and not 
bothering with standard redirect-based OAuth flows?" are commonly asked.

Also, in this text:

"If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel 
Authentication (CIBA) provides an alternative, provided that the underlying 
devices can receive push notifications."

It might be best to use a term other than 'push notifications' there or 
otherwise rewording this, as there are alternatives. e.g. I think there's at 
least one CIBA implementation out there that can use email to notify the user 
of an authorization request.

Thanks

Joseph

> On 19 Oct 2022, at 15:55, Pieter Kasselman 
> mailto:40microsoft@dmarc.ietf.org>>
>  wrote:
>
> Hi All
>
> Following on from the discussions at IETF 113, the OAuth Security Workshop, 
> Identiverse and IETF 114, Daniel, Filip and I created a draft document 
> capturing some of the attacks that we are seeing on cross device flows, 
> including Device Authorization Grant (aka Device Code Flow).
>
> These attacks exploit the unauthenticated channel between devices to trick 
> users into granting authorization by using social engineering techniques to 
> change the context in which authorization is requested.
>
> The purpose of the document is to serve as guidance on best practices when 
> designing and implementing scenarios that require cross device flows. We 
> would appreciate any feedback or comments on the document, or any other 
> mitigations or techniques that can be used to mitigate these attacks. Links 
> to the documents are below. We also hope to discuss this at IETF 115 in 
> London in a few weeks' time.
>
> ---------
> A new version of I-D, draft-kasselman-cross-device-security-00.txt
> has been successfully submitted by Pieter Kasselman and posted to the IETF 
> repository.
>
> Name: draft-kasselman-cross-device-security
> Revision: 00
> Title:Cross Device Flows: Security Best Current Practice
> Document date:2022-10-19
> Group:Individual Submission
> Pages:25
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity-2D00.txt=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0=laLdZ6c7CRHmE3mvQ2aDBaT2pwnLrnv5tpBSlWrkhQh12iyjLjJHa81GBcZn8pUc=xGpRQKj7UudEOCRHx2eWl0xhVQ1D5i4SH8sehvDPpCY=<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_archive_id_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity-2D00.txt%26d%3DDwIGaQ%26c%3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ%26r%3DNMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9p1INnD0%26m%3DlaLdZ6c7CRHmE3mvQ2aDBaT2pwnLrnv5tpBSlWrkhQh12iyjLjJHa81GBcZn8pUc%26s%3DxGpRQKj7UudEOCRHx2eWl0xhVQ1D5i4SH8sehvDPpCY%26e%3D=05%7C01%7Cpieter.kasselman%40microsoft.com%7C7cbd164bf59942d654b108dab7caebed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638024379445779026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=TSMcP7Ix0dtwH9BgsKwvoqqfDdMdzGMF%2BkER4dp8Hd0%3D=0>
> Status: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dkasselman-2Dcross-2Ddevice-2Dsecurity-2D00.txt=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=NMZJHCV8pjvGIH2fTx9z6tOf9bN5lnuu0jl9

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

[Pieter Kasselman]

Thanks Joseph, those are good additions, thanks for pointing them out. I have 
opened issues to track both of them.

-Original Message-
From: Joseph Heenan  
Sent: Tuesday, October 25, 2022 11:49 AM
To: Pieter Kasselman 
Cc: oauth@ietf.org; Daniel Fett ; Filip Skokan 

Subject: Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

Hi Pieter / Daniel / Filip

It's great to see this document moving forward.

I may have missed it, but it may be worth being move explicit that one solution 
is to avoid using cross-device flows for same-device scenarios? It's sort of 
obvious, but questions like "well CIBA works for both cross-device and 
same-device, can't I save myself effort by only implementing CIBA and not 
bothering with standard redirect-based OAuth flows?" are commonly asked.

Also, in this text:

"If FIDO2/WebAuthn support is not available, Channel Initiated Backchannel 
Authentication (CIBA) provides an alternative, provided that the underlying 
devices can receive push notifications."

It might be best to use a term other than 'push notifications' there or 
otherwise rewording this, as there are alternatives. e.g. I think there's at 
least one CIBA implementation out there that can use email to notify the user 
of an authorization request.

Thanks

Joseph

> On 19 Oct 2022, at 15:55, Pieter Kasselman 
>  wrote:
> 
> Hi All
> 
> Following on from the discussions at IETF 113, the OAuth Security Workshop, 
> Identiverse and IETF 114, Daniel, Filip and I created a draft document 
> capturing some of the attacks that we are seeing on cross device flows, 
> including Device Authorization Grant (aka Device Code Flow). 
> 
> These attacks exploit the unauthenticated channel between devices to trick 
> users into granting authorization by using social engineering techniques to 
> change the context in which authorization is requested. 
> 
> The purpose of the document is to serve as guidance on best practices when 
> designing and implementing scenarios that require cross device flows. We 
> would appreciate any feedback or comments on the document, or any other 
> mitigations or techniques that can be used to mitigate these attacks. Links 
> to the documents are below. We also hope to discuss this at IETF 115 in 
> London in a few weeks' time.
> 
> --
> --- A new version of I-D, 
> draft-kasselman-cross-device-security-00.txt
> has been successfully submitted by Pieter Kasselman and posted to the IETF 
> repository.
> 
> Name: draft-kasselman-cross-device-security
> Revision: 00
> Title:Cross Device Flows: Security Best Current Practice
> Document date:2022-10-19
> Group:Individual Submission
> Pages:25
> URL: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.txtdata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2qQECauAiHwL5QTl0ijskyr7Rk1OX3%2F8LducJ6HBPoU%3Dreserved=0
> Status: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.txtdata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=2qQECauAiHwL5QTl0ijskyr7Rk1OX3%2F8LducJ6HBPoU%3Dreserved=0
>  
> Html:   
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.htmldata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=IL3OzMJpCQLSLEOxUSBv71egJo%2FAk1TkveMLX2bVGqY%3Dreserved=0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kasselman-cross-device-securitydata=05%7C01%7Cpieter.kasselman%40microsoft.com%7C13d136330ec84e82ff1c08dab676965f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638022917712107364%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=AAUBzWehBbE32S2tSk4MLghzBqnfyv7h5dVT%2F0xmLWU%3Dreserved=0
> 
> 
> Abstract:
>   This document describes threats against cross-device 

Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

[Pieter Kasselman]

Thanks Brian, I will add clarification on CIBA and fix those transposition 
errors. Much appreciated!

From: Brian Campbell 
Sent: Friday, October 21, 2022 11:10 PM
To: Pieter Kasselman 
Cc: oauth@ietf.org; Daniel Fett ; Filip Skokan 

Subject: Re: [OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

And I just happened to notice there are a few mentions of RFC8682 (TinyMT32 
Pseudorandom Number Generator) which should probably be RFC8628 (OAuth 2.0 
Device Authorization Grant).

On Fri, Oct 21, 2022 at 4:06 PM Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
Just want to try and clarify some things about the status of CIBA, which is 
described somewhat erroneously as a "standard under development."  There is a 
FAPI profile of CIBA that is still under development but core 
CIBA<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-client-initiated-backchannel-authentication-core-1_0.html=05%7C01%7Cpieter.kasselman%40microsoft.com%7C0d240f6b43f9cd6008dab3b12d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019870835005801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=FSBqj0OFDHj9ERUVs%2B8l2mOUR6zHUekJZWE%2Ffy9Lg%2F0%3D=0>
 was finalized last year.




On Wed, Oct 19, 2022 at 8:56 AM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Hi All

Following on from the discussions at IETF 113, the OAuth Security Workshop, 
Identiverse and IETF 114, Daniel, Filip and I created a draft document 
capturing some of the attacks that we are seeing on cross device flows, 
including Device Authorization Grant (aka Device Code Flow).

These attacks exploit the unauthenticated channel between devices to trick 
users into granting authorization by using social engineering techniques to 
change the context in which authorization is requested.

The purpose of the document is to serve as guidance on best practices when 
designing and implementing scenarios that require cross device flows. We would 
appreciate any feedback or comments on the document, or any other mitigations 
or techniques that can be used to mitigate these attacks. Links to the 
documents are below. We also hope to discuss this at IETF 115 in London in a 
few weeks' time.

-
A new version of I-D, draft-kasselman-cross-device-security-00.txt
has been successfully submitted by Pieter Kasselman and posted to the IETF 
repository.

Name:   draft-kasselman-cross-device-security
Revision:   00
Title:  Cross Device Flows: Security Best Current Practice
Document date:  2022-10-19
Group:  Individual Submission
Pages:  25
URL: 
https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.txt=05%7C01%7Cpieter.kasselman%40microsoft.com%7C0d240f6b43f9cd6008dab3b12d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019870835005801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3zvGvZt0nubZbiEQh3YbkrI7%2BmJCt9YzhXUfmaI1JpY%3D=0>
Status: 
https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.txt=05%7C01%7Cpieter.kasselman%40microsoft.com%7C0d240f6b43f9cd6008dab3b12d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019870835005801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=3zvGvZt0nubZbiEQh3YbkrI7%2BmJCt9YzhXUfmaI1JpY%3D=0>
Html:   
https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-kasselman-cross-device-security-00.html=05%7C01%7Cpieter.kasselman%40microsoft.com%7C0d240f6b43f9cd6008dab3b12d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019870835005801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Y8WZlZbLMrcmEtSZtbm1p4L4CqMGecS%2FXuGiTyi7plY%3D=0>
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kasselman-cross-device-security<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-kasselman-cross-device-security=05%7C01%7Cpieter.kasselman%40microsoft.com%7C0d240f6b43f9cd6008dab3b12d19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638019870835005801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Vo1I0ugE9hlMDEKGnB9d4Y51ymxt%2F%2BuM4lIb8KCbJ98%3D=0>


Abstract:
   

[OAUTH-WG] Draft Proposal for a Cross Device Flow Security BCP

[Pieter Kasselman]

Hi All

Following on from the discussions at IETF 113, the OAuth Security Workshop, 
Identiverse and IETF 114, Daniel, Filip and I created a draft document 
capturing some of the attacks that we are seeing on cross device flows, 
including Device Authorization Grant (aka Device Code Flow). 

These attacks exploit the unauthenticated channel between devices to trick 
users into granting authorization by using social engineering techniques to 
change the context in which authorization is requested. 

The purpose of the document is to serve as guidance on best practices when 
designing and implementing scenarios that require cross device flows. We would 
appreciate any feedback or comments on the document, or any other mitigations 
or techniques that can be used to mitigate these attacks. Links to the 
documents are below. We also hope to discuss this at IETF 115 in London in a 
few weeks' time.

-
A new version of I-D, draft-kasselman-cross-device-security-00.txt
has been successfully submitted by Pieter Kasselman and posted to the IETF 
repository.

Name:   draft-kasselman-cross-device-security
Revision:   00
Title:  Cross Device Flows: Security Best Current Practice
Document date:  2022-10-19
Group:  Individual Submission
Pages:  25
URL: 
https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt
Status: 
https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.txt 
Html:   
https://www.ietf.org/archive/id/draft-kasselman-cross-device-security-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kasselman-cross-device-security


Abstract:
   This document describes threats against cross-device flows along with
   near term mitigations, protocol selection guidance and the analytical
   tools needed to evaluate the effectiveness of these mitigations.  It
   serves as a security guide to system designers, architects, product
   managers, security specialists, fraud analysts and engineers
   implementing cross-device flows.


  


The IETF Secretariat


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

Re: [OAUTH-WG] WGLC for Step-up Authentication

[Pieter Kasselman]

I want to clarify that I don't see any blockers to using the step-up auth 
proposal from working with fine-grained policies.

The comment and question was more to outline use cases being evaluated and to 
see whether others are observing this shift as well.

Cheers

Pieter

From: OAuth  On Behalf Of Pieter Kasselman
Sent: Friday, October 7, 2022 9:29 PM
To: Rifaat Shekh-Yusef ; oauth 
Subject: Re: [OAUTH-WG] WGLC for Step-up Authentication


I am very supportive of this work and have been working through different use 
cases to see whether it can satisfy the requirements that arise from them.



One observation from working through these uses cases is that as customers move 
to Zero Trust architectures, we are seeing customers adopting finer grained 
policy segmentation. Consequently customers are planning to deploy segmented 
access control by data or action sensitivity, within a service. This approach 
to policy design makes it more common for a single service to depend on 
multiple authentication context values or combinations of authentication 
context values.



An example of this is a policy that has multiple acr values (e.g. 
acr1=password, acr2=FIDO, acr3=selfie check, acr4=trusted network). A customer 
may define a policy that requires different combinations of these acr values, 
for example, a file server may requires password for general access (e.g. 
acr1), FIDO authentication (acr2) or password access and being on a trusted 
network to read sensitive data (acr 2 of (acr1 + acr 4), FIDO authentication 
and password (acr1 + acr2) for accessing editing sensitive documents and a 
real-time selfie check on top of FIDO and presence on a trusted network  (acr1 
+ acr2 + acr3 + acr4) to initiate a sensitive workflow (e.g. check-in code). 
Other variations of this includes database access with different types of 
access requirement for certain rows (row-level permissions) or columns (column 
level permissions) with different combinations of acr values.



I was curious if this type of scenario where multiple authentication contexts 
and combinations of contexts are required is something others see (or are 
beginning to see) as well?

Cheers

Pieter

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Thursday, September 22, 2022 3:02 PM
To: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] WGLC for Step-up Authentication

Correction:

Please, review the document and provide your feedback on the mailing list by 
Oct 7th, 2022.

On Thu, Sep 22, 2022 at 9:52 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is to start a WG Last Call for the Step-up Authentication document:
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-03.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-step-up-authn-challenge-03.html=05%7C01%7Cpieter.kasselman%40microsoft.com%7Ca9927281814243e628ac08daa8a2b9a7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638007714137535915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=eajkqEWpu4%2BIbWJhY%2F89IzEB36JAh6zxW3JppdQuCH8%3D=0>

Please, review the document and provide your feedback on the mailing list by 
Sep 30th, 2022.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for Step-up Authentication

[Pieter Kasselman]

I am very supportive of this work and have been working through different use 
cases to see whether it can satisfy the requirements that arise from them.



One observation from working through these uses cases is that as customers move 
to Zero Trust architectures, we are seeing customers adopting finer grained 
policy segmentation. Consequently customers are planning to deploy segmented 
access control by data or action sensitivity, within a service. This approach 
to policy design makes it more common for a single service to depend on 
multiple authentication context values or combinations of authentication 
context values.



An example of this is a policy that has multiple acr values (e.g. 
acr1=password, acr2=FIDO, acr3=selfie check, acr4=trusted network). A customer 
may define a policy that requires different combinations of these acr values, 
for example, a file server may requires password for general access (e.g. 
acr1), FIDO authentication (acr2) or password access and being on a trusted 
network to read sensitive data (acr 2 of (acr1 + acr 4), FIDO authentication 
and password (acr1 + acr2) for accessing editing sensitive documents and a 
real-time selfie check on top of FIDO and presence on a trusted network  (acr1 
+ acr2 + acr3 + acr4) to initiate a sensitive workflow (e.g. check-in code). 
Other variations of this includes database access with different types of 
access requirement for certain rows (row-level permissions) or columns (column 
level permissions) with different combinations of acr values.



I was curious if this type of scenario where multiple authentication contexts 
and combinations of contexts are required is something others see (or are 
beginning to see) as well?

Cheers

Pieter

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, September 22, 2022 3:02 PM
To: oauth 
Subject: Re: [OAUTH-WG] WGLC for Step-up Authentication

Correction:

Please, review the document and provide your feedback on the mailing list by 
Oct 7th, 2022.

On Thu, Sep 22, 2022 at 9:52 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is to start a WG Last Call for the Step-up Authentication document:
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-03.html

Please, review the document and provide your feedback on the mailing list by 
Sep 30th, 2022.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - SD-JWT

[Pieter Kasselman]

I support adoption

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Friday, July 29, 2022 1:17 AM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - SD-JWT

All,

This is a call for adoption for the SD-JWT document
https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/

Please, provide your feedback on the mailing list by August 12th.

Regards,
 Rifaat & Hannes

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

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

[Pieter Kasselman]

I support adoption of this work.

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Tuesday 26 April 2022 11:47
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Step-up Authentication

This is a call for adoption for the Step-up Authentication document
https://datatracker.ietf.org/doc/draft-bertocci-oauth-step-up-authn-challenge/

Please, provide your feedback on the mailing list by May 10th.

Regards,
 Rifaat & Hannes

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

Re: [OAUTH-WG] Step-up Authentication review

[Pieter Kasselman]

Hi Vittorio, Brian, Rifaat and OAuth WG members.

I volunteered to review the OAuth 2.0 Step-up Authentication Challenge Protocol 
(https://www.ietf.org/archive/id/draft-bertocci-oauth-step-up-authn-challenge-01.html)
 at the OAuth working group meeting at IETF 113. I did the review in the 
context of a "just-in-time" step-up authentication scenario we are exploring 
and have the following observations:


  1.  A standard for step-up authentication will be valuable with an increasing 
need for "just-in-time" step-up authentication to improve user experience and 
allow customers to protect their assets appropriately. We should pursue this 
work.
  2.  There is an implicit assumption in the proposal that the "step-up" is a 
superset that includes all preceding authentication contexts and that it 
persists. This may not always be the case if the "step-up" is short lived 
before reverting to the previous authentication context and the authentication 
methods may not always be a superset. For example a server side liveness 
biometric check or government ID presentation may be required on top of an MFA 
authentication. Satisfying the liveness check or government ID presentation can 
be done independent of the MFA method, and does not imply the MFA method was 
used.
  3.  When this "super-set" assumption does not hold it may result in a 
degraded user experience (user is prompted to re-authenticate on "step-down", 
extra latency and round trips), increased costs (extra token issuance) or cause 
a security vulnerability (e.g. only the "step_up" check is performed, the acr 
and auth_time is updated implying initial checks were performed as well while 
resetting the auth_time for the initial authentication context (if it took 
place)).

Some ideas on how to address this (there are probably more):

  1.  Make the assumption explicit and add security considerations to outline 
the security risks along with implementation guidance on how to deal with the 
"temporary step-up" uses cases (see Step 6: Option 1-3 below as examples).
  2.  Don't assume that "step-up" is always a superset of what came before and 
include authentication context history in the access token to give visibility 
to the resource server on which authentication contexts were satisfied when and 
how long ago (e.g. include the latest acr and auth_time values as proposed but 
also provide an acr_history construct of acr/auth_time tuples that reflect the 
authentication context history). This "acr_history" property may be optional 
for those deployments that do operate in a strict superset environment (if it 
is optional, the security considerations should outline the risks of making 
this assumption).

I am sharing more details on the scenario below, in case it helps to clarify 
the above observations (also, feel free to poke holes or suggest better 
options).

Scenario Description
The user is authenticated using one of a number of authentication methods 
available (password, FIDO, other MFA etc). For specific high value actions 
(e.g. a transaction approval, code commit etc), an additional "step-up" spot 
check needs to be performed on the user identity (e.g. a server side biometric 
liveness check, present a government issued ID, or some additional MFA 
options). The validity period of this "spot-check" needs to be short to 
minimise risk, after which authentication needs to "step-down" to the original 
authentication context. If the user needs to perform another high value 
transaction, they need to complete the "step-up" again. This roughly translates 
into the following steps:


  1.  User attempts to access "regular resource 1"
  2.  User is authenticated using an "initial" authentication mechanism 
(password, FIDO, other MFA)
  3.  User attempts to perform high value action on "sensitive resource 2"
  4.  User is prompted for a "step-up" authentication (e.g. server side 
liveness check/biometric verification, government ID presentation)
  5.  User authenticates and completes action.
  6.  User continues to access regular resources as before with no 
re-authentication for the "initial" authentication method.
  7.  User attempts to perform another high value action on "sensitive resource 
2"
  8.  User is once again prompted for a "step-up" authentication (e.g. server 
side liveness check/biometric verification, government ID presentation)
  9.  User authenticates and completes action.

So, ideally we want to be able to perform an "initial" authentication, then 
force a short-lived "step-up" and then  followed by a "step-down" without 
having the user take any action for the "step-down". So, going through this 
step-by-step, it looks something like this:

Steps 1-2: This is achieved using existing OAuth flows and the authorisation 
server issues an access token with "acr: initial" and "auth_time: t0".

Step 3-5: The resource server responds with "insufficient_user_authentication", 
"acr_values: step_up" and "max_age: 0", which the client pass 

Re: [OAUTH-WG] WGLC for DPoP Document

[Pieter Kasselman]

I support publication

From: OAuth  On Behalf Of Warren Parad
Sent: Wednesday 30 March 2022 13:12
To: Torsten Lodderstedt 
Cc: oauth 
Subject: Re: [OAUTH-WG] WGLC for DPoP Document

I support publication.


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress.


On Wed, Mar 30, 2022 at 2:08 PM Torsten Lodderstedt 
mailto:40lodderstedt@dmarc.ietf.org>>
 wrote:
I support publication of this specification.


Am 30.03.2022 um 09:18 schrieb Steinar Noem 
mailto:stei...@udelt.no>>:

I support publication of the specification

ons. 30. mar. 2022 kl. 08:56 skrev Dave Tonge 
mailto:dave.to...@momentumft.co.uk>>:
I support publication of the specification

On Wed, 30 Mar 2022 at 08:55, Daniel Fett 
mailto:f...@danielfett.de>> wrote:

I also support publication.

-Daniel
Am 29.03.22 um 23:20 schrieb David Waite:
I also support publication of this specification

-DW


On Mar 29, 2022, at 3:12 PM, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

I support publication of the specification.

   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Monday, March 28, 2022 5:01 AM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] WGLC for DPoP Document

All,

As discussed during the IETF meeting in Vienna last week, this is a WG Last 
Call for the DPoP document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Please, provide your feedback on the mailing list by April 11th.

Regards,
 Rifaat & Hannes

___
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

--

https://danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Dave Tonge
CTO
[Moneyhub 

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[Pieter Kasselman]

Hi Brock, one of the options to consider here is just better guidance in terms 
of implementation, including guidance on selecting protocols. From looking at 
numerous exploits (not just the authroization grant flow and the social 
engineering exploits), implementation issues is by far the most prevalent cause 
of issues, much more so than protocol issues themselves.

I would add that keeping protocols and the primitives they are built on simple 
is important in reducing implementation errors as well.

To put it another way, giving implementors more context about the consequences 
of using a protocol in a certain way is really important if we want to minimise 
security issues that arise from implementation issues and protocol selection.

Cheers

Pieter

From: Brock Allen 
Sent: Thursday 24 March 2022 02:25
To: George Fletcher ; Pieter Kasselman 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit 
Consent Exploits

In the case of DEF CON video showing the Microsoft exploit, it worked liked 
this (if I recall correctly):

The attacker started the device flow from their system, sent the user a link to 
login with an "promo code" (the user code) to get a discount on their Microsoft 
bill, and when the user logged in they were prompted for the code (which they 
thought it was a promo code), and thus they granted access to the attacker 
waiting for the flow to be complete.

The problem was that:

1) The vendor's first party administrative CLI app was designed to use device 
flow.
2) The consent screen just said "Do you want to login to your Microsoft 
account".

So the issues were that for (1) device flow was just the wrong one (the native 
apps BCP w/ system browser should have been used), especially for an app with 
such high/privileged access, and for (2) the consent did not let the end-user 
know they were granting the client full administrative access.

So several missteps here that the protocol by itself can't completely protect 
against.

-Brock

On 3/23/2022 9:10:01 PM, George Fletcher 
mailto:gffle...@aol.com>> wrote:
I just want to make a quick comment on the use of "proximity and location 
information". I used the device flow to authorize my son's device by having him 
text me the code so I could login on my device (in a different state) and 
provide his device access. If we close the door too much we will potentially 
impact good users :)

I agree that consent can be socially engineered... but think that it would be 
useful to improve that information so that the user authenticating to provide 
authorization could know where the device their authorizing is located. That 
could help users detecting that they are authorizing a device in a location 
that doesn't make sense to them.

Thanks,
George
On 3/18/22 8:21 AM, Pieter Kasselman wrote:
Hi Brock

Great point, and I would agree that better consent screens could help, but I 
don’t think it is sufficient.

One of the challenges with consent screens is that it makes assumptions about 
the users abilities when they are being asked to make decisions about things 
they do not fully appreciate or understand. In addition, they are in a rush, 
are often trying to be helpful and prone to grant consent (the framing in these 
social engineering attacks can be very persuasive). Even users who are aware of 
these exploits and understand the systems they interact with are prone to be 
misled. Better guidance on the consent screen is definitely something we should 
provide.

I do think there is a defence in depth strategy that can reduce risk by (1) 
avoiding asking the user for a decision by making back-end risk decisions (2) 
augmenting the information presented to the user when making the decisions and 
(3) mitigating against a decision made in error.

Proximity and location information can for instance be used to bind user codes 
to specific locations or inform the user on where the user code was first 
presented, device status and/or location may be used to make decisions on 
whether to allow device code flows to be used in the first place and use of 
token binding (e.g. DPoP) may help defend against attackers who are able to 
exfiltrate tokens from a device and make lateral attacks.

Anything we can do to encourage implementor to ask users to make fewer 
decision, help them make better decisions and then protecting them in case of a 
bad decision will help drive down risk.

Cheers

Pieter


From: Brock Allen <mailto:brockal...@gmail.com>
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman 
<mailto:pieter.kassel...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit 
Consent Exploits

I watched one of those videos and it seems to be that a proper consent screen 
would have been the best and easiest line of defense. Is there something more 
to the attacks where a better consent page

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[Pieter Kasselman]

Thanks George, I agree that there are “on behalf-off” authorization use cases 
where strict proximity enforcement could be problematic.

I think of proximity as one of the controls that can be applied and influence 
the risk assessment. For example, the authorization server may still issue 
authorization tokens, but may choose to reduce the validity period or require 
re-authentication in the future if proximity cannot be established (i.e. you 
can get a temporary pass, until you can satisfy the proximity requirements).

Another way to think about it is correlating proximity at different levels 
(same room, same building, same city, same country, same continent).

A third variation of this may be related to the vce being protected (e.g. above 
a certain monetary value proximity is enforced, below another value, it is not).

I don’t think of it as a binary decision, but rather one of a number of signals 
that can help to reduce risk, based on the deployment scenario.

Cheers

Pieter

From: George Fletcher 
Sent: Thursday 24 March 2022 02:10
To: Pieter Kasselman ; Brock Allen 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit 
Consent Exploits

I just want to make a quick comment on the use of "proximity and location 
information". I used the device flow to authorize my son's device by having him 
text me the code so I could login on my device (in a different state) and 
provide his device access. If we close the door too much we will potentially 
impact good users :)

I agree that consent can be socially engineered... but think that it would be 
useful to improve that information so that the user authenticating to provide 
authorization could know where the device their authorizing is located. That 
could help users detecting that they are authorizing a device in a location 
that doesn't make sense to them.

Thanks,
George
On 3/18/22 8:21 AM, Pieter Kasselman wrote:
Hi Brock

Great point, and I would agree that better consent screens could help, but I 
don’t think it is sufficient.

One of the challenges with consent screens is that it makes assumptions about 
the users abilities when they are being asked to make decisions about things 
they do not fully appreciate or understand. In addition, they are in a rush, 
are often trying to be helpful and prone to grant consent (the framing in these 
social engineering attacks can be very persuasive). Even users who are aware of 
these exploits and understand the systems they interact with are prone to be 
misled. Better guidance on the consent screen is definitely something we should 
provide.

I do think there is a defence in depth strategy that can reduce risk by (1) 
avoiding asking the user for a decision by making back-end risk decisions (2) 
augmenting the information presented to the user when making the decisions and 
(3) mitigating against a decision made in error.

Proximity and location information can for instance be used to bind user codes 
to specific locations or inform the user on where the user code was first 
presented, device status and/or location may be used to make decisions on 
whether to allow device code flows to be used in the first place and use of 
token binding (e.g. DPoP) may help defend against attackers who are able to 
exfiltrate tokens from a device and make lateral attacks.

Anything we can do to encourage implementor to ask users to make fewer 
decision, help them make better decisions and then protecting them in case of a 
bad decision will help drive down risk.

Cheers

Pieter


From: Brock Allen <mailto:brockal...@gmail.com>
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman 
<mailto:pieter.kassel...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit 
Consent Exploits

I watched one of those videos and it seems to be that a proper consent screen 
would have been the best and easiest line of defense. Is there something more 
to the attacks where a better consent page (or any consent page for that 
matter) would not have been sufficient?

-Brock

On 3/17/2022 5:10:35 PM, Pieter Kasselman 
mailto:pieter.kasselman=40microsoft@dmarc.ietf.org>>
 wrote:

Hi All



One of the agenda items for IETF 113 is the device authorization grant flow 
(aka device code flow), scheduled for Thursday 24 March 2022.  Before the 
meeting, I wanted to share a bit more information for those interested in the 
topic and also give those who are unable to attend in person an opportunity to 
participate in the conversation.



The Device Authorization Grant Flow (RFC 
8682)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[Pieter Kasselman]

Hi Shane,

Agreed that CIBA is interesting in this context as an alternative to Device 
Authorization Grant.

Having the user initiate the request makes it harder for an adversary to 
manipulate the context, but I think it also shifts the point of attack. Now 
instead of getting the user to enter a user code, you have to get the user to 
enter their “user_hint”. This does put it on par with any regular phishing 
attack (at least the attack did not become easier). I do think mitigations on 
the back-end can help to further reduce the risks for both Device Authorization 
Grant and CIBA.

Something else we may want to provide is some clear recommendations on when to 
use CIBA vs Device Authorization Grant etc (e.g. use CIBA if the user can 
provide input, use Device Authorization Grant if there is no input device). All 
of this may seem obvious for experts familiar with this space, but being 
explicit will help implementors who has expertise elsewhere.

From looking at various protocols, whenever we attempt to use the user as a 
secure transport between their authentication device and the device on which 
the service will be delivered, we open an opportunity for social engineering 
attacks. Keeping that opening as small and constrained as possible and then 
mitigating against errors in judgement will help the overall security posture.

Cheers

Pieter

From: Shane B Weeden 
Sent: Thursday 17 March 2022 21:21
To: Pieter Kasselman 
Cc: oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit 
Consent Exploits

Isn’t this essentially what is mitigated in the FAPI-compliant OIDC CIBA by:
1. Requiring the client to initiate the flow with signed request parameters 
which include, via some hint, the resource owner for whom authentication is 
being requested
2. Requiring that the OP check that the resource owner approving the grant is 
the same as that the client associated with the request in step 1

I realise this requires that the client obtains an indication of the username 
of the resource owner up front to kick things off, but short of this I cannot 
think of any practical mitigation.




On 18 Mar 2022, at 7:09 am, Pieter Kasselman 
mailto:pieter.kasselman=40microsoft@dmarc.ietf.org>>
 wrote:

ant problem by enabling authorization flows on devices that are unable to 
support a browsers or have limited input capabilities. However, looking back 
over the past 18-24 months, there have been a number of practical exploits 
published that use social en

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

Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[Pieter Kasselman]

Hi Brock

Great point, and I would agree that better consent screens could help, but I 
don’t think it is sufficient.

One of the challenges with consent screens is that it makes assumptions about 
the users abilities when they are being asked to make decisions about things 
they do not fully appreciate or understand. In addition, they are in a rush, 
are often trying to be helpful and prone to grant consent (the framing in these 
social engineering attacks can be very persuasive). Even users who are aware of 
these exploits and understand the systems they interact with are prone to be 
misled. Better guidance on the consent screen is definitely something we should 
provide.

I do think there is a defence in depth strategy that can reduce risk by (1) 
avoiding asking the user for a decision by making back-end risk decisions (2) 
augmenting the information presented to the user when making the decisions and 
(3) mitigating against a decision made in error.

Proximity and location information can for instance be used to bind user codes 
to specific locations or inform the user on where the user code was first 
presented, device status and/or location may be used to make decisions on 
whether to allow device code flows to be used in the first place and use of 
token binding (e.g. DPoP) may help defend against attackers who are able to 
exfiltrate tokens from a device and make lateral attacks.

Anything we can do to encourage implementor to ask users to make fewer 
decision, help them make better decisions and then protecting them in case of a 
bad decision will help drive down risk.

Cheers

Pieter


From: Brock Allen 
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman ; oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit 
Consent Exploits

I watched one of those videos and it seems to be that a proper consent screen 
would have been the best and easiest line of defense. Is there something more 
to the attacks where a better consent page (or any consent page for that 
matter) would not have been sufficient?

-Brock

On 3/17/2022 5:10:35 PM, Pieter Kasselman 
mailto:pieter.kasselman=40microsoft@dmarc.ietf.org>>
 wrote:

Hi All



One of the agenda items for IETF 113 is the device authorization grant flow 
(aka device code flow), scheduled for Thursday 24 March 2022.  Before the 
meeting, I wanted to share a bit more information for those interested in the 
topic and also give those who are unable to attend in person an opportunity to 
participate in the conversation.



The Device Authorization Grant Flow (RFC 
8682)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=EswcNYKNZWEAWLBuOvQytd8TMlgpgUxIk0E%2FlfKkRIk%3D=0>
 solves an important problem by enabling authorization flows on devices that 
are unable to support a browsers or have limited input capabilities. However, 
looking back over the past 18-24 months, there have been a number of practical 
exploits published that use social engineering techniques applied to the device 
authorization grant flow.



The goal of the session at IETF 113 is to discuss the patterns of the exploits 
that are known and start a conversation on what (if anything) we should do, 
based on what we are learning.



These exploits follow a general man-in-the-middle (MITM) pattern, where the 
attacker:



  1.  Initiates the Device Authorization Grant flow on a device under their 
control,
  2.  Presents the user code in a context that the end-user is likely to act on 
(using social engineering techniques), and
  3.  Once the user grants access, retrieves the access and refresh tokens and 
uses them to access the user’s resources.



Some of the exploits are described here for those interested in more detail:



  1.  The Art of the Device Code Phish - Boku 
(0xboku.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=%2B71AMxS1m4aBTrX8e76UiXs%2Fa%2F22dfxen1pI9Ln17Ig%3D=0>
  2.  Microsoft 365 OAuth Device Code Flow and Phishing | 
Optiv<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi

[OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

[Pieter Kasselman]

Hi All



One of the agenda items for IETF 113 is the device authorization grant flow 
(aka device code flow), scheduled for Thursday 24 March 2022.  Before the 
meeting, I wanted to share a bit more information for those interested in the 
topic and also give those who are unable to attend in person an opportunity to 
participate in the conversation.



The Device Authorization Grant Flow (RFC 
8682) solves an important 
problem by enabling authorization flows on devices that are unable to support a 
browsers or have limited input capabilities. However, looking back over the 
past 18-24 months, there have been a number of practical exploits published 
that use social engineering techniques applied to the device authorization 
grant flow.



The goal of the session at IETF 113 is to discuss the patterns of the exploits 
that are known and start a conversation on what (if anything) we should do, 
based on what we are learning.



These exploits follow a general man-in-the-middle (MITM) pattern, where the 
attacker:



  1.  Initiates the Device Authorization Grant flow on a device under their 
control,
  2.  Presents the user code in a context that the end-user is likely to act on 
(using social engineering techniques), and
  3.  Once the user grants access, retrieves the access and refresh tokens and 
uses them to access the user’s resources.



Some of the exploits are described here for those interested in more detail:



  1.  The Art of the Device Code Phish - Boku 
(0xboku.com)
  2.  Microsoft 365 OAuth Device Code Flow and Phishing | 
Optiv
 *   optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a 
phishing attack abusing Microsoft 365 OAuth Authorization Flow 
(github.com)
  3.  Introducing a new phishing technique for compromising Office 365 accounts 
(o365blog.com)
  4.  DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth 
Authentication Flows - YouTube



In terms of a response, there are a few options that come to mind (these are 
not exhaustive, I would love to see what others have in mind as well):



  1.  Do nothing: We can choose to leave everything as is. The downside of this 
is that the lessons we are learning are not getting disseminated or resulting 
in reduced risks.
  2.  Update the recommendations: We can document the social engineering 
exploits and recommend some additional mitigations as well as recommendations 
in terms of use cases. Although these types of "phishing"/social engineering 
attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 
Device Authorization Grant, we 
can add further mitigations to create greater defence in depth. This will help 
future implementers and may even be useful for future protocols that rely on a 
similar cross-device authentication and authorization flows.
  3.  Explore alternatives: Develop, adopt, or evolve new protocols that 
address the scenario while mitigating or avoiding the risks.



Option A does not do much to improve the state of the art. Option B feels like 
something we can do now, and we may learn something along the way that can help 
inform Option C, which may be much further down the road and require more 
research. What other options come to mind?



I’m looking forward to the conversation and hearing what others are thinking 
about this topic.



Cheers,

Pieter

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

Re: [OAUTH-WG] [EXTERNAL] Re: Call for adoption - JWK Thumbprint URI

[Pieter Kasselman]

+1. I support adoption.

From: OAuth  On Behalf Of George Fletcher
Sent: Friday 21 January 2022 21:22
To: Rifaat Shekh-Yusef ; oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

+1 for adoption
On 1/13/22 9:26 AM, Rifaat Shekh-Yusef wrote:
All,

This is a call for adoption for the JWK Thumbprint URI draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/

Please, provide your feedback on the mailing list by Jan 27th.

Regards,
 Rifaat & Hannes




___

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] [EXTERNAL] Re: OAuth Redirection Attacks

[Pieter Kasselman]

The problem isn't invalid URLs but malicious ones. Given a choice between a 
sub-optimal user experience and a phished end-user, perhaps an option that 
allows the authorization server to handle the error, rather than redirecting 
can serve end-users better. But as Vittorio points, out, there are probably 
other options as well to consider. URL reputation services is another option, 
but problematic since they are imperfect and I expect hard to standardise to a 
point that creates a common minimum level of assurance (similar to any fraud 
calculation or risk score).

From: Warren Parad 
Sent: Friday 17 December 2021 20:27
To: Pieter Kasselman 
Cc: Vittorio Bertocci ; oauth 
Subject: Re: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

You want to redirect on some errors because the last thing an AS wants is to 
leave the user in the AS because the user can't do anything there and the AS 
can't do anything either. It's just bad UX. But if the redirect url isn't 
valid, this is absolutely the time that the AS should keep the user there for 
user's protection.  Any AS redirecting the user to an invalid redirect url, 
isn't doing the right thing.

But that only solves the illegitimate phishing urls, it doesn't solve the class 
of problem where a phishing application is legitimately registered.


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D=0>.


On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Agreed that the attackers goal is to bypass phishing filters and they found a 
way to achieve this by using an IdP that adheres to the standards. I don't have 
the context for the design choice to redirect on an error condition, but am 
curious why the IdP should not be allowed to handle the error condition, rather 
than redirect (or at least have the option to do so)?

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Vittorio Bertocci
Sent: Friday 17 December 2021 19:55
To: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

The attack doesn't rely on redirecting to unregistered URLs, that's the problem.
The goal of the attack is to circumvent phishing filters, by presenting a URL 
from a legitimate domain (the AS) that eventually redirects to the actual 
phishing URL. The actual phishing page doesn't need to target the same 
authorization server, or an authorization server at all for that matter.
An attacker can register a legitimate app on any authorization server as a 
service, on their own tenant. The goal is just to have a starting URL that 
phishing filters won't block, and the attacker is in full control of the 
redirect URIs they register in their own tenant.

My take: it might be tricky to change the redirect on error behavior at this 
point, but we should at least note the issue in the security 
considerations/BCPs and possibly give some advice. For example, on top of my 
head: AS should expose their endpoints on a domain dedicated to OAuth/OIDC 
operations, and avoid using its top level domains (different area/service, but 
think 
herokuapp.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fherokuapp.com%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=6oiRh6TMVJnXYUGdDJt%2BLQQI0gCtOs7au%2BU7ctOd%2Bjo%3D=0>
 vs 
heroku.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fheroku.com%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=egS2AEI1FmpbL09upMutgGCUtpgyEn2l1FtdDb7WCdI%3D=0>)
 so that if a phishing filter decides to block direct links to the issuing 
endpoints will only impact things like IdP initiated flows (solvable by adding 
jumpstart endpoints on the RP anyway, just like IdP initiated sign in works in 
OIDC). I am sure there are lots of other things we can come up with that can 
make the problem better.

On Fri, Dec 17, 2021 at 5:00 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
I think this just falls into the category of never redirect the user to a url 
that doesn't match one of the preregistered redirect urls (o

Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

[Pieter Kasselman]

Agreed that the attackers goal is to bypass phishing filters and they found a 
way to achieve this by using an IdP that adheres to the standards. I don't have 
the context for the design choice to redirect on an error condition, but am 
curious why the IdP should not be allowed to handle the error condition, rather 
than redirect (or at least have the option to do so)?

From: OAuth  On Behalf Of Vittorio Bertocci
Sent: Friday 17 December 2021 19:55
To: Warren Parad 
Cc: oauth 
Subject: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks

The attack doesn't rely on redirecting to unregistered URLs, that's the problem.
The goal of the attack is to circumvent phishing filters, by presenting a URL 
from a legitimate domain (the AS) that eventually redirects to the actual 
phishing URL. The actual phishing page doesn't need to target the same 
authorization server, or an authorization server at all for that matter.
An attacker can register a legitimate app on any authorization server as a 
service, on their own tenant. The goal is just to have a starting URL that 
phishing filters won't block, and the attacker is in full control of the 
redirect URIs they register in their own tenant.

My take: it might be tricky to change the redirect on error behavior at this 
point, but we should at least note the issue in the security 
considerations/BCPs and possibly give some advice. For example, on top of my 
head: AS should expose their endpoints on a domain dedicated to OAuth/OIDC 
operations, and avoid using its top level domains (different area/service, but 
think 
herokuapp.com
 vs 
heroku.com)
 so that if a phishing filter decides to block direct links to the issuing 
endpoints will only impact things like IdP initiated flows (solvable by adding 
jumpstart endpoints on the RP anyway, just like IdP initiated sign in works in 
OIDC). I am sure there are lots of other things we can come up with that can 
make the problem better.

On Fri, Dec 17, 2021 at 5:00 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
I think this just falls into the category of never redirect the user to a url 
that doesn't match one of the preregistered redirect urls (or logout urls for 
that matter). Any application that has redirects anywhere provides an 
opportunity for this attack vector, OAuth isn't unique in that way, it just is 
consistent and documented. And the 2.1 draft is pretty clear on this front:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2.1
   If the request fails due to a missing, invalid, or mismatching
   redirect URI, or if the client identifier is missing or invalid, the
   authorization server SHOULD inform the resource owner of the error
   and MUST NOT automatically redirect the user agent to the invalid
   redirect URI.

I want to call this attack vector "illegitimate phishing applications" which is 
easily blocked by preregistration and/or PARs. And is only a very small subset 
of phishing attacks with OAuth, of which the larger group is "legitimate 
phishing applications". An app can be registered correctly, and still issue a 
phishing attack as phishing attacks through OAuth are actually 
indistinguishable from standard user delegation. There is no way to prevent 
these without an application review before registration is completed, here's an 
example that cloned Google apps y creating a fake app called google defender: 

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Pieter Kasselman]

Thanks for the comments and engagement Warren.

The attacks we described and the ideas on mitigations are born out of attack 
vectors we are observing in the wild. They are not negligible. We are seeing a 
new class of very sophisticated attackers, and if you're interested, this 
article provides good context on capability and sophistication of the attackers 
Brad Smith: Inside Microsoft during the SolarWinds hack 
(fastcompany.com)<https://www.fastcompany.com/90672384/microsoft-president-brad-smith-solarwinds-exclusive>.
 We are sharing this with the hope that the industry will benefit from our 
experiences and incorporate it into standards and products. Attacks that seemed 
impossibly complex are not only possible, but have become probable.

The proposed changes for DPoP are not meant to replace the need for one-time 
use tokens (single use tokens are preferable and we should continue to expect 
them), but instead address the limitations around implementing one-time use, 
especially at scale. The 60s window you mention below is sufficiently long to 
be exploited by these sophisticated attackers.

Cheers

Pieter

From: OAuth  On Behalf Of Warren Parad
Sent: Wednesday 1 December 2021 15:29
To: Pieter Kasselman 
Cc: Mike Jones ; oauth@ietf.org
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

(e.g. one-time use in a certain timeframe etc).

Sure but couldn't we just reduce the lifetime? Even if the token isn't one time 
use, surely the reuse time is trivially short which would prevent against 
exfiltration of the necessary security tokens to issue the attack?

I feel like the simpler solution will always win, which in this case is 
one-time use tokens, then the problem is moot, right? So this only comes into 
play if you want to allow token reuse in a time window. The previously 
suggested max allowed time window from OAuth 2.1 was 60s for auth codes. So we 
are saying that the attack surface is still too large, for the .01% of 
implementations that have multi-use tokens, and the .01% of implementations 
that use the maximum 60s reuse, and then the subset of those that aren't 
correctly scrubing their logs, and then the subset of those that have a 
vulnerability which allows for exfiltration of both those logged tokens and the 
logged PKCE verifier?

Why are we making this more complicated for a majority of cases, which:

  *   Only have single use tokens
  *   Or Only have a very short lifetime
  *   Or Are already correctly sanitizing their logs
  *   Or Have defense in depth for their deployments.
If the implementation is so insecure that none of those are happening, wouldn't 
the implementation for this functionality also be suspect for an opportunity 
for attack?

I feel like we are justifying here that multi-use tokens are wrong, but still 
want a solution to use them. Once we've proven that an deployment is not okay 
with using multi-use tokens, then the conclusion should be "don't have 
multi-use tokens", not: "let's still have multi-use tokens, but come up with a 
complex way to prevent their multi-use from accidentally being abused".

Or am I missing something that would actually make this a non-negligible attack 
vector?

- Warren


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cb5c71bfcbfbb48fd641508d9b4df5fcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739693847580905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=%2FBkvuWZ3FVTcdTtfe%2FoLurIGxcsJHCz6zXmW1PROTSc%3D=0>.


On Wed, Dec 1, 2021 at 4:14 PM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Hi Aaron, Neil

Thanks for the questions.

We agree that ideally authorization codes and PKCE proofs would never end up in 
log files and one-time use would be perfectly implemented.

However, in practice these artefacts do find their way into log files in 
various places and one-time use may not always be practical (e.g. one-time use 
in a certain timeframe etc).

The addition of these mitigations is not meant to replace the need for one-time 
use or good logging hygiene. Instead they provide pragmatic defence in depth 
against real attacks rather than assuming perfect implementations. We are 
deploying these mitigations and are sharing them for inclusion in DPoP to 
enable others to do the same.

Regarding the question about interrupting/intercepting the HTTPS connection, 
the attacker don't need to intercept the HTTPS connection or modify the content 
in the TLS tunnel, rather they just need to prevent the authorization code from 
being presented to the Au

Re: [OAUTH-WG] [EXTERNAL] Re: dpop_jkt Authorization Request Parameter

[Pieter Kasselman]

hile adding DPoP in 
new code, which may be an advantage in some deployments.

Please review and comment.  Note that I plan to add more of the attack 
description written by Pieter Kasselman to the security considerations in a 
future commit.  This attack description was sent by Pieter yesterday in a 
message with the subject "Authorization Code Log File Attack (was DPoP Interim 
Meeting Minutes)".

   -- Mike

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=04%7C01%7Cpieter.kasselman%40microsoft.com%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=%2FijJyL4AbGch83O%2B6gxmRN%2FpwXqH5ejIa46pZ0gImy0%3D=0>

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=04%7C01%7Cpieter.kasselman%40microsoft.com%7C73630bc47d8447ad414708d9b45e504e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637739139477365460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=%2FijJyL4AbGch83O%2B6gxmRN%2FpwXqH5ejIa46pZ0gImy0%3D=0>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Rotating RTs and grace periods

[Pieter Kasselman]

Neil

Is the goal to accommodate network latency or clock drift? It would be helpful 
to include reasons for why a grace period should be considered if it is allowed.

Without knowing the reasons for the grace period it is not clear why a grace 
period is a better solution than just extending the expiry time by a set time 
(60 seconds in your example) and having the client present the token a little 
earlier.

If grace periods are allowed, it may be worth considering adding additional 
mitigations against replay. For example, a grace period may be allowed if the 
refresh token is sender constrained with DPoP so there is at least some 
assurances that the request is originating from the sender (especially if the 
nonce option is used with DPoP).

I would worry about adding more complexity and less predictability by adding 
grace periods though (e.g. by looking at a refresh token, will you be able to 
tell if it can still be used or not), but your point that implementors may 
solve for it in other less predictable ways raises a valid point.

Cheers

Pieter

From: OAuth  On Behalf Of Neil Madden
Sent: Tuesday 2 November 2021 10:29
To: oauth 
Subject: [EXTERNAL] [OAUTH-WG] Rotating RTs and grace periods

Hi all,

There was a previous discussion on whether to allow a grace period during 
refresh token rotation, allowing the client to retry a refresh if the response 
fails to be received due to some transient network issue/timeout [1]. Vittorio 
mentioned that Auth0 already implement such a grace period. We (ForgeRock) 
currently do not, but we do periodically receive requests to support this. The 
current security BCP draft is silent on whether implementing such a grace 
period is a good idea, but I think we should add some guidance here one way or 
another.

My own opinion is that a grace period is not a good idea, and if it is to be 
supported as an option then it should be kept as short as possible. The reason 
(as I mentioned in the previous thread) is that it is quite easy for an 
attacker to observe when a legitimate client performs a refresh flow and so can 
easily sneak in their own request afterwards within the grace period. There are 
several reasons why it is easy for an attacker to observe this:

- RT rotation is primarily intended for public clients, such as mobile apps and 
SPAs. These clients are geographically distributed across the internet, and so 
there is a good chance that the attacker is able to observe the network traffic 
of at least some of these client instances.
- The refresh flow is typically the only request that the client makes directly 
to the AS after initial authorization, so despite the traffic being encrypted 
it is very easy for an observer to determine that the client is performing a 
refresh whenever it makes any connection to the AS.
- As well as observing the request itself, an attacker may be able to observe 
the DNS lookup for the AS hostname instead, which is even more likely to be 
observable and also in plaintext most of the time.
- An attacker in a position to steal RTs from e.g. localStorage, is probably 
also in a good position to either observe when the legitimate client refreshes 
or to actually force it to refresh early (e.g., by deleting the corresponding 
AT from the same storage).

I know some people argue that a grace period is a reasonable trade-off between 
security and usability. But I think that this kind of attack would be quite 
easy to carry out in practice for the reasons I suggest above, so I think the 
security actually degrades extremely quickly if you allow a grace period of any 
reasonable length.

On the other hand, if we discourage this entirely then people may use dubious 
workarounds instead (e.g., one proposal I've seen was to use an ID token with 
the JWT Bearer grant, effectively turning the ID Token into an ad-hoc RT with 
much fewer protections).

As a strawman, what would people think of wording like the following:

---
The AS MAY allow the original RT to be replayed for a short grace period to 
allow the client to recover if the response is not received due to a network 
problem or other transient issue. However, implementors should be aware that an 
attacker may be able to easily observe when the legitimate client makes a 
refresh request to the AS and so time their use of a stolen RT to occur within 
the grace period. Any grace period MUST be kept as short as possible, and MUST 
NOT exceed 60 seconds. Clients should prefer sender-constrained refresh tokens 
if recovery from network issues is a priority.
-

(The 60 seconds limit here is based on Auth0's grace period).

[1]: 

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Pieter Kasselman]

SHOULD is more likely to cause the right conversations to take place for 
implementors as they weigh the risks. Reducing it to MAY risks diluting it too 
much.

From: OAuth  On Behalf Of Warren Parad
Sent: Friday 15 October 2021 09:25
To: Pieter Kasselman 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD on 
an expected lifetime of an authorization code. I think sending the message that 
these should be one time use except in exceptional circumstances.


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7C0d1e820fa1664a5bb1ab08d98fb54d4f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637698831154740432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=6rSI2UvnakrWNh3qtBEgIMbRO8L9oXu8zGj4Fd128B8%3D=0>.


On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
Any weakening of the requirement should include a clear outline of the risks to 
help implementors make informed decisions.

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Ash Narayanan
Sent: Friday 15 October 2021 01:51
To: Aaron Parecki mailto:aa...@parecki.com>>
Cc: IETF oauth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

You don't often get email from 
ashvinnaraya...@gmail.com<mailto:ashvinnaraya...@gmail.com>. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>
Yes, as I said before, authorization servers are free to enforce one-time use 
of the authorization code even if there isn't a requirement to. The proposal is 
just to remove the *requirement* of authorization servers enforcing it.

I agree, and therefore I think what it really ought to be is "MAY".

Annabelle said:
There are legitimate use cases for a client to replay an authorization code. 
Connection failures happen. Servers fall over before completing requests. Users 
hit browser refresh buttons. Permitting replay of authorization codes (assuming 
valid PKCE, client creds, etc.) allows clients to handle these failure modes 
simply and gracefully via retries.

Couldn't agree more. Having experienced these exact use-cases, I can honestly 
say that denying users a smooth experience just to be compliant with the spec, 
which offers no additional security if PKCE is also being used, makes no sense.
It is also more effort (from a repository layer perspective) to implement 
one-time use than do PKCE verification.

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are there 
really use cases out there where SHA-256 is a deal breaker?

I'd be interested in these use-cases as well (I can't think of any).

On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
Yes, as I said before, authorization servers are free to enforce one-time use 
of the authorization code even if there isn't a requirement to. The proposal is 
just to remove the *requirement* of authorization servers enforcing it.

I am okay with Mike's suggestion of changing the language to "SHOULD" to 
continue to point out the possibility of enforcing one-time authorization codes 
if desired.



On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>> wrote:
Log files can exist in lots of place (clients, servers, data lakes). The 
question is whether it is a valid assumption that an attacker cannot obtain an 
Authorization Code and a Code Verifier and present it a second time round. 
Limiting the validity period is one layer of defence, PKCE is another layer, 
one time use enforcement is another. Assuming breach and designing from a 
defence in depth perspective is a good practice, so why not give implementors 
options (and guidance) to add additional layers of defence to match their risk 
profiles?


From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki mailto:aa...@parecki.com>>
Cc: IETF oauth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Ok, if the goal is to avoid unnecessary requirements I am suggesting to point 
out why MUST was changed to SHOULD. Otherwise developers will start to mix and 
match OAuth 2.0 and OAuth 2.1 requirements as they see them fit their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that as 
the general implementation.

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Pieter Kasselman]

Any weakening of the requirement should include a clear outline of the risks to 
help implementors make informed decisions.

From: OAuth  On Behalf Of Ash Narayanan
Sent: Friday 15 October 2021 01:51
To: Aaron Parecki 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

You don't often get email from ashvinnaraya...@gmail.com. Learn why this is 
important<http://aka.ms/LearnAboutSenderIdentification>
Yes, as I said before, authorization servers are free to enforce one-time use 
of the authorization code even if there isn't a requirement to. The proposal is 
just to remove the *requirement* of authorization servers enforcing it.

I agree, and therefore I think what it really ought to be is "MAY".

Annabelle said:
There are legitimate use cases for a client to replay an authorization code. 
Connection failures happen. Servers fall over before completing requests. Users 
hit browser refresh buttons. Permitting replay of authorization codes (assuming 
valid PKCE, client creds, etc.) allows clients to handle these failure modes 
simply and gracefully via retries.

Couldn't agree more. Having experienced these exact use-cases, I can honestly 
say that denying users a smooth experience just to be compliant with the spec, 
which offers no additional security if PKCE is also being used, makes no sense.
It is also more effort (from a repository layer perspective) to implement 
one-time use than do PKCE verification.

What is the practical reason for allowing "plain" PKCE in OAuth 2.1? Are there 
really use cases out there where SHA-256 is a deal breaker?

I'd be interested in these use-cases as well (I can't think of any).

On Thu, Oct 14, 2021 at 8:36 AM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
Yes, as I said before, authorization servers are free to enforce one-time use 
of the authorization code even if there isn't a requirement to. The proposal is 
just to remove the *requirement* of authorization servers enforcing it.

I am okay with Mike's suggestion of changing the language to "SHOULD" to 
continue to point out the possibility of enforcing one-time authorization codes 
if desired.



On Wed, Oct 13, 2021 at 2:15 PM Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>> wrote:
Log files can exist in lots of place (clients, servers, data lakes). The 
question is whether it is a valid assumption that an attacker cannot obtain an 
Authorization Code and a Code Verifier and present it a second time round. 
Limiting the validity period is one layer of defence, PKCE is another layer, 
one time use enforcement is another. Assuming breach and designing from a 
defence in depth perspective is a good practice, so why not give implementors 
options (and guidance) to add additional layers of defence to match their risk 
profiles?


From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki mailto:aa...@parecki.com>>
Cc: IETF oauth WG mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Ok, if the goal is to avoid unnecessary requirements I am suggesting to point 
out why MUST was changed to SHOULD. Otherwise developers will start to mix and 
match OAuth 2.0 and OAuth 2.1 requirements as they see them fit their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that as 
the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
The PKCE spec actually says "Typically, the "code_challenge" and 
"code_challenge_method" values are stored in encrypted form in the "code" 
itself" which I feel like might be a stretch to say that's typical, but this 
scenario was clearly thought of ahead of time. Doing that would enable an AS to 
avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch 
mailto:saschapreibi...@gmail.com>> wrote:
If the challenge is based on distributed authorization server configurations, 
how would they handle PKCE? I imagine that managing the state for PKCE is not 
less challenging than managing authorization codes on the server side, 
preventing reuse of them.
With that in mind I am not sure if I follow the given argument. I would prefer 
to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
HTTPS, because if that's broken then the rest of OAuth falls apart too.

On Wed, Oct 13, 2021 at 1:36 PM Warren Parad 
mailto:wpa...@rhosys.ch>> wrote:
I feel like I'm missing something, what stops just plain old network sniffing 
and replying the whole encrypted payload to the AS and getting back a valid 
token?


[Image removed by sender.]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Au

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Pieter Kasselman]

Log files can exist in lots of place (clients, servers, data lakes). The 
question is whether it is a valid assumption that an attacker cannot obtain an 
Authorization Code and a Code Verifier and present it a second time round. 
Limiting the validity period is one layer of defence, PKCE is another layer, 
one time use enforcement is another. Assuming breach and designing from a 
defence in depth perspective is a good practice, so why not give implementors 
options (and guidance) to add additional layers of defence to match their risk 
profiles?


From: OAuth  On Behalf Of Sascha Preibisch
Sent: Wednesday 13 October 2021 22:06
To: Aaron Parecki 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

Ok, if the goal is to avoid unnecessary requirements I am suggesting to point 
out why MUST was changed to SHOULD. Otherwise developers will start to mix and 
match OAuth 2.0 and OAuth 2.1 requirements as they see them fit their needs.
In regards to encrypted values in PKCE, Aaron, I can also not confirm that as 
the general implementation.

On Wed, 13 Oct 2021 at 13:56, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
The PKCE spec actually says "Typically, the "code_challenge" and 
"code_challenge_method" values are stored in encrypted form in the "code" 
itself" which I feel like might be a stretch to say that's typical, but this 
scenario was clearly thought of ahead of time. Doing that would enable an AS to 
avoid storing server-side state.

On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch 
mailto:saschapreibi...@gmail.com>> wrote:
If the challenge is based on distributed authorization server configurations, 
how would they handle PKCE? I imagine that managing the state for PKCE is not 
less challenging than managing authorization codes on the server side, 
preventing reuse of them.
With that in mind I am not sure if I follow the given argument. I would prefer 
to keep MUST as it is today.


On Wed, 13 Oct 2021 at 13:37, Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
HTTPS, because if that's broken then the rest of OAuth falls apart too.

On Wed, Oct 13, 2021 at 1:36 PM Warren Parad 
mailto:wpa...@rhosys.ch>> wrote:
I feel like I'm missing something, what stops just plain old network sniffing 
and replying the whole encrypted payload to the AS and getting back a valid 
token?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7C93c20c9c80354c77c10708d98e8d6776%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637697560293904430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=vwcfj%2FVB8a84yDoAmqkXraWyqjOfWGrV08XdtZLWMXw%3D=0>.


On Wed, Oct 13, 2021 at 10:33 PM Aaron Parecki 
mailto:aa...@parecki.com>> wrote:
Aside from the "plain" method, the PKCE code verifier never leaves the client 
until it's sent along with the authorization code in the POST request to the 
token endpoint. The only place it can leak at that point is if the 
authorization server itself leaks it. If you have things leaking from the 
authorization server log, you likely have much bigger problems than 
authorization code replays.

Keep in mind that even with the proposed change to drop the requirement of 
authorization codes being one time use, authorization servers are free to 
enforce this still if they want. Authorization code lifetimes are still 
expected to be short lived as well.

Aaron


On Wed, Oct 13, 2021 at 1:25 PM Pieter Kasselman 
mailto:pieter.kassel...@microsoft.com>> wrote:
Aaron, I was curious what prevents an attacker from presenting an Authorization 
Code and a PKCE Code Verifier for a second time if the one time use requirement 
is removed. Is there another countermeasure in  PKCE that would prevent it? For 
example, an attacker may obtain the Authorization Code and the Code Verifier 
from a log and replay it.

Cheers

Pieter

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>>
Cc: Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>;
 oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Warren, I didn't see you on the interim call, so you might be missing some 
context.

The issue that was discussed is that using PKCE already provides all the 
security benefit that is gained by enforcing single-use authorization codes. 
Therefore, requiring that they are single-use isn't necessary as it doesn't 
pro

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Pieter Kasselman]

Aaron, I was curious what prevents an attacker from presenting an Authorization 
Code and a PKCE Code Verifier for a second time if the one time use requirement 
is removed. Is there another countermeasure in  PKCE that would prevent it? For 
example, an attacker may obtain the Authorization Code and the Code Verifier 
from a log and replay it.

Cheers

Pieter

From: OAuth  On Behalf Of Aaron Parecki
Sent: Wednesday 13 October 2021 18:40
To: Warren Parad 
Cc: Mike Jones ; oauth@ietf.org
Subject: [EXTERNAL] Re: [OAUTH-WG] Authorization code reuse and OAuth 2.1

Warren, I didn't see you on the interim call, so you might be missing some 
context.

The issue that was discussed is that using PKCE already provides all the 
security benefit that is gained by enforcing single-use authorization codes. 
Therefore, requiring that they are single-use isn't necessary as it doesn't 
provide any additional benefit.

If anyone can think of a possible attack by allowing authorization codes to be 
reused *even with a valid PKCE code verifier* then that would warrant keeping 
this requirement.

---
Aaron Parecki


On Wed, Oct 13, 2021 at 10:27 AM Warren Parad 
mailto:40rhosys...@dmarc.ietf.org>> wrote:
Isn't it better for it to be worded as we want it to be, with the implication 
being that of course it might be difficult to do that, but that AS devs will 
think long and hard about sometimes not denying the request? Even with MUST, 
some AS will still allow reuse of auth codes. Isn't that better than flat out 
saying: sure, there's a valid reason

In other words, how do we think about RFCs? Do they exist to be followed to the 
letter or not at all? Or do they exist to stipulate this is the way, but 
acknowledge that not everyone will build a solution that holds them as law.

Let's look at SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid 
reasons in particular circumstances to ignore a particular item, but the full 
implications must be understood and carefully weighed before choosing a 
different course.

I think recommended here is not sufficient nor are there valid reasons. "It's 
too hard" isn't really a valid reason. Isn't it better in this case for an AS 
to not be compliant with the RFC, than it is to relax this to SHOULD and have 
lots of AS thinking reusing auth codes is a viable solution, "because they are 
a special snowflake where SHOULD should apply".

Are we setting the standard or instead attempting to sustain a number of "AS 
that are in compliance with the RFC"?


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement 
Authress.


On Wed, Oct 13, 2021 at 7:17 PM Mike Jones 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
During today's call, it was asked whether we should drop the OAuth 2.0 language 
that:
 The client MUST NOT use the authorization code
 more than once.  If an authorization code is used more than
 once, the authorization server MUST deny the request and SHOULD
 revoke (when possible) all tokens previously issued based on
 that authorization code."

The rationale given was that enforcing one-time use is impractical in 
distributed authorization server deployments.

Thinking about this some more, at most, we should relax this to:
 The client MUST NOT use the authorization code
 more than once.  If an authorization code is used more than
 once, the authorization server SHOULD deny the request and SHOULD
 revoke (when possible) all tokens previously issued based on
 that authorization code."

In short, it should remain illegal for the client to try to reuse the 
authorization code.  We can relax the MUST to SHOULD in the server requirements 
in recognition of the difficulty of enforcing the MUST.

Code reuse is part of some attack scenarios.  We must not sanction it.

  -- Mike

___
OAuth mailing list
OAuth@ietf.org