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

["Nat Sakimura" <[e-mail]>]

Thanks Ben for the comments.

My responses inline.

> -----Original Message-----
> From: OAuth [mailto:[e-mail]] On Behalf Of Ben Campbell
> Sent: Wednesday, June 10, 2015 6:31 AM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: [OAUTH-WG] Ben Campbell's No Objection on 
> draft-ietf-oauth-spop-12:
> (with COMMENT)
>
> 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

Please see my and John's response to Barry.

> 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?

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

>
> -- 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?
>

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.

> -- 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"?

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".

>
> -- 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.)

Please see the above.

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

Please see the response to Barry.

>
> -- 7.4:
>
> 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.

>
> 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?)

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.


>
> -- 4.4.1, first paragraph:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



-- 
Nat Sakimura ([e-mail])
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.