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

["Michael Behringer (mbehring)" <[e-mail]>]

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:[e-mail]] On
> Behalf Of Max Pritikin (pritikin)
> Sent: 24 June 2015 18:39
> To: [e-mail]
> 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.
> 
> 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.
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap