Thanks Ben for the comments.
My responses inline.
-----Original Message-----
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Ben Campbell
Sent: Wednesday, June 10, 2015 6:31 AM
To: The IESG
Cc: draft-ietf-oauth-s...@ietf.org; oauth-cha...@ietf.org;
draft-ietf-oauth-spop.sheph...@ietf.org; oauth@ietf.org;
draft-ietf-oauth-spop...@ietf.org
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (n-sakim...@nri.co.jp)
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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
