Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Aaron Parecki]

> obviously we can't use any sensitive keys with these

That's not true at all, public clients can use keys that they create
themselves or are issued to a particular instance. That's one of the
reasons we are giving a name to this type of client in OAuth 2.1, a
"credentialed" client.

A public client clearly can't share credentials with other instances of the
public client, but there's no reason they can't use a key that is only ever
known to them.




On Thu, Oct 7, 2021 at 9:06 PM Ash Narayanan 
wrote:

> Oh geez, yesterday was my day off but ended up down a deep rabbit hole
> after reading this draft and the ones that came before it.
>
> I do not support adoption and was going to list my reasons but Warren
> Parad beat me to it.
>
> In addition to the list he has provided, I'd also like to see the draft
> make a mention of public clients; obviously we can't use any sensitive keys
> with these.
>
>
> Regards,
> Ash
>
> On Thu, Oct 7, 2021 at 11:02 PM Neil Madden 
> wrote:
>
>> Canonicalised signature schemes inevitably lead to cryptographic doom,
>> and should die with SAML (ha!). For that reason I do not support adoption
>> of this draft.
>>
>> I also think the arguments for canonicalisation vanish as soon as you
>> want end-to-end confidentiality too.
>>
>> — Neil
>>
>> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef 
>> wrote:
>>
>> 
>> All,
>>
>> As a followup on the interim meeting today, this is a *call for adoption
>> *for the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
>> as a WG document:
>> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>>
>> Please, provide your feedback on the mailing list by* October 20th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> Manage My Preferences , Unsubscribe
>> 
>>
>> ___
>> 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
>
-- 
---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Ash Narayanan]

Oh geez, yesterday was my day off but ended up down a deep rabbit hole
after reading this draft and the ones that came before it.

I do not support adoption and was going to list my reasons but Warren Parad
beat me to it.

In addition to the list he has provided, I'd also like to see the draft
make a mention of public clients; obviously we can't use any sensitive keys
with these.


Regards,
Ash

On Thu, Oct 7, 2021 at 11:02 PM Neil Madden 
wrote:

> Canonicalised signature schemes inevitably lead to cryptographic doom, and
> should die with SAML (ha!). For that reason I do not support adoption of
> this draft.
>
> I also think the arguments for canonicalisation vanish as soon as you want
> end-to-end confidentiality too.
>
> — Neil
>
> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef 
> wrote:
>
> 
> All,
>
> As a followup on the interim meeting today, this is a *call for adoption *for
> the *OAuth Proof of Possession Tokens with HTTP Message Signature* draft
> as a WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>
> Please, provide your feedback on the mailing list by* October 20th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Manage My Preferences , Unsubscribe
> 
>
> ___
> 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] I-D Action: draft-ietf-oauth-v2-1-04.txt

[Aaron Parecki]

Hello all, on Tuesday we published a new revision of the OAuth 2.1 draft in
advance of the interim meeting next week.

The main changes are documented in the changelog section but are summarized
below as well:

* Added explicit mention of not sending access tokens in URI query strings
* Clarifications on definition of client types
* Consolidated text around loopback vs localhost
* Editorial clarifications throughout the document

There are still a number of outstanding issues we are aware of, and have
highlighted a few of them for discussion during the session next week.

Aaron


On Tue, Oct 5, 2021 at 5:19 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : The OAuth 2.1 Authorization Framework
> Authors : Dick Hardt
>   Aaron Parecki
>   Torsten Lodderstedt
> Filename: draft-ietf-oauth-v2-1-04.txt
> Pages   : 85
> Date: 2021-10-05
>
> Abstract:
>The OAuth 2.1 authorization framework enables a third-party
>application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and an authorization service, or by
>allowing the third-party application to obtain access on its own
>behalf.  This specification replaces and obsoletes the OAuth 2.0
>Authorization Framework described in RFC 6749.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-04.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.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] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification

[Rifaat Shekh-Yusef]

Thanks Karsten!

On Thu, Oct 7, 2021 at 1:21 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> Hi Rifaat,
>
> apologies for the delay.
>
> We published a new draft addressing your comments.
>
> We changed Section 2.4, paragraph 3 to:
>
> If clients interact with both authorization servers supporting this
>specification and authorization servers not supporting this
>specification, clients MUST store the information which authorization
>server supports the iss parameter.  Clients *MUST* reject authorization
>responses without the iss parameter from authorization servers which
>do support the parameter according to the client's configuration.
>*Clients SHOULD discard authorization responses with the iss parameter
>from authorization servers which do not indicate their support for
>the parameter.  However, there might be legitimate authorization
>servers that provide the iss parameter without indicating their
>support in their metadata.  The decision of whether to accept such
>responses is individual for every scenario and it is not in the scope
>of this specification.*
>
>
> Let us know if there is anything else we should work on.
>
>
> Best regards,
> Karsten
> On 26.09.2021 00:04, Rifaat Shekh-Yusef wrote:
>
> Karsten, Daniel,
>
> Can you please address my comments in a new version of the draft to allow
> me to progress it?
>
> Regards,
>  Rifaat
>
>
> On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen <
> karsten.meyerzuselhau...@hackmanit.de> wrote:
>
>> Hi Rifaat,
>>
>> thank you for the shepherd's review.
>>
>> Those are valid comments. We will have a second look on this paragraph.
>>
>> Best regards,
>> Karsten
>> On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote:
>>
>> Hi Karsten, Daniel,
>>
>> As the document shepherd, I have reviewed the document and I have the
>> following comments on draft-ietf-oauth-iss-auth-resp-01 version:
>>
>>
>> Section 2.4, paragraph 3, first sentence:
>>
>> "If clients interact with both authorization servers supporting this
>>specification and authorization servers not supporting this
>>specification, clients SHOULD store the information which
>>authorization server supports the "iss" parameter."
>>
>> Why is this a SHOULD?
>>
>>
>> "Clients MUST
>>reject authorization responses without the "iss" parameter from
>>authorization servers which do support the parameter according to the
>>client's configuration."
>>
>> What should the client do when it receives a response with "iss" parameter
>> from an authorization server that did not indicate its support for this
>> parameter?
>>
>>
>> Section 7
>>
>> RFC6479 should be replaced with *RFC6749*
>>
>>
>> Regards,
>>   Rifaat
>>
>> ___
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> --
>> Karsten Meyer zu Selhausen
>> Senior IT Security Consultant
>> Phone:   +49 (0)234 / 54456499
>> Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, 
>> Security Training
>>
>> Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? 
>> Find out more on our 
>> blog:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>>
>> Hackmanit GmbH
>> Universitätsstraße 60 (Exzenterhaus)
>> 44789 Bochum
>>
>> Registergericht: Amtsgericht Bochum, HRB 14896
>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
>> Christian Mainka, Prof. Dr. Marcus Niemietz
>>
>> --
> Karsten Meyer zu Selhausen
> Senior IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? 
> Find out more on our 
> blog:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Prof. Dr. Marcus Niemietz
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Neil Madden]

Canonicalised signature schemes inevitably lead to cryptographic doom, and 
should die with SAML (ha!). For that reason I do not support adoption of this 
draft. 

I also think the arguments for canonicalisation vanish as soon as you want 
end-to-end confidentiality too.

— Neil

> On 6 Oct 2021, at 22:02, Rifaat Shekh-Yusef  wrote:
> 
> 
> All,
> 
> As a followup on the interim meeting today, this is a call for adoption for 
> the OAuth Proof of Possession Tokens with HTTP Message Signature draft as a 
> WG document:
> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
> 
> Please, provide your feedback on the mailing list by October 20th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Manage My Preferences , Unsubscribe 


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

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Warren Parad]

I do not support adoption.

While I love the idea to be able to restrict the usage of the access token
by the client, enabling longer expiry access tokens, and preventing usage
to perform unexpected actions with that token, the reasons I do not support
the adoption are as follows:

* The draft depends on another draft and personally not one that I even
agree with. Saying that the "draft is officially adopted" doesn't justify
depending on it.
* I reject the use of an additional header to transmit additional
authorization information. Due to the nature of this information may be
conveyed and stored throughout a number of systems which would all need
access to this complexity. As headers and authorization evolves the
introduction and replacement of existing headers provides additional
security vulnerabilities.
* The draft does not support multiple clients with access to the access
token who all should be able to provide different client signatures and all
be verifiable by the RS.
* This forces the RS to lookup two pieces of information in the case of
signed JWTs, the JWKs from the AS and the JWKs from the client
* The argument in the introduction is flawed

Bearer tokens are simple to implement but also have the significant
> security downside of allowing anyone who sees the access token to use that
> token.


This is not a complete argument because I can replace the words in the
sentence and justify that HTTPSig should never be used by the same argument:

> HTTPSig tokens are incredibly complex to implement but also have the
> significant security downside of allowing anyone who sees the access token
> and signature to use that token.


We need to come up with a better argument such as: *This allows a client to
reduce use of the token to a smaller window to where the signature is also
valid.*
That would allow us to better focus on the value that the RFC would
provide, rather than getting stuck with arbitrary implementation of another
RFC draft as it would apply to OAuth.



Warren Parad

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


On Thu, Oct 7, 2021 at 11:03 AM Denis  wrote:

> I am not supportive of adoption of this document by the WG *at this time*.
>
> As I said during the last interim meeting, at this time, there is no
> security considerations section, nor a privacy considerations section.
>
> The current draft describes a mechanism but does not state how the signing
> key will be established and / or come from.
>
> From a security considerations point of view, if the client has the
> control of the private key, it might be able to voluntary transmit
> the private key to another client in order to mount a client collaborative
> attack. If the client is unable to transmit the private key
> to another client in order to mount a collaborative attack, it might be
> able to perform all the cryptographic computations that
> the other client needs. It is important to state which protections (or
> detection) features will be obtained as well as which protections
> (or detection) features will not be obtained. A top-down approach is
> currently missing.
>
> From a privacy considerations point of view, if the same public key is
> used to sign the messages whatever the RS is, this will allow
> different RSs to link the requests from the same client. It is important
> to state which protections (or detection) features will be obtained
> as well as which protections (or detection) features will not be obtained.
>
> Let us wait to have both the security considerations section and the
> privacy considerations section written,
> before adopting this draft as a WG document.
>
> Denis
>
> Remember token binding? It was a stable draft. The OAuth WG spent a bunch
> of cycles building on top of token binding, but token binding did not get
> deployed, so no token binding for OAuth.
>
> As I mentioned, I think Justin and Annabelle (and anyone else interested)
> can influence HTTP Sig to cover OAuth use cases.
>
> /Dick
>
> ᐧ
>
> On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki  wrote:
>
>> This actually seems like a great time for the OAuth group to start
>> working on this more closely given the relative stability of this draft as
>> well as the fact that it is not yet an RFC. This is a perfect time to be
>> able to influence the draft if needed, rather than wait for it to be
>> finalized and then have to find a less-than-ideal workaround for something
>> unforeseen.
>>
>> Aaron
>>
>> On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt  wrote:
>>
>>> I meant it is not yet adopted as an RFC.
>>>
>>> To be clear, I think you are doing great work on the HTTP Sig doc, and a
>>> number of concerns I have with HTTP signing have been addressed => I just
>>> think that doing work in the OAuth WG on a moving and unproven draft in the
>>> HTTP WG is not a good use of resources in the OAuth WG at this time.
>>>
>>>
>>> ᐧ
>>>
>>> On Wed, Oct 6, 2021 at 2:20 PM Justin Richer  

Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

[Denis]

I am not supportive of adoption of this document by the WG /at this time/.

As I said during the last interim meeting, at this time, there is no 
security considerations section, nor a privacy considerations section.


The current draft describes a mechanism but does not state how the 
signing key will be established and / or come from.


From a security considerations point of view, if the client has the 
control of the private key, it might be able to voluntary transmit
the private key to another client in order to mount a client 
collaborative attack. If the client is unable to transmit the private key
to another client in order to mount a collaborative attack, it might be 
able to perform all the cryptographic computations that
the other client needs. It is important to state which protections (or 
detection) features will be obtained as well as which protections
(or detection) features will not be obtained. A top-down approach is 
currently missing.


From a privacy considerations point of view, if the same public key is 
used to sign the messages whatever the RS is, this will allow
different RSs to link the requests from the same client. It is important 
to state which protections (or detection) features will be obtained

as well as which protections (or detection) features will not be obtained.

Let us wait to have both the security considerations section and the 
privacy considerations section written,

before adopting this draft as a WG document.

Denis


Remember token binding? It was a stable draft. The OAuth WG spent a 
bunch of cycles building on top of token binding, but token binding 
did not get deployed, so no token binding for OAuth.


As I mentioned, I think Justin and Annabelle (and anyone else 
interested) can influence HTTP Sig to cover OAuth use cases.


/Dick
ᐧ

On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki > wrote:


This actually seems like a great time for the OAuth group to start
working on this more closely given the relative stability of this
draft as well as the fact that it is not yet an RFC. This is a
perfect time to be able to influence the draft if needed,
rather than wait for it to be finalized and then have to find a
less-than-ideal workaround for something unforeseen.

Aaron

On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt mailto:dick.ha...@gmail.com>> wrote:

I meant it is not yet adopted as an RFC.

To be clear, I think you are doing great work on the HTTP Sig
doc, and a number of concerns I have with HTTP signing have
been addressed => I just think that doing work in the OAuth WG
on a moving and unproven draft in the HTTP WG is not a good
use of resources in the OAuth WG at this time.


ᐧ

On Wed, Oct 6, 2021 at 2:20 PM Justin Richer mailto:jric...@mit.edu>> wrote:

> HTTP Sig looks very promising, but it has not been
adopted as a draft

Just to be clear, the HTTP Sig draft is an official
adopted document of the HTTP Working Group since about a
year ago. I would not have suggested we depend on it for a
document within this WG otherwise.

 — Justin


On Oct 6, 2021, at 5:08 PM, Dick Hardt
mailto:dick.ha...@gmail.com>> wrote:

I am not supportive of adoption of this document at this
time.

I am supportive of the concepts in the document. Building
upon existing, widely used, proven security mechanisms
gives us better security.

HTTP Sig looks very promising, but it has not been
adopted as a draft, and as far as I know, it is not
widely deployed.

We should wait to do work on extending HTTP Sig for OAuth
until it has stabilized and proven itself in the field.
We have more than enough work to do in the WG now, and
having yet-another PoP mechanism is more likely to
confuse the community at this time.

An argument to adopt the draft would be to ensure HTTP
Sig can be used in OAuth.
Given Justin and Annabelle are also part of the OAuth
community, I'm sure they will be considering how HTTP Sig
can apply to OAuth, so the overlap is serving us already.

/Dick


ᐧ

On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki
mailto:aa...@parecki.com>> wrote:

I support adoption of this document.

- Aaron

On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef
mailto:rifaat.s.i...@gmail.com>> wrote:

All,

As a followup on the interim meeting today, this
is a *call for adoption *for the *OAuth Proof of
Possession Tokens with HTTP Message
Signature* draft as a