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

Nat Sakimura sakimura at gmail.com
Thu Sep 26 14:38:20 UTC 2013


This is the agreed upon next round edit for tcse.

---------- Forwarded message ----------
From: Nat Sakimura <sakimura at gmail.com>
Date: 2013/9/9
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-sakimura-oauth-tcse-00.txt
To: Naveen Agarwal <nvnagr at gmail.com>
Cc: John Bradley <ve7jtb at ve7jtb.com>


OK. As a compromise, what about this?

1. Default: Just a random number.
2. Iff the server supports and the client has done a alg
negotiation/registration with the server, client may send hash etc.
instead. In this case, the alg needs to be adhered.

I do not think the run-time negotiation of alg is a good idea as it would
be prone to the downgrade attack.

What do you think?


2013/9/6 Naveen Agarwal <nvnagr at gmail.com>

>
> Breno and I chatted a bit more.
> Adding any hashing algo makes it more work for the client and also we have
> to worry about servers supporting the same hashing algos. We need to then
> define various hashing algorithms, handshake and a way to upgrade in the
> future otherwise issues will keep coming up.
> Given that we don't know of a way requests get compromised (unless the bad
> guy has full platform control) we feel strongly that it is better to keep
> it simple and get rid of any hashing. i.e. Don't do crypto unless we need
> it.
>
>
>
> On Thu, Sep 5, 2013 at 4:25 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
>> It is all about the level of assurance, i suppose.
>> If it is just a random number, then it could be captured on the way and
>> reused.
>> On the other hand, if it is a hash, it will not be.
>>
>> I made it a hash as a striking ground between a random number and more
>> full brown cypto protection.
>> It is easy and short enough for the sender while the attacker would have
>> hard time cracking it on the device within a second or so.
>> Considering we are fighting against attackers right now, just a little
>> more protection than a random number seemed to be a good idea.
>> That's what Brian and other people seemed to have thought as well.
>>
>> What would you think about that?
>>
>>
>>
>>
>> 2013/9/5 Naveen Agarwal <nvnagr at gmail.com>
>>
>>> - mailing list
>>>
>>> Hi Nat, John,
>>>
>>> In Google's implementation we are generating a random string and just
>>> passing that as is (in the request and in the code exchange). There is no
>>> hashing magic etc. I think that may be enough and also takes away the
>>> complain people may have about doing the crypto and crypto analysis. Given
>>> the code is short lived, I don't know if hashing and other complexities
>>> really help. I can see that the current proposal tries helps in the bad guy
>>> intercepts the request itself then it won't have the secret either but not
>>> sure that is a real concern. Thoughts?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Naveen
>>>
>>>
>>> On Tue, Sep 3, 2013 at 11:04 PM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>
>>>> 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 <ve7jtb at ve7jtb.com>
>>>>
>>>>> 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 <phil.hunt at oracle.com> 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
>>>>> phil.hunt at oracle.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-09-02, at 3:44 PM, John Bradley <ve7jtb at ve7jtb.com> 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 <prateek.mishra at oracle.com>
>>>>> 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: <internet-drafts at ietf.org>
>>>>> Date: 2013/7/30
>>>>> Subject: New Version Notification for draft-sakimura-oauth-tcse-00.txt
>>>>> To: Nat Sakimura <sakimura at gmail.com>, John Bradley <
>>>>> jbradley at pingidentity.com>, Naveen Agarwal <naa at google.com>
>>>>>
>>>>>
>>>>>
>>>>> 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 listOAuth at ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>  _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>
>


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



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130926/a4bc59c3/attachment-0001.html>


More information about the Openid-specs-ab mailing list