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 >> >> >> >> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
