Re: [OAUTH-WG] Signatures, Why?

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Fri, 12 March 2010 21:15 UTC

Return-Path: <igor.faynberg@alcatel-lucent.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4B03A6989 for <oauth@core3.amsl.com>; Fri, 12 Mar 2010 13:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1SL-7Ivaa7n for <oauth@core3.amsl.com>; Fri, 12 Mar 2010 13:14:58 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 426283A68D5 for <oauth@ietf.org>; Fri, 12 Mar 2010 13:14:57 -0800 (PST)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o2CLF2rL006759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Mar 2010 15:15:02 -0600 (CST)
Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o2CLF2WG018819; Fri, 12 Mar 2010 15:15:02 -0600 (CST)
Message-ID: <4B9AAED5.9060502@alcatel-lucent.com>
Date: Fri, 12 Mar 2010 16:15:01 -0500
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Dick Hardt <dick.hardt@gmail.com>
References: <d37b4b431003041200n1fc6cc5au83194aca28763b0d@mail.gmail.com> <4B99B2DD.3000405@stpeter.im> <4B99D783.1090905@lodderstedt.net> <B1DB9DB1-74F9-4E6C-83C3-22DB27648B92@xmlgrrl.com> <D507E0CF-2AC8-4989-A0B4-64E04E5334C4@gmail.com> <4B9A984F.9080401@alcatel-lucent.com> <D66E227D-3386-4EB7-B8A4-8DC96E310AB8@gmail.com>
In-Reply-To: <D66E227D-3386-4EB7-B8A4-8DC96E310AB8@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Signatures, Why?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2010 21:15:00 -0000

Yes, the third-party-based non-repudiation with symmetric cryptography 
is a complex thing.  The way I would apply it to the Client request  is 
as follows:

1)  The Client sends the token request, R, to the Third Party (and, you 
are right, the Third Party must know who the client is, and so  one 
shared secret is needed right there, given that there is no public key 
cryptography; so this secret is used to sign R);

2) The Third Party hashes the request using a secret that *only the 
Third Party knows* and sends this quantity, Q, back to the Client;

3) Now the Client sends to the server (R, Q).

The server could now go back to the Third Party and ask if Q is indeed 
what it had given. To eliminate this step, the Third Party can either 
encrypt (R, Q) with the secret shared with the server, or sign it with 
its secret, and return the resulting quantity, Q', to the Client.

The requirement her is that the Third Party must be trusted  by both the 
Client and the Server and--in addition--it must be trusted by the court, 
which could verify with the Third Party that it indeed has computed Q. 
(Verification, I understand, should be done involving a real person 
because, in general, escrowing signature keys makes signatures invalid.)

Igor

Dick Hardt wrote:
> Hi Igor
>
> Thanks for explanation. Unfortunately I am more  confused. How does the third party know who the Client is?
>
> I don't understand how an Access Token plus a signing secret gives any more assurance than an Access Token unless I get the Access Token from a different place than the signing secret. Is that what I am missing?
>
> -- Dick
>
> On 2010-03-12, at 11:38 AM, Igor Faynberg wrote:
>
>   
>> Dick,
>>
>> The trick here is THE THIRD PARTY (referred to in the last words of Eve's message), who is effectively a witness to the transaction. (This works pretty much like when you want to switch your telephone provider. You would be transferred to the third party to confirm your request.) Absent of the private-key signature, this is the only known way to ensure non-repudiation.
>>
>> Igor
>>
>> Dick Hardt wrote:
>>     
>>> On 2010-03-12, at 10:22 AM, Eve Maler wrote:
>>>
>>>       
>>>> This nets out to the requesting party (person or company seeking access) having an incentive to say "It's really me accessing this", such that it mitigates the risk that the requester (client) will hand off both the access token and the signing secret to a third party.
>>>>         
>>> Note I am NOT a security expert, and would appreciate an education on where I am wrong.
>>>
>>> When I look at this, I question if there really is that much more value in the Client having two secret items over one secret item. 
>>> I can see an advantage with something like using RAS, in that only the Client should have the private key, and if the private key can be used for lots of things, then there is some difference between a token and the private key. With symmetric keys, multiple parties have the keys, so non-repudiation is not possible.
>>>
>>> -- Dick
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>  
>>>       
>
>