Message-ID: <54E450B2.7020409@gmx.net>
Date: Wed, 18 Feb 2015 09:43:30 +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>
In-Reply-To: <20150218131359.19dae026d3e459813e21dc55@nri.co.jp>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/9Fjgj9ZLt-GX8r7vZYcHQfxebLs>
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)
--SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

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
>=20
> I hereby confirm that I have submit the draft  in full conformance with=
 the  provisions of BCP 78 and BCP 79.
>=20
> Re: Security Consideration (7.1) and section 4.1
>=20
> 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 o=
r modeled. In a way, this is laying out the basic security property requi=
rment on the code verifier.=20
>=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 s=
ome language that are  not cryptographically random to generate 32-octet =
sequence. The same text is in 4.1 as well.=20
>=20
> We did not copy "code verifier SHOULD have enough entropy to make it im=
practical to guess the value" here because that looked needlessly repeati=
ng, but if you want, I have no objection in adding it to 7.1.=20
>=20
> Alternatively, in 7.1, after explaining the rationale, we can just poin=
t to 4.1 for the control and implementation guidance.=20
>=20
> Re: 32-octet
>=20
> We chose it because we are using SHA256 in generating the code challang=
e.
> Having more entropy does not help us here, while having less octets inc=
reases the risk.=20
>=20
> Best,=20
>=20
> Nat=20
>=20
>=20
>=20
> On Tue, 17 Feb 2015 17:56:33 +0100
> Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>=20
>> 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


--SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl
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

iQEcBAEBCgAGBQJU5FCyAAoJEGhJURNOOiAtRv8IAJM8woXukiEcvyTe3180pPHE
Ti9vh7GfexmAhWsMW+9Y3YzXTPIKUhZHHOdnncBVS5IgyS/F1/XSfi34PmHfrmKS
zlU2JpRYJou3fKBICHNqxv4wKgtCWvkwrwzENUr+GzV19fpjMxHrnMR6fUTB2hn4
Al0risEdi35dikWsE/cB3jgql0mlh4Qg8UCjrzGpW8X0rgbiY8ahVO89MhbSmLy1
Sy7IH64aiMLxYKrpDaqtHE71bCqqGUM8l0OiQQbwALJDWObGqDgsb6uZYDtmvO6V
qC+hvr1SasMV8caermsT9C+hgi0yxKyxueIpm5LcCIJY1vjrwDPf5X1nuYt68Qo=
=Y40K
-----END PGP SIGNATURE-----

--SSFpfMuQHn3oUEBCG22MQrCu76f2eO6sl--