[Anima] Call for agenda ANIMA @ IETF 104， Prague

[Sheng Jiang]

Hi, all anima,



We have been allocated a session of 2-hour for the ANIMA WG meeting for 
IETF-104 (Prague) - Tuesday afternoon session I. We are now starting to collect 
agenda items for the session. Please send your request for agenda by March 
14th, Thursday.



For this coming meeting, we would like to discuss potential future ANIMA works. 
As normal, the priority among these non-charter work items would be: these that 
have active discussion in mail list, then these have submitted drafts, and 
topics without drafts.



Please send us (anima-chairs at ietf.org) requests for time 
slot by March 14th, Thursday and include:



Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):



More details about the IETF 104, Prague can be found at:



https://www.ietf.org/how/meetings/104/



Again, presenters and draft authors please invoke active discussions in the 
ANIMA list. Mail list is a very good place to discuss and reach consensus on 
technical issues.



Best regards,



Toerless & Sheng
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] $transport-proto in BRSKI

[Brian E Carpenter]

Sigh. I was wrong. The $ sign is legal CDDL:

> Per convention, CDDL extension points are marked with a leading
> dollar sign (types) or two leading dollar signs (groups).
[draft-ietf-cbor-cddl-07]

It isn't *required* but it shows that the item in question is expected
to be extended in future.

So either include it or don't, but at the moment there's a nit in
your text: the syntax says
> transport-proto /= IPPROTO_TCP
but the following paragraph says:
> The $transport-proto above indicates the method...

Otherwise, fwiw I'm happy with bootstrapping-keyinfra-19.

   Brian

On 02-Mar-19 11:43, Brian E Carpenter wrote:
> On 02-Mar-19 10:34, Michael Richardson wrote:
>>
>> Brian, we have CDDL in BRSKI:
>>
>> ipv6-address  = the v6 LL of the Proxy
>> $transport-proto /= IPPROTO_TCP   ; note this can be any value from the
>>  ; IANA protocol registry, as per
>>  ; [GRASP] section 2.9.5.1, note 3.
>>
>> and we don't know why we have a $ on transport-proto.
>> Maybe it's a typo.
> 
> I think it's a typo. As additional evidence, the comment is one space
> too far to the right. Editorial fix!
> 
> Brian
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-19.txt

[Michael Richardson]

internet-dra...@ietf.org wrote:
> Title   : Bootstrapping Remote Secure Key Infrastructures (BRSKI)
> Authors : Max Pritikin
> Michael C. Richardson
> Michael H. Behringer
> Steinthor Bjarnason
> Kent Watsen
> Filename: draft-ietf-anima-bootstrapping-keyinfra-19.txt


> A diff from the previous version is available at:
> 
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-19

While the 18 to 19 diff is probably of interest to those who have most
recently reviewed the document a diff against version 16 is probably most
useful to those who last read during the WGLC.
   
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-16=draft-ietf-anima-bootstrapping-keyinfra-19

We believe that we dealt with all of the review comments raised during WGLC
and reviews, and we are ready to proceed to the IESG.

The reviews are at:
secdir:  
https://mailarchive.ietf.org/arch/browse/anima/?gbt=1=NGsR9xGIL7k_j06FXkI_GBeJZMo
genart:  https://mailarchive.ietf.org/arch/msg/anima/iVg7MRMdBQBVFA5VFiksYFHchBU
iotdir:  https://mailarchive.ietf.org/arch/msg/anima/1N7AR8hqu2oIWuTFFd9OQOab8SI

The issues that were opened are at:

https://github.com/anima-wg/anima-bootstrap/issues?utf8=%E2%9C%93=is%3Aissue+

In most cases, we have used the #issue notation that github (and trac, and..)
supports in order to link the diffs that we made to the issue number.

Major changes:
  1) new section 5.3: Registrar Authorization of Pledge
  2) new section 3.1: Nonceless Voucher Requests
  3) new section 8: Applicability to the Autonomic Control Plane (plus
  other details in the document)
  4) new section 9: Privacy Considerations:

   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  60
 9.1.  MASA audit log  . . . . . . . . . . . . . . . . . . . . .  60
 9.2.  What BRSKI-MASA reveals to the manufacturer . . . . . . .  61
 9.3.  Manufacturers and Used or Stolen Equipment  . . . . . . .  63
 9.4.  Manufacturers and Grey market equipment . . . . . . . . .  64
 9.5.  Some mitigations for meddling by manufacturers  . . . . .  64

  5) additions to Security Considerations:
   10.1.  DoS against MASA . . . . . . . . . . . . . . . . . . . .  66
   10.4.  Manufacturer Maintainance of trust anchors . . . . . . .  69


Issues that we have not dealt with using text.
If you want to re-open the ticket, please go ahead, but please also bring
some text that is in-scope for ANIMA ACP:

https://github.com/anima-wg/anima-bootstrap/issues/112
add discussion of each major mode of the protocol #112

* We are focused on the proximity assertion that we think is the most
  secure version of the protocol.  We have described this in detail.
* We have expanded discussion about the nonceless (offline) mechanism
  that vouchers can use.
* There are some additional ways the protocol can be used, but we
  feel that they should be dealt with in other documents.

https://github.com/anima-wg/anima-bootstrap/issues/110
gen art issue #22: permanent vouchers... feature or bug. explain further
* we think that further discussion about this is needed.
* this is a "major mode" that belongs in an operational document.


https://github.com/anima-wg/anima-bootstrap/issues/79
security review issue 6: ship and forget not supported
* a new major mode, which we do not support, and we don't know how.
* it is out of scope for ANIMA.
* we did add text that existing mechanisms (craft consoles) continue
  to be available.

https://github.com/anima-wg/anima-bootstrap/issues/82
security review issue 7: what if MASA always issues vouchers
* "It is mentioned in
   section 6.4, which recommend that manufacturers should not do that. 
What
   are the consequences if they still do?"
-> it's hard to say what will happen if implementers violate the 
protocol.
   Some other set of assumptions need to be made about how many
   violations the other components do.

https://github.com/anima-wg/anima-bootstrap/issues/83
security review issue 8: device refuses to be imprinted
* we think the answer is that the customer ships it back.
* we provide telemetry as to success, but if the device is broken,
  it's broken.

https://github.com/anima-wg/anima-bootstrap/issues/86
security review issue 13: individualization
* the issue asks about the per-device step in manufacturing.
*** we think that this is out-of-scope for ANI use ***
* we considered talking about technology like:
  https://en.wikipedia.org/wiki/Physical_unclonable_function
  but ultimately, that's just another way to do TPM, so
  skirts the question.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT 

[Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-19.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and 
Approach WG of the IETF.

Title   : Bootstrapping Remote Secure Key Infrastructures 
(BRSKI)
Authors : Max Pritikin
  Michael C. Richardson
  Michael H. Behringer
  Steinthor Bjarnason
  Kent Watsen
Filename: draft-ietf-anima-bootstrapping-keyinfra-19.txt
Pages   : 101
Date: 2019-03-07

Abstract:
   This document specifies automated bootstrapping of an Autonomic
   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
   is created using manufacturer installed X.509 certificate, in
   combination with a manufacturer's authorizing service, both online
   and offline.  Bootstrapping a new device can occur using a routable
   address and a cloud service, or using only link-local connectivity,
   or on limited/disconnected networks.  Support for lower security
   models, including devices with minimal identity, is described for
   legacy reasons but not encouraged.  Bootstrapping is complete when
   the cryptographic identity of the new key infrastructure is
   successfully deployed to the device but the established secure
   connection can be used to deploy a locally issued certificate to the
   device as well.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-19
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-19


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima