Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-26.txt

From: [email-masked]
Date: Wed, 01 Jul 2020 13:56:03 -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           : An Autonomic Control Plane (ACP)
        Authors         : Toerless Eckert
                          Michael H. Behringer
                          Steinthor Bjarnason
	Filename        : draft-ietf-anima-autonomic-control-plane-26.txt
	Pages           : 162
	Date            : 2020-07-01

Abstract:
   Autonomic functions need a control plane to communicate, which
   depends on some addressing and routing.  This Autonomic Control Plane
   should ideally be self-managing, and as independent as possible of
   configuration.  This document defines such a plane and calls it the
   "Autonomic Control Plane", with the primary use as a control plane
   for autonomic functions.  It also serves as a "virtual out-of-band
   channel" for Operations, Administration and Management (OAM)
   communications over a network that provides automatically configured
   hop-by-hop authenticated and encrypted communications via
   automatically configured IPv6 even when the network is not
   configured, or misconfigured.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-26
https://datatracker.ietf.org/doc/html/draft-ietf-anima-autonomic-control-plane-26

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-26

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: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 18:47:32 -0400

As I understand the diff, AcpNodeName seems to be a new extension,
not a SubjectAltName extension, but an extension?

I found it difficult, reading RFC5912 to figure out where id-on was located,
and I had to go into
  https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-1.3.6.1.5.5.7.0
to see.

Throughout 5912, we have:
  id-pkix  OBJECT IDENTIFIER  ::=
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7)}

while ACP says:

   id-pkix
    FROM PKIX1Explicit-2009
      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ;

and while I understand that these are "local" variables, it does make
figuring stuff out difficult.  May I request that the above link
(smi-numbers.xml ) go into a comment?  maybe that's not often done.

The IANA section is a bit of a clearer pointer, but I sure wish we'd point
people straight at the the place we mean by URL.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 18:58:10 -0400

the diff for 6.1.5.3.  Certificate Revocation Lists (CRLs)
fixes some TLAs, but continues to seem to recommend long-lived certificates with CRLs.
I think that CRLs are not useful, and we should not use them.

6.1.3 is clear that OCSP/CRLs may not be available when connecting!

I think that use of STAR (https://datatracker.ietf.org/doc/rfc8739/ )
Short-Term, Automatically Renewed is the best recommendation!

If we have to do OCSP (via https://datatracker.ietf.org/doc/rfc4806/ )
then we nodes can download their staple and provide it when connecting.
New nodes can get this using the Join Proxy.

Perhaps this needs to be in a new document at this point.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 2 Jul 2020 01:29:51 +0200

> not a SubjectAltName extension, but an extension?

No, i think this is why Russ was adament to have subjectAltName
mentioned. It is just a new otherName and can therefore theoretically
be used everywhere a GeneralName can be used. It MUST be in a
subjectAltName / otherName to name the subject. It _could_ be
in IssuerAltName if for example an ACP node is a subCA etc. pp.

It could be used in IDr / IDi in IPsec too.

>       mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ;

i took pretty much the whole ASN.1 block from RFC8398,
given how nobody was jumping forward to suggest writing the ASN.1 code.
This RFC looked like the newest/best template for a new string type otherName.

> (smi-numbers.xml ) go into a comment?  maybe that's not often done.

Can you pls. suggest explicit text, because i am just winging this ASN.1 stuff
by stealing text from prior RFCs.

> people straight at the the place we mean by URL.

Suggest text, or pull request pls.

I just tried to stay on the safe side, dong what prior RFCs did. Pasting
a Title into Google is typically a better way to find stuff than hoping
URLs don't change, although IANA is prety stable (never try URL with any
vendor WWW server ;-).

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 2 Jul 2020 01:41:00 +0200

> fixes some TLAs, but continues to seem to recommend long-lived certificates with CRLs.

The need to diligently document support for CRL/OCSP was done on
behalf of securiy reviews. It is not meant to be a recommendation.
There is mentioning of short-lived certificates in a few places in the
doc.

> I think that CRLs are not useful, and we should not use them.

I think we agree.

> Short-Term, Automatically Renewed is the best recommendation!

In general yes, but the STAR use cases typically do not take into
account  connectivity problems that are longer than the lifetime of
a cert, whereas for the ACP this might be a problem.

With CRL/OCSP, it seems as if we could define the details under
loss of connectivity through these mentioned rules. This seems
like an easily acceptable solution for the proponents of CRL/OCSP
because they couldn't come up with a better solution and its their
technology.

When we are talking about expiry of short lived certs we would be
talking about pootentially authenticating expired certs under
limited network connectivity. Thats quite new and the proponents
of CRL/OCSP would drag along the argument much longer.

> Perhaps this needs to be in a new document at this point.

Yepp.  I think to remember that MaxP was thinking of suggesting to
talk about dealing with expired certs for our cases in i think LAMPS too
but longer ago...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 20:30:36 -0400

> There is mentioning of short-lived certificates in a few places in the

I didn't see an RFC8739 reference.  Oh. It's I-D.ietf-acme-star.
Your section 6.1.5.4 suggests CRLs are unnecessary when the lifetime is on
the order of hours,  while RFC8739 is less specific about what is short.
I think that a certificate lifetime on the order of a week would probably be
workable.

But, I think think we should get implementation experience.

    > I think we agree.

Good.

    > a cert, whereas for the ACP this might be a problem.

yes, but the solution is to find a Join Proxy, reach out to the Registrar and
renew the certificate using the LDevID one has.
STAR even went into some detail about how one could renew expired
certificates, I think. (I recall a discussion, but I'd have to check the
document again)

    > talk about dealing with expired certs for our cases in i think LAMPS too

yes, the document wound up in ACME, and I think they did a good job, although
it is proscriptive for ACME only, while our end-client interface is assumed
to be EST.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 7 Jul 2020 01:13:55 +0200

> the order of hours,  while RFC8739 is less specific about what is short.

2.3 days is one number i found in the RFC.

IMHO RFC8739 is not a relevant comparison for ACP (and i am not only
saying this because otherName killed our ability to use ACME CA with
RFC822 names ;-):

Unless i am missing something, ACP/EST renewal of certs is already the
same "lightweight" renewal that RFC8739 introduces for ACME.

In addition for ANI nodes, we always have re-enrollment via BRSKI/MASA.

Aka: ultimately, the question is whether/how we should deal with
expired certs under incomplete reachability. Max already said that
it should be perfectly fine for EST to accept expired certs as
a valid credential for renewal, that was just never top of mind when
EST was developed, and it certainly would cause hesitation at first
by IETF security review should that be added. 

I for once had to regularily re-activate enterprise WFH VPN clients
that where switched off  for months, then users sent me email, and
i had to go to the VPN server and configure "ignore lifetime for this cert",
so the VPN client would renew its cert.

> I think that a certificate lifetime on the order of a week would probably be

I think that if you want to get rid of CRL/OCSP then you need to
get down to reaction time at the order of revocation, which i think
can be as little as 30 minutes. I think its not a problem to do that,
its just far off the beaten track people feel offended to think about
it. There are a lot of network operations aliveness operations at
a 30 seconds interval for every node (aliveness ping). Doing a simple
cert re-signing once every 30 minutes isn't worse IMHO.

> But, I think think we should get implementation experience.

Sure, but there are a lot long-term issues that can happen, sometimes
folks take yeas in deployments to figure out probems with cert lifetime
management, hence the theoretical discussion is useful here too.

> certificates, I think. (I recall a discussion, but I'd have to check the

Exactly, but that i think was also why the general purpose STAR document
didn't progress in LAMPS. But i forgot all the generic issues there,
i think to remember they are not an issue for ANI/ACP though, but
obviously that would have to be probed by going to LAMPS with a more
constrained EST renewal with expired certs discussion.

> it is proscriptive for ACME only, while our end-client interface is assumed

Yepp. The comparison is probably that doing in ACME the revalidation of
ownership of (domain/email) name is as complex as going through BRSKI/MASA,
whereas doing just EST renewal, worst case via join-proxy (if cert is
expired) is exactly what RFC8739 does for ACME.

Cheers
    Toerless

-- 
---
[email-masked]