Peter, I think, you have captured the meeting's discussion well. I tried to document the meeting's agreements. Below is my summary of the main points on which, in my opinion, the participants have agreed (or, at least, were close to an agreement).
* OAuth should develop specifications that provide security for the implementations that do not use SSL. There is a need for describing the threats against which the protection is provided in such cases. The developers need to understand a level of protection. * TLS/SSL cannot address all security issues as it protects only the messages that are in transit (i.e., inside the channel). * There is a need to specify what should be signed. The various use cases may have different requirements on that. It is unlikely to find one approach that will satisfy all scenarios. The different signing profiles may be needed. * People have different use cases that they particularly care about and their favorite security solutions for them. Input on the use cases is invited. * A description of a use case should explain the case's threat model and what needs to be signed (and why) if the signatures are used. Everybody's corrections of and additions to this summary are welcome. Zachary > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Peter Saint-Andre > Sent: Thursday, February 18, 2010 3:29 PM > To: OAuth WG > Subject: [OAUTH-WG] good meeting > > That was a helpful discussion just now -- thanks to everyone > who participated. Jeff Hodges and I made some *rough* notes > via EtherPad at http://etherpad.com/n2jOXo3WTY and I paste > them below. Real minutes will follow once we've had a chance > to listen to the recording. > > --Peter > > ## > > OAuth interim #3 > > [notes picked up in progress] > > Blaine: cert chains often aren't checked in libraries, but I > like the elegance of no distinction between consumer and > access token -- instead SP decides what token means (James > Manger's proposal to separate tokens from signatures) > > Brian: IETF OAuth work should try to provide security for > those who are not able or willing to use SSL? > > Blaine: I think so > > Brian: how much security can we reasonably provide for those people? > need to be really clear about threat models > > Blaine: e.g. in Twitter originally were concerned about > replay attacks, also concerns about refresh tokens > > Brian: let's explore the Twitter example -- they send cookies > over HTTP but passwords over HTTPS, but when they have issues > it's usually operational issues, weak passwords, etc. > > Hannes: re-use of an eavesdropped token depends on the > application, but how much concern is there about off-path attacks? > > Blaine: I definitely support bearer tokens > > Brian: my point is that it's silly to use OAuth as a > replacement for HTTPS -- what are the threat models that > HTTPS doesn't protect against? > > Hannes: I wouldn't put that as a design constraint -- this is > true for everything, not just OAuth over HTTPS > > JeffH: TLS/SSL doesn't give you message integrity and replay > protection (if you keep the message around) -- secure > channels provide integrity (and encryption) of the channel > but not integrity outside the context of the channel > > Hannes: the same is true of an OAuth token once unbundled, if > you share it with other entities > > JeffH: my point is only that the secure channel doesn't > protect a token outside the channel > > Hannes: distinction between transport layer security and > application layer security (yes, this is a good way to put it) > > Peter: it seems that we don't have a clear threat model > > Blaine: is the threat developers? people are lazy... > > Brian: we have a real problem with operational security > (e.g., credentials kept in plaintext on the service provider) > -- if we have a bearer token model then we won't need to keep > credentials in plaintext > > Hannes: I have a proposal -- we won't be able to have one > approach that satisfies everyone, but we can at least > describe the threat model more clearly and let people choose > which features solve those problems > > Peter: that might make sense > > Hannes: what are people's constraints in implementation and > deployment? > > Brian: all widely deployed security technologies use > transport security or bearer tokens > > Blaine: I somewhat disagree -- percentages might be larger at > a service like Twitter or Flickr than at a broader service > like Google or Yahoo! > > Blaine: my observation is that no one has ever deployed a > bearer token system that works, other than cookies -- I think > that OAuth tokens that can be signed can work quite well > > [scribal note: we will have an audio recording] > > Brian: Microsoft and Kerberos support > > Blaine: not on the web > > Brian: how about OpenID? > > Blaine: but no one uses that > > Brian: how about SSO systems between Yahoo and Flickr? > > Blaine: Flickr people complain about that :) > > Blaine: bearer tokens like Flickr's capability URLs don't > have strong security > > Blaine: do we need [lost] > > JeffH: OAuth as toolkit that gets profiled for different use > cases -- the current split among the documents makes sense -- > the Token I-D is the basic toolkit, and the "delegation" I-D > is an example of a particular profile for a (small) range of > use cases. > > Hannes: what is the disagreement at that point? > > [the chair falls down on note-taking] > > Brian: we were trying something that had never been done before > > Blaine: maybe it is that the signatures are too hard, but we > don't really know > > Eve: we have existence proofs of it working, but maybe not > wide interop > > Brian: what is the threat model behind signatures? what are > signatures for? > > Eve: signatures are not there to substitute for channel > security, but provide attestations or other features that > can't be derived from channel security -- might need strong > identity proofing > > Brian: is a bearer token that lasts one minute OK? > > Eve: interested in data origin authentication and fact attestation > > Paul: a bearer token might not show intention, signatures > provide a strong indication > > Brian: not sufficient that bearer token have a short lifetime > -- need to sign the whole message? > > Paul: yes, the body would need to be protected > > Brian: in that case, it seems as if the IETF OAuth draft > doesn't give you what you need because it secures only the > URL and the time, not the post body > > Paul: might need an extension for that > > Brian: what if the URL was not integrity-protected but the > body was -- would that be enough? > > Paul: yes we'd want to sign it all > > Brian: that's hard > > Brian: I'm hearing that different people need different things signed > > Hannes: the bearer signing token is like the null profile > > Brian: how many optional signing methods do we need? > > Blaine: I disagree with the assertion that the use cases are > not overlapping > > Hannes: do you think that there's only one signing profile needed? > > Blaine: I'm hearing that "there's so much fragmentation that > we should just use bearer tokens" > > Brian: the solution I'd like to see is (1) bearer tokens with > good operational security characteristics and (2) a second > layer that formats a message in a canonical way (e.g., a set > of bytes) that would separate it from the details of the HTTP protocol > > Hannes: (1) it won't help to say in the spec that you > shouldn't have infinite lifetimes (2) might want a more > flexible signing approach, more like DKIM than SIP signing > > Justin: if we feel strongly about signing, we need to have > clarity on the use cases -- can we have three or four > paragraphs on each signing scenario? i.e., what exactly needs > to be signed (does the timestamp need to be signed? the > nonce? the body? etc.) > > Agreement to discuss this on the list -- Brian, Blaine, and > Paul will post about several scenarios. > > ## END > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
