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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 09 Jun 2015 14:31:18 -0700

Ben Campbell 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:
----------------------------------------------------------------------

I share Barry's and Alexey's concerns about both allowing "plain" and
defaulting to it.  I have some other comments, which may overlap with the
comments from others:

Substantive:

-- section 1, pre-condition 3: "All OAuth 2.0 native app client-instances
use the same client_id.  Secrets provisioned in client binary
applications cannot be considered confidential."

Is that part of the pre-condition per-se, or a general statement? If the
former, wouldn't a potential mitigation for this attack be to ensure the
precondition doesn't occur?

-- section 1, paragraph after precondition list: "not applicable since
they rely on a per-client instance secret or aper client instance
   redirect URI."

I infer that these are not realistic? If so, it might be useful to say
why. For instance, would one way to mitigate this attack be to make sure
you have per-client secrets and redirect URIs?

-- 4.4.1, last sentence:

Does this advice change if people register new challenge methods?  That
is, what if the client supports "plain", and "foo" but not S256, where
foo is more secure than plain. Can it still use "plain"?

-- 6.2:

Does the ability to register new challenge methods introduce bid-down
attacks? (Assuming that any such method is more secure than "plain", and
that the server might not support it.)

Also, I share Barry's concern that the registration procedures require
quite a bit of special treatment from IANA.

-- 7.4:

This seems to need a normative reference to 6819.

-- 7.5: How does the guidance in section 10.8 of 6479 apply to the
code_verifier? Also, I think the last sentence requires this draft (or
some other) to update 6749.

Editorial:

-- 4.4, 2nd to last paragraph: "The server MUST NOT include the
"code_challenge" value in client requests in a form that other entities
can extract."

should "client requests" be "responses to clients"? (I assume the server
does not send client requests--or do I have the terminology wrong?)

-- 4.4.1, first paragraph:
Please expand PKCE on first mention. (It might help to declare PKCE in
the introduction.)

---

From: "Nat Sakimura" <[email-masked]>
Date: Thu, 11 Jun 2015 18:14:29 +0900

Thanks Ben for the comments.

My responses inline.

> -----Original Message-----
> From: OAuth [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Wednesday, June 10, 2015 6:31 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: [OAUTH-WG] Ben Campbell's No Objection on 
> draft-ietf-oauth-spop-12:
> (with COMMENT)
>
> email
> addresses included in the To and CC lines. (Feel free to cut this 
> introductory
> paragraph, however.)
>
>
> defaulting
> to it.  I have some other comments, which may overlap with the comments

Please see my and John's response to Barry.

> others:
> use
> the same client_id.  Secrets provisioned in client binary applications 
> cannot
> be considered confidential."
>
> former,
> wouldn't a potential mitigation for this attack be to ensure the 
> precondition
> doesn't occur?

It is describing the state we are in, and the state is a prerequisite for 
the attck to succeed.

> they rely
> on a per-client instance secret or aper client instance
>    redirect URI."
>
> why. For
> instance, would one way to mitigate this attack be to make sure you have 
> per-client
> secrets and redirect URIs?
>

Per-client secrets to tens of millions of clients adds serverside headache 
by
requiring persistent serverside client state.
Also, the client development overhead become much larger now that the client
has to be capable of doing dynamic client registration.

These combined, tendency of the developer is to ignore the risk.

PKCE provides a way to mitigate the risk without persistent serverside state 
nor
development overhead of dynamic client registration.

> is, what
> if the client supports "plain", and "foo" but not S256, where foo is more 
> secure
> than plain. Can it still use "plain"?

Client needs to a priori know that the server supports "foo".
Otherwise, it will be a target for algorithm downgrade attack.
If the Client knows that the server supports "foo", then the client must not
accept "plain".

> attacks?
> (Assuming that any such method is more secure than "plain", and that the 
> server
> might not support it.)

Please see the above.

> a bit of special treatment from IANA.

Please see the response to Barry.

> This seems to need a normative reference to 6819.

We can move it from Informative Reference to Normative if referring it in 
SHOULD qualifies it for.

>
> -- 7.5: How does the guidance in section 10.8 of 6749 apply to the 
> code_verifier?

code_verifier will be transmitted in the clear between the app and the 
system browser in the main use case.

> Also, I think the last sentence requires this draft (or some other) to 
> update
> 6749.

Probably yes, but that is a separate issue, I suppose.

> "code_challenge"
> value in client requests in a form that other entities can extract."
>
> does
> not send client requests--or do I have the terminology wrong?)

I think that my bad English.
The intent was:

The server MUST NOT include (the "code_challenge" value in the client 
request) in the code in a form that other entities can extract.

I could restate it as:

When the server embeds the received Code Challange in the Authorization 
Code, it MUST NOT be done in a form that other entities can extract it.

> Please expand PKCE on first mention. (It might help to declare PKCE in the
> introduction.)

Please see my response to Barry. I have proposed even a fuller alternative.

Cheers,

Nat Sakimura
Nomura Research Institute.

>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Nat Sakimura ([email-masked])
Nomura Research Institute

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.