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> <mailto: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>  
<mailto: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>  [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  <mailto:OAuth@ietf.org>

                    https://www.ietf.org/mailman/listinfo/oauth

                _______________________________________________

                OAuth mailing list

                OAuth@ietf.org  <mailto:OAuth@ietf.org>

                https://www.ietf.org/mailman/listinfo/oauth




    _______________________________________________

    OAuth mailing list

    OAuth@ietf.org  <mailto:OAuth@ietf.org>

    https://www.ietf.org/mailman/listinfo/oauth



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

Reply via email to