Last Call Review of draft-ietf-oauth-spop-11
review-ietf-oauth-spop-11-secdir-lc-laurie-2015-06-10-00

Request Review of draft-ietf-oauth-spop
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-09
Requested 2015-05-21
Authors Nat Sakimura, John Bradley, Naveen Agarwal
Draft last updated 2015-06-10
Completed reviews Genart Last Call review of -11 by Alexey Melnikov (diff)
Secdir Last Call review of -11 by Ben Laurie (diff)
Opsdir Last Call review of -11 by Melinda Shore (diff)
Assignment Reviewer Ben Laurie
State Completed
Review review-ietf-oauth-spop-11-secdir-lc-laurie-2015-06-10
Reviewed rev. 11 (document currently at 15)
Review result Has Issues
Review completed: 2015-06-10

Review
review-ietf-oauth-spop-11-secdir-lc-laurie-2015-06-10

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Status: ready with issues.

It is disappointing that such a protocol must be introduced to work
around security deficiencies in application platforms - have these
security issues been reported to vendors?

Anyway, issues:

1. Security consideration says: "Concatenating a publicly known value
to a code_challenge
   (with 256 bits of entropy) and then hashing it with SHA256 would
   actually reduce the entropy in the resulting code_verifier making it
   easier for an attacker to brute force." This makes no sense. A
brute force attack would still require iteration of 2^256 inputs. How
is that easier?

2. The introduction says "No client secret is used (since public
clients cannot keep their secrets confidential.)". However, a client
secret is used. I suspect I know what is intended, but this should be
clarified.