[OAUTH-WG] AD Review of draft-ietf-oauth-dpop-11

[Roman Danyliw]

Hi!

I performed an AD review on draft-ietf-oauth-dpop-11.  Thanks for this 
document.  Comments below.

** The document has 6 listed authors.  Could this rationale for this be 
explained on the list and captured in the shepherd write-up.

** Section 2.
(CRIME,
   BREACH, Heartbleed, and the Cloudflare parser bug are some examples). There 
have also been numerous published token theft attacks on OAuth
   implementations themselves

Good pointers.  Could informative references be provided for them.

** Section 4.2.

alg: a digital signature algorithm identifier such as per
  [RFC7518].  

Shouldn't this text constraint the algorithm identifier as coming from a 
registry pointed to in RFC7518 (i.e., 
https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms)?

** Section 4.1.

htm: The HTTP method of the request to which the JWT is attached,
  as defined in [RFC9110]. 

Shouldn't the values in this field come from the registry HTTP methods registry:
https://www.iana.org/assignments/http-methods/http-methods.xhtml?  RFC9110 
specifies the semantics of the fields, not the values.

** Section 4.1.  Shouldn't these text read like the description of htm:

OLD
The HTTP target URI (Section 7.1 of [RFC9110]), without query
  and fragment parts. 

NEW
The HTTP target URI (Section 7.1 of [RFC9110]), without query and fragment 
parts of the request to which the JWT is attached.

** Section 4.2.  Editorial.

OLD
But that it be a minimal  subset of the HTTP data so as to
   avoid the substantial difficulties inherent in attempting to
   normalize HTTP messages.

NEW
This design approach of using only a minimal  subset of the HTTP header data is 
to avoid the substantial difficulties inherent in attempting to normalize HTTP 
messages.

** Section 4.3.  Editorial.  Clarifying.

OLD
the header field value is a well-formed JWT,

NEW
the DPoP HTTP request header field value is a well-formed JWT,

** Section 4.3.

the alg JOSE header parameter indicates an asymmetric digital
  signature algorithm, is not none, is supported by the application,
  and is deemed secure,

-- check feedback already provided in Section 4.2 about this field pointing to 
a value in a JOSE registry
-- "is deemed secure" seems open ended.  Perhaps "and is acceptable per local 
policy"

** Section 5.  Normative language

OLD
The client must discard the response in this case,

NEW
The client MUST ...

** Section 5.1.  Cite the relevant registry which would the source of JWS alg 
values in the dpop_signing_alg_values_supported array

** Section 7

   Binding the token value to the proof in this way prevents a
   calculated proof to be used with multiple different access token
   values across different requests.  

What makes a proof "calculated"?

** Section 7.

its inclusion strongly
   binds the access token value to the holder of the key used to
   generate the signature.


Is "strongly binds" the same as "cryptographically binds"?  "Strong" is used in 
the next paragraph too.  Please review it.

** Section 10.1.  Editorial.

OLD
The dpop_jkt parameter can be used as described above to bind the
  issued authorization code to a specific key.

NEW
The dpop_jkt parameter can be used as described in Section 10 to bind the 
issued authorization code to a specific key.

** Section 10.1.  Typo. s/distingush/distinguish/

**  Section 11.1.  Editorial.  Recommend unpacking this dense sentence.

OLD
   To prevent multiple uses of the same DPoP proof servers can store, in
   the context of the target URI, the jti value of each DPoP proof for
   the time window in which the respective DPoP proof JWT would be
   accepted and decline HTTP requests to the same URI for which the jti
   value has been seen before. 
 
NEW
To prevent multiple uses of the same DPoP proof, servers can store, inthe 
context of the target URI, the jti value of each DPoP proof forthe time 
window in which the respective DPoP proof JWT would beaccepted.  HTTP 
requests to the same URI for which the jti value has been seen before would be 
declined.

**  Section 11.1.  Recommend unpacking this dense sentence.

OLD
Because clock skews between servers
   and clients may be large, servers may choose to limit DPoP proof
   lifetimes by using server-provided nonce values containing the time
   at the server rather than comparing the client-supplied iat time to
   the time at the server, yielding intended results even in the face of
   arbitrarily large clock skews.

NEW
Because clock skews between servers
and clients may be large, servers MAY limit DPoP proof lifetimes by using 
server-provided nonce values containing the time at the server rather than 
comparing the client-supplied iat time to the time at the server.  Nonces 
created in this way yield the same result even in the face of arbitrarily large 
clock skews.

**  Section 11.1.  Editorial.

OLD
If jti is enforced unique for
   the lifetime of the nonce, there is no additional 

[OAUTH-WG] Last Call: (OAuth 2.0 Rich Authorization Requests) to Proposed Standard

[The IESG]

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'OAuth 2.0 Rich Authorization
Requests'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2022-11-17. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document specifies a new parameter authorization_details that is
   used to carry fine-grained authorization data in OAuth messages.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/



No IPR declarations have been submitted directly on this I-D.





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

Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12

[Justin Richer]

Thank you, Roman — I put together a PR with those changes here:

https://github.com/oauthstuff/draft-oauth-rar/pull/89

 — Justin

> On Oct 27, 2022, at 1:51 PM, Roman Danyliw  wrote:
> 
> Hi!
> 
> I appreciate the updated in -13 and -14.  Most of the AD feedback has been 
> addressed there.  Combing through the multiple sub-threads, I've pruned to 
> text to cover what is the residual feedback.  See below.
> 
> To keep this document moving, I'm going to start IETF LC on it.  Please 
> address this feedback concurrently.
> 
>>> -Original Message-
>>> From: Justin Richer 
>>> Sent: Thursday, September 15, 2022 11:20 AM
>>> To: Roman Danyliw 
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
>>> 
>>> Hi Roman, some responses inline.
>>> 
 On Sep 14, 2022, at 6:30 PM, Roman Danyliw  wrote:
> 
> [snip]
> 
 ** Section 6.1
 
 However, when comparing a new request to an existing request,
  authorization servers can use the same processing techniques as used
  in granting the request in the first place to determine if a resource
  owner needs to authorize the request.
 
 Why is it possible to assess two arbitrary requests in this case to
 determine "if
>>> a resource owner needs to authorize the request", but the prior
>>> paragraph explicitly calls out that comparing two arbitrary requests
>>> is not feasible?  To me is seems like comparing two requests to
>>> understand if more or less permissions are being requested is
>>> equivalent to determining if a new request exceed the current request to
>> determine if going back to the resource owner is needed.
 
>>> 
>>> It might be possible to do such a comparison in a specific case, but
>>> we can’t add logic in the general case. In OAuth, scopes are supposed
>>> to be purely additive, so if you have another scope it’s for “more”
>>> things. We know in practice that that’s not always how it works.
>>> Things get much more complex with RAR because you could have an object
>>> with :more: fields in it that makes things more :strict: by the
>>> presence of those fields. That’s all going to be up to the “type”
>>> definition though, so if you understand the “type” definition you
>>> could do a comparison based on that. To me the text is clear, can you 
>>> suggest
>> how we could clarify this?
>> 
>> OLD 1
>> Since the nature of an authorization details request
>>   is based solely on the API or APIs that it is describing, there is
>>   not a simple means of comparing any two arbitrary authorization
>>   details requests.
>> 
>> NEW 1
>> Since the semantics of the fields in the authorization details result will be
>> implementation specific to a given API or set of APIs, there is a no 
>> standardized
>> mechanism to compare two arbitrary authorization detail requests.
>> 
>> OLD 2
>>   However, when comparing a new request to an existing request,
>> 
>> NEW 2
>> 
>> When comparing a new request to an existing request, ...
> 
> [snip]
> 
> 
 ** Section 11.2.
 
 Accept authorization_details parameter in authorization requests
 including basic syntax check  for compliance with this
 specification
 
 Why only "basic syntax checking"?  Perhaps "syntax checking"?
>>> 
>>> I’m not positive, but I think the guidance here is meant for “basic”
>>> to mean more like “make sure it’s a JSON object and that it has a type
>>> field” as opposed to “check the type field’s value and run it against a JSON
>> Schema definition”.
>> 
>> I don't think this is worth unpacking and would just recommend:
>> 
>> OLD
>> *  Accept authorization_details parameter in authorization requests
>>  including basic syntax check for compliance with this
>>  specification
>> 
>> NEW
>> *  Accept authorization_details parameter in authorization requests
>>  Conformant with this this specification
> 
> Thanks,
> Roman
> 
> ___
> 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] AD review of draft-ietf-oauth-rar-12

[Roman Danyliw]

Hi!

I appreciate the updated in -13 and -14.  Most of the AD feedback has been 
addressed there.  Combing through the multiple sub-threads, I've pruned to text 
to cover what is the residual feedback.  See below.

To keep this document moving, I'm going to start IETF LC on it.  Please address 
this feedback concurrently.

> > -Original Message-
> > From: Justin Richer 
> > Sent: Thursday, September 15, 2022 11:20 AM
> > To: Roman Danyliw 
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-rar-12
> >
> > Hi Roman, some responses inline.
> >
> > > On Sep 14, 2022, at 6:30 PM, Roman Danyliw  wrote:

[snip]

> > > ** Section 6.1
> > >
> > >  However, when comparing a new request to an existing request,
> > >   authorization servers can use the same processing techniques as used
> > >   in granting the request in the first place to determine if a resource
> > >   owner needs to authorize the request.
> > >
> > > Why is it possible to assess two arbitrary requests in this case to
> > > determine "if
> > a resource owner needs to authorize the request", but the prior
> > paragraph explicitly calls out that comparing two arbitrary requests
> > is not feasible?  To me is seems like comparing two requests to
> > understand if more or less permissions are being requested is
> > equivalent to determining if a new request exceed the current request to
> determine if going back to the resource owner is needed.
> > >
> >
> > It might be possible to do such a comparison in a specific case, but
> > we can’t add logic in the general case. In OAuth, scopes are supposed
> > to be purely additive, so if you have another scope it’s for “more”
> > things. We know in practice that that’s not always how it works.
> > Things get much more complex with RAR because you could have an object
> > with :more: fields in it that makes things more :strict: by the
> > presence of those fields. That’s all going to be up to the “type”
> > definition though, so if you understand the “type” definition you
> > could do a comparison based on that. To me the text is clear, can you 
> > suggest
> how we could clarify this?
> 
> OLD 1
> Since the nature of an authorization details request
>is based solely on the API or APIs that it is describing, there is
>not a simple means of comparing any two arbitrary authorization
>details requests.
> 
> NEW 1
> Since the semantics of the fields in the authorization details result will be
> implementation specific to a given API or set of APIs, there is a no 
> standardized
> mechanism to compare two arbitrary authorization detail requests.
> 
> OLD 2
>However, when comparing a new request to an existing request,
> 
> NEW 2
> 
> When comparing a new request to an existing request, ...

[snip]


> > > ** Section 11.2.
> > >
> > > Accept authorization_details parameter in authorization requests
> > >  including basic syntax check  for compliance with this
> > >  specification
> > >
> > > Why only "basic syntax checking"?  Perhaps "syntax checking"?
> >
> > I’m not positive, but I think the guidance here is meant for “basic”
> > to mean more like “make sure it’s a JSON object and that it has a type
> > field” as opposed to “check the type field’s value and run it against a JSON
> Schema definition”.
> 
> I don't think this is worth unpacking and would just recommend:
> 
> OLD
> *  Accept authorization_details parameter in authorization requests
>   including basic syntax check for compliance with this
>   specification
> 
> NEW
> *  Accept authorization_details parameter in authorization requests
>   Conformant with this this specification

Thanks,
Roman
 
___
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. Learn 
why this is important

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=
> Status: 
> 

Re: [OAUTH-WG] Security Topics | Incorporate in-browser communication security considerations | PR53

[Christian Mainka]

Hi,

glad to hear that you like our work.

If you have any questions or if we can do anything to help you with 
this, don't hesitate to ask.


Best regards
Christian

On 26.10.22 17:13, Donna Chong Nee wrote:

Hi, thanks so much.  Will take my time amending this with some help.

Smart E11

On Thu, 27 Oct 2022, 02:16 Daniel Fett, 
wrote:


Hi Christian,

thanks for bringing this to our attention! I think the recommendations in
the PR are very helpful and we will consider adding the text to the
document.

-Daniel
Am 25.10.22 um 15:37 schrieb Christian Mainka:

Hi,

we would like to request the inclusion of _in-browser communication
security considerations_ in the OAuth security topics.

We found that in-browser communications like the postMessage API is widely
used by Clients and Authorization Servers as an alternative to the
standardized HTTP redirects.
If these techniques are used insecurely, OAuth token leaks and injections
are possible.

We publish our results soon at ACM CCS in November 2022.
The paper is accessible [1].

We think that the paragraph about in-browser communications should be
added to the security topics.
We created a pull request [2] to help developers in understanding the
risks and best practices of using in-browser communications in OAuth.

We are happy to discuss the idea here or directly in the pull request.

Best regards
Christian

[1]: "DISTINCT: Identity Theft using In-Browser Communications in
Dual-Window Single Sign-On, https://distinct-sso.com/paper.pdf

[2]:
https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/53

___
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


--
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security
Chair for Network and Data Security
Ruhr University Bochum, Germany

Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
https://nds.rub.de/chair/people/cmainka/
@CheariX

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