[Ace] use of object security

[Michael Richardson <[e-mail]>]

subject was:
        Subject: Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00:
        (with BLOCK)

Mališa Vučinić <[e-mail]> wrote:
    > I refer everyone interested to our DTLS-based architecture named OSCAR
    > (http://arxiv.org/pdf/1404.7799) that will be presented during IEEE
    > WoWMoM in June.

Very interesting.
I think maybe your figure 1 appears too early, or appears without enough
explanation, or perhaps is too detailed for that point in the paper.

You write that "The relation between j'th access secret Sj
    and i'th resource Ri is dependent on authorization policies and the
    desired level of confidentiality."

I guess the point is that the one can make Sj a "group" key, or
distribute it on per-end-point basis, based upon the level of audit
and paranoia.  The whole thing is very similar to the pre-IKE
IPsec SKIP mechanism, including the lack of crypto parameter negotiation.
   http://en.wikipedia.org/wiki/Simple_Key-Management_for_Internet_Protocol
   http://tools.ietf.org/html/draft-ietf-ipsec-skip-06

You write earlier:

> Due to the physical constraints, the number of supported cryptographic
> ciphers is limited. Indeed, constrained devices often have a single
> supported cipher suite (selected at the compile time). This fact reverses
> the paradigm encountered in the Internet where one of the security concerns
> during the handshake is the downgrade attack (the attacker forces two
> parties to use the weakest common

and later:

> The request contains  header carrying preferred content types. If capable,
> server responds with the content supported by the client. Therefore, to
> solve the interoperability issues, we require an additional accept option
> carrying supported ciphers.

I am not yet convinced that:
  a) the downgrade attack can be ignored.
  b) that this permits us to incrementally deploy new cryptographic
     protocols as the ones we have become weak over a multi-decade
     deployment period of many IoT.

I am pleased that OSCAR is not shy about asymmetric operations.
I am reminded of Jari's temperature sensor.  (You bring security to
Jari's 4-bit microcontroller multicast temperature sender...)
but, I think it would be easier to think of a light switch.

Imagine a light bulb receives a message from some sender that it should
turn on.  But the light bulb is *already* turned on.  In that context,
there may be no reason to always validate the asymmetric signature.
This is similar to how the replay counter in IPsec works: if we already
saw that packet, we can tell that without bothering to authenticate it.

This assumes no active, on-path, attacker will bother to change an "off"
signal into a "on" signal (invalidating the signature).  Such an attacker
is easily caught, and so the attack is very unlikely to succeed.

Is your contiki code available?

You write at the end:
> However, as it (IPsec) resides in the Operating System kernel, it is
> impractical for typical IoT applications.

1) There is no requirement that IPsec be in the kernel,
   the reason people put it there is so that it can act as
   service for layer-4 protocols, but if you want to re-implement
   those protocols (UDP is trivial) in userspace, one can easily
   have IPsec in an application using a raw IP socket.

2) when implemented over UDP, one can even have it in application
   library.

3) most IoT operating systems have no concept of a "kernel" anyway,
   so the concern is really only on the more capable endsystems
   (the smartphones and desktop systems) which want to talk to
   the IoT devices.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-