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 >>> >>> > >
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- [OAUTH-WG] Signatures, Why? Blaine Cook
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Ethan Jewett
- Re: [OAUTH-WG] Signatures, Why? John Panzer
- Re: [OAUTH-WG] Signatures, Why? John Kemp
- Re: [OAUTH-WG] Signatures, Why? Ethan Jewett
- Re: [OAUTH-WG] Signatures, Why? Ethan Jewett
- Re: [OAUTH-WG] Signatures, Why? John Kemp
- Re: [OAUTH-WG] Signatures, Why? Leif Johansson
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? John Panzer
- Re: [OAUTH-WG] Signatures, Why? Jochen Hiller
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? Jochen Hiller
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? John Kemp
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? Ethan Jewett
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? John Panzer
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Peter Saint-Andre
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? Eve Maler
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Dick Hardt
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Eve Maler
- Re: [OAUTH-WG] Signatures, Why? Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? John Panzer
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? Paul Lindner
- Re: [OAUTH-WG] Signatures, Why? Igor Faynberg
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? John Kemp
- Re: [OAUTH-WG] Signatures, Why? Torsten Lodderstedt
- Re: [OAUTH-WG] Signatures, Why? Ethan Jewett
- Re: [OAUTH-WG] Signatures, Why? Brian Eaton
- Re: [OAUTH-WG] Signatures, Why? John Panzer
- Re: [OAUTH-WG] Signatures, Why? Zeltsan, Zachary (Zachary)
- Re: [OAUTH-WG] Signatures, Why? John Panzer
- Re: [OAUTH-WG] Signatures, Why? Eve Maler