Good that you both raise this point. The refresh token mechanism allows us to request new access tokens (and new keying material correspondingly since the two are tight together) in a dynamic fashion. If you turn the MAC key into a long term secret or use it with multiple resource servers then you obviously loose the security benefits.
All this is documented in Section 5 of http://tools.ietf.org/html/draft-tschofenig-oauth-security-00#section-5 On Nov 27, 2012, at 7:59 PM, William Mills wrote: > Yes! > > The other thing that is better in the OAuth 2 model is the refresh > capability, which makes plain text channel token usage more palatable. > > From: "Richer, Justin P." <jric...@mitre.org> > To: William Mills <wmills_92...@yahoo.com> > Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com>; ext > Sergey Beryozkin <sberyoz...@gmail.com>; Hannes Tschofenig > <hannes.tschofe...@gmx.net>; "oauth@ietf.org" <oauth@ietf.org> > Sent: Tuesday, November 27, 2012 9:51 AM > Subject: Re: [OAUTH-WG] What needs to be done to complete MAC > > An important point to note, that many OAuth1 implementations in the wild > screw up, is that you still need TLS between the client and the Authorization > Server to protect the token and secret in transit, even if you don't use TLS > during the client's calls to the protected resource. Since OAuth2 core > mandates TLS at the Token Endpoint explicitly for all token types, that's > much more clear to understand (in my opinion) in implementation. > > In case the above is unclear, what I'm trying to say is this: putting a > signed token like MAC into the OAuth2 framework will give us the capability > of OAuth1 in a clearer, more secure (in the wild) structure. I think it's > vitally important that we have this functionality, and while I understand the > need for clear use cases, I don't understand the feet-dragging. > > -- Justin > > On Nov 27, 2012, at 12:32 PM, William Mills wrote: > >> I don't see in that document a significant use case for a signed token, >> which is use over clear text channels. Bearer tokens have similar security >> properties to HTTP cookies (minus for the moment the XSRF problem). Signed >> token types can be used over plain text channels without the concern about >> re-use of the token by a 3rd party. Replay protection is still needed but >> that's not in scope for the token mechanism itself. >> >> It's always been this simple use case that has been my focus for MAC. >> >> Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we >> won't be able to go completely SSL due to the installed base of clients. >> Given the dynamic I see in the mobile development community I don't see us >> getting all mobile apps into SSL only anytime soon. MAC and OAuth 1.0 solve >> the token security problem for the last hop to the phone/wi-fi device >> without SSL for the bulk of the application traffic. >> >> -bill >> >> >> From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com> >> To: ext Sergey Beryozkin <sberyoz...@gmail.com>; Hannes Tschofenig >> <hannes.tschofe...@gmx.net> >> Cc: oauth@ietf.org >> Sent: Tuesday, November 27, 2012 4:33 AM >> Subject: Re: [OAUTH-WG] What needs to be done to complete MAC >> >> 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. >> >> 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. >> >> 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 >> >> >> _______________________________________________ >> 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
