Subject: [OAUTH-WG] Joel Jaeggli's No Objection on draft-ietf-oauth-spop-12: (with COMMENT)

From: "Joel Jaeggli" <[email-masked]>
Date: Tue, 09 Jun 2015 19:40:08 -0700

Joel Jaeggli has entered the following ballot position for
draft-ietf-oauth-spop-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

>From Melinda Shore's OPSdir review:

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These  comments were written with the intent of improving the
operational aspects of the  IETF drafts. Comments that are not
addressed in last call may be included in AD reviews
during the IESG review.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary:

This document is ready, with very minor issues.  It does not appear to
introduce new management/manageability considerations.

This document describes a challenge-response mechanism to protect
against an OAuth authorization code being intercepted by an attacker,
when that authorization code is sent in the clear.  The authorization
code is used to acquire an access token and must be protected.  This
attack (an attacker using an intercepted authz code to acquire an
access token) has been observed in the wild.

We are astonished to learn that OAuth is being run over an
unencrypted channel.

However, given that it is, this is a reasonable defense mechanism.

Questions:

Why is S256 RECOMMENDED and not a MUST?

Nits:

ASCII(STRING) does not appear to be used in the protocol grammar?

Melinda