Hi Jim, On Aug 17, 2012, at 10:06 AM, Jim Schaad wrote:
> 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. ... 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 > 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. 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 > 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. You are essentially saying that it would be good to have the ability to use a single cryptographic primitive, namely AES, for constrained devices. > > 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. 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. > > 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. 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.) > > 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. I am not sure a new algorithm is required. Aren't existing algorithms providing this support already? > > 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. Certainly. Ciao Hannes > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
