Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

[takamichi saito]

2014/11/14 14:13、John Bradley  のメール：

> This blog post has some good background on why salting is no longer effective 
> against brute force attacks.  
> http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html?m=1

It is basic knowledge as you know.
If I don’t misunderstand the article, the article doesn’t say so.

"That's why it's so important to use a unique salt for each stored password (it 
reduces the return on investment that the new rainbow table will provide)."

> 
> More entropy in the secret is much more important.  
> 
> The code verifier should not be thought of as a password.  It needs to be a 
> high entropy key. 


I can’t understand your point, sorry.
Probably, you may mix some points.
I separate points:

1) against brute-force 
-> it should use iterations.

2) high entropy for the code verifier
-> it should use random generator such like Sandy Bridge's DRNG.
-> or using a longer code_verifier with more uniqueness.

3) against table, including rainbow
-> it should use salt-like string, i.e. adding client_ID 

for example of simple use of hashing:
 hash(1) = sip
 hash(2) = asi
 hash(3) = isd
 hash(4) = tt!
 hash(5) = ou?
  :
  :

 if we apply 1 to hash, we can get “sip" every time.
 Therefore, 
 if someone makes the table for the scheme, we can call SPOP table,
 every person can obtain legitimate code_verifier from any code_challenge.
 That’s my concern.


 



> 
> John B. 
>  
> 
> Sent from my iPhone
> 
> On Nov 13, 2014, at 6:11 PM, Bill Mills  wrote:
> 
>> Adding client ID is no better than simply adding extra random bits, but 256 
>> is a LOT.
>> 
>> Also remember that the server SHOULD:
>> 
>> -only allowing a code to be tried once
>> -at a very minimum should have a severely limited number of tries for a 
>> code
>> -a short time window to use a code
>> 
>> Unless you can brute force 256 bits of (pseudo)random in under a minute or 
>> two the code is dead.  Guess wrong, the code should be dead/trash.
>> 
>> 
>> 
>> On Thursday, November 13, 2014 7:03 PM, takamichi saito 
>>  wrote:
>> 
>> 
>> Sorry for my poor english.
>> 
>> 
>> 2014/11/14 10:45、John Bradley  のメール：
>> 
>> > We have discussed it and that was in fact my original recommendation.  
>> > However I have been convinced that it adds complexity without any real 
>> > improvement in security. 
>> 
>> Really?
>> I think that there is same discussion in storing passwords with salt.
>> It seems to be dangerous to use hashes of fixed-range values.
>> 
>> 
>> > 
>> > The reality is that people don't bother with rainbow tables these days.  
>> > They calculate hashes on the fly faster than they can look them up.  If 
>> > you are generating the hashes to find a collision then having fixed text 
>> > that is known to the attacker won't help.
>> 
>> How quick?
>> Since lifetime of the code_challenge is short, it can works effectively.
>> 
>> >  
>> > 
>> > It is better for people to have more entropy in the code verifier than to 
>> > have a fixed block of text.  I want to avoid people using less bits of 
>> > entropy because they think the hmac is adding something. 
>> 
>> I agree.
>> Then, we should add “client ID” in code_challenge.
>> We can get a few more entropy, since client ID is not fixed value.
>> 
>> 
>> > 
>> > I will come up with some text for the spec, as you are not the only person 
>> > asking that question. 
>> 
>> Thank you.
>> 
>> > 
>> > The other issue is that the term HMAC is scary to developers and we want 
>> > maximum adoption. 
>> 
>> 
>> 
>> > 
>> > John B. 
>> > 
>> > Sent from my iPhone
>> > 
>> >> On Nov 13, 2014, at 3:28 PM, takamichi saito  wrote:
>> >> 
>> >> 
>> >> Hi all,
>> >> 
>> >> I appreciate this idea, simple and powerful to achieve proof of 
>> >> possession.
>> >> But, I have some questions against the scheme.
>> >> Sorry if these ware already discussed.
>> >> 
>> >> I worry about using a hash function in simple way.
>> >> I mean, a simple use of random as code_verifier may cause that malicious 
>> >> client can have any code_verifier and code_challenge.
>> >> All combinations of random and its hash can be obtained, it may not be 
>> >> risk?
>> >> 
>> >> So, we should use:
>> >> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”))
>> >> or
>> >> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID” + 
>> >> “server ID”))
>> >> Where, you know that client ID is client’s unique name.
>> >> 
>> >> 
>> >> Other problem is the following, using Nat’s slide:
>> >> http://www.slideshare.net/nat_sakimura/1112-spoppresso .
>> >> 
>> >> 0.Attacker prepares own code_verifier and code_challenge.
>> >> 1.replage legitimate challenge with malicious code_challenge.
>> >> 5. Attacker can submits own code_verifier.
>> >> 
>> >> It may be out of the draft, I think.
>> >> 
>> >> Best regards,
>> >> 
>> >> 
>> >> ;; takamixhi saito
>> >> 
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> http

Re: [OAUTH-WG] Meeting Minutes

[Brian Campbell]

My question was not really about the status of
draft-bradley-oauth-stateless-client-id but rather about
draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless
client id that Bradley described in his draft.

And draft-ietf-oauth-dyn-reg-management still has text that says, 'The
value of the "client_id" MUST NOT change from the initial registration
response.' which makes it incompatible with the concepts described in
draft-bradley-oauth-stateless-client-id.

On Thu, Nov 13, 2014 at 8:05 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi all,
>
> here is a draft version of the meeting minutes:
> http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth
>
> Thanks to Brian Rosen for taking notes.
>
> Comments are welcome!
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] crosspost.... SASL OAUTH

[Brian Campbell]

Given the state of things, maybe the MAC Token specification
[I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted?

On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills  wrote:

> There's a draft it would be great to get more eyes on in the Kitten WG
>
> draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth
> 
>
> Nearing it's 5th and hopefully final WGLC, so any more eyes and comments
> on it would be welcome.
>
> Thanks,
>
> -bill
>
> ___
> 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] bike-shedding the SPOP into

[Brian Campbell]

In the into, I'd suggest changing,
"The code verifier is created for every authorization request..."
to
"A unique code verifier is created for every authorization request..."
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] crosspost.... SASL OAUTH

[Bill Mills]

Yep, fair enough.  Done. 

 On Friday, November 14, 2014 6:33 AM, Brian Campbell 
 wrote:
   

 Given the state of things, maybe the MAC Token specification 
[I-D.ietf-oauth-v2-http-mac] reference should be changed or omitted?

On Thu, Nov 13, 2014 at 7:01 PM, Bill Mills  wrote:

There's a draft it would be great to get more eyes on in the Kitten WG
draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth

Nearing it's 5th and hopefully final WGLC, so any more eyes and comments on it 
would be welcome.
Thanks,
-bill
___
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] draft-ietf-oauth-spop-04: a way of making code_challenge

[Nat Sakimura]

The code challenge is only one time use and has a short validity period. It
is not something that is going to be stored.

For (1), we could define such transformation, but at a later time, IMHO. We
are getting push back even for sha256 from developers. We need to balance
the benefit and adoption. BTW, what John mentioned as Brute Force attack is
not talking about this. See (3).

For (2), we plan to provide some guidance in the security consideration
section. We know too many developers use a bad source of random.

For (3), as I understand, the salting is to stretch the search space. In
your example, the original search space is very small. In such cases, I
understand the value of stretching. In SPOP's case, we are requiring the
original search space to be rather big. The incremental value from
stretching the space using a known value seems to be minimal, if at all. We
are recommending to use 256bit random. (Since we are SHA256ing, more bits
does not buy us much.) If we stretch the 256 bit random string with a salt
and then hash, the range of the mapping is still 256 bit space. John's
comment on brute force is actually talking about this. Now that the hashing
is so fast that it is faster than table lookup, attacker can effectively
create a table on-the-fly. Given that, prefixing with a known string does
not slow the search.

On Fri Nov 14 2014 at 18:40:08 takamichi saito  wrote:

>
>
>
> 2014/11/14 14:13、John Bradley  のメール：
>
> > This blog post has some good background on why salting is no longer
> effective against brute force attacks.
> > http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html?m=1
>
> It is basic knowledge as you know.
> If I don’t misunderstand the article, the article doesn’t say so.
>
> "That's why it's so important to use a unique salt for each stored
> password (it reduces the return on investment that the new rainbow table
> will provide)."
>
> >
> > More entropy in the secret is much more important.
> >
> > The code verifier should not be thought of as a password.  It needs to
> be a high entropy key.
>
>
> I can’t understand your point, sorry.
> Probably, you may mix some points.
> I separate points:
>
> 1) against brute-force
> -> it should use iterations.
>
> 2) high entropy for the code verifier
> -> it should use random generator such like Sandy Bridge's DRNG.
> -> or using a longer code_verifier with more uniqueness.
>
> 3) against table, including rainbow
> -> it should use salt-like string, i.e. adding client_ID
>
> for example of simple use of hashing:
>  hash(1) = sip
>  hash(2) = asi
>  hash(3) = isd
>  hash(4) = tt!
>  hash(5) = ou?
>   :
>   :
>
>  if we apply 1 to hash, we can get “sip" every time.
>  Therefore,
>  if someone makes the table for the scheme, we can call SPOP table,
>  every person can obtain legitimate code_verifier from any code_challenge.
>  That’s my concern.
>
>
>
>
>
>
> >
> > John B.
> >
> >
> > Sent from my iPhone
> >
> > On Nov 13, 2014, at 6:11 PM, Bill Mills  wrote:
> >
> >> Adding client ID is no better than simply adding extra random bits, but
> 256 is a LOT.
> >>
> >> Also remember that the server SHOULD:
> >>
> >> -only allowing a code to be tried once
> >> -at a very minimum should have a severely limited number of tries
> for a code
> >> -a short time window to use a code
> >>
> >> Unless you can brute force 256 bits of (pseudo)random in under a minute
> or two the code is dead.  Guess wrong, the code should be dead/trash.
> >>
> >>
> >>
> >> On Thursday, November 13, 2014 7:03 PM, takamichi saito <
> sa...@cs.meiji.ac.jp> wrote:
> >>
> >>
> >> Sorry for my poor english.
> >>
> >>
> >> 2014/11/14 10:45、John Bradley  のメール：
> >>
> >> > We have discussed it and that was in fact my original
> recommendation.  However I have been convinced that it adds complexity
> without any real improvement in security.
> >>
> >> Really?
> >> I think that there is same discussion in storing passwords with salt.
> >> It seems to be dangerous to use hashes of fixed-range values.
> >>
> >>
> >> >
> >> > The reality is that people don't bother with rainbow tables these
> days.  They calculate hashes on the fly faster than they can look them up.
> If you are generating the hashes to find a collision then having fixed text
> that is known to the attacker won't help.
> >>
> >> How quick?
> >> Since lifetime of the code_challenge is short, it can works effectively.
> >>
> >> >
> >> >
> >> > It is better for people to have more entropy in the code verifier
> than to have a fixed block of text.  I want to avoid people using less bits
> of entropy because they think the hmac is adding something.
> >>
> >> I agree.
> >> Then, we should add “client ID” in code_challenge.
> >> We can get a few more entropy, since client ID is not fixed value.
> >>
> >>
> >> >
> >> > I will come up with some text for the spec, as you are not the only
> person asking that question.
> >>
> >> Thank you.
> >>
> >> >
> >> > The other issue is that the term HMAC is scary to 

Re: [OAUTH-WG] Adding machine readable errors to SPOP?

[Brian Campbell]

I struggle to see the value in adding more fine grained machine readable
error messages for this.

Do we really want clients to try and negotiate the code_challenge_method
using browser redirects? Especially in light of the fact that we'll likely
also be discouraging AS's from redirecting on some error conditions when
there's no user interaction.

On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:

> As discussed at F2F today at IETF 91 OAuth WG, there has been some request
> to have a more fine grained machine readable error messages.
>
> Currently, it only returns the error defined in RFC6749 and any more
> details is supposed to be returned in error_descripton and error_uri.
>
> So, I came up with the following proposal. If WG agrees, I would put text
> embodying it into the draft-04. Otherwise, I would like to go as is. You
> have to speak out to put it in. (I am sending out -03, which we meant to
> send before submit freeze, without it..)
>
> nError response to authorization request
> lReturns invalid_request with additional error param spop_error with the
> following values:
> ▪S256_unsupported
> ▪none_unsupported
> ▪invalid_code_challenge
>
> Clients MUST NOT accept the downgrade
>
> request through this as it may be a downgrade
>
> attack by a MITM.
> nError response to token request
> lReturns invalid_request with additional error param spop_error with the
> following values:
> ▪invalid _code_verifier
> ▪verifier_challenge_mismatch
> nAuthorization server should return more descriptive information on
> lerror_description
> lerror_uri
>
>
>
>
> ___
> 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] Meeting Minutes

[Justin Richer]

Brian is right, it's still a MUST NOT. We could relax that to a SHOULD NOT to 
allow for the (still largely theoretical) structured client_id construct to 
change over time. The reason it's how it is right now is that most systems use 
the client_id value as a key into things and funny expect it to change, as was 
discussed at several meetings and on the list already. Current implementations 
of this spec don't use structured client_id values. 

But as this is now tagged as experimental, we could also just publish it as is 
and see if anybody actually tried to deploy those two options together.

-- Justin

/ Sent from my phone /


 Original message 
From: Brian Campbell  
Date:11/14/2014  4:26 AM  (GMT-10:00) 
To: Hannes Tschofenig  
Cc: oauth@ietf.org 
Subject: Re: [OAUTH-WG] Meeting Minutes 

My question was not really about the status of 
draft-bradley-oauth-stateless-client-id but rather about 
draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless client 
id that Bradley described in his draft.

And draft-ietf-oauth-dyn-reg-management still has text that says, 'The value of 
the "client_id" MUST NOT change from the initial registration response.' which 
makes it incompatible with the concepts described in 
draft-bradley-oauth-stateless-client-id.

On Thu, Nov 13, 2014 at 8:05 PM, Hannes Tschofenig  
wrote:
Hi all,

here is a draft version of the meeting minutes:
http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth

Thanks to Brian Rosen for taking notes.

Comments are welcome!

Ciao
Hannes & Derek


___
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] Adding machine readable errors to SPOP?

[Nat Sakimura]

I find not much, if any. 


On Fri, Nov 14, 2014 at 06:27 Brian Campbell 
wrote:

> I struggle to see the value in adding more fine grained machine readable
> error messages for this.
>
> Do we really want clients to try and negotiate the code_challenge_method
> using browser redirects? Especially in light of the fact that we'll likely
> also be discouraging AS's from redirecting on some error conditions when
> there's no user interaction.
>
> On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:
>
>> As discussed at F2F today at IETF 91 OAuth WG, there has been some
>> request to have a more fine grained machine readable error messages.
>>
>> Currently, it only returns the error defined in RFC6749 and any more
>> details is supposed to be returned in error_descripton and error_uri.
>>
>> So, I came up with the following proposal. If WG agrees, I would put text
>> embodying it into the draft-04. Otherwise, I would like to go as is. You
>> have to speak out to put it in. (I am sending out -03, which we meant to
>> send before submit freeze, without it..)
>>
>> nError response to authorization request
>> lReturns invalid_request with additional error param spop_error with the
>> following values:
>> ▪S256_unsupported
>> ▪none_unsupported
>> ▪invalid_code_challenge
>>
>> Clients MUST NOT accept the downgrade
>>
>> request through this as it may be a downgrade
>>
>> attack by a MITM.
>> nError response to token request
>> lReturns invalid_request with additional error param spop_error with the
>> following values:
>> ▪invalid _code_verifier
>> ▪verifier_challenge_mismatch
>> nAuthorization server should return more descriptive information on
>> lerror_description
>> lerror_uri
>>
>>
>>
>>
>> ___
>> 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] bike-shedding the SPOP into

[Nat Sakimura]

Sounds good.
On Fri, Nov 14, 2014 at 05:29 Brian Campbell 
wrote:

> In the into, I'd suggest changing,
> "The code verifier is created for every authorization request..."
> to
> "A unique code verifier is created for every authorization request..."
> ___
> 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] Adding machine readable errors to SPOP?

[John Bradley]

 Nat and I discussed it yesterday and I am still personally unconvinced 
that the errors from the authorization endpoint are helpful.   So I am 
personally against adding specific errors for S256_unsupported 

On Nov 14, 2014, at 6:52 AM, Nat Sakimura  wrote:

> I find not much, if any. 
> 
> 
> On Fri, Nov 14, 2014 at 06:27 Brian Campbell  
> wrote:
> I struggle to see the value in adding more fine grained machine readable 
> error messages for this. 
> 
> Do we really want clients to try and negotiate the code_challenge_method 
> using browser redirects? Especially in light of the fact that we'll likely 
> also be discouraging AS's from redirecting on some error conditions when 
> there's no user interaction. 
> 
> On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:
> As discussed at F2F today at IETF 91 OAuth WG, there has been some request to 
> have a more fine grained machine readable error messages. 
> 
> Currently, it only returns the error defined in RFC6749 and any more details 
> is supposed to be returned in error_descripton and error_uri. 
> 
> So, I came up with the following proposal. If WG agrees, I would put text 
> embodying it into the draft-04. Otherwise, I would like to go as is. You have 
> to speak out to put it in. (I am sending out -03, which we meant to send 
> before submit freeze, without it..) 
> 
> nError response to authorization request
> lReturns invalid_request with additional error param spop_error with the 
> following values:
> ▪S256_unsupported
> ▪none_unsupported
> ▪invalid_code_challenge
> Clients MUST NOT accept the downgrade
> request through this as it may be a downgrade
> attack by a MITM.
> nError response to token request
> lReturns invalid_request with additional error param spop_error with the 
> following values:
> ▪invalid _code_verifier
> ▪verifier_challenge_mismatch
> nAuthorization server should return more descriptive information on
> lerror_description
> lerror_uri
> 
> 
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Meeting Minutes

[Brian Campbell]

I'd guess people wouldn't try to deploy those two options together because
it's clearly prohibited.

On Fri, Nov 14, 2014 at 9:47 AM, Justin Richer  wrote:

> Brian is right, it's still a MUST NOT. We could relax that to a SHOULD NOT
> to allow for the (still largely theoretical) structured client_id construct
> to change over time. The reason it's how it is right now is that most
> systems use the client_id value as a key into things and funny expect it to
> change, as was discussed at several meetings and on the list already.
> Current implementations of this spec don't use structured client_id values.
>
> But as this is now tagged as experimental, we could also just publish it
> as is and see if anybody actually tried to deploy those two options
> together.
>
> -- Justin
>
> / Sent from my phone /
>
>
>  Original message 
> From: Brian Campbell 
> Date:11/14/2014 4:26 AM (GMT-10:00)
> To: Hannes Tschofenig 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Meeting Minutes
>
> My question was not really about the status of
> draft-bradley-oauth-stateless-client-id but rather about
> draft-ietf-oauth-dyn-reg-management allowing for the kind of stateless
> client id that Bradley described in his draft.
>
> And draft-ietf-oauth-dyn-reg-management still has text that says, 'The
> value of the "client_id" MUST NOT change from the initial registration
> response.' which makes it incompatible with the concepts described in
> draft-bradley-oauth-stateless-client-id.
>
> On Thu, Nov 13, 2014 at 8:05 PM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi all,
>>
>> here is a draft version of the meeting minutes:
>> http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth
>>
>> Thanks to Brian Rosen for taking notes.
>>
>> Comments are welcome!
>>
>> Ciao
>> Hannes & Derek
>>
>>
>> ___
>> 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] Meeting Minutes

[Mike Jones]

Please change "jwt-req-request" to "jwt-reg-review", per 
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-30#section-10.1.

Other than that, the minutes look good.

Thanks,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, November 13, 2014 5:05 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Meeting Minutes

Hi all,

here is a draft version of the meeting minutes:
http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth

Thanks to Brian Rosen for taking notes.

Comments are welcome!

Ciao
Hannes & Derek

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

Re: [OAUTH-WG] Adding machine readable errors to SPOP?

[Nat Sakimura]

That pretty much was the conclusion we reached. I believe that it was what
the F2F room inclined to. So, for -04, we added a section on error response
but it doesn't have those granular errors.
On Fri, Nov 14, 2014 at 07:07 John Bradley  wrote:

>  Nat and I discussed it yesterday and I am still personally
> unconvinced that the errors from the authorization endpoint are helpful.
> So I am personally against adding specific errors for S256_unsupported
> 
>
> On Nov 14, 2014, at 6:52 AM, Nat Sakimura  wrote:
>
> I find not much, if any. 
>
>
> On Fri, Nov 14, 2014 at 06:27 Brian Campbell 
> wrote:
>
>> I struggle to see the value in adding more fine grained machine readable
>> error messages for this.
>>
>> Do we really want clients to try and negotiate the code_challenge_method
>> using browser redirects? Especially in light of the fact that we'll likely
>> also be discouraging AS's from redirecting on some error conditions when
>> there's no user interaction.
>>
>> On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:
>>
>>> As discussed at F2F today at IETF 91 OAuth WG, there has been some
>>> request to have a more fine grained machine readable error messages.
>>>
>>> Currently, it only returns the error defined in RFC6749 and any more
>>> details is supposed to be returned in error_descripton and error_uri.
>>>
>>> So, I came up with the following proposal. If WG agrees, I would put
>>> text embodying it into the draft-04. Otherwise, I would like to go as is.
>>> You have to speak out to put it in. (I am sending out -03, which we meant
>>> to send before submit freeze, without it..)
>>>
>>> nError response to authorization request
>>> lReturns invalid_request with additional error param spop_error with
>>> the following values:
>>> ▪S256_unsupported
>>> ▪none_unsupported
>>> ▪invalid_code_challenge
>>> Clients MUST NOT accept the downgrade
>>> request through this as it may be a downgrade
>>> attack by a MITM.
>>> nError response to token request
>>> lReturns invalid_request with additional error param spop_error with
>>> the following values:
>>> ▪invalid _code_verifier
>>> ▪verifier_challenge_mismatch
>>> nAuthorization server should return more descriptive information on
>>> lerror_description
>>> lerror_uri
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Adding machine readable errors to SPOP?

[Bill Mills]

I sent some feedback on that section in a different message on list. 

 On Friday, November 14, 2014 12:41 PM, Nat Sakimura  
wrote:
   

 That pretty much was the conclusion we reached. I believe that it was what the 
F2F room inclined to. So, for -04, we added a section on error response but it 
doesn't have those granular errors. 
On Fri, Nov 14, 2014 at 07:07 John Bradley  wrote:

 Nat and I discussed it yesterday and I am still personally unconvinced 
that the errors from the authorization endpoint are helpful.   So I am 
personally against adding specific errors for S256_unsupported 
On Nov 14, 2014, at 6:52 AM, Nat Sakimura  wrote:

I find not much, if any. 


On Fri, Nov 14, 2014 at 06:27 Brian Campbell  wrote:

I struggle to see the value in adding more fine grained machine readable error 
messages for this. 

Do we really want clients to try and negotiate the code_challenge_method using 
browser redirects? Especially in light of the fact that we'll likely also be 
discouraging AS's from redirecting on some error conditions when there's no 
user interaction. 

On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:

As discussed at F2F today at IETF 91 OAuth WG, there has been some request to 
have a more fine grained machine readable error messages. 
Currently, it only returns the error defined in RFC6749 and any more details is 
supposed to be returned in error_descripton and error_uri. 
So, I came up with the following proposal. If WG agrees, I would put text 
embodying it into the draft-04. Otherwise, I would like to go as is. You have 
to speak out to put it in. (I am sending out -03, which we meant to send before 
submit freeze, without it..) 
nErrorresponse to authorization requestlReturns invalid_request withadditional 
error param spop_error with the following values: 
▪S256_unsupported▪none_unsupported▪invalid_code_challengeClientsMUST NOT accept 
the downgrade request throughthis as it may be a downgrade attack by a MITM. 
nErrorresponse to token requestlReturns invalid_request withadditional error 
param spop_error with the following values: ▪invalid 
_code_verifier▪verifier_challenge_mismatchnAuthorizationserver should return 
more descriptive information on lerror_descriptionlerror_uri





___
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] Adding machine readable errors to SPOP?

[Nat Sakimura]

Thanks. I will dig it up.
On Fri, Nov 14, 2014 at 10:54 Bill Mills  wrote:

> I sent some feedback on that section in a different message on list.
>
>
>   On Friday, November 14, 2014 12:41 PM, Nat Sakimura 
> wrote:
>
>
> That pretty much was the conclusion we reached. I believe that it was what
> the F2F room inclined to. So, for -04, we added a section on error response
> but it doesn't have those granular errors.
> On Fri, Nov 14, 2014 at 07:07 John Bradley  wrote:
>
>  Nat and I discussed it yesterday and I am still personally
> unconvinced that the errors from the authorization endpoint are helpful.
> So I am personally against adding specific errors for S256_unsupported
> 
>
> On Nov 14, 2014, at 6:52 AM, Nat Sakimura  wrote:
>
> I find not much, if any. 
>
>
> On Fri, Nov 14, 2014 at 06:27 Brian Campbell 
> wrote:
>
> I struggle to see the value in adding more fine grained machine readable
> error messages for this.
>
> Do we really want clients to try and negotiate the code_challenge_method
> using browser redirects? Especially in light of the fact that we'll likely
> also be discouraging AS's from redirecting on some error conditions when
> there's no user interaction.
>
> On Wed, Nov 12, 2014 at 1:48 PM, Nat Sakimura  wrote:
>
> As discussed at F2F today at IETF 91 OAuth WG, there has been some request
> to have a more fine grained machine readable error messages.
>
> Currently, it only returns the error defined in RFC6749 and any more
> details is supposed to be returned in error_descripton and error_uri.
>
> So, I came up with the following proposal. If WG agrees, I would put text
> embodying it into the draft-04. Otherwise, I would like to go as is. You
> have to speak out to put it in. (I am sending out -03, which we meant to
> send before submit freeze, without it..)
>
> nError response to authorization request
> lReturns invalid_request with additional error param spop_error with the
> following values:
> ▪S256_unsupported
> ▪none_unsupported
> ▪invalid_code_challenge
> Clients MUST NOT accept the downgrade
> request through this as it may be a downgrade
> attack by a MITM.
> nError response to token request
> lReturns invalid_request with additional error param spop_error with the
> following values:
> ▪invalid _code_verifier
> ▪verifier_challenge_mismatch
> nAuthorization server should return more descriptive information on
> lerror_description
> lerror_uri
>
>
>
>
> ___
> 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

[OAUTH-WG] HELP

[Joseph Coley-Wayne Johnson]

-Original Message-
From: "oauth-requ...@ietf.org" 
Sent: ‎11/‎14/‎2014 2:54 PM
To: "oauth@ietf.org" 
Subject: OAuth Digest, Vol 73, Issue 38

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


[The entire original message is not included.]___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] HELP

[Joseph Coley-Wayne Johnson]

-Original Message-
From: "oauth-requ...@ietf.org" 
Sent: ‎11/‎14/‎2014 2:03 PM
To: "oauth@ietf.org" 
Subject: OAuth Digest, Vol 73, Issue 37

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] HELP

[Joseph Coley-Wayne Johnson]

-Original Message-
From: "oauth-requ...@ietf.org" 
Sent: ‎11/‎15/‎2014 12:50 AM
To: "oauth@ietf.org" 
Subject: OAuth Digest, Vol 73, Issue 39

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


[The entire original message is not included.]___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] HELP

[Joseph Coley-Wayne Johnson]

Message Me 6127607882 It's C.-W.

-Original Message-
From: "oauth-requ...@ietf.org" 
Sent: ‎11/‎14/‎2014 11:07 AM
To: "oauth@ietf.org" 
Subject: OAuth Digest, Vol 73, Issue 36

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


[The entire original message is not included.]___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth