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.mis...@oracle.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@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-boun...@ietf.org [mailto:oauth-boun...@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 <tony...@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:ve7...@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.tschofe...@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:ve7...@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-boun...@ietf.org [mailto:oauth-boun...@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
