Subject: [Ace] Balancing How Tightly Coupled against Reasonable Options

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Mar 2014 12:14:07 -0400

At the BOF I was a strong proponent of scoping the solution only to
COAP+DTLS.
I've thought more about that.  I still favor that.  However, I've
realized that I had a bunch of complex reasoning behind that.

In the broader Internet, interoperability tends to be more important
than optimization.  It's more important to have fewer solutions than to
have solutions exactly matched to the environment.  The solution needs
to bmeet the requirements, but extra options, complexity, code size, etc
is preferable to having multiple solutions that do not interoperate.

As several people pointed out, you need a trusted element to convert one
authentication scheme into another; same is true for authorization
schemes.

However, in the constrained environment, it's often more important that
a solution work within the constraints than it is to re-use technology.

I would strongly object to chartering work here that's going to
effectively be another generic authentication mechanism that doesn't
have inherent  properties that strongly bind it to the constrained
space.

So, I've thought about this in terms of the COAP+DTLS question and come
up with the following.

The point of doing this seems to be to minimize code size and complexity
and re-use DICE work across ACE.  So, you could design a system where
DTLS was the only crypto you needed, where cipher and hash selection was
optimized between your COAP security and your authentication.  You could
solve challenges with DTLS and re-use the work.

This sort of inherently binds the problem to COAP speakers including
constrained devices, software written explicitly for constrained devices
and for trusted security proxies that interface with the rest of the
world.

Examples of work I'd support with this scoping:

* For ABFAB:

** An EAP method that worked well with DICE/DTLS

** Removing unnecessary EAP round trips

** RADIUS over DTLS with DICE constraints if you want to put an
   authorization server on a constrained device.

** Compression/better encodings of authorization information.

Alternatively, we could look at things that proxies can do without being
trusted.  Ways of reversably transforming other authentication
technologies for use in constrained environments more broadly than
COAP+DTLS.

Examples include:

* For ABFAB:

** Reversable ways of removing EAP round trips: avoiding EAP
   request/identity; taking success indications from a method to avoid
   need for  eap failure and eap success messages

* For OAUTH:

** a losless compression of signed tokens that can represent anything,
   but hapeens to be very efficient if the token generator is
   constrained-device friendly

** more efficient encoding of the HTTP parts of OAUTH that do not impact
   signature validity

What I would not support is something that was OAUTH-like or ABFAB-like
or PKI-like but was neither tied to COAP+DTLS nor transformable by an
untrusted proxy without keys.  I think that work would strike an
inappropriate balance with technology re-use and interoperability across
the wider Internet.  If we need a more efficient OAUTH or EAP, do that
work in the OAUTH or EMU workings groups, not here.  Actually get the
right people in the room to balance that tradeoff well.

--Sam