[Netconf] zero touch update plan

Kent Watsen <kwatsen@juniper.net> Wed, 02 September 2015 20:01 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2D1B5420 for <netconf@ietfa.amsl.com>; Wed, 2 Sep 2015 13:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 QTd5yAe0rlcy for <netconf@ietfa.amsl.com>; Wed, 2 Sep 2015 13:01:12 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A494C1B541F for <netconf@ietf.org>; Wed, 2 Sep 2015 13:01:12 -0700 (PDT)
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.256.15; Wed, 2 Sep 2015 20:01:11 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.01.0256.013; Wed, 2 Sep 2015 20:01:11 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: zero touch update plan
Thread-Index: AQHQ3BnruYZ2Dr6gYEiWn5a5V+RszQ==
Date: Wed, 02 Sep 2015 20:01:11 +0000
Message-ID: <D1FCA752.D0863%kwatsen@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.4.140807
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:51l2XxS7Swnmx9kRYhOttBzDLLyXJ1k7qhGycy5GCcw54ar5WL0l8Cf2sZv9IrcGl7vXNajYCJtuEWk2d7OJsxpNBDbYHXV9D17EibznWzLMXlFPxXDuHwvtiKSa+uthHjrJLGbdiZN/ryEu4TzmWA==; 24:bvm8RzHi7JLY6y9+7XFzvsl4V2o7aCEdXFEXHTTpfC2j40VS0/5doHnFuUdkRjmiN8eZObrorVCBhe1TF65ghJaTNTXMUesm1uWDrTIUgEk=; 20:9Ki6TX4Lo5r1w5HAcaj+p9b/m3JuB2oWj7z6rYoywnZedW6zGVCnk/Z6kkXbqbfIPGYlRqK5KwkuveF89XT7gA==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-microsoft-antispam-prvs: <CO1PR05MB457819B444660820E33DE2FA5690@CO1PR05MB457.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457;
x-forefront-prvs: 0687389FB0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(52314003)(229853001)(102836002)(5002640100001)(66066001)(2900100001)(2351001)(16236675004)(106356001)(86362001)(101416001)(83506001)(64706001)(99286002)(54356999)(105586002)(92566002)(106116001)(2501003)(87936001)(5001920100001)(110136002)(189998001)(5001960100002)(5001860100001)(107886002)(10400500002)(40100003)(4001350100001)(97736004)(4001540100001)(36756003)(46102003)(81156007)(450100001)(62966003)(5004730100002)(77156002)(68736005)(122556002)(5007970100001)(5001830100001)(50986999)(140573001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D1FCA752D0863kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2015 20:01:11.0482 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: <http://mailarchive.ietf.org/arch/msg/netconf/y96xWtNpLGAvRRSCMhi90cOGYjk>
Subject: [Netconf] zero touch update plan
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2015 20:01:15 -0000

I presented in Prague about resolving a privacy issue by defining a secure redirect mechanism.  The mechanism entails the device only receiving back a redirect message to its deployment-specific bootstrap server.  The redirect message would include also an X.509 certificate that the device can subsequently use to authenticate the bootstrap server the device is being redirected to.  This is what I'm calling "secure redirect".

Secure-redirect is fundamentally a transport-level security play.  That is, an authenticated connection to the redirect server (most likely hosted by the device's vendor) provides the trust anchor for an authenticated connection to the deployment-specific bootstrap server.  Because the trust anchor is provided over a trusted connection, it can be trusted.  Likewise, the bootstrap data received from the bootstrap server can also be trusted, because it is provided over a trust connection.  This solution is notable as it does not require the data to be signed in order to be trusted, unlike what's written in the current zerotouch draft.  That is, nothing related to Owner Certificate or Ownership Vouchers is needed for this solution to be secure.

Summarizing, there are two distinct solutions:

1. For when end-to-end transport-level security is possible (i.e., device can route to Internet)
- bootstrap data does not have to be signed

2. For when end-to-end transport-level security is NOT possible (e.g., a private network)
- bootstrap data has to be signed (e.g., Owner Certificate and Ownership Vouchers)

Of course, it's OK to do both at the same time too - i.e., signed data over a secure transport

Anyway, unless anyone objects, I will update the draft along these lines in a few days.

Ciao,
Kent