Return-Path: <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4E512008B; Tue, 6 Aug 2019 17:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6fagzRD6A41; Tue, 6 Aug 2019 17:09:40 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE08D12008C; Tue, 6 Aug 2019 17:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565136578; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=UnXFNJS55Ymwpi2+3Vz5qBiJwwJt+q/MOjHmTUYaMW8=; b=bFVL8pKf5tX5VA0fb3hEoJ/1RIOkLN64zcPkGCM/jjyQzwTl/mpPIXlY6nEc4fvO t3M/svEVBDNJ4wtvUq8yq2BNISteKDDQfaPp7ndMKRrLivyx/RlAzzBkOLMvyQsSaVD lmze86h+OWaibGu2z06oiGQdAP1K4EpJT24Ox57E= From: Kent Watsen Message-ID: <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 00:09:38 +0000 In-Reply-To: <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> Cc: "Owen Friel (ofriel)" , "iot-onboarding@ietf.org" , Rifaat Shekh-Yusef , "anima@ietf.org" To: Toerless Eckert References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.07-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 00:09:42 -0000 --Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Toerless, > I ranted about the need to better describe the common architecture=20 > already in prior emails to the anima list. Good. =20 > Complexity is in the eye of the beholder. True, but it seems that getting a domain certificate and getting an = initial configuration are at least two distinct steps in ANIMA, whereas = they're rolled into one step with SZTP. =20 While the comparison may not apply perfectly, for a long time in = filesystems, the redundancy layer (e.g., RAID-6) and the volume = management layer were distinct, but ZFS collapsed them into one layer, = for the better. I wonder if we might not have something like that = here... > I like the modularity/flexibility that NetConf provides, but of > try to find someone who understands how to duplicate the full > enrolment process of BRSKI+EST with equivalent NetConf > supported Yang object models (especially for TA and Cert enrollment). > And then find more constrained devices that would more happily=20 > go with that more (IMHO) flexible model.=20 That paragraph didn't parse completely for me, but I get the sense that = there is an incomplete view, in both directions, for how things work. = Ideally, I would be more active in ANIMA but, I've been so busy that I = haven't had time. Perhaps we could schedule a call to go over = where/how SZTP can fit into the ANIMA model? > But given how constrained devices also do not like TLS of > BRSKI, it would be great if we could come up with a single > preferred transport to use with either server-controlle workflow > (like SZTP/Netconf) and client-side controlled (like BRSKI). Regarding TLS, SZTP depends on TLS in a soft way, other bindings could = be defined if needed. Regarding which side controls the flow, I'm unsure if SZTP is = server-controlled, at least, it is the device the initiates the = connection to the server, but perhaps you mean what I'd refer to a = post-bootstrapping steps that are needed to complete the full bringup. >> Regarding ACME integration during bootstrap, I think the basic desire = is to configure a device to obtain a certificate via ACME, configuration = which so happens to be provided at the time of the bootstrap event, but = could also happen at anytime thereafter. Support for such = configuration should be added to = https://tools.ietf.org/html/draft-ietf-netconf-keystore = . =20 >=20 > I think what you say is not specific to ACME but true for any RA<->CA = protocol. Yes. > The fact that NetConf/SZTP allows to enrol the certificate any time = later > is a key difference. I think architecturally, you want to make it as > soon as possible, but for example you may still want to first do > some additional attestation before the key enrollment. This is where > BRSKI+EST is a lot less flexible in design, but given how i think > there is no model for attestation in IETF, its hard t make the point = now. I'm quasi-working with Henk on RATS... > The only ACME specific thing i can think of are the mechanisms for the > RA to prove to the CA posession of a domain-name/prefix. That i think > is independent of the key-store. More related to the ability of the > RA to create DNS entries. No idea if there is a yang model for that > (would be nice). The keystore relation here is threefold: 1) when shipped from manufacturing, the keystore may be pre-populated with the device's, e.g., TPM-protected asymmetric key and = associated IDevID certificate. 2) when deployed, an alternate LDevID certificate may be configured in the keystore. 3) ACME or equivalent could be used to auto-update certificates as needed (the keystore model doesn't support this yet) I'm not aware of a YANG model to configure a DNS server as of yet. Kent --Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Toerless,


I ranted about = the need to better describe the common architecture
already= in prior emails to the anima list.

Good. =  


Complexity is = in the eye of the beholder.

True, = but it seems that getting a domain certificate and getting an initial = configuration are at least two distinct steps in ANIMA, whereas they're = rolled into one step with SZTP.   

While the comparison may not apply perfectly, for = a long time in filesystems, the redundancy layer (e.g., RAID-6) and the = volume management layer were distinct, but ZFS collapsed them into one = layer, for the better.  I wonder if we might not have something = like that here...


I like the modularity/flexibility that NetConf provides, but = of
try to find someone who understands how to duplicate = the full
enrolment process of BRSKI+EST with equivalent = NetConf
supported Yang object models (especially for TA = and Cert enrollment).
And then find more constrained = devices that would more happily
go with that more (IMHO) = flexible model.

That paragraph didn't parse completely for me, but = I get the sense that there is an incomplete view, in both directions, = for how things work.   Ideally, I would be more active in ANIMA = but, I've been so busy that I haven't had time.   Perhaps we could = schedule a call to go over where/how SZTP can fit into the ANIMA = model?


But given how constrained devices also do not like TLS of
BRSKI, it would be great if we could come up with a single
preferred transport to use with either server-controlle = workflow
(like SZTP/Netconf) and  client-side = controlled (like BRSKI).

Regarding TLS, SZTP depends on TLS in a soft way, = other bindings could be defined if needed.

Regarding which side controls the flow, I'm unsure = if SZTP is server-controlled, at least, it is the device the initiates = the connection to the server, but perhaps you mean what I'd refer to a = post-bootstrapping steps that are needed to complete the full = bringup.


Regarding ACME integration during bootstrap, I = think the basic desire is to configure a device to obtain a certificate = via ACME, configuration which so happens to be provided at the time of = the bootstrap event, but could also happen at anytime thereafter. =   Support for such configuration should be added to https://tools.ietf.org/html/draft-ietf-netconf-keystore = <https://tools.ietf.org/html/draft-ietf-netconf-keystore>= .   

I think what = you say is not specific to ACME but true for any RA<->CA = protocol.

Yes.


The fact that NetConf/SZTP allows to enrol the certificate = any time later
is a key difference. I think = architecturally, you want to make it as
soon as possible, = but for example you may still want to first do
some = additional attestation before the key enrollment. This is where
BRSKI+EST is a lot less flexible in design, but given how i = think
there is no model for attestation in IETF, its hard = t make the point now.

I'm quasi-working with Henk on = RATS...


The only ACME = specific thing i can think of are the mechanisms for the
RA = to prove to the CA posession of a domain-name/prefix. That i think
is independent of the key-store. More related to the ability = of the
RA to create DNS entries. No idea if there is a = yang model for that
(would be nice).


The keystore relation here is = threefold:

  1) when shipped = from manufacturing, the keystore may be pre-populated
  =     with the device's, e.g., TPM-protected asymmetric key and = associated
      IDevID = certificate.

  2) when = deployed, an alternate LDevID certificate may be configured = in
      the keystore.

  3) ACME or equivalent could be used to = auto-update certificates as
      needed (the = keystore model doesn't support this yet)


I'm not aware of a YANG = model to configure a DNS server as of yet.


Kent


= --Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1--