Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-00.txt

[Nat Sakimura <[e-mail]>]

>From the security PoV, I prefer HMAC as well.
If implementers supports the idea, I would change it to HMAC in the next
rev.
I am also open to changing the param names. As I was writing them, I was
reading JWx specs and got influenced by their short names apparently. I
have no strong preference.

I agree with John that we may want to avoid the name that is a variation on
client secret as it would confuse people.




2013/9/3 John Bradley <[e-mail]>

> Yes Phil it is the same sort of idea that you proposed in 2011.
>
> In this proposal it is limited to preventing an attacker who intercepts
> code from being able to use it even if it knows the client_id and secret of
> the requester as is likely in a native app without dynamic registration
> case.
>
> I think of this as a symmetric proof of possession for code rather than a
> authentication mechanism for the client.  Looking at the old thread I don't
> think that was clear to people.
>
> I also don't think the problem with native apps custom redirect schemes
> being hijacked was apparent to people.
>
> Sending the password itself in the authorization request works assuming
> the attacker can't see the request as is the case in native environments
> currently.
> We changed it to sending a hash of the secret in the request as sending
> passwords in the clear just seems like it will eventually bite us in the
> ass.
>
> I personally think making it a hmac is something people are more likely to
> have the correct code for than a truncated hash, but this is a first draft.
>
> John B.
>
>
> On 2013-09-02, at 4:34 PM, Phil Hunt <[e-mail]> wrote:
>
> FWIW, this was raised before in 2011.
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg06073.html
> http://www.ietf.org/mail-archive/web/oauth/current/msg06079.html
>
> Phil
>
> @independentid
> www.independentid.com
> [e-mail]
>
>
>
>
>
>
>
> On 2013-09-02, at 3:44 PM, John Bradley <[e-mail]> wrote:
>
> AS that don't maintain state would need to encode everything into code.
> I have seen a couple of implementations  do that.  The encoding tends to be
> custom for size reasons.
> Many AS maintain server state for code as it also has grants,
> redirect_uri, client_id, subject etc that need to be tracked.
>
> The point being that the value of "tcsh" not be made available to someone
> who intercepts code on the return.
>
> This method is being used without hashing, and just sending "tcs" however
> that clearly has no resistance if the authorization request can somehow be
> intercepted by an attacker as well.
>
> In order to stick to well understood crypto I argued that "tcsh" be a hmac
> of the client_id using tcs as the key.    I also think calling it a client
> secret is misleading as it is a proof for the code requester not the client.
>
> This is intended as a early draft to document the security problem on iOS
> and one possible mitigation that people are using.
>
> While interoperable OAuth clients like Connect may be a edge case to some,
> it is desirable to have a solution to this that can work with multiple AS
> rather than the client requiring custom code to talk to every AS.
>
> John B.
>
>
> On 2013-09-02, at 2:14 PM, Prateek Mishra <[e-mail]>
> wrote:
>
>  Nat - is there cryptanalysis of the proposed model available anyplace?
>
> Extending protocols by throwing in a smidgen of hashing and a tablespoon
> of encryption is often a bad idea. One of the strengths of *RFC* 6749 is
> that it avoids stuff like that.
>
> What do you mean when you say -
>
> [quote]
> The server MUST NOT include the "tcsh" value in the form that any entity
> but itself can extract it.
> [\quote]
>
> Is this even theoretically achievable without a stateful server that
> maintains a table of [code x tcsh] pairs?
>
> If not, how should the server embed tcsh in "code" and what constructions
> are recommended?
>
> - prateek
>
>  As some of you know, passing the authorization code securely to a native
> app on iOS platform is next to impossible. Malicious application may
> register the same custom scheme as the victim application and hope to
> obtain the code, whose success rate is rather high.
>
>  We have discussed about it during the OpenID Conenct Meeting at IETF 87
> on Sunday, and over a lengthy thread on the OpenID AB/Connect work group
> list. I have captured the discussion in the form of I-D. It is pretty short
> and hopefully easy to read.
>
>  IMHO, although it came up as an issue in OpenID Connect, this is a quite
> useful extension to OAuth 2.0 in general.
>
>  Best,
>
>  Nat Sakimura
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: 2013/7/30
> Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
> To: Nat Sakimura <[e-mail]>, John Bradley <
> [e-mail]>, Naveen Agarwal <[e-mail]>
>
>
>
> A new version of I-D, draft-sakimura-oauth-tcse-00.txt
> has been successfully submitted by Nat Sakimura and posted to the
> IETF repository.
>
> Filename:        draft-sakimura-oauth-tcse
> Revision:        00
> Title:           OAuth Transient Client Secret Extension for Public Clients
> Creation date:   2013-07-29
> Group:           Individual Submission
> Number of pages: 7
> URL:
> http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse
> Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-tcse-00
>
>
> Abstract:
>    The OAuth 2.0 public client utilizing code flow is susceptible to the
>    code interception attack.  This specification describe a mechanism
>    that acts as a control against this threat.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>  _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en