[ietf-http-auth] Review of draft-hammer-oauth

[Eric Rescorla]

$Id: draft-hammer-oauth-00-rev.txt,v 1.1 2008/10/18 20:56:37 ekr Exp $

This document describes a set of protocols for delegated access
to resources. The paradigmatic case here is photo printing. 
User U has a set of photos on service provider SP (e.g., Flickr)
and wants to have them printed by some printing service (called
a Consumer, so C) and so needs to give C permission to access
some set of photos on SP.

This document actually describes three related but independent
technical artifacts:

- A set of new HTTP authentication mechanisms, including
  a shared secret mechanism based on HMAC-SHA1 and a
  digital signature mechanism based on RSA.
- A set of message flows for a user to authorize a Consumer
  to access a given object.
- A token mechanism for the SP to offload storage onto the
  Consumer.

These are quite separable and should be standardized independently,
if at all. In particular, if new authentication mechanisms are
needed they should be standardized apart from OAuth.


BACKGROUND
This sort of delegated permissions is a fairly well-studied
problem with several major classes of solution, depending on
whether (1) the SP needs to be involved in the delegation
operation and (2) the SP needs to store information
about the delegation. I'll talk about two below, by way
of example.

Delegation Certificates:
For example, one class of solution is "delegation certificates",
which have the dataflow shown below:

    User                   Consumer                   SP
    ----------------------------------------------------
1.  Print R ------------------->
2.  <----- Need permission for R
3.  Token --------------------->
4.                             Request R + Token ------>
5.                             <--------- Response for R
6.  <------------------- Success    

In line 1, U requests C to do something (e.g., print it)
with Resource R. C detects that it doesn't have an existing
credential for R, and in line 2 asks U to give it one. 
U responds with a token (3) which C forwards to SP along
with its request (4). We assume that U and SP share some 
sort of cryptographic credential (e.g., SP knows U's public
key) which SP can use to verify the Token. SP checks that
the token grants C permission to R (and that U owns R) 
and if so responds with R. C can then do whatever the task
is, and reports success to U.

Note that U hasn't had to interact with SP directly at all
(though presumably it does in some other context.) It just
cooks up the token to give to C and C takes it from there.
What is the token? It could be an X.509 delegation certificate,
or a SAML assertion, or some other authenticated token, but
the key point is that SP wasn't involved in its creation.
Nor does the SP need to store anything about C's permissions
[depending on how the token is constructed, it may not even
need to know anything about C at all, if the token is a bearer
ticket].

This has a number of advantages, but also one major disadvantage:
it requires U's participation in the construction of the token,
which requires new software on U. o


ACLs:
Another class of solutions is access control lists; in a system 
of this type, SP would be involved in every delegation, as shown
below:

    User                   Consumer                   SP
    ----------------------------------------------------
1.  Print R ------------------->
2.  <----- Need permission for R
3.  Let C access R ------------------------------------>
4.  <------------------------------------------------ OK
5.  You have access ----------->
6.                             Request for R ---------->
7.                             <--------- Response for R
8.  <------------------- Success    

The key pieces of this system are messages 3 and 4, where
U instructs SP to give C access to R. SP handles this by
creating a local access control entry so that when C 
requests R, it knows to return it. Note that the standard
procedure would be for C to have an account with SP, 
though it's at least possible for U to refer to C via
a key pair, in which case C would not need an account
and SP could just store the key pair in the ACL.

A major advantage of this kind of scheme is that U can
be very primitive, since it's just frobbing bits on SP. 
In fact, it can be a standard Web browser and redirects
can be used to transition back and forth between SP and
C.


THE OAUTH SCHEME
OAuth isn't precisely like either of the schemes I describe
above. Rather, it's mostly an access control list based scheme
but it (at least potentially) offloads storage onto C rather
than storing the ACLs on SP. The dataflow as far as I can
tell is shown below [Note: this document would really 
benefit from a diagram like the one below]

    User                   Consumer                   SP
    ----------------------------------------------------
1.  Print R ------------------->
2.                             Need to access R ------->
3.                             <----- Request Token (RT)
4.  <------- Redirect to SP + RT
5.  <----------- U authorizes C access to R ----------->
6.  <------------------------------------  Redirect to C
7.  Redirected to C ----------->
8.                             Request Token ---------->
9.                             <------ Access Token (AT)
10.                            Request for R + AT ----->
11.                            <--------- Response for R
12. <------------------- Success

This is a little confusing because of the redirects, but what
seems to be going on is as follows:

1:     U requests C to print R.
2-3:   C gets a "Request Token" from SP
4-7:   U authorizes SP to give C access to R. The Request Token
       is used to carry the identity of R and C through 
       the redirects and C back from SP to itself. Finally,
       U is redirected to C. 
8-9:   C redeems RT for an Access Token (AT)
10-11: C uses AT to access the resource.
12:    C returns success to the user.

As I said above, except for the redirects required by HTTP, this is
basically an ACL scheme, except that because C stores the Access
Token, SP is not required to store access information for C, but can
(at least theoretically) extract it from AT. I don't know what real
OAuth systems do.


SEPARABILITY
So, why do I say this is separable? 

1. In order to know whether to grant C access to R, SP, needs to
   be able to authenticate C. However, there's nothing OAuth
   specific about authentication and so there's no reason that
   this should be tied to OAuth. Indeed, we already have a number
   of mechanisms for using both shared secrets (Digest, TLS-PSK,...)
   and digital signatures (TLS Client Auth, S-HTTP,...) as 
   HTTP authentication mechanisms and I don't see any showstopping
   OAuth couldn't use those. It's certainly arguable that
   these are unsatisfactory, but if so the IETF should do a general
   set of new HTTP authentication protocols, not do something
   OAuth specific.

2. The Access Token redemption part of the dataflow is only
   necessary to offload data onto C. If SP is willing to store
   access control lists, then this can be omitted entirely,
   as far as I can tell. On the other hand, one might want to
   design a scheme where the user preemptively sets access
   control values but then the first time the Consumer contacts
   the SP it gets a token and then the SP forgets the ACL values.
   The point is that these are separable and shouldn't be 
   rigidly slaved together.

3. As I indicated above in the Delegation Certificate section,
   there are useful architectures where there's no need to
   have an interlocking protocol with the client and the SP
   in order to authorize the consumer. However, because those
   architectures require the client to generate the token,
   and token format isn't standardized, this system can't be used
   in that way. I'm not saying that we need to do a DC/SAML
   type thing now, but the system should be constructed in
   such a way that it doesn't preclude it, and this one does
   not seem to be that way.


SPECIFIC COMMENTS
S 5.3.1.
Please do not class signature schemes like RSA with MAC
schemes like HMAC. They are not the same thing and it's
really confusing to treat them the same way. 

S 12.12.
This whole section belies a seriously confused model of how
cryptographic entropy works. Well designed cryptographic PRNGs can
produce a nearly arbitrary amount of pseudorandom data with no
significant impact on security provided that they are initially seeded
with an appropriate amount of entropy.  (I'm talking about 100 or so
bits here). If your system is constructed so that repeated requests
for randomness cause either blocking or generation of weak keys
then it is broken. 

Appendix A.
This would be a lot more useful towards the front of the document so
it provided context for the discussion of the PDUs.




-Ekr