Re: [Ace] use of object security

[Malisa Vucinic <[e-mail]>]

Hi Michael,

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

Regards,
Malisa Vucinic

On 22 May 2014, at 20:38, Michael Richardson <[e-mail]> wrote:

> 
> 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.

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. 

> 
> 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.  

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
> 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

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. 

> 
> 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.

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?

> 
> 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.

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

> 
> 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.

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.
> 
> 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.

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

> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace