Sunday 2012-11-04 15:10-16:10 Salon E

Attendance:
Behcet Sarikaya
Carsten Bormann
Jürgen Schönwälder
Kerry Lynn
Mehmet Ersue
Paul Chilton
Ulrich Herberg
Yoshihiro Ohba

This was an informal meeting that was intended to move forward our
common understanding of what the SOLACE activity is going to be.

Carsten went quickly through the slides from the Vancouver IETF
(http://www.ietf.org/proceedings/84/slides/slides-84-roll-11.pdf).
He stressed that the near term focus of SOLACE is soliciting
contributions that provide a fleshed out view of the lifecycle, the
players/roles and the security objectives of a specific scenario,
together with the security protocols that can be used between specific
roles to achieve these objectives.

We then mainly discussed two topics:


1) What is the best home for SOLACE?

One approach is to find a home in IRTF.
Several participants agreed:
-- this spans a couple of areas
-- IRTF can work in a relatively "sheltered" way
-- there may less of a need to go through an excruciating chartering
   process before we really understand the specific shape of the
   result that we can achieve

Other participants pointed out:
-- an IETF activity may be more focused on directly usable results
-- there are specific gaps such as the OLSRv2 security model that need
   input soon
-- there might even be a new M2M area in the IETF

Clearly, there wasn't consensus yet, but some more people leaned
towards the IRTF approach.  This requires further discussion.
Ulrich, Yoshihiro, and Carsten volunteered for working on a potential
charter for a new group.


2) What are the specific questions we want to ask for the contributions?

Questions that we would like to see covered in the contributions (in
no particular order):

-- What are the specific roles in this scenario?
   Groups of nodes may differ in their trust relationships, in their
   role in running the lifecycle, in their security domain, in their
   constrainedness, ...  (e.g., in SEP2 a "meter" appears to be a very
   special role, having a trusted relationship to the backend, ...)
-- what is the topology between these roles?  (This may include both a
   security-focused point of view and a view based on physical,
   link-layer or network layer topology)
-- What is the trust model?
   Specifically, what is the chain of trust needed for the system to
   operate, how do the different roles relate to the trust model; are
   there classes of trust based on some specific property (such as
   "inside"/"outside" something)?
-- Is there anything done to secure group communications (multicast/broadcast)?
-- What are the elements of your lifecycle?  Do you handle events like
   an entire building changing hands?
-- How does your security really work, which security protocols are
   being used?
-- What gaps are there?  Where do we need additional specifications?
-- Constrainedness?  What are the resource requirements on the
   specific roles?  What groups of nodes are there?

We should try to obtain contributions at least from the following
groups/for the following scenarios:
-- SEP2 (may need to be fleshed out wrt key management)
-- A simple home scenario that can be realized with PSKs
-- Cullen's Mothership scenario
-- ETSI M2M, maybe related to the EAP/PANA I-D and ETSI GBA
-- MANET scenarios such as that addressed by OLSRv2
-- AMI networking

Besides the I-Ds already identified, Kerry also has co-authored an
interesting NIST paper that he will provide a reference to.


At the SAAG meeting Thu 1510-1710, we have a short presentation slot.
We should try to narrow down the set of choices so we can present
something coherent to SAAG.  The intention is providing a heads-up of
the activity, and make it clear that this activity is not trying to
threaten any specific security area work but tries to benefit as much
as possible from existing results.

Please send corrections and additions to these notes to the list.

Grüße, Carsten