Hi Sergey, On Nov 27, 2012, at 2:45 PM, Sergey Beryozkin wrote:
> Hi Hannes > > On 27/11/12 12:33, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> Hi Sergey, >> >> I believe we would make faster progress on security topics if could >> focus on listing security requirements we have and what threats we want >> to mitigate. The reason why we have not finished this topic is simply >> because everyone was just talking about specific (but incomplete) >> solutions. You are unfortunately falling in the same trap as well. > > Quite possible - I was hoping to give some perspective of someone who would > like to see a wider acceptance of 2.0 at the grass root level if you wish > where 'grass root' represents simple 2.0 applications. We are obviously interested in wide acceptance of our specifications. > >> >> If you really care about the topic then have a look at the mentioned >> document and tell us whether the requirements are complete. >> Reading through the document you will notice that there a few more >> considerations to pay attention to than just the few listed below. >> > Believe it or not I did read the document awhile back :-) Cool. Thanks. > and will definitely read it few times more - it is a must-read. I'm just > concerned that it appears that the possible progress on MAC > needs to be justified by linking it implicitly to the security threats doc. > And I'm not sure it is the best way to follow. > > How about a slightly different approach. > Do you agree that supporting HOK is important ? Assuming yes then I guess the > threats doc must be talking about the relevant issues that HOK can help with > addressing. > > If we can agree on this then IMHO MAC passes the acceptance criteria because > it offers one way to provide a HOK support. Whether JWT or other token type > may also help with HOK support is entirely different issue and it is down to > specific OAuth2 implementers on which HOK-capable token to support In Section 4 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 we tried to explain that there are three approaches to address very common security threats that exist in these three party protocols. All three approach, namely "confidentiality protection", "sender constraint", and "key confirmation", address these common threats in their own way. The details vary between the different solution categories. We published the bearer token specification, which follows the approach described in Section 4.1 ("confidentiality protection"). The group very early on said that they also wand an alternative, using "key confirmation". This was actually the reason why we moved the bearer and the MAC specification out of the main OAuth 2.0 and put them into separate documents. Consequently, there is no need to convince us that we should be working on a solution that is different than the bearer token (even I keep explaining folks that bearer tokens are not cookies and that they have similar properties than the other mechanisms). We had also figured out that there isn't only a single solution that will make everyone happy. But we also don't want to standardize everything comes to our mind: you can see in other areas (e.g., EAP, SASL, TLS ciphersuites, IKEv2 extension, etc.) that the creativity is endless when it comes to authentication and key exchange protocols. I am hoping that the conference calls (which I had asked folks to indicate their preference for) will help us to come up with an answer of what the essential requirements are (and hopefully within a very short timeframe). You are, btw, welcome to join those calls. Ciao Hannes PS: We should have probably never used the term HOK since it caused more confusion than it helped. > > Thanks, Sergey > > > >> Ciao >> Hannes >> >> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >>> Of ext Sergey Beryozkin >>> Sent: Tuesday, November 27, 2012 1:23 PM >>> To: Hannes Tschofenig >>> Cc:<oauth@ietf.org> >>> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >>> >>> Hi Hannes >>> On 26/11/12 19:01, Hannes Tschofenig wrote: >>>> Hi Sergey, >>>> >>>> as Phil said it would be helpful for us to receive reviews of this >>> document: >>>> http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 >>>> >>>> The document lists requirements and threats. >>> >>> >>> Let me offer two possibly naive reasons why using MAC may help, one of >>> them is related to the security, another to the ease of HOK support on >>> the client >>> >>> 1. The most safe way to return MAC token to the client is to use a >>> two-way TLS due to the mac key also returned to the client. Two-Way >> TLS >>> offers a stronger support for getting the client authenticated along >> the >>> way too >>> >>> 2. Assuming HOK confirmation matters at all (and I believe it does), >>> IMHO it is much simpler for a basic client implementation to apply a >> MAC >>> signature algo and thus work with the OAuth2 servers expecting HOK >>> confirmations >>> >>> One more reason is more about facilitating the further migration to >> 2.0 >>> which I tried to outline in my response to Phil Hunt >>> >>> Thanks, Sergey >>> >>>> >>>> Ciao >>>> Hannes >>>> >>>> On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: >>>> >>>>> If we want to get this done we have to get agreements on the >>> requirements for HOK. Several meetings ago (quebec) the group >> indicated >>> that mac wasn't appropriate to anyone's needs. >>>>> >>>>> Some would argue that OAuth1 users arguably have less security than >>> the simpler bearer token /tls model in OAuth2. This just shows the >> real >>> issue of demonstrated need has not been properly defined and >> understood. >>>>> >>>>> More dialog on use cases is very helpful to moving HOK/MAC/etc >>> forward. >>>>> >>>>> Phil >>>>> >>>>> On 2012-11-26, at 10:15, Sergey Beryozkin<sberyoz...@gmail.com> >>> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> What needs to be done to complete the MAC token spec ? Without >>> having it signed off it will be difficult to get people working with >>> OAuth 1.0 convinced to move to 2.0. >>>>>> I'm seeing another user request for getting OAuth 1.0 support >>> extended further because the user expects it is more secure, and I >> guess >>> because it is proven to work for people, and I guess because many >> OAuth >>> 1.0 users feel that should stay from OAuth 2.0 because of some bad >> press. >>>>>> >>>>>> Without MAC being completed the division will continue, with even >>> more misleading anti-OAuth2 posts appearing (though I guess some of >> the >>> better posts point to some level of complexity in 2.0). >>>>>> >>>>>> Is it a matter of a security expert validating the text, fixing >> few >>> typos, and basically signing it off ? >>>>>> >>>>>> If someone is interested then I can provide the info offline on >> how >>> it MAC supported in our framework to get things tested easily and >> such... >>>>>> >>>>>> Cheers, Sergey >>>>>> >>>>>> _______________________________________________ >>>>>> 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
