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

From: "Mališa Vučinić" <[email-masked]>
Date: Thu, 22 May 2014 12:52:28 +0200

Hello everyone,

I would just like to stress our strong support for the “data object security” approach to authorization in constrained environments.

At the University of Grenoble and STMicroelectronics, we have on-going research efforts in this direction and benefits seem very appealing — first in terms of possible optimizations leading to efficient operation on constrained devices, but also in terms of the implicit support for proxies and multicast.

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.

Regards,
Mališa Vučinić

> From: Jari Arkko <[email-masked]>
> Subject: Re: [Ace] Adrian Farrel's Block on charter-ietf-ace-00-00: (with BLOCK)
> Date: 20 May 2014 14:05:15 GMT+2
> To: Likepeng <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Göran Selander <[email-masked]>, 'The IESG' <[email-masked]>, 'Barry Leiba' <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> 
> 
>> NEW
>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
>> Other security protocols may be considered as long as the primary
>> focus is maintained.  Other application protocols and protocols at other
>> layers in the stack are out of scope.
>> END
>> 
>> Only Jari prefers the original text (-00 version). 
>> 
>> So if Jari can live with Barry's proposal, maybe we can move on with that one.
> ...
>> I think the important message we want to convey is, we will not work on authentication and authorization for application protocols like OMA DM, transport protocols like SMS /USSD etc.
> 
> To clarify my position, I have been commenting as someone interested on this topic. About things that I would be willing to spend my time on around this WG. I do not think it would be appropriate for me to use my AD powers to force changes related to my preferences into the charter unless it is seriously broken. Group consensus should be the rule. So if I'm in the minority, feel free to ignore me :-)
> 
> In any case, I fully agree with what you said above about OMA DM, USSD, and so on; I do not want to work on those.
> 
> But I do believe that if we are creating an authorisation solution for constrained devices, it should have at least a little bit of generality in it. And I do not believe achieving this would be hard. Here's an example of something I would like to do: the basic setup in the working group is to be able to authorise a <trusted device> to instruct, say, a <thermostat> to maintain a particular temperature. This is a very transport-related way of looking at the problem, however. I would like to do things like sending the <thermostat> a <temperature schedule> that is signed by the <home owner>, and authorising the <thermostat> to trust information from that source. So my interests are not just in transport layer security, but in data object security. You can imagine various ways of implementing this, say S/MIME or JOSE signed pieces of information delivered over CoAP or HTTP. The details don't really matter at this point, but a reason I wanted to participate in this work was to make sure that our authz designs can do that later.
> 
> Can I live with the above text? Not sure, because I'm not sure how to interpret it. For instance, if the WG produced a solution that was able to do authz for CoAP/HTTP when used with DTLS, TLS, or JOSE, would that fall inside our outside what the text says? I think probably inside, because the second sentence allows looking at other security protocols as long as the focus is maintained. 
> 
> If I can suggest an edit, I'd say:
> 
> NEW
> Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
> Other security protocols may be considered as long as the primary
> focus is maintained.  The group is scoped to work only on the web
> protocols and data carried within them.
> END
> 
> Jari

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 May 2014 14:38:48 -0400

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

Mališa Vučinić <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Malisa Vucinic <[email-masked]>
Date: Fri, 23 May 2014 18:44:12 +0200

Hi Michael,

Thanks for your time to read the paper. My answers are inline.

Regards,
Malisa Vucinic

> explanation, or perhaps is too detailed for that point in the paper.

Yes, we get that remark often… The goal with fig 1 was to present at an early stage
in the paper all that we aim to support and the design idea of having the constrained
device (producer) agnostic of the response type. It could be a classical GET 
request/response pair, response to a multicast request or an asynchronous update
to observers, the device needs to locally monitor the physical quantities and anticipate
the preparation of signed objects, which are then encrypted on a per response basis 
(encapsulated in encrypted objects).

You can then have the signed objects traverse the application level gateways and 
achieve nice end-to-end security properties even when the information is stored 
somewhere in the Cloud. 

> and paranoia.  

In terms of the communication security, yes, one could make Sj a group key, with group
members being the end points. From the authorization folks, however, I get the impression
that they would like to have access control with a granularity of RESTful resource 
so we thus have this hybrid approach in sense that we do not differentiate between 
pure communication security and authorization, rather try to approach both in one go.

> The whole thing is very similar to the pre-IKE

SKIP (and particularly multicast extension to SKIP) could fit as 'access secret' key 
management scheme of OSCAR which would deprecate the need for secure unicast
channels (DTLS) between the Authorization Server (AS) and each host. In our model 
hosts support DTLS (mainly for backwards compatibility with current CoAP spec) so 
given the authenticated channels, the key management scheme could be really 
simplified with all intelligence residing within AS, and with a simple push model for 
key updates over the secure channel.

Indeed, the derivation of the master key in SKIP is similar to the derivation of our
per-response encryption key in terms of the replay protection. Note though that 
we rely here on how CoAP handles the Message ID used for duplicate detection 
so a nice extension (and more appropriate for security usage) would certainly be
the counter mechanism of SKIP. 

>     deployment period of many IoT.

Yes, you are right that there is room for the downgrade attack once devices 
start supporting multiple ciphers, so in that sense the cipher negotiation 
approach in the paper is a bit limiting.

Off the top of my head, would it make sense to include the list of supported
ciphers in the certificate of a device, also specifying the default one? You
would need to update the certificate with firmware upgrades introducing new
ciphers but it seems doable? Then the device could use the default signature
algorithm to generate signed objects offline and when needed it would need to  
perform online signing (or depending on RAM available, perform offline signing
with multiple ciphers).

In the model, we require clients to fetch device (server) certificates from the AS so 
client would in that case have a-priori knowledge what ciphers a device supports.
Essentially, this would be reversing the current decision model in terms that
it would be the client who would decide which cipher is going to be used, but
it makes sense with the constrained device and small cipher set on the other 
side, no?

Then, the client can issue the request with the cipher accept option simply 
stating which cipher was chosen. To protect this from downgrade, client could
include in the payload of the request a pre-defined token encrypted from the
derived key (using the chosen cipher), where the derivation procedure from
the paper would need to be extended to include the cipher accept option field.

Does this make sense?

> saw that packet, we can tell that without bothering to authenticate it.

Yes, in fact I was referring to these kinds of optimizations in my original post.
See bellow.

> is easily caught, and so the attack is very unlikely to succeed.

In the model, only an attacker in possession of the group key (access secret)
can get to the signed objects. In that sense, signed objects should never traverse
the network in clear.

Coming back to the light bulb, it could locally cache ‘on’ and ‘off’ signed objects,
upon first validation. For the following receptions of on/off requests, the light bulb
would first need to decrypt the payload with the derived symmetric key and then
check if the received signed object is in cache (already seen packet from your IPsec
example). Now if you have this light bulb and appropriate switch as hosts in a 
synchronized network with global time awareness, you could easily add expiry 
field to the on/off commands and control for how long the signed objects can 
bounce over the network as valid, without overhead of signature verification.

Do you see any concerns here?

> Is your contiki code available?
I will get back to you regarding this.
>   (the smartphones and desktop systems) which want to talk to

Thanks for the clarifications, I wasn’t aware of user space IPsec possibility!

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace