Subject: [core] Security considerations draft-ietf-core-coap-03

From: Rene Struik <[email-masked]>
Date: Wed, 27 Oct 2010 11:38:45 -0400

Dear colleagues:

I had a quick glance at draft-ietf-core-coap-03 and in particular 
security related items (unfortunately, no time yet to give this a 
thorough read).

Some initial comments on Section 10 of this document below:

1) Bootstrapping seems to be considered as a preliminary phase of a 
device or system's lifecycle. In my mind, this should be considered as a 
lifecycle stage that may be revisited over the lifetime of a device or 
system. An example hereof would be the deployment scenario where one 
configures a device in a mini-network using a configuration tool and 
subesequently enrols with another network; another one would be where a 
device is configured in stages "along the stack" (e.g., first MAC parms, 
then 6lowpan parms, then application parms). This suggests that 
enrolment and bootstrapping steps are not necessarily confined to a 
pre-operational "embryonic" stage, but may re-occur over time. In fact, 
this may be considered as part of configuration management (where 
shooting in initial parms would be considered as "configuration 
establishment").

2) Security of the coap packets seems to require mostly consideration of 
the "key usage" phase of key management only, i.e., it describes how to 
provide security services for packets communicated over the air. This 
being said, how one establishes shared keying material and maintains 
keys (or how one triggers, e.g., a key update) should of course be 
considered. If one chooses the key usage mindset here, public key 
certificates do not fit in, since these are aimed at setting up a secure 
and authentic channel, not at securing ordinary packets (it is part of 
management functionality, not operational use).

3) The cryptographic constructs to be used with coap should not preclude 
implementations where one already has cryptographic hardware on board, 
such as is the case with IEEE 802.15.4-2006 (where one often has an 
AES-128 engine in forward mode and/or a CCM cryptographic mode of 
operation). Using CBC mode as mode of operation (as one of the ISec 
modes discussed in Section 10.1) requires implementation of the inverse 
AES mode and would be unlikely to be supported by 802.15.4 platforms 
currently available in the market place.

4) The cryptographic constructs should try and be economical with 
communication bandwidth. This suggests that IPSec is a somewhat 
unfortunate choice since it may cause considerable data expansion for 
security admin data, this even cryptographic data expansion (due to 
message authentication codes) aside.

I have more comments, but will put thoughts on this in an email somewhat 
later. Please see also my list of items that require some discussion below.

Rene

==

[excerpt email RS to Zach Shelby as of September 29, 2010, 10:55am EDT]

I read the coap-pre2 draft and the DTLS document (RFC 4347) this weekend, but did not get back to you yet on this.

Some initial feedback:

1) security services: confidentiality, data authenticity, relative ordering in time, timeliness (specific services to be identified in packet header)
2) granularity: depends on scope of key sharing group (key id to be identified in packet)

To be discussed:
1) How to implement security policy enforcement
2) Maintaining state:
a) counter value for originating device;
b) mapping URI and device id;
3) binding packet and corresponding ack packet (so, not all crypto independent on per-packet basis as with DTLS)
4) stateless vs. state
a) properties achieved, resp. lost
b) DoS with handshake

I have time to discuss in detail this Friday (Fri October 1, 2010). Please indicate whether 10:30am EDT works for you.

Best regards, Rene

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363