[Ace] The ACE documents

[Hannes Tschofenig <[e-mail]>]

I took a look at the document in the working group. Here is a my short
summary.

- Use Cases
https://datatracker.ietf.org/doc/draft-seitz-ace-usecases/

This document describes the use cases and requirements already presented
during the BOF.

- Problem Description
http://tools.ietf.org/html/draft-seitz-ace-problem-description-01

This document provides a good summary of the conversation at the meeting
in Stockholm. It captures the essential design decisions.

- Design Considerations
http://tools.ietf.org/html/draft-seitz-ace-design-considerations-00

This document was written in preparation of the BOF to highlight some of
the challenges with constraint devices. None of the discussed issues are
surprising.

- Overview of Existing Security Protocols
https://datatracker.ietf.org/doc/draft-tschofenig-ace-overview/

I wrote this document in preparation for the BOF to explain the pros and
cons of available protocol solutions.

- Solution Documents

There are two types of solutions currently submitted to the group, namely

a) OAuth-based Designs

draft-gerdes-ace-dcaf-authorize-00 is a re-write of the OAuth protocol
to make the encoding more efficient and introduces new terminology per
draft-gerdes-ace-actors-01 (which stresses the cross-domain use).
draft-tschofenig-ace-oauth-bt-00 and draft-tschofenig-ace-oauth-iot-00
re-uses OAuth as much as possible.
draft-schmitt-ace-twowayauth-for-iot-00 follows an OAuth-based design as
well
(even though many relevant message exchange parts are left out of the
description) but the description puts a strong emphasis on the use of DTLS.

The three solution show differences in what credentials they use.

There are two types of credentials, namely long-term credentials shared
between the client and the authorization server and short-term
credentials established for use between the client and the resource server.

* draft-gerdes-ace-dcaf-authorize-00 focuses on the establishment of a
symmetric session key to be used between the client and the resource
server, which is then used within DTLS. IMHO what credentials are used
between the client and the AS are not further discussed but DTLS is used
as well.

* draft-tschofenig-ace-oauth-bt-00 and draft-tschofenig-ace-oauth-iot-00
inherits the functionality from OAuth and uses DTLS between the client
the AS and may use CoAP/DTLS between the client and the RS. The
established session key for use between the client and the RS is also
flexible, as in OAuth, can can either be a symmetric or an asymmetric
key (so-called proof-of-possession key). Also the use of a bearer token
is possible.

* draft-schmitt-ace-twowayauth-for-iot-00 focuses on the use of
asymmetric credentials between the client and the AS as well as on the
communication between the client and the RS. The use of a ticket is only
hinted in Figure 4.

b) EAP-based Design

draft-marin-ace-wg-coap-eap-00 describes how to map EAP to the
CoAP-based environment. If the requirements in
draft-seitz-ace-usecases-01	are strictly interpreted then this proposal
fails since it does not support offline operation of the resource server.

- Out-of-Scope documents

There are a few documents that are not within the scope of the group,
namely
https://datatracker.ietf.org/doc/draft-zhu-ace-groupauth/
https://datatracker.ietf.org/doc/draft-sarikaya-ace-cga-nd/