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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
