Subject: [jose] Additional Usage Case

From: "Jim Schaad" <[email-masked]>
Date: Fri, 17 Aug 2012 16:36:32 +0930

Richard,

After talking with Bob at the last F2F meeting, I think I got my usage case
fleshed out.  I don't have access to your draft at the moment so I can't
harmonize with how things look, but I am sure you will be able to

X.X Constrained Devices

There is a class of devices that are starting to come online that need to be
able to do secure communications, but are very constrained both in terms of
power and in terms of memory.  One additional constraint is that these
devices have minimal cryptographic functionality.  Thus these devices have
exponentiation and AES block encryption/decryption, but they do not have any
hash functions built nor do they have enough memory for a software
implementation.  As such they can do EC-DH key agreement, but use an AES
based KDF function for generating keys for encryption/decryption or MAC
operations.  One side effect of not having any hash functionality is that
they have no ability at present to use TLS for any message protection.

These devices are power constrained; this means that every byte that is
transmitted over the net to another device is a drain.  For this reason the
smaller the message the better, the environment that they are working in
however is better than that of the HTTP header in that they can transmit
binary data without any problems.  Thus for these devices there is no
requirement that the data be converted to base64 prior to transmission.
This is actually an undesirable step as it increases the size of the message
to be transmitted.  A better method of encoding the headers would be to use
a length prefixed format for each of the pieces as this would produce a
smaller transmission block.  These devices would use UDP or the output of
the CORE working group for transmission of data thus leading to a hard limit
on the size of messages in the case of UDP.

For these devices the messages are going to be extremely constrained, as
such this means that allowing for a fixed order of the headers and any
content fields is highly desirable.  Having a fixed order simplifies the
parsing as does the ability to specify a canonicalization of the encoding to
minimize the number and location of characters that are not needed for
parsing the fields of a JSON structure.

Any devices operating in this environment would need to define some new
algorithms as they will be operating in a static-static EC-DH mode (combined
with constrained environments, this can provide some assurance on who
originates the message) and a new AES based KDF function to move from the
agreed secret to the content encryption key or MAC key used for protection
on the message.  This would also require defining a new MAC algorithm which
allows for key derivation but no content encryption.  It is possible that
these environments would be fully satisfied with AES-GCC encryption mode
however.

These devices would use internal methods for deciding which keys can be
trusted and what they are named.  This means that all keys can be easily
identified for all parties.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 17 Aug 2012 16:23:16 +0300

Hi Jim, 

On Aug 17, 2012, at 10:06 AM, Jim Schaad wrote:

> power and in terms of memory.

... and later in the text you add bandwidth constraints as well. 

>  One additional constraint is that these
> devices have minimal cryptographic functionality.

because of computational limitations or because of code size? 

>  Thus these devices have
> implementation.

It's surprising that they have PK-based capabilities but no support for a hash function...

>  As such they can do EC-DH key agreement, but use an AES

You are essentially saying that it would be good to have the ability to use a single cryptographic primitive, namely AES, for constrained devices. 

> on the size of messages in the case of UDP.

This is essentially the story the CoAP guys are presenting us. HTTP (with TCP) is too expensive and therefore they have to design something new that is based on UDP and consumes less bandwidth. 

> parsing the fields of a JSON structure.

Maybe JSON is too constrained for those scenarios as well. 
(I have already hear that argument and those folks have been interested in standardizing a binary format.)

> on the message.

>  This would also require defining a new MAC algorithm which

I am not sure a new algorithm is required. Aren't existing algorithms providing this support already? 

> identified for all parties.

Certainly. 

Ciao
Hannes

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