Re: [OAUTH-WG] HTTP signing spec and nonce

[Samuel Erdtman]

To me it seems reasonable that a client may send multiple signed messages
in one second.

So I´m +1 for a nonce. A more fine grained timestamp is nice but I think we
might end upp at the same place, someone saying that they think it is
reasonable to send multiple signed messages the same millisecond.

//Samuel

On Sun, Feb 28, 2016 at 10:34 PM, Justin Richer  wrote:

> I understand how they work, I’ve built exactly that cache before. But I
> askWouldn’t a unique timestamp have the same effect? Currently it’s integer
> seconds but slicing that down further (floating point seconds?) if people
> desired would allow for multiple signed messages in the same second from
> the same client using the otherwise same parameters.
>
> “Other protocols do it” is not a compelling reason on its own, especially
> when the example of “other protocols” includes WS-* ;)
>
> Seriously though, an optional nonce is easy to add to the draft if there’s
> enough WG support, I’m just hesitant to add more complexity than needed to
> this.
>
>  — Justin
>
> On Feb 26, 2016, at 11:06 PM, Dominick Baier 
> wrote:
>
> The nonce would allow to build a replay cache, the timestamp to trim that
> cache and reject messages that are too old.
>
> Similar protocols have a nonce for the above reasons (ws-sec msg security,
> hawk)...
>
> —
> cheers
> Dominick Baier
>
> On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu) wrote:
>
> I’d be glad to add in a nonce if there’s a compelling reason for it, such
> as closing a security attack vector.
>
> What’s the proposed purpose of the nonce? Is it just to add randomness to
> the signing base? Or is it to prevent replay at the RS? If the former, the
> timestamp should add enough of that and it can be verified to be within a
> reasonable window by the RS by comparing it with the time the request was
> made. If the latter, the RS is going to have to track previously used
> nonces for some amount of time.
>
> There was a small discussion of just signing an outgoing “Date:” header
> instead of the separate timestamp, but the timestamp seemed to be more
> robust. I forget the full reasoning though.
>
>  — Justin
>
> On Feb 26, 2016, at 9:49 AM, Brock Allen  wrote:
>
> Question about the HTTP signing spec – why is there no nonce (and just a
> timestamp)?
>
> TIA
>
> -Brock
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

[Phil Hunt (IDM)]

The issue for any service is that things like gateways and proxies may change 
or add parameters.

There is a long tradition with http to mess with things headers and payload in 
the real world. Not ideal, but a certain reality. 

Thus for certain services it is likely only possible to sign a subset of params 
that the client and service provider want to verify did not change. 

Phil

> On Feb 28, 2016, at 18:39, Manger, James  
> wrote:
> 
> Being able to selectively include or exclude individual query string 
> name=value parameters in a signature feels far too dangerous. Always sign 
> them all — with the only exception being the signature itself if transmitted 
> as a query string parameter.
> Unfortunately we do need to selectively include or exclude HTTP headers as 
> they are a mix of transport, app-layer, end-to-end, and hop-by-hop items.
>  
> Ignoring duplicate query parameter names is a poor design for a fairly 
> generic HTTP signing method. My suggestion would be to do a stable sort on 
> parameter names. That is, sort the names, but preserve the order of values 
> when a name appears multiple times. …hoping that works with almost all 
> frameworks.
>  
> --
> James Manger
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen
> Sent: Monday, 29 February 2016 12:17 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Yea, I’m cool with just saying “duplicate keys won’t work” for my 
> implementation, unless I do some implementation specific thing like sort them 
> by value order or some such (but that would have to be on both sides).
>  
> -Brock
>  
> From: Justin Richer [mailto:jric...@mit.edu] 
> Sent: Sunday, February 28, 2016 8:13 PM
> To: Brock Allen 
> Cc:  
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP 
> message inside the JWS envelope, because then you end up with a SOAP kind of 
> approach where you’re not really using the outside HTTP constructs to their 
> fullest anymore. 
>  
> In the end, I don’t think this spec is ever going to be perfectly universal, 
> but if it can hit a majority of use cases with a simple and robust solution, 
> I think we’re in good shape.
>  
>  — Justin
>  
> On Feb 28, 2016, at 1:50 PM, Brock Allen  wrote:
>  
> Now that I’m thinking about this, the only thing that comes to mind is a hash 
> of the value included somehow (which I’m sure you’ve already thought of). 
> That’s obviously more complexity and overhead for all scenarios to support 
> this edge case.
>  
> -Brock
>  
> From: Brock Allen [mailto:brockal...@gmail.com] 
> Sent: Sunday, February 28, 2016 4:40 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Ok, missed that – thanks.
>  
> For now in my implementation I’m also ignoring this problem :)
>  
> -Brock
>  
> From: Justin Richer [mailto:jric...@mit.edu] 
> Sent: Sunday, February 28, 2016 4:37 PM
> To: Brock Allen 
> Cc:  
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> In §7.5 we currently have:
>  
>The behavior of repeated query parameters or repeated HTTP headers is
>undefined by this specification.  If a header or query parameter is
>repeated on either the outgoing request from the client or the
>incoming request to the protected resource, that query parameter or
>header name MUST NOT be covered by the hash and signature. [[ Note to
>the WG: is this something we need to cover? ]]
>  
> Which is to say: Yeah, that’s a problem, probably. We either declare this 
> behavior out of scope and say you can’t use this method with that kind of API 
> (or at least those parameters/headers) or we define a mechanism for handling 
> that. I’m in favor of the former, and removing the text from the generation 
> sections that says repeated parameters are processed with no special 
> handling, making them explicitly out of scope throughout.
>  
> I would love to see more feedback from the group about this, especially if 
> someone’s got a clever solution.
>  
>  — Justin
>  
> On Feb 28, 2016, at 1:31 PM, Brock Allen  wrote:
>  
> Given that the client can iterate over the query/headers in any order to 
> generate the concatenated value to hash, I think there’s an issue with query 
> string or header values with repeated keys. I’ll stick with query params for 
> simplicity in my sample.
>  
> If a client signs this concatenated query: “a=1&a=2” then the “p” value in 
> the signed JSON object could be this:
>  
> "p": [["a", "a"], "blah"]
>  
> On the resource server, how do you know which key/value pair to put in which 
> order for verification? Also, given that different server implementations 
> express these incoming parameters in different ways, it seems problematic to 
> be consistent.
>  
> Thanks.
>  
> -Brock
>  
>

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

[Manger, James]

Being able to selectively include or exclude individual query string name=value 
parameters in a signature feels far too dangerous. Always sign them all — with 
the only exception being the signature itself if transmitted as a query string 
parameter.
Unfortunately we do need to selectively include or exclude HTTP headers as they 
are a mix of transport, app-layer, end-to-end, and hop-by-hop items.

Ignoring duplicate query parameter names is a poor design for a fairly generic 
HTTP signing method. My suggestion would be to do a stable sort on parameter 
names. That is, sort the names, but preserve the order of values when a name 
appears multiple times. …hoping that works with almost all frameworks.

--
James Manger

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen
Sent: Monday, 29 February 2016 12:17 PM
To: 'Justin Richer' 
Cc: '' 
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

Yea, I’m cool with just saying “duplicate keys won’t work” for my 
implementation, unless I do some implementation specific thing like sort them 
by value order or some such (but that would have to be on both sides).

-Brock

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, February 28, 2016 8:13 PM
To: Brock Allen mailto:brockal...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:OAuth@ietf.org>>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP 
message inside the JWS envelope, because then you end up with a SOAP kind of 
approach where you’re not really using the outside HTTP constructs to their 
fullest anymore.

In the end, I don’t think this spec is ever going to be perfectly universal, 
but if it can hit a majority of use cases with a simple and robust solution, I 
think we’re in good shape.

 — Justin

On Feb 28, 2016, at 1:50 PM, Brock Allen 
mailto:brockal...@gmail.com>> wrote:

Now that I’m thinking about this, the only thing that comes to mind is a hash 
of the value included somehow (which I’m sure you’ve already thought of). 
That’s obviously more complexity and overhead for all scenarios to support this 
edge case.

-Brock

From: Brock Allen [mailto:brockal...@gmail.com]
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' mailto:jric...@mit.edu>>
Cc: 'mailto:oauth@ietf.org>>' 
mailto:OAuth@ietf.org>>
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys

Ok, missed that – thanks.

For now in my implementation I’m also ignoring this problem :)

-Brock

From: Justin Richer [mailto:jric...@mit.edu]
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen mailto:brockal...@gmail.com>>
Cc: mailto:oauth@ietf.org>> 
mailto:OAuth@ietf.org>>
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

In §7.5 we currently have:


   The behavior of repeated query parameters or repeated HTTP headers is

   undefined by this specification.  If a header or query parameter is

   repeated on either the outgoing request from the client or the

   incoming request to the protected resource, that query parameter or

   header name MUST NOT be covered by the hash and signature. [[ Note to

   the WG: is this something we need to cover? ]]

Which is to say: Yeah, that’s a problem, probably. We either declare this 
behavior out of scope and say you can’t use this method with that kind of API 
(or at least those parameters/headers) or we define a mechanism for handling 
that. I’m in favor of the former, and removing the text from the generation 
sections that says repeated parameters are processed with no special handling, 
making them explicitly out of scope throughout.

I would love to see more feedback from the group about this, especially if 
someone’s got a clever solution.

 — Justin

On Feb 28, 2016, at 1:31 PM, Brock Allen 
mailto:brockal...@gmail.com>> wrote:

Given that the client can iterate over the query/headers in any order to 
generate the concatenated value to hash, I think there’s an issue with query 
string or header values with repeated keys. I’ll stick with query params for 
simplicity in my sample.

If a client signs this concatenated query: “a=1&a=2” then the “p” value in the 
signed JSON object could be this:

"p": [["a", "a"], "blah"]

On the resource server, how do you know which key/value pair to put in which 
order for verification? Also, given that different server implementations 
express these incoming parameters in different ways, it seems problematic to be 
consistent.

Thanks.

-Brock

___
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] HTTP request signing and repeated query/header keys

[Brock Allen]

Yea, I’m cool with just saying “duplicate keys won’t work” for my 
implementation, unless I do some implementation specific thing like sort them 
by value order or some such (but that would have to be on both sides).

 

-Brock

 

From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Sunday, February 28, 2016 8:13 PM
To: Brock Allen 
Cc:  
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

 

Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP 
message inside the JWS envelope, because then you end up with a SOAP kind of 
approach where you’re not really using the outside HTTP constructs to their 
fullest anymore. 

 

In the end, I don’t think this spec is ever going to be perfectly universal, 
but if it can hit a majority of use cases with a simple and robust solution, I 
think we’re in good shape.

 

 — Justin

 

On Feb 28, 2016, at 1:50 PM, Brock Allen mailto:brockal...@gmail.com> > wrote:

 

Now that I’m thinking about this, the only thing that comes to mind is a hash 
of the value included somehow (which I’m sure you’ve already thought of). 
That’s obviously more complexity and overhead for all scenarios to support this 
edge case. 

 

-Brock

 

From: Brock Allen [mailto:brockal...@gmail.com] 
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' mailto:jric...@mit.edu> >
Cc: 'mailto:oauth@ietf.org> >' mailto:OAuth@ietf.org> >
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys

 

Ok, missed that – thanks.

 

For now in my implementation I’m also ignoring this problem :)

 

-Brock

 

From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen mailto:brockal...@gmail.com> >
Cc: mailto:oauth@ietf.org> > mailto:OAuth@ietf.org> >
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

 

In §7.5 we currently have:

 

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

 

Which is to say: Yeah, that’s a problem, probably. We either declare this 
behavior out of scope and say you can’t use this method with that kind of API 
(or at least those parameters/headers) or we define a mechanism for handling 
that. I’m in favor of the former, and removing the text from the generation 
sections that says repeated parameters are processed with no special handling, 
making them explicitly out of scope throughout.

 

I would love to see more feedback from the group about this, especially if 
someone’s got a clever solution.

 

 — Justin

 

On Feb 28, 2016, at 1:31 PM, Brock Allen mailto:brockal...@gmail.com> > wrote:

 

Given that the client can iterate over the query/headers in any order to 
generate the concatenated value to hash, I think there’s an issue with query 
string or header values with repeated keys. I’ll stick with query params for 
simplicity in my sample. 

 

If a client signs this concatenated query: “a=1&a=2” then the “p” value in the 
signed JSON object could be this:

 

"p": [["a", "a"], "blah"]

 

On the resource server, how do you know which key/value pair to put in which 
order for verification? Also, given that different server implementations 
express these incoming parameters in different ways, it seems problematic to be 
consistent.

 

Thanks.

 

-Brock

 

___
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] HTTP request signing and repeated query/header keys

[Justin Richer]

Yeah, that’s the trick — you don’t want to end up replicating the entire HTTP 
message inside the JWS envelope, because then you end up with a SOAP kind of 
approach where you’re not really using the outside HTTP constructs to their 
fullest anymore. 

In the end, I don’t think this spec is ever going to be perfectly universal, 
but if it can hit a majority of use cases with a simple and robust solution, I 
think we’re in good shape.

 — Justin

> On Feb 28, 2016, at 1:50 PM, Brock Allen  wrote:
> 
> Now that I’m thinking about this, the only thing that comes to mind is a hash 
> of the value included somehow (which I’m sure you’ve already thought of). 
> That’s obviously more complexity and overhead for all scenarios to support 
> this edge case.
>  
> -Brock
>  
> From: Brock Allen [mailto:brockal...@gmail.com] 
> Sent: Sunday, February 28, 2016 4:40 PM
> To: 'Justin Richer' 
> Cc: '' 
> Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> Ok, missed that – thanks.
>  
> For now in my implementation I’m also ignoring this problem :)
>  
> -Brock
>  
> From: Justin Richer [mailto:jric...@mit.edu ] 
> Sent: Sunday, February 28, 2016 4:37 PM
> To: Brock Allen mailto:brockal...@gmail.com>>
> Cc: mailto:oauth@ietf.org>>  >
> Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys
>  
> In §7.5 we currently have:
>  
>The behavior of repeated query parameters or repeated HTTP headers is
>undefined by this specification.  If a header or query parameter is
>repeated on either the outgoing request from the client or the
>incoming request to the protected resource, that query parameter or
>header name MUST NOT be covered by the hash and signature. [[ Note to
>the WG: is this something we need to cover? ]]
>  
> Which is to say: Yeah, that’s a problem, probably. We either declare this 
> behavior out of scope and say you can’t use this method with that kind of API 
> (or at least those parameters/headers) or we define a mechanism for handling 
> that. I’m in favor of the former, and removing the text from the generation 
> sections that says repeated parameters are processed with no special 
> handling, making them explicitly out of scope throughout.
>  
> I would love to see more feedback from the group about this, especially if 
> someone’s got a clever solution.
>  
>  — Justin
>  
>> On Feb 28, 2016, at 1:31 PM, Brock Allen > > wrote:
>>  
>> Given that the client can iterate over the query/headers in any order to 
>> generate the concatenated value to hash, I think there’s an issue with query 
>> string or header values with repeated keys. I’ll stick with query params for 
>> simplicity in my sample.
>>  
>> If a client signs this concatenated query: “a=1&a=2” then the “p” value in 
>> the signed JSON object could be this:
>>  
>> "p": [["a", "a"], "blah"]
>>  
>> On the resource server, how do you know which key/value pair to put in which 
>> order for verification? Also, given that different server implementations 
>> express these incoming parameters in different ways, it seems problematic to 
>> be consistent.
>>  
>> Thanks.
>>  
>> -Brock
>>  
>> ___
>> 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] HTTP request signing and repeated query/header keys

[Brock Allen]

Now that I’m thinking about this, the only thing that comes to mind is a hash 
of the value included somehow (which I’m sure you’ve already thought of). 
That’s obviously more complexity and overhead for all scenarios to support this 
edge case. 

 

-Brock

 

From: Brock Allen [mailto:brockal...@gmail.com] 
Sent: Sunday, February 28, 2016 4:40 PM
To: 'Justin Richer' 
Cc: '' 
Subject: RE: [OAUTH-WG] HTTP request signing and repeated query/header keys

 

Ok, missed that – thanks.

 

For now in my implementation I’m also ignoring this problem :)

 

-Brock

 

From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen mailto:brockal...@gmail.com> >
Cc: mailto:oauth@ietf.org> > mailto:OAuth@ietf.org> >
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

 

In §7.5 we currently have:

 

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

 

Which is to say: Yeah, that’s a problem, probably. We either declare this 
behavior out of scope and say you can’t use this method with that kind of API 
(or at least those parameters/headers) or we define a mechanism for handling 
that. I’m in favor of the former, and removing the text from the generation 
sections that says repeated parameters are processed with no special handling, 
making them explicitly out of scope throughout.

 

I would love to see more feedback from the group about this, especially if 
someone’s got a clever solution.

 

 — Justin

 

On Feb 28, 2016, at 1:31 PM, Brock Allen mailto:brockal...@gmail.com> > wrote:

 

Given that the client can iterate over the query/headers in any order to 
generate the concatenated value to hash, I think there’s an issue with query 
string or header values with repeated keys. I’ll stick with query params for 
simplicity in my sample. 

 

If a client signs this concatenated query: “a=1&a=2” then the “p” value in the 
signed JSON object could be this:

 

"p": [["a", "a"], "blah"]

 

On the resource server, how do you know which key/value pair to put in which 
order for verification? Also, given that different server implementations 
express these incoming parameters in different ways, it seems problematic to be 
consistent.

 

Thanks.

 

-Brock

 

___
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] HTTP signing and parameter validation

[Justin Richer]

It’s a bit of both and it’s going to be highly specific to the API being 
protected. The RS should reject a signed request in which a critical parameter 
is unsigned — some implementations of OpenID 2.0 were susceptible to exactly 
this kind of attack a number of years ago. 

We could probably add more guidance text to describe what the API designers 
need to communicate to the client and the RS in terms of what’s expected to be 
covered by the signature. I’m open to suggested text on that point!

 — Justin

> On Feb 28, 2016, at 1:41 PM, Brock Allen  wrote:
> 
> Another question related to HTTP signing.
>  
> It’s not clear to me from the RFC if the resource server should be using the 
> incoming pop token JWS to know what to verify, or if the resource server 
> should have a preconceived notion of what should be sent in the pop token. 
> For example, the query params: should the resource server decode the pop 
> token to see what a client included, or should a resource server always know 
> query params “a, b and c” should always be expected. The same goes for any of 
> the params (method, path, body, etc).
>  
> Thanks.
>  
> -Brock
>  
> ___
> 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] HTTP signing and parameter validation

[Brock Allen]

Another question related to HTTP signing.

 

It's not clear to me from the RFC if the resource server should be using the
incoming pop token JWS to know what to verify, or if the resource server
should have a preconceived notion of what should be sent in the pop token.
For example, the query params: should the resource server decode the pop
token to see what a client included, or should a resource server always know
query params "a, b and c" should always be expected. The same goes for any
of the params (method, path, body, etc).

 

Thanks.

 

-Brock

 

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

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

[Brock Allen]

Ok, missed that – thanks.

 

For now in my implementation I’m also ignoring this problem :)

 

-Brock

 

From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Sunday, February 28, 2016 4:37 PM
To: Brock Allen 
Cc:  
Subject: Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

 

In §7.5 we currently have:

 

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

 

Which is to say: Yeah, that’s a problem, probably. We either declare this 
behavior out of scope and say you can’t use this method with that kind of API 
(or at least those parameters/headers) or we define a mechanism for handling 
that. I’m in favor of the former, and removing the text from the generation 
sections that says repeated parameters are processed with no special handling, 
making them explicitly out of scope throughout.

 

I would love to see more feedback from the group about this, especially if 
someone’s got a clever solution.

 

 — Justin

 

On Feb 28, 2016, at 1:31 PM, Brock Allen mailto:brockal...@gmail.com> > wrote:

 

Given that the client can iterate over the query/headers in any order to 
generate the concatenated value to hash, I think there’s an issue with query 
string or header values with repeated keys. I’ll stick with query params for 
simplicity in my sample. 

 

If a client signs this concatenated query: “a=1&a=2” then the “p” value in the 
signed JSON object could be this:

 

"p": [["a", "a"], "blah"]

 

On the resource server, how do you know which key/value pair to put in which 
order for verification? Also, given that different server implementations 
express these incoming parameters in different ways, it seems problematic to be 
consistent.

 

Thanks.

 

-Brock

 

___
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] HTTP request signing and repeated query/header keys

[Justin Richer]

In §7.5 we currently have:

   The behavior of repeated query parameters or repeated HTTP headers is
   undefined by this specification.  If a header or query parameter is
   repeated on either the outgoing request from the client or the
   incoming request to the protected resource, that query parameter or
   header name MUST NOT be covered by the hash and signature. [[ Note to
   the WG: is this something we need to cover? ]]

Which is to say: Yeah, that’s a problem, probably. We either declare this 
behavior out of scope and say you can’t use this method with that kind of API 
(or at least those parameters/headers) or we define a mechanism for handling 
that. I’m in favor of the former, and removing the text from the generation 
sections that says repeated parameters are processed with no special handling, 
making them explicitly out of scope throughout.

I would love to see more feedback from the group about this, especially if 
someone’s got a clever solution.

 — Justin

> On Feb 28, 2016, at 1:31 PM, Brock Allen  wrote:
> 
> Given that the client can iterate over the query/headers in any order to 
> generate the concatenated value to hash, I think there’s an issue with query 
> string or header values with repeated keys. I’ll stick with query params for 
> simplicity in my sample.
>  
> If a client signs this concatenated query: “a=1&a=2” then the “p” value in 
> the signed JSON object could be this:
>  
> "p": [["a", "a"], "blah"]
>  
> On the resource server, how do you know which key/value pair to put in which 
> order for verification? Also, given that different server implementations 
> express these incoming parameters in different ways, it seems problematic to 
> be consistent.
>  
> Thanks.
>  
> -Brock
>  
> ___
> 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] HTTP signing spec and nonce

[Justin Richer]

I understand how they work, I’ve built exactly that cache before. But I 
askWouldn’t a unique timestamp have the same effect? Currently it’s integer 
seconds but slicing that down further (floating point seconds?) if people 
desired would allow for multiple signed messages in the same second from the 
same client using the otherwise same parameters. 

“Other protocols do it” is not a compelling reason on its own, especially when 
the example of “other protocols” includes WS-* ;)

Seriously though, an optional nonce is easy to add to the draft if there’s 
enough WG support, I’m just hesitant to add more complexity than needed to this.

 — Justin

> On Feb 26, 2016, at 11:06 PM, Dominick Baier  
> wrote:
> 
> The nonce would allow to build a replay cache, the timestamp to trim that 
> cache and reject messages that are too old.
> 
> Similar protocols have a nonce for the above reasons (ws-sec msg security, 
> hawk)...
> 
> — 
> cheers
> Dominick Baier
> 
> On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu 
> ) wrote:
> 
>> I’d be glad to add in a nonce if there’s a compelling reason for it, such as 
>> closing a security attack vector.
>> 
>> What’s the proposed purpose of the nonce? Is it just to add randomness to 
>> the signing base? Or is it to prevent replay at the RS? If the former, the 
>> timestamp should add enough of that and it can be verified to be within a 
>> reasonable window by the RS by comparing it with the time the request was 
>> made. If the latter, the RS is going to have to track previously used nonces 
>> for some amount of time. 
>> 
>> There was a small discussion of just signing an outgoing “Date:” header 
>> instead of the separate timestamp, but the timestamp seemed to be more 
>> robust. I forget the full reasoning though.
>> 
>>  — Justin
>> 
>>> On Feb 26, 2016, at 9:49 AM, Brock Allen >> > wrote:
>>> 
>>> Question about the HTTP signing spec – why is there no nonce (and just a 
>>> timestamp)?
>>>  
>>> TIA
>>>  
>>> -Brock
>>>  
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___ 
>> OAuth mailing list 
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 

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

[OAUTH-WG] HTTP request signing and repeated query/header keys

[Brock Allen]

Given that the client can iterate over the query/headers in any order to
generate the concatenated value to hash, I think there's an issue with query
string or header values with repeated keys. I'll stick with query params for
simplicity in my sample. 

 

If a client signs this concatenated query: "a=1&a=2" then the "p" value in
the signed JSON object could be this:

 

"p": [["a", "a"], "blah"]

 

On the resource server, how do you know which key/value pair to put in which
order for verification? Also, given that different server implementations
express these incoming parameters in different ways, it seems problematic to
be consistent.

 

Thanks.

 

-Brock

 

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

Re: [OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps

[Torsten Lodderstedt]

Hi Thomas,

see comments inline.

Am 19.02.2016 um 12:14 schrieb thomas.ku...@bmw.de:


Hi,

we use the OAuth 2.0 Implicit grant to issue access_tokens to client 
applications such as HTML 5 web apps that have no secure means to 
securely authenticating themselves. Even if the credentials would be 
obfuscated, any user could extract them from the HTTP requests their 
User Agent makes with minimal effort. Since RFC 7009 also talks about 
the usage of CORS to support User-Agent clients, however, I believe 
that these clients should be supported.


So I am having trouble supporting the revocation requirement in RFC 
7009 which states:


   The client also includes its authentication credentials as described
inSection 2.3. of [RFC6749] 
.


Looking at said section in in RFC 6749, it states:

   If the client type is confidential, the client and authorization
   server establish a client authentication method suitable for the
   security requirements of the authorization server.  The authorization
   server MAY accept any form of client authentication meeting its
security requirements.

I am unsure whether “having no form of client authentication” conforms 
to the standard, can you comment on this?




Yes, it does. The client shall use the authentication means it would use 
on the AS's token endpoint as well. And in the same way as public 
clients only identify themself in this use case, they are supposed to do 
the same at the revocation endpoint.


As a side note, I wonder why client authentication for token 
revocations is required anyway, because if a client received a token 
by any legit means, it should always be able to revoke it, regardless 
of authentication. And if an unauthorized client ‘stole’ any type of 
token, revoking it should also be possible, since loss of service for 
the intended client should always be preferred over misusing the token.




Good catch :-) We discussed this when we went through WG review. The 
position we finally decided to take is: what is the worst thing an 
attacker could do on the revocation endpoint? It would revoke tokens in 
order to interupt the respective service for the resource owner. 
Requiring authentication will prevent this.


best regards,
Torsten.


Cheers,

Thomas

*BMW Group*
Thomas Kupka

Customer Data Management, FG-6301

GCDM Identity & Access Management

Bremer Straße 6

80807 München

Postanschrift:

80788 München


Tel: +49-89-382-54083
Mail: thomas.ku...@bmw.de 
Web: http://www.bmwgroup.com/

Bayerische Motoren Werke Aktiengesellschaft
Vorstand: Harald Krüger (Vorsitzender),
Milagros Caiña Carreiro-Andree, Klaus Draeger,
Friedrich Eichiner, Klaus Fröhlich, Ian Robertson,
Peter Schwarzenbauer, Oliver Zipse.
Vorsitzender des Aufsichtsrats: Norbert Reithofer
Sitz und Registergericht: München HRB 42243




___
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] Fixing the Authorization Server Mix-Up: Call for Adoption

[Torsten Lodderstedt]

Hi all,

I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point 
simply because it gives some description of the threats we need to cope 
with. This does not preclude to eventually use 
draft-sakimura-oauth-meta-07 as solution or any other suitable 
mechanisms we find consensus on.


In my opinion, both proposals (iss and meta data) are very similar on a 
conceptual level as they inform the client about the sender of the 
redirect. iss could nicely fit with the upcoming OAuth AS discovery, 
whereas meta is appealing if we want a mechanism, which always keeps the 
client informed where it is considered secure to obtain/use credentials 
(tokens, codes, ...).


Beside this, I would like to emphasize again that code injection/copy 
and paste is not related to idp mix up (even if we discussed both in the 
same workshop). Even traditional OAuth deployments (single AS) are 
potentially affected by the attack. I suggest to split the draft into 
separat documents per threat/mitigation and move forward mitigation 
against code injection as quickly as possible. The current proposal to 
tie the authz code to the client state seems a pretty simple and 
straightforward solution to me.


kind regards,
Torsten.

Am 19.02.2016 um 20:42 schrieb Hannes Tschofenig:

Early February I posted a mail to the list to make progress on the
solution to the OAuth Authorization Server Mix-Up problem discovered
late last year.

Here is my mail about the Authorization Server Mix-Up:
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html

Here is my mail to the list that tries to summarize the discussion
status and asked a few questions:
http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html

Unfortunately, my mail didn't lead to the intended success. While there
was some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that
serves as a starting point for further work in the group*. We have two
documents that provide similar functionality in an attempt to solve the
Authorization Server Mix-Up problem.

So, here is the question for the group. Which document do you want as a
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley

Link:
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
Sascha Preibisch

Link:
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07

Deadline for feedback is March, 4th.

Ciao
Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper
acknowledgement for those who contributed to the work.



___
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