Hi Bill, On Nov 27, 2012, at 7: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. With "that document" I guess you refer to http://tools.ietf.org/html/draft-tschofenig-oauth-security-00? With "signed token" do you mean an access token that is signed by the party issuing it? > Bearer tokens have similar security properties to HTTP cookies (minus for > the moment the XSRF problem). Please don't compare bearer tokens with cookies. They are very different. > 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. I guess signed token here means something like MAC where you actually do not sign the token but compute a message digest over some headers of the request. > > It's always been this simple use case that has been my focus for MAC. Could you describe your simple use case? For example, is it acceptable for you to use TLS from the client to the authorization server to get the MAC key (and algorithm)? What is your story regarding computing the keyed message digest over the HTTP message: header fields only, body? What about confidentiality protection? What about protecting the actual data (not just the request that contains the access token)? > > 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. If that's the case and they only use HTTP then they are in violation of the OAuth 1.0a spec. > Given the dynamic I see in the mobile development community I don't see us > getting all mobile apps into SSL only anytime soon. What makes you believe that guys who don't want to use an off-the-shelf library for security will get a custom security solution right. The performance of TLS is not an issue for mobile devices anymore. It may have been an issue in 2005. If they want to use OAuth 2.0 (as it is specified today; irrespectively of the bearer token spec) they have to use TLS in their code base. > 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. The IETF OAuth 1.0a specification requires TLS to be used between the client and the authorization server. Ciao Hannes > -bill > > > From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email protected]> > To: ext Sergey Beryozkin <[email protected]>; Hannes Tschofenig > <[email protected]> > Cc: [email protected] > 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: [email protected] [mailto:[email protected]] On Behalf > > Of ext Sergey Beryozkin > > Sent: Tuesday, November 27, 2012 1:23 PM > > To: Hannes Tschofenig > > Cc: <[email protected]> > > 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<[email protected]> > > 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 > > >>> [email protected] > > >>> https://www.ietf.org/mailman/listinfo/oauth > > >> _______________________________________________ > > >> OAuth mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
