Hi Bill,
On 8/15/12 9:16 AM, "ext William Mills" <[email protected]> wrote: > Fundamentally MAC and any HoK that uses symmetric keys are equivalent. Either > can pull in the same profile of HTTP stuff into the signature. > > The issue is: a small change in the protocol specification makes the two > mechanisms incompatible. Hence, you have to provide the code for the two and a > possible negotiation mechanism along with it. For example, the fact that OAuth > 1.0 does not allow for automatic token refresh already makes the OAuth 1.0 MAC > and the OAuth 2.0 MAC different. > > I commented on your argument that MAC and Bearer have equivalent security > properties in a different thread. > > Sorry. I missed that. Do you have a pointer for me by chance? > > > Ciao > Hannes > > -bill > > > > > > > From: Hannes Tschofenig <[email protected]> > To: William Mills <[email protected]> > Cc: Hannes Tschofenig <[email protected]>; Torsten Lodderstedt > <[email protected]>; O Auth WG <[email protected]> > Sent: Tuesday, August 14, 2012 10:49 PM > Subject: Re: [OAUTH-WG] OAuth 1.0a > > > Hi Bill, > > how do you know that the outcome of the security discussions will unlikely be > different than MAC? > > The views about TLS had changed in the meanwhile (a few years ago many thought > it is too heavy and too expensive to get certificates), and we now have the > JSON work as well. On top of that we may also want to provide not just client > to server key confirmation with integrity protection of a few fields but more > than that. In a nutshell the solution has to provide better security than > bearer -- not just be different. > > Ciao > Hannes > > On Aug 14, 2012, at 10:53 PM, William Mills wrote: > >> > I want to get the SASL work done. HoK is interesting, but I've become >> convinced that it's not actually anything that needs it's own spec, you can >> do HoK with MAC or any other signed scheme by including the needed proof of >> ownership in the token. HoK, however it works out, is unlikely to vary a >> lot from the elements that would currently be needed to support MAC or 1.0a >> and if needed can just extend the SASL mechanism. >> > >> > -bill >> > >> > From: Torsten Lodderstedt <[email protected]> >> > To: William Mills <[email protected]> >> > Cc: Mike Jones <[email protected]>; O Auth WG <[email protected]> >> > Sent: Tuesday, August 14, 2012 12:42 PM >> > Subject: Re: [OAUTH-WG] OAuth 1.0a >> > >> > Hi Bill, >> > >> > do you need to specify this aspect of your SASL profile now? Why don't you >> wait for the group to complete the work on signing/HoK? >> > >> > You could also contribute your use cases to drive the discussion. >> > >> > best regards, >> > Torsten. >> > >> > Am 14.08.2012 21:37, schrieb William Mills: >>> >> It's for the OAUTH SASL spec. I've been writing it with the idea that >>> OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we >>> want to allow for IMAP), but several folks were saying when this all started >>> that 1.0a was dead and I should not refer to it. >>> >> >>> >> I want to make sure the SASL mechanism is build to properly handle signed >>> auth schemes and not just bearer (cookie) type. >>> >> >>> >> -bill >>> >> >>> >> From: Mike Jones <[email protected]> >>> >> To: William Mills <[email protected]>; O Auth WG <[email protected]> >>> >> Sent: Tuesday, August 14, 2012 12:28 PM >>> >> Subject: RE: [OAUTH-WG] OAuth 1.0a >>> >> >>> >> What problem are you trying to solve? >>> >> >>> >> From: [email protected] [mailto:[email protected]] On Behalf Of >>> William Mills >>> >> Sent: Tuesday, August 14, 2012 12:22 PM >>> >> To: O Auth WG >>> >> Subject: [OAUTH-WG] OAuth 1.0a >>> >> >>> >> What's the general opinion on 1.0a? Am I stepping in something if I >>> refer to it in another draft? I want to reference an auth scheme that uses >>> signing and now MAC is apparently going back to the drawing board, so I'm >>> thinking about using 1.0a. >>> >> >>> >> Thanks, >>> >> >>> >> -bill >>> >> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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
