[OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hi all,

Nat and I went through the latest version of the Proof Key for Code
Exchange (PKCE) draft and I completed the shepherd writeup.

You can find the writeup here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-spop/shepherdwriteup/

Ciao
Hannes



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Thanks, Naveen!

I will complete my shepherd write-up with this information.

Ciao
Hannes

On 03/10/2015 07:33 PM, Naveen Agarwal wrote:
> 
> I definitely need the IPR confirmation.
> 
> 
> 
> I'm not aware of any IPR related tho this draft.
> 
> 
> On Tue, Feb 17, 2015 at 8:56 AM, Hannes Tschofenig
> mailto:hannes.tschofe...@gmx.net>> wrote:
> 
> Hi Nat, John, Naveen,
> 
> thanks a lot for your work on the document.
> 
> I still need responses to this mail to complete the shepherd writeup:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> 
> I definitely need the IPR confirmation.
> 
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
> 
> As a final remark I still believe that the text regarding the randomness
> is still a bit inconsistent. Here are two examples:
> 
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
> 
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
> enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
> 
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
> 
> It is also not clear why you ask for 32 bytes of entropy in particular.
> 
> Ciao
> Hannes
> 
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed.

[Torsten Lodderstedt]

Hi Hannes,

Am 02.03.2015 um 16:31 schrieb Hannes Tschofenig:

Hi all,

I am trying to finalize my work on the shepherd write-up of
draft-ietf-oauth-spop.

Unfortunately, there are still some outstanding issues:

1. S256 as a mandatory-to-implement code challenge method
(by the Authorization Server)

Currently, S256 is MTI but implementations do not use S256 (yet).
Hence, we have very few (maybe not even a single) implementation
that is in conformance with the specification at the moment.

Does the group see a problem with this choice of MTI
(or lack of conformance)?


As already indicated on the list: The original reason to invent spop was 
to prevent malicous apps, which intercepted the redirect back to the 
legitimate app and that way impersonated the user (see section 1). In my 
opinion, "plain" fullfils this goal. I therefore don't see a need (or 
justification) to make S256 MTI.


The security considerations sections says:

"If the "plain" method is used,
   there is a chance that it will be observed by the attacker on the
   device."

Under which circumstances is an attacker supposed to observe the 
challenge on the device? And if the attacker is able to observe the URLs 
in an embedded or the system browser, isn't this attacker most likely 
capable of observing password input in the same browser? In this case, 
we should rather be concerned regarding the user's password then 
anything else.


kind regards,
Torsten.



2. Naveen Agarwal has not provided his confirmation that any and
all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed.

Without his confirmation I cannot finalize my shepherd write-up.

3. Normative language regarding code verifier randomness

We had a discussion about the language used to describe what
implementations need to provide in terms of randomness of the
code verifier. Here is the discussion thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg14217.html

Ultimately, the issue boiled down to the following sentence and
the use of 'MUST' vs. 'SHOULD':

"the code verifier SHOULD have enough entropy to make it
impractical to guess the value"

It would be good to know whether the group objects using MUST
instead of SHOULD to enhance security.

Ciao
Hannes






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


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

[OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed.

[Hannes Tschofenig]

Hi all,

I am trying to finalize my work on the shepherd write-up of
draft-ietf-oauth-spop.

Unfortunately, there are still some outstanding issues:

1. S256 as a mandatory-to-implement code challenge method
(by the Authorization Server)

Currently, S256 is MTI but implementations do not use S256 (yet).
Hence, we have very few (maybe not even a single) implementation
that is in conformance with the specification at the moment.

Does the group see a problem with this choice of MTI
(or lack of conformance)?

2. Naveen Agarwal has not provided his confirmation that any and
all appropriate IPR disclosures required for full conformance
with the provisions of BCP 78 and BCP 79 have already been filed.

Without his confirmation I cannot finalize my shepherd write-up.

3. Normative language regarding code verifier randomness

We had a discussion about the language used to describe what
implementations need to provide in terms of randomness of the
code verifier. Here is the discussion thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg14217.html

Ultimately, the issue boiled down to the following sentence and
the use of 'MUST' vs. 'SHOULD':

"the code verifier SHOULD have enough entropy to make it
impractical to guess the value"

It would be good to know whether the group objects using MUST
instead of SHOULD to enhance security.

Ciao
Hannes






signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Brian Campbell]

On Wed, Feb 18, 2015 at 7:38 AM, John Bradley  wrote:

>
>
> I don’t remember precisely , but I may be the one responsible for the for
> the 2^(-128) value for code.
>
>
The archives have a more precise memory
http://www.ietf.org/mail-archive/web/oauth/current/msg03844.html ;)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Bill Mills]

I was OK with SHOULD because there's no firm measure of "enough entropy".  
Whether it's SHOULD or MUST is moot without some way to quantify it. 

 On Wednesday, February 18, 2015 1:27 AM, Nat Sakimura 
 wrote:
   

 Hi Hannes, 

The reason I have put SHOULD there instead of MUST is 
that there may be a valid reason not to in a controlled 
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy, 
and SHOULD allows it while MUST does not. 

Having said that, if the WG is OK with a MUST there, 
I am fine with incorporating the proposed change. 

Cheers, 

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes, 
> > 
> > I hereby confirm that I have submit the draft  in full conformance
> > with the  provisions of BCP 78 and BCP 79.
> > 
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well. 
> > 
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1. 
> > 
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
> > 
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk. 
> > 
> > Best, 
> > 
> > Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.  It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

___
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/o

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[John Bradley]

As I stated in my message.  I think for plain having there be a MUST at 256 
bits would be overkill.  

For plain given it is single use like the code is we should probably match it 
to the entropy required for code.

In RFC 6749 we say
The probability of an attacker guessing generated tokens (and other
   credentials not intended for handling by end-users) MUST be less than
   or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

So to be consistent I would make plain "MUST be between 16 and 32 octets”

I don’t remember precisely , but I may be the one responsible for the for the 
2^(-128) value for code.  
That was a bit higher than needed if people can really only use code once.   
However the reality is that not all AS properly revoke code after it is used.
That is really hard in a clustered environment.  (There is more than one large 
one so I am not picking on anyone in particular) 

Knowing that in reality an attacker might be able to make a limited number 
attacks before a code time expires there is a fudge factor in the 128bit code 
to still make it plausibly unguessable even in that case.

The same factor would apply to code_verifier other wise I would say 8 octets 
would be sufficient.

 John B.

> On Feb 18, 2015, at 1:50 AM, Nat Sakimura  wrote:
> 
> Is there anyone who has problems changing it to a MUST? 
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig  > wrote:
> I think that the "controlled environment" is a risky idea. I believe we
> should definitely go for a MUST.
> 
> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> > Hi Hannes,
> >
> > The reason I have put SHOULD there instead of MUST is
> > that there may be a valid reason not to in a controlled
> > environment, and it does not interfere the interoperability.
> > The deployment may opt to use other control than entropy,
> > and SHOULD allows it while MUST does not.
> >
> > Having said that, if the WG is OK with a MUST there,
> > I am fine with incorporating the proposed change.
> >
> > Cheers,
> >
> > Nat
> >
> >
> > On Wed, 18 Feb 2015 09:43:30 +0100
> > Hannes Tschofenig  > > wrote:
> >
> >> Hi Nat,
> >>
> >> thanks for the quick response.
> >>
> >> I was hoping to see a statement like "The code verifier MUST have
> >> enough entropy to make it impractical to guess the value." in the
> >> text rather than the SHOULD. Given all the other statements in the
> >> draft I am not sure what the should actually means. Under what
> >> conditions would an implementer not provide enough entropy to make
> >> guessing impractical?
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> >>> Hi Hannes,
> >>>
> >>> I hereby confirm that I have submit the draft  in full conformance
> >>> with the  provisions of BCP 78 and BCP 79.
> >>>
> >>> Re: Security Consideration (7.1) and section 4.1
> >>>
> >>> The first part of the 7.1 is a non-normative prose explaining that
> >>> the implementers got to make sure that the code verifier is hard to
> >>> guessed or modeled. In a way, this is laying out the basic security
> >>> property requirment on the code verifier.
> >>>
> >>> Then, it goes onto the implementation guideance that one need to
> >>> use a cryptographic random number generator instead of relying on a
> >>> rand() in some language that are  not cryptographically random to
> >>> generate 32-octet sequence. The same text is in 4.1 as well.
> >>>
> >>> We did not copy "code verifier SHOULD have enough entropy to make
> >>> it impractical to guess the value" here because that looked
> >>> needlessly repeating, but if you want, I have no objection in
> >>> adding it to 7.1.
> >>>
> >>> Alternatively, in 7.1, after explaining the rationale, we can just
> >>> point to 4.1 for the control and implementation guidance.
> >>>
> >>> Re: 32-octet
> >>>
> >>> We chose it because we are using SHA256 in generating the code
> >>> challange. Having more entropy does not help us here, while having
> >>> less octets increases the risk.
> >>>
> >>> Best,
> >>>
> >>> Nat
> >>>
> >>>
> >>>
> >>> On Tue, 17 Feb 2015 17:56:33 +0100
> >>> Hannes Tschofenig  >>> > wrote:
> >>>
>  Hi Nat, John, Naveen,
> 
>  thanks a lot for your work on the document.
> 
>  I still need responses to this mail to complete the shepherd
>  writeup:
>  http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html 
>  
> 
>  I definitely need the IPR confirmation.
> 
>  It would also be helpful to have someone who implemented the
>  specification as it currently is. I asked Brian and Thorsten for
>  clarification regarding their statements that they implemented
>  earlier versions of the spec.
> 
>  As a final remark I still believe that the text regarding the
>  randomness is still a bit inconsistent. Here are two ex

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Brian Campbell]

I tend to agree with Torsten here - similar sentiments were (maybe not
well) expressed a few weeks ago:
http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html



On Wed, Feb 18, 2015 at 6:36 AM,  wrote:

>  Hi Nat,
>
> as far as I understand, the length of at least 32 octets is justified for
> S256 only. So limiting the MUST to S256 would be ok (from my perspective).
> I consider a general MUST (which also applies to plain) a to strong
> requirement.
>
> kind regards,
> Torsten.
>
> Am 18.02.2015 10:50, schrieb Nat Sakimura:
>
> Is there anyone who has problems changing it to a MUST?
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig 
> wrote:
>
>> I think that the "controlled environment" is a risky idea. I believe we
>> should definitely go for a MUST.
>>
>> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
>> > Hi Hannes,
>> >
>> > The reason I have put SHOULD there instead of MUST is
>> > that there may be a valid reason not to in a controlled
>> > environment, and it does not interfere the interoperability.
>> > The deployment may opt to use other control than entropy,
>> > and SHOULD allows it while MUST does not.
>> >
>> > Having said that, if the WG is OK with a MUST there,
>> > I am fine with incorporating the proposed change.
>> >
>> > Cheers,
>> >
>> > Nat
>> >
>> >
>> > On Wed, 18 Feb 2015 09:43:30 +0100
>> > Hannes Tschofenig  wrote:
>> >
>> >> Hi Nat,
>> >>
>> >> thanks for the quick response.
>> >>
>> >> I was hoping to see a statement like "The code verifier MUST have
>> >> enough entropy to make it impractical to guess the value." in the
>> >> text rather than the SHOULD. Given all the other statements in the
>> >> draft I am not sure what the should actually means. Under what
>> >> conditions would an implementer not provide enough entropy to make
>> >> guessing impractical?
>> >>
>> >> Ciao
>> >> Hannes
>> >>
>> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>> >>> Hi Hannes,
>> >>>
>> >>> I hereby confirm that I have submit the draft  in full conformance
>> >>> with the  provisions of BCP 78 and BCP 79.
>> >>>
>> >>> Re: Security Consideration (7.1) and section 4.1
>> >>>
>> >>> The first part of the 7.1 is a non-normative prose explaining that
>> >>> the implementers got to make sure that the code verifier is hard to
>> >>> guessed or modeled. In a way, this is laying out the basic security
>> >>> property requirment on the code verifier.
>> >>>
>> >>> Then, it goes onto the implementation guideance that one need to
>> >>> use a cryptographic random number generator instead of relying on a
>> >>> rand() in some language that are  not cryptographically random to
>> >>> generate 32-octet sequence. The same text is in 4.1 as well.
>> >>>
>> >>> We did not copy "code verifier SHOULD have enough entropy to make
>> >>> it impractical to guess the value" here because that looked
>> >>> needlessly repeating, but if you want, I have no objection in
>> >>> adding it to 7.1.
>> >>>
>> >>> Alternatively, in 7.1, after explaining the rationale, we can just
>> >>> point to 4.1 for the control and implementation guidance.
>> >>>
>> >>> Re: 32-octet
>> >>>
>> >>> We chose it because we are using SHA256 in generating the code
>> >>> challange. Having more entropy does not help us here, while having
>> >>> less octets increases the risk.
>> >>>
>> >>> Best,
>> >>>
>> >>> Nat
>> >>>
>> >>>
>> >>>
>> >>> On Tue, 17 Feb 2015 17:56:33 +0100
>> >>> Hannes Tschofenig  wrote:
>> >>>
>>  Hi Nat, John, Naveen,
>> 
>>  thanks a lot for your work on the document.
>> 
>>  I still need responses to this mail to complete the shepherd
>>  writeup:
>>  http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>> 
>>  I definitely need the IPR confirmation.
>> 
>>  It would also be helpful to have someone who implemented the
>>  specification as it currently is. I asked Brian and Thorsten for
>>  clarification regarding their statements that they implemented
>>  earlier versions of the spec.
>> 
>>  As a final remark I still believe that the text regarding the
>>  randomness is still a bit inconsistent. Here are two examples:
>> 
>>  1) In the Security Consideration you write that "The security model
>>  relies on the fact that the code verifier is not learned or
>>  guessed by the attacker.  It is vitally important to adhere to
>>  this principle. "
>> 
>>  2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>>  have enough entropy to make it impractical to guess the value.  It
>>  is RECOMMENDED that the output of a suitable random number
>>  generator be used to create a 32-octet sequence."
>> 
>>  There is clearly a long way from a SHOULD have enough entropy to
>>  the text in the security consideration section where you ask for
>>  32 bytes entropy.
>> 
>>  It is also not clear why you ask for 32 bytes of entropy in
>>  particular.
>> 
>>  Ciao
>>  

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[torsten]

 

Hi Nat, 

as far as I understand, the length of at least 32 octets is justified
for S256 only. So limiting the MUST to S256 would be ok (from my
perspective). I consider a general MUST (which also applies to plain) a
to strong requirement. 

kind regards,
Torsten. 

Am 18.02.2015 10:50, schrieb Nat Sakimura: 

> Is there anyone who has problems changing it to a MUST? 
> On 2015年2月18日(水) at 18:48 Hannes Tschofenig  wrote:
> 
>> I think that the "controlled environment" is a risky idea. I believe we
>> should definitely go for a MUST.
>> 
>> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
>>> Hi Hannes,
>>> 
>>> The reason I have put SHOULD there instead of MUST is
>>> that there may be a valid reason not to in a controlled
>>> environment, and it does not interfere the interoperability.
>>> The deployment may opt to use other control than entropy,
>>> and SHOULD allows it while MUST does not.
>>> 
>>> Having said that, if the WG is OK with a MUST there,
>>> I am fine with incorporating the proposed change.
>>> 
>>> Cheers,
>>> 
>>> Nat
>>> 
>>> 
>>> On Wed, 18 Feb 2015 09:43:30 +0100
>>> Hannes Tschofenig  wrote:
>>> 
 Hi Nat,
 
 thanks for the quick response.
 
 I was hoping to see a statement like "The code verifier MUST have
 enough entropy to make it impractical to guess the value." in the
 text rather than the SHOULD. Given all the other statements in the
 draft I am not sure what the should actually means. Under what
 conditions would an implementer not provide enough entropy to make
 guessing impractical?
 
 Ciao
 Hannes
 
 On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> Hi Hannes,
> 
> I hereby confirm that I have submit the draft in full conformance
> with the provisions of BCP 78 and BCP 79.
> 
> Re: Security Consideration (7.1) and section 4.1
> 
> The first part of the 7.1 is a non-normative prose explaining that
> the implementers got to make sure that the code verifier is hard to
> guessed or modeled. In a way, this is laying out the basic security
> property requirment on the code verifier.
> 
> Then, it goes onto the implementation guideance that one need to
> use a cryptographic random number generator instead of relying on a
> rand() in some language that are not cryptographically random to
> generate 32-octet sequence. The same text is in 4.1 as well.
> 
> We did not copy "code verifier SHOULD have enough entropy to make
> it impractical to guess the value" here because that looked
> needlessly repeating, but if you want, I have no objection in
> adding it to 7.1.
> 
> Alternatively, in 7.1, after explaining the rationale, we can just
> point to 4.1 for the control and implementation guidance.
> 
> Re: 32-octet
> 
> We chose it because we are using SHA256 in generating the code
> challange. Having more entropy does not help us here, while having
> less octets increases the risk.
> 
> Best,
> 
> Nat
> 
> 
> 
> On Tue, 17 Feb 2015 17:56:33 +0100
> Hannes Tschofenig  wrote:
> 
>> Hi Nat, John, Naveen,
>> 
>> thanks a lot for your work on the document.
>> 
>> I still need responses to this mail to complete the shepherd
>> writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html [1]
>> 
>> I definitely need the IPR confirmation.
>> 
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented
>> earlier versions of the spec.
>> 
>> As a final remark I still believe that the text regarding the
>> randomness is still a bit inconsistent. Here are two examples:
>> 
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or
>> guessed by the attacker. It is vitally important to adhere to
>> this principle. "
>> 
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>> have enough entropy to make it impractical to guess the value. It
>> is RECOMMENDED that the output of a suitable random number
>> generator be used to create a 32-octet sequence."
>> 
>> There is clearly a long way from a SHOULD have enough entropy to
>> the text in the security consideration section where you ask for
>> 32 bytes entropy.
>> 
>> It is also not clear why you ask for 32 bytes of entropy in
>> particular.
>> 
>> Ciao
>> Hannes
>> 
> 
> 
 
>>> 
>>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth [2]
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Nat Sakimura]

Is there anyone who has problems changing it to a MUST?
On 2015年2月18日(水) at 18:48 Hannes Tschofenig 
wrote:

> I think that the "controlled environment" is a risky idea. I believe we
> should definitely go for a MUST.
>
> On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> > Hi Hannes,
> >
> > The reason I have put SHOULD there instead of MUST is
> > that there may be a valid reason not to in a controlled
> > environment, and it does not interfere the interoperability.
> > The deployment may opt to use other control than entropy,
> > and SHOULD allows it while MUST does not.
> >
> > Having said that, if the WG is OK with a MUST there,
> > I am fine with incorporating the proposed change.
> >
> > Cheers,
> >
> > Nat
> >
> >
> > On Wed, 18 Feb 2015 09:43:30 +0100
> > Hannes Tschofenig  wrote:
> >
> >> Hi Nat,
> >>
> >> thanks for the quick response.
> >>
> >> I was hoping to see a statement like "The code verifier MUST have
> >> enough entropy to make it impractical to guess the value." in the
> >> text rather than the SHOULD. Given all the other statements in the
> >> draft I am not sure what the should actually means. Under what
> >> conditions would an implementer not provide enough entropy to make
> >> guessing impractical?
> >>
> >> Ciao
> >> Hannes
> >>
> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> >>> Hi Hannes,
> >>>
> >>> I hereby confirm that I have submit the draft  in full conformance
> >>> with the  provisions of BCP 78 and BCP 79.
> >>>
> >>> Re: Security Consideration (7.1) and section 4.1
> >>>
> >>> The first part of the 7.1 is a non-normative prose explaining that
> >>> the implementers got to make sure that the code verifier is hard to
> >>> guessed or modeled. In a way, this is laying out the basic security
> >>> property requirment on the code verifier.
> >>>
> >>> Then, it goes onto the implementation guideance that one need to
> >>> use a cryptographic random number generator instead of relying on a
> >>> rand() in some language that are  not cryptographically random to
> >>> generate 32-octet sequence. The same text is in 4.1 as well.
> >>>
> >>> We did not copy "code verifier SHOULD have enough entropy to make
> >>> it impractical to guess the value" here because that looked
> >>> needlessly repeating, but if you want, I have no objection in
> >>> adding it to 7.1.
> >>>
> >>> Alternatively, in 7.1, after explaining the rationale, we can just
> >>> point to 4.1 for the control and implementation guidance.
> >>>
> >>> Re: 32-octet
> >>>
> >>> We chose it because we are using SHA256 in generating the code
> >>> challange. Having more entropy does not help us here, while having
> >>> less octets increases the risk.
> >>>
> >>> Best,
> >>>
> >>> Nat
> >>>
> >>>
> >>>
> >>> On Tue, 17 Feb 2015 17:56:33 +0100
> >>> Hannes Tschofenig  wrote:
> >>>
>  Hi Nat, John, Naveen,
> 
>  thanks a lot for your work on the document.
> 
>  I still need responses to this mail to complete the shepherd
>  writeup:
>  http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> 
>  I definitely need the IPR confirmation.
> 
>  It would also be helpful to have someone who implemented the
>  specification as it currently is. I asked Brian and Thorsten for
>  clarification regarding their statements that they implemented
>  earlier versions of the spec.
> 
>  As a final remark I still believe that the text regarding the
>  randomness is still a bit inconsistent. Here are two examples:
> 
>  1) In the Security Consideration you write that "The security model
>  relies on the fact that the code verifier is not learned or
>  guessed by the attacker.  It is vitally important to adhere to
>  this principle. "
> 
>  2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>  have enough entropy to make it impractical to guess the value.  It
>  is RECOMMENDED that the output of a suitable random number
>  generator be used to create a 32-octet sequence."
> 
>  There is clearly a long way from a SHOULD have enough entropy to
>  the text in the security consideration section where you ask for
>  32 bytes entropy.
> 
>  It is also not clear why you ask for 32 bytes of entropy in
>  particular.
> 
>  Ciao
>  Hannes
> 
> >>>
> >>>
> >>
> >
> >
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

I think that the "controlled environment" is a risky idea. I believe we
should definitely go for a MUST.

On 02/18/2015 10:26 AM, Nat Sakimura wrote:
> Hi Hannes, 
> 
> The reason I have put SHOULD there instead of MUST is 
> that there may be a valid reason not to in a controlled 
> environment, and it does not interfere the interoperability.
> The deployment may opt to use other control than entropy, 
> and SHOULD allows it while MUST does not. 
> 
> Having said that, if the WG is OK with a MUST there, 
> I am fine with incorporating the proposed change. 
> 
> Cheers, 
> 
> Nat
> 
> 
> On Wed, 18 Feb 2015 09:43:30 +0100
> Hannes Tschofenig  wrote:
> 
>> Hi Nat,
>>
>> thanks for the quick response.
>>
>> I was hoping to see a statement like "The code verifier MUST have
>> enough entropy to make it impractical to guess the value." in the
>> text rather than the SHOULD. Given all the other statements in the
>> draft I am not sure what the should actually means. Under what
>> conditions would an implementer not provide enough entropy to make
>> guessing impractical?
>>
>> Ciao
>> Hannes
>>
>> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
>>> Hi Hannes, 
>>>
>>> I hereby confirm that I have submit the draft  in full conformance
>>> with the  provisions of BCP 78 and BCP 79.
>>>
>>> Re: Security Consideration (7.1) and section 4.1
>>>
>>> The first part of the 7.1 is a non-normative prose explaining that
>>> the implementers got to make sure that the code verifier is hard to
>>> guessed or modeled. In a way, this is laying out the basic security
>>> property requirment on the code verifier. 
>>>
>>> Then, it goes onto the implementation guideance that one need to
>>> use a cryptographic random number generator instead of relying on a
>>> rand() in some language that are  not cryptographically random to
>>> generate 32-octet sequence. The same text is in 4.1 as well. 
>>>
>>> We did not copy "code verifier SHOULD have enough entropy to make
>>> it impractical to guess the value" here because that looked
>>> needlessly repeating, but if you want, I have no objection in
>>> adding it to 7.1. 
>>>
>>> Alternatively, in 7.1, after explaining the rationale, we can just
>>> point to 4.1 for the control and implementation guidance. 
>>>
>>> Re: 32-octet
>>>
>>> We chose it because we are using SHA256 in generating the code
>>> challange. Having more entropy does not help us here, while having
>>> less octets increases the risk. 
>>>
>>> Best, 
>>>
>>> Nat 
>>>
>>>
>>>
>>> On Tue, 17 Feb 2015 17:56:33 +0100
>>> Hannes Tschofenig  wrote:
>>>
 Hi Nat, John, Naveen,

 thanks a lot for your work on the document.

 I still need responses to this mail to complete the shepherd
 writeup:
 http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html

 I definitely need the IPR confirmation.

 It would also be helpful to have someone who implemented the
 specification as it currently is. I asked Brian and Thorsten for
 clarification regarding their statements that they implemented
 earlier versions of the spec.

 As a final remark I still believe that the text regarding the
 randomness is still a bit inconsistent. Here are two examples:

 1) In the Security Consideration you write that "The security model
 relies on the fact that the code verifier is not learned or
 guessed by the attacker.  It is vitally important to adhere to
 this principle. "

 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
 have enough entropy to make it impractical to guess the value.  It
 is RECOMMENDED that the output of a suitable random number
 generator be used to create a 32-octet sequence."

 There is clearly a long way from a SHOULD have enough entropy to
 the text in the security consideration section where you ask for
 32 bytes entropy.

 It is also not clear why you ask for 32 bytes of entropy in
 particular.

 Ciao
 Hannes

>>>
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Nat Sakimura]

Hi Hannes, 

The reason I have put SHOULD there instead of MUST is 
that there may be a valid reason not to in a controlled 
environment, and it does not interfere the interoperability.
The deployment may opt to use other control than entropy, 
and SHOULD allows it while MUST does not. 

Having said that, if the WG is OK with a MUST there, 
I am fine with incorporating the proposed change. 

Cheers, 

Nat


On Wed, 18 Feb 2015 09:43:30 +0100
Hannes Tschofenig  wrote:

> Hi Nat,
> 
> thanks for the quick response.
> 
> I was hoping to see a statement like "The code verifier MUST have
> enough entropy to make it impractical to guess the value." in the
> text rather than the SHOULD. Given all the other statements in the
> draft I am not sure what the should actually means. Under what
> conditions would an implementer not provide enough entropy to make
> guessing impractical?
> 
> Ciao
> Hannes
> 
> On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> > Hi Hannes, 
> > 
> > I hereby confirm that I have submit the draft  in full conformance
> > with the  provisions of BCP 78 and BCP 79.
> > 
> > Re: Security Consideration (7.1) and section 4.1
> > 
> > The first part of the 7.1 is a non-normative prose explaining that
> > the implementers got to make sure that the code verifier is hard to
> > guessed or modeled. In a way, this is laying out the basic security
> > property requirment on the code verifier. 
> > 
> > Then, it goes onto the implementation guideance that one need to
> > use a cryptographic random number generator instead of relying on a
> > rand() in some language that are  not cryptographically random to
> > generate 32-octet sequence. The same text is in 4.1 as well. 
> > 
> > We did not copy "code verifier SHOULD have enough entropy to make
> > it impractical to guess the value" here because that looked
> > needlessly repeating, but if you want, I have no objection in
> > adding it to 7.1. 
> > 
> > Alternatively, in 7.1, after explaining the rationale, we can just
> > point to 4.1 for the control and implementation guidance. 
> > 
> > Re: 32-octet
> > 
> > We chose it because we are using SHA256 in generating the code
> > challange. Having more entropy does not help us here, while having
> > less octets increases the risk. 
> > 
> > Best, 
> > 
> > Nat 
> > 
> > 
> > 
> > On Tue, 17 Feb 2015 17:56:33 +0100
> > Hannes Tschofenig  wrote:
> > 
> >> Hi Nat, John, Naveen,
> >>
> >> thanks a lot for your work on the document.
> >>
> >> I still need responses to this mail to complete the shepherd
> >> writeup:
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> >>
> >> I definitely need the IPR confirmation.
> >>
> >> It would also be helpful to have someone who implemented the
> >> specification as it currently is. I asked Brian and Thorsten for
> >> clarification regarding their statements that they implemented
> >> earlier versions of the spec.
> >>
> >> As a final remark I still believe that the text regarding the
> >> randomness is still a bit inconsistent. Here are two examples:
> >>
> >> 1) In the Security Consideration you write that "The security model
> >> relies on the fact that the code verifier is not learned or
> >> guessed by the attacker.  It is vitally important to adhere to
> >> this principle. "
> >>
> >> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> >> have enough entropy to make it impractical to guess the value.  It
> >> is RECOMMENDED that the output of a suitable random number
> >> generator be used to create a 32-octet sequence."
> >>
> >> There is clearly a long way from a SHOULD have enough entropy to
> >> the text in the security consideration section where you ask for
> >> 32 bytes entropy.
> >>
> >> It is also not clear why you ask for 32 bytes of entropy in
> >> particular.
> >>
> >> Ciao
> >> Hannes
> >>
> > 
> > 
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

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

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hi John,

I am fine with the plain vs. SHA256 concept and I understand the
reasoning behind the two. Having the same for both types is also OK for me.

My question about the 32 bytes entropy was based on curiosity. SHA256 is
a function that takes an arbitrary length input and produces an output
with 256 bits. The 256bit output length does not mean that you have put
give it 256bits randomness as input.

If the group thinks that this is a reasonable value (and not too big)
then I am fine with it as well.

Ciao
Hannes

On 02/18/2015 05:42 AM, John Bradley wrote:
> We have discussed on the list making allowing the entropy for plain to be 
> smaller.
> 
> 32bytes was selected as a good value for S256.  
> 
> The reason for S256 vs plain is that you are assuming an attacker is going to 
> intercept the request, and thus you want to have enough entropy to prevent 
> offline brute force.
> 
> For plain you are assuming that the attacker can't intercept the request, and 
> if they do more entropy won't help you.
> 
> In the plain case you are only protecting against a on line guess for a 
> single use token.   That could safely be much lower entropy as it is not 
> protecting against off-line brute force.
> 128bits would be more than enough in that case.   I left it as 256bits for 
> both to not introduce more options and not confuse people about why plain 
> needs less entropy than S256.
> 
> What is the WG feeling should we recommend different minimum values for each 
> of the transforms?
> 
> John B.
> 
>> On Feb 17, 2015, at 8:56 AM, Hannes Tschofenig  
>> wrote:
>>
>> Hi Nat, John, Naveen,
>>
>> thanks a lot for your work on the document.
>>
>> I still need responses to this mail to complete the shepherd writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>
>> I definitely need the IPR confirmation.
>>
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented earlier
>> versions of the spec.
>>
>> As a final remark I still believe that the text regarding the randomness
>> is still a bit inconsistent. Here are two examples:
>>
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or guessed by
>> the attacker.  It is vitally important to adhere to this principle. "
>>
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
>> enough entropy to make it impractical to guess the value.  It is
>> RECOMMENDED that the output of a suitable random number generator be
>> used to create a 32-octet sequence."
>>
>> There is clearly a long way from a SHOULD have enough entropy to the
>> text in the security consideration section where you ask for 32 bytes
>> entropy.
>>
>> It is also not clear why you ask for 32 bytes of entropy in particular.
>>
>> Ciao
>> Hannes
>>
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hi Nat,

thanks for the quick response.

I was hoping to see a statement like "The code verifier MUST have enough
entropy to make it impractical to guess the value." in the text rather
than the SHOULD. Given all the other statements in the draft I am not
sure what the should actually means. Under what conditions would an
implementer not provide enough entropy to make guessing impractical?

Ciao
Hannes

On 02/18/2015 05:13 AM, Nat Sakimura wrote:
> Hi Hannes, 
> 
> I hereby confirm that I have submit the draft  in full conformance with the  
> provisions of BCP 78 and BCP 79.
> 
> Re: Security Consideration (7.1) and section 4.1
> 
> The first part of the 7.1 is a non-normative prose explaining that the 
> implementers got to make sure that the code verifier is hard to guessed or 
> modeled. In a way, this is laying out the basic security property requirment 
> on the code verifier. 
> 
> Then, it goes onto the implementation guideance that one need to use a 
> cryptographic random number generator instead of relying on a rand() in some 
> language that are  not cryptographically random to generate 32-octet 
> sequence. The same text is in 4.1 as well. 
> 
> We did not copy "code verifier SHOULD have enough entropy to make it 
> impractical to guess the value" here because that looked needlessly 
> repeating, but if you want, I have no objection in adding it to 7.1. 
> 
> Alternatively, in 7.1, after explaining the rationale, we can just point to 
> 4.1 for the control and implementation guidance. 
> 
> Re: 32-octet
> 
> We chose it because we are using SHA256 in generating the code challange.
> Having more entropy does not help us here, while having less octets increases 
> the risk. 
> 
> Best, 
> 
> Nat 
> 
> 
> 
> On Tue, 17 Feb 2015 17:56:33 +0100
> Hannes Tschofenig  wrote:
> 
>> Hi Nat, John, Naveen,
>>
>> thanks a lot for your work on the document.
>>
>> I still need responses to this mail to complete the shepherd writeup:
>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
>>
>> I definitely need the IPR confirmation.
>>
>> It would also be helpful to have someone who implemented the
>> specification as it currently is. I asked Brian and Thorsten for
>> clarification regarding their statements that they implemented earlier
>> versions of the spec.
>>
>> As a final remark I still believe that the text regarding the
>> randomness is still a bit inconsistent. Here are two examples:
>>
>> 1) In the Security Consideration you write that "The security model
>> relies on the fact that the code verifier is not learned or guessed by
>> the attacker.  It is vitally important to adhere to this principle. "
>>
>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
>> have enough entropy to make it impractical to guess the value.  It is
>> RECOMMENDED that the output of a suitable random number generator be
>> used to create a 32-octet sequence."
>>
>> There is clearly a long way from a SHOULD have enough entropy to the
>> text in the security consideration section where you ask for 32 bytes
>> entropy.
>>
>> It is also not clear why you ask for 32 bytes of entropy in
>> particular.
>>
>> Ciao
>> Hannes
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[John Bradley]

We have discussed on the list making allowing the entropy for plain to be 
smaller.

32bytes was selected as a good value for S256.  

The reason for S256 vs plain is that you are assuming an attacker is going to 
intercept the request, and thus you want to have enough entropy to prevent 
offline brute force.

For plain you are assuming that the attacker can't intercept the request, and 
if they do more entropy won't help you.

In the plain case you are only protecting against a on line guess for a single 
use token.   That could safely be much lower entropy as it is not protecting 
against off-line brute force.
128bits would be more than enough in that case.   I left it as 256bits for both 
to not introduce more options and not confuse people about why plain needs less 
entropy than S256.

What is the WG feeling should we recommend different minimum values for each of 
the transforms?

John B.

> On Feb 17, 2015, at 8:56 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Nat, John, Naveen,
> 
> thanks a lot for your work on the document.
> 
> I still need responses to this mail to complete the shepherd writeup:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> 
> I definitely need the IPR confirmation.
> 
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
> 
> As a final remark I still believe that the text regarding the randomness
> is still a bit inconsistent. Here are two examples:
> 
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
> 
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
> enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
> 
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
> 
> It is also not clear why you ask for 32 bytes of entropy in particular.
> 
> Ciao
> Hannes
> 



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

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[John Bradley]

I hereby confirm that I have submit the draft  in full conformance with the  
provisions of BCP 78 and BCP 79.



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

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

[Nat Sakimura]

Hi Hannes, 

I hereby confirm that I have submit the draft  in full conformance with the  
provisions of BCP 78 and BCP 79.

Re: Security Consideration (7.1) and section 4.1

The first part of the 7.1 is a non-normative prose explaining that the 
implementers got to make sure that the code verifier is hard to guessed or 
modeled. In a way, this is laying out the basic security property requirment on 
the code verifier. 

Then, it goes onto the implementation guideance that one need to use a 
cryptographic random number generator instead of relying on a rand() in some 
language that are  not cryptographically random to generate 32-octet sequence. 
The same text is in 4.1 as well. 

We did not copy "code verifier SHOULD have enough entropy to make it 
impractical to guess the value" here because that looked needlessly repeating, 
but if you want, I have no objection in adding it to 7.1. 

Alternatively, in 7.1, after explaining the rationale, we can just point to 4.1 
for the control and implementation guidance. 

Re: 32-octet

We chose it because we are using SHA256 in generating the code challange.
Having more entropy does not help us here, while having less octets increases 
the risk. 

Best, 

Nat 



On Tue, 17 Feb 2015 17:56:33 +0100
Hannes Tschofenig  wrote:

> Hi Nat, John, Naveen,
> 
> thanks a lot for your work on the document.
> 
> I still need responses to this mail to complete the shepherd writeup:
> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html
> 
> I definitely need the IPR confirmation.
> 
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
> 
> As a final remark I still believe that the text regarding the
> randomness is still a bit inconsistent. Here are two examples:
> 
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
> 
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD
> have enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
> 
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
> 
> It is also not clear why you ask for 32 bytes of entropy in
> particular.
> 
> Ciao
> Hannes
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

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

[OAUTH-WG] draft-ietf-oauth-spop-10

[Hannes Tschofenig]

Hi Nat, John, Naveen,

thanks a lot for your work on the document.

I still need responses to this mail to complete the shepherd writeup:
http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html

I definitely need the IPR confirmation.

It would also be helpful to have someone who implemented the
specification as it currently is. I asked Brian and Thorsten for
clarification regarding their statements that they implemented earlier
versions of the spec.

As a final remark I still believe that the text regarding the randomness
is still a bit inconsistent. Here are two examples:

1) In the Security Consideration you write that "The security model
relies on the fact that the code verifier is not learned or guessed by
the attacker.  It is vitally important to adhere to this principle. "

2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
enough entropy to make it impractical to guess the value.  It is
RECOMMENDED that the output of a suitable random number generator be
used to create a 32-octet sequence."

There is clearly a long way from a SHOULD have enough entropy to the
text in the security consideration section where you ask for 32 bytes
entropy.

It is also not clear why you ask for 32 bytes of entropy in particular.

Ciao
Hannes



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth