Subject: [oauth] FW: Secdir Review of draft-hammer-oauth-00.txt

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Dec 2008 12:16:34 -0700

------ Forwarded Message
From: Sam Hartman <[email-masked]>
Reply-To: <[email-masked]>
Date: Fri, 17 Oct 2008 14:21:58 -0700
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [oauth] Secdir Review of draft-hammer-oauth-00.txt

[For the oauth list: The IETF has a security directorate (see
sec.ietf.org) which is a group of experts that review IETF drafts for
security issues.  I'm a member of that directorate and have been asked
by the area director sponsoring the oauth BOF at the next IETF to
perform such a review of the oauth draft.  Typically reviews happen fairly late in the process, although as in this case they can happen early on request.]

I have reviewed draft-hammer-oauth-00 as a special requests.  These
comments are primarily intended for the security and applications area
directors as input into considering the oauth bof.  These comments
should also be taken as input into the consensus process surrounding
the draft.

Background:

Oauth provides a way to delegate access to a resource in HTTP. The
canonical example is a user who has photos stored say at
photos.example.net and wants to buy prints from printer.example.com.
The user does not want to give printer.example.com their name and
password for photos.example.net; depending on what authentication is
in place they may not even be able to do so.  Oauth provides a way
that after obtaining consent from the user, printer.example.com can
gain a token that can be used to access the protected resource.  The
printer service may only be granted access to some photos--the ones
that the user wants printed.  The access may be time limited and have
other restrictions.

This mechanism is similar to proxy tickets in Kerberos and proxy
certificates in grid contexts.  It is related to constrained
delegation in Microsoft Kerberos, although involves significantly less
trust of the consumer (party seeking delegated access to a protected
resource).

The protocol roughly runs as follows:
1) Consumer makes a request to the service provider (where the protected resources live) and gets a blob called a request token
2) Consumer redirects the user to the service provider passing along the blob ; if the user authorizes the transaction then the consumer is notified.
3) Consumer asks service provider to turn the request token into another blob called an access token.
4) Consumer can use the access token to access protected resources.

Associated with each token is a shared secret used to provide
integrity protection and peer entity authentication of the party
making the request.

One thing we've been looking at with HTTP authentication schemes is
whether they are browser specific or whether they will work well in
atom/dav/etc environments.  Most of oauth will work well in a
non-browser context.  However oauth redirects the user from the
consumer to the service provider to seek authorization for the request
token.  This tends to mean that the service provider and consumer tend
to need to have the same idea about what kind of agent the user is
using. It seems clear that the service provider can enable whatever
they like, but that oauth may have limitations when being used with
classes of agent the service provider has never considered.

I found the spec sufficiently clear.  While I do have a lot of
detailed comments, I'd expect that at this point in the process.
Whenever you bring some idea into an large organization like the IETF,
you're almost certainly guaranteed that there are a set of things that
the organization cares about in its specs that need to be addressed.

                           Interoperability

The oauth document is not really a complete protocol; it is more like
a set of components that can be used in building a higher level
protocol.  To some extent this is necessary: a consumer that wants to
talk to a photo store will not know what to do if it is talking to a
blog.  Also, oauth treats issues like naming of resources to be
accessed, naming of users etc as an API matter to be handled at a
layer above oauth.  However it really seems like there are a lot of
things that are not specified in the spec that need to be done for
interoperability.  It seems like the description of how a service uses
oauth would need to be a fairly significant document.  In addition,
the security analysis of oauth itself is going to be somewhat
incomplete; oauth will need to be analyzed in the context of the using
service.
I realize that to some extent the same can be said for RFC 2822 or
HTTP.  However my qualitative feeling that this is more true for
oauth.

Oauth does not have mandatory-to-implement algorithms for security.
We typically require that.  There is no mandatory-to-implement method
for conveying request parameters.

There is no interoperable way to find the lifetime of a request or
access token, to find out when an access token has been revoked, etc.

                               Security

 Consumers are typically in different organizations than
service providers.  Their may be a potentially large number of
consumers.  However there is no automated key management for a shared
secret used to authenticate the consumer to the service provider.  I
think RFC 4107 will require us to create such a mechanism.

Section 12.8 implies that the consumer secret might not be secret--in
particular, a single consumer secret would be used in all instances of
a desktop application.  That is, you'd download a binary, and inside
that binary would be a secret used to authenticate to some provider.
The text and concept will require revision to survive last call in the
IETF.

The oauth parts of messages from the client to a server are optionally
integrity protected.  However there is no response protection.  At
least for the hmac-sha1 signature type adding response protection
would be trivial.  It would be reasonably trivial for the RSA
signature type, although the consumer would then need to know the
public key of the service provider.

Oauth service providers send shared secrets back to consumers for
request and access tokens.  There are two potential issues with this.
First, the consumer does not contribute to the secret.  Second, there
is no mandatory confidentiality protection of the secret.  This issue
needs significant discussion with the security community if only to
satisfy people that the oauth spec is reasonable in this regard.

Oauth responses can be cut&pasted onto different requests.  Fixing the
response integrity problem does not inherently fix this issue.

Oauth provides no mutual authentication.  We have typically expected
authentication systems that we're designing to provide mutual
authentication especially when there is no good reason not to do so.
It seems like fixing the response integrity problem could also fix fix
the lack of mutual authentication.

The replay prevention mechanism has a significant DOS concern for the
service provider.  A request contains a nonce and a timestamp.  The
timestamp must be non-decreasing but is not required to be
particularly close to current time nor to ever change.  The nonce is
required to be unique for a given timestamp.  So, if a particular
consumer never changes the timestamp then the server must retain all
nonce values presented to it.  Mechanisms such a digest handle this by
providing a server challenge in the www-authenticate header and
providing a mechanism for dealing with the server and client getting
out of sync.  Oauth is less likely to actually use www-authenticate
than digest.  One possible solution would be to define an error
meaning that the consumer must use a timestamp at least as large as
some value in a future request.  However without some sort of server
challenge this requires synchronizing replay state across all
instances of a service provider.  For example, if you have a bunch of
edge servers that implement your service, you need to make sure that
all of them are aware of the nonce values that have been used.  I
suspect that in practice people would not implement replay protection
in that environment.  I'd like to see optional support for channel
binding to TLS when TLS is used.  In many cases oauth has a shared
secret between the consumer and the service provider or a shared
secret specific to the token in question.  Using this secret to
confirm that we're talking to the right server at the TLS level will
provide extra defenses against phishing or other server substitution
attacks.  The support for channel binding should be good enough that
the consumer can tell securely whether the server verified the channel
binding.  Adding this to the protocol is relatively easy.  In some
implementations, implementing it  will also be easy; in others it
might be fairly difficult.  Thus I think the feature should be
optional, but secured against downgrade attacks.

The specification does not provide for automated key management of RSA
public keys; I think this too will be required by RFC 4107.  I can
understand why you want to rule enrollment (initial key discovery) out
of scope.  However you need to provide a mechanism for a consumer to
change its public key.

Section 6.2 provides user interface requirements for what a service
provider must do when seeking consent.  I didn't see any problems with
this, but  I want to call it to the attention of the security community.

Section 6.3 does not actually require that the service provider check
that the request token is authorized.  This requirement is critical;
fortunately I think it is obvious enough that  people are unlikely to
omit the check in implementations.

                            Extensibility

The oauth extensibility model should be improved.  There is a version
field, but the behavior for an unknown version is unspecified.  I know
there are a lot of arguments about how to handle versioning.  This
behavior is inconsistent with all of them.  You could drop the field;
you could require an error if the version number does not match; you
could use HTTP-style versioning where minor version mismatch is OK but
major version mismatch generates an error.

There is an error for parameter not understood.  It seems like sending
this error in response to an unknown parameter is permitted.
Unfortunately, this combined with the way the version number is
handled means there is no way for a new consumer to indicate support
for a new feature while working with an old service provider.  It may
be desirable to have critical (the other guy must fail if he does not
understand) parameters, but it seems like optional parameters as a way
of extending the protocol are also required.

                               Phishing

I'm still thinking about the phishing implications of oauth.  It's
clear that oauth has the concerns associated with any redirect scheme.
A malicious consumer can redirect the user to a phishing site rather
than the actual service provider.  This is only bad if the user
discloses credentials or other confidential information to the
malicious service provider.  So, it could be seen as a mistrusted
introduction problem.  I analyze situations like that and ask myself
how well will this approach work if the target of the redirect
actually improves their authentication technology.  Oauth seems like
it scores reasonably under this analysis.

However because there are three parties involved in the protocol the
phishing issues are more complicated.  If there is a problem it's
relatively subtle; I'm not comfortable saying that I've analyzed
things sufficiently, although assuming that mutual authentication and
binding to TLS are added, I think I'm happy with everything I've
considered so far.  Of course, phishing defense only makes sense when
TLS is being used.  The point of phishing is to obtain confidential
information.  Without confidentiality protection being provided,
there's no hope of preventing the attack.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OAuth" group.
To post to this group, send email to [email-masked]
To unsubscribe from this group, send email to [email-masked]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

------ End of Forwarded Message
_______________________________________________
oauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth