Subject: [Anima-bootstrap] Meeting notes from 6/24

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 24 Jun 2015 16:38:35 +0000

Today we walked through the bootstrapping document ToC and discussed current active work areas and solicited suggestions for additional areas. This is of course on top of the general guidance of open discussion on this list and active feedback from subgroup members to provide document text suggestions. 

What follows is the current ether-pad including active notes from todays conversation.

- max

IETF 93 IMPORTANT DATES
	• 2015-07-06 (Monday) submission cutoff (e.g. our doc needs to be done and done by then)

https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-01

Table of Contents

   1.  Introduction [only 1st para]  . . . . . . . . . . . . . . . . . . . . . . . .   3  (MCR)
     1.1.  Problem Statement [other para's of the intro]
     [AI] nail down the device types that are in scope
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
        define pledge and imprint part
        define authorization and authentication (rfc4949)
        Include architectural overview terms/entities (e.g. Factory/Factory CA)
        map names: new entity, proxy, registrar to EAP (supplicant, authenticator, authentication server)
	•         glossary to define how we're using authC/authZ (not in intro)
   2.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   4        (MAX)
   limit to registrar/new-entity interaction (via proxy)
   this describes a message based protocol that runs over another (unsecured) transport, TBD by specific situation.

   3.  Operational Overview  . . . . . . . . . . . . . . . . . . . .   7
   MCR: This is actually the "domain operator point of view" ... the story from the operators perspective
   "this is the initial state of the system and how it was instantiated"
   MCR: this might be too soon to detail how to admin the system, first they want to know what the system does for them
   Tesla doesn't start by saying "first you need to build a chain of electric 'gas' stations"
   This a good argument for moving this later in the document
     3.1.  Instantiating the Domain Certification Authority  . . . .   7
     3.2.  Instantiating the Registrar . . . . . . . . . . . . . . .   7
     This could be an ASA [autonomic service agent] that can be the registrar
     The automated registrar selection is in the scope of signaling document
     The proxy needs to be aware of the selection!
     3.3.  Accepting New Entities  . . . . . . . . . . . . . . . . .   8
     
     For each New Entity the Registrar is informed *of* the unique identifier
     
     3.4.  Automatic Enrolment of Devices  . . . . . . . . . . . . .   9
     3.5.  Operating the Network . . . . . . . . . . . . . . . . . .   9

   4.  Functional Overview . . . . . . . . . . . . . . . . . . . . .   9
Make this a section of "overall flow"
promote the "behavior of" subsections to 5, 6, 7 etc

     4.1.  Behavior of a new entity  . . . . . . . . . . . . . . . .  10
     "Device's Point of View"
     Perhaps expand to show the state machine for the Device
       4.1.1.  Proxy Discovery . . . . . . . . . . . . . . . . . . .  11
       discovery is all that should be covered here. the communications between the proxy and the registrar
       should be discussed in s4.2
       4.1.2.  Receiving and accepting the Domain Identity . . . . .  12
       Should there be a state where the device will no longer "returns to discovery state"? 
         MAX: "no!" :)
         MCR: maybe[?] (MAY) 
         This is the question of "can a device prevent itself from being stolen or trojan'd"? 
         Is there an in scope use case for this?
         Open for continued conversation.
       4.1.3.  Enrollment  . . . . . . . . . . . . . . . . . . . . .  13
       Allow direct entry into this state to support non-zero touch
       Support console for RFC7030 s4.1.1 'Bootstrap Distribution of CA Certificates' with "engage a human user"
       MCR would like to specify the exact format of the "fingerprint" 
       MAX use the URL bootstrapping model
       Discussion of IDevID displayed in browser; how to deal with this? Is it in scope for this document? Is this a 'console port' model?
       4.1.4.  After Enrollment  . . . . . . . . . . . . . . . . . .  13
       maintain brightline between enrollment and configuration
       but accept that for optimization some configuration information might be delivered during enrollment
       clients and servers SHOULD support TLS session resumption. allowing for efficient handoff across this line
       with appropriate security considerations to be addressed: for example a constrained device might be better 
       served by the server's sharing the 
       resumption token rather than being forced to use poor entropy. this is worth discussion. perhaps this new 
       session is a DTLS COAP on a different port.  
       perhaps this allows the s4.1.1 proxy communications to now be transitioned to a direct connection
       
     4.2.  Behavior of a proxy . . . . . . . . . . . . . . . . . . .  13
     s4.1.1 hypothesizes existing protocol for proxy<->registrar communications.
     (s4.1.1 is about device discovery of proxy. toerless points out that maybe we collect proxy discussion into one section)
     AI: we need to pick one here as normative
     toerless: perhaps just choose a model or models (e.g. EAP) but allow an alternate anima doc to be more prescriptive
     until we have more clarity here we'll have to structure this into its own document section and provide flexibility
     AI: include text about what requirements are being made on the transport protocol such that potential protocols can
     be evaluated. [[this is probably a good 1st step for selecting a normative method anyway]]. Sounds like this is the first step.
     [[this is also a good to understand the device types to be supported. but recall that the device's that are in scope will feedback requirements here. so this will be a give/take discussion]]
     AI: <some author> to pick one and argue for it. "proof by confrontation"
     EAP-TLS is discussed strongly in the 6/24 call with awareness that constrained devices might be troubled (PANA also)
     MCR: worried about what this protocol "lives in"; argues that we need to be able to support the EAP model but not necessarily EAP-TLS
     We need to indicate how the registrar is discovered.
     The outward requirement from bootstrap -> signaling, is that the protocol should be architectually capable of working with EAP-like protocols. (if not EAP itself)
     (IKEv2, PANA, 1x, TLS, DHCP all likely support the model)
     
     4.3.  Behavior of the Registrar . . . . . . . . . . . . . . . .  14
       4.3.1.  Authenticating the Device . . . . . . . . . . . . . .  14
       Discussion of IDevID displayed in browser; how to deal with this? Is it in scope for this document?
       4.3.2.  Accepting the Entity  . . . . . . . . . . . . . . . .  14
       4.3.3.  Claiming the new entity . . . . . . . . . . . . . . .  15
     4.4.  Behavior of the MASA Service  . . . . . . . . . . . . . .  15
       4.4.1.  Issue Authorization Token and Log the event . . . . .  16
       4.4.2.  Retrieve Audit Entries from Log . . . . . . . . . . .  16
     4.5.  Leveraging the new key infrastructure / next steps  . . .  16
       4.5.1.  Network boundaries  . . . . . . . . . . . . . . . . .  16

   5.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  17
     5.1.  EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . .  18
     5.2.  Request bootstrap token . . . . . . . . . . . . . . . . .  18
     5.3.  Request MASA authorization token  . . . . . . . . . . . .  18
     5.4.  Request MASA authorization log  . . . . . . . . . . . . .  19
   6.  Reduced security operational modes  . . . . . . . . . . . . .  20
   need to clarify why each reduced security mode might be necessary
   [additional scenario for #5: not uncommon to resale equipement: need to rekey it all]
   
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   [THREAT: can an attacker regain control using a nonceless masa token for some 
   [short period of time before returning the device to the current owner; is there
   [a way to 'rekey' the device to stop this? re: IDevID it?]

     7.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  22

* Virtual Factory
     move text to deal with virtual machines here (from architectural overview)
     this is related to the "non-802.1AR" discussion
     here we indicate the 'blob' of data that can be inserted instead of
     the IDevID, which is used for client authentication

   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
     
     Perhaps a reference toward a doc (TCG? IEEE?) about best practices for IDevID insertion
     (e.g. how not to keep the CA root key in manufacturing facility) 

=======
For next week (6/4):
    AI: michael to do section #1 (6/11 - still open)
    AI: max to do section #2 (6/11 - still open) 
    agenda plan: 6stich overlap discussion [[completed 6/4]]
    continued Table of Contents driven walk through

https://mailarchive.ietf.org/arch/msg/anima-signaling/oJzM0fuaniZ_PxO27Bcg_la4MdU - email summary.

======
6band: 

The scope of this mailing list is mainly to address threat analysis of 6lo networks, secure bootstrapping and evaluating solutions for constrained node devices in constrained-L2-access technology networks. The problem scope is limited to secure network access/bootstrapping of the 6lo nodes. This interest group may also discuss interfaces between network layer and Application layer for sharing security association. The scope of this work does not include Application level security work . The goal is to identify existing candidate technologies or needs for new development of bootstrapping mechanisms.
OUR RESPONSE: There is no clear use case discussion ("no clear constraints"). 
For example the anima charter paragraph 7 states: "The ANIMA working group focuses on professionally-managed networks" and provides examples. Can we see a similar statement from 6band. 
Devices that are professionally managed would be in scope of anima --- but since anima bootstrapping is intended to provide a zero-touch solution we encourage continued conversation and the possibility of re-using the work in whatever the 6band scope turns out to be.
PLAN: wait out until their mailing list gets going and then approach them with this discussion. The three of us have subscribed to the 6band mailing list.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 24 Jun 2015 16:50:04 +0000

Thanks for sharing. 

A high level question up front: When we wrote draft-pritikin, we started from the premise that the draft should describe the most secure model as a reference, then in section 6, explains alternative models which may be less secure, but more useful for certain environments. Are we still sticking to this philosophy "describe best possible, and separately less secure alternatives"? (I hope so ;-) 

I can review section 3, if that is considered useful. I understand that things may change, but it doesn't harm to document current understanding. 

Michael

> -----Original Message-----
> From: Anima-bootstrap [mailto:[email-masked]] On
> Behalf Of Max Pritikin (pritikin)
> Sent: 24 June 2015 18:39
> To: [email-masked]
> Subject: [Anima-bootstrap] Meeting notes from 6/24
> 
> 
> Today we walked through the bootstrapping document ToC and discussed
> current active work areas and solicited suggestions for additional areas. This
> is of course on top of the general guidance of open discussion on this list
> and active feedback from subgroup members to provide document text
> suggestions.
> 
> 	* 2015-07-06 (Monday) submission cutoff (e.g. our doc needs to be
> done and done by then)
> 
> 
> 
> 	*         glossary to define how we're using authC/authZ (not in intro)
>    this describes a message based protocol that runs over another
> (unsecured) transport, TBD by specific situation.
> 
> 
>    MCR: this might be too soon to detail how to admin the system, first they
> want to know what the system does for them
>        Discussion of IDevID displayed in browser; how to deal with this? Is it in
> scope for this document? Is this a 'console port' model?
>      (s4.1.1 is about device discovery of proxy. toerless points out that maybe
> we collect proxy discussion into one section)
>      toerless: perhaps just choose a model or models (e.g. EAP) but allow an
> alternate anima doc to be more prescriptive
>      AI: include text about what requirements are being made on the
> transport protocol such that potential protocols can
>      be evaluated. [[this is probably a good 1st step for selecting a normative
> method anyway]]. Sounds like this is the first step.
>      [[this is also a good to understand the device types to be supported. but
> recall that the device's that are in scope will feedback requirements here.
> so this will be a give/take discussion]]
>      EAP-TLS is discussed strongly in the 6/24 call with awareness that
> constrained devices might be troubled (PANA also)
>      MCR: worried about what this protocol "lives in"; argues that we need to
> be able to support the EAP model but not necessarily EAP-TLS
>      The outward requirement from bootstrap -> signaling, is that the protocol
> should be architectually capable of working with EAP-like protocols. (if not
> EAP itself)
> https://mailarchive.ietf.org/arch/msg/anima-
> signaling/oJzM0fuaniZ_PxO27Bcg_la4MdU - email summary.
> 
> ======
> 6band:
> 
> The scope of this mailing list is mainly to address threat analysis of 6lo
> networks, secure bootstrapping and evaluating solutions for constrained
> node devices in constrained-L2-access technology networks. The problem
> scope is limited to secure network access/bootstrapping of the 6lo nodes.
> This interest group may also discuss interfaces between network layer and
> Application layer for sharing security association. The scope of this work
> does not include Application level security work . The goal is to identify
> existing candidate technologies or needs for new development of
> bootstrapping mechanisms.
> For example the anima charter paragraph 7 states: "The ANIMA working
> group focuses on professionally-managed networks" and provides
> examples. Can we see a similar statement from 6band.
> Devices that are professionally managed would be in scope of anima --- but
> since anima bootstrapping is intended to provide a zero-touch solution we
> encourage continued conversation and the possibility of re-using the work
> in whatever the 6band scope turns out to be.
> PLAN: wait out until their mailing list gets going and then approach them
> with this discussion. The three of us have subscribed to the 6band mailing
> list.
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 24 Jun 2015 17:00:57 +0000

> A high level question up front: When we wrote draft-pritikin, we started from the premise that the draft should describe the most secure model as a reference, then in section 6, explains alternativ…

I believe this is still the plan. Section6 includes the discussion of “Reduced security operational modes” and I haven’t seen pushback that these should be buried within the other sections. 

There is plenty of discussion about the transport protocol operational modes (and requirements upon) as captured in the meeting notes around sections s4.1.1 and s4.2. Although currently discussed as a “model” or “transport” with limited effect on the protocol security details I brought up today the point that various models for the proxy impact the security threat modeling and might have impacts on section6. 

> I can review section 3, if that is considered useful. I understand that things may change, but it doesn't harm to document current understanding. 

Current changes for section3 are mostly planned to be the addition of distinct state machines for each element. If you focus your review on what states are implied or not-implied then your feedback would be most helpful! 

- max

>> scope for this document?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jun 2015 14:09:41 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > A high level question up front: When we wrote draft-pritikin, we
    > started from the premise that the draft should describe the most secure
    > model as a reference, then in section 6, explains alternative models
    > which may be less secure, but more useful for certain environments. Are
    > we still sticking to this philosophy "describe best possible, and
    > separately less secure alternatives"? (I hope so ;-)

I think that this is the best way.

I wanted to describe the less secure ways as "mitigations" --- things you
do because you are unable to do a secure(r) thing.  Brian Carpenter did not
like that term, and I'm still trying to understand why.

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 26 Jun 2015 07:03:19 +0000

> Behalf Of Michael Richardson
> Sent: 25 June 2015 20:10
> Subject: Re: [Anima-bootstrap] Meeting notes from 6/24
> 
> 

Good - we're on the same page. 
 
> I wanted to describe the less secure ways as "mitigations" --- things you do
> because you are unable to do a secure(r) thing.  Brian Carpenter did not like
> that term, and I'm still trying to understand why.

That term doesn't sound right to me either. From dictionary.reference.com: 

1. the act of mitigating, or lessening the force or intensity of something unpleasant, as wrath, pain, grief, or extreme circumstances: 
Social support is the most important factor in the mitigation of stress among adolescents.

2. the act of making a condition or consequence less severe: 
the mitigation of a punishment.

3. the process of becoming milder, gentler, or less severe. 

4. a mitigating circumstance, event, or consequence.

bottom line: to me "mitigation" is a positive thing (see definition 3). It's making something bad feel less bad. I think if you take any of the less secure options, you SHOULD feel bad :-) 

Call it "less secure options" - that's what it is. 

Michael