Subject: [OAUTH-WG] good meeting

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 13:29:22 -0700

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

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 18 Feb 2010 17:41:37 -0600

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: [email-masked] [mailto:[email-masked]] 
> 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
> 
> 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
> 
> 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?
> 
> 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)
> 
> 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
> 
> 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
> 
> Blaine: bearer tokens like Flickr's capability URLs don't 
> have strong security
> 
> 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.
> 
> Blaine: maybe it is that the signatures are too hard, but we 
> don't really know
> 
> 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
> 
> 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?
> 
> 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
> 
> Brian: what if the URL was not integrity-protected but the 
> body was -- would that be enough?
> 
> 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
> 
> 
>