Re: [OAUTH-WG] Holder-of-the-Key for OAuth

William Mills <wmills_92105@yahoo.com> Fri, 13 July 2012 20:42 UTC

Return-Path: <wmills_92105@yahoo.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5919511E810A for <oauth@ietfa.amsl.com>; Fri, 13 Jul 2012 13:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level:
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spMtOVeQD4rZ for <oauth@ietfa.amsl.com>; Fri, 13 Jul 2012 13:42:28 -0700 (PDT)
Received: from nm32-vm4.bullet.mail.bf1.yahoo.com (nm32-vm4.bullet.mail.bf1.yahoo.com [72.30.239.140]) by ietfa.amsl.com (Postfix) with SMTP id 3CEF611E80C7 for <oauth@ietf.org>; Fri, 13 Jul 2012 13:42:28 -0700 (PDT)
Received: from [98.139.212.145] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2012 20:43:05 -0000
Received: from [98.139.215.250] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jul 2012 20:43:04 -0000
Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 13 Jul 2012 20:43:04 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 946246.47956.bm@omp1063.mail.bf1.yahoo.com
Received: (qmail 80488 invoked by uid 60001); 13 Jul 2012 20:43:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1342212184; bh=FmvaRItc3lfSH026VnqVuU2BSPe7dn0TT+gN4+Knvjw=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Dy9tMmMKK7nAoAc9JVH+tGWl407F5reiDTVIdDkX23wSmSlgckZ6ROWzrptVIJhMQQ76YADScDUh3dAGmo7sH0JM+7W4lIu+ucyNtXYjeElLXTxwGZvEGZr48/TLhCz5PG4dP2u8ZKIGrZaQ7odFCCy79zcsOCYpSVdDWIaTsAw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sSKLyYDUYVrBv7JCnEHfTxRhf4+u8tGtLYu0s0gCoxxZ1poolqfVXkVj/gVhMCa9RPiI1Z41Rdkz3LSNHfdQcA/jJIfusB9zLmfa9yUwQ3Fl+U9E9uahO9K/lhErdKu9+Bp4uk+JizOB1BKuz4/o5/YMa6LjRGKIo6S0tzDXJVA=;
X-YMail-OSG: p6PZgOoVM1mbiMtmRaCF_hcEtRcqKDIA8tplkmNKv4bxjbR h080f8WtWvf6RxLvT2peHgUlbteEU9WUs3ePQSGRozMB5_xvy.PV1TV3KI0o sAcAqbU.T4IuCzU6p3BhHrO2YwPKO74.xh1NBAiT3J1sNJ0bVdP83Z.6AS7k Eup5z22VhgR1UZlPwGbJFu1U8eiDytMCr2c7bHwOJixsrZEQAj0_aqdL5AnD TNBozjNLm4r8fA.eUAiTKCWkhtwR5DyOxWKZtnNmVQZ2cGbcK7CRbBVt9Pnl ZVJUQmTSTinmsuQSDiWR9VuHtQZiUCuA8HJj.hSnX7jB_Gz1SOBBBFtUXaig wbdapw.IazBTBkT6qLAzV64HWYp1UvfPeYg8r1nDO9bdGzDJ_aghjD0m4ULP y81tQUeuBH0U6ECFG42FfllQiJkMVC6DwWkxZ6gbXyQH3iQGjcz5080pnTPm rnTwaZCtp.xxnawVV2cA7SyHEechMfyimh03QQZf2Nz0-
Received: from [209.131.62.115] by web31806.mail.mud.yahoo.com via HTTP; Fri, 13 Jul 2012 13:43:04 PDT
X-Mailer: YahooMailWebService/0.8.120.356233
References: <8FB1BC31-D183-47A0-9792-4FDF460AFAA1@gmx.net><B26C1EF377CB694EAB6BDDC8E624B6E74F979CF1@BL2PRD0310MB362.namprd03.prod.outlook.com><22194120-0613-48A7-9825-FD3BAD76062A@gmx.net><C433DCE1-3015-4442-9DD0-A5228415D6C0@ve7jtb.com><B26C1EF377CB694EAB6BDDC8E624B6E74F97B2E2@BL2PRD0310MB362.namprd03.prod.outlook.com><6D7E3A30-873A-41DD-8ADA-A3334E023576@gmx.net><397384FE-394C-4C4B-8962-56E4F86579C1@ve7jtb.com><B26C1EF377CB694EAB6BDDC8E624B6E74F97B4C1@BL2PRD0310MB362.namprd03.prod.outlook.com><AD9183B2-42DC-4DB8-A103-D97948C4BC59@ve7jtb.com> <4FFC6983.8030704@oracle.com> <999913AB42CC9341B05A99BBF358718D01A4937B@FIESEXC035.nsn-intra.net> <4FFC7BC4.5030902@oracle.com> <1341951979.14398.YahooMailNeo@web31803.mail.mud.yahoo.com> <8DD974A3-44A8-4E3F-AF43-E6511A6100B0@gmx.net> <1342025520.18462.YahooMailNeo@web31801.mail.mud.yahoo.com>
Message-ID: <1342212184.51204.YahooMailNeo@web31806.mail.mud.yahoo.com>
Date: Fri, 13 Jul 2012 13:43:04 -0700
From: William Mills <wmills_92105@yahoo.com>
To: William Mills <wmills_92105@yahoo.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <1342025520.18462.YahooMailNeo@web31801.mail.mud.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1055047407-201487617-1342212184=:51204"
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills_92105@yahoo.com>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 13 Jul 2012 20:42:30 -0000

The more I think about this the more I think that HoK is really more or an informational type RFC if anything.  If you really want a cleartext part so as not to encrypt a certificate or something then OK, but in the end all our extant token types can support the HoK token payload.  In profiles where we already have a transaction signature nothing more is needed.   And if you want to apply it to something like Bearer, then you should be using MAC instead.

We could theoretically wedge it in to the client authentication mechanism, but why?



________________________________
 From: William Mills <wmills_92105@yahoo.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net> 
Cc: "oauth@ietf.org" <oauth@ietf.org> 
Sent: Wednesday, July 11, 2012 9:52 AM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
 

Having re-read this I think I now understand how symmetric would work.  In the HOK model as I think of it we have 3 basic parts:  opaque token stuff, asserted client key, and server signature.  The asserted client key could be:

-a public key
-a certificate
-an encrypted symmetric key
-other?

For symmetric key it would act as a key distribution for clients to the endpoints, so it would be doing a similar thing for symmetric keys that it would for PK, e.g. key distribution and trust.  In the end the token itself can contain the asserted key, MAC tokens can support this concept now in fact.  The relying endpoint would extract the secret from the token to check the signature.  For the PK case you don't have to encrypt the asserted key, which is a little cheaper.

-bill


________________________________
 From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: William Mills <wmills_92105@yahoo.com> 
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; prateek mishra <prateek.mishra@oracle.com>; "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>; "oauth@ietf.org" <oauth@ietf.org> 
Sent: Tuesday, July 10, 2012 11:23 PM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
 
I also fail to see the value of a symmetric holder-of-the-key solution and I don't buy the performance argument either (particularly since we are using a short key length here.

I hope that this is not the "let us replicate all the work we had done in some other crazy enterprise identity management solution so far." approach. 


On Jul 10, 2012, at 11:26 PM, William Mills wrote:

> OK, but why do you need holder-of-key then?  I think holder-of-key gets significantly weird in the symmetric key case.   In the PKI case the token has (public_key, token, signature(public_key, token, serversecret)).  How will the server assert something in the credential that's useful in place of a plublic key (or certificate)?  I think the best case there is that the server is asserting a client name which the protected resource uses to look up the symmetric key to use for the signature check, but that could just be included in
 token anyway without holder-of-key.
> 
> I really don't see how this works with symmetric keys in any useful way that's not easier via another method like MAC tokens?
> 
> 
> From: prateek mishra <prateek.mishra@oracle.com>
> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> 
> Cc: oauth@ietf.org 
> Sent: Tuesday, July 10, 2012 12:00 PM
> Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
> 
> Hannes,
> 
> we have a variety of use-cases wherein a single server ("client") repeatedly interacts with a resource server for business purposes. These interactions may be on-behalf-of
> a single user or
 even multiple users. In such a use-case, use of assymetric signature imposes an unacceptable performance penalty and there is a lot of interest in being able
> to use symmetric signature instead.
> 
> - prateek
>> Hi Prateek,
>>  
>> why do you care about the symmetric key case?
>> Specifying more variants requires more code and decreases interoperability.
>>  
>> Ciao
>> Hannes
>>  
>>  
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of ext prateek mishra
>> Sent: Tuesday, July 10, 2012 8:42 PM
>> To: oauth@ietf.org
>> Subject: Re: [OAUTH-WG]
 Holder-of-the-Key for OAuth
>>  
>> As Phil Hunt suggests, there is a need for a discussion of the use-cases involved
>> 
>> How to bind the key to the requestor may have several variations, I would hope the work would cover a broad range
>> 
>> Given the importance of the symmetric key case, I would also be interested in key establishment methods as well
>> 
>> 
>> 
>> When I say arguably,  I expect you to argue.  
>>  
>> John B. 
>>  
>> Sent from my iPhone
>>  
>> On 2012-07-10, at 1:01 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>  
>> Binding the key to the channel is arguably the most secure
>>  
>> Not really, there are hardware
 options that give good security properties
>>  
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
>> Sent: Tuesday, July 10, 2012 9:55 AM
>> To: Hannes Tschofenig
>> Cc: Anthony Nadalin; Hannes Tschofenig; OAuth WG
>> Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
>>  
>> Binding the key to the channel is arguably the most secure. 
>>  
>> SSL offloading and other factors may prevent that from working in all cases. 
>>  
>> I suspect that we will need two OAuth bindings. One for TLS and one for signed message. 
>>  
>> John B.  
>>  
>> Sent from my iPhone
>>  
>> On 2012-07-10, at 12:11 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>  
>> If we do not bind the key to the channel than we will run into all sorts of problems. The current MAC specification illustrates that quite nicely. On top of that you can re-use the established security channel for the actual data exchange. 
>>  
>> On Jul 10, 2012, at 5:29 PM, Anthony Nadalin wrote:
>>  
>> One question is if we want to do a generic proof of possession for JWT that is useful outside OAuth,  or something OAuth specific.    The answer may be a combined approach.
>>  
>> Depends if we want OAuth to support the concept of a request/response for a proof token and keep the actual binding for a separate specification, in most of our cases the keying material is opaque (and just a blob), where we care
 about the key material  is in the key agreement (entropy) cases.
>>  
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] 
>> Sent: Tuesday, July 10, 2012 3:34 AM
>> To: Hannes Tschofenig
>> Cc: Anthony Nadalin; OAuth WG
>> Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
>>  
>> I agree that there are use-cases for all of the proof of possession mechanisms.
>>  
>> Presentment methods also need to be considered.  
>>  
>> TLS client auth may not always be the best option.  Sometimes message signing is more appropriate.
>>  
>> One question is if we want to do a generic proof of possession for JWT that is useful outside OAuth,  or something OAuth specific.   
 The answer may be a combined approach.
>>  
>> I think this is a good start to get discussion going.
>>  
>> John B.
>> On 2012-07-09, at 3:05 PM, Hannes Tschofenig wrote:
>>  
>> Hi Tony, 
>>  
>> I had to start somewhere. I had chosen the asymmetric version since it provides good security properties and there is already the BrowserID/OBC work that I had in the back of my mind. I am particularly interested to illustrate that you can accomplish the same, if not better, characteristics than BrowserID by using OAuth instead of starting from scratch. 
>>  
>> Regarding the symmetric keys: The asymmetric key can be re-used but with a symmetric key holder-of-the-key you would have to request a fresh one every time in order to accomplish comparable security benefits. 
>>  
>> Ciao
>>
 Hannes
>>  
>> On Jul 9, 2012, at 9:57 PM, Anthony Nadalin wrote:
>>  
>> Hannes, thanks for drafting this, couple of comments:
>>  
>> 1. HOK is one of Proof of Possession methods, should we consider others?
>> 2. This seems just to handle asymmetric keys, need to also handle symmetric keys
>>  
>>  
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Monday, July 09, 2012 11:15 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Holder-of-the-Key for OAuth
>>  
>> Hi guys, 
>>  
>> today I submitted a short document
 that illustrates the concept of holder-of-the-key for OAuth. 
>> Here is the document: 
>> https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk
>>  
>> Your feedback is welcome 
>>  
>> Ciao
>> Hannes
>>  
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
>>  
>>  
>>  
>>  
>>  
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth