Subject: [Ace] Notes about OAuth analysis in draft-greevenbosch-ace-comparison

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Nov 2014 02:49:42 +0100

Hi Bert,
Hi all,

I wanted to provide a brief, written response to your ACE presentation
at IETF91 in http://www.ietf.org/proceedings/91/slides/slides-91-ace-3.pptx

The model used by draft-wahlstroem-ace-oauth-iot and by token
introspection is the following:

Client -> AS: Request Access Token
Client <- AS: Get Handle to Access Token

Client -> RS: Send Access Token Handle

RS -> AS: Token Introspection Req. (Access Token Handle)
RS <- AS: Token Introspection Resp. (Content of Access Token)

While this is not directly a pull model it does not match the indirect
push model described in the slide set either. I am not sure any proposal
uses the indirect push model described in your figure.

OAuth is typically described in a three party setup (since it is a
common deployment very much like Kerberos is described as a three party
protocol as well). However, it may also have more entities if the AS and
the RS belong to separate administrative domains. As I mentioned in
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 there is
also this Kantara UMA work, which builds on OAuth extensions, to extend
the model.

In fact, the number of parties is not a good measure overall since any
of the protocols can easily utilize more parties. Just consider how
complex AAA/EAP deployments and PKI deployments can get in a real world
environment.

Regarding the ticket format OAuth provides a lot of flexibility since
the access token is opaque to the client (and with token introspection
also for the RS). This means that you can use any format you like,
including the JWT format or a new design.

Regarding the protocol stack the OAuth-IoT proposal changed the
transport from HTTP to CoAP for the communication between the client and
the AS. For the client to RS communication it really depends on the
environment; a number of possible deployments are easy to imagine,
including exchanging access tokens inside a Bluetooth Smart GATT
exchange, a DTLS/CoAP exchange, or a CoAP with application layer security.

As you see so far, OAuth provides a lot of flexibility to deal with the
variety of requirements from different environments and the same is true
for client credentials. You can use a shared secret or an asymmetric
credential for client authentication in OAuth. It is not outside the
scope but rather left to the deployment to decide what is best.

The OAuth IoT drafts define new CoAP options to communicate the access
token from the client to the resource server. I guess all solutions will
have to find out a way to convey the token/ticket/cert/etc. from the
client to the RS somehow. Whether this is inside the CoAP exchange or
somewhere else does not really matter.

In the end you mention that "OAuth are trying to tweak a solution that
was not designed for IoT towards IoT.". It sounded as this would be
negative but, as Erik mentioned, you could also see this as an advantage
in a number of ways (particularly for those who have existing deployment
experience with OAuth already).

Ciao
Hannes