What about security in depth? Signing + TLS is more secure than either alone, isn't it?
-- Justin On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: > Hi Bill, > > thanks for the feedback. Let's have a look at this use case: > > You need to provide me a bit more information regarding your use case. Could > you please explain > > 1) Who is authenticated to whom? > 2) What plaintext connection are you talking about? > 3) What is the problem with encrypted connections? Is this again the "TLS has > so bad performance" argument? > 4) Since you are talking about cookies and making them more secure are you > trying to come up with a general solution to better cookie security - a topic > others are working on as well. > 5) What is the threat you are concerned about? > > Ciao > Hannes > > PS: I would heavily argue against standardize a security mechanism that > offers weaker protection than bearer when the entire argument has always been > "Bearer is so insecure and we need something stronger." > > On Aug 9, 2012, at 9:43 PM, William Mills wrote: > >> OK, I'll play and start documenting the use cases. >> >> Use case #1: Secure authentication in plain text connections: >> >> Some applications need a secure form authorization, but do not want or need >> the overhead of encrypted connections. HTTP cookies and their ilk are >> replayable credentials and do not satisfy this need. the MAC scheme using >> signed HTTP authorization credentials offer the capability to securely >> authorize a transaction, can offer integrity protection on all or part of an >> HTTP request, and can provide replay protection. >> >> -bill >> >> From: John Bradley <ve7...@ve7jtb.com> >> To: William Mills <wmills_92...@yahoo.com> >> Cc: Dick Hardt <dick.ha...@gmail.com>; "oauth@ietf.org" <oauth@ietf.org> >> Sent: Thursday, August 9, 2012 11:26 AM >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >> >> In Vancouver the question was asked about the future of the MAC spec due to >> it no linger having a editor. >> >> The Chair and AD indicated a desire to have a document on the use-cases we >> are trying to address before deciding on progressing MAC or starting a new >> document. >> >> Phil Hunt is going to put together a summery of the Vancouver discussion and >> we are going to work on the use-case/problem description document ASAP. >> >> People are welcome to contribute to the use-case document. >> >> Part of the problem with MAC has been that people could never agree on what >> it was protecting against. >> >> I think there is general agreement that one or more proof mechanisms are >> required for access tokens. >> Security for the token endpoint also cannot be ignored. >> >> >> John B. >> >> On 2012-08-09, at 1:53 PM, William Mills wrote: >> >>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are >>> libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model >>> and will provide for a single codepath for sites that want to use both >>> Bearer and MAC. >>> >>> From: Dick Hardt <dick.ha...@gmail.com> >>> To: William Mills <wmills_92...@yahoo.com> >>> Cc: "oauth@ietf.org" <oauth@ietf.org> >>> Sent: Thursday, August 9, 2012 10:27 AM >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>> >>> >>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>> >>>> I find the idea of starting from scratch frustrating. MAC solves a set of >>>> specific problems and has a well defined use case. It's symmetric key >>>> based which doesn't work for some folks, and the question is do we try to >>>> develop something that supports both PK and SK, or finish the SK use case >>>> and then work on a PK based draft. >>>> >>>> I think it's better to leave them separate and finish out MAC which is >>>> *VERY CLOSE* to being done. >>> >>> Who is interested in MAC? People can use OAuth 1.0 if they prefer that >>> model. >>> >>> For my projects, I prefer the flexibility of a signed or encrypted JWT if I >>> need holder of key. >>> >>> Just my $.02 >>> >>> -- Dick >>> >>> >>> >>> _______________________________________________ >>> 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
