Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson]

Comments on section 5, 6 and 7.



> --
> Section 5.4

> a) See comment for section 2.4.4  for where i think the first paragraph
> description should be.

There isn't a 2.4.4, so I'm not really sure I understand what you want me to do.

> (aka: make this paragrap a summary of what the MASA interface is,
> mentioning both requestvoucher and requestauditlog and move to 2.4.4).

> b) The paragraph is difficult to parse and has IMHO wrong pieces.
> - What does "simplicity" mean ?

I think it's mostly content-free.
It makes the text simpler to not have explain all of EST here.


> - "the Registrar is not required to make use of any other EST
> functionality when communicating with the MASA service"... what does
> that mean.. ? Not required = but could optionally do it ?

I guess, we probably gained nothing by saying it was EST rather than a
straight RESTful web service.

I've opened issue,
 https://github.com/anima-wg/anima-bootstrap/issues/53

I think that's what you are asking here.

> If a shared code basis is used for MASA and other EST/BRSKI defined
> service roles (Domain Registrar, CA,...), the MASA service MUST
> properly reject any EST functionality requests it does not wish to
> service; a requirement that holds for any REST interface.

For me there is/was no code sharing.

> "when the Registrar is expected to be offline" ->
> "when the Registrar is expected to be unable to connect to a MASA"

> Offline can be confusing because it does not explain who is not able to
> talk with whom, and i think in both cases two of the three are still
> expected to talk with each other (or at least that part does not
> matter).

> I am still confused about the "Pledge is unable to connect to the
> Registrar" case.  Is this a case where BRSKI-EST does not happen but
> something else (e.g.: sneakernet) between Registrar and Plege ? Please
> add a sentence explaining what this case means.


https://github.com/anima-wg/anima-bootstrap/issues/54

> f) "since the registrar is not known to the MASA server in advance"

> Given how the HTTPS connection requires authentication, there is some
> knowledge about the registrar from that, so the above sentence is
> confusing. Whats the
> correct statement to be made here thats takes the existance of the HTTPS
> authentication of the Registrar to the MASA into account ?

https://github.com/anima-wg/anima-bootstrap/issues/55


> g) Registrar revocation consistency:

> Maybe change the lead in in this section to something like: "If the 
Registrar
> uses a CA known to the MASA to make certificate revocation information
> available
> to the MASA, MASA SHOULD check ... of the Registrar Certificate. MASA MAY
> limit service to Registrar where this applies to provide owners
> protection against impacted registrar (e.g.: stolen).

okay, clarified text a bunch of text, and went back to 2.6.1 and changed
some text to put a few additional constrained on time.   I also turned the
point form into sections because they needed more detail, and so that they
can be referenced.
See:   https://goo.gl/166KTe

> In any case a short reasoning why to do this step would be helpfull.

> h) Pledge proximity assertion:

> Sentence summarizing one most important attack vector reducet by
> this. Or pointer to reference where this is explained.

I agree, we should expand this section to explain why.
  https://github.com/anima-wg/anima-bootstrap/issues/56

> 
-
> Section 5.5

> a) "immediately complete authentication of the provisional"

> This sounds contradictory to the potential need to perform /cacerts first 
as
> described in section 5. Add something like (potentially after
> performing /cacerts,
> see section 5.) ?

We opened an issue before about this. I added this to it.
   https://github.com/anima-wg/anima-bootstrap/issues/51


> 
-
> Section 5.5.1

> a) "which is an additional justification
> for the recommendation to proceed with EST key management operations.
> Once a full CA Certificate Response is obtained it is more
> authoritative for the domain than the limited 'pinned-domain-cert'
> response."

> This sounds contradicting to the statement in section 5., where it sounds 
as if
> provisional state is completes only after the (optional /cacerts) and 
cacerts
> is part of bootstrap, whereas here it sounds as if its part of
> enrollment only.

okay, part of issue above.


> 
-
> Section 5.6)

> a) "The domain is expected to provide indications to the system

[Anima] dns-sd [was Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09]

[Brian E Carpenter]

On one point only:

On 27/03/2018 08:11, Michael Richardson wrote:

> 
> > d) Add section to request brksi-proxy and brski-registrar to
> > IANA service name registry.
> 
> I'm still not sure I understand the why of dns-sd discovery in an ANI
> environment.

That's a discussion on its own and I think it should be kept separate.
So I would leave these registrations aside for now; nobody else
is going to ask for brksi-* service names, so there's no urgency.

Once this phase is done, I hope we can discuss draft-eckert-anima-grasp-dnssd
properly in the WG, and the deeper implications.

 Brian

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

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson]

Brian E Carpenter  wrote:
> I definitely recommend replacing lower-case "may" in a case like
> the one below.

Agreed.

> Perhaps:

>>> , and MUST NOT be
>>> enabled unless the JRC indicates support for them

Changed.


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





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] dns-sd [was Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09]

[Brian E Carpenter]

On 27/03/2018 10:47, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> > On 27/03/2018 08:11, Michael Richardson wrote:
> > ...
> >>
> >> > d) Add section to request brksi-proxy and brski-registrar to
> >> > IANA service name registry.
> >>
> >> I'm still not sure I understand the why of dns-sd discovery in an ANI
> >> environment.
> 
> > That's a discussion on its own and I think it should be kept separate.
> 
> Good, I think so as well.
> 
> > So I would leave these registrations aside for now; nobody else
> > is going to ask for brksi-* service names, so there's no urgency.
> 
> > Once this phase is done, I hope we can discuss
> > draft-eckert-anima-grasp-dnssd
> > properly in the WG, and the deeper implications.
> 
> I'm not sure what to do about the current statements in the appendix then.

I really can't judge whether that material is sufficiently 
baked to be normative text (even under a MAY). I do have
sympathy with making BRSKI usable more generally, but I'm
not competent to judge whether this text is ready for the
standards track.

Brian

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

Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson]

Final comments/actions on Toerless' awesome review.
The -13 is coming out soon, but we have 13 issues to resolve still.

> 
-
> Section 8)

> a) First paragraph: Unvailable MASA is not a security but an
> operational consideration.
> Feel free to add "Operational considerations" section before security
> considerations and move it there. Might want to add some more
> considerations around
> MASA to set context: Suggest something like:

It's due to that operational consideration that someone might want a nonceless
voucher, and therein is the security consideration.

So while I'm not oppposed to an Operational Considerations section,
it would not start with that first paragraph.

> c) "The MASA authorization log..."

> Not security consideration either IMHO.  Suggest to move into a new
> "Privacy considerations"

Agreed.
MAX: when did the MASA audit log became an authorization log?
 Is this intentional?

> 
-
> Appendix A)

> a) Would change title to non-IPv6 or non-ANI operations:
> b) Initial explanation:

I'm changing it to IPv4 and non-ANI operations.
I'd rather search found "IPv4"

> Specification of BRSKI in Section 4. only covered the mechanisms for an 
IP6
> Pledge (link-local IPv6 address) and Proxy options necessary for IPv6
> and ANI.
> It does not cover the options for non-IPv6 Pledge or non-ANI Proxies
> (IPv4 or IPv6).

done.

> 
-
> Appendix A.2)

> a) Replace with:

> A.2.  Use of DHCP

Not sure I agree. I think that DHCPv6 considerations are very different.
There are RAs, DHCPv6, as well as what kind of address will be given.
An IPv4 address is almost 100% certain to be RFC1918/NAPT, while IPv6 will not.

I don't mind adding a section on this, but I'd prefer to have a seperate
section as it needs significantly more details.

> 
-
> Appendix B)

> a) Use suggested service name of "_brski-proxy" in all caes where
> "_bootstrapks"
> is used. (see comment for section 4.1.1 for why that name is better).

Opened issue: https://github.com/anima-wg/anima-bootstrap/issues/57

> b) After "The Pledge MAY perform DNS-based Service Discovery", new 
paragraph:

> A non-ANI Proxy MAY perform DNS-based Service Discovery using unicast DNS
> to discover Registrars searching for searching for the service
> "_brski-registrar._tcp.local.".

okay.

> c) "To prevent unaccceptable levels of network traffic" -> add ", when
> using mDNS"

okay.

> d) "received a useable IPv4 address via DHCPv4 as suggested in Appendix 
A" ->
> "received a useable IP address via DHCP/DHCPv6 as suggested in Appendix
> A.2"

see above.

> e) "If no local bootstrapks service": Add at end of paragraph: See
> Section 2.6 (Cloud Registrar).

done.

> 
-

> Appendix C)

> a) See discussion for section 4.3 above for the issues i see with
> current IPIP
> specification and suggestion to maybe move out of BRSKI to resolve with
> more time.

Yes, I think that I agreed to remove it.

> 
-
> Appendix E)

> a) Please add a sentence how to decode Hex Certs (not keys) with utility
> at the very top of the appendix (right now its further down in the
> text).

I'm confused by this.
a) there are no Hex Certs, they are all base64, and they are in standard
   PEM format.
b) I never say how to decode them... so?

> b) E.1.4: which element in the cert would become the serial-number ?

Good point, it's not in the Subject in this example.
 https://github.com/anima-wg/anima-bootstrap/issues/58

I expect to regenerate the examples at AUTH48 time, once IANA
has assigned everything.

> c) There are no ASN1 decodings of the artefacts, Please fix.
> If this is subject to IANA assignments, please add RFC editor note to
> block draft progressing.

Sorry?  Which one is missing?

> X) Applicability outside ANIMA

> If i am not mistaken, BRSKI-MASA should be one option how a bootstrap
> server in "draft-ietf-netconf-zerotouch" could obtain a voucher from a
> MASA (if i understand it correctly, the mean by which such a bootstrap
> server obtains a voucher is left open). If that is correct, then it would
> be great to mention this in a sentence or two in an appropriate section
> of BRSKI as a very explicit example how BRSKI can be reused outside the
> complete ANIMA scope (also add draft-ietf-netconf-zerotouch as an
> informational
> reference).

I would 

Re: [Anima] dns-sd [was Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09]

[Michael Richardson]

Brian E Carpenter  wrote:
> On 27/03/2018 08:11, Michael Richardson wrote:
> ...
>>
>> > d) Add section to request brksi-proxy and brski-registrar to
>> > IANA service name registry.
>>
>> I'm still not sure I understand the why of dns-sd discovery in an ANI
>> environment.

> That's a discussion on its own and I think it should be kept separate.

Good, I think so as well.

> So I would leave these registrations aside for now; nobody else
> is going to ask for brksi-* service names, so there's no urgency.

> Once this phase is done, I hope we can discuss
> draft-eckert-anima-grasp-dnssd
> properly in the WG, and the deeper implications.

I'm not sure what to do about the current statements in the appendix then.

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





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Brian E Carpenter]

So, page 21 says:

> ... This provides an  
> earliest date which is reasonable.  Call this the current 
> reasonable date (CRD).  This value SHOULD NOT be stored in any
> way, and applies to the current Registration attempt only.
> Subsequent attempts MUST follow this proceedure again from
> scratch.  The current reasonable date may only increase.

Firstly, "SHOULD NOT be stored in any way" surely means
"SHOULD NOT be permanently stored in any way", because
it must certainly be temporarily stored during the current
registration attempt.

Secondly, "The current reasonable date may only increase."
is unverifiable unless the previous CRD is stored for
comparison.

So I think the "SHOULD NOT" clause has to go. Perhaps you
mean:
  This value MUST NOT be used for any future Registration attempt.

Regards
   Brian

On 27/03/2018 10:48, internet-dra...@ietf.org wrote:
> 
> 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-13.txt
>   Pages   : 91
>   Date: 2018-03-26
> 
> Abstract:
>This document specifies automated bootstrapping of a remote secure
>key infrastructure (BRSKI) 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-13
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-13
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> 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
> 

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