Message-ID: <54E45F22.8060902@gmx.net>
Date: Wed, 18 Feb 2015 10:45:06 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Nat Sakimura <n-sakimura@nri.co.jp>
References: <54E372C1.8040204@gmx.net>	<20150218131359.19dae026d3e459813e21dc55@nri.co.jp>	<54E450B2.7020409@gmx.net>
 <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
In-Reply-To: <20150218182653.b84a14b8c26c3a506579692e@nri.co.jp>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/wAzByu1QNa0qxrFhST8-CW7zAWM>
Cc: "oauth@ietf.org" <oauth@ietf.org>, naa@google.com
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

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,=20
>=20
> The reason I have put SHOULD there instead of MUST is=20
> that there may be a valid reason not to in a controlled=20
> environment, and it does not interfere the interoperability.
> The deployment may opt to use other control than entropy,=20
> and SHOULD allows it while MUST does not.=20
>=20
> Having said that, if the WG is OK with a MUST there,=20
> I am fine with incorporating the proposed change.=20
>=20
> Cheers,=20
>=20
> Nat
>=20
>=20
> On Wed, 18 Feb 2015 09:43:30 +0100
> Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>=20
>> 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,=20
>>>
>>> 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.=20
>>>
>>> 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.=20
>>>
>>> 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.=20
>>>
>>> Alternatively, in 7.1, after explaining the rationale, we can just
>>> point to 4.1 for the control and implementation guidance.=20
>>>
>>> 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.=20
>>>
>>> Best,=20
>>>
>>> Nat=20
>>>
>>>
>>>
>>> On Tue, 17 Feb 2015 17:56:33 +0100
>>> Hannes Tschofenig <hannes.tschofenig@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
>>>>
>>>
>>>
>>
>=20
>=20


--x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJU5F8iAAoJEGhJURNOOiAtxEoH/2xYdihDiPp+C8uCj6dUxRgl
TNnZzr4pUILGWx53H8Kzb701AgCD8+wKVSHwIekXkwTsddV23l/dQei/sCgyTc2z
pkAjxcHWx7CJbGWoPQBG/4uRj4MYu1p9Zw0bzohRrOri8FiE9awFh+QeVArqCQpH
MjJJZzZpLw/R1hxgsgJSrWzwOj3LMrGzwDeVfvuBXHaQWzK2NFIxUqyDVMOwGNHH
d64db9WNbzn8eJAesEobbvxm6ehUCtsPCirp1uDf5fA2ZNMOMBCLNzo+LotXvvvi
TBItPJXjCevEyTyamwU27XFPHxpOqTWtHF4Qrv4/ijNFhHjGQxMR/0ZOzLazBHU=
=M8/Q
-----END PGP SIGNATURE-----

--x7RnoLXHRhb01ttAiNthqSJQva0GuP2kA--