Subject: Re: [Anima] Confirmation of consensus to adopt draft-pritikin-anima-bootstrapping-keyinfra as ANIMA WG document, ends Aug 12, 2015

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 3 Aug 2015 12:08:11 +0000

Support from my side, too. 
Michael

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Duzongpeng
> Sent: 31 July 2015 07:11
> To: Sheng Jiang; anima
> Cc: Toerless Eckert (eckert); [email-masked]
> Subject: Re: [Anima] Confirmation of consensus to adopt draft-pritikin-
> anima-bootstrapping-keyinfra as ANIMA WG document, ends Aug 12, 2015
> 
> Hi Dear all,
> 
> I support adoption of this bootstrapping draft.
> 
> Best Regards,
> Zongpeng Du
> 
> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Thursday, July 30, 2015 10:44 AM
> To: anima
> Cc: Toerless Eckert; [email-masked]
> Subject: [Anima] Confirmation of consensus to adopt draft-pritikin-anima-
> bootstrapping-keyinfra as ANIMA WG document, ends Aug 12, 2015
> 
> There was clear consensus for adopting draft-pritikin-anima-bootstrapping-
> keyinfra as a ANIMA working group document in the IETF 93 ANIMA WG
> meeting. This message starts a two-week call on confirming the consensus
> from the WG meeting.
> 
>   Title:      Bootstrapping Key Infrastructures
>   Authors :   Pritikin, et al.
>   Filename:  draft-pritikin-anima-bootstrapping-keyinfra
> 
>   https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-02
> 
> Please express your support or rejection. If you think this document should
> _not_ be adopted, please also explicitly indicate the reasons.
> 
> This adoption call will end on Aug 12, 2015.
> 
> Regards,
> 
> Sheng + Toerless
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Aug 2015 09:28:29 +0000

The chairs conclude there is a consensus in the ANIMA working to have this draft become a working group draft - no one had any objections to adopting the document and it targets one of our chartered work items. The authors should submit the next version as an ANIMA working group document (draft-ietf-anima-*-00).

This authors and the ANIMA bootstrap design team should keep working on this document as editor towards its maturity. The authors and the ANIMA bootstrap design team should report any major modifications to the WG, either mail list or face-to-face meeting, and acquire consensus in ANIMA WG.

Thanks,

Sheng & Toerless
>Subject: [Anima] Confirmation of consensus to adopt
>draft-pritikin-anima-bootstrapping-keyinfra as ANIMA WG document, ends
>Aug 12, 2015
>
>There was clear consensus for adopting
>draft-pritikin-anima-bootstrapping-keyinfra as
>a ANIMA working group document in the IETF 93 ANIMA WG meeting. This
>message
>starts a two-week call on confirming the consensus from the WG meeting.
>
>_not_ be
>adopted, please also explicitly indicate the reasons.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Aug 2015 13:10:16 +0200

I would like to raise a concern at this point in time.

I personally believe that the use of design teams in the IETF has become
a new way of excluding people (not only in ANIMA but also in other groups).

Design teams run for a (very) long period of time (often without a clear
mandate), are put together by the chairs (who decide about the
participants and also who they do not want on the design team) and the
entire decision making process is less clear in the end.

The situation becomes worse when there is actually work going on
elsewhere in the IETF with a very similar scope.

I am raising this now because Max approached me at the last IETF meeting
and was a big advocate of inclusiveness and the need to harmonize
activities in the area of bootstrapping (which I call key distribution)
in the IETF. Today, this does not work since even participating in many
of the design teams is not possible.

Ciao
Hannes

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 12 Aug 2015 07:22:47 -0400

Hannes,

Thanks for raising this issue.  For some working groups, SACM for instance, the design team meeting times and connection information are published so others can join.  Maybe we can make that more of the standard practice?  Alternative, change logs/diffs could be used by others to counter new points introduced.  Are they being used as they should be?

Thank you,
Kathleen 

Sent from my iPhone

> On Aug 12, 2015, at 7:10 AM, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 12:29:40 +0100

In a side conversation in Prague, Max offered to try pull together
an overview of the various related things being tackled in the IETF,
as this topic came up in saag as well.

(Max's opinion was that there may be a way to provide one solution for
almost all of those, I'm less convinced of that.)

Would having that discussion f2f at IETF94 be useful? (That could be
a non-WG forming BoF session or a saag slot I guess.)

I think (but am open to correction) that we don't have any related
work item that has to be done before IETF94, so if that timing is
ok, we could organise something

S.

On 12/08/15 12:22, Kathleen Moriarty wrote:
> Hannes,
> 
> Thanks for raising this issue.  For some working groups, SACM for
> instance, the design team meeting times and connection information
> are published so others can join.  Maybe we can make that more of the
> standard practice?  Alternative, change logs/diffs could be used by
> others to counter new points introduced.  Are they being used as they
> should be?
> 
> Thank you, Kathleen
> 
> Sent from my iPhone
> 
>> I personally believe that the use of design teams in the IETF has
>> become a new way of excluding people (not only in ANIMA but also in
>> other groups).
>> 
>> Design teams run for a (very) long period of time (often without a
>> clear mandate), are put together by the chairs (who decide about
>> the participants and also who they do not want on the design team)
>> and the entire decision making process is less clear in the end.
>> 
>> I am raising this now because Max approached me at the last IETF
>> meeting and was a big advocate of inclusiveness and the need to
>> harmonize activities in the area of bootstrapping (which I call key
>> distribution) in the IETF. Today, this does not work since even
>> participating in many of the design teams is not possible.
>> 
>> Ciao Hannes
>> 
>> 
>>> On 08/12/2015 11:28 AM, Sheng Jiang wrote: The chairs conclude
>>> there is a consensus in the ANIMA working to have this draft
>>> become a working group draft - no one had any objections to
>>> adopting the document and it targets one of our chartered work
>>> items. The authors should submit the next version as an ANIMA
>>> working group document (draft-ietf-anima-*-00).
>>> 
>>> This authors and the ANIMA bootstrap design team should keep
>>> working on this document as editor towards its maturity. The
>>> authors and the ANIMA bootstrap design team should report any
>>> major modifications to the WG, either mail list or face-to-face
>>> meeting, and acquire consensus in ANIMA WG.
>>> 
>>> Thanks,
>>> 
>>> Sheng & Toerless
>>>> -----Original Message----- From: Anima
>>>> [mailto:[email-masked]] On Behalf Of Sheng Jiang Sent:
>>>> Thursday, July 30, 2015 10:44 AM To: anima Cc: Toerless Eckert;
>>>> [email-masked] Subject: [Anima] Confirmation of
>>>> consensus to adopt draft-pritikin-anima-bootstrapping-keyinfra
>>>> as ANIMA WG document, ends Aug 12, 2015
>>>> 
>>>> draft-pritikin-anima-bootstrapping-keyinfra as a ANIMA working
>>>> group document in the IETF 93 ANIMA WG meeting. This message 
>>>> Title:      Bootstrapping Key Infrastructures Authors :
>>>> Pritikin, et al. Filename:
>>>> draft-pritikin-anima-bootstrapping-keyinfra
>>>> 
>>>> _______________________________________________ Anima mailing
>>>> list [email-masked] 
>>> _______________________________________________ Anima mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/anima
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Aug 2015 14:01:01 +0200

On 08/12/2015 01:22 PM, Kathleen Moriarty wrote:
> For some working groups, SACM for instance, the design team meeting
> times and connection information are published so others can join.

This might be an option. In some sense this is a model where the mailing
list activities are extended with phone conference calls (for those
cases where mailing list activities are just not enough).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Aug 2015 14:11:14 +0200

Sounds a bit like https://xkcd.com/927/

I would already be happy if we could come up with terminology to
understand when we are solving the same problem and when we aren't.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 12 Aug 2015 12:30:07 +0000

Also the ANIMA design teams are open mailing lists open to everyone, etc. For example the bootstrap team meets in 1.5 hours, info at 

http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap

For ANIMA, I don't see your concern at this point, Hannes, but I do agree that generally these teams could turn "private" easily if we're not paying attention. 

But, that always happened in the past as well, folks got together and worked offline on some things, then came back to the group. It also has advantages, as long as the end result is still open for debate. 

Michael

> From: Anima [mailto:[email-masked]] On Behalf Of Hannes
> Tschofenig
> Sent: 12 August 2015 14:01
> To: Kathleen Moriarty
> Cc: Sheng Jiang; Toerless Eckert (eckert); [email-masked];
> anima; Stephen Farrell
> Subject: Re: [Anima] Conclusion: adopt draft-pritikin-anima-bootstrapping-
> keyinfra as ANIMA WG document
> 
> 
> 
> This might be an option. In some sense this is a model where the mailing list
> activities are extended with phone conference calls (for those cases where
> mailing list activities are just not enough).
> 
> Ciao
> Hannes
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Aug 2015 10:02:56 -0400

Stephen Farrell <[email-masked]> wrote:
    > In a side conversation in Prague, Max offered to try pull together an
    > overview of the various related things being tackled in the IETF, as
    > this topic came up in saag as well.

    > Would having that discussion f2f at IETF94 be useful? (That could be a
    > non-WG forming BoF session or a saag slot I guess.)

Either is fine; I'm happy to participate and contribute; but I'm not
convinced that a 1 hour conversation is useful.

The most useful thing might be to have a conversation about a common
nomenclature for the threats that one needs to defend against.

That would, I think, make it much easier for different groups to compare
different solutions, and realize whether or not they actually want/need to
defend against things.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Aug 2015 10:46:50 -0400

> clear mandate), are put together by the chairs (who decide about the

You are exactly right that this has historically been a serious problem.
I can point to a number of cases where there have been serious issues that
continue to linger until today.

I'm not happy about design teams, and I resisted a bit about creating the
bootstrap design team.  My take on *this* design team (and design teams done
right) is that they have essentially replaced (opaque) author teams who
in the past have done things in a totally adhoc manner.

In this case, the chairs (and AD) forced us to build a charter:
   https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap

so we have a mandate.  The call for design team members was open, and really
is still open, and the mailing list is archived and open.

    > elsewhere in the IETF with a very similar scope.

Agreed, and I hate when this work elsewhere is done under NDA.
(I really really hate it, and it pains not to point fingers and name names.)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Aug 2015 09:06:17 +1200

> understand when we are solving the same problem and when we aren't.

Sure, and when we are solving an already-solved problem. But I don't
think there's any process rule or algorithm that is going to fix this:
it's just one of the things where everybody, and not only the ADs,
have to keep their eyes and ears open and raise the alarm when they
notice overlaps.

As already noted, the Anima design teams have been set up to
operate transparently.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 13 Aug 2015 06:15:36 +0000

This is reply to both Hannes and Stephen.

The ANIMA chairs have been very clearly to emphasized that the design teams were open to for all interested ANIMA participants. The mail list for the anima bootstrap design team are also open. It is currently have 18 subscribed members. We also encourage Max to harmonize with other relevant WGs, such as netconf, 6bitsh, 6low. So, in this case, we are not worrying the closeness issue.

ANIMA WG has a chartered work item for "bootstrapping a trust infrastructure", but it is for autonomic network. draft-pritikin-anima-bootstrapping-keyinfra has just been adopted as WG document. Whether it may become the fundamental of the potential one solution, I have very open opinion. It would be very useful, if such attempt gets success at the end. It is worthy trying at least.

Best regards,

Sheng

>From: Stephen Farrell [mailto:[email-masked]]
>Sent: Wednesday, August 12, 2015 7:30 PM
>To: Kathleen Moriarty; Hannes Tschofenig
>Cc: Sheng Jiang; anima; Toerless Eckert; [email-masked]
>Subject: Re: [Anima] Conclusion: adopt
>draft-pritikin-anima-bootstrapping-keyinfra as ANIMA WG document
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Aug 2015 13:00:15 +0200

Hi Sheng,

thanks for your mail. A short response below:

On 08/13/2015 08:15 AM, Sheng Jiang wrote:
> The ANIMA chairs have been very clearly to emphasized that the design
> teams were open to for all interested ANIMA participants. The mail
> list for the anima bootstrap design team are also open. It is
> currently have 18 subscribed members. 

Before this discussion took place I have not been under the impression
that this design team is open to everyone.

If you want to make it open then you might want to consider the idea
Kathleen described in her email.

As you can imagine if the chairs announce the formation of a design
team, ask for volunteers (and not do not accept everyone who
volunteers!), and then put the conference bridge details on the Wiki
that does not make me think that I can just dial in.

Maybe I am the only one who got that impression and everyone else (who
cared) dialed into the bridge.

> We also encourage Max to
> harmonize with other relevant WGs, such as netconf, 6bitsh, 6low. So,
> in this case, we are not worrying the closeness issue.

Encouraging is always good and an easy thing to do.

The question remains about the desired outcome. Is the idea to have one
solution only or is it to educate interested parties that there are
multiple solutions around?

I am advocating the latter and argue that the market should shake it
out. I have looked at many of the solutions and even though I am
familiar with the security terminology and the generic concepts it took
me a while since every community (not only within the IETF but also in
other SDOs) use their own language. I have to admit that there is even
stuff that I don't fully understand.

In ACE we ran a tutorial series to discuss existing work and we managed
to cover a few things but certainly not all of it. (I am still planning
to schedule more tutorials. Here is the list of things we had looked at:
http://www.tschofenig.priv.at/wp/?p=1012).

> 
> ANIMA WG has a chartered work item for "bootstrapping a trust
> infrastructure", but it is for autonomic network.

The scope of the ANIMA group is pretty fuzzy so that it is quite likely
that in a few months that some folks in the group will claim that their
work has much wider applicability. Already now I read the *constrained
environments* terminology in the abstract of the bootstrapping document.
It might not be too far fetched to assume that someone will show up in,
for example, ACE and notices this lack of alignment with ANIMA. As one
of the co-chairs of ACE should I care?

The same issue just recently happened with the 6tisch group. Initially
their work was focused on a special radio technology (which only very
few people care about). Time passed and now there is the believe that it
has applicability to other areas as well.

IHMO I am not sure whether it was a good idea to do this type of
security work in the ANIMA group. I believe the security area would have
been a much better place given the broader expertise.

I believe that this arrangement has happened because of the use new
terminology (particularly bootstrapping) and even within the IESG there
might have not been enough understanding that this work is about
authentication, authorization and key distribution. Just guessing.

Ciao
Hannes

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 13 Aug 2015 16:01:04 +0000

> Kathleen described in her email.

Kathleen said:
“the design team meeting times and connection information [could be] published so others can join”

The anima bootstrap design team mailing list, charter, current drafts, active team members, meeting notes, collaboration notes, and recurring meeting times and webex information are all published at the anima wiki as previously noted:
	http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap

> cared) dialed into the bridge.

Please join us. Often, even of the people that signed up, only a few folks show. Honest, I’m not sure where your frustration is coming from since in my experience what every working group wants is active involvement! 

> other SDOs) use their own language.

I think good goals include:

* Alignment on the language. There may be good reasons to have alternate solutions for alternate use cases but there really isn’t a good excuse for inconsistent terminology. That would go a long way toward helping us understand each other’s use cases and local optimizations. 

* I continue to believe there is room for a unified core around bootstrapping the key infrastructure and feel that much of the divergence between similar efforts is due to us mixing in other concepts. I agree this is a fine point for disagreement as even well established layered architectures constantly have “layer violation” holy wars. And we don’t have a well established terminology for discussing possible layers. 

> I have to admit that there is even

Good to know we’re all in that club together. 

>From your ace bof summary:
http://www.ietf.org/mail-archive/web/ace/current/msg00336.html
> Participants suggested to consider looking at the entire life cycle of
> these IoT devices to prevent problems later with provisioning. While
> those do not necessarily be standardized in this group there was a
> desire to avoid later problems.
> 
> As next steps the charter discussions will have to continue to resolve
> some of the raised questions.

I agree with the statements that lifecycle provisioning is often original fuzzy in scope but always turns out to be a source of later problems when not addressed. 

> authentication, authorization and key distribution. Just guessing.

Authentication, authorization and key distribution concepts are of course well established. What has not been clearly addressed is a clear framework for bootstrapping of the key infrastructures. Key distribution is *kinda* that except that to date it depends on manually provisioned prior keys or other manual operations by an external third party. The value of the “bootstrapping” term is it comes from the metaphor about pulling ones self up by the bootstraps and thus clearly excludes short cuts like assuming a god-mode administrator kicking things off. 

As I noted during saag at IETF#93 I too see value in involving the larger security area. We have the existent working groups though so a first step is to foster better communication toward a common framework. 

- max

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Aug 2015 15:07:00 -0500

After reading draft-pritikin, I had similar views as Hannes expressed below.

In my view the solution  should not claim constrained environments
applicability.

On the other hand, in my view the solution should be developed in each
group separately, like aces, and 6lo. In fact 6lo already formed a
mailing list but that work stalled because of anima DT.
I don't think that it should go to the security area.

Regards,

Behcet

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 13 Aug 2015 20:46:55 +0000

> In my view the solution  should not claim constrained environments

Thanks for providing the review feedback. 

The bootstrapping document uses the term “constrained environments” in the sense of a network environment that provides limited connectivity due to the untrusted nature of the device (e.g. don’t let untrusted devices generate or receive traffic) or the security characteristics of the network (e.g. air gapped). This is distinct from the use of the term “constrained environment” as used to indicate code that is running in a “constrained device”. 

I’ve added an issue to the bootstrapping document github to track this and ensure the language is clarified. 

- max

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 Aug 2015 14:10:32 -0700

On Wed, Aug 12, 2015 at 10:46:50AM -0400, Michael Richardson wrote:
> so we have a mandate.

Well, the WG-chairs did what the ADs asked, and i am sure the ADs did
what the official IETF process is for handing out email aliases that
are considered to be sub-WG mailing aliases (for constructs like design
teams formed to deliver part of working group charter items).

This may sound all a bit like process badness, but it does help to
stay focussed on deliverables of the WGs.

> (I really really hate it, and it pains not to point fingers and name names.)

How is that even possible in the IETF ? Or where you complaining about
other bodies ?

Cheeers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 Aug 2015 14:50:25 -0700

> that does not make me think that I can just dial in.

The reason for asking first for volunteers was trying to elecit
actual commitments from folks and give them credit in "design team members"
section. I am pretty sure i did send afterwards another email stating
that everybody is welcome to join the maling list and participate after
the call for volunteers was through.

This may not have been ideal or ideally communicated, but right now
i wouldn't know how to do it better. If we do not explicity ask
folks to state their names and volunteer cycles to work towards 
a well defined charter of the design team, we easily end up with just
a discussion club. 

> multiple solutions around?

I for once start forming the picture of a common framework between NETCNF
and ANIMA wrt bootstrap. I might be possible, and it might even be useful to 
extended this over time to what other WG needs - with work. 

> stuff that I don't fully understand.

Some thoughts:

"Learning curves are for pussies" (TM) Jon Stewart, retired *sob*:

Aka: trying to invent bootstrap from scratch  over and over again does
lead to more variety but not better bootstrap. Awareness of what else is
out there and then modify/expand accordingly to what you need sound like
a better strategy to me.

"Name recognition"

Calling the same things differently is the main reason to create confusion.
We've already seen this between ANIMA and NETCONF. It certainly does help
to find some whatever slow way to create common terminology for common
elements/steps in bootstrap.

Avoiding to reinvent security and allowing easy validation of security.
I am sure there are lots of RFC to detail these points ;-)

> http://www.tschofenig.priv.at/wp/?p=1012).

Nice!

> of the co-chairs of ACE should I care?

I'd just try to figure out whatever form of collaboration helps
us to better achieve our mutual charter goals first. Then bother
about the rest. Of course every WG would love to see their work result
be used accordingly in other places in the IETF. With ANIMA being
in OPS and ACE being in SEC, its a lot more likely that we in ANIMA
have to be a lot more worried about correctly reusing other IETF WGs
work result appropriately and to fill our your areas mandatory RFC
section accordingly. There's is not mandatory "autonomic considerations"
sections in every RFC ;-))

> been a much better place given the broader expertise.

Yeah, and the routing piece of ANIMA would have been done a lot better
in the routing area and the our signaling in the INT area and so on.

ANIMA is about operationalizing a system concept by building it from the
appropriate components, thats why it's in OPS. For the most part,
the components where specific expertise from those areas is required,
anima just reuses and combines other IETF defined components anyhow.

It also drives me mad (ok, maybe i was mad in before) to hear that
experts refuse to participate in work where their input is welcome
because it has the wrong area label attached to it.

> authentication, authorization and key distribution. Just guessing.

I don't think we're developing new AAK mechanisms, but combining/applying
known components. 

Cheers
   Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 13 Aug 2015 14:51:34 -0700

How was 6lo work influenced/stalled by anything ANIMA did/does/ This is
the first i heard. Please explain.

Cheers
    Toerless

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Aug 2015 17:26:24 -0500

> the first i heard. Please explain.

Because people got the impression that the anima bootstrapping work
may also solve 6lo problem.
I had conversations with some people to that effect.

Of course there may be other factors involved.

Regards,

Behcet

---

From: Robert Cragie <[email-masked]>
Date: Thu, 13 Aug 2015 23:52:25 +0100

I have to say I sent an e-mail to anima-chairs on June 17 just after the
last call for volunteers requesting participation in the bootstrapping
design team and heard nothing. I even had to ping the anima-chairs e-mail
to make sure it was working. I am glad to hear that participation is still
welcome and will sign up to the e-mail list.

Robert

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Aug 2015 09:12:19 +0200

Hi Max,

> Please join us.
> Often, even of the people that signed up, only a few
> folks show. Honest, I’m not sure where your frustration is coming
> from since in my experience what every working group wants is active
> involvement!

I am unhappy about 3 things:

1) My co-worker did not become a design team member even though he
volunteered for it. He obviously didn't know that everyone can join the
calls at any time. (I didn't know that either.)

I am sure you don't understand that this can be frustrating since you
had 4 persons from Cisco on the design team.

2) I am unhappy if design teams have a long lifetime. While the design
team produced a draft that was presented to the working group it seems
that the design team work continues.

3) I am unhappy about the unclear scope of the ANIMA working group and
how it relates to other working groups.

For some time I thought that ANIMA does not focus on IoT but then I get
this impression again from reading your document abstract. If it also
focuses on IoT then what is the difference between ANIMA and ACE?

> Authentication, authorization and key distribution concepts are of
> course well established. What has not been clearly addressed is a
> clear framework for bootstrapping of the key infrastructures. 

You use manufacturer provided keys. This is a form of manually
provisioning information (even though it is done in a factory by a machine).

Ciao
Hannes

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Fri, 14 Aug 2015 05:24:40 -0700

> calls at any time. (I didn't know that either.)

This is what i sent after the call for volunteers had expired, we had 
taken the list of volunteers, asked for the design team mailing list,
created the wiki, described in the wiki its open, etc. pp.

I admit the message was terse, but i was trying to reduce annoying at least
when writing as a WG chair folks with too long emails which i am otherwise
often prone to produce. I guess in this case that was a mistake.

>From [email-masked] Thu Jun 18 19:33:35 2015                                                         
Date: Thu, 18 Jun 2015 19:33:35 -0700                                                                  
From: Toerless Eckert <[email-masked]>                                                               
To: [email-masked]                                                                                     
Subject: anima-bootstrap created                                                                       
Message-ID: <[email-masked]>                                                         
Mime-Version: 1.0                                                                                      
Content-Type: text/plain; charset=us-ascii                                                             
Content-Disposition: inline                                                                            
User-Agent: Mutt/1.4.2.2i                                                                              
Status: RO                                                                                             
Content-Length: 247                                                                                    
Lines: 7                                                                                               
                                                                                                       
Mailing list for anima-bootstrap has been created. Team members are subscribed.                         
If you wish to follow the work please feel free to subscribe.                                          
                                                                                                       
all pointers on the wiki: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap                          
                                                                                                       
Thanks                                                                                                 
  Sheng & Toerless

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Fri, 14 Aug 2015 06:14:07 -0700

Wrt to the other questions:

On Fri, Aug 14, 2015 at 09:12:19AM +0200, Hannes Tschofenig wrote:
> volunteered for it.

I am not aware that we rejected for anima-bootstrap anyone who
volunteered during the announced time window, can you remind me of the
name so i go back and check email archive to see what happened ?

> had 4 persons from Cisco on the design team.

The design team is as frustrated about this as you are. Please join.

> that the design team work continues.

I hope i can claim to still be new at the job as WG chair, but it seems
the word design team is associated with negatives that IMHO the way
we created and operate the design teams does not apply. The design teams
are just s meant to make it easier for participant to concentrate
on a well specified sub-part of the WG charter work they're interested to
participate in, with meetings, mailing list, wiki and a set of drafts
being worked on. And it only takes one more subscribe to use it.

> how it relates to other working groups.

It would be nice if you could be more specific: If its technical, please
have the discussion here on the groups list. If it's more about charter
text interpretation, interpretation of responsibilities or other bureaucracy
issues, i'd suggest to start discussing this between WG chairs and ADs
(as needed) and then we can report back to the WGs (unless WG members are
happy to have the lists technical to bureaucracy SNR to be low...).

> focuses on IoT then what is the difference between ANIMA and ACE?

How do you define IoT and "constrained environments" ? Are the concerns
for battery life time in an octo-core 2Ghz smartphone in scope for
ACE ? Is the ethernet in a train IoT ? Aka: lets just talk ANIMA vs. ACE:

>From just quick reading ACE charter, it seems to be about AAK in
bitrate/memory/cpu constrained devices by adding it to existing/evolving
lot bitrate/memory/cpu protocols.

ANIMA has components like network wide autonomic connectivity, bootstrap
and signaling as a framework for OAM and autonomic service agents in
scope. The type of networks we target are well-managed, which includes
SP, Enterprise, and IMHO networks that would like to call themselves IoT
but also are well-managed (aka: have an operating entity paid for the job).

ANIMA definitely needs to further refine the set of constraints to devices
and neetwork connectivity especially at the lower end into which we
think we can reuse the anima technologies without creating so much
additional workt hat we'd rather like split off solutions for those spaces.

> provisioning information (even though it is done in a factory by a machine).

I don't agree with that classification. Maybe you can explain how
you think manufacturer provided keys must imply "manual" provisioning steps.

Cheers
    Toerles

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Aug 2015 15:05:15 +0100

Hi Toerless,

In response to the specific request for more information. I received an
e-mail through anima mailing list from anima chairs on Jun 17:

'''
Hi folks,

If you had responded to our poll for the anima bootstrap team,
you should have gotten an invite email now. If not, then please
send us an email because i must have overlooked an email

Thanks!
  Sheng & Toerless
'''

I responded 8 hours later (put it down to timezone difference) to
[email-masked]:

'''
Apologies for not replying sooner. I am interested in participating in the
bootstrap design team.
'''

I heard nothing more. Perhaps I should have followed up but I was patient
for a while then it most likely went off my radar. So, not an outright
rejection as such, but could be taken as a tacit rejection :-)

Furthermore, I put in a polite request to consider changing the agenda for
IETF 93 to move the bootstrapping conversation to Thursday session as I
didn't think I would be in Prague in time for the first anima session on
Monday, where bootstrapping was being discussed. Again I heard nothing
which prompted me to ping [email-masked] to make sure my e-mail were
getting through. I subsequently received this refusal:

'''
Hi, Robert,

The WG would like to have most important work items, including bootstrap,
discussed on Monday morning session, in which more attendances are expected
with good spirits. It would also allow the authors/design teams to work
based on the feedback/discussion. The bootstrap design team would keep
working during the IETF work. You can catch up and work together with them.
They are expected to make a progress update on Thursday afternoon session.

Best regards,

Sheng
'''

I did get there in time for half of Monday's session but looks like I still
missed the bootstrapping conversation. I did have a brief chat with Max
who, to be fair, encouraged me to get more involved however I was not made
aware of any design team side meetings at IETF 93 and it appears nothing
was announced on anima-bootstrap list either.

I am not complaining but I have to agree with Hannes that the design team
came across as exclusive at the time. Anyway, I am happy to review the
latest draft and will provide feedback.

Robert

> name so i go back and check email archive to see what happened ?

<snip>

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Fri, 14 Aug 2015 07:17:11 -0700

Thanks Robert,

So, on the first mail thread i am not sure if i had simply already
sent the email i'd pasted in before saying folks can now simply subscribe
because the mailing list was created and therefore we provided no further
reply or if we did overlook to reply.

To avoid further miscommunication, i'd suggest to loud and clearly complain
about bad WG chairing on the list once they don't answer  to private emails
in what you perceive to be timely.

On the second mail i do stand to the reply we formulated to you.
We felt that if we had a slot on monday that would help continuing the work
through the week into thursday and that turned out to be true. 
If you would have said you might have made it to the second half of monday,
i'd changed the agenda order for monday to make bootstrap late. 

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Aug 2015 11:07:19 -0400

> focuses on IoT then what is the difference between ANIMA and ACE?

All of the work of ANIMA focuses on the part of that we agreed would be out
of scope for ACE!!!!

I felt we had to solve it (the bootstrap problem) in the non-constrained case
first, and I felt that some other group (I didn't know ANIMA would happen)
would get there while ACE could focus on the core protocol.

You speak of IoT as if it was one thing, and yet really, it's too imprecise
to be anything.   ACE is focused on *constrained* devices.

ANIMA is not chartered specifically to work on constrained devices, yet it
hasn't been made out of scope.

{personally, I have been left off many design teams}

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 14 Aug 2015 15:25:05 +0000

Hannes, 

> of the design teams is not possible.

I’m glad I approached you. It sounds like you’ve been frustrated by something for a while.

> had 4 persons from Cisco on the design team.

Clearly we have an interest. But in many calls it’s just been Michael Richardson and myself. 

> focuses on IoT then what is the difference between ANIMA and ACE?

As noted earlier on this thread the use of the term “constrained network” was a reference to the network limitations not ACE. I’ve taken an action to clarify that terminology overlap. I look forward to hearing your comments on the text after the abstract.

> provisioning information (even though it is done in a factory by a machine).

As an author of the IEEE 802.1AR document I clearly agree that the Initial Device IDentity (IDevID) is an important aspect of bootstrapping. The draft also goes into how the ‘imprint’ on the local network is secured. This is a harder problem to solve; and I reject “Trust On First Use” (TOFU) as it leaves a large security vulnerability unmitigated. 

I look forward to your input into the solutions for that problem, 

- max

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Aug 2015 17:30:08 +0100

Fair enough - I was just being transparent about communication. I actually
arrived earlier than I thought I would on Monday; I assumed based on my
travel schedule that I would miss all of Monday's session.

Robert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Aug 2015 13:28:16 +1200

Hopefully some misunderstandings and miscommunications have already
been resolved, but I want to add a couple of points below.

On 15/08/2015 03:07, Michael Richardson wrote:>
> All of the work of ANIMA focuses on the part of that we agreed would be out

In any case, the security bootstrap is only a small part of Anima.
(It's vital, because it's a pre-condition for everything else.)

> hasn't been made out of scope.

Intentionally. At least for the signaling protocol (which is another small
part of Anima), the scope is any autonomic device that might communicate
with other autonomic devices. In my mind that's anything from a lighting
controller for one floor of a building to a core router in a Tier 1 ISP.
(I wouldn't extend it down to individual smart light switches, but I
could be wrong.) And we're hoping for a uniform solution for the security
bootstrap across that range.

> {personally, I have been left off many design teams}

If there's anyone who thinks they were left off the Anima signaling
design team, please say so!

    Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Aug 2015 09:50:20 +0200

Hi Toerles,

some in the IoT community refer to RFC 7228 when they talk about
constrained devices and networks.

For example, in ACE we have several folks who are designing for a
solution that supports symmetric keys since public key cryptography is
too heavy for their envisioned class of device.

We developed many use cases to avoid having an abstract discussion.
Still, this is not entirely satisfactory (at least to me) and for that
reason several ACE participants worked on user stories to paint the
describe the bigger picture (including user interactions).

I haven't seen any detailed use cases / user stories from the ANIMA
working group to judge whether there are common aspects.

A further comment below:

> you think manufacturer provided keys must imply "manual" provisioning steps.

If you look at
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00 then you see
two models. The first model is widely used with many Bluetooth /
Bluetooth Smart devices where the devices comes without any keys
provisioned to the end customer. Then, there is a second model where
there are some keys provisioned to the device already. Based on this
initially provisioned key other keys are derived/distributed.

You seem to be focusing on model #2. In discussions, however, I often
get the impression that you (not you personally but folks in the group)
mix the properties with what is available with model #1.

In general, it is easy to derive/distribute new keys once you have
already gone through the effort of distributing the initial keys. This
is what many IETF protocols do.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Aug 2015 10:16:50 +0200

Hi Max,

> I’m glad I approached you. It sounds like you’ve been frustrated by

I believe you misinterpret frustration. I speak up when I see things
going wrong rather than being silent. You might call this behaviour
undiplomatic or, even worse, honest.

> 
> 
>> I am sure you don't understand that this can be frustrating since
>> you had 4 persons from Cisco on the design team.
> 

Oops. Not good (tm).

> As an author of the IEEE 802.1AR document I clearly agree that the
> Initial Device IDentity (IDevID) is an important aspect of
> bootstrapping. The draft also goes into how the ‘imprint’ on the
> local network is secured. This is a harder problem to solve; and I
> reject “Trust On First Use” (TOFU) as it leaves a large security
> vulnerability unmitigated.

This the area where terminology gets confusing

 0) You use the term 'device identity'.

I use the term device credential since the term 'identity' is so
confusing even in the field where humans (users) are involved. We have
established terminology for that purpose in RFC 6973.

A device credential consists of keying material, algorithms, and
parameters used by the device to authenticate itself to some other nodes
(potentially only a limited set of nodes).

Of course, with different credentials the details about what needs to be
provisioned varies.

 1) You seem to be using the term "bootstrapping" for provisioning keys
(and configuration parameters) in a factory.

I call this device credential provisioning.

 2) You use the term "imprinting" for the use of the manufacturer
provided keys to distribute further keying material/configuration
parameters.

I call this step device management since you typically want to send a
number of things to the device. The key exchange component is definitely
in there but there are also aspects of authorization / permission
management included as well.

Ciao
Hannes

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Mon, 17 Aug 2015 04:39:26 -0700

Inline.

> constrained devices and networks.

Yes, already on my toread list ;-)

> too heavy for their envisioned class of device.

Sure, we can break the autonomic architecture into individual block and
see if a subset would make it more attractive to specific constrained
environments. Whether we would call that subset with the substituted
elements (like pre-established shared keys) then still an ANIMA solution
or not is not a technical but IETF process question.

If there are pre-established keys, the first question to me is if (and if,
how) a customer would want to / need to derive customer specific keys If
it does want, and if that desired, then such a design would already be
a lot closer to the current ANIMA targets than without it.

Thats IMHO the end of the scope of building key infra". Then comes
GARP for neighbor discovery, ACP building, eg: IPsec encryption channels,
RPL routing. Depending on size all of this might be well feasible to
re-use (if you do have to do routing, RPL seems to be a very lightweight
option).

> working group to judge whether there are common aspects.

Agreed. We have stable connectivity as the key user-story for how to
use autonomic network infra WITHOUT any specifc ASAs (to communicate
with NOC/controllers). We have the addressing draft as ONE example
of autonomic agents achieving an objective. And then we had to stop because
anything beyond that is not part of current charter.

My gut feeling (and i'll have to discuss that with Sheng), is that we
may open the door for more user-story drafts when a) we prove we make
progress on charter items (which i think we do), and b) we get support from
other WGs (like ACE, eg: you) that such user stories can support proliferating
ANIMA charter item work better into other WGs. 

> provisioned to the end customer. 

Aka: pairing.

> Then, there is a second model where

Please elaoborate where you think there might be confusion.

The way you explain it, the framework seems to be:

  -> first key phase: 
       IDevID/MIC or pairing

  -> second key phase:
       deriving of customer/deployment keys.
       cutomer certificate or - customer shared key (constrained devices) 
       Q: is this phase desirable/feasible for the embedded devices yo
       consider ?
  
> is what many IETF protocols do.

Sure, but the problem that the "second key phase" in ANIMA and NETCONF
considers is the three party relationship between vendor, operator
and devices. Maybe even with trusted third parties. So i think thats
still new and not something we could ahve simply taken from existing
IETF protocols (the complete workflow, not the components).

Cheers
    Toerless

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Aug 2015 08:36:35 -0700

> hasn't been made out of scope.

We tried I think to focu on a concise set of achievable goals in the
charter. There is potential in thise space to either get wrapped around
the axel and make no progress, or attempt to boil the ocean. It was the
hope that the long gestation in the IRTF would leave us with the ability
to narrow the scope of work.

imho that doesn't mean it won't expand on recharter, or that we might
have done it wrong in the first place, but drawing the line where it is
respecting initial work items was intentional.

joel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 14:57:58 +0100

Apologies for the oversized distribution list.

Kathleen and I chatted about this, and indeed we had some
discussion of related topics at the saag meeting in Prague.

I'd like to see if there are a bunch of folks who are
interested in doing work in this space and if there's a
useful topic or set of topics on which work could be done and
that needs a bit more co-ordination between working groups.

I think that might well justify either a slot at the saag
session at IETF94 or even perhaps a non-WG-forming BoF
session if more time for discussion was needed. Minimally, Max
Pritkin has already offered to do a presentation for saag at
IETF94 presenting his view of the problem and solution spaces.
(Which I guess will generate discussion:-)

But first, I'd like to see who's interested in working on
this between now and IETF94. If you are interested, please
send me an offlist mail, preserving the subject line.

Depending on how many of those I get I may start a new list
or send around a few mails, but in any case I'll get back
to this list in a week or two and what, if anything, is
the plan.

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Aug 2015 11:05:43 -0400

> that needs a bit more co-ordination between working groups.

I'm not exactly sure I understand the question.

I think that the context is, wrt:
  draft-pritikin-anima-bootstrapping-keyinfra

which has just been adopted into ANIMA... so I'm not sure that we need
another space for discussion of the problem in a
non-constrained/non-challenged network space.

So, I think that you skipped the question part :-)

On the constrained-node/challenged network space, the 6band non-WG list
already exists.

There is a space of non-constrained-node with challenged networks
(think mains powered Raspberry PI with 15.4 interface)
and constrained-node on non-challenged network
(think battery powered class-2 device with ethernet) where some different
things might apply.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 16:09:51 +0100

> I'm not exactly sure I understand the question.

The question is whether or not folks believe that there
is some more or other work that needs to be done aside
from that already chartered. "Work" here could either be
co-ordination or might be new technical work that is not
currently chartered.

S.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Aug 2015 15:24:29 -0400

> co-ordination or might be new technical work that is not

My suggestion is that we make this a topic for the IoT directorate.
I think it's slightly too soon to know what is missing.

I think that content of certificates which are bound to names or
IP addressses (I had an ILOM example, where mac address or asset tag would
make sense) is something that would be nice.
This has some relevance to ANIMA, but is not directly in scope.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 21:18:08 +0100

> I think it's slightly too soon to know what is missing.

Hmm. It's not clear to me that we're only dealing with a thing
that's an IoT thing.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Aug 2015 08:38:44 +1200

The scope of devices that anima-bootstrapping considers is certainly not
limited to IoT. I assume that is also true for netconf-zerotouch.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Aug 2015 11:40:17 -0400

> Hmm. It's not clear to me that we're only dealing with a thing

I agree; but I don't know what other thing there is yet.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Aug 2015 10:55:06 -0500

Hi Steve,

> I agree; but I don't know what other thing there is yet.

When we say that it should be done in IoT directorate or in IoT WGs
not in security area, it is not out of disrespect to the security
area. We love security area, they are doing great things.

But the idea here is what needs to be done is using existing security
mechanisms/protocols to come up with a solution to an IoT problem. An
example is about using HIP-DEX

http://tools.ietf.org/id/draft-ohba-6lo-mle-hip-dex-00.txt which has
been accepted to become a WG draft in 6lo.

Regards,

Behcet

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 17:07:13 +0100

> area. We love security area, they are doing great things.

I don't much care in what area work gets done when work gets
done well. And I'm sure most sensible folks think the same.

> mechanisms/protocols to come up with a solution to an IoT problem. 

Again, it is not clear to me that everyone here is talking
about something that can fairly be described as an "IoT
problem."

Part of the reason I sent a mail is to see who's interested
in helping figure that out.

So far, btw, I have gotten zero off list answers. Which is
interesting given the amount of mail I've seen going by on
this topic.

> An

Ah, yet another solution. Isn't that an even better support
for the argument that we ought try get the folks proposing
such solutions in different bits of the IETF to chat with one
another and with other interested parties?

Cheers,
S.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 20 Aug 2015 16:41:09 +0000

Stephen: I'm interested in the discussion as well. But not only for IoT. 

Michael

> From: Anima [mailto:[email-masked]] On Behalf Of Behcet
> Sarikaya
> Sent: 19 August 2015 17:55
> To: Michael Richardson
> Cc: Brian Haberman; [email-masked]; Max Pritikin (pritikin);
> Toerless Eckert (eckert); joel jaeggli; Kathleen Moriarty; Sheng Jiang;
> Hannes Tschofenig; anima; Stephen Farrell
> Subject: Re: [Anima] who's interested?
> 
> Hi Steve,
> 
> 
> When we say that it should be done in IoT directorate or in IoT WGs not in
> security area, it is not out of disrespect to the security area. We love
> security area, they are doing great things.
> 
> http://tools.ietf.org/id/draft-ohba-6lo-mle-hip-dex-00.txt which has been
> accepted to become a WG draft in 6lo.
> 
> Regards,
> 
> Behcet
> 
> 
> > --

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Aug 2015 11:45:11 -0500

> Stephen: I'm interested in the discussion as well. But not only for IoT.

Then not in anima.

Behcet

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 21 Aug 2015 07:19:00 +0000

Can you please clarify what you mean by "not in anima"? I don't understand it... 

Michael

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: 20 August 2015 18:45
> To: Michael Behringer (mbehring)
> Cc: Michael Richardson; Brian Haberman; [email-masked]; Max
> Pritikin (pritikin); Toerless Eckert (eckert); joel jaeggli; Kathleen Moriarty;
> Sheng Jiang; Hannes Tschofenig; anima; Stephen Farrell
> >> Cc: Brian Haberman; [email-masked]; Max Pritikin
> >> (pritikin); Toerless Eckert (eckert); joel jaeggli; Kathleen
> >> Moriarty; Sheng Jiang; Hannes Tschofenig; anima; Stephen Farrell