I don't have much data on how many request/responses an oauth web client does
per connection. But if we force a new TLS connection for each access token
(which may only be used for 1 or 2 request/responses) we will have a
scalability issue. I do agree the approach is relatively simple and workable
for native apps since there is less of a client performance issue.
For web app clients, I'd rather keep TLS security a separate issue/layer. For
example, a long-lived private key (symmetric or asymmetric) could be issued to
the client so that it can establish 2-way TLS connections that can be used for
1000s of requests per connection. Then a separate authorization header HoK
access token is used to authenticate each request/response.
Speaking of the authorization header, it's not clear in section 3.2 whether in
fact an authorization header is sent. The implication seems to be that the
resource server must have a way to pull the information from the TLS end-point
or get it from the authorization header which 3.2 doesn't speak to.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-07-10, at 1: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.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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
