Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22

David Mandelberg <david+work@mandelberg.org> Sat, 18 August 2018 00:19 UTC

Return-Path: <david+work@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03A3130FF0 for <secdir@ietfa.amsl.com>; Fri, 17 Aug 2018 17:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 9F6VBR1BzYxC for <secdir@ietfa.amsl.com>; Fri, 17 Aug 2018 17:19:35 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A67D130FF4 for <secdir@ietf.org>; Fri, 17 Aug 2018 17:19:33 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=KaWQikQD c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=dapMudl6Dx4A:10 a=bmmO2AaSJ7QA:10 a=48vgC7mUAAAA:8 a=BTUBnpS-AAAA:8 a=v_OVUiDecUYEfxGDTDQA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:59462] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from <david+work@mandelberg.org>) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 44/6B-45687-216677B5; Fri, 17 Aug 2018 20:19:31 -0400
Received: from [0.0.0.0] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 47CF91C605C; Fri, 17 Aug 2018 20:19:26 -0400 (EDT)
To: Kent Watsen <kwatsen@juniper.net>, "draft-ietf-netconf-zerotouch.all@ietf.org" <draft-ietf-netconf-zerotouch.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
References: <361393b0-6666-08ff-bdf4-3ba3bf4323c7@mandelberg.org> <47EEE9B6-5BC2-4A1F-ABB2-2ACB1C494545@juniper.net> <4579f9bf-0ead-a6af-dc80-a841527414eb@mandelberg.org> <51E98D22-1DBF-4069-A750-90987EB96B0D@juniper.net> <bfeb8564-9390-c241-4585-2340de1345d2@mandelberg.org> <F0355112-AD44-49F3-9862-CC939AC768B7@juniper.net>
From: David Mandelberg <david+work@mandelberg.org>
Message-ID: <b661ba01-cf1f-adef-54bf-e1fe4366ab0c@mandelberg.org>
Date: Fri, 17 Aug 2018 20:19:18 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <F0355112-AD44-49F3-9862-CC939AC768B7@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UT0vTVSAZgUyS0NoQHKx72SKnG4>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-zerotouch-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Aug 2018 00:19:37 -0000

On 08/14/2018 09:59 PM, Kent Watsen wrote:
> 
> Hi David,
> 
> Trimming down to just the remaining items...
> 
> 
>>> I was writing the Security Considerations for this when it seemed
>>> that the better thing to do here is to instead add "not-before" and
>>> "not-after" leafs to the zerotouch information artifact.  The draft
>>> would then explain that devices MUST ensure the current time is in
>>> between.
>>>
>>> Would such an addition resolve this issue for you?
>>
>> Yes, that would work. It probably makes sense to say something in
>> the security considerations about keeping those validity intervals
>> short.
>>
>> If you prefer to leave the data formats and implementations unchanged,
>> you could also consider using per-CMS EE certificates, like the RPKI
>> does: https://tools.ietf.org/html/rfc6480#section-2.3. (I haven't
>> thought about how compatible that method is with zerotouch, I'm just
>> mentioning it as an alternative in case it happens to be easier for you.)
> 
> Ah, this is an interesting idea.  Actually, I'd say that there is a
> near 1-1 correspondence between EE certificates and what this draft
> is calling the owner cert.  Section 3.2 says about owner certs:
> 
>     The owner certificate CMS structure MUST contain the owner
>     certificate itself, as well as all intermediate certificates leading
>     to the 'pinned-domain-cert' certificate specified in the ownership
>     voucher.  The owner certificate artifact MAY optionally include the
>     'pinned-domain-cert' as well.
> 
> While we conceptually think of the owner certificate as a singleton,
> there is nothing in the draft that prevents a unique owner certificate
> per device, which would allow for per-device validity and revocation to
> be supported.
> 
> This being the case, I think that the following Security Consideration
> section should be added:
> 
>     9.11.  Validity Period for Zero Touch Information
> 
>     Zero touch information does not specify a validity period.  For
>     instance, neither redirect information nor onboarding information
>     enable "not-before" or "not-after" values to be specified, and
>     neither artifact alone can be revoked.
> 
>     For unsigned data provided by an untrusted source of bootstrapping
>     data, it is not meaningful to discuss its validity period when the
>     information itself has no authenticity and may have come from
>     anywhere.
> 
>     For unsigned data provided by a trusted source of bootstrapping data,
>     the availability of the data is the only measure of it being current.
>     Since the untrusted data comes from a trusted source, its current
>     availability is meaningful.

(nit) The only trusted sources of bootstrapping data are TLS servers, 
right? I think this paragraph would be a bit stronger if you explicitly 
mentioned that TLS's integrity guarantee and replay protection are what 
you're relying on here.


>     For signed data, whether provided by an untrusted or trusted source
>     of bootstrapping data, the validity is constrained by the validity of
>     the both the ownership voucher and owner certificate used to
>     authenticate it.
> 
>     The ownership voucher's validity is primarily constrained by the
>     ownership voucher's "created-on" and "expires-on" nodes.  While
>     [RFC8366] recommends short-lived vouchers (see Section 6.1), the
>     "expires-on" node may be set to any point in the future, or omitted
>     altogether to indicate that the voucher never expires.  The ownership
>     voucher's validity is secondarily constrained by the manufacturer's
>     PKI used to sign the voucher; whilst an ownership voucher cannot be
>     revoked directly, the PKI used to sign it may be.
> 
>     The owner certificate's validity is primarily constrained by the
>     X.509's validity field, the "notBefore" and "notAfter" values, as
>     specified by the certificate authority that signed it.  The owner
>     certificate's validity is secondarily constrained by the validity of
>     the PKI used to sign the voucher.  Owner certificates may be revoked
>     directly.
> 
>     For owners that wish to have maximum flexibility in their ability to
>     specify and constrain the validity of signed data, it is RECOMMENDED
>     that a unique owner certificate is created for each signed artifact.
>     Not only does this enable a validity period to be specified, for each
>     artifact, but it also enables to the validity of each artifact to be
>     revoke.
> 
> What do you think?

Looks good!


>>> Do you think it's worth adding a warning to operators somewhere to
>>> remind them to change the flag? Or maybe the "device SHOULD report a
>>> warning if the bootstrapping completes successfully but zerotouch
>>> bootstrapping is still enabled"?
> 
> I forgot to respond to this comment of your before.  To address this
> comment, I added the following:
> 
>     If the onboarding information was obtained from a trusted bootstrap
>     server, and the result of the bootstrapping process did not disable
>     the "flag to enable zerotouch bootstrapping" described in
>     Section 5.1, the device SHOULD send an "bootstrap-warning" progress
>     report.

Thanks!


>>>> I think it's already clear what an error in paragraph 6 is. What I found
>>>> unclear was what to do with errors in paragraphs 6 or 7. Yes, don't go
>>>> on to the next step, but what about: In paragraph 6, should the device
>>>> rollback any partial config update if there's an error? In paragraph 7,
>>>> should the device rollback all config from paragraph 6 if there's an error?
>>>
>>> This very same issue was raised to me separately and my response has been
>>> to essentially rewrite section 5.6 to be crystal clear on how errors are
>>> handled, especially with regard to state retained.  Please see attached
>>> for a preview of -23.
>>
>> Much better, thanks!
> 
> FIW, this text is going thru a WG churn, but the essence of what I attached
> before is being retained.

Sounds good.


-- 
https://david.mandelberg.org/