Re: [solace] Slides posted for SAAG heads-up

[Rene Struik <[e-mail]>]

Hi Carsten:

Great to discuss some of these topics with SAAG. I believe it would have 
merit to take this on a more fundamental ITRF level, so as to prevent 
people throwing a single protocol at the topic area: all context needs 
to be defined here in a unified way. More importantly, though, this 
should become an effort aimed at wide-scale usability (the 50billion 
devices everyone seems to point to in presentations from time to time)

Some brief comments:
a) Deployment scenarios.
I believe it would be a mistake to limit oneself to a single use case 
scenario. The proverbial light switch-lamp use case comes to mind, which 
would suffer from the often made assumption that one has a single, 
homogeneous trust domain (rather than a heterogeneous trust domain 
setting, where device roles etc are dynamic) and from small network size 
(after all, if internet of things will have 50 billion devices in 2020, 
then the avg network size *must* be large). This was the original 
approach within ZigBee all the way back in 2003, which - in my mind - 
set back the whole life-cycle management topic for years. By now (2012), 
there have been lots of studies into more realistic use cases with 
large-scale deployment by user groups, which do assume one can procure 
devices from mutually untrusted vendors, have many transitions in the 
supply-chain, may buy/sell/dispose of subsystems, etc. This all points 
towards heterogeneous trust models and very dynamic device behavior, 
without requiring centralized control flows involving a manufacturer 
(the latter is also undesirable from a survivability perspective).
b) Trust life-cycle management.
Please note that trust lifecycle management requires both crypto and 
security protocols (mechanical constructs) and constructs that take care 
of authorization decisions (initial authorization, changes to device 
role mapping, device replacement, etc.). The latter seems 
under-emphasized on the slides. This should include questions as to how 
to initialize 50 billion devices for virtually $0 apiece.
c) Security objectives.
An objective such as "not subject to a mass scale attack" would be hard 
to quantify in terms of required cryptographic assurances. Moreover, it 
seems to miss the point that some of these highly constrained networks 
are suppose to safeguard critical infrastructure (municipal water 
supply, hurricane prediction systems, etc.). In my mind, it would be a 
mistake to make this an exercise in toning down normal security 
requirements (under the pretext that this is only for "non-serious 
applications" (lamp-switch scenario again)). If one wants to get mass 
scale deployment of the 50 billion devices mark, one cannot aim for 
"crappy, but good enough" solutions, since no one in a position of 
accountability would sign off on these (lifes and jobs on the line if 
something goes wrong, so to speak).

The good news is that most high-quality crypto that is also efficient 
and does not leave a huge implementation footprint is fast becoming a 
commodity (or is getting there). The bad news is that integration of 
individual crypto and security constructs *and* security policies that 
allow these to be woven into a unified, standardizable framework 
architecture is still far off from sufficient understanding, let alone 
support via standards (and often simply ruled out of scope, since a 
"convenient" way to lock out product from other vendors).

==

Weblink to NIST Cryptography for Emerging Technologies and Applications 
Workshop, Gaithersburg, MD, November 7-8, 2011
http://www.nist.gov/itl/csd/ct/ceta-workshop.cfm

A very old IETF draft of potential interest - with requirements, 
spelling out crypto + policy requirements, etc.
(true: 3yrs old draft [Nov 2009], but referring to needing a home with 
IETF in concluding section):
http://tools.ietf.org/pdf/draft-struik-6lowapp-security-considerations-00.pdf


On 11/7/2012 12:45 PM, Carsten Bormann wrote:
> The slides for my short report at tomorrow's SAAG meeting are up:
>
> http://www.ietf.org/proceedings/85/slides/slides-85-saag-3.pdf
>
> (Disclaimer: These are presentation slides, not a presentation by itself.
> So they make sense primarily in combination with what I'm going to say.)
>
> Grüße, Carsten
>
> _______________________________________________
> solace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/solace


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]