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

From: [email-masked]
Date: Fri, 13 Oct 2017 10:33:00 -0700

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-08.txt
	Pages           : 59
	Date            : 2017-10-13

Abstract:
   This document specifies automated bootstrapping of a remote secure
   key infrastructure (BRSKI) using vendor installed X.509 certificate,
   in combination with a vendor'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-08
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-08

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

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/

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Oct 2017 08:07:28 +1300

Hi,

I will review this carefully soon, but I already noticed one nit.
The IANA Considerations needs to include registration of the two
GRASP objectives. There's a model for that at
https://tools.ietf.org/html/draft-ietf-anima-prefix-management-05#section-8
and the registry even exists:
https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names

Regards
   Brian

On 14/10/2017 06:33, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 14 Oct 2017 10:10:04 -0400

> https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names

Thanks for pointing this out!
I'll add that in today.
We also left our MIME-type registration in (empty)... it should have been
removed.

We will spin an -09 before the cut-off.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Oct 2017 16:19:09 +1300

Hi,

Unfortunately this is still a little broken around both GRASP objectives,
in a way that needs to be fixed:

> 4.1.1.  Proxy Grasp announcements
> 
>    A proxy uses the GRASP M_FLOOD mechanism to announce itself.  The
>    pledge SHOULD listen for messages of these form.  This announcement
>    can be within the same message as the ACP announcement detailed in
>    [I-D.ietf-anima-autonomic-control-plane].
> 
> 
>     proxy-objective = ["AN_Proxy", [ O_IPv6_LOCATOR, ipv6-address,
>     transport-proto, port-number ] ]

That's not valid syntax for an objective. Also, in the Flood message you
have the option of associating a locator directly with the flooded
objective, as part of the basic message format. My suggestion:

The objective is defined in fragmentary CDDL as:

 registrar-objective = ["AN_Proxy", objective-flags, loop-count, null]

 objective-flags = ; as in the GRASP specification
 loop-count =  1   ; restricted to link-local use

 The objective-flags field is set to indicate synchronization.

 The loop-count is set to 1 to limit the scope of flooding
 to the local link.

 The value field is set to a null value.

In the GRASP Flood message, an IPv6 locator option is
associated with the objective as described in Section 2.8.11
of [I-D.ietf-anima-grasp]. The locator format is
 [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number]
where
>     ipv6-address       - the v6 LL of the proxy
>     transport-proto    - 6, for TCP 17 for UDP
>     port-number        - the TCP or UDP port number to find the proxy

Then there are more problems with this:

> 4.4.  Proxy discovery of Registrar
> 
>    The Registrar SHOULD announce itself so that proxies can find it and
>    determine what kind of connections can be terminated.
> 
>    When the Registrar joins an Autonomic Control Plane
>    ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP
>    ([I-D.ietf-anima-grasp]) M_NEG_SYN message.

There is no such thing as M_NEG_SYN. Anyway this is a backwards
way of describing things. I think you should start with something
like:

When the Registrar joins an Autonomic Control Plane
[I-D.ietf-anima-autonomic-control-plane] it MUST be
ready to support the GRASP [I-D.ietf-anima-grasp]
object "AN_registrar" defined below. This is an
objective that supports only discovery; it does not
support synchronization or negotiation. When a proxy
sends a GRASP Discovery (M_DISCOVERY) message seeking
this objective, the Registrar SHOULD respond with a
GRASP Discovery Response (M_RESPONSE) message including
relevant locators as described below.

The objective is defined in fragmentary CDDL as:

 registrar-objective = ["AN_join_registrar", objective-flags,
                            loop-count, null]

 objective-flags = ; as in the GRASP specification
 loop-count =      ; as in the GRASP specification

 The objective-flags field is set to indicate discovery.

 The loop-count is set to a suitable value to limit the scope of
 discovery.  A suggested default value is 6.

 The value field is set to a null value.

>    The registrar responds to discovery messages from the proxy (or GRASP
>    caches between them) as follows: (XXX changed from M_DISCOVERY)
> 
>     objective         = ["AN_registrar", F_DISC, 255 ]

Why 255? Do you expect networks to be that big? Discovery
loops will be detected anyway, but I think a much more conservative
value is appropriate.

>     discovery-message = [M_NEG_SYN, session-id, initiator, objective]

Nope. M_DISCOVERY is needed. But anyway, what is the point of
replicating bog-standard GRASP here? Possibly in an appendix, but not
main text.

>    Figure 6: Registrar Discovery
> 
>    The response from the registrar (or cache) will be a M_RESPONSE with
>    the following parameters:
> 
>     response-message = [M_RESPONSE, session-id, initiator, ttl,
>     (+locator-option // divert-option), ?objective)]

Here an example is more helpful than more cut-and-paste from
GRASP.

>     initiator = ACP address of Registrar

Wrong, another argument against redundancy.
See https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.8.5

>     locator1  = [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443]
>     locator2  = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]

OK. This is fine in terms of GRASP syntax, although it's
a slightly special case of implying semantics within the
locators. The only problem is mine: my prototype code can't
do this without enhancement. I'd suggest giving the example
a bit more precisely, something like:

An example M_RESPONSE packet, following the GRASP syntax,
could be as follows:

 [M_RESPONSE, session-id, initiator, ttl,
 [O_IPv6_LOCATOR, fd45:1345::6789, 6,  443],
 [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683],
 [O_IPv6_LOCATOR, fe80::1234, 41, null]]

Also, technically, using proto = 41 extends the formal GRASP syntax.
We could let that slide, holding it in reserve for GRASP 2.0, or
we could at least note that it's an extension.
  
Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Oct 2017 12:59:24 +1300

Just an update on this.

1) I missed a couple of inconsistencies below, noted in line.
2) I updated the GRASP prototype to support the previously
missing features used below. I update my demo ASAs for the
pledge, proxy and registrar roles. They work.

I need to do quite a bit more testing before pushing the
updated code to GitHub, but basically I think the GRASP
aspect of BRSKI is good to go.

>  registrar-objective = ["AN_Proxy", objective-flags, loop-count, null]

proxy-objective = ["AN_Proxy", objective-flags, loop-count, null]

>  registrar-objective = ["AN_join_registrar", objective-flags,

 registrar-objective = ["AN_registrar", objective-flags,
                            loop-count, null]

   Brian

---

From: peter van der Stok <[email-masked]>
Date: Tue, 24 Oct 2017 12:14:37 +0200

Hi keyinfra authors,

Glad to see that so much progress has been made since the last version.

I had problems with understanding some pieces of text. See below.

In the terminology section, the “Join proxy” is introduced. The term is 
almost never used but the term “circuit proxy” is used. However, in 
section 4 it is mentioned that join proxy can be a circuit proxy or an 
IP-in-IP proxy. Therefore, I think that circuit proxy should be replaced 
by Join proxy, at least in the figures and the accompanying text.

In section 1.3, the text from “The bootstrapping process…. such 
techniques when defined” is confusing in my opinion. It makes the 
purpose of the draft ambiguous. I recommend removing that text and 
replacing it with shorter text, like:

“Possible constrained devices are the Join Proxy and the Pledge. Draft 
vanderstok-ace-est-coaps specifies how TLS/HTTP is replaced by 
DTLS/CoAP. Draft Richardson-anima-state-router discusses different join 
proxy implementations”.

The above text allows removal of last 2 paragraph of section 4 before 
section 4.1; and removal of section 4.2.

First paragraph of section 5 is difficult to parse. What is 
configuration in this context?

End of section 5.1, what is “security paranoia”?

Section 5.2
Do the two media types refer to two different requests? Why and which 
ones?

Section 5.4
Only one request media type? Why?
Voucher signature consistency, why not refer to 6402 instead of 7030?

Section 5.5 2nd paragraph
"If the join operation is successful", s/join operation/voucher request/

Section 5.6, paragraph 4
“The client HTTP POSTs the following…” is the client the pledge? What is 
the following?

End of section 5.6 what is Specification Required?

Hope this helps,

Peter