From nobody Mon Jul 2 13:19:35 2018 Return-Path: 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 2E3DC1312DC; Mon, 2 Jul 2018 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 wfmuAxMnbh8g; Mon, 2 Jul 2018 13:19:21 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF60131319; Mon, 2 Jul 2018 13:19:18 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C2A7758C4AE; Mon, 2 Jul 2018 22:19:13 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A8F894401A4; Mon, 2 Jul 2018 22:19:13 +0200 (CEST) Date: Mon, 2 Jul 2018 22:19:13 +0200 From: Toerless Eckert To: Sheng Jiang Cc: "anima@ietf.org" , "anima-chairs@ietf.org" Message-ID: <20180702201913.7veip52cbywxbbei@faui48f.informatik.uni-erlangen.de> References: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92900ED44D@NKGEML515-MBX.china.huawei.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 102, Montreal X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 20:19:34 -0000 Requesting a slot to present draft-eckert-anima-noc-autoconfig-00 This new draft proposes standardization of a set of crucial NOC services by ACP nodes to further autoamte ACP network opeations as well as closing the zero-touch gap after BRSKI (for further secure configuration). This draft builds on the framework for DNS-SD compatible (but extended) service discovery via GRASP, which i refreshed to eckert-anima-grasp-dnssd-01 (presented in prior IETF). Both drafts are proposed as standards track work items to further complete the ANI self-configuration for use in todays networks. Cheers Toerless P.S.: Was trying to also make advances on the YANG model, but ran out of time this IETF before the deadline. On Sat, Jun 23, 2018 at 12:59:23PM +0000, Sheng Jiang wrote: > Hi, all anima, > > > > We have been allocated a session of 2.5-hour for the ANIMA WG meeting for IETF-102 (Montreal) and are starting to collect agenda items for the session.. Please send your request for agenda by July 5th, Thursday. > > > > Giving that most of our chartered work items have been sent to IESG for publication by the meeting, we expect short time slots for only two or three of them. For this coming meeting, we would like to discuss potential future ANIMA works. > > > > As normal, the priority among these non-charter work items would be: these that have active discussion in mail list, then these have submitted drafts, and topics without drafts. > > > > Please send us (anima-chairs at ietf.org) requests for time slot by July 5th, Thursday and include: > > > > Name of time slot: > > Name of draft(s): > > Time requested: > > Presenter name(s): > > > > More details about the IETF 102, Montreal can be found at: > > > > https://www.ietf.org/how/meetings/102/ > > > > Again, presenters and draft authors please invoke active discussions in the ANIMA list. Mail list is a very good place to discuss and reach consensus on technical issues. > > > > Best regards, > > > > Toerless & Sheng > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Tue Jul 3 09:07:44 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7971013104A; Tue, 3 Jul 2018 09:00:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ibagdona@gmail.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362849.4893.6315551881277122114.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:28 -0700 Archived-At: Subject: [Anima] anima - Requested session has been scheduled for IETF 102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:40 -0000 Dear Sheng Jiang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (2:30 requested) Wednesday, 18 July 2018, Morning Session I 0930-1200 Room Name: Van Horne size: 130 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/anima.ics Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf Third Priority: cfrg saag intarea opsarea People who must be present: Toerless T. Eckert Sheng Jiang Terry Manderson Ignas Bagdonas Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. --------------------------------------------------------- From nobody Tue Jul 3 17:17:37 2018 Return-Path: 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 EC09A130E62 for ; Tue, 3 Jul 2018 17:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 XJzqYQHs5zi0 for ; Tue, 3 Jul 2018 17:17:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A79130DFA for ; Tue, 3 Jul 2018 17:17:33 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EA0F158C4AE; Wed, 4 Jul 2018 02:17:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D90534401A4; Wed, 4 Jul 2018 02:17:28 +0200 (CEST) Date: Wed, 4 Jul 2018 02:17:28 +0200 From: Toerless Eckert To: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra-all@ietf.org Message-ID: <20180704001728.e6hepg7mrv7hzoyf@faui48f.informatik.uni-erlangen.de> References: <20180531015608.322bsmtpgusnaskh@faui48f.informatik.uni-erlangen.de> <20180619221316.rj7gge77x3xeiexj@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180619221316.rj7gge77x3xeiexj@faui48f.informatik.uni-erlangen.de> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jul 2018 00:17:36 -0000 Dear authors: With draft-ietf-anima-bootstrapping-keyinfra published, all WG last call review issues have been resolved. In addition the the positive feedback on the list and no negative feedback, i declare the WG last call successfull and will take the document forward. As a reminder: as part of doing the shepherd writeup for the document to go to the IESG, we are checking IPR status with the authors. I expect that the authors are not aware of any new IPR. We have 2 IPR disclosures from 2014/2016 against this document: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-anima-bootstrapping-keyinfra To the best of my memory, hese where briefly discussed after they where filed but did not raise an concerns. There where also no concerns brought up during WG last call against these. Cheers Toerless From nobody Tue Jul 3 17:18:22 2018 Return-Path: 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 D0B77130E60; Tue, 3 Jul 2018 17:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 QVKImZG9hGCl; Tue, 3 Jul 2018 17:18:16 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDCD130DFA; Tue, 3 Jul 2018 17:18:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 617AB58C4AE; Wed, 4 Jul 2018 02:18:09 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 58DAF4401A4; Wed, 4 Jul 2018 02:18:09 +0200 (CEST) Date: Wed, 4 Jul 2018 02:18:09 +0200 From: Toerless Eckert To: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org Message-ID: <20180704001809.vhrpp7sbpw4z73wl@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 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, 04 Jul 2018 00:18:19 -0000 Dear authors: With draft-ietf-anima-bootstrapping-keyinfra published, all WG last call review issues have been resolved. In addition the the positive feedback on the list and no negative feedback, i declare the WG last call successfull and will take the document forward. As a reminder: as part of doing the shepherd writeup for the document to go to the IESG, we are checking IPR status with the authors. I expect that the authors are not aware of any new IPR. We have 2 IPR disclosures from 2014/2016 against this document: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-anima-bootstrapping-keyinfra To the best of my memory, hese where briefly discussed after they where filed but did not raise an concerns. There where also no concerns brought up during WG last call against these. Cheers Toerless From nobody Thu Jul 5 12:07:02 2018 Return-Path: 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 B5FD3130F63; Thu, 5 Jul 2018 12:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 wPC6R5bY79a7; Thu, 5 Jul 2018 12:06:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05543130F52; Thu, 5 Jul 2018 12:06:42 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C923558C4B4; Thu, 5 Jul 2018 21:06:38 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B82744401A4; Thu, 5 Jul 2018 21:06:38 +0200 (CEST) Date: Thu, 5 Jul 2018 21:06:38 +0200 From: Toerless Eckert To: Kent Watsen , anima@ietf.org Cc: "draft-ietf-anima-bootstrapping-keyinfra.authors@ietf.org" , "anima-chairs@ietf.org" Message-ID: <20180705190638.334hjjmk5nuvte4i@faui48f.informatik.uni-erlangen.de> References: <20180703233923.77ujphvmqwwtqwrd@faui48f.informatik.uni-erlangen.de> <3A976489-28ED-46B2-993F-345C35921C35@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A976489-28ED-46B2-993F-345C35921C35@juniper.net> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] ATTN/MUST REPLY: IPR disclosure against draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 19:07:01 -0000 Thanks Kent Let me forward to the mailing list so it is aware of this information. IPR disclosure for that Juniper patent is here, from 2015: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netconf-zerotouch https://datatracker.ietf.org/ipr/2581/ And for reference the ones disclosed explicitly against the bootstrap draft in 2014/2016: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-pritikin-anima-bootstrapping-keyinfra https://datatracker.ietf.org/ipr/2463/ https://datatracker.ietf.org/ipr/2816/ Cheers Toerless On Thu, Jul 05, 2018 at 03:21:53PM +0000, Kent Watsen wrote: > > The following was filed for the NETCONF WG's zerotouch draft: > > US Patent Application No. 14/626,382 > > link: https://patents.justia.com/patent/20160246617 > > > I didn't think to file it for the voucher draft itself, because the voucher > draft just sets up the environment. The patent is primarily concerned with > "offline bootstrapping" (e.g., booting off a USB flash drive), but it may > have some applicability to this draft. Please review and let me know. > > Kent > > > ===== original message ===== > > Dear authors of ANIMA draft-ietf-anima-bootstrapping-keyinfra > > As the document shepherd, i am hereby asking each of you to confirm > that any and all appropriate IPR disclosures required for full conformance > with the provisions of BCP 78 and BCP 79 have already been filed? > > Currently, there are two disclosures mentioned: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dietf-2Danima-2Dbootstrapping-2Dkeyinfra&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aUmDyJOX9lAznU-gnIOBXiJ8GWg7vbgP6bIAjQ6jBFE&s=9OhEIj9bViZjDM-VnPjRuJvXrRQEFhT1KoBG7DfTu6E&e= > > Hint: > > "I am not aware of any IPR against draft-ietf-anima-bootstrapping-keyinfra > that have not already been disclosed" > > Is a perfect answer to the question raised by this email (if it is true). > But remember that you are expected to be aware of all IPR with your name on it. > > Cheers > Toerless From nobody Thu Jul 5 16:47:10 2018 Return-Path: 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 383FC130E54; Thu, 5 Jul 2018 16:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wofRwQik5Q3o; Thu, 5 Jul 2018 16:47:05 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D6F130E21; Thu, 5 Jul 2018 16:47:05 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id j17-v6so6749215pfn.5; Thu, 05 Jul 2018 16:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VoP93DWKMfsNIMu3ggLFpiyxUZ/fO3nhVG8OsJG3jis=; b=LIPHlxW3UvBXQjjD3O6LeyEujL0VioK3tyuVIpCbcHsVlA3/X2X2rLRYZ2EK/T6Ns+ HfEadGbfWTBrMAirUzMSfdbdgXPy2ijAYUDbZ/hHBFMDC8Oe3JLn6wWP0pS6fidE2d+q FQ5sFiS4I7tf7z9iL9xbYMqhpg+A5h0f6Txfs7jE2cU/QE4Ttyu88fcErLkjZfKJ1skG ba04PS+FTzA6Xc4wJe6Wj/WbHHuDYHK4nVXcha+QHo/XZRqhOVwqywvTisd7K27mIqlZ kUS5kDx2gMss4D6W27UTPxLJaLWs12XcHBKvxYbiJiHW08fBJfTqKxpXAUVR+DxHONQr uMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VoP93DWKMfsNIMu3ggLFpiyxUZ/fO3nhVG8OsJG3jis=; b=NbouLdcbMwCUXA3h/mKn8j7QDlwwQwfBo1J5Za2mEPBUP/Bz3InwplbM6gU1cwnvn1 62zXzdiTjklOr+LP5vlzs5eEsxMvWCTr6VLiwmiJr901xiuHdennLvvCtylMGHGZFop/ LeneldJ3OrCWaH0hORqerzR9XlnZVDQ/LsvjMBOzEyqRICl8BVgjTN0I4YQs7em4V+Mq QwHu5jqskLcL/2+LB8DdaQOi7VVVMg2xC674BNqJIEKjdA1qDESFUqJtlDjgH7yG+erT PeSug3IGDhpM3G21yr8S4OBnDNLgINQYO9Ei1FgCCaqEjXmDHdJ9dU6L3w5LDfLoGTC0 /k6w== X-Gm-Message-State: APt69E1TPrnhrUgj8FzvuPlrfVEZoPdEAphel1+Xi6F7KKXJEIB9ZcJw 9mhfWE78dXH76vgTrBtpsECsTA== X-Google-Smtp-Source: AAOMgpdd7uogN27qlbcDb/P+q/G0eL4HfZCfRSuf88Cyb7Lt4KLIIKEDOrwdcTq743XYhaDvBtxaWg== X-Received: by 2002:a63:743:: with SMTP id 64-v6mr7555696pgh.216.1530834424869; Thu, 05 Jul 2018 16:47:04 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id k186-v6sm13320767pgk.94.2018.07.05.16.47.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jul 2018 16:47:04 -0700 (PDT) To: Toerless Eckert , Kent Watsen , anima@ietf.org Cc: "anima-chairs@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.authors@ietf.org" References: <20180703233923.77ujphvmqwwtqwrd@faui48f.informatik.uni-erlangen.de> <3A976489-28ED-46B2-993F-345C35921C35@juniper.net> <20180705190638.334hjjmk5nuvte4i@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <309df588-2bd3-1184-0745-41229e114945@gmail.com> Date: Fri, 6 Jul 2018 11:47:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180705190638.334hjjmk5nuvte4i@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ATTN/MUST REPLY: IPR disclosure against draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 23:47:09 -0000 On 06/07/2018 07:06, Toerless Eckert wrote: > Thanks Kent > > Let me forward to the mailing list so it is aware of this information. > > IPR disclosure for that Juniper patent is here, from 2015: > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netconf-zerotouch > https://datatracker.ietf.org/ipr/2581/ If somebody believes that is relevant to BRSKI, that somebody needs to file a separate disclosure. > And for reference the ones disclosed explicitly against the bootstrap draft > in 2014/2016: > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-pritikin-anima-bootstrapping-keyinfra > https://datatracker.ietf.org/ipr/2463/ This one isn't of great concern, since it's a reciprocal non-assert declaration. > https://datatracker.ietf.org/ipr/2816/ This one meets minimal requirements since it is reciprocal RAND, but note that it does *not* declare what the RAND conditions are, and the claims in the patent are fairly wide. Personally I don't think it is a reason to change track, exactly because the claims *are* wide - no minor changes to BRSKI would avoid them, if they are valid at all. But vendors will need to look closely at it. Brian > > Cheers > Toerless > > On Thu, Jul 05, 2018 at 03:21:53PM +0000, Kent Watsen wrote: >> >> The following was filed for the NETCONF WG's zerotouch draft: >> >> US Patent Application No. 14/626,382 >> >> link: https://patents.justia.com/patent/20160246617 >> >> >> I didn't think to file it for the voucher draft itself, because the voucher >> draft just sets up the environment. The patent is primarily concerned with >> "offline bootstrapping" (e.g., booting off a USB flash drive), but it may >> have some applicability to this draft. Please review and let me know. >> >> Kent >> >> >> ===== original message ===== >> >> Dear authors of ANIMA draft-ietf-anima-bootstrapping-keyinfra >> >> As the document shepherd, i am hereby asking each of you to confirm >> that any and all appropriate IPR disclosures required for full conformance >> with the provisions of BCP 78 and BCP 79 have already been filed? >> >> Currently, there are two disclosures mentioned: >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dietf-2Danima-2Dbootstrapping-2Dkeyinfra&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aUmDyJOX9lAznU-gnIOBXiJ8GWg7vbgP6bIAjQ6jBFE&s=9OhEIj9bViZjDM-VnPjRuJvXrRQEFhT1KoBG7DfTu6E&e= >> >> Hint: >> >> "I am not aware of any IPR against draft-ietf-anima-bootstrapping-keyinfra >> that have not already been disclosed" >> >> Is a perfect answer to the question raised by this email (if it is true). >> But remember that you are expected to be aware of all IPR with your name on it. >> >> Cheers >> Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Jul 6 00:09:53 2018 Return-Path: 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 63A7D130E2C for ; Fri, 6 Jul 2018 00:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 3ps-BJeklZnc for ; Fri, 6 Jul 2018 00:09:49 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF91130E1A for ; Fri, 6 Jul 2018 00:09:48 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w6679VL6031761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2018 12:39:37 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w6678rbG018175; Fri, 6 Jul 2018 12:38:55 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w6678p9C015446; Fri, 6 Jul 2018 12:38:51 +0530 From: "Anoop Kumar Pandey" To: Cc: Date: Fri, 6 Jul 2018 12:38:48 +0530 Message-ID: <007b01d414f8$313d68a0$93b839e0$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01D41526.4AF667F0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-in Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLg== X-CDAC-PUNE-MailScanner-ID: w6678rbG018175 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_20 -0.00, HTML_MESSAGE 0.00), not spam, SpamAssassin (not cached, score=-2.909, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_05 -1.11, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w6679VL6031761 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 07:09:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007C_01D41526.4AF667F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Michael, When a device is purchased in real world, usually an invoice is issued in the name of the purchaser with stamp of vendor/manufacturer. I propose that similarly, a digital invoice can be issued which will contain the public key(s) of the and digitally signed by the manufacturer. The digital invoice may be embedded in the pledge along with the IDevID. When a pledge starts the registration process, it will present the digital invoice along with IDevID. The JRC can verify the digital signature of the manufacturer on the digital invoice and sent a signed note of acceptance to the pledge. The pledge can verify the signed note using the public key(s) mentioned in the digital invoice, thereby verifying its true owner. This process with eliminate all the communication overhead with MASA and multiple level verification (voucher request, voucher, telemetry etc at JRC/MASA/Pledge). >From security point of view: Given that the digital invoice is digitally signed by manufacturer, the public key of domain owner embedded in the digital invoice can't be changed, otherwise verification of digital signature of manufacturer at JRC end will fail. Requesting you to give your comments as it will simplify the protocol. P.S.: As you had earlier mentioned "On resale, the device should be put through a factory reset to clear things. The MASA will have to be willing to issue a new voucher to the new domain owner."; here also, manufacturer may issue a new digital invoice in case of resale. Regards, Anoop Kumar Pandey ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_NextPart_000_007C_01D41526.4AF667F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Michael,<= o:p>

     When a devic= e is purchased in real world, usually an invoice is issued in the name of t= he purchaser with stamp of vendor/manufacturer.
    = ; I propose that similarly, a digital invoice can be issued which will= contain the public key(s) of the <domain owner(s)/JRC(s)> and digita= lly signed by the manufacturer. The digital invoice may be embedded in the = pledge along with the IDevID.
     When a pledge sta= rts the registration process, it will present the digital invoice along wit= h IDevID. The JRC can verify the digital signature of the manufacturer on t= he digital invoice and sent a signed note of acceptance to the pledge. The = pledge can verify the signed note using the public key(s) mentioned in the = digital invoice, thereby verifying its true owner.

This process with eliminate all the communication ove= rhead with MASA and multiple level verification (voucher request, voucher, = telemetry etc at JRC/MASA/Pledge).

From security point of view: Give= n that the digital invoice is digitally signed by manufacturer, the public = key of domain owner embedded in the digital invoice can’t be changed,= otherwise verification of digital signature of manufacturer at JRC end wil= l fail.

Requesting you to give your comments as it will simplify th= e protocol.

 =

P.S.: As you had earlier mentioned “On resale, t= he device should be put through a factory reset to clear things.  The = MASA will have to be willing to issue a new voucher to the new domain owner= .”; here also, manufacturer may issue a new digital invoice in case o= f resale.


Regards,
Anoop Kumar Pandey 


----------------------------------------------------------= ---------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_007C_01D41526.4AF667F0-- From nobody Fri Jul 6 13:45:56 2018 Return-Path: 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 70E7E130F3B; Fri, 6 Jul 2018 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 yTDdyekPxgYn; Fri, 6 Jul 2018 13:45:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F75130F33; Fri, 6 Jul 2018 13:45:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B07EC58C5A2; Fri, 6 Jul 2018 22:45:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A09864401A4; Fri, 6 Jul 2018 22:45:36 +0200 (CEST) Date: Fri, 6 Jul 2018 22:45:36 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Kent Watsen , anima@ietf.org, "anima-chairs@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.authors@ietf.org" Message-ID: <20180706204536.6ipbgo5otbvgg33j@faui48f.informatik.uni-erlangen.de> References: <20180703233923.77ujphvmqwwtqwrd@faui48f.informatik.uni-erlangen.de> <3A976489-28ED-46B2-993F-345C35921C35@juniper.net> <20180705190638.334hjjmk5nuvte4i@faui48f.informatik.uni-erlangen.de> <309df588-2bd3-1184-0745-41229e114945@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <309df588-2bd3-1184-0745-41229e114945@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] ATTN/MUST REPLY: IPR disclosure against draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 20:45:55 -0000 Brian, Thanks for the insight. I checked with IETF legal council, and the guidance was that RFC8179/5.1.3 would only come in second here. Given how the draft author is the IPR author, we need for Kent to come back authoritatively with an answer according to RFC8179/5.1.1. Or at least i need to wait for that answer for the shepherd-writeup. Wrt to your other comments (swapping hat to contributor): I love to comment on patent writeups publically, but i am too fearfull one could unexpectedly end up later as witness (if not worse) in some lawsuit with computers seized and inspected as evidence. So, i'll restrict myself to commenting in environments with more privacy. Cheers Toerless On Fri, Jul 06, 2018 at 11:47:07AM +1200, Brian E Carpenter wrote: > On 06/07/2018 07:06, Toerless Eckert wrote: > > Thanks Kent > > > > Let me forward to the mailing list so it is aware of this information. > > > > IPR disclosure for that Juniper patent is here, from 2015: > > > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-netconf-zerotouch > > https://datatracker.ietf.org/ipr/2581/ > > If somebody believes that is relevant to BRSKI, that somebody needs to > file a separate disclosure. > > > And for reference the ones disclosed explicitly against the bootstrap draft > > in 2014/2016: > > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-pritikin-anima-bootstrapping-keyinfra > > https://datatracker.ietf.org/ipr/2463/ > > This one isn't of great concern, since it's a reciprocal non-assert declaration. > > > https://datatracker.ietf.org/ipr/2816/ > > This one meets minimal requirements since it is reciprocal RAND, but note > that it does *not* declare what the RAND conditions are, and the claims > in the patent are fairly wide. Personally I don't think it is a reason > to change track, exactly because the claims *are* wide - no minor > changes to BRSKI would avoid them, if they are valid at all. But vendors > will need to look closely at it. > > Brian > > > > > > > Cheers > > Toerless > > > > On Thu, Jul 05, 2018 at 03:21:53PM +0000, Kent Watsen wrote: > >> > >> The following was filed for the NETCONF WG's zerotouch draft: > >> > >> US Patent Application No. 14/626,382 > >> > >> link: https://patents.justia.com/patent/20160246617 > >> > >> > >> I didn't think to file it for the voucher draft itself, because the voucher > >> draft just sets up the environment. The patent is primarily concerned with > >> "offline bootstrapping" (e.g., booting off a USB flash drive), but it may > >> have some applicability to this draft. Please review and let me know. > >> > >> Kent > >> > >> > >> ===== original message ===== > >> > >> Dear authors of ANIMA draft-ietf-anima-bootstrapping-keyinfra > >> > >> As the document shepherd, i am hereby asking each of you to confirm > >> that any and all appropriate IPR disclosures required for full conformance > >> with the provisions of BCP 78 and BCP 79 have already been filed? > >> > >> Currently, there are two disclosures mentioned: > >> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dietf-2Danima-2Dbootstrapping-2Dkeyinfra&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=aUmDyJOX9lAznU-gnIOBXiJ8GWg7vbgP6bIAjQ6jBFE&s=9OhEIj9bViZjDM-VnPjRuJvXrRQEFhT1KoBG7DfTu6E&e= > >> > >> Hint: > >> > >> "I am not aware of any IPR against draft-ietf-anima-bootstrapping-keyinfra > >> that have not already been disclosed" > >> > >> Is a perfect answer to the question raised by this email (if it is true). > >> But remember that you are expected to be aware of all IPR with your name on it. > >> > >> Cheers > >> Toerless > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de From nobody Sat Jul 7 12:02:15 2018 Return-Path: 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 D1166130EA1 for ; Sat, 7 Jul 2018 12:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 jg0EHaK35cXe for ; Sat, 7 Jul 2018 12:02:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA13F130E6C for ; Sat, 7 Jul 2018 12:02:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F0A8C20091; Sat, 7 Jul 2018 15:17:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 061332677; Sat, 7 Jul 2018 14:58:53 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0348F2674; Sat, 7 Jul 2018 14:58:53 -0400 (EDT) From: Michael Richardson To: "Anoop Kumar Pandey" cc: anima@ietf.org In-Reply-To: <007b01d414f8$313d68a0$93b839e0$@cdac.in> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2018 19:02:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anoop Kumar Pandey wrote: > When a device is purchased in real world, usually an invoice is issue= d in the > name of the purchaser with stamp of vendor/manufacturer. > I propose that similarly, a digital invoice can be issued which will = contain > the public key(s) of the and digitally signe= d by the > manufacturer. The digital invoice may be embedded in the pledge along= with > the IDevID. That's an interesting idea, perhaps you could write it up in the form of an Internet-Draft? Then I could make sure that I fully understand your proposal. It seems very difficult to make digitally signed invoices occur in the real world, given the constrained of the supply chain. Still, BRSKI makes provisions for higher security if the supply chain is integrated. I once proposed something similar using signed certficates: https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5y= qfRm0n00 In effect, the voucher artifact that we created in RFC8366 replaces these certificates with purpose built signed artifacts that expresses what the invoice attempts to express. > When a pledge starts the registration process, it will present the di= gital > invoice along with IDevID. The JRC can verify the digital signature o= f the > manufacturer on the digital invoice and sent a signed note of accepta= nce to > the pledge. The pledge can verify the signed note using the public ke= y(s) > mentioned in the digital invoice, thereby verifying its true owner. A pledge which has sat in a warehouse for a year before being sold to an owner will not have the invoice on it yet. That's okay, because the invoic= e, being digitally signed, could be retrieved from another place, and that's effectively what the BRSKI-MASA protocol *does*. If the invoice needs to be loaded into the Pledge via a secure-out-of-band mechanism, (i.e. during the manufacturing process), then the Pledge could also be fully configured, and could include a simple PSK too. This is the approach which is being used in draft-ietf-6tisch-minimal-security. Ultimately, it's not the JRC which is suspicious of who the Pledge's owner is, it's the Pledge which does not know who owns it. > This process with eliminate all the communication overhead with MASA = and > multiple level verification (voucher request, voucher, telemetry etc = at > JRC/MASA/Pledge). Yes, it does, at the cost of making every device in the warehouse unique to= a specific customer. If I may make an analogy to distribution of movies, you are suggesting that netflix go back to mailing DVDs to people. > From security point of view: Given that the digital invoice is digita= lly > signed by manufacturer, the public key of domain owner embedded in the > digital invoice can=E2=80=99t be changed, otherwise verification of d= igital signature > of manufacturer at JRC end will fail. > Requesting you to give your comments as it will simplify the protocol. > P.S.: As you had earlier mentioned =E2=80=9COn resale, the device sho= uld be put > through a factory reset to clear things. The MASA will have to be wil= ling to > issue a new voucher to the new domain owner..=E2=80=9D; here also, ma= nufacturer may > issue a new digital invoice in case of resale. yes, that's true. But, since you said that the invoice is in the Pledge, t= he manufacturer would have to take the device back to do that. The reason for all the JRC,MASA etc, is so that we do not need to have the manufacturer touch the device a second time. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW0ENaYCLcPvd0N1lAQIv4wgAmuNp98zw1yLQGAOXIQk45GrY9isktRR1 lWDShK1UgxWUcAcFJKCwEZateOwIWYXlcweqAuF0CbXcJkCoKNuecVU/XJmPEUn4 ko1y8Z5IpHHUAYNGMHjBhyfkc1iJ9M7foz1ICMW4ovh96Y//XK8TiuUcSGJvZpio Ekv24PonedT3GYI1yQE5eAAYnewJoS+M7xv6RXKsHUSBoJLj1xT9T2okeX3zRdyj fGOyvq9K5AJ8K7nfv5uK2LSWDCXEmcVQD/tBElcyKjRtWAo77wevMlPDCIAfqy04 WLi2XbmLonZqNGA+ziL+GxA5MYrXJx/dCvf6R4L7Xp0l+XkSikdLMA== =vKee -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 8 19:54:14 2018 Return-Path: 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 A54D0130DDE; Sun, 8 Jul 2018 19:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 O5Y-F45HVOXK; Sun, 8 Jul 2018 19:54:11 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 49EAF1294D7; Sun, 8 Jul 2018 19:54:11 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6B6A3ACD41AA7; Mon, 9 Jul 2018 03:54:08 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 9 Jul 2018 03:54:09 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Mon, 9 Jul 2018 10:54:03 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Primary ANIMA Agenda for IETF102 Thread-Index: AdQXL9yLlGOCmFIkRy+W0JIMa/yeTQ== Date: Mon, 9 Jul 2018 02:54:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92901119D9@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.174.115] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B92901119D9NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Primary ANIMA Agenda for IETF102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 02:54:13 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B92901119D9NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFOSU1BLA0KDQpUaGUgYmVsb3cgaXMgdGhlIGxpbmsgdG8gb3VyIHByaW1hcnkgQU5JTUEg YWdlbmRhLiBJdCBpcyBhIHN1YmplY3QgdG8gYmUgY2hhbmdlZC4NCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9tYXRlcmlhbHMvYWdlbmRhLTEwMi1hbmltYS0wMA0K DQpQbGVhc2Ugbm8gaGVzaXRhdGUgdG8gY29udGFjdCB0aGUgY2hhaXIgZm9yIGFueSBtaXNzIG9y IG1pc3Rha2UuDQoNClJlZ2FyZHMsDQoNClNoZW5nDQo= --_000_5D36713D8A4E7348A7E10DF7437A4B92901119D9NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRl ci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCi8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIiBzdHlsZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I aSwgQU5JTUEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgYmVsb3cgaXMgdGhlIGxpbmsgdG8gb3Vy IHByaW1hcnkgQU5JTUEgYWdlbmRhLiBJdCBpcyBhIHN1YmplY3QgdG8gYmUgY2hhbmdlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy8xMDIvbWF0ZXJpYWxzL2FnZW5kYS0xMDItYW5pbWEtMDAiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL2FnZW5kYS0xMDItYW5pbWEtMDA8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugbm8gaGVzaXRhdGUgdG8gY29udGFjdCB0aGUgY2hh aXIgZm9yIGFueSBtaXNzIG9yIG1pc3Rha2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+U2hlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B92901119D9NKGEML515MBXchi_-- From nobody Sun Jul 8 20:19:32 2018 Return-Path: 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 C210C130E96 for ; Sun, 8 Jul 2018 20:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u6kCSmv-lyRn for ; Sun, 8 Jul 2018 20:19:29 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3F3130E0F for ; Sun, 8 Jul 2018 20:19:29 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id y5-v6so959607pgv.1 for ; Sun, 08 Jul 2018 20:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=p9JOlgouTckGI479FINn38k8cI3pcOaLIQVXNDODagc=; b=crpkEFGQM9B6ftKzo8BC/580SC7ehl0be1eJNF4g4JIBe3UFNKlLn5xMJQIDxy/ujd o0Bf1L7fTl+fHHqJ9zvNMsdz4J4bJt9q0tOGrqIS96OK37leXoGb2lk7exRs6Wy1P7St SIAl4JrK8LUhAwvaV1TTRG3WEuocpkQHY7uE+Rtl4tTwq13HQ6ZzPm4tbcdPaUUIZO1a sZC/yMkOJYNONEpLivcS+y2d92b2rk1GXNWgk/ZmExSLb6WtQ9bGWZKXIuyBJz1TZlku w7GzLaD/TNsjp+D7L3DBc1cgSoeyFftLEsg7SuNmWfwDcSadOz3PF3rK0tfFEXOVukw1 t8jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p9JOlgouTckGI479FINn38k8cI3pcOaLIQVXNDODagc=; b=erPNo8AA6aI4OeyV0J/FDbUIM0HdmycVR1F9hL+3cl4BpY+e3kMUtpByyo8kQiu+N8 lZlZxaRR9U2Eujqg/k4hltqHnVTOH0moOQaTTzAh+ZZoSpaN5ZDDEH0tQfJkpSspabVK U7HuDokZrL8indS5Mk5vrb6KrVG35LmTNoh+YsgyZpo23T3MerXEjUWEOaedUWAH0Xlo 9YMaqCxYN+PYt4Urmj3AjUY7NP6ALL9NlTtjTSLLHC2ohv/m7CyRXmecK6UOtCamJu5Y lYI1SA+jDiawy2fccN9jFI4DiqaAGvjAXYz4FidUerw48rWFffidP2WcuJ2KZ6jN7gnQ 4fSg== X-Gm-Message-State: APt69E0KDJpsMsEWufgH7Tw8mbmrTI7i2u6jikiXuk3LO7G8BCe0f66V f391fq5DTYYBROQ6BvU/qeU= X-Google-Smtp-Source: AAOMgpdr7Lafw5CBhonMv/BJbuiXLAZUu58WRlO+wfWJkixyq2PvsPGEsTXiKMUMV7ltmJpcHpGA+A== X-Received: by 2002:a62:a119:: with SMTP id b25-v6mr17998370pff.163.1531106368620; Sun, 08 Jul 2018 20:19:28 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id s185-v6sm27266582pfb.116.2018.07.08.20.19.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 20:19:27 -0700 (PDT) To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B92901119D9@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Cc: "Liubing (Leo)" Message-ID: <8794180a-1dd7-e478-fe24-b3852d5b78c5@gmail.com> Date: Mon, 9 Jul 2018 15:19:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B92901119D9@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Primary ANIMA Agenda for IETF102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 03:19:31 -0000 Hi Sheng, My suggestion was to combine draft-ietf-anima-grasp-api, draft-carpenter-anima-asa-guidelines and draft-carpenter-anima-grasp-bulk, in one (quick) presentation, to save time. That is item 7, except that only one draft is linked. We need only one slide per draft, because there is little change. But item 7 overlaps with item 2a. Please let us know what you prefer. Brian On 09/07/2018 14:54, Sheng Jiang wrote: > Hi, ANIMA, > > The below is the link to our primary ANIMA agenda. It is a subject to be changed. > > https://datatracker.ietf.org/meeting/102/materials/agenda-102-anima-00 > > Please no hesitate to contact the chair for any miss or mistake. > > Regards, > > Sheng > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Jul 8 20:57:46 2018 Return-Path: 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 28706130E11 for ; Sun, 8 Jul 2018 20:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BWadHMhtRpF8 for ; Sun, 8 Jul 2018 20:57:42 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0569130DC6 for ; Sun, 8 Jul 2018 20:57:42 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id u16-v6so12646439pfh.3 for ; Sun, 08 Jul 2018 20:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GNcXbp7LjHj3L7iNQ6MjcUDoh83FzIcQtpsmIGUDqok=; b=FBwJOAuMLWJmUUWWbHETgZxW/vI3dr4fBaeDK67CQWltS3Grm6j9Z78gz1zYHNSDco UFn8bHr3VEPCUsAY8O19I0Biq5cWp9rKQpHTkPuFSd6bM6aP20VvCUUH35Ih6QGG2BSK CN2Zgfc1H2nyXFxCKyH7VqIWlDnOcQHDgq3ksOpiDU9ibk0Rde23BUfUegMiSU6FqQxe Is6Ic33dieANirFQSkwfMqjMoLL+TP9ESLBTWkSs9cE4/+snvwuIAPvn7fHV55hzeHIa 4shLDkSwYfz5OlTztVBoNk8aAB6gDJXXekQ5hi1KKte298fH3CehBbdcFAoY5Y3PFZAe R2Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GNcXbp7LjHj3L7iNQ6MjcUDoh83FzIcQtpsmIGUDqok=; b=CmBSGhAsgDXBEtbCYovQx9iFHmLUUcKY7Zh2cLf0VLyt1MXIT88TWzF97aokOqRlZW iqgue561JB9s7Mnt/1ew+3jedb4csGawij/QwrFDfPD9LfxbpXrlewjE1Jz+who7xtiQ bbLZuIFhNlPAPm744Fapv2j2zV5l1PJk4QKR1Twa3RSGepylwjK+RQqwk95TrTq3BJKo 6uGgo4r4RGLBrBWb4LcW5dPisB8JErF+NLWZ8Lvjw4mzbIWP5FZ+b/CaXQ9xMab0SdCh nB0fYNzgMvlNGq8kCYZrXXlyUM/Eco/glND1GQ7Lr0dPk3pA0xtq26jMJsNnm0WovtFi RztA== X-Gm-Message-State: APt69E3wmqWxt5ANdbh5O53/8Za6mPiUaGPUBFKngd0LjDTehSAyXUzb qFTEAkB9cQV0wLLZmUJhjAXjiA== X-Google-Smtp-Source: AAOMgpclINH+TSwpbZKOAXvk51TJ7NtuFZuWyYATGZkaRZ6jWlGvNwvgN/N0LwBEwWtTSZv2OZld1Q== X-Received: by 2002:a63:1b17:: with SMTP id b23-v6mr17581313pgb.275.1531108661923; Sun, 08 Jul 2018 20:57:41 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id x68-v6sm24011592pfb.138.2018.07.08.20.57.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 20:57:41 -0700 (PDT) To: Anima WG References: <153056233884.16161.8599345146300412702@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 9 Jul 2018 15:57:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153056233884.16161.8599345146300412702@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-eckert-anima-noc-autoconfig-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 03:57:45 -0000 Hi, I've had a very quick look at this draft, and it didn't ring any alarms. Just one small comment on the Security Considerations, which starts: > There is no protection against "unauthorized" ACP nodes to generate > service announcements, because there is no authorization scheme in > GRASP. That sounds a bit brutal. I suggest replacing the sentence: All ACP nodes are at the same level of trust, as a result of successfully enrolling and joining the ACP. However, there is currently no mechanism in GRASP for indicating and authorizing the role of a node. Therefore there is no protection against ACP nodes generating inappropriate service announcments. Regards Brian From nobody Sun Jul 8 21:22:58 2018 Return-Path: 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 BCDF4130F02 for ; Sun, 8 Jul 2018 21:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 071p7eqo80gQ for ; Sun, 8 Jul 2018 21:22:53 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FAF130E04 for ; Sun, 8 Jul 2018 21:22:53 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id c21-v6so8071694pfn.8 for ; Sun, 08 Jul 2018 21:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GaOIH+yppv1ZNvVib8E0WcMjFio7MoGAlN4F8ixvB98=; b=nTow7yxJ+sDXf6sfzngOVO/BctkT5I9nEXPg/utX1gnkSbPcjlCem0PW6hy6fQ9d98 hFtzmLTo3YMHPSwh0xZN8dXH9qUdKWScnK1m3YAyuDBJa5gqxQu8Kx3gtblxMJ6kZ9gs 02b72HF9bLhSwjPLWx4KUIIluIeVaJm3IukT+FqScd3oFFMnm62+POt6aE1aFlxP+dY/ c4c6gugrGK2wEbsUIlDJWKFMWjPFvkbL8Q0phyHAp5GShisa9786ayhJNBZBaTXjKpfk T+tQTXuYSNkMKfCCj3NFxMxvzkXEeClrrW4MGsUYt5xmtl9gEorDw3LUCrMUDYYTnrSQ Q8nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GaOIH+yppv1ZNvVib8E0WcMjFio7MoGAlN4F8ixvB98=; b=DuXDCvS2OH8KZtOCTUsX0qzkD+blr0A3olqAY6tKIpdczr+m99WyeJvdzAMf0NPsGb EY+wvNsnNn8CozNiv80GvGky3ypHWhP6ZoYL1q85MpnA0RQ22mol1GD9fr03dpaWHAOB rXGgEHh2nu+0tZ+XQ1IvlDcL/Cu0z2Q8YVQIuN7+LgMjEvqO5lEn1cKqp6S7xGVcEV59 NIEm/DcML/WA0Yb2vShAF+AIEWalUDXYTiQ0OCY0TO//QmbIPLgitZnGt819HG+CcSl9 miIDO5UdhLpR97zNUVXHtAInENrOkFrYvn74vG+8xlYxB28NCqU9ExCgnfblyWlYmap0 SlDg== X-Gm-Message-State: APt69E02bXOq62dGtTb1Wkbb/IyjaaVIy96GwAYo8orrz+5G5/Q8dX7O gLsij2R8MeZPa22Qb4F3SRhAIg== X-Google-Smtp-Source: AAOMgpfPYUb1XObJ2FYwSM7pykn7nfG9sH2uHZvoTFTFXJ6HxxYRqXu7W4PUA4JsRJCni4pcAQXgYg== X-Received: by 2002:a63:6a45:: with SMTP id f66-v6mr17026550pgc.81.1531110172753; Sun, 08 Jul 2018 21:22:52 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id f2-v6sm10441147pge.39.2018.07.08.21.22.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 21:22:51 -0700 (PDT) From: Brian E Carpenter To: Anima WG References: <150939968366.7857.10812413552277328001@ietfa.amsl.com> Message-ID: Date: Mon, 9 Jul 2018 16:22:49 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <150939968366.7857.10812413552277328001@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-eckert-anima-grasp-dnssd-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2018 04:22:56 -0000 I am repeating below my comments previously made on the -00 version, since they still apply to -01. FYI there is some hacked-together Python3 code for the GRASP part of this at https://github.com/becarpenter/graspy/blob/master/AskDNSSD2.py and https://github.com/becarpenter/graspy/blob/master/GetDNSSD2.py The code has zero production value but it validates the GRASP objective syntax in the draft against real-world DNSSD examples. ---- Hi, I think this draft raises an important topic. In the early days of ANIMA we had quite some discussion about embedding discovery in GRASP rather than simply using DNS-SD. I think we took the right decision, since GRASP objectives are a very flexible concept, only one application being a mapping to a traditional 'service'. But this left open the question of how to link the ANI tools to traditional services when necessary. I think this a necessary next step for ANIMA. I think the general direction is reasonable, but I don't understand DNS-SD enough to be sure if it all works. From a first reading, I have a few questions and comments: > 2.2. Objective Value Reuseable Elements Structure > > Because service discovery, as explained in the prior section, needs > to utilize different objectives, it requires cross-objective > standardized encoding of the elements of services. GRASP did not > define standardized message elements for the message body (called > "objective-value") of GRASP messages. I'd like to insert "intentionally" before "did not define". This was left open so that we can have effectively infinite extensibility of the syntax and semantics of GRASP. Therefore, considering the next sentence: > Therefore, this document introduces such a feature. I'd like it to be clear that it is intended for SRV.* and NAME.* objectives. (If people want to use the "@rfcXXX" construct elsewhere, that's fine, but we need to keep all the existing extensibility.) Also, should we add a convention that private use objectives may use the same feature, e.g. 411:SRV.example ? Some details and nits: s/// > 2.3.3. Name Element > > The NAME, elements is meant to provide basic name resolution s/NAME,/NAME./ > ipv6-address-option = [O_IPv4_ADDRESS, ipv6-address] > ipv4-address-option = [O_IPv6_ADDRESS, ipv6-address] 1) Check your 6's and 4's ;-) 2) It's confusing that these are different from the basic GRASP options: [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number] It costs almost nothing in CBOR to include null values for the protocol and port. If you use the same option format as basic GRASP, it will remove confusion and very likely save code. > 5. IANA Considerations > > This document requests a new "GRASP Objective Value Standard > Elements" table in the GRASP Parameter Registrar. The values in this > table are names and a unique numerical value assigned to each name. > Future values MUST be assigned using the RFC Required policy Do you really want "RFC Required"? We chose "Specification Required" for GRASP objectives in general, which still requires Expert Review but with less imposed bureaucracy. Regards Brian From nobody Mon Jul 9 19:07:10 2018 Return-Path: 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 27ADD130EE4; Mon, 9 Jul 2018 19:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 qeTzFJUpE7Mv; Mon, 9 Jul 2018 19:07:06 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1641130EE2; Mon, 9 Jul 2018 19:07:03 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C156D58C4B3; Tue, 10 Jul 2018 04:06:59 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B14934401A4; Tue, 10 Jul 2018 04:06:59 +0200 (CEST) Date: Tue, 10 Jul 2018 04:06:59 +0200 From: Toerless Eckert To: Michael.H.Behringer@gmail.com Cc: anima@ietf.org, draft-ietf-anima-reference-model@ietf.org Message-ID: <20180710020659.mwfqh52ydagts3r3@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Michael: Nit suggestion for draft-ietf-anima-reference-model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:07:08 -0000 (not sure which hat i should wear for this email ... i guess it mostly my personal opinion): Michael (dear editor) One nit fix suggestion for whenever you'll do a rev because of IESG feedback: I have just noticed that some tooling, at least from Jari (http://www.arkko.com/tools/allstats) is also taking contributors into account when listing RFCs. Datatracker does not (yet) do this, but i want to suggest it to them given how i feel that its valuable to more explicitly givecredit to the contributor status (aka: list RFCs someone contributed to on their datatracker personal page). Wrt. to the anima reference model: If would be good if you could put the email address of each contributor in parenthesis behind the contributors name. This should help any parsing tool trying to identify/ match contributors. Also, please move the contributors section before the Acknowledgements section - unless you disagree that thats the more appropriate order. Thanks! toerless From nobody Mon Jul 9 23:06:46 2018 Return-Path: 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 D3636130DFA for ; Mon, 9 Jul 2018 23:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 xnqpS6khUmqE for ; Mon, 9 Jul 2018 23:06:42 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABAE130EFC for ; Mon, 9 Jul 2018 23:06:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1B5DE58C4B3; Tue, 10 Jul 2018 08:06:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0901E4401A4; Tue, 10 Jul 2018 08:06:35 +0200 (CEST) Date: Tue, 10 Jul 2018 08:06:35 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20180710060635.wrhsdt7nuhyvaxr2@faui48f.informatik.uni-erlangen.de> References: <153056233884.16161.8599345146300412702@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] role management in ANI/NIMA (was: Re: I-D Action: draft-eckert-anima-noc-autoconfig-00.txt) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 06:06:45 -0000 Thanks Brian, as always, great recommendation. It would be great if followup work in ANIMA would tackle the problem of role management. In the case of this drafts simple view at the world its a simple master/slave role assignment: You have few master nodes such as those in the NOC and registrars that are still "manually" configured, and a much larger number of "zero-touch" slave nodes (all the other nodes) that are controlled by the masters via a combination of ANIMA/ANI and SDN. And we could easily add this model via simple binary distinctions in the Domain Certificates. And appropriate signing element in GRASP messages. I just wonder if its worth tackling this role management problem if we only have an idea how to solve this simple "SDN"'ish case. Would be a lot more useful if we had a more generalized solution that would also work in more autonomic networks with a lot more ASA - aka: how do we manage the privileges/roles of ASAs... ? The classic solution is probably role/privilege assignment from those NOC-master nodes. And if such schemes can distribute appropriate credentials (role certificates), we can easily add this too. Then again, i think more fully distributed, autonomic networks might want to have a more innovative solution approach to roles. There is for example the proposal direction we wanted to present in DINRG to use blockchain/distributed ledger technologies. Or in other words: An ASA could ultimately raise to a particular role by collecting credit in the blockchain through "proof of doing a good job and being trustworthy". This would be cool stuff to get into ANIMA, but of course, i at this point in time i am no sure how far away this type of technology is from being applicable to IETF (as opposed to being refined in IRTF). Cheers Toerless On Mon, Jul 09, 2018 at 03:57:38PM +1200, Brian E Carpenter wrote: > Hi, > > I've had a very quick look at this draft, and it didn't ring any alarms. > Just one small comment on the Security Considerations, which starts: > > > There is no protection against "unauthorized" ACP nodes to generate > > service announcements, because there is no authorization scheme in > > GRASP. > > That sounds a bit brutal. I suggest replacing the sentence: > > All ACP nodes are at the same level of trust, as a result of > successfully enrolling and joining the ACP. However, there is > currently no mechanism in GRASP for indicating and authorizing > the role of a node. Therefore there is no protection against ACP > nodes generating inappropriate service announcments. > > Regards > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jul 9 23:30:05 2018 Return-Path: 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 C3D38129C6B for ; Mon, 9 Jul 2018 23:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 ZxpYYmxFu8Ar for ; Mon, 9 Jul 2018 23:30:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E7D1277C8 for ; Mon, 9 Jul 2018 23:30:00 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 63E0D58C4B3; Tue, 10 Jul 2018 08:29:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 519174401A4; Tue, 10 Jul 2018 08:29:56 +0200 (CEST) Date: Tue, 10 Jul 2018 08:29:56 +0200 From: Toerless Eckert To: Michael Richardson Cc: Anoop Kumar Pandey , anima@ietf.org Message-ID: <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5778.1530989932@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 06:30:04 -0000 Anoop: To rephrase from Michaels reply: You do not need any BRSKI protocol or voucher changes to do what you want. The pledge simply needs to locate the voucher locally, and when it connects to the registrar, it can skip the step of retrieving the voucher because it already does trust the registrar as it has the voucher locally. In fact, you can even use RFC7030. If you already have a voucher locally, you do not need BRSKI for voucher signalling. IMHO, you still want BRSKI (instead of just RFC7030) because of the proxy and the enrolment telemetry. This just leaves the whole painfull question Michael brings up: "how the heck do we get vouchers onto devices in the real world" ? This is IMHO where everybodies favourite options for managing "offline vouchers" come into play. There are a lot of vendor solutions where you feed those nodes information such as vouchers via USB sticks, or temporarily connected cellphones to the pledge. I think those solutions are not ideal because they do introduce another new "touch" to the pledge. But there are also simply a lot of options how to get the voucher into the registrar without having to use an online BRSKI-MASA connection. And then you just need to send the voucher from the registrar to the pledge using BRSKI: No new "touch" on the pledge, no BRSKI-MASA connection! The BRSKI document does allude to these options but does not necessarily detail them well enough for every uninitiated reader to understand the options. Followup documents refining individual interesting workflows would certainly be useful IMHO (contributor, not WG chair hat on). Cheers Toerless On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > > Anoop Kumar Pandey wrote: > > When a device is purchased in real world, usually an invoice is issued in the > > name of the purchaser with stamp of vendor/manufacturer. > > > I propose that similarly, a digital invoice can be issued which will contain > > the public key(s) of the and digitally signed by the > > manufacturer. The digital invoice may be embedded in the pledge along with > > the IDevID. > > That's an interesting idea, perhaps you could write it up in the form of an > Internet-Draft? Then I could make sure that I fully understand your > proposal. > > It seems very difficult to make digitally signed invoices occur in the real > world, given the constrained of the supply chain. Still, BRSKI makes > provisions for higher security if the supply chain is integrated. > > I once proposed something similar using signed certficates: > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00 > > In effect, the voucher artifact that we created in RFC8366 replaces these > certificates with purpose built signed artifacts that expresses what the > invoice attempts to express. > > > When a pledge starts the registration process, it will present the digital > > invoice along with IDevID. The JRC can verify the digital signature of the > > manufacturer on the digital invoice and sent a signed note of acceptance to > > the pledge. The pledge can verify the signed note using the public key(s) > > mentioned in the digital invoice, thereby verifying its true owner. > > A pledge which has sat in a warehouse for a year before being sold to an > owner will not have the invoice on it yet. That's okay, because the invoice, > being digitally signed, could be retrieved from another place, and that's > effectively what the BRSKI-MASA protocol *does*. > > If the invoice needs to be loaded into the Pledge via a secure-out-of-band > mechanism, (i.e. during the manufacturing process), then the Pledge could > also be fully configured, and could include a simple PSK too. This is the > approach which is being used in draft-ietf-6tisch-minimal-security. > > Ultimately, it's not the JRC which is suspicious of who the Pledge's owner > is, it's the Pledge which does not know who owns it. > > > This process with eliminate all the communication overhead with MASA and > > multiple level verification (voucher request, voucher, telemetry etc at > > JRC/MASA/Pledge). > > Yes, it does, at the cost of making every device in the warehouse unique to a > specific customer. If I may make an analogy to distribution of movies, > you are suggesting that netflix go back to mailing DVDs to people. > > > From security point of view: Given that the digital invoice is digitally > > signed by manufacturer, the public key of domain owner embedded in the > > digital invoice can???t be changed, otherwise verification of digital signature > > of manufacturer at JRC end will fail. > > > Requesting you to give your comments as it will simplify the protocol. > > > P.S.: As you had earlier mentioned ???On resale, the device should be put > > through a factory reset to clear things. The MASA will have to be willing to > > issue a new voucher to the new domain owner..???; here also, manufacturer may > > issue a new digital invoice in case of resale. > > yes, that's true. But, since you said that the invoice is in the Pledge, the > manufacturer would have to take the device back to do that. > > The reason for all the JRC,MASA etc, is so that we do not need to have the > manufacturer touch the device a second time. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jul 9 23:43:38 2018 Return-Path: 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 99FC0130E1B for ; Mon, 9 Jul 2018 23:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 DPQWof5peTtw for ; Mon, 9 Jul 2018 23:43:33 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE821277C8 for ; Mon, 9 Jul 2018 23:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18465; q=dns/txt; s=iport; t=1531205013; x=1532414613; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=iuN73WmCEQiTuK1bSwWFrJh13UVMqVDkVGEBhcUBF6A=; b=lHEgwN31cYKvkygpRr9FhI1dLVf72i4cuxTTrPC1Mmm+bj3EMGifG1rd Bqnu/86nzYT+2fqd0FtSyFrbzvFnzMhlDcyTw/WJaAja8IclbwuI1SuA8 YO+ZtCQ24PijGA5parb9A86N3Eu1lFfsb7jnlOruEb7i4vq/Gu0Reb5pW U=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.51,333,1526342400"; d="asc'?scan'208,217";a="5075859" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 06:43:31 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w6A6hUos023934; Tue, 10 Jul 2018 06:43:31 GMT To: Toerless Eckert , Michael Richardson Cc: Anoop Kumar Pandey , anima@ietf.org References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Tue, 10 Jul 2018 08:43:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xOm3G5mfnkAmxJDhfkJSvR4keypa043pH" Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 06:43:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xOm3G5mfnkAmxJDhfkJSvR4keypa043pH Content-Type: multipart/mixed; boundary="T7lMgTRMVr7SVzd1HCnuN9lQXOMNgbj3B"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert , Michael Richardson Cc: Anoop Kumar Pandey , anima@ietf.org Message-ID: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> --T7lMgTRMVr7SVzd1HCnuN9lQXOMNgbj3B Content-Type: multipart/alternative; boundary="------------C24369761E00ACE4692CB1FF" Content-Language: en-US This is a multi-part message in MIME format. --------------C24369761E00ACE4692CB1FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Toerless, When we look at this scenario, we should consider several factors: * The manufacturer is in a position to control both the MASA and the pledge.=C2=A0 That's useful because it means that there is less interoperability friction if the manufacturer wants to pass additional parameters between the pledge and the manufacturer, so long as the registrar doesn't interfere. * In WiFi we have two additional issues: a device needs to do ANIMA, but it needs to be authorized in some manner to do so.=C2=A0 * The second issue is one of network selection.=C2=A0 There is a need f= or the pledge to really *know* that this is The network when 802.11 is involved.=C2=A0 What a manufacturer wants to avoid is a pledge joinin= g a network where the MASA just does the logging and does no validation, without any other means to determine that the device is on the correct network.=C2=A0 Otherwise, the pledge (we could call it the "station" in this context) could simply home to the wrong network, and even resetting the device won't get you to the right network. Owen will present something in Montreal that begins the discussion of these issues. Eliot On 10.07.18 08:29, Toerless Eckert wrote: > Anoop: > > To rephrase from Michaels reply:=20 > > You do not need any BRSKI protocol or voucher changes to do what you wa= nt. > > The pledge simply needs to locate the voucher locally, and when it > connects to the registrar, it can skip the step of retrieving > the voucher because it already does trust the registrar > as it has the voucher locally. > > In fact, you can even use RFC7030. If you already have a voucher locall= y, > you do not need BRSKI for voucher signalling. IMHO, you still want > BRSKI (instead of just RFC7030) because of the proxy and the > enrolment telemetry. > > This just leaves the whole painfull question Michael brings up: > > "how the heck do we get vouchers onto devices in the real world" ? > This is IMHO where everybodies favourite options for managing > "offline vouchers" come into play. There are a lot of vendor > solutions where you feed those nodes information such as vouchers > via USB sticks, or temporarily connected cellphones to the pledge.=20 > > I think those solutions are not ideal because they do introduce > another new "touch" to the pledge. But there are also simply > a lot of options how to get the voucher into the registrar > without having to use an online BRSKI-MASA connection. And then you > just need to send the voucher from the registrar to the pledge > using BRSKI: No new "touch" on the pledge, no BRSKI-MASA > connection! > > The BRSKI document does allude to these options but does not > necessarily detail them well enough for every uninitiated reader > to understand the options. Followup documents refining individual > interesting workflows would certainly be useful > IMHO (contributor, not WG chair hat on). > > > Cheers > Toerless > > > On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: >> Anoop Kumar Pandey wrote: >> > When a device is purchased in real world, usually an invoice is = issued in the >> > name of the purchaser with stamp of vendor/manufacturer. >> >> > I propose that similarly, a digital invoice can be issued which = will contain >> > the public key(s) of the and digitally = signed by the >> > manufacturer. The digital invoice may be embedded in the pledge = along with >> > the IDevID. >> >> That's an interesting idea, perhaps you could write it up in the form = of an >> Internet-Draft? Then I could make sure that I fully understand your >> proposal. >> >> It seems very difficult to make digitally signed invoices occur in the= real >> world, given the constrained of the supply chain. Still, BRSKI makes >> provisions for higher security if the supply chain is integrated. >> >> I once proposed something similar using signed certficates: >> https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-H= U9s5yqfRm0n00 >> >> In effect, the voucher artifact that we created in RFC8366 replaces th= ese >> certificates with purpose built signed artifacts that expresses what t= he >> invoice attempts to express. >> >> > When a pledge starts the registration process, it will present t= he digital >> > invoice along with IDevID. The JRC can verify the digital signat= ure of the >> > manufacturer on the digital invoice and sent a signed note of ac= ceptance to >> > the pledge. The pledge can verify the signed note using the publ= ic key(s) >> > mentioned in the digital invoice, thereby verifying its true own= er. >> >> A pledge which has sat in a warehouse for a year before being sold to = an >> owner will not have the invoice on it yet. That's okay, because the i= nvoice, >> being digitally signed, could be retrieved from another place, and tha= t's >> effectively what the BRSKI-MASA protocol *does*. >> >> If the invoice needs to be loaded into the Pledge via a secure-out-of-= band >> mechanism, (i.e. during the manufacturing process), then the Pledge co= uld >> also be fully configured, and could include a simple PSK too. This is= the >> approach which is being used in draft-ietf-6tisch-minimal-security. >> >> Ultimately, it's not the JRC which is suspicious of who the Pledge's o= wner >> is, it's the Pledge which does not know who owns it. >> >> > This process with eliminate all the communication overhead with = MASA and >> > multiple level verification (voucher request, voucher, telemetry= etc at >> > JRC/MASA/Pledge). >> >> Yes, it does, at the cost of making every device in the warehouse uniq= ue to a >> specific customer. If I may make an analogy to distribution of movie= s, >> you are suggesting that netflix go back to mailing DVDs to people. >> >> > From security point of view: Given that the digital invoice is d= igitally >> > signed by manufacturer, the public key of domain owner embedded = in the >> > digital invoice can???t be changed, otherwise verification of di= gital signature >> > of manufacturer at JRC end will fail. >> >> > Requesting you to give your comments as it will simplify the pro= tocol. >> >> > P.S.: As you had earlier mentioned ???On resale, the device shou= ld be put >> > through a factory reset to clear things. The MASA will have to b= e willing to >> > issue a new voucher to the new domain owner..???; here also, man= ufacturer may >> > issue a new digital invoice in case of resale. >> >> yes, that's true. But, since you said that the invoice is in the Pled= ge, the >> manufacturer would have to take the device back to do that. >> >> The reason for all the JRC,MASA etc, is so that we do not need to have= the >> manufacturer touch the device a second time. >> >> -- >> ] Never tell me the odds! | ipv6 mesh ne= tworks [ >> ] Michael Richardson, Sandelman Software Works | network arch= itect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on ra= ils [ >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >> >> >> > > >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > --------------C24369761E00ACE4692CB1FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Toerless,

When we look at this scenario, we should consider several factors:

  • The manufacturer is in a position to control both the MASA and the pledge.=C2=A0 That's useful because it means that there is le= ss interoperability friction if the manufacturer wants to pass additional parameters between the pledge and the manufacturer, so long as the registrar doesn't interfere.
  • In WiFi we have two additional issues: a device needs to do ANIMA, but it needs to be authorized in some manner to do so.=C2=A0=
  • The second issue is one of network selection.=C2=A0 There is a = need for the pledge to really know that this is The network when 802.11 is involved.=C2=A0 What a manufacturer wants to avoid= is a pledge joining a network where the MASA just does the logging and does no validation, without any other means to determine that the device is on the correct network.=C2=A0 Otherwise, the pledge (we could call it the "station" in this context) could simply home to the wrong network, and even resetting the device won't get you to the right network.

Owen will present something in Montreal that begins the discussion of these issues.

Eliot

On 10.07.18 08:29, Toerless Eckert wrote:
Anoop:

To rephrase from Michaels reply:=20

You do not need any BRSKI protocol or voucher changes to do what you want=
=2E

The pledge simply needs to locate the voucher locally, and when it
connects to the registrar, it can skip the step of retrieving
the voucher because it already does trust the registrar
as it has the voucher locally.

In fact, you can even use RFC7030. If you already have a voucher locally,=

you do not need BRSKI for voucher signalling. IMHO, you still want
BRSKI (instead of just RFC7030) because of the proxy and the
enrolment telemetry.

This just leaves the whole painfull question Michael brings up:

"how the heck do we get vouchers onto devices in the real world" ?
This is IMHO where everybodies favourite options for managing
"offline vouchers" come into play. There are a lot of vendor
solutions where you feed those nodes information such as vouchers
via USB sticks, or temporarily connected cellphones to the pledge.=20

I think those solutions are not ideal because they do introduce
another new "touch" to the pledge. But there are also simply
a lot of options how to get the voucher into the registrar
without having to use an online BRSKI-MASA connection. And then you
just need to send the voucher from the registrar to the pledge
using BRSKI: No new "touch" on the pledge, no BRSKI-MASA
connection!

The BRSKI document does allude to these options but does not
necessarily detail them well enough for every uninitiated reader
to understand the options. Followup documents refining individual
interesting workflows would certainly be useful
IMHO (contributor, not WG chair hat on).


Cheers
    Toerless


On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote:

Anoop Kumar Pandey <anoop@cdac.in> wrote:
    > When a device is purchased in real world, usually an invoice is =
issued in the
    > name of the purchaser with stamp of vendor/manufacturer.

    > I propose that similarly, a digital invoice can be issued which =
will contain
    > the public key(s) of the <domain owner(s)/JRC(s)> and digi=
tally signed by the
    > manufacturer. The digital invoice may be embedded in the pledge =
along with
    > the IDevID.

That's an interesting idea, perhaps you could write it up in the form of =
an
Internet-Draft?  Then I could make sure that I fully understand your
proposal.

It seems very difficult to make digitally signed invoices occur in the re=
al
world, given the constrained of the supply chain.  Still, BRSKI makes
provisions for higher security if the supply chain is integrated.

I once proposed something similar using signed certficates:
  https://mailarchiv=
e.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

In effect, the voucher artifact that we created in RFC8366 replaces these=

certificates with purpose built signed artifacts that expresses what the
invoice attempts to express.

    > When a pledge starts the registration process, it will present t=
he digital
    > invoice along with IDevID. The JRC can verify the digital signat=
ure of the
    > manufacturer on the digital invoice and sent a signed note of ac=
ceptance to
    > the pledge. The pledge can verify the signed note using the publ=
ic key(s)
    > mentioned in the digital invoice, thereby verifying its true own=
er.

A pledge which has sat in a warehouse for a year before being sold to an
owner will not have the invoice on it yet.  That's okay, because the invo=
ice,
being digitally signed, could be retrieved from another place, and that's=

effectively what the BRSKI-MASA protocol *does*.

If the invoice needs to be loaded into the Pledge via a secure-out-of-ban=
d
mechanism, (i.e. during the manufacturing process), then the Pledge could=

also be fully configured, and could include a simple PSK too.  This is th=
e
approach which is being used in draft-ietf-6tisch-minimal-security.

Ultimately, it's not the JRC which is suspicious of who the Pledge's owne=
r
is, it's the Pledge which does not know who owns it.

    > This process with eliminate all the communication overhead with =
MASA and
    > multiple level verification (voucher request, voucher, telemetry=
 etc at
    > JRC/MASA/Pledge).

Yes, it does, at the cost of making every device in the warehouse unique =
to a
specific customer.   If I may make an analogy to distribution of movies,
you are suggesting that netflix go back to mailing DVDs to people.

    > From security point of view: Given that the digital invoice is d=
igitally
    > signed by manufacturer, the public key of domain owner embedded =
in the
    > digital invoice can???t be changed, otherwise verification of di=
gital signature
    > of manufacturer at JRC end will fail.

    > Requesting you to give your comments as it will simplify the pro=
tocol.

    > P.S.: As you had earlier mentioned ???On resale, the device shou=
ld be put
    > through a factory reset to clear things. The MASA will have to b=
e willing to
    > issue a new voucher to the new domain owner..???; here also, man=
ufacturer may
    > issue a new digital invoice in case of resale.

yes, that's true.  But, since you said that the invoice is in the Pledge,=
 the
manufacturer would have to take the device back to do that.

The reason for all the JRC,MASA etc, is so that we do not need to have th=
e
manufacturer touch the device a second time.

--
]               Never tell me the odds!                 | ipv6 mesh netwo=
rks [
]   Michael Richardson, Sandelman Software Works        | network archite=
ct  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rai=
ls    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software =
Works
 -=3D IPv6 IoT consulting =3D-







_______________________________________________
Anima mailing list
Anim=
a@ietf.org
https://www.ietf.org/mailman/listinfo/anima

--------------C24369761E00ACE4692CB1FF-- --T7lMgTRMVr7SVzd1HCnuN9lQXOMNgbj3B-- --xOm3G5mfnkAmxJDhfkJSvR4keypa043pH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltEVZIACgkQh7ZrRtnS ejPbVwgAuIzacTh6VULeUuyTpk7u9f/4ztvh9jT3oi/+gV1dN/Cts55LOKeUIYpj iONHzNjDlDXXqFyFFfNR5Y0oWTvuA+Yeii2FALYAAscrlEiH7w94BmrdEJRxI1Tj 3VCerFO6hjL464D6rqoRhpcXJsBKKEx7wFVzUIm8PQYcNnNh0W1AEvcmU9jhsjmg QNbYiKYPEyeknfDlTq/WeLb2URVHaEnLoEbGVTdle9hlSY6SsS1RCLVIsr1hpSM+ A+J+fn3NFHawPX7PP5M3F+S3tFkAQ+hQQHvwWRvayf2WQiNl8NgDd/aMtM7x8PbE WRwn7p2LWObkwkU6bTijjutl7KBFZw== =ZWkM -----END PGP SIGNATURE----- --xOm3G5mfnkAmxJDhfkJSvR4keypa043pH-- From nobody Tue Jul 10 00:16:11 2018 Return-Path: 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 4A3EC130F14 for ; Tue, 10 Jul 2018 00:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 j0QRLU_B2K8N for ; Tue, 10 Jul 2018 00:16:05 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580F8130F07 for ; Tue, 10 Jul 2018 00:16:04 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w6A7FOLX020295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jul 2018 12:45:29 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w6A7Eomi027695; Tue, 10 Jul 2018 12:44:50 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w6A7EkxC002710; Tue, 10 Jul 2018 12:44:48 +0530 From: "Anoop Kumar Pandey" To: "'Toerless Eckert'" , "'Michael Richardson'" Cc: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> Date: Tue, 10 Jul 2018 12:44:45 +0530 Message-ID: <004901d4181d$b02f8710$108e9530$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01D4184B.C9EB4580" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-in Thread-Index: AQFAzvEfV8gDGlfdQPkEn1OSJPe5FQHjX3D4AdayjmKlkMg4sA== X-CDAC-PUNE-MailScanner-ID: w6A7Eomi027695 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.984, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_40 -0.18, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w6A7FOLX020295 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 07:16:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01D4184B.C9EB4580 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Toerless >The pledge simply needs to locate the voucher locally, and when it connects to the registrar, it can skip the step of retrieving the voucher because it already does trust the registrar as it has the voucher locally. The pledge may have the voucher locally, but how will it know that the domain it is going to register is the real owner. It may be some other domain. For that, I suggested use of public key of owners in the digital invoice which can be used to verify the signed acceptance sent by JRC. Once pledge and JRC have verified each other, enrolment can go on using EST. I want to eliminate the communication overhead or MASA itself. Toerless>I think those solutions are not ideal because they do introduce another new "touch" to the pledge. Anyway manufacturer is installing an IDevID, they can also install a digital invoice (or voucher). Toerless> The BRSKI document does allude to these options but does not necessarily detail them well enough for every uninitiated reader to understand the options. Why leave something to someone's imagination. All necessary details/angles/options can be entailed if it's provisioned in the BRSKI already so that no stone is left unturned. @Michael: You mentioned "Yes, it does, at the cost of making every device in the warehouse unique to a > specific customer. If I may make an analogy to distribution of movies, > you are suggesting that netflix go back to mailing DVDs to people." When a device is manufactured, it will only have IDevID. But when a device is sold; before shipping, digital invoice may be embedded in it. In this way the device may lie in the warehouse for years but unless it has been sold, it is not unique to a customer. Michael"> Ultimately, it's not the JRC which is suspicious of who the Pledge's > owner is, it's the Pledge which does not know who owns it." I assure you that pledge can verify the JRC using the public key put in the digital invoice and using it to verify the digitally signed acceptance note from JRC. Regards, Anoop -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de] Sent: 10 July 2018 12:00 To: Michael Richardson Cc: Anoop Kumar Pandey ; anima@ietf.org Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg Anoop: To rephrase from Michaels reply: You do not need any BRSKI protocol or voucher changes to do what you want. The pledge simply needs to locate the voucher locally, and when it connects to the registrar, it can skip the step of retrieving the voucher because it already does trust the registrar as it has the voucher locally. In fact, you can even use RFC7030. If you already have a voucher locally, you do not need BRSKI for voucher signalling. IMHO, you still want BRSKI (instead of just RFC7030) because of the proxy and the enrolment telemetry. This just leaves the whole painfull question Michael brings up: "how the heck do we get vouchers onto devices in the real world" ? This is IMHO where everybodies favourite options for managing "offline vouchers" come into play. There are a lot of vendor solutions where you feed those nodes information such as vouchers via USB sticks, or temporarily connected cellphones to the pledge. I think those solutions are not ideal because they do introduce another new "touch" to the pledge. But there are also simply a lot of options how to get the voucher into the registrar without having to use an online BRSKI-MASA connection. And then you just need to send the voucher from the registrar to the pledge using BRSKI: No new "touch" on the pledge, no BRSKI-MASA connection! The BRSKI document does allude to these options but does not necessarily detail them well enough for every uninitiated reader to understand the options. Followup documents refining individual interesting workflows would certainly be useful IMHO (contributor, not WG chair hat on). Cheers Toerless On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > > Anoop Kumar Pandey < anoop@cdac.in> wrote: > > When a device is purchased in real world, usually an invoice is issued in the > > name of the purchaser with stamp of vendor/manufacturer. > > > I propose that similarly, a digital invoice can be issued which will contain > > the public key(s) of the and digitally signed by the > > manufacturer. The digital invoice may be embedded in the pledge along with > > the IDevID. > > That's an interesting idea, perhaps you could write it up in the form > of an Internet-Draft? Then I could make sure that I fully understand > your proposal. > > It seems very difficult to make digitally signed invoices occur in the > real world, given the constrained of the supply chain. Still, BRSKI > makes provisions for higher security if the supply chain is integrated. > > I once proposed something similar using signed certficates: > > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9 > s5yqfRm0n00 > > In effect, the voucher artifact that we created in RFC8366 replaces > these certificates with purpose built signed artifacts that expresses > what the invoice attempts to express. > > > When a pledge starts the registration process, it will present the digital > > invoice along with IDevID. The JRC can verify the digital signature of the > > manufacturer on the digital invoice and sent a signed note of acceptance to > > the pledge. The pledge can verify the signed note using the public key(s) > > mentioned in the digital invoice, thereby verifying its true owner. > > A pledge which has sat in a warehouse for a year before being sold to > an owner will not have the invoice on it yet. That's okay, because > the invoice, being digitally signed, could be retrieved from another > place, and that's effectively what the BRSKI-MASA protocol *does*. > > If the invoice needs to be loaded into the Pledge via a > secure-out-of-band mechanism, (i.e. during the manufacturing process), > then the Pledge could also be fully configured, and could include a > simple PSK too. This is the approach which is being used in draft-ietf-6tisch-minimal-security. > > Ultimately, it's not the JRC which is suspicious of who the Pledge's > owner is, it's the Pledge which does not know who owns it. > > > This process with eliminate all the communication overhead with MASA and > > multiple level verification (voucher request, voucher, telemetry etc at > > JRC/MASA/Pledge). > > Yes, it does, at the cost of making every device in the warehouse unique to a > specific customer. If I may make an analogy to distribution of movies, > you are suggesting that netflix go back to mailing DVDs to people. > > > From security point of view: Given that the digital invoice is digitally > > signed by manufacturer, the public key of domain owner embedded in the > > digital invoice can???t be changed, otherwise verification of digital signature > > of manufacturer at JRC end will fail. > > > Requesting you to give your comments as it will simplify the protocol. > > > P.S.: As you had earlier mentioned ???On resale, the device should be put > > through a factory reset to clear things. The MASA will have to be willing to > > issue a new voucher to the new domain owner..???; here also, manufacturer may > > issue a new digital invoice in case of resale. > > yes, that's true. But, since you said that the invoice is in the > Pledge, the manufacturer would have to take the device back to do that. > > The reason for all the JRC,MASA etc, is so that we do not need to have > the manufacturer touch the device a second time. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson < mcr+IETF@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_NextPart_000_004A_01D4184B.C9EB4580 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

To= erless >The pledge simply needs to locate the voucher locally, and when = it connects to the registrar, it can skip the step of retrieving the vouche= r because it already does trust the registrar as it has the voucher locally= .

 

The pledge may have the voucher locally, but how will = it know that the domain it is going to register is the real owner. It may b= e some other domain. For that, I suggested use of public key of owners in t= he digital invoice which can be used to verify the signed acceptance sent b= y JRC.

Once pledge and JRC have verified each other, enrolment can = go on using EST. I want to eliminate the communication overhead or MASA its= elf.

 

Toerless>I think those solutions are not ideal b= ecause they do introduce another new "touch" to the pledge.<= /o:p>

 

Anyway manufacturer is installing an IDevID, they can also install a= digital invoice (or voucher).

Toerless> The BRSKI document does allude to these options but does= not necessarily detail them well enough for every uninitiated reader to un= derstand the options.

Why= leave something to someone’s imagination. All necessary details/angl= es/options can be entailed if it’s provisioned in the BRSKI already s= o that no stone is left unturned.

 

 

@Michael: You mentioned

<= b>“Yes, it does, at the cost of making every device in the warehouse = unique to a

> specific cust= omer.   If I may make an analogy to distribution of movies,<= /o:p>

> you are suggesting that netfli= x go back to mailing DVDs to people.”


When a device is manufactured, it will only have IDevID. But= when a device is sold; before shipping, digital invoice may be embedded in= it. In this way the device may lie in the warehouse for years but unless i= t has been sold, it is not unique to a customer.

 

 = ;

Michael“> Ultimately, it's n= ot the JRC which is suspicious of who the Pledge's

> owner is, it's the Pledge which does not know wh= o owns it.”

 

I assure you that pledge can verify the JRC u= sing the public key put in the digital invoice and using it to verify the d= igitally signed acceptance note from JRC.

Regards,

Anoop

 = ;

-----Original Message-----
From: Toerless Eckert [mailto= :tte@cs.fau.de]
Sent: 10 July 2018 12:00
To: Michael Richardson <= mcr+ietf@sandelman.ca>
Cc: Anoop Kumar Pandey <anoop@cdac.in>; = anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in the BRS= KI - Reg

 

Anoop:

 =

To rephrase from Michaels reply:

 

You d= o not need any BRSKI protocol or voucher changes to do what you want.<= /o:p>

 

The pledge simply needs to locate the voucher locally, and when it conne= cts to the registrar, it can skip the step of retrieving the voucher becaus= e it already does trust the registrar as it has the voucher locally.

 

In fact, you can even use RFC7030. If you already have a voucher locally,= you do not need BRSKI for voucher signalling. IMHO, you still want BRSKI (= instead of just RFC7030) because of the proxy and the enrolment telemetry.<= o:p>

 

This just leaves the whole painfull question Michael brings up:

 

"how the heck do we get vouchers onto devices in the real world&q= uot; ?

This is IMHO where everybodies= favourite options for managing "offline vouchers" come into play= . There are a lot of vendor solutions where you feed those nodes informatio= n such as vouchers via USB sticks, or temporarily connected cellphones to t= he pledge.

 

I think those solutions are not ideal because they do i= ntroduce another new "touch" to the pledge. But there are also si= mply a lot of options how to get the voucher into the registrar without hav= ing to use an online BRSKI-MASA connection. And then you just need to send = the voucher from the registrar to the pledge using BRSKI: No new "touc= h" on the pledge, no BRSKI-MASA connection!

 

The BRSKI document= does allude to these options but does not necessarily detail them well eno= ugh for every uninitiated reader to understand the options. Followup docume= nts refining individual interesting workflows would certainly be useful IMH= O (contributor, not WG chair hat on).

 

 

Cheers

  &n= bsp; Toerless

 

 

On Sat, = Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote:

<= p class=3DMsoPlainText>>

> Ano= op Kumar Pandey <anoop@cdac.in> wrote:

>     > When a dev= ice is purchased in real world, usually an invoice is issued in the

>     > name of th= e purchaser with stamp of vendor/manufacturer.

>

>   = ;  > I propose that similarly, a digital invoice can be issued whic= h will contain

>   =   > the public key(s) of the <domain owner(s)/JRC(s)> and dig= itally signed by the

>  =    > manufacturer. The digital invoice may be embedded in the = pledge along with

>  &nb= sp;  > the IDevID.

> =

> That's an interesting idea, perhaps = you could write it up in the form

&g= t; of an Internet-Draft?  Then I could make sure that I fully understa= nd

> your proposal.

>

> I= t seems very difficult to make digitally signed invoices occur in the =

> real world, given the constrained of= the supply chain.  Still, BRSKI

> makes provisions for higher security if the supply chain is integrat= ed.

>

> I once proposed something similar using signed certficates:=

>  

> https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLl= huI-HU9

> s5yqfRm0n00

>

> In effect, the voucher artifact that we created in RFC8366 repla= ces

> these certificates with pur= pose built signed artifacts that expresses

> what the invoice attempts to express.

>

>  &n= bsp;  > When a pledge starts the registration process, it will pres= ent the digital

>   = ;  > invoice along with IDevID. The JRC can verify the digital sign= ature of the

>   &n= bsp; > manufacturer on the digital invoice and sent a signed note of acc= eptance to

>   &nbs= p; > the pledge. The pledge can verify the signed note using the public = key(s)

>     &= gt; mentioned in the digital invoice, thereby verifying its true owner.

>

> A pledge which has sat in a warehouse for a year before being sold= to

> an owner will not have the = invoice on it yet.  That's okay, because

> the invoice, being digitally signed, could be retrieved from= another

> place, and that's effe= ctively what the BRSKI-MASA protocol *does*.

>

> If the invoice nee= ds to be loaded into the Pledge via a

> secure-out-of-band mechanism, (i.e. during the manufacturing process= ),

> then the Pledge could also b= e fully configured, and could include a

> simple PSK too.  This is the approach which is being used in = draft-ietf-6tisch-minimal-security.

&= gt;

> Ultimately, it's not the JR= C which is suspicious of who the Pledge's

> owner is, it's the Pledge which does not know who owns it.<= /o:p>

>

>     > This process with eliminate all the com= munication overhead with MASA and

>= ;     > multiple level verification (voucher request= , voucher, telemetry etc at

> = ;    > JRC/MASA/Pledge).

>

> Yes, it does, at the= cost of making every device in the warehouse unique to a

> specific customer.   If I may make an a= nalogy to distribution of movies,

>= ; you are suggesting that netflix go back to mailing DVDs to people.

>

>     > From security point of view: Given that = the digital invoice is digitally

>=      > signed by manufacturer, the public key of dom= ain owner embedded in the

> &= nbsp;   > digital invoice can???t be changed, otherwise verifi= cation of digital signature

> = ;    > of manufacturer at JRC end will fail.

>

>&= nbsp;    > Requesting you to give your comments as it wil= l simplify the protocol.

>

>     > P.S.: As = you had earlier mentioned ???On resale, the device should be put=

>     > through a fac= tory reset to clear things. The MASA will have to be willing to<= /p>

>     > issue a new vo= ucher to the new domain owner..???; here also, manufacturer may<= /p>

>     > issue a new di= gital invoice in case of resale.

>=

> yes, that's true.  But, s= ince you said that the invoice is in the

> Pledge, the manufacturer would have to take the device back to do= that.

>

> The reason for all the JRC,MASA etc, is so that we do = not need to have

> the manufactur= er touch the device a second time.

&g= t;

> --

> ]         &n= bsp;     Never tell me the odds!    = ;             |= ipv6 mesh networks [

> ] &nb= sp; Michael Richardson, Sandelman Software Works    &nb= sp;   | network architect  [

> ]     <= span style=3D'color:windowtext;text-decoration:none'>mcr@sandelman.ca  http://www.sandelman.ca/  =       |   ruby on rails   = ; [

>

>

> --

> Michael Richardson <m= cr+IETF@sandelman.ca>, Sandelman Software Works 

> -=3D IPv6 IoT consulting =3D-

>

&= gt;

>

 

 <= /p>

 

>= ; _______________________________________________

> Anima mailing list

= > Anima@ietf.org

> https://www.ietf.org/mailman= /listinfo/anima

 = ;

 

--

---

tte@cs.fau.de


--------------------------------------------------------------------------= -----------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_004A_01D4184B.C9EB4580-- From nobody Tue Jul 10 01:10:03 2018 Return-Path: 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 846FC130DFE; Tue, 10 Jul 2018 01:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6N2kuxZMr9hl; Tue, 10 Jul 2018 01:10:00 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9F5130DDE; Tue, 10 Jul 2018 01:10:00 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id s11-v6so13550589wra.13; Tue, 10 Jul 2018 01:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CB4FUrdKHbqpssAObtHVJp9kreJd68uQHhrZ2Ub0/TA=; b=ojIvKQymVS7ilWNUCRV09hvfcPrhPPvt/5A0/ZqxCYVNjgb9g4eonhT7IzF2Zcfqg7 BEHiDO4+lv7GQT4jh/eBkC/hDhAobmJ/iisljYpwnrsaRmWiGPIyztG8xN7JwOBKZ/9s dK8HZUEC1Jd3FfuLTN5YtvFkp5L/9R9bEXBqI4d3mC0q/Mb8HzM4OBelTRCyep8cDEMZ tQgug13Tm3e25RpYQhnuEdTfVZfAYgqV/kzaaLLfsyf9m99bUHlf1Dn9EDCNyWAdBDX2 wW1u+9zIYcFLmdE9pTajf+WvwgUcceePhW7c6+JLMsT9Zw1REI+0B4QQ6y+B94cvNnbw qB8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CB4FUrdKHbqpssAObtHVJp9kreJd68uQHhrZ2Ub0/TA=; b=c3jpzarlyvIKWHtq3obYuQni9uLktEqVhQdmkoJPVJPKSV2eNwGxekvt75Efj4mVr6 L5S7qxFlKu/vqsBsrQhIBXRGCpMosfOCAvUHf+lgHb7mLxn3FSIcbvYCpYgPuBmsmzq3 NgWBn/UiugP1SCHneMhd5GF0w8v1HUNOIL9e82YbXLmRTp8j0q68w40VFiZ5hyNTp7KQ Z5huceoeg5LKeoBQgSkYtF0Bhnto+n/HcLUIFBjVEICEzdCJMPEN0tymNPmp8FHpXSAE eZbapbjF0TQDSxD4U64CaWPh0SNIJSE7PT97ulQpvg4sRw7G9K0TtoXx7efoFWCQG1yc rm9A== X-Gm-Message-State: AOUpUlGzjP7JsNqr8YnFs2jl7TlNbPssnNOUmBkH3b3EqeHSgZsap4zP fQbbxNdwlQGzoowOFbASxUS1JWmh X-Google-Smtp-Source: AAOMgpd1uGSJqQdF1TTuIjEdhUghkSVGyenCN8bwyH/prykbmKiZdefxUdQzdliNCiq1WnoN6ssNPw== X-Received: by 2002:adf:ed8e:: with SMTP id c14-v6mr9148730wro.264.1531210198663; Tue, 10 Jul 2018 01:09:58 -0700 (PDT) Received: from [192.168.1.21] (ANice-652-1-137-106.w83-201.abo.wanadoo.fr. [83.201.208.106]) by smtp.gmail.com with ESMTPSA id l10-v6sm27538584wrv.23.2018.07.10.01.09.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 01:09:57 -0700 (PDT) From: "Michael H. Behringer" X-Google-Original-From: "Michael H. Behringer" To: Toerless Eckert Cc: anima@ietf.org, draft-ietf-anima-reference-model@ietf.org References: <20180710020659.mwfqh52ydagts3r3@faui48f.informatik.uni-erlangen.de> Message-ID: <5e46a761-9a24-a1d2-9cfe-02db2c8dc2f5@gmail.com> Date: Tue, 10 Jul 2018 10:09:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180710020659.mwfqh52ydagts3r3@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: fr-classic Archived-At: Subject: Re: [Anima] Michael: Nit suggestion for draft-ietf-anima-reference-model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 08:10:03 -0000 Hi Toerless, thanks for the feedback. No problem with me, I'll move contributors before acknowledgements (makes sense). Personally I have no problem adding email addresses behind contributors, will need to check with everybody which email address they want listed. Are other ID editors doing the same thing? Just, if we're the first to do that, maybe we should check with our AD that this is ok? Michael On 10/07/2018 04:06, Toerless Eckert wrote: > (not sure which hat i should wear for this email ... i guess it > mostly my personal opinion): > > Michael (dear editor) > > One nit fix suggestion for whenever you'll do a rev because of IESG feedback: > > I have just noticed that some tooling, at least from Jari (http://www.arkko.com/tools/allstats) > is also taking contributors into account when listing RFCs. Datatracker does not > (yet) do this, but i want to suggest it to them given how i feel that its > valuable to more explicitly givecredit to the contributor status (aka: > list RFCs someone contributed to on their datatracker personal page). > > Wrt. to the anima reference model: If would be good if you > could put the email address of each contributor in parenthesis behind the > contributors name. This should help any parsing tool trying to identify/ > match contributors. Also, please move the contributors > section before the Acknowledgements section - unless you disagree that > thats the more appropriate order. > > Thanks! > toerless From nobody Tue Jul 10 01:16:48 2018 Return-Path: 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 BFED5130F23 for ; Tue, 10 Jul 2018 01:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 CibWLmloIZ_J for ; Tue, 10 Jul 2018 01:16:40 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729E1130F01 for ; Tue, 10 Jul 2018 01:16:40 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 17ADD58C4B3; Tue, 10 Jul 2018 10:16:35 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 06B244401A4; Tue, 10 Jul 2018 10:16:34 +0200 (CEST) Date: Tue, 10 Jul 2018 10:16:34 +0200 From: 'Toerless Eckert' To: Anoop Kumar Pandey Cc: 'Michael Richardson' , anima@ietf.org Message-ID: <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004901d4181d$b02f8710$108e9530$@cdac.in> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 08:16:45 -0000 On Tue, Jul 10, 2018 at 12:44:45PM +0530, Anoop Kumar Pandey wrote: > Toerless >The pledge simply needs to locate the voucher locally, and when it > connects to the registrar, it can skip the step of retrieving the voucher > because it already does trust the registrar as it has the voucher locally. > > The pledge may have the voucher locally, but how will it know that the > domain it is going to register is the real owner. It may be some other > domain. For that, I suggested use of public key of owners in the digital > invoice which can be used to verify the signed acceptance sent by JRC. Maybe i am confused and overlook something in your assumed setup, but: When the pledge opens a TLS connection to the registrar, the pledge can authenticate the certificate presented by the registrar as part of the TLS connection setup with the voucher. Thats what the voucher does. [there is the detail aspect of you saying owner public key whereas the voucher uses the owners certificate, which is better, but lets ignore tht for a second] > Once pledge and JRC have verified each other, enrolment can go on using EST. > I want to eliminate the communication overhead or MASA itself. Yes, what i said does this. Pledge has voucher, pledge doe not need to request voucher from Registrar, ergo Registrar does not need to connect to MASA. > Toerless>I think those solutions are not ideal because they do introduce > another new "touch" to the pledge. > > > Anyway manufacturer is installing an IDevID, they can also install a digital > invoice (or voucher). Unless your devie is built to order, you do not know the owner at the time when you put an IDevID onto a device. And putting an IDevID onto a device is a highly specialized process in manufacturing where even if you where doing build-to-order, you likely would want to separate it from assigning an owner to a device. As Max said, the mayority of all devices are assigned an owner when the product has long left the manufacturer and is now sitting in some reseller hosted storge facility. > Toerless> The BRSKI document does allude to these options but does not > necessarily detail them well enough for every uninitiated reader to > understand the options. > > > Why leave something to someone's imagination. All necessary > details/angles/options can be entailed if it's provisioned in the BRSKI > already so that no stone is left unturned. ? Not sure i correctly understand that sentence. If its saying that it would be good to write down the possible derived workflows, i think i already said that in my email. > When a device is manufactured, it will only have IDevID. But when a device > is sold; before shipping, digital invoice may be embedded in it. In this way > the device may lie in the warehouse for years but unless it has been sold, > it is not unique to a customer. Its IMHO certainly a better option if the reseller puts the voucher onto the device when it is shipping it out to the customer than the customer doing it upon receipt/installation of the device. Alas, even in that option there are operational pitfalls: Lets say you want voucher-on-a-stick. As long as you just attach that USB stick to the products packaging, you're up to a high rate of errors on the receiver side.. "What.. there was a USB stick in the packaging ? Where do i need to put it ? Oh wait, the cleaner already threw away the packaging". So you want to make sure that the voucher is actually in the device itself. At minimum you would need the reseller to open the box and put the USB stick into a specific USB port designed not to stick out, so tht that USB stick is an undistinguishable part of the device. I knew few router products where this is mechanically feasible. Or you can try to electronically load the voucher onto the device. Which just makes the whole thing even worse: IMHO, no reeller in their sane mind would want to open boxes to physically attach a sales dongle to a device. Even less so do they want to eletctrically power it on and run some magic uploa routine to put the voucher onto the device. I think there are ways around this, i can write up something if i find the time, but suffice to say: Without some better solutions than this, the most lightweigt option is still to think of an offline system to feed the voucher into the registrar if you want to avoid the BRSKI-MASA connection. Instead of trying to feed it directly to the pledge. > > Michael"> Ultimately, it's not the JRC which is suspicious of who the > Pledge's owner is, it's the Pledge which does not know who owns it." > > > I assure you that pledge can verify the JRC using the public key put in the > digital invoice and using it to verify the digitally signed acceptance note > from JRC. Agreed. And we have an object that does this, its called the voucher. Cheers Toerless > Regards, > > Anoop > > > > -----Original Message----- > From: Toerless Eckert [mailto:tte@cs.fau.de] > Sent: 10 July 2018 12:00 > To: Michael Richardson > Cc: Anoop Kumar Pandey ; anima@ietf.org > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > > > Anoop: > > > > To rephrase from Michaels reply: > > > > You do not need any BRSKI protocol or voucher changes to do what you want. > > > > The pledge simply needs to locate the voucher locally, and when it connects > to the registrar, it can skip the step of retrieving the voucher because it > already does trust the registrar as it has the voucher locally. > > > > In fact, you can even use RFC7030. If you already have a voucher locally, > you do not need BRSKI for voucher signalling. IMHO, you still want BRSKI > (instead of just RFC7030) because of the proxy and the enrolment telemetry. > > > > This just leaves the whole painfull question Michael brings up: > > > > "how the heck do we get vouchers onto devices in the real world" ? > > This is IMHO where everybodies favourite options for managing "offline > vouchers" come into play. There are a lot of vendor solutions where you feed > those nodes information such as vouchers via USB sticks, or temporarily > connected cellphones to the pledge. > > > > I think those solutions are not ideal because they do introduce another new > "touch" to the pledge. But there are also simply a lot of options how to get > the voucher into the registrar without having to use an online BRSKI-MASA > connection. And then you just need to send the voucher from the registrar to > the pledge using BRSKI: No new "touch" on the pledge, no BRSKI-MASA > connection! > > > > The BRSKI document does allude to these options but does not necessarily > detail them well enough for every uninitiated reader to understand the > options. Followup documents refining individual interesting workflows would > certainly be useful IMHO (contributor, not WG chair hat on). > > > > > > Cheers > > Toerless > > > > > > On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > > > > > > Anoop Kumar Pandey < anoop@cdac.in> wrote: > > > > When a device is purchased in real world, usually an invoice is > issued in the > > > > name of the purchaser with stamp of vendor/manufacturer. > > > > > > > I propose that similarly, a digital invoice can be issued which will > contain > > > > the public key(s) of the and digitally > signed by the > > > > manufacturer. The digital invoice may be embedded in the pledge > along with > > > > the IDevID. > > > > > > That's an interesting idea, perhaps you could write it up in the form > > > of an Internet-Draft? Then I could make sure that I fully understand > > > your proposal. > > > > > > It seems very difficult to make digitally signed invoices occur in the > > > real world, given the constrained of the supply chain. Still, BRSKI > > > makes provisions for higher security if the supply chain is integrated. > > > > > > I once proposed something similar using signed certficates: > > > > > > > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9 > > > s5yqfRm0n00 > > > > > > In effect, the voucher artifact that we created in RFC8366 replaces > > > these certificates with purpose built signed artifacts that expresses > > > what the invoice attempts to express. > > > > > > > When a pledge starts the registration process, it will present the > digital > > > > invoice along with IDevID. The JRC can verify the digital signature > of the > > > > manufacturer on the digital invoice and sent a signed note of > acceptance to > > > > the pledge. The pledge can verify the signed note using the public > key(s) > > > > mentioned in the digital invoice, thereby verifying its true owner. > > > > > > A pledge which has sat in a warehouse for a year before being sold to > > > an owner will not have the invoice on it yet. That's okay, because > > > the invoice, being digitally signed, could be retrieved from another > > > place, and that's effectively what the BRSKI-MASA protocol *does*. > > > > > > If the invoice needs to be loaded into the Pledge via a > > > secure-out-of-band mechanism, (i.e. during the manufacturing process), > > > then the Pledge could also be fully configured, and could include a > > > simple PSK too. This is the approach which is being used in > draft-ietf-6tisch-minimal-security. > > > > > > Ultimately, it's not the JRC which is suspicious of who the Pledge's > > > owner is, it's the Pledge which does not know who owns it. > > > > > > > This process with eliminate all the communication overhead with MASA > and > > > > multiple level verification (voucher request, voucher, telemetry etc > at > > > > JRC/MASA/Pledge). > > > > > > Yes, it does, at the cost of making every device in the warehouse unique > to a > > > specific customer. If I may make an analogy to distribution of movies, > > > you are suggesting that netflix go back to mailing DVDs to people. > > > > > > > From security point of view: Given that the digital invoice is > digitally > > > > signed by manufacturer, the public key of domain owner embedded in > the > > > > digital invoice can???t be changed, otherwise verification of > digital signature > > > > of manufacturer at JRC end will fail. > > > > > > > Requesting you to give your comments as it will simplify the > protocol. > > > > > > > P.S.: As you had earlier mentioned ???On resale, the device should > be put > > > > through a factory reset to clear things. The MASA will have to be > willing to > > > > issue a new voucher to the new domain owner..???; here also, > manufacturer may > > > > issue a new digital invoice in case of resale. > > > > > > yes, that's true. But, since you said that the invoice is in the > > > Pledge, the manufacturer would have to take the device back to do that. > > > > > > The reason for all the JRC,MASA etc, is so that we do not need to have > > > the manufacturer touch the device a second time. > > > > > > -- > > > ] Never tell me the odds! | ipv6 mesh > networks [ > > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > > ] mcr@sandelman.ca > http://www.sandelman.ca/ | ruby on rails > [ > > > > > > > > > -- > > > Michael Richardson < > mcr+IETF@sandelman.ca>, Sandelman Software Works > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > tte@cs.fau.de > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > -- --- tte@cs.fau.de From nobody Tue Jul 10 01:18:36 2018 Return-Path: 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 AC7C4130F20; Tue, 10 Jul 2018 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 h5R-8xATb8xP; Tue, 10 Jul 2018 01:18:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2977E130F01; Tue, 10 Jul 2018 01:18:33 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0D76B58C4B3; Tue, 10 Jul 2018 10:18:29 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id F0AEE4401A4; Tue, 10 Jul 2018 10:18:28 +0200 (CEST) Date: Tue, 10 Jul 2018 10:18:28 +0200 From: Toerless Eckert To: "Michael H. Behringer" Cc: anima@ietf.org, draft-ietf-anima-reference-model@ietf.org Message-ID: <20180710081828.2zx55ty4birwiozs@faui48f.informatik.uni-erlangen.de> References: <20180710020659.mwfqh52ydagts3r3@faui48f.informatik.uni-erlangen.de> <5e46a761-9a24-a1d2-9cfe-02db2c8dc2f5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e46a761-9a24-a1d2-9cfe-02db2c8dc2f5@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Michael: Nit suggestion for draft-ietf-anima-reference-model X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 08:18:35 -0000 Thanks, Michael I ran into this via an RFC that had the emails of contributor listed. I'll check next week in person wrt. to best current practices with RFC editor. Cheers Toerless On Tue, Jul 10, 2018 at 10:09:56AM +0200, Michael H. Behringer wrote: > Hi Toerless, thanks for the feedback. > > No problem with me, I'll move contributors before acknowledgements (makes > sense). Personally I have no problem adding email addresses behind > contributors, will need to check with everybody which email address they > want listed. > > Are other ID editors doing the same thing? Just, if we're the first to do > that, maybe we should check with our AD that this is ok? > > Michael > > > On 10/07/2018 04:06, Toerless Eckert wrote: > > (not sure which hat i should wear for this email ... i guess it > > mostly my personal opinion): > > > > Michael (dear editor) > > > > One nit fix suggestion for whenever you'll do a rev because of IESG feedback: > > > > I have just noticed that some tooling, at least from Jari (http://www.arkko.com/tools/allstats) > > is also taking contributors into account when listing RFCs. Datatracker does not > > (yet) do this, but i want to suggest it to them given how i feel that its > > valuable to more explicitly givecredit to the contributor status (aka: > > list RFCs someone contributed to on their datatracker personal page). > > > > Wrt. to the anima reference model: If would be good if you > > could put the email address of each contributor in parenthesis behind the > > contributors name. This should help any parsing tool trying to identify/ > > match contributors. Also, please move the contributors > > section before the Acknowledgements section - unless you disagree that > > thats the more appropriate order. > > > > Thanks! > > toerless -- --- tte@cs.fau.de From nobody Tue Jul 10 01:35:39 2018 Return-Path: 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 D5CCE130F12 for ; Tue, 10 Jul 2018 01:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 coKBr7IdvSBV for ; Tue, 10 Jul 2018 01:35:35 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029FD130F27 for ; Tue, 10 Jul 2018 01:35:35 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6A96F58C4B3; Tue, 10 Jul 2018 10:35:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 59D1C4401A4; Tue, 10 Jul 2018 10:35:28 +0200 (CEST) Date: Tue, 10 Jul 2018 10:35:28 +0200 From: Toerless Eckert To: Eliot Lear Cc: Michael Richardson , Anoop Kumar Pandey , anima@ietf.org Message-ID: <20180710083528.u7fx4676cuzss33h@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 08:35:38 -0000 Thanks Eliot Very interesting, but can you explain why you think this is in the same ballpark as the issue Anoop raised ? More inline. On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote: > Hi Toerless, > > When we look at this scenario, we should consider several factors: > > * The manufacturer is in a position to control both the MASA and the > pledge.  That's useful because it means that there is less > interoperability friction if the manufacturer wants to pass > additional parameters between the pledge and the manufacturer, so > long as the registrar doesn't interfere. Haha. I am not sure you want to mention "interoperability friction" in a venue whose purpose in life is interoperability (IETF). We discussed during BRSKI design this aspect, and i think we can all see good flexiblity reasons for this side-channel, even without having to blame ineroperability. The main issue is that it is a side-channel, and if there is any concerns about BRKI it is the mistrust against manufacturers. SO i would hope that any use of the side-channel would allow to establish the ability on the registrar to passively analyze/observe that side-channel. > * In WiFi we have two additional issues: a device needs to do ANIMA, > but it needs to be authorized in some manner to do so.  You mean we have the issue of getting initial 802.11 credentials to the pledge ? If not, then i didn't understand this bullet point. > * The second issue is one of network selection.  There is a need for > the pledge to really *know* that this is The network when 802.11 is > involved.  What a manufacturer wants to avoid is a pledge joining a > network where the MASA just does the logging and does no validation, > without any other means to determine that the device is on the > correct network.  Otherwise, the pledge (we could call it the > "station" in this context) could simply home to the wrong network, > and even resetting the device won't get you to the right network. Right. BRSKI is called zero-touch, but there is really one touch left: plugging a network cable into a right network port. With WiFi this can be automated because selecting the right SSID can be done without a human touch. I just wonder how we call it when we take one more touch away. BRSKI double zero (with a license to kill) ? ;-)) > Owen will present something in Montreal that begins the discussion of > these issues. Great. Cheers Toerless > Eliot > > On 10.07.18 08:29, Toerless Eckert wrote: > > Anoop: > > > > To rephrase from Michaels reply: > > > > You do not need any BRSKI protocol or voucher changes to do what you want. > > > > The pledge simply needs to locate the voucher locally, and when it > > connects to the registrar, it can skip the step of retrieving > > the voucher because it already does trust the registrar > > as it has the voucher locally. > > > > In fact, you can even use RFC7030. If you already have a voucher locally, > > you do not need BRSKI for voucher signalling. IMHO, you still want > > BRSKI (instead of just RFC7030) because of the proxy and the > > enrolment telemetry. > > > > This just leaves the whole painfull question Michael brings up: > > > > "how the heck do we get vouchers onto devices in the real world" ? > > This is IMHO where everybodies favourite options for managing > > "offline vouchers" come into play. There are a lot of vendor > > solutions where you feed those nodes information such as vouchers > > via USB sticks, or temporarily connected cellphones to the pledge. > > > > I think those solutions are not ideal because they do introduce > > another new "touch" to the pledge. But there are also simply > > a lot of options how to get the voucher into the registrar > > without having to use an online BRSKI-MASA connection. And then you > > just need to send the voucher from the registrar to the pledge > > using BRSKI: No new "touch" on the pledge, no BRSKI-MASA > > connection! > > > > The BRSKI document does allude to these options but does not > > necessarily detail them well enough for every uninitiated reader > > to understand the options. Followup documents refining individual > > interesting workflows would certainly be useful > > IMHO (contributor, not WG chair hat on). > > > > > > Cheers > > Toerless > > > > > > On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > >> Anoop Kumar Pandey wrote: > >> > When a device is purchased in real world, usually an invoice is issued in the > >> > name of the purchaser with stamp of vendor/manufacturer. > >> > >> > I propose that similarly, a digital invoice can be issued which will contain > >> > the public key(s) of the and digitally signed by the > >> > manufacturer. The digital invoice may be embedded in the pledge along with > >> > the IDevID. > >> > >> That's an interesting idea, perhaps you could write it up in the form of an > >> Internet-Draft? Then I could make sure that I fully understand your > >> proposal. > >> > >> It seems very difficult to make digitally signed invoices occur in the real > >> world, given the constrained of the supply chain. Still, BRSKI makes > >> provisions for higher security if the supply chain is integrated. > >> > >> I once proposed something similar using signed certficates: > >> https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00 > >> > >> In effect, the voucher artifact that we created in RFC8366 replaces these > >> certificates with purpose built signed artifacts that expresses what the > >> invoice attempts to express. > >> > >> > When a pledge starts the registration process, it will present the digital > >> > invoice along with IDevID. The JRC can verify the digital signature of the > >> > manufacturer on the digital invoice and sent a signed note of acceptance to > >> > the pledge. The pledge can verify the signed note using the public key(s) > >> > mentioned in the digital invoice, thereby verifying its true owner. > >> > >> A pledge which has sat in a warehouse for a year before being sold to an > >> owner will not have the invoice on it yet. That's okay, because the invoice, > >> being digitally signed, could be retrieved from another place, and that's > >> effectively what the BRSKI-MASA protocol *does*. > >> > >> If the invoice needs to be loaded into the Pledge via a secure-out-of-band > >> mechanism, (i.e. during the manufacturing process), then the Pledge could > >> also be fully configured, and could include a simple PSK too. This is the > >> approach which is being used in draft-ietf-6tisch-minimal-security. > >> > >> Ultimately, it's not the JRC which is suspicious of who the Pledge's owner > >> is, it's the Pledge which does not know who owns it. > >> > >> > This process with eliminate all the communication overhead with MASA and > >> > multiple level verification (voucher request, voucher, telemetry etc at > >> > JRC/MASA/Pledge). > >> > >> Yes, it does, at the cost of making every device in the warehouse unique to a > >> specific customer. If I may make an analogy to distribution of movies, > >> you are suggesting that netflix go back to mailing DVDs to people. > >> > >> > From security point of view: Given that the digital invoice is digitally > >> > signed by manufacturer, the public key of domain owner embedded in the > >> > digital invoice can???t be changed, otherwise verification of digital signature > >> > of manufacturer at JRC end will fail. > >> > >> > Requesting you to give your comments as it will simplify the protocol. > >> > >> > P.S.: As you had earlier mentioned ???On resale, the device should be put > >> > through a factory reset to clear things. The MASA will have to be willing to > >> > issue a new voucher to the new domain owner..???; here also, manufacturer may > >> > issue a new digital invoice in case of resale. > >> > >> yes, that's true. But, since you said that the invoice is in the Pledge, the > >> manufacturer would have to take the device back to do that. > >> > >> The reason for all the JRC,MASA etc, is so that we do not need to have the > >> manufacturer touch the device a second time. > >> > >> -- > >> ] Never tell me the odds! | ipv6 mesh networks [ > >> ] Michael Richardson, Sandelman Software Works | network architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >> > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -= IPv6 IoT consulting =- > >> > >> > >> > > > > > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > > -- --- tte@cs.fau.de From nobody Tue Jul 10 02:02:33 2018 Return-Path: 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 AC5A9130E22 for ; Tue, 10 Jul 2018 02:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 CuRXyKLDplRL for ; Tue, 10 Jul 2018 02:02:26 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17278130E12 for ; Tue, 10 Jul 2018 02:02:24 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w6A91dA3003509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jul 2018 14:31:45 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w6A90E8O004124; Tue, 10 Jul 2018 14:30:14 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w6A90Dvn002607; Tue, 10 Jul 2018 14:30:13 +0530 From: "Anoop Kumar Pandey" To: "'Toerless Eckert'" Cc: "'Michael Richardson'" , References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> Date: Tue, 10 Jul 2018 14:30:12 +0530 Message-ID: <007501d4182c$6985efc0$3c91cf40$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D4185A.83461B00" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-in Thread-Index: AQFAzvEfV8gDGlfdQPkEn1OSJPe5FQHjX3D4AdayjmICGbwlNAJnXrCGpWzb1AA= X-CDAC-PUNE-MailScanner-ID: w6A90E8O004124 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.798, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_50 0.00, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w6A91dA3003509 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 09:02:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0076_01D4185A.83461B00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Toerless>When the pledge opens a TLS connection to the registrar, the pledge can authenticate the certificate presented by the registrar as part of the TLS connection setup with the voucher. Thats what the voucher does. Anyone can present certificate of anyone else (it's public). That's why I proposed use of digital signature and later verification to establish the identity of both JRC and Pledge. Toerless>[there is the detail aspect of you saying owner public key whereas the voucher uses the owners certificate, which is better, but lets ignore tht for a second] Certificate is just a container for public key along with other meta data. Toerless> Its IMHO certainly a better option if the reseller puts the voucher onto the device when it is shipping it out to the customer than the customer doing it upon receipt/installation of the device. Alas, even in that option there are operational pitfalls: Lets say you want voucher-on-a-stick. As long as you just attach that USB stick to the products packaging, you're up to a high rate of errors on the receiver side.. "What.. there was a USB stick in the packaging ? Where do i need to put it ? Oh wait, the cleaner already threw away the packaging". So you want to make sure that the voucher is actually in the device itself. At minimum you would need the reseller to open the box and put the USB stick into a specific USB port designed not to stick out, so tht that USB stick is an undistinguishable part of the device. I knew few router products where this is mechanically feasible. Or you can try to electronically load the voucher onto the device. Which just makes the whole thing even worse: IMHO, no reeller in their sane mind would want to open boxes to physically attach a sales dongle to a device. Even less so do they want to eletctrically power it on and run some magic uploa routine to put the voucher onto the device. Why go to such lengths and give headache of extra USB. Why can't the digital invoice(or voucher) be embedded in the ROM in the device itself or be kept wherever the IDevID has been put. [If you use any external detachable device then that usb can used with other pledge also(may be). If it is embedded, it's part of device] Toerless> Agreed. And we have an object that does this, its called the voucher. I know. I only want to put it into the device itself so that communication with MASA is not required and protocol becomes simpler as now pledge and JRC can authenticate themselves using digital signature on the voucher. Regards, Anoop -----Original Message----- From: 'Toerless Eckert' [mailto:tte@cs.fau.de] Sent: 10 July 2018 13:47 To: Anoop Kumar Pandey Cc: 'Michael Richardson' ; anima@ietf.org Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg On Tue, Jul 10, 2018 at 12:44:45PM +0530, Anoop Kumar Pandey wrote: > Toerless >The pledge simply needs to locate the voucher locally, and > when it connects to the registrar, it can skip the step of retrieving > the voucher because it already does trust the registrar as it has the voucher locally. > > The pledge may have the voucher locally, but how will it know that the > domain it is going to register is the real owner. It may be some other > domain. For that, I suggested use of public key of owners in the > digital invoice which can be used to verify the signed acceptance sent by JRC. Maybe i am confused and overlook something in your assumed setup, but: When the pledge opens a TLS connection to the registrar, the pledge can authenticate the certificate presented by the registrar as part of the TLS connection setup with the voucher. Thats what the voucher does. [there is the detail aspect of you saying owner public key whereas the voucher uses the owners certificate, which is better, but lets ignore tht for a second] > Once pledge and JRC have verified each other, enrolment can go on using EST. > I want to eliminate the communication overhead or MASA itself. Yes, what i said does this. Pledge has voucher, pledge doe not need to request voucher from Registrar, ergo Registrar does not need to connect to MASA. > Toerless>I think those solutions are not ideal because they do > Toerless>introduce > another new "touch" to the pledge. > > > Anyway manufacturer is installing an IDevID, they can also install a > digital invoice (or voucher). Unless your devie is built to order, you do not know the owner at the time when you put an IDevID onto a device. And putting an IDevID onto a device is a highly specialized process in manufacturing where even if you where doing build-to-order, you likely would want to separate it from assigning an owner to a device. As Max said, the mayority of all devices are assigned an owner when the product has long left the manufacturer and is now sitting in some reseller hosted storge facility. > Toerless> The BRSKI document does allude to these options but does not > necessarily detail them well enough for every uninitiated reader to > understand the options. > > > Why leave something to someone's imagination. All necessary > details/angles/options can be entailed if it's provisioned in the > BRSKI already so that no stone is left unturned. ? Not sure i correctly understand that sentence. If its saying that it would be good to write down the possible derived workflows, i think i already said that in my email. > When a device is manufactured, it will only have IDevID. But when a > device is sold; before shipping, digital invoice may be embedded in > it. In this way the device may lie in the warehouse for years but > unless it has been sold, it is not unique to a customer. Its IMHO certainly a better option if the reseller puts the voucher onto the device when it is shipping it out to the customer than the customer doing it upon receipt/installation of the device. Alas, even in that option there are operational pitfalls: Lets say you want voucher-on-a-stick. As long as you just attach that USB stick to the products packaging, you're up to a high rate of errors on the receiver side.. "What.. there was a USB stick in the packaging ? Where do i need to put it ? Oh wait, the cleaner already threw away the packaging". So you want to make sure that the voucher is actually in the device itself. At minimum you would need the reseller to open the box and put the USB stick into a specific USB port designed not to stick out, so tht that USB stick is an undistinguishable part of the device. I knew few router products where this is mechanically feasible. Or you can try to electronically load the voucher onto the device. Which just makes the whole thing even worse: IMHO, no reeller in their sane mind would want to open boxes to physically attach a sales dongle to a device. Even less so do they want to eletctrically power it on and run some magic uploa routine to put the voucher onto the device. I think there are ways around this, i can write up something if i find the time, but suffice to say: Without some better solutions than this, the most lightweigt option is still to think of an offline system to feed the voucher into the registrar if you want to avoid the BRSKI-MASA connection. Instead of trying to feed it directly to the pledge. > > Michael"> Ultimately, it's not the JRC which is suspicious of who the > Pledge's owner is, it's the Pledge which does not know who owns it." > > > I assure you that pledge can verify the JRC using the public key put > in the digital invoice and using it to verify the digitally signed > acceptance note from JRC. Agreed. And we have an object that does this, its called the voucher. Cheers Toerless > Regards, > > Anoop > > > > -----Original Message----- > From: Toerless Eckert [ mailto:tte@cs.fau.de] > Sent: 10 July 2018 12:00 > To: Michael Richardson < mcr+ietf@sandelman.ca> > Cc: Anoop Kumar Pandey < anoop@cdac.in>; anima@ietf.org > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > > > Anoop: > > > > To rephrase from Michaels reply: > > > > You do not need any BRSKI protocol or voucher changes to do what you want. > > > > The pledge simply needs to locate the voucher locally, and when it > connects to the registrar, it can skip the step of retrieving the > voucher because it already does trust the registrar as it has the voucher locally. > > > > In fact, you can even use RFC7030. If you already have a voucher > locally, you do not need BRSKI for voucher signalling. IMHO, you still > want BRSKI (instead of just RFC7030) because of the proxy and the enrolment telemetry. > > > > This just leaves the whole painfull question Michael brings up: > > > > "how the heck do we get vouchers onto devices in the real world" ? > > This is IMHO where everybodies favourite options for managing "offline > vouchers" come into play. There are a lot of vendor solutions where > you feed those nodes information such as vouchers via USB sticks, or > temporarily connected cellphones to the pledge. > > > > I think those solutions are not ideal because they do introduce > another new "touch" to the pledge. But there are also simply a lot of > options how to get the voucher into the registrar without having to > use an online BRSKI-MASA connection. And then you just need to send > the voucher from the registrar to the pledge using BRSKI: No new > "touch" on the pledge, no BRSKI-MASA connection! > > > > The BRSKI document does allude to these options but does not > necessarily detail them well enough for every uninitiated reader to > understand the options. Followup documents refining individual > interesting workflows would certainly be useful IMHO (contributor, not WG chair hat on). > > > > > > Cheers > > Toerless > > > > > > On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > > > > > > Anoop Kumar Pandey < < mailto:anoop@cdac.in> anoop@cdac.in> wrote: > > > > When a device is purchased in real world, usually an invoice > > is > issued in the > > > > name of the purchaser with stamp of vendor/manufacturer. > > > > > > > I propose that similarly, a digital invoice can be issued > > which will > contain > > > > the public key(s) of the and > > digitally > signed by the > > > > manufacturer. The digital invoice may be embedded in the > > pledge > along with > > > > the IDevID. > > > > > > That's an interesting idea, perhaps you could write it up in the > > form > > > of an Internet-Draft? Then I could make sure that I fully > > understand > > > your proposal. > > > > > > It seems very difficult to make digitally signed invoices occur in > > the > > > real world, given the constrained of the supply chain. Still, BRSKI > > > makes provisions for higher security if the supply chain is integrated. > > > > > > I once proposed something similar using signed certficates: > > > > > > > > > HU9> > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9 > > > s5yqfRm0n00 > > > > > > In effect, the voucher artifact that we created in RFC8366 replaces > > > these certificates with purpose built signed artifacts that > > expresses > > > what the invoice attempts to express. > > > > > > > When a pledge starts the registration process, it will present > > the > digital > > > > invoice along with IDevID. The JRC can verify the digital > > signature > of the > > > > manufacturer on the digital invoice and sent a signed note of > acceptance to > > > > the pledge. The pledge can verify the signed note using the > > public > key(s) > > > > mentioned in the digital invoice, thereby verifying its true owner. > > > > > > A pledge which has sat in a warehouse for a year before being sold > > to > > > an owner will not have the invoice on it yet. That's okay, because > > > the invoice, being digitally signed, could be retrieved from another > > > place, and that's effectively what the BRSKI-MASA protocol *does*. > > > > > > If the invoice needs to be loaded into the Pledge via a > > > secure-out-of-band mechanism, (i.e. during the manufacturing > > process), > > > then the Pledge could also be fully configured, and could include a > > > simple PSK too. This is the approach which is being used in > draft-ietf-6tisch-minimal-security. > > > > > > Ultimately, it's not the JRC which is suspicious of who the Pledge's > > > owner is, it's the Pledge which does not know who owns it. > > > > > > > This process with eliminate all the communication overhead > > with MASA > and > > > > multiple level verification (voucher request, voucher, > > telemetry etc > at > > > > JRC/MASA/Pledge). > > > > > > Yes, it does, at the cost of making every device in the warehouse > > unique > to a > > > specific customer. If I may make an analogy to distribution of movies, > > > you are suggesting that netflix go back to mailing DVDs to people. > > > > > > > From security point of view: Given that the digital invoice is > digitally > > > > signed by manufacturer, the public key of domain owner > > embedded in > the > > > > digital invoice can???t be changed, otherwise verification of > digital signature > > > > of manufacturer at JRC end will fail. > > > > > > > Requesting you to give your comments as it will simplify the > protocol. > > > > > > > P.S.: As you had earlier mentioned ???On resale, the device > > should > be put > > > > through a factory reset to clear things. The MASA will have to > > be > willing to > > > > issue a new voucher to the new domain owner..???; here also, > manufacturer may > > > > issue a new digital invoice in case of resale. > > > > > > yes, that's true. But, since you said that the invoice is in the > > > Pledge, the manufacturer would have to take the device back to do that. > > > > > > The reason for all the JRC,MASA etc, is so that we do not need to > > have > > > the manufacturer touch the device a second time. > > > > > > -- > > > ] Never tell me the odds! | ipv6 mesh > networks [ > > > ] Michael Richardson, Sandelman Software Works | network > architect [ > > > ] < mailto:mcr@sandelman.ca> mcr@sandelman.ca > < http://www.sandelman.ca/> http://www.sandelman.ca/ | ruby on rails > [ > > > > > > > > > -- > > > Michael Richardson < < mailto:mcr+IETF@sandelman.ca> > mcr+IETF@sandelman.ca>, Sandelman Software Works > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > > < mailto:Anima@ietf.org> Anima@ietf.org > > > < https://www.ietf.org/mailman/listinfo/anima> > https://www.ietf.org/mailman/listinfo/anima > > > > > > -- > > --- > > < mailto:tte@cs.fau.de> tte@cs.fau.de > > > ---------------------------------------------------------------------- > --------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and > destroy all copies and the original message. Any unauthorized review, > use, disclosure, dissemination, forwarding, printing or copying of > this email is strictly prohibited and appropriate legal action will be taken. > ---------------------------------------------------------------------- > --------------------------------------------------------- > -- --- tte@cs.fau.de ------------------------------------------------------------------------------------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------------------------- ------=_NextPart_000_0076_01D4185A.83461B00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

To= erless>When the pledge opens a TLS connection to the registrar, the pled= ge can authenticate the certificate presented by the registrar as part of t= he TLS connection setup with the voucher. Thats what the voucher does.
<= br>Anyone can present certificate of anyone else (it’s public). T= hat’s why I proposed use of digital signature and later verification = to establish the identity of both JRC and Pledge.

 

Toerless>[t= here is the detail aspect of you saying owner public key whereas  the = voucher uses the owners certificate, which is better, but lets  ignore= tht for a second]

 

Certificate is just a container for public k= ey along with other meta data.

&= nbsp;

Toerless> Its IMHO certainly a= better option if the reseller puts the voucher onto the device when it is = shipping it out to the customer than the customer doing it upon receipt/ins= tallation of the device. Alas, even in that option there are operational pi= tfalls:

Lets say you want vou= cher-on-a-stick. As long as you just attach that USB stick to the products = packaging, you're up to a high rate of errors on the receiver side.. "= What.. there was a USB stick in the packaging ? Where do i need to put it ?= Oh wait, the cleaner already threw away the packaging".

So you want to make sure that the voucher i= s actually in the device itself.

= At minimum you would need the reseller to open the box and put the USB s= tick into a specific USB port designed not to stick out, so tht that USB st= ick is an undistinguishable part of the device. I knew few router products = where this is mechanically feasible.

Or you can try to electronically load the voucher onto the device.<= o:p>

Which just makes the whole thi= ng even worse:

IMHO, no reelle= r in their sane mind would want to open boxes to physically attach a sales = dongle to a device. Even less so do they want to eletctrically power it on = and run some magic uploa routine to put the voucher onto the device.


Why go to such lengths and give hea= dache of extra USB. Why can’t the digital invoice(or voucher) be embe= dded in the ROM in the device itself or be kept wherever the IDevID has bee= n put.

[If you use any external detachable device then that usb can = used with other pledge also(may be). If it is embedded, it’s part of = device]

Toerless> Agreed. And we have an object that does this= , its called the voucher.

&n= bsp;

I know. I only want to put it into th= e device itself so that communication with MASA is not required and protoco= l becomes simpler as now pledge and JRC can authenticate themselves using d= igital signature on the voucher.

 

Regards,

Anoop



-----Original Message-----
From: 'Toerless Eckert' [ma= ilto:tte@cs.fau.de]
Sent: 10 July 2018 13:47
To: Anoop Kumar Pandey = <anoop@cdac.in>
Cc: 'Michael Richardson' <mcr+ietf@sandelman.ca= >; anima@ietf.org
Subject: Re: [Anima] Revision of scope of MASA in t= he BRSKI - Reg

 

On Tue, Jul 10, 2018 at 12:44:45PM +0530, Anoop Kumar Pa= ndey wrote:

> Toerless >The ple= dge simply needs to locate the voucher locally, and

> when it connects to the registrar, it can skip the ste= p of retrieving

> the voucher bec= ause it already does trust the registrar as it has the voucher locally.

>

> The pledge may have the voucher locally, but how will it know that= the

> domain it is going to regi= ster is the real owner. It may be some other

> domain. For that, I suggested use of public key of owners in = the

> digital invoice which can b= e used to verify the signed acceptance sent by JRC.

 

Maybe i am con= fused and overlook something in your assumed setup, but:

 

When the p= ledge opens a TLS connection to the registrar, the pledge can authenticate = the certificate presented by the registrar as part of the TLS connection se= tup with the voucher. Thats what the voucher does.

 

[there is the = detail aspect of you saying owner public key whereas  the voucher uses= the owners certificate, which is better, but lets  ignore tht for a s= econd]

 

> Once pledge and JRC have verified each other, enrolmen= t can go on using EST.

> I want to= eliminate the communication overhead or MASA itself.

 

Yes, what i s= aid does this. Pledge has voucher, pledge doe not need to request voucher f= rom Registrar, ergo Registrar does not need to connect to MASA.<= /p>

 

>= ; Toerless>I think those solutions are not ideal because they do

> Toerless>introduce

> another new "touch" to the pledge.

> 

>

> Anyway manufactu= rer is installing an IDevID, they can also install a

> digital invoice (or voucher).

 

Unless your de= vie is built to order, you do not know the owner at the time when you put a= n IDevID onto a device. And putting an IDevID onto a device is a highly spe= cialized process in manufacturing where even if you where doing build-to-or= der, you likely would want to separate it from assigning an owner to a devi= ce. As Max said, the mayority of all devices are assigned an owner when the= product has long left the manufacturer and is now sitting in some reseller= hosted storge facility.

 <= /o:p>

> Toerless> The BRSKI document does = allude to these options but does not

= > necessarily detail them well enough for every uninitiated reader to

> understand the options.

>

&g= t;

> Why leave something to someo= ne's imagination. All necessary

>= details/angles/options can be entailed if it's provisioned in the

> BRSKI already so that no stone is left = unturned.

 

? Not sure i correctly understand that sentence. If its s= aying that it would be good to write down the possible derived workflows, i= think i already said that in my email.

 

 

> When a device is manufactured, it will only have IDe= vID. But when a

> device is sold;= before shipping, digital invoice may be embedded in

> it. In this way the device may lie in the warehouse f= or years but

> unless it has been= sold, it is not unique to a customer.

 

Its IMHO certainly a better = option if the reseller puts the voucher onto the device when it is shipping= it out to the customer than the customer doing it upon receipt/installatio= n of the device. Alas, even in that option there are operational pitfalls:<= o:p>

 

Lets say you want voucher-on-a-stick. As long as you just attach th= at USB stick to the products packaging, you're up to a high rate of errors = on the receiver side.. "What.. there was a USB stick in the packaging = ? Where do i need to put it ? Oh wait, the cleaner already threw away the p= ackaging".

 

=

So you want to make sure that the voucher is actual= ly in the device itself.

At minimum y= ou would need the reseller to open the box and put the USB stick into a spe= cific USB port designed not to stick out, so tht that USB stick is an undis= tinguishable part of the device. I knew few router products where this is m= echanically feasible.

 

Or you can try to electronically load the vo= ucher onto the device.

Which just mak= es the whole thing even worse:

&= nbsp;

IMHO, no reeller in their sane mind = would want to open boxes to physically attach a sales dongle to a device. E= ven less so do they want to eletctrically power it on and run some magic up= loa routine to put the voucher onto the device.

 

I think there are w= ays around this, i can write up something if i find the time, but suffice t= o say: Without some better solutions than this, the most lightweigt option = is still to think of an offline system to feed the voucher into the registr= ar if you want to avoid the BRSKI-MASA connection. Instead of trying to fee= d it directly to the pledge.

&nb= sp;

>

> Michael"> Ultimately, it's not the JRC which is suspicio= us of who the

> Pledge's owner is= , it's the Pledge which does not know who owns it."

> 

> =

> I assure you that pledge can ve= rify the JRC using the public key put

> in the digital invoice and using it to verify the digitally signed <= o:p>

> acceptance note from JRC.

 

Agreed. And we have an object that does this, its called the voucher.

 

Cheers

    Toerle= ss

 

> Regards,

>

> Anoop

>

> 

>

> -= ----Original Message-----

> From: = Toerless Eckert [mailto:tte@cs.fau.de]

> Sent: 10 July 2018 12:00

> To: Michael Richardson <mcr+i= etf@sandelman.ca>

> = Cc: Anoop Kumar Pandey <anoop@cdac.in>; anima@ietf.org

>= Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg

>

&= gt; 

>

> Anoop:

>

> 

>

> To rephrase fr= om Michaels reply:

> <= /p>

> 

>

> You do not need any BRSK= I protocol or voucher changes to do what you want.

>

> 

>

> The pledge simply needs to locate the voucher locally, and when it=

> connects to the registrar, it = can skip the step of retrieving the

= > voucher because it already does trust the registrar as it has the vouc= her locally.

>

> 

> =

> In fact, you can even use RFC70= 30. If you already have a voucher

&g= t; locally, you do not need BRSKI for voucher signalling. IMHO, you still <= o:p>

> want BRSKI (instead of just RFC7= 030) because of the proxy and the enrolment telemetry.

>

> 

>

> This just leaves the whole painfull question Michael brings up:<= o:p>

>

> 

>

> "how the heck do we get vouchers onto d= evices in the real world" ?

>=

> This is IMHO where everybodies= favourite options for managing "offline

> vouchers" come into play. There are a lot of vendor sol= utions where

> you feed those nod= es information such as vouchers via USB sticks, or

> temporarily connected cellphones to the pledge.

>

> 

>

> I think those solutions are not ideal because they= do introduce

> another new "= ;touch" to the pledge. But there are also simply a lot of <= /p>

> options how to get the voucher into the reg= istrar without having to

> use an= online BRSKI-MASA connection. And then you just need to send

> the voucher from the registrar to the pledge= using BRSKI: No new

> "touc= h" on the pledge, no BRSKI-MASA connection!

>

> 

>

= > The BRSKI document does allude to these options but does not

> necessarily detail them well enough for = every uninitiated reader to

> und= erstand the options. Followup documents refining individual

=

> interesting workflows would certainly be usefu= l IMHO (contributor, not WG chair hat on).

>

> 

>

>&n= bsp;

>

> Cheers

>

>     Toerless<= /o:p>

>

> 

>

> 

>=

> On Sat, Jul 07, 2018 at 02:58:= 52PM -0400, Michael Richardson wrote:

>

> >

>

> > An= oop Kumar Pandey < <mailto:anoop@cdac.in> <= a href=3D"mailto:anoop@cdac.in">anoop@cdac.in> wrote:

>

> >  =    > When a device is purchased in real world, usually an invo= ice

> > is

> issued in the

>

> >   &nb= sp; > name of the purchaser with stamp of vendor/manufacturer.

>

&g= t; >

>

> >     > I propose that simil= arly, a digital invoice can be issued

> > which will

> contain

>

> >     > the public key(s) of the <d= omain owner(s)/JRC(s)> and

> &= gt; digitally

> signed by the=

>

> >     > manufacturer. The digital invoice= may be embedded in the

> > pl= edge

> along with

>

> >=      > the IDevID.

>

> >

<= p class=3DMsoPlainText>>

> >= ; That's an interesting idea, perhaps you could write it up in the

> > form

>

> > of an Intern= et-Draft?  Then I could make sure that I fully

> > understand

= >

> > your proposal.

>

> >

>

> > It seems very difficult to make digitally sign= ed invoices occur in

> > the

>

> > real world, given the constrained of the supply chain. = ; Still, BRSKI

>

> > makes provisions for higher security if the= supply chain is integrated.

>

> >

>

> > I once prop= osed something similar using signed certficates:

>

> > &nbs= p;

>

> > 

> >= <https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-

> > HU9>

> https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI= -HU9

>

<= p class=3DMsoPlainText>> > s5yqfRm0n00

>

> >

>

> = > In effect, the voucher artifact that we created in RFC8366 replaces

>

> > these certificates with purpose built signed artifacts that =

> > expresses

>

> >= what the invoice attempts to express.

>

> >

>

> >&n= bsp;    > When a pledge starts the registration process, = it will present

> > the

> digital

>

> >  &n= bsp;  > invoice along with IDevID. The JRC can verify the digital <= o:p>

> > signature

> of the

>=

> >     &= gt; manufacturer on the digital invoice and sent a signed note of

> acceptance to

>

> >  = ;   > the pledge. The pledge can verify the signed note using = the

> > public

<= p class=3DMsoPlainText>> key(s)

&g= t;

> >    = > mentioned in the digital invoice, thereby verifying its true owner.

>

> >

>

=

> > A pledge which has sat in a warehouse for= a year before being sold

> > = to

>

> > an owner will not have the invoice on it yet.  Tha= t's okay, because

>

> > the invoice, being digitally signed, cou= ld be retrieved from another

>

> > place, and that's effectively= what the BRSKI-MASA protocol *does*.

>

> >

>

> > If= the invoice needs to be loaded into the Pledge via a

>

> > secu= re-out-of-band mechanism, (i.e. during the manufacturing

> > process),

>

> > then the Pledge c= ould also be fully configured, and could include a

>

> > simpl= e PSK too.  This is the approach which is being used in

=

> draft-ietf-6tisch-minimal-security.=

>

>= ; >

>

> > Ultimately, it's not the JRC which is suspicious = of who the Pledge's

> <= /p>

> > owner is, it's the Pledge which does n= ot know who owns it.

> =

> >

>

> >   &n= bsp; > This process with eliminate all the communication overhead <= /o:p>

> > with MASA

> and

>

> >     > mult= iple level verification (voucher request, voucher,

> > telemetry etc

> at

>

> >     > JRC/MASA/Pledge).<= o:p>

>

> >

>

> > Yes, it does, at the cost of making ever= y device in the warehouse

> > = unique

> to a

>

> > spe= cific customer.   If I may make an analogy to distribution of mov= ies,

>

> > you are suggesting that netflix go back to mailing DV= Ds to people.

>

> >

> =

> >     &g= t; From security point of view: Given that the digital invoice is

> digitally

>

> >  &nb= sp;  > signed by manufacturer, the public key of domain owner =

> > embedded in

> the

>

> >     > d= igital invoice can???t be changed, otherwise verification of

=

> digital signature

>

> >  =    > of manufacturer at JRC end will fail.

>

> >

>

> >     > Requesting you to give your co= mments as it will simplify the

> p= rotocol.

>

> >

> =

> >     > P.= S.: As you had earlier mentioned ???On resale, the device

> > should

> be put

>

> >     > through a facto= ry reset to clear things. The MASA will have to

> > be

> willing= to

>

> >     > issue a new voucher to th= e new domain owner..???; here also,

&= gt; manufacturer may

> =

> >     > issue a = new digital invoice in case of resale.

>

> >

>

> > y= es, that's true.  But, since you said that the invoice is in the<= /o:p>

>

> > Pledge, the manufacturer would have to take the device back to = do that.

>

> >

> =

> > The reason for all the JRC,MASA= etc, is so that we do not need to

&= gt; > have

>

> > the manufacturer touch the device a second t= ime.

>

> >

>

> > --

>

> > ]  &n= bsp;            Neve= r tell me the odds!         &n= bsp;       | ipv6 mesh

> networks [

> =

> > ]   Michael Rich= ardson, Sandelman Software Works        = | network

> architect  [=

>

> > ]      <mailto:mcr@= sandelman.ca> mcr@sandelman.ca=

> <http://www.sande= lman.ca/> http://www.sandelman.ca/=         |   ruby on rails=

> [

>

> >

>

> >=

>

> > --

>

> > Michael Richardson < <mailto:mcr+IETF@sandelman.ca>

> mcr+IETF@sandelman.ca>, Sandelman Software Works

>=

> > -=3D IPv6 IoT consulting = =3D-

>

> >

>

> >

>

> >

>

> = ;

>

> 

>

> 

>

> > _________________= ______________________________

> <= o:p>

> > Anima mailing list

>

&= gt; >  <mailto:Anima@ietf.org> Anima@ietf.org

>=

> >  <https://www.ietf.org/mailman/listinfo/anima&= gt;

> https://www.ietf.org/mailman/listinfo/anima

>

>&n= bsp;

>

> 

>

> --

>

> ---

>

>  &= lt;mailto:tte@cs.fau.de> tte@cs.fau.d= e

>

>

> ------= ----------------------------------------------------------------=

> ------------------------------------------= ---------------

> [ C-DAC is on So= cial-Media too. Kindly follow us at:

= > Facebook: https://www.facebook.com/CDACIND= IA & Twitter: @cdacindia ]

>

> This e-mail is for th= e sole use of the intended recipient(s) and may

> contain confidential and privileged information. If you ar= e not the

> intended recipient, p= lease contact the sender by reply e-mail and

> destroy all copies and the original message. Any unauthorized= review,

> use, disclosure, disse= mination, forwarding, printing or copying of

> this email is strictly prohibited and appropriate legal actio= n will be taken.

> ---------------= -------------------------------------------------------

> ---------------------------------------------------= ------

>

 

--<= /p>

---

tte@cs.fau.de


------------------= ---------------------------------------------------------------------------= ----------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_0076_01D4185A.83461B00-- From nobody Tue Jul 10 02:05:20 2018 Return-Path: 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 64882130E22 for ; Tue, 10 Jul 2018 02:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2KVBX8XZf0c7 for ; Tue, 10 Jul 2018 02:05:16 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0934130F1C for ; Tue, 10 Jul 2018 02:05:15 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w6A9597v008254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jul 2018 14:35:09 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w6A94DIZ020036; Tue, 10 Jul 2018 14:34:13 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w6A94CTL006601; Tue, 10 Jul 2018 14:34:12 +0530 From: "Anoop Kumar Pandey" To: "'Michael Richardson'" Cc: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> In-Reply-To: <5778.1530989932@localhost> Date: Tue, 10 Jul 2018 14:34:11 +0530 Message-ID: <008501d4182c$f8101c20$e8305460$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-in Thread-Index: AQFAzvEfV8gDGlfdQPkEn1OSJPe5FQHjX3D4pZ+gAfA= X-CDAC-PUNE-MailScanner-ID: w6A94DIZ020036 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.199, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-2.54, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_20 -0.74) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w6A9597v008254 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 09:05:18 -0000 I shall go through those RFCs that you have mentioned and get back to you. = If you have used similar artefacts earlier, may it be revived. Thank you. -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: 08 July 2018 00:29 To: Anoop Kumar Pandey Cc: anima@ietf.org Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg Anoop Kumar Pandey wrote: > When a device is purchased in real world, usually an invoice is issue= d in the > name of the purchaser with stamp of vendor/manufacturer. > I propose that similarly, a digital invoice can be issued which will = contain > the public key(s) of the and digitally signe= d by the > manufacturer. The digital invoice may be embedded in the pledge along= with > the IDevID. That's an interesting idea, perhaps you could write it up in the form of an= Internet-Draft? Then I could make sure that I fully understand your propo= sal. It seems very difficult to make digitally signed invoices occur in the real= world, given the constrained of the supply chain. Still, BRSKI makes prov= isions for higher security if the supply chain is integrated. I once proposed something similar using signed certficates: https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5y= qfRm0n00 In effect, the voucher artifact that we created in RFC8366 replaces these c= ertificates with purpose built signed artifacts that expresses what the inv= oice attempts to express. > When a pledge starts the registration process, it will present the di= gital > invoice along with IDevID. The JRC can verify the digital signature o= f the > manufacturer on the digital invoice and sent a signed note of accepta= nce to > the pledge. The pledge can verify the signed note using the public ke= y(s) > mentioned in the digital invoice, thereby verifying its true owner. A pledge which has sat in a warehouse for a year before being sold to an ow= ner will not have the invoice on it yet. That's okay, because the invoice,= being digitally signed, could be retrieved from another place, and that's = effectively what the BRSKI-MASA protocol *does*. If the invoice needs to be loaded into the Pledge via a secure-out-of-band = mechanism, (i.e. during the manufacturing process), then the Pledge could a= lso be fully configured, and could include a simple PSK too. This is the a= pproach which is being used in draft-ietf-6tisch-minimal-security. Ultimately, it's not the JRC which is suspicious of who the Pledge's owner = is, it's the Pledge which does not know who owns it. > This process with eliminate all the communication overhead with MASA = and > multiple level verification (voucher request, voucher, telemetry etc = at > JRC/MASA/Pledge). Yes, it does, at the cost of making every device in the warehouse unique to= a specific customer. If I may make an analogy to distribution of movies, you are suggesting that netflix go back to mailing DVDs to people. > From security point of view: Given that the digital invoice is digita= lly > signed by manufacturer, the public key of domain owner embedded in the > digital invoice can=E2=80=99t be changed, otherwise verification of d= igital signature > of manufacturer at JRC end will fail. > Requesting you to give your comments as it will simplify the protocol. > P.S.: As you had earlier mentioned =E2=80=9COn resale, the device sho= uld be put > through a factory reset to clear things. The MASA will have to be wil= ling to > issue a new voucher to the new domain owner..=E2=80=9D; here also, ma= nufacturer may > issue a new digital invoice in case of resale. yes, that's true. But, since you said that the invoice is in the Pledge, t= he manufacturer would have to take the device back to do that. The reason for all the JRC,MASA etc, is so that we do not need to have the = manufacturer touch the device a second time. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- ---------------------------------------------------------------------------= ---------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------------------------------------- From nobody Tue Jul 10 03:08:30 2018 Return-Path: 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 4B676130DD0 for ; Tue, 10 Jul 2018 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IP4VHLNMKTbV for ; Tue, 10 Jul 2018 03:08:26 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9836B130E2B for ; Tue, 10 Jul 2018 03:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10711; q=dns/txt; s=iport; t=1531217305; x=1532426905; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=XY6zos2nZiZLwf3oJzc2/boQxDdmQryjs+1WEu4szak=; b=Hig8KAsjeyfE/sUmh0TIveRS7cT+6OXwf2EEiuvhJ7+yAUhiAVvLYbvg tYEFMkvuPYvjcCzMnwGbWubn537fT2qIQ8l5tlmwySHwh88Nw+3iXzpGJ wkrUYiZpxh86XbnP8NC/EnB1HhWxq1tahWu0Q910QPJMeMmwe0f75tg3B g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBQBLhERb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEoQiiGONNggjkCSHCAgDhGwCglA4FAECAQECAQECbSh?= =?us-ascii?q?CAQEBAgEIAoRlAQUjVhALDgoqAgJXBg0IAQEVAoMFAYF/qguCHB+IMIErD4s?= =?us-ascii?q?PgRAnDIIwLod8glUCh0EzhF+FGIdmCYNdgViJawaIFoVHkhCBWCGBUjMaCBs?= =?us-ascii?q?VgyWCJBeOGT2GIxmCDIMDK4IbAQE?= X-IronPort-AV: E=Sophos;i="5.51,334,1526342400"; d="asc'?scan'208,217";a="5080208" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2018 10:08:23 +0000 Received: from [10.61.195.132] ([10.61.195.132]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w6AA8MRV022835; Tue, 10 Jul 2018 10:08:22 GMT To: Toerless Eckert Cc: Michael Richardson , Anoop Kumar Pandey , anima@ietf.org References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <20180710083528.u7fx4676cuzss33h@faui48f.informatik.uni-erlangen.de> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Tue, 10 Jul 2018 12:08:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180710083528.u7fx4676cuzss33h@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WELFqkKtN6BwWEOSW3Yn68G8CYIur0hvj" Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 10:08:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WELFqkKtN6BwWEOSW3Yn68G8CYIur0hvj Content-Type: multipart/mixed; boundary="3j4lywllzJg6KOYX2tn5V7YuKMI2bbBPw"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert Cc: Michael Richardson , Anoop Kumar Pandey , anima@ietf.org Message-ID: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <20180710083528.u7fx4676cuzss33h@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180710083528.u7fx4676cuzss33h@faui48f.informatik.uni-erlangen.de> --3j4lywllzJg6KOYX2tn5V7YuKMI2bbBPw Content-Type: multipart/alternative; boundary="------------53BA6A1ECCE340E5E78E844B" Content-Language: en-US This is a multi-part message in MIME format. --------------53BA6A1ECCE340E5E78E844B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Toerless, On 10.07.18 10:35, Toerless Eckert wrote: > Thanks Eliot > > Very interesting, but can you explain why you think this is in the > same ballpark as the issue Anoop raised ? Yes, the reason I mentioned this is that it seems like we may want some additional authentication mechanism, such as proof of knowledge *on top* of the voucher model =E2=80=93 in some cases.=C2=A0 This might involve la= beling/BoM aspects.=C2=A0 Also, where the MASA lives is an interesting question.=C2=A0= From the AN perspective, at least to me, what is important is that the mechanism be tightly bound in terms of what code needs to be written, maybe with a few compile-time options. > > More inline. > > On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote: >> Hi Toerless, >> >> When we look at this scenario, we should consider several factors: >> >> * The manufacturer is in a position to control both the MASA and the= >> pledge.=C2=A0 That's useful because it means that there is less >> interoperability friction if the manufacturer wants to pass >> additional parameters between the pledge and the manufacturer, so >> long as the registrar doesn't interfere. > Haha. I am not sure you want to mention "interoperability friction" > in a venue whose purpose in life is interoperability (IETF).=20 > We discussed during BRSKI design this aspect, and i think > we can all see good flexiblity reasons for this side-channel, even > without having to blame ineroperability. > > The main issue is that it is a side-channel, and if there is any concer= ns > about BRKI it is the mistrust against manufacturers. SO i would hope th= at > any use of the side-channel would allow to establish the ability on > the registrar to passively analyze/observe that side-channel. Yes, that is an argument for documentation, and maybe some authorization.= > >> * In WiFi we have two additional issues: a device needs to do ANIMA,= >> but it needs to be authorized in some manner to do so.=C2=A0 > You mean we have the issue of getting initial 802.11 credentials to the= > pledge ? If not, then i didn't understand this bullet point. Yes. > >> * The second issue is one of network selection.=C2=A0 There is a nee= d for >> the pledge to really *know* that this is The network when 802.11 i= s >> involved.=C2=A0 What a manufacturer wants to avoid is a pledge joi= ning a >> network where the MASA just does the logging and does no validatio= n, >> without any other means to determine that the device is on the >> correct network.=C2=A0 Otherwise, the pledge (we could call it the= >> "station" in this context) could simply home to the wrong network,= >> and even resetting the device won't get you to the right network. > Right. BRSKI is called zero-touch, but there is really one touch left: > plugging a network cable into a right network port. With WiFi this can > be automated because selecting the right SSID can be done without > a human touch. I just wonder how we call it when we take one more touch= > away. BRSKI double zero (with a license to kill) ? ;-)) Well, that is the work to be done.=C2=A0 Someone else should name the solution, given how good I am at naming. > >> Owen will present something in Montreal that begins the discussion of >> these issues. > Great. > Eliot --------------53BA6A1ECCE340E5E78E844B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Toerless,


On 10.07.18 10:35, Toerless Eckert wrote:
Thanks Eliot

Very interesting, but can you explain why you think this is in the
same ballpark as the issue Anoop raised ?

Yes, the reason I mentioned this is that it seems like we may want some additional authentication mechanism, such as proof of knowledge on top of the voucher model =E2=80=93 in some cases.=C2=A0 Thi= s might involve labeling/BoM aspects.=C2=A0 Also, where the MASA lives is an interesting question.=C2=A0 From the AN perspective, at least to me, = what is important is that the mechanism be tightly bound in terms of what code needs to be written, maybe with a few compile-time options.

More inline.

On Tue, Jul 10, 2018 at 08:43:30AM +0200, Eliot Lear wrote:

Hi Toerless,

When we look at this scenario, we should consider several factors:

  * The manufacturer is in a position to control both the MASA and the
    pledge.=C2=A0 That's useful because it means that there is less
    interoperability friction if the manufacturer wants to pass
    additional parameters between the pledge and the manufacturer, so
    long as the registrar doesn't interfere.

Haha. I am not sure you want to mention "interoperability friction"
in a venue whose purpose in life is interoperability (IETF).=20
We discussed during BRSKI design this aspect, and i think
we can all see good flexiblity reasons for this side-channel, even
without having to blame ineroperability.

The main issue is that it is a side-channel, and if there is any concerns=

about BRKI it is the mistrust against manufacturers. SO i would hope that=

any use of the side-channel would allow to establish the ability on
the registrar to passively analyze/observe that side-channel.

Yes, that is an argument for documentation, and maybe some authorization.



  * In WiFi we have two additional issues: a devic=
e needs to do ANIMA,
    but it needs to be authorized in some manner to do so.=C2=A0

You mean we have the issue of getting initial 802.11 credentials to the
pledge ? If not, then i didn't understand this bullet point.

Yes.


  * The second issue is one of network selection.=C2=
=A0 There is a need for
    the pledge to really *know* that this is The network when 802.11 is
    involved.=C2=A0 What a manufacturer wants to avoid is a pledge joinin=
g a
    network where the MASA just does the logging and does no validation,
    without any other means to determine that the device is on the
    correct network.=C2=A0 Otherwise, the pledge (we could call it the
    "station" in this context) could simply home to the wrong network,
    and even resetting the device won't get you to the right network.

Right. BRSKI is called zero-touch, but there is really one touch left:
plugging a network cable into a right network port. With WiFi this can
be automated because selecting the right SSID can be done without
a human touch. I just wonder how we call it when we take one more touch
away. BRSKI double zero (with a license to kill) ?  ;-))

Well, that is the work to be done.=C2=A0 Someone else should name the= solution, given how good I am at naming.


Owen will present something in Montreal that begin=
s the discussion of
these issues.

Great.
Eliot
--------------53BA6A1ECCE340E5E78E844B-- --3j4lywllzJg6KOYX2tn5V7YuKMI2bbBPw-- --WELFqkKtN6BwWEOSW3Yn68G8CYIur0hvj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltEhZUACgkQh7ZrRtnS ejPpnwgAkfuWRQSukdw8Ob5qj0AbqjNM5SN67m3bw0V1NLLJ+ndO1G1wWOaS51W/ CpaDxVKd5un1JjA65r7Nu8TCYhpMi2PdKfsF/L8a22WpgDX6cgx18cgUOW9p/5oV 37/+a8/3DiNwyumBxq309U5wZcumSIIzb9zEqmfxjQJ9pOdPhU5ytL5A5v4gQst6 4Kbg2HsTS5cMfhojBRZ60u64BwyjWlmd6muQrt1wt6R67f8fvtHsDb0+2j/RCDOY +q4P5N/nXCNFR+Znswpv5ZVlUtY070EscB1fZaHX+xprqXDKTYWfX20Ye9dDwblh T7Lgvu9k8JPssD5FnLBCylxDG0SeAg== =Qg1N -----END PGP SIGNATURE----- --WELFqkKtN6BwWEOSW3Yn68G8CYIur0hvj-- From nobody Tue Jul 10 03:19:56 2018 Return-Path: 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 A9CD9130DF1 for ; Tue, 10 Jul 2018 03:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 6nUYtaJg4MXv for ; Tue, 10 Jul 2018 03:19:52 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E931B1292F1 for ; Tue, 10 Jul 2018 03:19:51 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1EEF958C4B3; Tue, 10 Jul 2018 12:19:47 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0EBE34401A4; Tue, 10 Jul 2018 12:19:47 +0200 (CEST) Date: Tue, 10 Jul 2018 12:19:46 +0200 From: 'Toerless Eckert' To: Anoop Kumar Pandey Cc: 'Michael Richardson' , anima@ietf.org Message-ID: <20180710101946.bfz73rbcfpysiqru@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> <007501d4182c$6985efc0$3c91cf40$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501d4182c$6985efc0$3c91cf40$@cdac.in> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 10:19:55 -0000 On Tue, Jul 10, 2018 at 02:30:12PM +0530, Anoop Kumar Pandey wrote: > Toerless>When the pledge opens a TLS connection to the registrar, the pledge > can authenticate the certificate presented by the registrar as part of the > TLS connection setup with the voucher. Thats what the voucher does. > > Anyone can present certificate of anyone else (it's public). YOu do understand how TLS authentication works, right ? > That's why I proposed use of digital signature and later verification > to establish the identity of both JRC and Pledge. Please try to understand how authentication of TLS peer with the help of voucher works. If it's unclear from BRSKI and rfc8366, feel free to ask more detailled questions. > Toerless>[there is the detail aspect of you saying owner public key whereas > the voucher uses the owners certificate, which is better, but lets ignore > tht for a second] > > Certificate is just a container for public key along with other meta data. Right. And that meta data makes the crucial difference. > Why go to such lengths and give headache of extra USB. Why can't the digital > invoice(or voucher) be embedded in the ROM in the device itself or be kept > wherever the IDevID has been put. Asked and answered. Also: Read up on ROM to understand why its not storage for device specific information and on TAM why those are not a good place to store public information like vouchers. > [If you use any external detachable device then that usb can used with other > pledge also(may be). If it is embedded, it's part of device] > > Toerless> Agreed. And we have an object that does this, its called the > voucher. > > I know. I only want to put it into the device itself so that communication > with MASA is not required and protocol becomes simpler as now pledge and JRC > can authenticate themselves using digital signature on the voucher. Sure. Hope you understood my explanations. No new artefact needed, no change to BRSKI needed. Cheers Toerless > Regards, > > Anoop > > > > > > -----Original Message----- > From: 'Toerless Eckert' [mailto:tte@cs.fau.de] > Sent: 10 July 2018 13:47 > To: Anoop Kumar Pandey > Cc: 'Michael Richardson' ; anima@ietf.org > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > > > On Tue, Jul 10, 2018 at 12:44:45PM +0530, Anoop Kumar Pandey wrote: > > > Toerless >The pledge simply needs to locate the voucher locally, and > > > when it connects to the registrar, it can skip the step of retrieving > > > the voucher because it already does trust the registrar as it has the > voucher locally. > > > > > > The pledge may have the voucher locally, but how will it know that the > > > domain it is going to register is the real owner. It may be some other > > > domain. For that, I suggested use of public key of owners in the > > > digital invoice which can be used to verify the signed acceptance sent by > JRC. > > > > Maybe i am confused and overlook something in your assumed setup, but: > > > > When the pledge opens a TLS connection to the registrar, the pledge can > authenticate the certificate presented by the registrar as part of the TLS > connection setup with the voucher. Thats what the voucher does. > > > > [there is the detail aspect of you saying owner public key whereas the > voucher uses the owners certificate, which is better, but lets ignore tht > for a second] > > > > > Once pledge and JRC have verified each other, enrolment can go on using > EST. > > > I want to eliminate the communication overhead or MASA itself. > > > > Yes, what i said does this. Pledge has voucher, pledge doe not need to > request voucher from Registrar, ergo Registrar does not need to connect to > MASA. > > > > > Toerless>I think those solutions are not ideal because they do > > > Toerless>introduce > > > another new "touch" to the pledge. > > > > > > > > > Anyway manufacturer is installing an IDevID, they can also install a > > > digital invoice (or voucher). > > > > Unless your devie is built to order, you do not know the owner at the time > when you put an IDevID onto a device. And putting an IDevID onto a device is > a highly specialized process in manufacturing where even if you where doing > build-to-order, you likely would want to separate it from assigning an owner > to a device. As Max said, the mayority of all devices are assigned an owner > when the product has long left the manufacturer and is now sitting in some > reseller hosted storge facility. > > > > > Toerless> The BRSKI document does allude to these options but does not > > > necessarily detail them well enough for every uninitiated reader to > > > understand the options. > > > > > > > > > Why leave something to someone's imagination. All necessary > > > details/angles/options can be entailed if it's provisioned in the > > > BRSKI already so that no stone is left unturned. > > > > ? Not sure i correctly understand that sentence. If its saying that it would > be good to write down the possible derived workflows, i think i already said > that in my email. > > > > > > > When a device is manufactured, it will only have IDevID. But when a > > > device is sold; before shipping, digital invoice may be embedded in > > > it. In this way the device may lie in the warehouse for years but > > > unless it has been sold, it is not unique to a customer. > > > > Its IMHO certainly a better option if the reseller puts the voucher onto the > device when it is shipping it out to the customer than the customer doing it > upon receipt/installation of the device. Alas, even in that option there are > operational pitfalls: > > > > Lets say you want voucher-on-a-stick. As long as you just attach that USB > stick to the products packaging, you're up to a high rate of errors on the > receiver side.. "What.. there was a USB stick in the packaging ? Where do i > need to put it ? Oh wait, the cleaner already threw away the packaging". > > > > So you want to make sure that the voucher is actually in the device itself. > > At minimum you would need the reseller to open the box and put the USB stick > into a specific USB port designed not to stick out, so tht that USB stick is > an undistinguishable part of the device. I knew few router products where > this is mechanically feasible. > > > > Or you can try to electronically load the voucher onto the device. > > Which just makes the whole thing even worse: > > > > IMHO, no reeller in their sane mind would want to open boxes to physically > attach a sales dongle to a device. Even less so do they want to > eletctrically power it on and run some magic uploa routine to put the > voucher onto the device. > > > > I think there are ways around this, i can write up something if i find the > time, but suffice to say: Without some better solutions than this, the most > lightweigt option is still to think of an offline system to feed the voucher > into the registrar if you want to avoid the BRSKI-MASA connection. Instead > of trying to feed it directly to the pledge. > > > > > > > > Michael"> Ultimately, it's not the JRC which is suspicious of who the > > > Pledge's owner is, it's the Pledge which does not know who owns it." > > > > > > > > > I assure you that pledge can verify the JRC using the public key put > > > in the digital invoice and using it to verify the digitally signed > > > acceptance note from JRC. > > > > Agreed. And we have an object that does this, its called the voucher. > > > > Cheers > > Toerless > > > > > Regards, > > > > > > Anoop > > > > > > > > > > > > -----Original Message----- > > > From: Toerless Eckert [ mailto:tte@cs.fau.de] > > > Sent: 10 July 2018 12:00 > > > To: Michael Richardson < > mcr+ietf@sandelman.ca> > > > Cc: Anoop Kumar Pandey < anoop@cdac.in>; > anima@ietf.org > > > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > > > > > > > > > > > Anoop: > > > > > > > > > > > > To rephrase from Michaels reply: > > > > > > > > > > > > You do not need any BRSKI protocol or voucher changes to do what you want. > > > > > > > > > > > > The pledge simply needs to locate the voucher locally, and when it > > > connects to the registrar, it can skip the step of retrieving the > > > voucher because it already does trust the registrar as it has the voucher > locally. > > > > > > > > > > > > In fact, you can even use RFC7030. If you already have a voucher > > > locally, you do not need BRSKI for voucher signalling. IMHO, you still > > > want BRSKI (instead of just RFC7030) because of the proxy and the > enrolment telemetry. > > > > > > > > > > > > This just leaves the whole painfull question Michael brings up: > > > > > > > > > > > > "how the heck do we get vouchers onto devices in the real world" ? > > > > > > This is IMHO where everybodies favourite options for managing "offline > > > vouchers" come into play. There are a lot of vendor solutions where > > > you feed those nodes information such as vouchers via USB sticks, or > > > temporarily connected cellphones to the pledge. > > > > > > > > > > > > I think those solutions are not ideal because they do introduce > > > another new "touch" to the pledge. But there are also simply a lot of > > > options how to get the voucher into the registrar without having to > > > use an online BRSKI-MASA connection. And then you just need to send > > > the voucher from the registrar to the pledge using BRSKI: No new > > > "touch" on the pledge, no BRSKI-MASA connection! > > > > > > > > > > > > The BRSKI document does allude to these options but does not > > > necessarily detail them well enough for every uninitiated reader to > > > understand the options. Followup documents refining individual > > > interesting workflows would certainly be useful IMHO (contributor, not WG > chair hat on). > > > > > > > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > > > > > > > On Sat, Jul 07, 2018 at 02:58:52PM -0400, Michael Richardson wrote: > > > > > > > > > > > > > > Anoop Kumar Pandey < < mailto:anoop@cdac.in> > anoop@cdac.in> wrote: > > > > > > > > When a device is purchased in real world, usually an invoice > > > > is > > > issued in the > > > > > > > > name of the purchaser with stamp of vendor/manufacturer. > > > > > > > > > > > > > > > I propose that similarly, a digital invoice can be issued > > > > which will > > > contain > > > > > > > > the public key(s) of the and > > > > digitally > > > signed by the > > > > > > > > manufacturer. The digital invoice may be embedded in the > > > > pledge > > > along with > > > > > > > > the IDevID. > > > > > > > > > > > > > > That's an interesting idea, perhaps you could write it up in the > > > > form > > > > > > > of an Internet-Draft? Then I could make sure that I fully > > > > understand > > > > > > > your proposal. > > > > > > > > > > > > > > It seems very difficult to make digitally signed invoices occur in > > > > the > > > > > > > real world, given the constrained of the supply chain. Still, BRSKI > > > > > > > makes provisions for higher security if the supply chain is integrated. > > > > > > > > > > > > > > I once proposed something similar using signed certficates: > > > > > > > > > > > > > > > > > > > > > HU9> > > > > https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9 > > > > > > > s5yqfRm0n00 > > > > > > > > > > > > > > In effect, the voucher artifact that we created in RFC8366 replaces > > > > > > > these certificates with purpose built signed artifacts that > > > > expresses > > > > > > > what the invoice attempts to express. > > > > > > > > > > > > > > > When a pledge starts the registration process, it will present > > > > the > > > digital > > > > > > > > invoice along with IDevID. The JRC can verify the digital > > > > signature > > > of the > > > > > > > > manufacturer on the digital invoice and sent a signed note of > > > acceptance to > > > > > > > > the pledge. The pledge can verify the signed note using the > > > > public > > > key(s) > > > > > > > > mentioned in the digital invoice, thereby verifying its true > owner. > > > > > > > > > > > > > > A pledge which has sat in a warehouse for a year before being sold > > > > to > > > > > > > an owner will not have the invoice on it yet. That's okay, because > > > > > > > the invoice, being digitally signed, could be retrieved from another > > > > > > > place, and that's effectively what the BRSKI-MASA protocol *does*. > > > > > > > > > > > > > > If the invoice needs to be loaded into the Pledge via a > > > > > > > secure-out-of-band mechanism, (i.e. during the manufacturing > > > > process), > > > > > > > then the Pledge could also be fully configured, and could include a > > > > > > > simple PSK too. This is the approach which is being used in > > > draft-ietf-6tisch-minimal-security. > > > > > > > > > > > > > > Ultimately, it's not the JRC which is suspicious of who the Pledge's > > > > > > > owner is, it's the Pledge which does not know who owns it. > > > > > > > > > > > > > > > This process with eliminate all the communication overhead > > > > with MASA > > > and > > > > > > > > multiple level verification (voucher request, voucher, > > > > telemetry etc > > > at > > > > > > > > JRC/MASA/Pledge). > > > > > > > > > > > > > > Yes, it does, at the cost of making every device in the warehouse > > > > unique > > > to a > > > > > > > specific customer. If I may make an analogy to distribution of movies, > > > > > > > you are suggesting that netflix go back to mailing DVDs to people. > > > > > > > > > > > > > > > From security point of view: Given that the digital invoice is > > > digitally > > > > > > > > signed by manufacturer, the public key of domain owner > > > > embedded in > > > the > > > > > > > > digital invoice can???t be changed, otherwise verification of > > > digital signature > > > > > > > > of manufacturer at JRC end will fail. > > > > > > > > > > > > > > > Requesting you to give your comments as it will simplify the > > > protocol. > > > > > > > > > > > > > > > P.S.: As you had earlier mentioned ???On resale, the device > > > > should > > > be put > > > > > > > > through a factory reset to clear things. The MASA will have to > > > > be > > > willing to > > > > > > > > issue a new voucher to the new domain owner..???; here also, > > > manufacturer may > > > > > > > > issue a new digital invoice in case of resale. > > > > > > > > > > > > > > yes, that's true. But, since you said that the invoice is in the > > > > > > > Pledge, the manufacturer would have to take the device back to do that. > > > > > > > > > > > > > > The reason for all the JRC,MASA etc, is so that we do not need to > > > > have > > > > > > > the manufacturer touch the device a second time. > > > > > > > > > > > > > > -- > > > > > > > ] Never tell me the odds! | ipv6 mesh > > > networks [ > > > > > > > ] Michael Richardson, Sandelman Software Works | network > > > architect [ > > > > > > > ] < mailto:mcr@sandelman.ca> > mcr@sandelman.ca > > > < http://www.sandelman.ca/> > http://www.sandelman.ca/ | ruby on rails > > > [ > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Michael Richardson < < > mailto:mcr+IETF@sandelman.ca> > > > mcr+IETF@sandelman.ca>, Sandelman Software > Works > > > > > > > -= IPv6 IoT consulting =- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Anima mailing list > > > > > > > < mailto:Anima@ietf.org> > Anima@ietf.org > > > > > > > < > https://www.ietf.org/mailman/listinfo/anima> > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > > > > < mailto:tte@cs.fau.de> > tte@cs.fau.de > > > > > > > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > [ C-DAC is on Social-Media too. Kindly follow us at: > > > Facebook: > https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > > > > > This e-mail is for the sole use of the intended recipient(s) and may > > > contain confidential and privileged information. If you are not the > > > intended recipient, please contact the sender by reply e-mail and > > > destroy all copies and the original message. Any unauthorized review, > > > use, disclosure, dissemination, forwarding, printing or copying of > > > this email is strictly prohibited and appropriate legal action will be > taken. > > > ---------------------------------------------------------------------- > > > --------------------------------------------------------- > > > > > > > -- > > --- > > tte@cs.fau.de > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------------------------------------------------------------------------- > -- --- tte@cs.fau.de From nobody Tue Jul 10 13:51:27 2018 Return-Path: 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 48E57130E76 for ; Tue, 10 Jul 2018 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XVux9Nw4YvNi for ; Tue, 10 Jul 2018 13:51:23 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48965130EAA for ; Tue, 10 Jul 2018 13:51:23 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id j3-v6so16870504pfh.11 for ; Tue, 10 Jul 2018 13:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1tb/ViPuJnNIHZYEQEvHz7z91Gf7j0PTUc2xiNNobKQ=; b=I2sEV1SIwuRScJOUP93iEXJ5e/OZU1IJSKALjKl3vdmOhL2pz1hjXkogvV9BfN2ML8 h/R0WR855dwzcMDLbrZ/9Uun1hIGTgCE2r1tt1o8Z866nPmkcIdyKFV285YWtPDP1xRa JZ3VpViBtQfXx5cTIxKlTHc/wto7MZJQHPLGc+z+CduuHFHM5KBHyhCjQYqmlKPQ3//w 5zJDNe4zutccTYWiDoZhj/1Iv9KXfbHLriaCUGCvv9eA+wA49inSez8ggzql6j+Vi0C4 H8RMa7+B7gayhztUkoqlGFH8BeTxJvjRiYH/yNTtybwwmRHkZi6tv6EptOZC2ff3aGBg CXSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1tb/ViPuJnNIHZYEQEvHz7z91Gf7j0PTUc2xiNNobKQ=; b=aofTgEOiiIMyN5SwxqNpml0PPpNfAtmeH89TZzf5olOhhD6eBvsFB/Em2+jGEVlYdf 9E/oqd0z41MAZScQeEJ6oIG9zwZBHufnfKFMLtShYd6TH6yrb0Xsvyunk4215uzo9QqO rmCUnoZ2zW6xIycE3n5GJDmwwhdI5VkF55FrUV+quR9WInAZvrltCVCNg4F38tFYOAxp bRddwhtJUEBgvPwsO1WKpHjPa8BZQvVUQRgV5jwjOTkuBiwI2jwfz8y42zaPyX1HIkcj IxoL4pddudQMqUCb/yfAlCpsaEQLnaS7mWvregXJCNcQ0grnOOO8aXLQMPPgt33HHjrh Z3tA== X-Gm-Message-State: APt69E2x08/DtNdMHoTf6Jz+gaCkm2jSckq7Ii2UqYIUk75byvl/GbqV ShWp/AMaER04deXEO0vqei7MTw== X-Google-Smtp-Source: AAOMgpcioRT7XrZBElL87nyo0eJgmmCwC0AI9urIJBpEatalgQJW9+C2L2u2PZbk9e5UvKQJztUufA== X-Received: by 2002:a63:440a:: with SMTP id r10-v6mr23876339pga.27.1531255882559; Tue, 10 Jul 2018 13:51:22 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id d9-v6sm21598136pfb.86.2018.07.10.13.51.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 13:51:21 -0700 (PDT) To: Toerless Eckert Cc: Anima WG References: <153056233884.16161.8599345146300412702@ietfa.amsl.com> <20180710060635.wrhsdt7nuhyvaxr2@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <99fcb1fb-00fb-b377-5333-13d15555cddf@gmail.com> Date: Wed, 11 Jul 2018 08:51:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180710060635.wrhsdt7nuhyvaxr2@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] role management in ANI/NIMA X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 20:51:26 -0000 Yes to all that. In particular: > It would be great if followup work in ANIMA would tackle the > problem of role management. I think that is necessary, and it's quite closely tied to the question of the domain boundary, which will presumably limit the scope of a role. And I have draft-choi-anima-trust-networking high on my reading list, too. Regards Brian Carpenter On 10/07/2018 18:06, Toerless Eckert wrote: > Thanks Brian, as always, great recommendation. > > It would be great if followup work in ANIMA would tackle the > problem of role management. In the case of this drafts > simple view at the world its a simple master/slave role > assignment: You have few master nodes such as those in the NOC > and registrars that are still "manually" configured, and a > much larger number of "zero-touch" slave nodes (all the other nodes) > that are controlled by the masters via a combination of > ANIMA/ANI and SDN. And we could easily add this model > via simple binary distinctions in the Domain Certificates. > And appropriate signing element in GRASP messages. > > I just wonder if its worth tackling this role management > problem if we only have an idea how to solve this simple > "SDN"'ish case. Would be a lot more useful if we had a more > generalized solution that would also work in more > autonomic networks with a lot more ASA - aka: how do > we manage the privileges/roles of ASAs... ? The classic > solution is probably role/privilege assignment from those > NOC-master nodes. And if such schemes can distribute > appropriate credentials (role certificates), we can easily add > this too. > > Then again, i think more fully distributed, autonomic > networks might want to have a more innovative solution approach > to roles. There is for example the proposal direction > we wanted to present in DINRG to use blockchain/distributed > ledger technologies. Or in other words: An ASA could > ultimately raise to a particular role by collecting credit > in the blockchain through "proof of doing a good job and > being trustworthy". > > This would be cool stuff to get into ANIMA, but of course, i > at this point in time i am no sure how far away this type > of technology is from being applicable to IETF (as opposed > to being refined in IRTF). > > Cheers > Toerless > > > On Mon, Jul 09, 2018 at 03:57:38PM +1200, Brian E Carpenter wrote: >> Hi, >> >> I've had a very quick look at this draft, and it didn't ring any alarms. >> Just one small comment on the Security Considerations, which starts: >> >>> There is no protection against "unauthorized" ACP nodes to generate >>> service announcements, because there is no authorization scheme in >>> GRASP. >> >> That sounds a bit brutal. I suggest replacing the sentence: >> >> All ACP nodes are at the same level of trust, as a result of >> successfully enrolling and joining the ACP. However, there is >> currently no mechanism in GRASP for indicating and authorizing >> the role of a node. Therefore there is no protection against ACP >> nodes generating inappropriate service announcments. >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jul 10 14:44:09 2018 Return-Path: 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 A2FD212872C for ; Tue, 10 Jul 2018 14:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 90xH3jOOv59S for ; Tue, 10 Jul 2018 14:44:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0017B131100 for ; Tue, 10 Jul 2018 14:44:03 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 848927E4FE80E for ; Tue, 10 Jul 2018 22:43:57 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Jul 2018 22:43:59 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Wed, 11 Jul 2018 05:43:49 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" CC: "Liubing (Leo)" Thread-Topic: [Anima] Primary ANIMA Agenda for IETF102 Thread-Index: AdQXL9yLlGOCmFIkRy+W0JIMa/yeTf//gW8A//yz+XA= Date: Tue, 10 Jul 2018 21:43:48 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B929011C5FC@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B92901119D9@NKGEML515-MBX.china.huawei.com> <8794180a-1dd7-e478-fe24-b3852d5b78c5@gmail.com> In-Reply-To: <8794180a-1dd7-e478-fe24-b3852d5b78c5@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.232] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Primary ANIMA Agenda for IETF102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:44:07 -0000 SGksIEJyaWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgY2FyZWZ1bGx5IGNoZWNraW5nLiBJIHByZWZl ciB0byBrZWVwIDJhIGFuZCBjdXQgaXRlbSA3IHRvIGJlIHR3byBkcmFmdHMsIGdpdmluZyB0aGV5 IGFyZSBpbiBkaWZmZXJlbnQgc3RhZ2VzIGZvciBXRyBjb25jZXJuLiBJIGhhdmUgc2hvcnRlbiBi b3RoIHByZXNlbnRhdGlvbiB0aW1lIGFzIHlvdSBzdWdnZXN0ZWQuIFlvdSBtYXkgY29uc2lkZXIg dG8gYXNrIFdHIGFkb3B0aW9uLCB3aGlsZSBJIGFtIGhvcGluZyB3ZSB3aWxsIGhhdmUgbmV3IGNo YXJ0ZXIgdGV4dCBzb29uLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KU2VudDogTW9uZGF5LCBKdWx5IDks IDIwMTggMTE6MTkgQU0NClRvOiBhbmltYUBpZXRmLm9yZw0KQ2M6IExpdWJpbmcgKExlbykgPGxl by5saXViaW5nQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBSZTogW0FuaW1hXSBQcmltYXJ5IEFOSU1B IEFnZW5kYSBmb3IgSUVURjEwMg0KDQpIaSBTaGVuZywNCg0KTXkgc3VnZ2VzdGlvbiB3YXMgdG8g Y29tYmluZSAgZHJhZnQtaWV0Zi1hbmltYS1ncmFzcC1hcGksIGRyYWZ0LWNhcnBlbnRlci1hbmlt YS1hc2EtZ3VpZGVsaW5lcyBhbmQgZHJhZnQtY2FycGVudGVyLWFuaW1hLWdyYXNwLWJ1bGssIGlu IG9uZSAocXVpY2spIHByZXNlbnRhdGlvbiwgdG8gc2F2ZSB0aW1lLiBUaGF0IGlzIGl0ZW0gNywg ZXhjZXB0IHRoYXQgb25seSBvbmUgZHJhZnQgaXMgbGlua2VkLiBXZSBuZWVkIG9ubHkgb25lIHNs aWRlIHBlciBkcmFmdCwgYmVjYXVzZSB0aGVyZSBpcyBsaXR0bGUgY2hhbmdlLiBCdXQgaXRlbSA3 IG92ZXJsYXBzIHdpdGggaXRlbSAyYS4gUGxlYXNlIGxldCB1cyBrbm93IHdoYXQgeW91IHByZWZl ci4NCg0KICAgQnJpYW4NCg0KDQoNCk9uIDA5LzA3LzIwMTggMTQ6NTQsIFNoZW5nIEppYW5nIHdy b3RlOg0KPiBIaSwgQU5JTUEsDQo+IA0KPiBUaGUgYmVsb3cgaXMgdGhlIGxpbmsgdG8gb3VyIHBy aW1hcnkgQU5JTUEgYWdlbmRhLiBJdCBpcyBhIHN1YmplY3QgdG8gYmUgY2hhbmdlZC4NCj4gDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL2FnZW5k YS0xMDItYW5pbWEtMDANCj4gDQo+IFBsZWFzZSBubyBoZXNpdGF0ZSB0byBjb250YWN0IHRoZSBj aGFpciBmb3IgYW55IG1pc3Mgb3IgbWlzdGFrZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBTaGVu Zw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5pbWFAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiANCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFuaW1hIG1haWxpbmcgbGlzdA0K QW5pbWFAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5p bWENCg== From nobody Tue Jul 10 14:57:33 2018 Return-Path: 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 8EA17131196; Tue, 10 Jul 2018 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ddvgDnWtOLk4; Tue, 10 Jul 2018 14:57:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 578CB13118D; Tue, 10 Jul 2018 14:57:27 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9B1B290C095DF; Tue, 10 Jul 2018 22:57:23 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Jul 2018 22:57:24 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Wed, 11 Jul 2018 05:57:07 +0800 From: Sheng Jiang To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Updated//RE: Primary ANIMA Agenda for IETF102 Thread-Index: AdQYmJSJXCNa7GstR8Ct6r30+PFaIQ== Date: Tue, 10 Jul 2018 21:57:06 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B929011C652@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.232] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B929011C652NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Updated//RE: Primary ANIMA Agenda for IETF102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 21:57:31 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B929011C652NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KQW4gdXBkYXRlZCB2ZXJzaW9uIGhhcyBiZWVuIHVwbG9hZGVkIHRvIGZpeCBh IGNvdXBsZSBtaXN0YWtlcy4gUGxlYXNlIG5vIGhlc2l0YXRlIHRvIGNvbnRhY3QgdGhlIGNoYWly IGZvciBhbnkgbWlzcyBvciBtaXN0YWtlLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L21lZXRpbmcvMTAyL21hdGVyaWFscy9hZ2VuZGEtMTAyLWFuaW1hLTAxDQoNClJlZ2FyZHMsDQoN ClNoZW5nDQoNCkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFNoZW5nIEppYW5nDQpTZW50OiBNb25kYXksIEp1bHkgOSwgMjAxOCAxMDo1NCBB TQ0KVG86IGFuaW1hQGlldGYub3JnDQpDYzogYW5pbWEtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0 OiBbQW5pbWFdIFByaW1hcnkgQU5JTUEgQWdlbmRhIGZvciBJRVRGMTAyDQoNCkhpLCBBTklNQSwN Cg0KVGhlIGJlbG93IGlzIHRoZSBsaW5rIHRvIG91ciBwcmltYXJ5IEFOSU1BIGFnZW5kYS4gSXQg aXMgYSBzdWJqZWN0IHRvIGJlIGNoYW5nZWQuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL2FnZW5kYS0xMDItYW5pbWEtMDANCg0KUGxlYXNlIG5v IGhlc2l0YXRlIHRvIGNvbnRhY3QgdGhlIGNoYWlyIGZvciBhbnkgbWlzcyBvciBtaXN0YWtlLg0K DQpSZWdhcmRzLA0KDQpTaGVuZw0K --_000_5D36713D8A4E7348A7E10DF7437A4B929011C652NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiIHN0eWxlPSJ0ZXh0LWp1c3RpZnktdHJpbTpwdW5jdHVhdGlvbiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSwgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BbiB1cGRhdGVkIHZlcnNpb24g aGFzIGJlZW4gdXBsb2FkZWQgdG8gZml4IGEgY291cGxlIG1pc3Rha2VzLiBQbGVhc2Ugbm8gaGVz aXRhdGUgdG8gY29udGFjdCB0aGUgY2hhaXIgZm9yIGFueSBtaXNzIG9yIG1pc3Rha2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJp YWxzL2FnZW5kYS0xMDItYW5pbWEtMDEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy8xMDIvbWF0ZXJpYWxzL2FnZW5kYS0xMDItYW5pbWEtMDE8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlNoZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFuaW1hIFttYWlsdG86 YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2hlbmcgSmlhbmc8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDksIDIwMTggMTA6NTQgQU08YnI+DQo8Yj5U bzo8L2I+IGFuaW1hQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBhbmltYS1jaGFpcnNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0FuaW1hXSBQcmltYXJ5IEFOSU1BIEFnZW5kYSBmb3Ig SUVURjEwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSwgQU5JTUEsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg YmVsb3cgaXMgdGhlIGxpbmsgdG8gb3VyIHByaW1hcnkgQU5JTUEgYWdlbmRhLiBJdCBpcyBhIHN1 YmplY3QgdG8gYmUgY2hhbmdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxzL2FnZW5kYS0xMDItYW5p bWEtMDAiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDIvbWF0ZXJpYWxz L2FnZW5kYS0xMDItYW5pbWEtMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugbm8gaGVz aXRhdGUgdG8gY29udGFjdCB0aGUgY2hhaXIgZm9yIGFueSBtaXNzIG9yIG1pc3Rha2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2hlbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B929011C652NKGEML515MBXchi_-- From nobody Tue Jul 10 21:11:15 2018 Return-Path: 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 AB691130EBF for ; Tue, 10 Jul 2018 21:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wpucm82e08YM for ; Tue, 10 Jul 2018 21:11:12 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01010130E54 for ; Tue, 10 Jul 2018 21:11:11 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id l9-v6so5877934pff.9 for ; Tue, 10 Jul 2018 21:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0GZ7wthHtrSaALIlzxm7sCf2PhGVUjr4bzdeghRjzWE=; b=ksS+dp33frWGK1xh4MD2aTtBiHFfwENkYZdmEVm+oHVNZqdR5ezF/wuAIG7Y6RcDQv 3fXwUrvE4nCFzBxlqdUUU0PnXD97HzgDwq86SWYnv87A3hI9fU40bwWn28vqoWhWbo4k V52oUyjCt5C3IT8Zhwdn7tdqZrUGJ0VydJVd10MDcc0awjm9cuqrhKVagaJx5acIZCbz ibDhfHXfHOc8kR39hVspyjCLb+lmLKanQ2aPl6umuzMD5LcKmOCc1qigGmlno6J0HRRn xoXxdIHOe8cDYzUxB/LbgBU8EMFkmG3Kqh/tj7koj7tzs+FBCmsm7Q6C/FMwxLyye0FH gMMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0GZ7wthHtrSaALIlzxm7sCf2PhGVUjr4bzdeghRjzWE=; b=di3u9LCetot7CbxQtR0E6RUrt64baKxu7GynPaZgvxkTkzMhTkpiuk8gJ1IWwoOXA2 pBx2OPZtwDiuWt3kvea+BtdQE8FrPpm4hhnfk4JbzHMG+8oWxxi60dikQ9Z5fmXZuHcE 5Ic5IsGTe2raj/vTOg7UukIFDt3oAG/nElavamiVA712/TXQHXN/98wEc2VHyPpZn+s9 g8UL4kr50URxBLZckb6wfX4Yo8Vk6v8sxbb2ra+tFZnBFST2H/4qvMoq/lxujqNvkGJ2 /4V540GeGg6/x6NvJbdP1DLM5tvwFdHSslY4aGbwkUYsk+4X0Z0FyW32wPjsgi9/DNd0 7DGg== X-Gm-Message-State: APt69E2+YhAPBwiVYFrcJmahl1CrI+T+lEtrwz08Gf9VHLT/GfsWGAsX 0jo5mCpJ6efmPsodod2iRW4= X-Google-Smtp-Source: AAOMgpcgZF1Wb7jaHmwplu2aPpszzbqgJNDf8dvPQVP25i7H8yez2Jh1Esshim6xEOQU0vJMrwwogg== X-Received: by 2002:a63:416:: with SMTP id 22-v6mr25260478pge.229.1531282271434; Tue, 10 Jul 2018 21:11:11 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z10-v6sm37405795pgc.9.2018.07.10.21.11.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 21:11:10 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: "Liubing (Leo)" References: <5D36713D8A4E7348A7E10DF7437A4B92901119D9@NKGEML515-MBX.china.huawei.com> <8794180a-1dd7-e478-fe24-b3852d5b78c5@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B929011C5FC@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Message-ID: <9f21763b-5c41-1dd8-32c6-84768940ce36@gmail.com> Date: Wed, 11 Jul 2018 16:11:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B929011C5FC@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Primary ANIMA Agenda for IETF102 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 11 Jul 2018 04:11:14 -0000 OK, I have prepared slides accordingly. Regards Brian On 11/07/2018 09:43, Sheng Jiang wrote: > Hi, Brian, > > Thanks for your carefully checking. I prefer to keep 2a and cut item 7 to be two drafts, giving they are in different stages for WG concern. I have shorten both presentation time as you suggested. You may consider to ask WG adoption, while I am hoping we will have new charter text soon. > > Best regards, > > Sheng > > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Monday, July 9, 2018 11:19 AM > To: anima@ietf.org > Cc: Liubing (Leo) > Subject: Re: [Anima] Primary ANIMA Agenda for IETF102 > > Hi Sheng, > > My suggestion was to combine draft-ietf-anima-grasp-api, draft-carpenter-anima-asa-guidelines and draft-carpenter-anima-grasp-bulk, in one (quick) presentation, to save time. That is item 7, except that only one draft is linked. We need only one slide per draft, because there is little change. But item 7 overlaps with item 2a. Please let us know what you prefer. > > Brian > > > > On 09/07/2018 14:54, Sheng Jiang wrote: >> Hi, ANIMA, >> >> The below is the link to our primary ANIMA agenda. It is a subject to be changed. >> >> https://datatracker.ietf.org/meeting/102/materials/agenda-102-anima-00 >> >> Please no hesitate to contact the chair for any miss or mistake. >> >> Regards, >> >> Sheng >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Jul 11 20:15:30 2018 Return-Path: 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 24DB0130FF1 for ; Wed, 11 Jul 2018 20:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 N28T0oMYiQ_F for ; Wed, 11 Jul 2018 20:15:26 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6466D130E7F for ; Wed, 11 Jul 2018 20:15:26 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id x10-v6so9816658pfm.4 for ; Wed, 11 Jul 2018 20:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RBxDqliphi2lME73XnuoezaoTjV9Y2h2YDjrJOoRIF4=; b=HcU1GDm/Zzvsc59spujBiD1C52SeDkrKHoqYSM41fYcr0R90n0LP0DPcmZTAsiuYma aE9xZTQxBq33Qczzr8soHovXQy7Jfj86gtCUUSEO4tng03kkDyD8Tn7c1REpStf/4pSB 1GNZHHT9wmXwOSNzK4PMLwX7DDtMuUB7ofbt9siYFGbJOFmogWeZu78HjQp62V4ZLWAP HnULz8MUFMxCzM4AX5ZNcBJapEk8oQwIHIEez5+HCyC6gc41X6+Q7gFK7xHxpWtvSFwZ l15UWkztQO8aTZ5vNC5ZUhObvXObvL67noa77YJhDJ8jh1nEC+IJOG1Rm6mjXc0jE/nr 31+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RBxDqliphi2lME73XnuoezaoTjV9Y2h2YDjrJOoRIF4=; b=JSgrrKN6RWZxQFzMBq1E9+IbymbE796v0VDha/Fwk1AEPy0YAHt7q6pqm9nPEVsWcA sRjZix+5bpiZYq1Z1xWehI8HSe/BEfhsP5F7NX9+uGrIEhW3Pe2ja9DchY/jIESJQxGp IWpdojqTo/s8d1g6Iu1i6il7zrMQ34S6dJ3HrVX0qsUM3yQwOo9AdkcHv2R4WVXg78wT +cXrU8c+Y+UhUmyOmHGvqXUKhzx3lF3Pnmrmlw99i7+2mjqsBbSPLm3n9sPNItcAvvSY 0Ljr/esM1THYMFU11f8sIIkB++3LELp9cw6gDDAauV1kkI8zOm4gWdx9bQIN6ycVcFEq wdtw== X-Gm-Message-State: AOUpUlGjNOZ1Ax4j23nL95b2fZMpEXmS95GrfqEFB1zAXrflUYKqo0vB hMa78VrjOS1thqQ9o1ziWWLnRQ== X-Google-Smtp-Source: AAOMgpebnsBw/7yK0KraQOtta96pdjl96grOGdGn43Tx7G2XEfp6TtGDxUj4E5KHLqBgSVuKDeRdHg== X-Received: by 2002:a63:383:: with SMTP id 125-v6mr448321pgd.421.1531365325374; Wed, 11 Jul 2018 20:15:25 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id 5-v6sm47531873pgc.86.2018.07.11.20.15.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 20:15:24 -0700 (PDT) To: Anima WG References: <153052861098.28235.15477231715646760940@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <8d3e90f7-8792-824a-32d2-cbafabc9f45c@gmail.com> Date: Thu, 12 Jul 2018 15:15:28 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <153052861098.28235.15477231715646760940@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:15:28 -0000 Hi, I haven't had time to carefully read sections 1-5, but I think their general message is fine. Here are some first comments on section 6, the proposed GRASP extensions: > In fragmentary CDDL, a Un-solicited Synchronization message follows > the pattern: > > unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, objective] > > A node MAY actively send a unicast Un-solicited Synchronization > message with the Synchronization data, to another node. This MAY be > sent to port GRASP_LISTEN_PORT at the destination address, which > might be obtained by GRASP Discovery or other possible ways. The > synchronization data are in the form of GRASP Option(s) for specific > synchronization objective(s). Three comments on that: 1. For this to work, the receiving node must always be listening for a new TCP session on that port. So that means a new API function (listen_unsolicited?) and of course either a separate thread or an additional entry in the event loop. Not a problem, just an implementation comment. 2. We need to specify that a new session_id is generated for each new M_UNSOLDSYNCH message. 3. Is this available for any synchronization objective, or do we need to add a new flag bit? > The selective flood option encapsulates a match-condition option > which represents the conditions regarding to continue or discontinue > flood the current message. To be clear, the match is evaluated in every node, and the flooded objective is dropped if there is a match? So we save on storage, not on processing. > 6.5 Publishing Objective Option > > In fragmentary CDDL, a Publish Objective Option follows the pattern: > > publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name > = PUBLISH > objective-flags = 2 > loop-count = 2 > pubobj = text > > This option MAY be included in GRASP M_Synchronization, when > included, it means this message is for a publish of a specific object > data. Can it also be included in M_UNSOLDSYNCH ? (In other words, the pub/sub bus does not need to send M_REQ_SYN, but always listens for M_UNSOLDSYNCH.) Regards Brian From nobody Wed Jul 11 20:58:36 2018 Return-Path: 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 A1276130DE8; Wed, 11 Jul 2018 20:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 r3-B9B2qkWbg; Wed, 11 Jul 2018 20:58:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0D0CD130EB7; Wed, 11 Jul 2018 20:58:31 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C1B2BE5E4A09F; Thu, 12 Jul 2018 04:58:27 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 04:58:29 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 11:58:26 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Anima WG CC: "draft-liu-anima-grasp-distribution@ietf.org" Thread-Topic: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt Thread-Index: AQHUEfKHb5EtQamVFUChKT4jCLgcgaSKcykAgACHtCA= Date: Thu, 12 Jul 2018 03:58:26 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C7A9D6A9@nkgeml514-mbx.china.huawei.com> References: <153052861098.28235.15477231715646760940@ietfa.amsl.com> <8d3e90f7-8792-824a-32d2-cbafabc9f45c@gmail.com> In-Reply-To: <8d3e90f7-8792-824a-32d2-cbafabc9f45c@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 03:58:34 -0000 Hi Brian, Thanks for your comments! Since this new version proposed some protocol ext= ensions, we really need review from GRASP perspective. Please see reply inl= ine. > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Thursday, July 12, 2018 11:15 AM > To: Anima WG > Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.tx= t >=20 > Hi, >=20 > I haven't had time to carefully read sections 1-5, but I think their gene= ral > message is fine. Here are some first comments on section 6, the proposed > GRASP extensions: >=20 > > In fragmentary CDDL, a Un-solicited Synchronization message follows > > the pattern: > > > > unsolicited_synch-message =3D [M_UNSOLDSYNCH, session-id, > > objective] > > > > A node MAY actively send a unicast Un-solicited Synchronization > > message with the Synchronization data, to another node. This MAY be > > sent to port GRASP_LISTEN_PORT at the destination address, which > > might be obtained by GRASP Discovery or other possible ways. The > > synchronization data are in the form of GRASP Option(s) for specific > > synchronization objective(s). >=20 > Three comments on that: >=20 > 1. For this to work, the receiving node must always be listening for a ne= w TCP > session on that port. So that means a new API function > (listen_unsolicited?) and of course either a separate thread or an additi= onal > entry in the event loop. Not a problem, just an implementation comment. [Bing] I believe so, another API should be needed. > 2. We need to specify that a new session_id is generated for each new > M_UNSOLDSYNCH message. [Bing] Yes, detailed behavior will be completed in the next version. > 3. Is this available for any synchronization objective, or do we need to = add a new > flag bit? [Bing] Ideally, I think the possibility should be open for any Synchronizat= ion Objective. But personally I prefer to avoid revising the base protocol = as much as possible (e.g. changing the flag bits). How about we just assume= any Sync Obj could be Un-solicited, would there be any harmfulness? > > The selective flood option encapsulates a match-condition option > > which represents the conditions regarding to continue or discontinue > > flood the current message. >=20 > To be clear, the match is evaluated in every node, and the flooded object= ive is > dropped if there is a match? So we save on storage, not on processing. [Bing] Yes, it's even more flexible that we can define either "something ma= tched" or "something not matched" to let the node drop the flooded messages= . Save on storage is surely one benefit, but I think maybe the more beneficia= l is saving on network traffic, especially in an constrained environment. A= nd also on security benefit, that some sensitive informative won't be propa= gated too far. =20 > > 6.5 Publishing Objective Option > > > > In fragmentary CDDL, a Publish Objective Option follows the pattern: > > > > publish-objection-option =3D [PUBLISH, 2, 2, pubobj] objective-na= me > > =3D PUBLISH > > objective-flags =3D 2 > > loop-count =3D 2 > > pubobj =3D text > > > > This option MAY be included in GRASP M_Synchronization, when > > included, it means this message is for a publish of a specific objec= t > > data. >=20 > Can it also be included in M_UNSOLDSYNCH ? (In other words, the pub/sub b= us > does not need to send M_REQ_SYN, but always listens for M_UNSOLDSYNCH.) [Bing] Currently, we follow the principle that Sub/Pub should be a more str= ict transaction model. Un-solicited Pub seems too arbitrary. But we can leave it as an open question, let's see if we could find some sc= enarios that really benefited from un-solicited Pub. Btw, we actually cared more about another question regarding to Sub/Pub. Fr= om semantic perspective, we actually preferred to make Sub/Pub as new messa= ges, rather than current objective extension. But later we thought we shoul= d utilize the base protocol as much as possible, so we chose objective exte= nsion. May I ask your opinion on this? Best regards, Bing >=20 >=20 > Regards > Brian >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Jul 11 22:26:15 2018 Return-Path: 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 23E25131031; Wed, 11 Jul 2018 22:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xvrfwr51tP0g; Wed, 11 Jul 2018 22:26:11 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E52913102C; Wed, 11 Jul 2018 22:26:08 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id b17-v6so19884339pfi.0; Wed, 11 Jul 2018 22:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WHeGzt2pV9jzgEM8gQYe+rL+eMW3dKnoTGhW5N6FZzM=; b=HKsPC2xwGLoU46+YfUCoAiDzVvjYr6vezHsxHG7FIsQZ8OYkq4OYkH1815wUcKhPwi 1u0jrej+dK+P3sUItJ/MD/SlNG4eK9sAmk7P3pz4oo5JXwKqj3xaU2wUTznsSIk5afk+ dXudHN39P8jIhSApvRwXXVgiqYbfck9J4gY+aEGkr6vpOnMMxowXiNus9Ja4MPoDiaFS bhoTar3j8QuNwePKhqjyf0LWO0GB2C/cJddTAwaoy+iqxlesPw3rqCPl+GBr0jx0yT8L 6KYuM3kYIWfJifJN/6EkC7llioC//yYHYox4RCrrXgEaYuNASDfgsfWScoMxC0Q+CGHC CaGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WHeGzt2pV9jzgEM8gQYe+rL+eMW3dKnoTGhW5N6FZzM=; b=Lc9wPTMpY7MUNihho0hUaKyTQdDptR1JSlcYTmn33qR4ygGLLFgRmzRrNdfsuzynXH NgWfgFX7yRKk52l9hxR70dvgJy8VJtKf237WMkIrbikoKMnW1meCi70odQCw5XPJuM4t mG5Rk22w/kSqUeT1Frx7G3FCQz/QTANj5Zh75cs9PfqJAt5wlxZY/GBbm4qsnuOnX4dm xejqqIk1chqKZfRqt06L5U8mfLf7Oju3lvY2U5hqwBx2kgPvzw7FLb9Wk2kmrNjiwEnY LunJY/TouHKUKLH396gDVqb8sG7RgWxoE1QqrXzK8vYl6cO0T3L7kEqRC2esKXcU8tSb /WBw== X-Gm-Message-State: AOUpUlHxE2DvxXBi77fNL5YxVGx4Bs7DmmTcpBvZoadyLVeIJrtSQO3o 0RkwZMOaGKlqk4rbBwWCQWJpQA== X-Google-Smtp-Source: AAOMgpc6SYLZMkzkY5CJZykA89dB0RUJ0KXHercCC+jpy2ZKB4IPT/KN4RxL9kCEgoWUim0XleZ5Dw== X-Received: by 2002:a62:c819:: with SMTP id z25-v6mr862881pff.44.1531373167443; Wed, 11 Jul 2018 22:26:07 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id q207-v6sm36033240pgq.11.2018.07.11.22.26.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 22:26:06 -0700 (PDT) To: "Liubing (Leo)" , Anima WG Cc: "draft-liu-anima-grasp-distribution@ietf.org" References: <153052861098.28235.15477231715646760940@ietfa.amsl.com> <8d3e90f7-8792-824a-32d2-cbafabc9f45c@gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C7A9D6A9@nkgeml514-mbx.china.huawei.com> From: Brian E Carpenter Message-ID: <18735321-2e66-45b9-ac40-c57102b74b49@gmail.com> Date: Thu, 12 Jul 2018 17:26:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C7A9D6A9@nkgeml514-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 05:26:15 -0000 Hi Bing, Responses in line: On 12/07/2018 15:58, Liubing (Leo) wrote: > Hi Brian, > > Thanks for your comments! Since this new version proposed some protocol extensions, we really need review from GRASP perspective. Please see reply inline. > >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Thursday, July 12, 2018 11:15 AM >> To: Anima WG >> Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-06.txt >> >> Hi, >> >> I haven't had time to carefully read sections 1-5, but I think their general >> message is fine. Here are some first comments on section 6, the proposed >> GRASP extensions: >> >>> In fragmentary CDDL, a Un-solicited Synchronization message follows >>> the pattern: >>> >>> unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, >>> objective] >>> >>> A node MAY actively send a unicast Un-solicited Synchronization >>> message with the Synchronization data, to another node. This MAY be >>> sent to port GRASP_LISTEN_PORT at the destination address, which >>> might be obtained by GRASP Discovery or other possible ways. The >>> synchronization data are in the form of GRASP Option(s) for specific >>> synchronization objective(s). >> >> Three comments on that: >> >> 1. For this to work, the receiving node must always be listening for a new TCP >> session on that port. So that means a new API function >> (listen_unsolicited?) and of course either a separate thread or an additional >> entry in the event loop. Not a problem, just an implementation comment. > > [Bing] I believe so, another API should be needed. > >> 2. We need to specify that a new session_id is generated for each new >> M_UNSOLDSYNCH message. > > [Bing] Yes, detailed behavior will be completed in the next version. > >> 3. Is this available for any synchronization objective, or do we need to add a new >> flag bit? > > [Bing] Ideally, I think the possibility should be open for any Synchronization Objective. But personally I prefer to avoid revising the base protocol as much as possible (e.g. changing the flag bits). How about we just assume any Sync Obj could be Un-solicited, would there be any harmfulness? I think it's fine. Effectively it just means this is a read-only objective, whether flooded, synchronized on request, or unsolicited. The NEG flag means it is read/write, by negotiation. >>> The selective flood option encapsulates a match-condition option >>> which represents the conditions regarding to continue or discontinue >>> flood the current message. >> >> To be clear, the match is evaluated in every node, and the flooded objective is >> dropped if there is a match? So we save on storage, not on processing. > > [Bing] Yes, it's even more flexible that we can define either "something matched" or "something not matched" to let the node drop the flooded messages. > Save on storage is surely one benefit, but I think maybe the more beneficial is saving on network traffic, especially in an constrained environment. And also on security benefit, that some sensitive informative won't be propagated too far. Yes, you can reduce relayed (forwarded) flooding, that's true. > >>> 6.5 Publishing Objective Option >>> >>> In fragmentary CDDL, a Publish Objective Option follows the pattern: >>> >>> publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name >>> = PUBLISH >>> objective-flags = 2 >>> loop-count = 2 >>> pubobj = text >>> >>> This option MAY be included in GRASP M_Synchronization, when >>> included, it means this message is for a publish of a specific object >>> data. >> >> Can it also be included in M_UNSOLDSYNCH ? (In other words, the pub/sub bus >> does not need to send M_REQ_SYN, but always listens for M_UNSOLDSYNCH.) > > [Bing] Currently, we follow the principle that Sub/Pub should be a more strict transaction model. Un-solicited Pub seems too arbitrary. > But we can leave it as an open question, let's see if we could find some scenarios that really benefited from un-solicited Pub. In any case this would be easy to add later, if found useful. > > Btw, we actually cared more about another question regarding to Sub/Pub. From semantic perspective, we actually preferred to make Sub/Pub as new messages, rather than current objective extension. But later we thought we should utilize the base protocol as much as possible, so we chose objective extension. May I ask your opinion on this? I think that's a good choice. In fact it gives you more flexibility at the ASA level, without changing the GRASP core. (In the same way, we could define the bulk transfer mechanism at the objective level, with literally zero changes needed in the protocol definition. I believe I could code a simple version of pub/sub tomorrow, without touching the basic GRASP code, except that I have to catch a plane.) Regards Brian > > Best regards, > Bing > >> >> >> Regards >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Jul 12 08:17:03 2018 Return-Path: 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 CA8A512D949 for ; Thu, 12 Jul 2018 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KlNVv1j1dcuY for ; Thu, 12 Jul 2018 08:16:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595A3130E52 for ; Thu, 12 Jul 2018 08:16:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 60A7F20090 for ; Thu, 12 Jul 2018 11:32:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7A4A71C5; Thu, 12 Jul 2018 11:12:29 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 77ED067 for ; Thu, 12 Jul 2018 11:12:29 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 15:17:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > involved. What a manufacturer wants to avoid is a pledge joining a > network where the MASA just does the logging and does no validation, > without any other means to determine that the device is on the > correct network. Otherwise, the pledge (we could call it the > "station" in this context) could simply home to the wrong network, > and even resetting the device won't get you to the right network. I don't understand how the "manufacturer" can have a desire ("the pledge avoid joining a network ...") that is different from the MASA's desire. The MASA *is* the expression manufacturer's desire. If the manufacturer has sales channel information that indicates the Pledge is on the wrong network, it should not issue a voucher. So the situation you describe makes no sense to me. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW0dv2oCLcPvd0N1lAQLt3Qf+JRnBdoM+3yVdFHhjGAjgrZwUdo7+WZ3F 0k7Aw1mGiyzTaAbvKxH6+HrXL7W4Lguje+d/BqXSFWX1i2A5l+ICQC4/QHO8qZ1I byAtjLyWKIvC7RZtjAkfYHfXkc/U26N2xXKFm4FkZv0V2L6OmUvlHF6EbjfkWAbc v/IaId8ccwG4jNamQAZZeKx+XyxgLdcZ/LuFZv6bXg5E8+V9c/TfXFQH2DTnzNu5 nwLE5b2nKl7rytSHAggbtZJChH0O8T6I273XF/y+8NFW2/huFywYJl3EcpYCaSZ9 TLsv8UazDJIdxWPYZrVMSPq8kGiHLufGH8rQ+mHfDsA5XuC9o+DvYA== =Hq0X -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 12 09:37:52 2018 Return-Path: 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 D76E1130EA3 for ; Thu, 12 Jul 2018 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 bXfe8UBFMHcf for ; Thu, 12 Jul 2018 09:37:48 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC0130E89 for ; Thu, 12 Jul 2018 09:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5248; q=dns/txt; s=iport; t=1531413468; x=1532623068; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=m2U4SjCFzNDWCRqTZZBRzjgmAetAKxBKOlJcYK51c/Q=; b=Irvo2zfRjCtUjAf3jj3ljmD3+3BUqgWyPjmG8xo+Di/BXA+BML48kxrc eg2/FXn10Ru80A7EugTAJ8l0LPMu+LZ9nuWFjBItv2vsK1R4ychNKV4kO dALxLUwWUTgagGj37jn7jyBHU1GNZB9pbMeghkKl/sm+ZOSltB/rSB2yD c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgCFg0db/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQsbRIog3qIY40zLJAlhwgIAxgBCoRJAoJqOBQBAgEBAgE?= =?us-ascii?q?BAm0cDEIQAYRkAQEBAwEBIUsbCwQUKgICJzAGAQwGAgEBgxwBgX8PqjOBLh+?= =?us-ascii?q?KEwoFixSBECeCPC6DGQEBhGGCVQKHQzORYwmDXYFZiWsGiBmFSJIUgVghgVI?= =?us-ascii?q?zGggbFTuCaYsVhUA9MIU3hEYrghsBAQ?= X-IronPort-AV: E=Sophos;i="5.51,344,1526342400"; d="asc'?scan'208,217";a="5132910" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2018 16:37:35 +0000 Received: from [10.61.194.177] ([10.61.194.177]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w6CGbYG3024833; Thu, 12 Jul 2018 16:37:34 GMT To: Michael Richardson , anima@ietf.org References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> Date: Thu, 12 Jul 2018 18:37:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4205.1531408349@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="78J0XFjAHaZ02dJMR6BLpWincvmwCDOpW" Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 16:37:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --78J0XFjAHaZ02dJMR6BLpWincvmwCDOpW Content-Type: multipart/mixed; boundary="gAIPoIpsSyxbXrkxulorlSJBSj3gwn8CA"; protected-headers="v1" From: Eliot Lear To: Michael Richardson , anima@ietf.org Message-ID: <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> In-Reply-To: <4205.1531408349@localhost> --gAIPoIpsSyxbXrkxulorlSJBSj3gwn8CA Content-Type: multipart/alternative; boundary="------------B3689896CE1A7F8FD87CC55A" Content-Language: en-US This is a multi-part message in MIME format. --------------B3689896CE1A7F8FD87CC55A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The problem is that the manufacturer doesn't have enough context to make decisions as to which network to join.=C2=A0 That is the challenge. On 12.07.18 17:12, Michael Richardson wrote: > Eliot Lear wrote: > > involved. What a manufacturer wants to avoid is a pledge joining = a > > network where the MASA just does the logging and does no validati= on, > > without any other means to determine that the device is on the > > correct network. Otherwise, the pledge (we could call it the > > "station" in this context) could simply home to the wrong network= , > > and even resetting the device won't get you to the right network.= > > I don't understand how the "manufacturer" can have a desire ("the pledg= e > avoid joining a network ...") that is different from the MASA's desire.= > > The MASA *is* the expression manufacturer's desire. > If the manufacturer has sales channel information that indicates the Pl= edge > is on the wrong network, it should not issue a voucher. > > So the situation you describe makes no sense to me. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --------------B3689896CE1A7F8FD87CC55A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

The problem is that the manufacturer doesn't have enough context to make decisions as to which network to join.=C2=A0 That is the challenge.


On 12.07.18 17:12, Michael Richardson wrote:
Eliot Lear <lear@cisco.com> wrote:
    > involved. What a manufacturer wants to avoid is a pledge joining=
 a
    > network where the MASA just does the logging and does no validat=
ion,
    > without any other means to determine that the device is on the
    > correct network. Otherwise, the pledge (we could call it the
    > "station" in this context) could simply home to the wrong networ=
k,
    > and even resetting the device won't get you to the right network=
=2E

I don't understand how the "manufacturer" can have a desire ("the pledge
avoid joining a network ...") that is different from the MASA's desire.

The MASA *is* the expression manufacturer's desire.
If the manufacturer has sales channel information that indicates the Pled=
ge
is on the wrong network, it should not issue a voucher.

So the situation you describe makes no sense to me.




_______________________________________________
Anima mailing list
Anim=
a@ietf.org
https://www.ietf.org/mailman/listinfo/anima

--------------B3689896CE1A7F8FD87CC55A-- --gAIPoIpsSyxbXrkxulorlSJBSj3gwn8CA-- --78J0XFjAHaZ02dJMR6BLpWincvmwCDOpW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltHg84ACgkQh7ZrRtnS ejPp0QgA0sp/TR3eWXKDzMDFje2+Gqr4I6wUXj5Ig8gTxdHoM1A0uzPLP6+8zN90 dA1zvDOqNmkduJNPZ7ry75uKaBjTdjezAPjt1nWOSkwxUgB0REj2sxNUfmGDh5Hb Im5XSTxGYUaQzRRmwKonPJaKcTuXq9YIfcxXw19nyJuM8XzuM61WG2LOv27RW/DA /6lYS1XrvQPo4N5vJlkTrm0GiTZRsVMR5tZz1+tCbHTbWjozoMaBSFaDQ0bRgPRt YTuVo5sKPwPz3wTv1n7faVo3/J84c/MVqq4MbVzAtj8jn2kWfMLfgdzxX0xGi/Nq zLUUnXrQOIVes5VBX6AUeaHc3sYLew== =Ksmx -----END PGP SIGNATURE----- --78J0XFjAHaZ02dJMR6BLpWincvmwCDOpW-- From nobody Fri Jul 13 02:26:43 2018 Return-Path: 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 7F319130ED1 for ; Fri, 13 Jul 2018 02:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cjhNyzlw67zQ for ; Fri, 13 Jul 2018 02:26:38 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2318130EBE for ; Fri, 13 Jul 2018 02:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13070; q=dns/txt; s=iport; t=1531473997; x=1532683597; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/ZsiQVqeJ4NwIQh9wpYnswaVJyt/2eHHyvR/dvrF5Is=; b=eo/2yzR0gf5gge2VWenhfZm/k5hbq0r8W7EcVzLXkJxPwcFmQoGz/n4r u1z0+UVRyxKw4dtmWh2cRiLaiEQg1wZlC/m9gPhwaVMy3rTWSvdXj/Oe3 jexLpf+RITvjrAi+4V/gwsW7LnJMXzb6fyK+klG4srfBS/n5nIF0sNJqv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAACGb0hb/4YNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTdmN/KAqDcYgEjDmCDJAnhQ6BegsYAQqESQIXgjYhNBg?= =?us-ascii?q?BAgEBAgEBAm0cDIU2AQEBAwEBASEKQRALAgEIEQQBASgDAgICJQsUCQgCBAE?= =?us-ascii?q?SCIMZgRtcCA+pNoEuH4oaBYkCgVc/gRGCYy6DGQEBgXcfgkuCVQKHQwcskWM?= =?us-ascii?q?JAo0JghSNaZFtAhETAYEkHTiBUnAVO4JpgiUXiFmFPm+JTiuBAYEaAQE?= X-IronPort-AV: E=Sophos;i="5.51,347,1526342400"; d="scan'208,217";a="142570679" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2018 09:26:37 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w6D9QbUe022152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2018 09:26:37 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 13 Jul 2018 04:26:31 -0500 Received: from xch-aln-012.cisco.com ([173.36.7.22]) by XCH-ALN-012.cisco.com ([173.36.7.22]) with mapi id 15.00.1320.000; Fri, 13 Jul 2018 04:26:31 -0500 From: "Owen Friel (ofriel)" To: Eliot Lear , Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Revision of scope of MASA in the BRSKI - Reg Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLgBWBpoAAHy30wAAAHlLAAB2W+CAAAL4tAAAGJiz8A== Date: Fri, 13 Jul 2018 09:26:31 +0000 Message-ID: <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> In-Reply-To: <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.8.24] Content-Type: multipart/alternative; boundary="_000_523b2a1dc6654463921771ebb045eda8XCHALN012ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2018 09:26:41 -0000 --_000_523b2a1dc6654463921771ebb045eda8XCHALN012ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpdHMgbW9yZSBhY2N1cmF0ZSB0byBzdGF0ZToNCg0K4oCcV2hhdCBhIENVU1RPTUVS IHdhbnRzIHRvIGF2b2lkIGlzIGEgcGxlZGdlIGpvaW5pbmcgYSBuZXR3b3JrIHdoZXJlIHRoZSBN QVNBIGp1c3QgZG9lcyB0aGUgbG9nZ2luZyBhbmQgZG9lcyBubyB2YWxpZGF0aW9uLCB3aXRob3V0 IGFueSBvdGhlciBtZWFucyB0byBkZXRlcm1pbmUgdGhhdCB0aGUgZGV2aWNlIGlzIG9uIHRoZSBj b3JyZWN0IG5ldHdvcmsu4oCdIEUuZy4gSSBwbHVnIGluIGEgd2ktZmkgZGV2aWNlIGFuZCBpdCBj b25uZWN0cyB0byB0aGUgU1NJRCBvZiB0aGUgY29tcGFueSBvbiB0aGUgZmxvb3IgYmVsb3cgbWUu DQoNClRoZSBNQVNBIGNhbm5vdCBoZWxwIHdpdGggdGhpcyB1bmxlc3MgdGhlcmUgaXMgY29tcGxl eCBzYWxlcyBjaGFubmVsIGludGVncmF0aW9uIGFuZCB0aGUgTUFTQSBleHBsaWNpdGx5IGtub3dz IGluIGFkdmFuY2UgZXhhY3RseSB3aGF0IG5ldHdvcmsgZWFjaCBwbGVkZ2Ugd2lsbCBiZSBjb25u ZWN0aW5nIHRvLiBBIHBvdGVudGlhbCBvcHRpb24gaXMgdG8gYWxzbyByZXF1aXJlIHRoZSByZWdp c3RyYXIgdG8gcHJvdmlkZSBzb21lIHByb29mIG9mIG93bmVyc2hpcCB0byB0aGUgTUFTQSBpbiB0 aGUgVm91Y2hlclJlcXVlc3QuDQoNCkZyb206IEFuaW1hIDxhbmltYS1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgRWxpb3QgTGVhcg0KU2VudDogVGh1cnNkYXkgMTIgSnVseSAyMDE4IDE3 OjM4DQpUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBhbmlt YUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtBbmltYV0gUmV2aXNpb24gb2Ygc2NvcGUgb2YgTUFT QSBpbiB0aGUgQlJTS0kgLSBSZWcNCg0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBtYW51ZmFj dHVyZXIgZG9lc24ndCBoYXZlIGVub3VnaCBjb250ZXh0IHRvIG1ha2UgZGVjaXNpb25zIGFzIHRv IHdoaWNoIG5ldHdvcmsgdG8gam9pbi4gIFRoYXQgaXMgdGhlIGNoYWxsZW5nZS4NCg0KT24gMTIu MDcuMTggMTc6MTIsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCg0KDQoNCkVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tPjxtYWlsdG86bGVhckBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgPiBp bnZvbHZlZC4gV2hhdCBhIG1hbnVmYWN0dXJlciB3YW50cyB0byBhdm9pZCBpcyBhIHBsZWRnZSBq b2luaW5nIGENCg0KICAgID4gbmV0d29yayB3aGVyZSB0aGUgTUFTQSBqdXN0IGRvZXMgdGhlIGxv Z2dpbmcgYW5kIGRvZXMgbm8gdmFsaWRhdGlvbiwNCg0KICAgID4gd2l0aG91dCBhbnkgb3RoZXIg bWVhbnMgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlIGRldmljZSBpcyBvbiB0aGUNCg0KICAgID4gY29y cmVjdCBuZXR3b3JrLiBPdGhlcndpc2UsIHRoZSBwbGVkZ2UgKHdlIGNvdWxkIGNhbGwgaXQgdGhl DQoNCiAgICA+ICJzdGF0aW9uIiBpbiB0aGlzIGNvbnRleHQpIGNvdWxkIHNpbXBseSBob21lIHRv IHRoZSB3cm9uZyBuZXR3b3JrLA0KDQogICAgPiBhbmQgZXZlbiByZXNldHRpbmcgdGhlIGRldmlj ZSB3b24ndCBnZXQgeW91IHRvIHRoZSByaWdodCBuZXR3b3JrLg0KDQoNCg0KSSBkb24ndCB1bmRl cnN0YW5kIGhvdyB0aGUgIm1hbnVmYWN0dXJlciIgY2FuIGhhdmUgYSBkZXNpcmUgKCJ0aGUgcGxl ZGdlDQoNCmF2b2lkIGpvaW5pbmcgYSBuZXR3b3JrIC4uLiIpIHRoYXQgaXMgZGlmZmVyZW50IGZy b20gdGhlIE1BU0EncyBkZXNpcmUuDQoNCg0KDQpUaGUgTUFTQSAqaXMqIHRoZSBleHByZXNzaW9u IG1hbnVmYWN0dXJlcidzIGRlc2lyZS4NCg0KSWYgdGhlIG1hbnVmYWN0dXJlciBoYXMgc2FsZXMg Y2hhbm5lbCBpbmZvcm1hdGlvbiB0aGF0IGluZGljYXRlcyB0aGUgUGxlZGdlDQoNCmlzIG9uIHRo ZSB3cm9uZyBuZXR3b3JrLCBpdCBzaG91bGQgbm90IGlzc3VlIGEgdm91Y2hlci4NCg0KDQoNClNv IHRoZSBzaXR1YXRpb24geW91IGRlc2NyaWJlIG1ha2VzIG5vIHNlbnNlIHRvIG1lLg0KDQoNCg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K QW5pbWEgbWFpbGluZyBsaXN0DQoNCkFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9y Zz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KDQo= --_000_523b2a1dc6654463921771ebb045eda8XCHALN012ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFs MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6Ymxh Y2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1J RSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgaXRzIG1vcmUgYWNjdXJhdGUgdG8g c3RhdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJxX aGF0IGEgQ1VTVE9NRVIgd2FudHMgdG8gYXZvaWQgaXMgYSBwbGVkZ2Ugam9pbmluZyBhIG5ldHdv cmsgd2hlcmUgdGhlIE1BU0EganVzdCBkb2VzIHRoZSBsb2dnaW5nIGFuZCBkb2VzIG5vIHZhbGlk YXRpb24sIHdpdGhvdXQNCiBhbnkgb3RoZXIgbWVhbnMgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlIGRl dmljZSBpcyBvbiB0aGUgY29ycmVjdCBuZXR3b3JrLuKAnSBFLmcuIEkgcGx1ZyBpbiBhIHdpLWZp IGRldmljZSBhbmQgaXQgY29ubmVjdHMgdG8gdGhlIFNTSUQgb2YgdGhlIGNvbXBhbnkgb24gdGhl IGZsb29yIGJlbG93IG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGhlIE1BU0EgY2Fubm90IGhlbHAgd2l0aCB0aGlzIHVubGVzcyB0aGVyZSBpcyBjb21w bGV4IHNhbGVzIGNoYW5uZWwgaW50ZWdyYXRpb24gYW5kIHRoZSBNQVNBIGV4cGxpY2l0bHkga25v d3MgaW4gYWR2YW5jZSBleGFjdGx5DQogd2hhdCBuZXR3b3JrIGVhY2ggcGxlZGdlIHdpbGwgYmUg Y29ubmVjdGluZyB0by4gQSBwb3RlbnRpYWwgb3B0aW9uIGlzIHRvIGFsc28gcmVxdWlyZSB0aGUg cmVnaXN0cmFyIHRvIHByb3ZpZGUgc29tZSBwcm9vZiBvZiBvd25lcnNoaXAgdG8gdGhlIE1BU0Eg aW4gdGhlIFZvdWNoZXJSZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQW5pbWEgJmx0O2FuaW1h LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVsaW90IExlYXI8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXkgMTIgSnVseSAyMDE4IDE3OjM4PGJyPg0KPGI+VG86PC9i PiBNaWNoYWVsIFJpY2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7OyBh bmltYUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FuaW1hXSBSZXZpc2lvbiBv ZiBzY29wZSBvZiBNQVNBIGluIHRoZSBCUlNLSSAtIFJlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwPlRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIG1hbnVmYWN0dXJlciBkb2Vzbid0IGhhdmUg ZW5vdWdoIGNvbnRleHQgdG8gbWFrZSBkZWNpc2lvbnMgYXMgdG8gd2hpY2ggbmV0d29yayB0byBq b2luLiZuYnNwOyBUaGF0IGlzIHRoZSBjaGFsbGVuZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAxMi4wNy4xOCAxNzoxMiwgTWljaGFlbCBSaWNoYXJkc29uIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ RWxpb3QgTGVhciA8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20iPiZsdDtsZWFyQGNpc2Nv LmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IGludm9sdmVkLiBXaGF0IGEgbWFudWZhY3R1cmVyIHdhbnRzIHRvIGF2b2lkIGlz IGEgcGxlZGdlIGpvaW5pbmcgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IG5ldHdvcmsgd2hlcmUgdGhlIE1BU0EganVzdCBkb2VzIHRoZSBsb2dnaW5nIGFu ZCBkb2VzIG5vIHZhbGlkYXRpb24sPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgd2l0aG91dCBhbnkgb3RoZXIgbWVhbnMgdG8gZGV0ZXJtaW5lIHRoYXQgdGhl IGRldmljZSBpcyBvbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBjb3JyZWN0IG5ldHdvcmsuIE90aGVyd2lzZSwgdGhlIHBsZWRnZSAod2UgY291bGQg Y2FsbCBpdCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyAmcXVvdDtzdGF0aW9uJnF1b3Q7IGluIHRoaXMgY29udGV4dCkgY291bGQgc2ltcGx5IGhvbWUg dG8gdGhlIHdyb25nIG5ldHdvcmssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgYW5kIGV2ZW4gcmVzZXR0aW5nIHRoZSBkZXZpY2Ugd29uJ3QgZ2V0IHlvdSB0 byB0aGUgcmlnaHQgbmV0d29yay48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT5JIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSAmcXVvdDttYW51ZmFj dHVyZXImcXVvdDsgY2FuIGhhdmUgYSBkZXNpcmUgKCZxdW90O3RoZSBwbGVkZ2U8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5hdm9pZCBqb2luaW5nIGEgbmV0d29yayAuLi4mcXVvdDspIHRoYXQgaXMg ZGlmZmVyZW50IGZyb20gdGhlIE1BU0EncyBkZXNpcmUuPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIE1BU0EgKmlzKiB0aGUgZXhwcmVzc2lv biBtYW51ZmFjdHVyZXIncyBkZXNpcmUuPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgdGhlIG1h bnVmYWN0dXJlciBoYXMgc2FsZXMgY2hhbm5lbCBpbmZvcm1hdGlvbiB0aGF0IGluZGljYXRlcyB0 aGUgUGxlZGdlPG86cD48L286cD48L3ByZT4NCjxwcmU+aXMgb24gdGhlIHdyb25nIG5ldHdvcmss IGl0IHNob3VsZCBub3QgaXNzdWUgYSB2b3VjaGVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNvIHRoZSBzaXR1YXRpb24geW91IGRlc2NyaWJl IG1ha2VzIG5vIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BbmltYSBtYWlsaW5nIGxpc3Q8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciPkFuaW1hQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYW5pbWE8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_523b2a1dc6654463921771ebb045eda8XCHALN012ciscocom_-- From nobody Fri Jul 13 17:08:47 2018 Return-Path: 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 6BF0612872C for ; Fri, 13 Jul 2018 17:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8dvuUZyM5B-Y for ; Fri, 13 Jul 2018 17:08:42 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8E11274D0 for ; Fri, 13 Jul 2018 17:08:42 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id u16-v6so23452916pfh.3 for ; Fri, 13 Jul 2018 17:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=NXIGYp4cisL2zZDMkDHBMM7E0sQizLUTlOwmzOIbVR0=; b=b0Itfxx5Z6FvE6M88+8EhtT3U/nNoTT2IJbrl8WVhtzvhLGnZPksgpXXceruT9SvuZ uflY2XU+ObtL5t5MSuZNwRi8umJ4AIY5sN7c3g358ypi1PRyBIoVtgLfP4QRF87OtlIl MVbRQ76sUJZ4BVAtb7CHfQ/gEdrZ++6BFpPb28sLhodo+qi0BrCfYsES6IVi/anOomVO nEPjm3HIRtU4t7HOGWa8bX4Uk9pbJ8+jOV5q3czyTPSpJsfgvaprReik1sRHjIbrd9SG exAqdd3gPLnFcznlPX3wv7O5XaY5mlQCN/ZEhijWLQ9u9p8C16sV2eAGqIzzLKOPqKam YndA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NXIGYp4cisL2zZDMkDHBMM7E0sQizLUTlOwmzOIbVR0=; b=h3Jx79irJu/vZOY2XpbXni5AxKniMoAP/H4xceOT2QzfHjnyQ16KclotrpqGdIN/8Z BfOyNNNZimkQ+xtJiY4yYj/0Q0lFkRJ34MbxchFxrPkVBDNw427o+ILVcXPB3ikflyr3 GVABL/wESarB2S08nTx2GV2aybCGpzl6Or2DOX9iXh0Z8fY2KImfMpyb7re0aOZLS7tv w+bsfSEx4pXBdGArZfoAiYYgIcobgowx80XvXa/Jk8b/4a1i9LbPsLtPF/ZjLCBsCPOI SJAca19KOSO+G1H184jNXZCCg1k9LOfNYfXRatXE4Yy9Nv19/AVQarf3UVuinwMRyLYh CHYA== X-Gm-Message-State: AOUpUlG9H9wbTEQjCtfgOVJwj8QfIAdgGIT7ZH8CyRuv/WIVyrCfW1bD G49QYirYrenThR5CZhxvU0OPuA== X-Google-Smtp-Source: AAOMgpegwZ8F3qVCbGEMXaE4DBT4QOGWkUz8frZMsCHyfqa0uxxGRL6MWHdWwjV9Cxf8kLxm9jf7MQ== X-Received: by 2002:a62:42d7:: with SMTP id h84-v6mr9116698pfd.146.1531526921921; Fri, 13 Jul 2018 17:08:41 -0700 (PDT) Received: from [172.16.26.203] ([206.108.25.53]) by smtp.gmail.com with ESMTPSA id t1-v6sm18032630pgp.32.2018.07.13.17.08.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 17:08:41 -0700 (PDT) To: "Owen Friel (ofriel)" , Eliot Lear , Michael Richardson , "anima@ietf.org" References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> From: Brian E Carpenter Message-ID: Date: Sat, 14 Jul 2018 11:34:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 00:08:45 -0000 On 13/07/2018 21:26, Owen Friel (ofriel) wrote: > I think its more accurate to state: >=20 > =E2=80=9CWhat a CUSTOMER wants to avoid is a pledge joining a network w= here the MASA just does the logging and does no validation, without any o= ther means to determine that the device is on the correct network.=E2=80=9D= E.g. I plug in a wi-fi device and it connects to the SSID of the company= on the floor below me. That is so far outside the scope of the autonomic networking infrastructu= re application of BRSKI that I don't see why we'd even mention it. It's a ca= se that definitely needs to fail hard in the autonomic context. If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi, I= think that's for some other WG. Brian > The MASA cannot help with this unless there is complex sales channel in= tegration and the MASA explicitly knows in advance exactly what network e= ach pledge will be connecting to. A potential option is to also require t= he registrar to provide some proof of ownership to the MASA in the Vouche= rRequest. >=20 > From: Anima On Behalf Of Eliot Lear > Sent: Thursday 12 July 2018 17:38 > To: Michael Richardson ; anima@ietf.org > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg >=20 >=20 > The problem is that the manufacturer doesn't have enough context to mak= e decisions as to which network to join. That is the challenge. >=20 > On 12.07.18 17:12, Michael Richardson wrote: >=20 >=20 >=20 > Eliot Lear wrote: >=20 > > involved. What a manufacturer wants to avoid is a pledge joining = a >=20 > > network where the MASA just does the logging and does no validati= on, >=20 > > without any other means to determine that the device is on the >=20 > > correct network. Otherwise, the pledge (we could call it the >=20 > > "station" in this context) could simply home to the wrong network= , >=20 > > and even resetting the device won't get you to the right network.= >=20 >=20 >=20 > I don't understand how the "manufacturer" can have a desire ("the pledg= e >=20 > avoid joining a network ...") that is different from the MASA's desire.= >=20 >=20 >=20 > The MASA *is* the expression manufacturer's desire. >=20 > If the manufacturer has sales channel information that indicates the Pl= edge >=20 > is on the wrong network, it should not issue a voucher. >=20 >=20 >=20 > So the situation you describe makes no sense to me. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > Anima mailing list >=20 > Anima@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/anima >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Sat Jul 14 07:47:16 2018 Return-Path: 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 371E813108E for ; Sat, 14 Jul 2018 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 TG9WydB5ckgi for ; Sat, 14 Jul 2018 07:47:08 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2219130FFE for ; Sat, 14 Jul 2018 07:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5231; q=dns/txt; s=iport; t=1531579628; x=1532789228; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=r5LmQVEHc9Z5dPCY4AJZfC5r4l67l/gsyu4fZeN2flY=; b=g/alftu8Hqn7Hf8FjawkDpIJt/Pd+Ea0Kbuy4V8QtMegiutmm18ipcLv AfU5RSIZ5Y51849V8HTJ262TsckQVZEBEH/4y3n2lneKUWwqzstTRyqIS YbnwJ0ExA4ZqdyhKzx3l3+V0ks5DH15s3hoWOHjNRoAVwSVLQbKnN4PQB g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAgDmC0pb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYQsbRIog3uIY407CCSXMwgDGAuESQKCcDgUAQIBAQIBAQJ?= =?us-ascii?q?tHAyFNgEBAQEDAQEhSxsLEQQBAQEnAwICJx8JCAYBDAYCAQGDHAGBfw+oZoE?= =?us-ascii?q?uijUKBYsYgREnDIIwLoMZAQGEYYJVAodEByyRZQmDXYFZh1WCFgaIHIVJkhS?= =?us-ascii?q?BWCGBUjMaCBsVO4JpgiUXiFmFQD0wii0rghsBAQ?= X-IronPort-AV: E=Sophos; i="5.51,352,1526342400"; d="asc'?scan'208"; a="5177180" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2018 14:47:05 +0000 Received: from [10.61.213.1] ([10.61.213.1]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w6EEl53R024394; Sat, 14 Jul 2018 14:47:05 GMT To: Brian E Carpenter , "Owen Friel (ofriel)" , Eliot Lear , Michael Richardson , "anima@ietf.org" References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <43bea659-f221-0331-1272-0714279705de@cisco.com> Date: Sat, 14 Jul 2018 16:47:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XrY0VnMctHMfWYURKcMdCOQcukq7F7Rms" Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 14:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XrY0VnMctHMfWYURKcMdCOQcukq7F7Rms Content-Type: multipart/mixed; boundary="BOAhtMAXaSTkVpWC3KHfPgtrn5Dg7eLog"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , "Owen Friel (ofriel)" , Eliot Lear , Michael Richardson , "anima@ietf.org" Message-ID: <43bea659-f221-0331-1272-0714279705de@cisco.com> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> In-Reply-To: --BOAhtMAXaSTkVpWC3KHfPgtrn5Dg7eLog Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Brian, is it your contention that 802.11 is beyond the scope of autonomic computing? On 14.07.18 01:34, Brian E Carpenter wrote: > On 13/07/2018 21:26, Owen Friel (ofriel) wrote: >> I think its more accurate to state: >> >> =E2=80=9CWhat a CUSTOMER wants to avoid is a pledge joining a network = where the MASA just does the logging and does no validation, without any = other means to determine that the device is on the correct network.=E2=80= =9D E.g. I plug in a wi-fi device and it connects to the SSID of the comp= any on the floor below me. > That is so far outside the scope of the autonomic networking infrastruc= ture > application of BRSKI that I don't see why we'd even mention it. It's a = case > that definitely needs to fail hard in the autonomic context. > > If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi,= I > think that's for some other WG. > > Brian > >> The MASA cannot help with this unless there is complex sales channel i= ntegration and the MASA explicitly knows in advance exactly what network = each pledge will be connecting to. A potential option is to also require = the registrar to provide some proof of ownership to the MASA in the Vouch= erRequest. >> >> From: Anima On Behalf Of Eliot Lear >> Sent: Thursday 12 July 2018 17:38 >> To: Michael Richardson ; anima@ietf.org >> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg >> >> >> The problem is that the manufacturer doesn't have enough context to ma= ke decisions as to which network to join. That is the challenge. >> >> On 12.07.18 17:12, Michael Richardson wrote: >> >> >> >> Eliot Lear wrote: >> >> > involved. What a manufacturer wants to avoid is a pledge joining= a >> >> > network where the MASA just does the logging and does no validat= ion, >> >> > without any other means to determine that the device is on the >> >> > correct network. Otherwise, the pledge (we could call it the >> >> > "station" in this context) could simply home to the wrong networ= k, >> >> > and even resetting the device won't get you to the right network= =2E >> >> >> >> I don't understand how the "manufacturer" can have a desire ("the pled= ge >> >> avoid joining a network ...") that is different from the MASA's desire= =2E >> >> >> >> The MASA *is* the expression manufacturer's desire. >> >> If the manufacturer has sales channel information that indicates the P= ledge >> >> is on the wrong network, it should not issue a voucher. >> >> >> >> So the situation you describe makes no sense to me. >> >> >> >> >> >> >> _______________________________________________ >> >> Anima mailing list >> >> Anima@ietf.org >> >> https://www.ietf.org/mailman/listinfo/anima >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima --BOAhtMAXaSTkVpWC3KHfPgtrn5Dg7eLog-- --XrY0VnMctHMfWYURKcMdCOQcukq7F7Rms Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltKDOgACgkQh7ZrRtnS ejPpzAf+P/JpF48NwUHLkU58kUSFlxDS6HdZwh8CY6Ksw0xN52J/SdCghqz9VPuG xfx0a6zl1a6hyTGK4aHimXMOstdQkKgWlfb3C+4gWezQXrYxu20tdFRrhbZEAOTT UoSiVDAQ+IfqesjPuX5AioHsOIK2KPA+zUvtonafYtGShtKktv/BmUOmAhGulmmm TTFjpOt8NisAv3x6C4Ztjqra0FlF5XwlVu7FKe1D9h7fmbPb+XE+/8+KBkH6q2J2 aXxLlvDDFMEgBDzXs5Pm3z3AnFfCEQ0liGNIsk6rY0kwOCPPb79OmLr0xUccukeY fUxxSKlSV1th/YHGuB+i+HyuGlz7Gg== =GHCq -----END PGP SIGNATURE----- --XrY0VnMctHMfWYURKcMdCOQcukq7F7Rms-- From nobody Sat Jul 14 08:20:32 2018 Return-Path: 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 2D1C31310A6 for ; Sat, 14 Jul 2018 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rLT8IBuDWePI for ; Sat, 14 Jul 2018 08:20:24 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75E71310A1 for ; Sat, 14 Jul 2018 08:20:23 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id y124-v6so7452854itc.0 for ; Sat, 14 Jul 2018 08:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=GM+HDDOJGLX8AyTaAoJedSUNoXgq+3t9IhJ1qzwsegg=; b=UaARO/70Pf5PH9e9hY9tc9wcvzeFw0MzzMqzWx7GhrH/XIwCGVvJAI4KjRwWirJbE8 V6TQDqPMm+9057qCRI7WzK12DfoEprDbkWa14GTIrRgU/uHt5J4t9bZNG2I7UFA4qiab 6znsf/r/7mcwAIuOwSd7CZORKHRCjAuCw1z89JYF/eER2k/FTlMHWZG09ePco3MM++fp R0IhLIkgNF+aNTBID7TVPcKz9ezHITPwdIq1vVeQKSSlzQB8J66v/y++PO2r9Qq4SLmy uvEv9NcNYJCi/hTWptEQn0t/nmUAr7x/iK3sivjbCyLAB6YtqJww7OEKTtIdkHE9WxAz t63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GM+HDDOJGLX8AyTaAoJedSUNoXgq+3t9IhJ1qzwsegg=; b=l3nuEIY5gt7vsm/N6pBtlhjt+s0nHxV/ej8uIW8nNB9jukWDH4BOuQw/YiItM+RXUz LCpjPzhfI8lJpIbZUeBUqgGyuUz/A6Ct2lQS0E03wkqlCgZCC3lGgApMByq6iEue/bYs ahCuo4XeSMXGGOKIvv9aoiRHoe/yoO2AtA6wVuKemQrmJS2VxiqrSUYpdxIrk6hHVXUS SL5bhCI6qEumva+1ZA/6qkXZvqZCvpNPUGJpZExPKnJY8sE4nS/SJloI2jdzQmnQRTjd t6TC0379vKhmEjMVylcBmXYVqg39BQmnfjpYblRDeQ6xnx+bqTQFjIUFVFvBeAWFwKKz S8fg== X-Gm-Message-State: AOUpUlHVX67eay07tXfYF0/YEsr6IPLTmQxcPgiJEuxu0Z5lYmQb8Pgm mqFDOL6sBpMP/4YGXQNinWMIPQ== X-Google-Smtp-Source: AAOMgpf4wJTj69w6yYm3cOhZhflPCXnqjMZlidkj0JA6GHK6rIkPE1koysbI2eIyzKKDEfmWANQqXQ== X-Received: by 2002:a02:1294:: with SMTP id 20-v6mr9168475jap.141.1531581622923; Sat, 14 Jul 2018 08:20:22 -0700 (PDT) Received: from [10.255.239.101] ([207.164.22.51]) by smtp.gmail.com with ESMTPSA id p202-v6sm5095036itc.43.2018.07.14.08.20.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 08:20:22 -0700 (PDT) To: Eliot Lear , "Owen Friel (ofriel)" , Eliot Lear , Michael Richardson , "anima@ietf.org" References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> From: Brian E Carpenter Message-ID: Date: Sun, 15 Jul 2018 03:20:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <43bea659-f221-0331-1272-0714279705de@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2018 15:20:27 -0000 On 15/07/2018 02:47, Eliot Lear wrote: > Brian, is it your contention that 802.11 is beyond the scope of > autonomic computing? No, of course not. But autonomic nodes aren't supposed to connect to any old WiFi they happen to find; that's exactly the case where secure bootstrap needs to fail. If they connect to a network on which there's a registrar that knows nothing about them, it won't authorize them to join the ACP. "The domain registrar authenticates the pledge, makes authorization decisions,..." In Figure 3, I guess authorization is the tiny item "[accept device?]". BRSKI is defined in a nicely general way, but in an AN it's the domain registrar's job to decide who's allowed in. Actually there seems to be a glitch in the text on this. We find: > 5.2. Pledge Requests Voucher from the Registrar > ... > ...The registrar performs authorization as > detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge > Authorization"]].=20 but that leads nowhere that I can find. BRSKI authors, please comment. Brian >=20 >=20 > On 14.07.18 01:34, Brian E Carpenter wrote: >> On 13/07/2018 21:26, Owen Friel (ofriel) wrote: >>> I think its more accurate to state: >>> >>> =E2=80=9CWhat a CUSTOMER wants to avoid is a pledge joining a network= where the MASA just does the logging and does no validation, without any= other means to determine that the device is on the correct network.=E2=80= =9D E.g. I plug in a wi-fi device and it connects to the SSID of the comp= any on the floor below me. >> That is so far outside the scope of the autonomic networking infrastru= cture >> application of BRSKI that I don't see why we'd even mention it. It's a= case >> that definitely needs to fail hard in the autonomic context. >> >> If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi= , I >> think that's for some other WG. >> >> Brian >> >>> The MASA cannot help with this unless there is complex sales channel = integration and the MASA explicitly knows in advance exactly what network= each pledge will be connecting to. A potential option is to also require= the registrar to provide some proof of ownership to the MASA in the Vouc= herRequest. >>> >>> From: Anima On Behalf Of Eliot Lear >>> Sent: Thursday 12 July 2018 17:38 >>> To: Michael Richardson ; anima@ietf.org >>> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg >>> >>> >>> The problem is that the manufacturer doesn't have enough context to m= ake decisions as to which network to join. That is the challenge. >>> >>> On 12.07.18 17:12, Michael Richardson wrote: >>> >>> >>> >>> Eliot Lear wrote: >>> >>> > involved. What a manufacturer wants to avoid is a pledge joinin= g a >>> >>> > network where the MASA just does the logging and does no valida= tion, >>> >>> > without any other means to determine that the device is on the >>> >>> > correct network. Otherwise, the pledge (we could call it the >>> >>> > "station" in this context) could simply home to the wrong netwo= rk, >>> >>> > and even resetting the device won't get you to the right networ= k. >>> >>> >>> >>> I don't understand how the "manufacturer" can have a desire ("the ple= dge >>> >>> avoid joining a network ...") that is different from the MASA's desir= e. >>> >>> >>> >>> The MASA *is* the expression manufacturer's desire. >>> >>> If the manufacturer has sales channel information that indicates the = Pledge >>> >>> is on the wrong network, it should not issue a voucher. >>> >>> >>> >>> So the situation you describe makes no sense to me. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Anima mailing list >>> >>> Anima@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/anima >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 >=20 From nobody Sat Jul 14 17:21:35 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 251EE131102 for ; Sat, 14 Jul 2018 17:21:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153161409414.12797.7829323495492368313.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2018 17:21:34 -0700 From: IETF Secretariat Archived-At: Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 00:21:34 -0000 Changed milestone "Submit the two validation drafts to IESG (Informational)", resolved as "Done", added draft-ietf-anima-stable-connectivity, draft-ietf-anima-prefix-management to milestone. Changed milestone "Submit autonomic control plane solution to IESG (Standards Track)", resolved as "Done", added draft-ietf-anima-autonomic-control-plane to milestone. Changed milestone "Submit reference model to IESG (Informational)", resolved as "Done", added draft-ietf-anima-reference-model to milestone. URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Sat Jul 14 17:24:00 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13595131102 for ; Sat, 14 Jul 2018 17:23:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153161423907.12797.7715519844699648791.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2018 17:23:59 -0700 From: IETF Secretariat Archived-At: Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 00:23:59 -0000 Changed milestone "Submit bootstrap a trust infrastructure solution to IESG (Standards Track)", set due date to July 2018 from April 2016, added draft-ietf-anima-bootstrapping-keyinfra, draft-ietf-anima-voucher to milestone. Changed milestone "recharter to refocus scope, or close", set due date to November 2018 from December 2016. URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Sat Jul 14 17:26:20 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60535131103 for ; Sat, 14 Jul 2018 17:26:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153161437939.12867.12311173287010574083.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2018 17:26:19 -0700 From: IETF Secretariat Archived-At: Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 00:26:19 -0000 Changed milestone "Adoption of initial drafts on AN components: Discovery and negotiation protocol(s), Bootstrap a trust infrastructure solution, Autonomic control plane solution", added draft-ietf-anima-bootstrapping-keyinfra, draft-ietf-anima-grasp, draft-ietf-anima-autonomic-control-plane to milestone. URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Sat Jul 14 17:28:48 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F39C9131103 for ; Sat, 14 Jul 2018 17:28:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153161452699.12757.10492878160585032365.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2018 17:28:46 -0700 From: IETF Secretariat Archived-At: Subject: [Anima] Milestones changed for anima WG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 00:28:47 -0000 Changed milestone "Adoption of reference model", added draft-ietf-anima-reference-model to milestone. Changed milestone "Adoption of the two validation drafts", added draft-ietf-anima-stable-connectivity, draft-ietf-anima-prefix-management to milestone. Changed milestone "Submit discovery and negotiation protocol(s) to IESG (Standards Track)", added draft-ietf-anima-grasp to milestone. URL: https://datatracker.ietf.org/wg/anima/about/ From nobody Sun Jul 15 00:19:39 2018 Return-Path: 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 87D4E130E9E for ; Sun, 15 Jul 2018 00:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] 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 7gLcN6qh2YFB for ; Sun, 15 Jul 2018 00:19:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BE3130E82 for ; Sun, 15 Jul 2018 00:19:33 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5186F58C4AF; Sun, 15 Jul 2018 09:19:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3E9AB4402CB; Sun, 15 Jul 2018 09:19:28 +0200 (CEST) Date: Sun, 15 Jul 2018 09:19:28 +0200 From: Toerless Eckert To: "Owen Friel (ofriel)" Cc: Eliot Lear , Michael Richardson , "anima@ietf.org" Message-ID: <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 07:19:38 -0000 Owen, I've associated draft-friel-brski-over-802dot11 to anima so folks will see it in data tracker. Next time post new work for a particular WG with draft---, that will make it happen automatically. 2.1.1.1) There is no need to bother the MASA with sales integration just so that the owner will know whether or not it owns a particular device. Any protocol from the manufacturer/reseller to the owner will suffice. I recommend carrier pidgeons with USB sticks trained to insert them into a USB slot releasing a food portion. Great protection against against unrecognize NSA interception of the channel especially for vendors products on the NSA shortlist ;-)) Kidding aside: A standard protocol for sales information disemination would be great, and given how its for bootstrap automation it would be fine for ANIMA. I would jus resist of mixing it with BRSKI/MASA unless there is clear evidence of not keeping it modular. Especially given how it cold come from the reseller, and nothe vendor. 2.1.1.2) This read a bit confused. I think it should mention two methods: One is the aove mentioned to know what you own - independent of MASA (yor last sentence in 2.1.1.2 confused this option with the MASA). The other option is just to try the MASA in the absence of better information. BUT: If you only try the MASA, you should only do this automatically if you do know the MASA has sales integation. Otherwise you better include a manual checkpoint before enrollment. 2.1.2) This section is a bit unmotivated even though its part of the best solution, but that solution requires more details than just WiFi. Aka: You want to allow announcement (using any of the options you specified) of open access SSID that allow to connect to cloud-registrars. These do not even have to be free internet access. Ideally we would think about an unencrypted channel to the cloud registrar that relies only on authenticated but unencrypted messages. That way the owner of the AP can veryify and constrict communications to only cloud-registrar-enrollment so that this access is not as a side-channel to gain full internet access. TLS 1.2 still allows zero-encryption, that would be the easiest option. TLS 1.3 removed it *sigh*. Note also that we have not defined cloud-registrar behavior. I think Eliot wold jus like to add something like WiFi SSID to vouchers, but i would rather like to see it as a separate "next-step after enrolment" message Cheers Toerless From nobody Sun Jul 15 00:38:55 2018 Return-Path: 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 28647130F62 for ; Sun, 15 Jul 2018 00:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3WsPdpbe7S6e for ; Sun, 15 Jul 2018 00:38:51 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8272130F5C for ; Sun, 15 Jul 2018 00:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5902; q=dns/txt; s=iport; t=1531640331; x=1532849931; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=iOHpKi+7I4fanGpDzTYxxA2QJOAZQngfazS4iLogdmI=; b=W3+7IH7d8c1DmsiMM6W1KqQijKX9y+mpE6ql5HgUoPfD5Tzxb6rjXvWG JxeX2ph8cYDY4NNORbR0LatQi9r+L89rOWV00lUDNOcxEA1htL2Cb7IG0 inB7jdP1JJu9OGtXMVN7A0hXm4+kFIVeR3gkkDzvt1eHdpkhaUbrFZAI0 c=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.51,355,1526342400"; d="asc'?scan'208,217";a="5126741" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 07:38:49 +0000 Received: from [10.61.100.188] (dhcp-10-61-100-188.cisco.com [10.61.100.188]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id w6F7cmiV008301; Sun, 15 Jul 2018 07:38:48 GMT To: Toerless Eckert , "Owen Friel (ofriel)" Cc: Michael Richardson , "anima@ietf.org" References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <388b5570-320f-99e2-71af-6eb298f7d7cf@cisco.com> Date: Sun, 15 Jul 2018 09:38:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MpM3UjObOfLzLXon6bhm6pzMbSmrMK0t0" Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 07:38:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MpM3UjObOfLzLXon6bhm6pzMbSmrMK0t0 Content-Type: multipart/mixed; boundary="GtAG3EqachCvj37yQQPJ4WRYYKwxxo9bU"; protected-headers="v1" From: Eliot Lear To: Toerless Eckert , "Owen Friel (ofriel)" Cc: Michael Richardson , "anima@ietf.org" Message-ID: <388b5570-320f-99e2-71af-6eb298f7d7cf@cisco.com> Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> --GtAG3EqachCvj37yQQPJ4WRYYKwxxo9bU Content-Type: multipart/alternative; boundary="------------80C46C22E9AFF32A47332EE7" Content-Language: en-US This is a multi-part message in MIME format. --------------80C46C22E9AFF32A47332EE7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Toerless, On 15.07.18 09:19, Toerless Eckert wrote: > Note also that we have not defined cloud-registrar behavior. I > think Eliot wold jus like to add something like WiFi SSID to > vouchers, but i would rather like to see it as a separate > "next-step after enrolment" message There is an ordering problem with 802.11 in particular.=C2=A0 In order to= get the voucher one has to have network connectivity.=C2=A0 In order to have network connectivity, one needs to be authenticated (e.g., having received the voucher).=C2=A0 An EAP method seems like a good way to break= that logjam, especially in environments where EAP is already prevalent, and TEAP has many of the characteristics that are already amenable to BRSKI.=C2=A0 As to SSID selection, the principle issue is some sort of pr= oof of ownership to the device.=C2=A0 A blind acceptance solely by a MASA is = what causes our issue.=C2=A0 If we can accept that problem statement, then we = have multiple paths we can take to avoid a deadlock. There are a few constraints: * In an environment with many SSIDs advertised, one doesn't want to simply round robin, due to power consumption.=C2=A0 Some sort of shor= tcut is desirable. * The discovery mechanism cannot be "chatty".=C2=A0 This is what Stewar= t Cheshire calls the "Stadium Problem".=C2=A0 That is not to say that devices must be entirely quiescent all the time. Finding the right balance here is the trick. Eliot --------------80C46C22E9AFF32A47332EE7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Toerless,


On 15.07.18 09:19, Toerless Eckert wrote:
Note also that we have not defined cloud-registrar b=
ehavior. I
think Eliot wold jus like to add something like WiFi SSID to
vouchers, but i would rather like to see it as a separate
"next-step after enrolment" message

There is an ordering problem with 802.11 in particular.=C2=A0 In orde= r to get the voucher one has to have network connectivity.=C2=A0 In order = to have network connectivity, one needs to be authenticated (e.g., having received the voucher).=C2=A0 An EAP method seems like a good w= ay to break that logjam, especially in environments where EAP is already prevalent, and TEAP has many of the characteristics that are already amenable to BRSKI.=C2=A0 As to SSID selection, the principle issue is some sort of proof of ownership to the device.=C2=A0 A blind= acceptance solely by a MASA is what causes our issue.=C2=A0 If we can= accept that problem statement, then we have multiple paths we can take to avoid a deadlock.

There are a few constraints:
  • In an environment with many SSIDs advertised, one doesn't want to simply round robin, due to power consumption.=C2=A0 Some sort = of shortcut is desirable.
  • The discovery mechanism cannot be "chatty".=C2=A0 This is what Stewart Cheshire calls the "Stadium Problem".=C2=A0 That is not t= o say that devices must be entirely quiescent all the time.

Finding the right balance here is the trick.

Eliot

--------------80C46C22E9AFF32A47332EE7-- --GtAG3EqachCvj37yQQPJ4WRYYKwxxo9bU-- --MpM3UjObOfLzLXon6bhm6pzMbSmrMK0t0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAltK+ggACgkQh7ZrRtnS ejOCzQgAg891Lzxl9Rj2ds/WxBiVmdXgc+D7TzDQzc8E6rFBRLRPJwc0BDu/dQ6Z s37LGpMoebQzLlXrkv72yhypn0cOuSXLbPZp7DL2Nn9Vv42wfCJT80FUw5OZU8ng SCDC6o1dXdi0TpBJYFC/rBsGhxm7ahUK8R/eGnNIg1OQDQkhi4NfVPNAA8m6z2jR 9FuFnB99LjzcSceAv2zasDXMl+0y+JILzvS7HDrZNsyrhOd8ntV/4oNrxKlLAqOT 9kOvg/uzz8Hzc3xZr+xgk6cXKjIH/D1AsG5D1s2LWuEC39o5gw7tKmuPW6u6pvtx 6A+Emj+9pwW00dIiocTiQyE7TAUdVw== =zRc0 -----END PGP SIGNATURE----- --MpM3UjObOfLzLXon6bhm6pzMbSmrMK0t0-- From nobody Sun Jul 15 10:02:08 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D29B130F84; Sun, 15 Jul 2018 10:01:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153167411704.21786.6541107096021109682@ietfa.amsl.com> Date: Sun, 15 Jul 2018 10:01:57 -0700 Archived-At: Subject: [Anima] IPR Disclosure Juniper's Statement about IPR related to draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 17:02:07 -0000 Dear Max Pritikin, Michael Richardson, Michael H. Behringer, Steinthor Bjarnason, Kent Watsen: An IPR disclosure that pertains to your Internet-Draft entitled "Bootstrapping Remote Secure Key Infrastructures (BRSKI)" (draft-ietf-anima-bootstrapping-keyinfra) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3233/). The title of the IPR disclosure is "Juniper's Statement about IPR related to draft-ietf-anima-bootstrapping-keyinfra" Thank you IETF Secretariat From nobody Sun Jul 15 10:33:53 2018 Return-Path: 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 EB7C9130F82 for ; Sun, 15 Jul 2018 10:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 JaZTVjEjO0tE for ; Sun, 15 Jul 2018 10:33:40 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357EC130FA8 for ; Sun, 15 Jul 2018 10:33:39 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 857FF58C4AF; Sun, 15 Jul 2018 19:33:34 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 703224402CB; Sun, 15 Jul 2018 19:33:34 +0200 (CEST) Date: Sun, 15 Jul 2018 19:33:34 +0200 From: Toerless Eckert To: Eliot Lear Cc: "Owen Friel (ofriel)" , Michael Richardson , "anima@ietf.org" Message-ID: <20180715173334.hnxtjtilql7in7as@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> <388b5570-320f-99e2-71af-6eb298f7d7cf@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <388b5570-320f-99e2-71af-6eb298f7d7cf@cisco.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 17:33:52 -0000 Eliot: I think you're trying this type of bootstrap: https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma#/media/File:Muenchhausen_Herrfurth_7_500x789.jpg The way to IMHO unconfuse this is to separate out the discussion about how to get the voucher, and if at all, how to signal the right SSID to a pledge. 1. A pledge can either try to find his owners AP/SSID and hope that if it gets connected to another AP/owner in before, then it will get rejected. That rejection could logically be done in two ways: a) cooperatively by those other owners knowing what they own and rejecting anything else. Knowing what they own could have a standards protocol but IMHO it should be different from MASA because it could come from a reseller, not the manufacturer (because the MASA has no sales integration). b) Some form of sales integration on the MASA so that it would reject non-owners. We did not talk about those schemes so far in ANIMA, IMHO the most simple sales integration is if there is a protocol by which a reseller could indicate to the MASA who owns a particular pledge. This transaction would then happen from the vendor as soon as it sold the pledge (and knows its serial number). The customer would need to provide once its trust anchors to the reseller, so they could be passed to the manufacturer by the reseller whenever this customer buys new pledges. The reseller could also guarantee any form of anonymity required, aka: manufacturer would not know who owns the trust anchors (paranoid customers may need to generate a bunch of trust anchors so they can not be identified by correlation over the set of pledges with the same trust anchor). Both 1.a and 1.b are trial and error wrt. finding the right SSID. Once can just limit search to those SSIDs that do support BRSKI and those who don't by coming up with appropriate network announcements, but those will not be able to help identifying the right owner. 2. Open but potentially constrained WiFi access allowing to access a cloud-registrar. Constrained in so far that the AP operator only support passing through BRSKI but not anything else (to avoid providing a free internet service). In this option, a case can be made to provide SSID information to the pledge during the voucher stage or after the enrolment stage. The argument for providing it during the voucher stage is that the pledge could earlier break the connection and take the third-party AP and manufacturer cloud registrar out of the picture. The main question is whether we should try to get the SSID passed to the pledge in an encrypted fashion so that the manufacturer MASA can not decrypt it. Of course, if you trust the manufacturers pledge, you kinda trust the manufacturer, but if i was running a MASA in a company of a country with perpass agencies, then i would like to define security procedures that would do its best to ensure that customers privacy is maximized. Cheers Toerless On Sun, Jul 15, 2018 at 09:38:47AM +0200, Eliot Lear wrote: > Hi Toerless, > > > On 15.07.18 09:19, Toerless Eckert wrote: > > Note also that we have not defined cloud-registrar behavior. I > > think Eliot wold jus like to add something like WiFi SSID to > > vouchers, but i would rather like to see it as a separate > > "next-step after enrolment" message > > There is an ordering problem with 802.11 in particular.  In order to get > the voucher one has to have network connectivity.  In order to have > network connectivity, one needs to be authenticated (e.g., having > received the voucher).  An EAP method seems like a good way to break > that logjam, especially in environments where EAP is already prevalent, > and TEAP has many of the characteristics that are already amenable to > BRSKI.  As to SSID selection, the principle issue is some sort of proof > of ownership to the device.  A blind acceptance solely by a MASA is what > causes our issue.  If we can accept that problem statement, then we have > multiple paths we can take to avoid a deadlock. > > There are a few constraints: > > * In an environment with many SSIDs advertised, one doesn't want to > simply round robin, due to power consumption.  Some sort of shortcut > is desirable. > * The discovery mechanism cannot be "chatty".  This is what Stewart > Cheshire calls the "Stadium Problem".  That is not to say that > devices must be entirely quiescent all the time. > > Finding the right balance here is the trick. > > Eliot > -- --- tte@cs.fau.de From nobody Sun Jul 15 11:21:11 2018 Return-Path: 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 B1421130ECD; Sun, 15 Jul 2018 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 F7IiHFj534Ev; Sun, 15 Jul 2018 11:21:07 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE294128CF3; Sun, 15 Jul 2018 11:21:06 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6D6E558C4AF; Sun, 15 Jul 2018 20:21:02 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56E7C4402CB; Sun, 15 Jul 2018 20:21:02 +0200 (CEST) Date: Sun, 15 Jul 2018 20:21:02 +0200 From: Toerless Eckert To: draft-ietf-anima-bootstrapping-keyinfra.authors@ietf.org Cc: Brian E Carpenter , anima@ietf.org Message-ID: <20180715182102.mb3uk2vi5km62nwz@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] BRSKI: New issue discoverd (Section D purge victim) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2018 18:21:10 -0000 Thanks, Brian. Let me change subject to catch the attention of the authors better. Filed as: https://github.com/anima-wg/anima-bootstrap/issues/66 > rev -16 section 5.2 has an unresolved EDNOTE pointing to a section for "Pledge Authorization". That section was last D.1.3.2. in -07 and was then removed when D.* was integrated back and the rest of D was removed in -08. > > I can not find offhand any stubs of D.1.3.2 integrated elsewhere into the text, so i would suggest to reintroduce an appropriate subset of that section (aka: anything you think is uncontentuous). On Sun, Jul 15, 2018 at 03:20:20AM +1200, Brian E Carpenter wrote: > No, of course not. But autonomic nodes aren't supposed to connect > to any old WiFi they happen to find; that's exactly the case where > secure bootstrap needs to fail. If they connect to a network on > which there's a registrar that knows nothing about them, > it won't authorize them to join the ACP. > > "The domain registrar authenticates the pledge, makes authorization > decisions,..." > > In Figure 3, I guess authorization is the tiny item "[accept device?]". > > BRSKI is defined in a nicely general way, but in an AN it's > the domain registrar's job to decide who's allowed in. > Actually there seems to be a glitch in the text on this. > We find: > > > 5.2. Pledge Requests Voucher from the Registrar > > ... > > ...The registrar performs authorization as > > detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge > > Authorization"]]. > > but that leads nowhere that I can find. BRSKI authors, please comment. > > Brian From nobody Mon Jul 16 13:01:48 2018 Return-Path: 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 8D551130DC2 for ; Mon, 16 Jul 2018 13:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gdLt0bfaRRWu for ; Mon, 16 Jul 2018 13:01:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1205129C6B for ; Mon, 16 Jul 2018 13:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6708; q=dns/txt; s=iport; t=1531771303; x=1532980903; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1qY7gb4KuVA8m/rD5NovxAN1AA3o/76haspq0CWLNfI=; b=E9MGKMV7BrHggYHpoqcn/fHhh9aLrejL8N/1FlFfGey6WEusugf5AlZY Ijwa2sSQjUWYMnbcahlLCsoOvlyuayFk5qPPHbDwXxQqpdQNwjm2rD+BN W+8+MyRzbq4ifDx4+VSn5ri+rMIyQrhhdFsLGsEPGe0G3dxNdrj9qVrY6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9BABM+Uxb/4MNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJY38oCoNzlD+CDIM4hQGNAIF6CxgLhEkCF4JKITUXAQI?= =?us-ascii?q?BAQIBAQJtHAyFNgEBAQECAQEBIRE6EAcEAgEIEQQBAQECAiMDAgICHwYLFAE?= =?us-ascii?q?ICAIEARIIgxmBZwMNCA+pGYEuhxENgyAFgQuHd4FXP4ERgmMughFFQwEBgXe?= =?us-ascii?q?CaoJVAodEByyROisJAowZcIIUgUuEEYgRiwiGZQIRFIEkHwE1gVJwFTuCaYI?= =?us-ascii?q?lF4hZhT5vAYtQK4EBgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,362,1526342400"; d="scan'208";a="422601104" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2018 20:01:24 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w6GK1Omw012684 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Jul 2018 20:01:24 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 16 Jul 2018 15:01:23 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Mon, 16 Jul 2018 15:01:23 -0500 From: "Owen Friel (ofriel)" To: Brian E Carpenter , Eliot Lear , Eliot Lear , Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Revision of scope of MASA in the BRSKI - Reg Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLgBWBpoAAHy30wAAAHlLAAB2W+CAAAL4tAAAGJiz8AAoQD2AAB/gUgAAASluAABjtXxg Date: Mon, 16 Jul 2018 20:01:23 +0000 Message-ID: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.242.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 20:01:47 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8 YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiANClNlbnQ6IFNhdHVyZGF5IDE0IEp1bHkgMjAx OCAxNjoyMA0KVG86IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPjsgT3dlbiBGcmllbCAob2Zy aWVsKSA8b2ZyaWVsQGNpc2NvLmNvbT47IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPjsgTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBhbmltYUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtBbmltYV0gUmV2aXNpb24gb2Ygc2NvcGUgb2YgTUFTQSBpbiB0aGUgQlJT S0kgLSBSZWcNCg0KT24gMTUvMDcvMjAxOCAwMjo0NywgRWxpb3QgTGVhciB3cm90ZToNCj4gQnJp YW4sIGlzIGl0IHlvdXIgY29udGVudGlvbiB0aGF0IDgwMi4xMSBpcyBiZXlvbmQgdGhlIHNjb3Bl IG9mIA0KPiBhdXRvbm9taWMgY29tcHV0aW5nPw0KDQpObywgb2YgY291cnNlIG5vdC4gQnV0IGF1 dG9ub21pYyBub2RlcyBhcmVuJ3Qgc3VwcG9zZWQgdG8gY29ubmVjdCB0byBhbnkgb2xkIFdpRmkg dGhleSBoYXBwZW4gdG8gZmluZDsgdGhhdCdzIGV4YWN0bHkgdGhlIGNhc2Ugd2hlcmUgc2VjdXJl IGJvb3RzdHJhcCBuZWVkcyB0byBmYWlsLiBJZiB0aGV5IGNvbm5lY3QgdG8gYSBuZXR3b3JrIG9u IHdoaWNoIHRoZXJlJ3MgYSByZWdpc3RyYXIgdGhhdCBrbm93cyBub3RoaW5nIGFib3V0IHRoZW0s IGl0IHdvbid0IGF1dGhvcml6ZSB0aGVtIHRvIGpvaW4gdGhlIEFDUC4NCltvZnJpZWxdIEFyZSB3 ZSBtYWtpbmcgdGhlIGFzc3VtcHRpb24gdGhhdCBhbGwgbmV0d29ya3MgYXJlIHdlbGwgYmVoYXZl ZCBhbmQgYSBSZWdpc3RyYXIgd2lsbCBhY3R1YWxseSByZWplY3QgZGV2aWNlcyBpdCBkb2VzIG5v dCBleHBsaWNpdGx5IG93bj8gV2hhdCBhYm91dCBhIHJvZ3VlIG5ldHdvcmsgd2hlcmUgdGhlIG9w ZXJhdG9yIGRvZXMgbm90IG93biB0aGUgY29ubmVjdGluZyBkZXZpY2VzIGJ1dCB0aGUgcmVnaXN0 cmFyIGFjY2VwdHMgdGhlbSBhbnl3YXk/IFRoYXQgaXMgdGhlIGlzc3VlIGhlcmUuDQoNCiJUaGUg ZG9tYWluIHJlZ2lzdHJhciBhdXRoZW50aWNhdGVzIHRoZSBwbGVkZ2UsIG1ha2VzIGF1dGhvcml6 YXRpb24gZGVjaXNpb25zLC4uLiINCg0KSW4gRmlndXJlIDMsIEkgZ3Vlc3MgYXV0aG9yaXphdGlv biBpcyB0aGUgdGlueSBpdGVtICJbYWNjZXB0IGRldmljZT9dIi4NCg0KQlJTS0kgaXMgZGVmaW5l ZCBpbiBhIG5pY2VseSBnZW5lcmFsIHdheSwgYnV0IGluIGFuIEFOIGl0J3MgdGhlIGRvbWFpbiBy ZWdpc3RyYXIncyBqb2IgdG8gZGVjaWRlIHdobydzIGFsbG93ZWQgaW4uDQpBY3R1YWxseSB0aGVy ZSBzZWVtcyB0byBiZSBhIGdsaXRjaCBpbiB0aGUgdGV4dCBvbiB0aGlzLg0KV2UgZmluZDoNCg0K PiA1LjIuICBQbGVkZ2UgUmVxdWVzdHMgVm91Y2hlciBmcm9tIHRoZSBSZWdpc3RyYXINCj4gICAg Li4uDQo+ICAgIC4uLlRoZSByZWdpc3RyYXIgcGVyZm9ybXMgYXV0aG9yaXphdGlvbiBhcw0KPiAg ICBkZXRhaWxlZCBpbiBbW0VETk9URTogVU5SRVNPTFZFRC4gIFNlZSBBcHBlbmRpeCBEICJQbGVk Z2UNCj4gICAgQXV0aG9yaXphdGlvbiJdXS4gDQoNCmJ1dCB0aGF0IGxlYWRzIG5vd2hlcmUgdGhh dCBJIGNhbiBmaW5kLiBCUlNLSSBhdXRob3JzLCBwbGVhc2UgY29tbWVudC4NCg0KICAgQnJpYW4N Cg0KPiANCj4gDQo+IE9uIDE0LjA3LjE4IDAxOjM0LCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToN Cj4+IE9uIDEzLzA3LzIwMTggMjE6MjYsIE93ZW4gRnJpZWwgKG9mcmllbCkgd3JvdGU6DQo+Pj4g SSB0aGluayBpdHMgbW9yZSBhY2N1cmF0ZSB0byBzdGF0ZToNCj4+Pg0KPj4+IOKAnFdoYXQgYSBD VVNUT01FUiB3YW50cyB0byBhdm9pZCBpcyBhIHBsZWRnZSBqb2luaW5nIGEgbmV0d29yayB3aGVy ZSB0aGUgTUFTQSBqdXN0IGRvZXMgdGhlIGxvZ2dpbmcgYW5kIGRvZXMgbm8gdmFsaWRhdGlvbiwg d2l0aG91dCBhbnkgb3RoZXIgbWVhbnMgdG8gZGV0ZXJtaW5lIHRoYXQgdGhlIGRldmljZSBpcyBv biB0aGUgY29ycmVjdCBuZXR3b3JrLuKAnSBFLmcuIEkgcGx1ZyBpbiBhIHdpLWZpIGRldmljZSBh bmQgaXQgY29ubmVjdHMgdG8gdGhlIFNTSUQgb2YgdGhlIGNvbXBhbnkgb24gdGhlIGZsb29yIGJl bG93IG1lLg0KPj4gVGhhdCBpcyBzbyBmYXIgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIGF1dG9u b21pYyBuZXR3b3JraW5nIA0KPj4gaW5mcmFzdHJ1Y3R1cmUgYXBwbGljYXRpb24gb2YgQlJTS0kg dGhhdCBJIGRvbid0IHNlZSB3aHkgd2UnZCBldmVuIA0KPj4gbWVudGlvbiBpdC4gSXQncyBhIGNh c2UgdGhhdCBkZWZpbml0ZWx5IG5lZWRzIHRvIGZhaWwgaGFyZCBpbiB0aGUgYXV0b25vbWljIGNv bnRleHQuDQo+Pg0KPj4gSWYgd2Ugd2FudCB0byBleHRlbmQgdGhlIHNjb3BlIG9mIEJSU0tJIHRv IGNvdmVyIEJZT0Qgb24gaW5zZWN1cmUgDQo+PiBXaUZpLCBJIHRoaW5rIHRoYXQncyBmb3Igc29t ZSBvdGhlciBXRy4NCj4+DQo+PiAgICBCcmlhbg0KPj4NCj4+PiBUaGUgTUFTQSBjYW5ub3QgaGVs cCB3aXRoIHRoaXMgdW5sZXNzIHRoZXJlIGlzIGNvbXBsZXggc2FsZXMgY2hhbm5lbCBpbnRlZ3Jh dGlvbiBhbmQgdGhlIE1BU0EgZXhwbGljaXRseSBrbm93cyBpbiBhZHZhbmNlIGV4YWN0bHkgd2hh dCBuZXR3b3JrIGVhY2ggcGxlZGdlIHdpbGwgYmUgY29ubmVjdGluZyB0by4gQSBwb3RlbnRpYWwg b3B0aW9uIGlzIHRvIGFsc28gcmVxdWlyZSB0aGUgcmVnaXN0cmFyIHRvIHByb3ZpZGUgc29tZSBw cm9vZiBvZiBvd25lcnNoaXAgdG8gdGhlIE1BU0EgaW4gdGhlIFZvdWNoZXJSZXF1ZXN0Lg0KPj4+ DQo+Pj4gRnJvbTogQW5pbWEgPGFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBF bGlvdCBMZWFyDQo+Pj4gU2VudDogVGh1cnNkYXkgMTIgSnVseSAyMDE4IDE3OjM4DQo+Pj4gVG86 IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgYW5pbWFAaWV0Zi5v cmcNCj4+PiBTdWJqZWN0OiBSZTogW0FuaW1hXSBSZXZpc2lvbiBvZiBzY29wZSBvZiBNQVNBIGlu IHRoZSBCUlNLSSAtIFJlZw0KPj4+DQo+Pj4NCj4+PiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBt YW51ZmFjdHVyZXIgZG9lc24ndCBoYXZlIGVub3VnaCBjb250ZXh0IHRvIG1ha2UgZGVjaXNpb25z IGFzIHRvIHdoaWNoIG5ldHdvcmsgdG8gam9pbi4gIFRoYXQgaXMgdGhlIGNoYWxsZW5nZS4NCj4+ Pg0KPj4+IE9uIDEyLjA3LjE4IDE3OjEyLCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6DQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4gRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20+PG1haWx0bzpsZWFyQGNp c2NvLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiAgICAgPiBpbnZvbHZlZC4gV2hhdCBhIG1hbnVmYWN0 dXJlciB3YW50cyB0byBhdm9pZCBpcyBhIHBsZWRnZSANCj4+PiBqb2luaW5nIGENCj4+Pg0KPj4+ ICAgICA+IG5ldHdvcmsgd2hlcmUgdGhlIE1BU0EganVzdCBkb2VzIHRoZSBsb2dnaW5nIGFuZCBk b2VzIG5vIA0KPj4+IHZhbGlkYXRpb24sDQo+Pj4NCj4+PiAgICAgPiB3aXRob3V0IGFueSBvdGhl ciBtZWFucyB0byBkZXRlcm1pbmUgdGhhdCB0aGUgZGV2aWNlIGlzIG9uIHRoZQ0KPj4+DQo+Pj4g ICAgID4gY29ycmVjdCBuZXR3b3JrLiBPdGhlcndpc2UsIHRoZSBwbGVkZ2UgKHdlIGNvdWxkIGNh bGwgaXQgdGhlDQo+Pj4NCj4+PiAgICAgPiAic3RhdGlvbiIgaW4gdGhpcyBjb250ZXh0KSBjb3Vs ZCBzaW1wbHkgaG9tZSB0byB0aGUgd3JvbmcgDQo+Pj4gbmV0d29yaywNCj4+Pg0KPj4+ICAgICA+ IGFuZCBldmVuIHJlc2V0dGluZyB0aGUgZGV2aWNlIHdvbid0IGdldCB5b3UgdG8gdGhlIHJpZ2h0 IG5ldHdvcmsuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gSSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGUg Im1hbnVmYWN0dXJlciIgY2FuIGhhdmUgYSBkZXNpcmUgKCJ0aGUgDQo+Pj4gcGxlZGdlDQo+Pj4N Cj4+PiBhdm9pZCBqb2luaW5nIGEgbmV0d29yayAuLi4iKSB0aGF0IGlzIGRpZmZlcmVudCBmcm9t IHRoZSBNQVNBJ3MgZGVzaXJlLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFRoZSBNQVNBICppcyogdGhl IGV4cHJlc3Npb24gbWFudWZhY3R1cmVyJ3MgZGVzaXJlLg0KPj4+DQo+Pj4gSWYgdGhlIG1hbnVm YWN0dXJlciBoYXMgc2FsZXMgY2hhbm5lbCBpbmZvcm1hdGlvbiB0aGF0IGluZGljYXRlcyB0aGUg DQo+Pj4gUGxlZGdlDQo+Pj4NCj4+PiBpcyBvbiB0aGUgd3JvbmcgbmV0d29yaywgaXQgc2hvdWxk IG5vdCBpc3N1ZSBhIHZvdWNoZXIuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gU28gdGhlIHNpdHVhdGlv biB5b3UgZGVzY3JpYmUgbWFrZXMgbm8gc2Vuc2UgdG8gbWUuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pg0KPj4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPj4+DQo+Pj4gQW5pbWFAaWV0Zi5v cmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0KPj4+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gQW5pbWEgbWFpbGluZyBsaXN0 DQo+Pj4gQW5pbWFAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuaW1hDQo+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBBbmltYSBtYWlsaW5nIGxpc3QNCj4+IEFuaW1hQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+IA0KPiANCg0K From nobody Mon Jul 16 16:30:06 2018 Return-Path: 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 182EA13123F for ; Mon, 16 Jul 2018 16:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 cC_nzyJpITt4 for ; Mon, 16 Jul 2018 16:30:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2E5130EE3 for ; Mon, 16 Jul 2018 16:30:03 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3C1DF58C4B4; Tue, 17 Jul 2018 01:29:59 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1AEF84402CB; Tue, 17 Jul 2018 01:29:59 +0200 (CEST) Date: Tue, 17 Jul 2018 01:29:59 +0200 From: Toerless Eckert To: "Owen Friel (ofriel)" Cc: Brian E Carpenter , Eliot Lear , Michael Richardson , "anima@ietf.org" Message-ID: <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> References: <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 23:30:05 -0000 On Mon, Jul 16, 2018 at 08:01:23PM +0000, Owen Friel (ofriel) wrote: [ofriel] Are we making the assumption that all networks are well behaved and a Registrar will actually reject devices it does not explicitly own? What about a rogue network where the operator does not own the connecting devices but the registrar accepts them anyway? That is the issue here. I think Brians comment was abouut fixing BRSKI to re-include text we lost in rev -08. The details of that text are not too relevant except IMHO giving some examples, as it did in -07. For the benefit of BRSKI becoming RFC, i would like to really only ask the minimum necessary to fix this piece, but not draw it into the larger discussion here related to your draft. As you point out, we can never be sure that rogue domains are not simply accepting devices they do not own. But we can build secure pledges by making MASA more secure and not hand out vouchers without more than the minimum necessary logging. That is not saying that the MASA should do more than just logging for every device, for example if the MASA supports both lightbulbs and core routers, it's clear that the MASA policies could be different. And this "sales" integration could be simply that the MASA requires some simple identity for a domains registrar. E.g: verify some domains email, credit-card number, ... something easily automated and good enough to track back the bad guy with enough likelihood. Cheers Toerless From nobody Mon Jul 16 17:55:30 2018 Return-Path: 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 54315130E7B for ; Mon, 16 Jul 2018 17:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IjPISQH1iriW for ; Mon, 16 Jul 2018 17:55:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A515130E7D for ; Mon, 16 Jul 2018 17:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2608; q=dns/txt; s=iport; t=1531788925; x=1532998525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ho+PdkuGd5i8NStQOlfCUtkUy4Mj65zZ45Pk8TyPHEs=; b=hKws0Kc9rqnqVrxN8ZBxXWdeNqbP0bQmeat+T/ixdHBlOWbOAwOrUNpR Pp51Ss8cQG0NzW60Rvy0O1VR4ovLNbmi3unfW6eBLNpNzBn5a8cwODiCI OOj+kinUeWCeWWQTol3c/t+SnFm4OBZviZ1qSZiv5DisAbiGix9hVg21j 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgD9PU1b/4QNJK1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDSWN/KAqYMoIMlTkUgWYLGAuESQKCYSE2FgECAQECAQE?= =?us-ascii?q?CbRwMhTYBAQEEAQEvCTQLDAQCAQgOAwQBAR8QJwsdCAIEAQ0FCBODBoF/D6o?= =?us-ascii?q?/gUqIdQWJAoFXP4ERgmMugxkBAQKBKgEBCAoBhXUCmVwJAo8djW2RbQIRFIE?= =?us-ascii?q?kIwExYXFwFTuCaYIlF4hZhT5vAYtpgR+BGgEB?= X-IronPort-AV: E=Sophos;i="5.51,363,1526342400"; d="scan'208";a="144064559" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 00:55:24 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w6H0tN3k015202 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2018 00:55:24 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 16 Jul 2018 19:55:23 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Mon, 16 Jul 2018 19:55:23 -0500 From: "Owen Friel (ofriel)" To: Toerless Eckert , "Owen Friel (ofriel)" CC: Michael Richardson , "anima@ietf.org" , Eliot Lear Thread-Topic: [Anima] Revision of scope of MASA in the BRSKI - Reg Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLgBWBpoAAHy30wAAAHlLAAB2W+CAAAL4tAAAGJiz8AAoQD2AAB/gUgAAASluAABjtXxgABH5iYAAB69nsA== Date: Tue, 17 Jul 2018 00:55:23 +0000 Message-ID: References: <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.242.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 00:55:28 -0000 -----Original Message----- From: Anima On Behalf Of Toerless Eckert Sent: Tuesday 17 July 2018 00:30 To: Owen Friel (ofriel) Cc: Michael Richardson ; anima@ietf.org; Eliot Lear = Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg On Mon, Jul 16, 2018 at 08:01:23PM +0000, Owen Friel (ofriel) wrote: [ofriel] Are we making the assumption that all networks are well behaved an= d a Registrar will actually reject devices it does not explicitly own? What= about a rogue network where the operator does not own the connecting devic= es but the registrar accepts them anyway? That is the issue here. I think Brians comment was abouut fixing BRSKI to re-include text we lost i= n rev -08. The details of that text are not too relevant except IMHO giving= some examples, as it did in -07. For the benefit of BRSKI becoming RFC, i would like to really only ask the = minimum necessary to fix this piece, but not draw it into the larger discus= sion here related to your draft. [ofriel] Agreed. I think the point Eliot and I are making is that the BRSKI= draft is fine as is (with that edit Brian pointed out) and does not need t= o explicitly address the Wi-Fi SSID rogue network issue. And its worth poin= ting out that the BRSKI draft does not preclude building a solution for tha= t rogue network SSID issue either (we have discussed this at length with Ma= x). The draft-friel-brski-over-802dot11 draft starts to touch on some mecha= nisms for how to address the SSID selection issue, and that is a potential = place to start to document possible solutions. As you point out, we can never be sure that rogue domains are not simply a= ccepting devices they do not own. But we can build secure pledges by making= MASA more secure and not hand out vouchers without more than the minimum n= ecessary logging. That is not saying that the MASA should do more than just= logging for every device, for example if the MASA supports both lightbulbs= and core routers, it's clear that the MASA policies could be different. And this "sales" integration could be simply that the MASA requires some si= mple identity for a domains registrar. E.g: verify some domains email, cred= it-card number, ... something easily automated and good enough to track bac= k the bad guy with enough likelihood. Cheers Toerless _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Mon Jul 16 20:27:05 2018 Return-Path: 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 E9F56130E76 for ; Mon, 16 Jul 2018 20:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 S7G8tAJPA35o for ; Mon, 16 Jul 2018 20:27:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D69B130E40 for ; Mon, 16 Jul 2018 20:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4389; q=dns/txt; s=iport; t=1531798021; x=1533007621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hMV0VV+xPGoXxYbjC7BNb0rxmZKZd+7tuduaKRfoxGM=; b=KcVz3onnIp4ESZD7ftwCuxhpAos8AfjUWm+1U2K4gT7rKUpq6P+XjYZq X3t71nVuWoz5/eZyHpCdCCeld7VZJFovROagvi+LmnIfaNXfgbFy7Y9Yp ZcgU9raPlDNQM8IJ6e5B6onvQF5UHIqLMRVQ1Szqv7jXUIbGWxGBFOye0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgAmYU1b/5BdJa1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDGy5jfygKmDKCDJVNgWYLI4RJAoJhITcVAQIBAQIBAQJ?= =?us-ascii?q?tKIU2AQEBBDotBQgCAwwEAgEIDgMEAQEfEDIdCAIEDgUIE4JjGAuBfw+qPYp?= =?us-ascii?q?EiHMPgVc/gRGCE1AuhFEShW4Ch0ssB5FeCQKGCIcBghSBS0OGO4UkkW0CERS?= =?us-ascii?q?BJDMigVJwFYMkCYIcF44Xb40JgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,364,1526342400"; d="scan'208";a="424736221" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 03:27:00 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id w6H3R0Uc032457 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2018 03:27:00 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 16 Jul 2018 22:26:59 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Mon, 16 Jul 2018 22:26:59 -0500 From: "Owen Friel (ofriel)" To: Toerless Eckert CC: Eliot Lear , Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Revision of scope of MASA in the BRSKI - Reg Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLgBWBpoAAHy30wAAAHlLAAB2W+CAAAL4tAAAGJiz8ABqyU8AAFF0loA= Date: Tue, 17 Jul 2018 03:26:59 +0000 Message-ID: <92b114963bbe465e887b6186b97ecc55@XCH-RCD-012.cisco.com> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.242.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 03:27:04 -0000 -----Original Message----- From: Toerless Eckert =20 Sent: Sunday 15 July 2018 08:19 To: Owen Friel (ofriel) Cc: Eliot Lear ; Michael Richardson = ; anima@ietf.org Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg Owen, I've associated draft-friel-brski-over-802dot11 to anima so folks will see = it in data tracker. Next time post new work for a particular WG with draft-= --, that will make it happen automatically. 2.1.1.1) There is no need to bother the MASA with sales integration just so= that the owner will know whether or not it owns a particular device. Any p= rotocol from the manufacturer/reseller to the owner will suffice. [ofriel] The point here isn't for the MASA can tell the owner that he owns = the devices, the purpose is for the owner to explicitly claim the devices o= n the MASA to accomplish your option 1(b) for later in this thread (the thr= ead is very disjointed at this stage): " b) Some form of sales integration on the MASA so that it would reject non= -owners. " I think we are actually talking about exactly the same thing here, if that'= s not clear in the draft text, we can certainly clarify. I recommend carrier pidgeons with USB sticks trained to insert them into a = USB slot releasing a food portion. Great protection against against unrecog= nize NSA interception of the channel especially for vendors products on the= NSA shortlist ;-)) Kidding aside: A standard protocol for sales information disemination would= be great, and given how its for bootstrap automation it would be fine for = ANIMA. I would jus resist of mixing it with BRSKI/MASA unless there is clea= r evidence of not keeping it modular. Especially given how it cold come fro= m the reseller, and nothe vendor. 2.1.1.2) This read a bit confused. I think it should mention two methods: O= ne is the aove mentioned to know what you own - independent of MASA (yor la= st sentence in 2.1.1.2 confused this option with the MASA). The other optio= n is just to try the MASA in the absence of better information. BUT: If you= only try the MASA, you should only do this automatically if you do know th= e MASA has sales integation. Otherwise you better include a manual checkpoi= nt before enrollment. [ofriel] Sales integration with the MASA (where sales integration means tha= t the MASA explicitly has a map of devices to owners) is not required here = at all. One of the core features of MASA is that it audit logs all issued v= ouchers and the vouched registrar identity. If a network operator knows the= identity of a device they own, but that device has not connected to their = network, the operator can query the MASA audit logs to see if that missing = device has been vouched for on a different network. E.g. I own serial#abc123 signed by AcmeCA, I can see it powered up and appa= rently live on the desk beside me, but my Registrar/AAA doesn't see it. My = Registrar /AAA could query MASA for logs pertaining to serial#abc123 and se= e that a voucher was issued for that device against registrar.the-company-o= n-the-floor-above-me.com. So this does not prevent my device from connectin= g to the wrong network, but it does allow me to detect it after the fact. 2.1.2) This section is a bit unmotivated even though its part of the best s= olution, but that solution requires more details than just WiFi. Aka: You want to allow announcement (using any of the options you specified= ) of open access SSID that allow to connect to cloud-registrars. These do not even have to be free internet access. Ideally we would think a= bout an unencrypted channel to the cloud registrar that relies only on auth= enticated but unencrypted messages. That way the owner of the AP can veryif= y and constrict communications to only cloud-registrar-enrollment so that t= his access is not as a side-channel to gain full internet access. TLS 1.2 s= till allows zero-encryption, that would be the easiest option. TLS 1.3 remo= ved it *sigh*. Note also that we have not defined cloud-registrar behavior. I think Eliot = wold jus like to add something like WiFi SSID to vouchers, but i would rath= er like to see it as a separate "next-step after enrolment" message Cheers Toerless From nobody Mon Jul 16 20:38:18 2018 Return-Path: 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 9ADD9130E8D for ; Mon, 16 Jul 2018 20:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WXjzXjjTwaxR for ; Mon, 16 Jul 2018 20:38:13 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B23A130DEF for ; Mon, 16 Jul 2018 20:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6169; q=dns/txt; s=iport; t=1531798693; x=1533008293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PO38Ij+QUd+Xfd4Hz7lPhZgSwFY/T6DnfKpQDWyQZjU=; b=azW3mjiEmxCdn4IghQRIUQSYWA7B4G0XVbDsVeDRdm5NnEsdqySZT1tk 6DFGw6m2azT6KlxJkwA5IJs/GNE2KNmJhw3iX/bKvo/i1prdHkJJQglM8 B8QLQ9dEeW/nDnNj7LEzj762Lkdg1UAbPpz2e5RqvaddsGenvEuodf2Nb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBdZE1b/5xdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMbLmN/KAqEVZNdggyXMwsnhEUCgmEhNxUBAgEBAgEBAm0?= =?us-ascii?q?cDIU2AQEBBA5XDwUMBAIBCA4DBAEBAS4yHQgCBAENBQiDGYF/D6o4gTeJCAW?= =?us-ascii?q?IZR2BVz+BEYJjLoI5YAEBAQEBgTcKBoVsAodEBywNhQ9vi1oJAoYIgmSEHYI?= =?us-ascii?q?UjW2KOYc0AhEUgSQzIoFScBWDJIIlF4hZhT5vAQGLWoEtgRoBAQ?= X-IronPort-AV: E=Sophos;i="5.51,364,1526342400"; d="scan'208";a="143542565" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 03:38:06 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w6H3c6mZ031002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Jul 2018 03:38:06 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 16 Jul 2018 22:38:05 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Mon, 16 Jul 2018 22:38:05 -0500 From: "Owen Friel (ofriel)" To: Toerless Eckert , Eliot Lear CC: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Revision of scope of MASA in the BRSKI - Reg Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLgBWBpoAAHy30wAAAHlLAAB2W+CAAAL4tAAAGJiz8ABqyU8AAACstIAAFMXHAAA8kt6A Date: Tue, 17 Jul 2018 03:38:05 +0000 Message-ID: <33927de7015b4c5192e38847d3864a54@XCH-RCD-012.cisco.com> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> <388b5570-320f-99e2-71af-6eb298f7d7cf@cisco.com> <20180715173334.hnxtjtilql7in7as@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20180715173334.hnxtjtilql7in7as@faui48f.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.242.128] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 03:38:16 -0000 -----Original Message----- From: Toerless Eckert =20 Sent: Sunday 15 July 2018 18:34 To: Eliot Lear Cc: Owen Friel (ofriel) ; Michael Richardson ; anima@ietf.org Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg Eliot: I think you're trying this type of bootstrap: https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma#/media/File:Muenchh= ausen_Herrfurth_7_500x789.jpg The way to IMHO unconfuse this is to separate out the discussion about how = to get the voucher, and if at all, how to signal the right SSID to a pledge= . [ofriel] If the pledge is connecting to an 802.1x network behind an SSID, I= don't think there is any need at all to explicitly tell the pledge the SSI= D at all. There could be multiple different SSIDs (in theory anyway) connec= ting to the same 802.1x network, the key thing is that the voucher tells th= e pledge to trust the EAP server that is it is establishing the TLS connect= ion to. If the EAP connection is trusted, then is doesn't really matter whi= ch AP or SSID the pledge used to get there... 1. A pledge can either try to find his owners AP/SSID and hope that if it g= ets connected to another AP/owner in before, then it will get rejected. Th= at rejection could logically be done in two ways: a) cooperatively by those other owners knowing what they own and rejecting anything else.=20 [ofriel] I don't think we can rely on that. Knowing what they own could have a standards protocol but IMHO it should be different from MASA because it could come from a reseller, not the manufacturer (because the MASA has no sales integration). b) Some form of sales integration on the MASA so that it would reject non-owners. We did not talk about those schemes so far in ANIMA, IMHO the most simple sales integration is if there is a protocol by which a reseller could indicate to the MASA who owns a particular pledge. This transaction would then happen from the vendor as soon as it sold the pledge (and knows its serial number). The customer would need to provide once its trust anchors to the reseller, so they could be passed to the manufacturer by the reseller whenever this customer buys new pledges. The reseller could also guarantee any form of anonymity required, aka: manufacturer would not know who owns the trust anchors (paranoid customers may need to generate a bunch of trust anchors so they can not be identified by correlation over the set of pledges with the same trust anchor). Both 1.a and 1.b are trial and error wrt. finding the right SSID. Once can = just limit search to those SSIDs that do support BRSKI and those who don't = by coming up with appropriate network announcements, but those will not be = able to help identifying the right owner. [ofriel] Agreed. Simple 802.11u/aq/etc. could reduce the number of SSID can= didates, but its still a round robin by the device if it fails to get a vou= cher when it tried any given SSID candidate. 2. Open but potentially constrained WiFi access allowing to access a cloud-= registrar. Constrained in so far that the AP operator only support passing = through BRSKI but not anything else (to avoid providing a free internet ser= vice). In this option, a case can be made to provide SSID information to the pledg= e during the voucher stage or after the enrolment stage. The argument for providing it during the voucher stage is that the pledge c= ould earlier break the connection and take the third-party AP and manufactu= rer cloud registrar out of the picture. [ofriel] If connecting to a cloud-registrar then that pretty much mandates = strong sales integration and ownership info on the MASA. The main question is whether we should try to get the SSID passed to the pl= edge in an encrypted fashion so that the manufacturer MASA can not decrypt = it. Of course, if you trust the manufacturers pledge, you kinda trust the m= anufacturer, but if i was running a MASA in a company of a country with per= pass agencies, then i would like to define security procedures that would d= o its best to ensure that customers privacy is maximized. [ofriel] There is an option 3, which is https://tools.ietf.org/html/draft-f= riel-brski-over-802dot11-01#section-2.1.3. DPP or any similar protocol wher= e proof-of-ownership is required. Cheers Toerless On Sun, Jul 15, 2018 at 09:38:47AM +0200, Eliot Lear wrote: > Hi Toerless, >=20 >=20 > On 15.07.18 09:19, Toerless Eckert wrote: > > Note also that we have not defined cloud-registrar behavior. I think=20 > > Eliot wold jus like to add something like WiFi SSID to vouchers, but=20 > > i would rather like to see it as a separate "next-step after=20 > > enrolment" message >=20 > There is an ordering problem with 802.11 in particular.=A0 In order to=20 > get the voucher one has to have network connectivity.=A0 In order to=20 > have network connectivity, one needs to be authenticated (e.g., having=20 > received the voucher).=A0 An EAP method seems like a good way to break=20 > that logjam, especially in environments where EAP is already=20 > prevalent, and TEAP has many of the characteristics that are already=20 > amenable to BRSKI.=A0 As to SSID selection, the principle issue is some=20 > sort of proof of ownership to the device.=A0 A blind acceptance solely=20 > by a MASA is what causes our issue.=A0 If we can accept that problem=20 > statement, then we have multiple paths we can take to avoid a deadlock. >=20 > There are a few constraints: >=20 > * In an environment with many SSIDs advertised, one doesn't want to > simply round robin, due to power consumption.=A0 Some sort of shortcu= t > is desirable. > * The discovery mechanism cannot be "chatty".=A0 This is what Stewart > Cheshire calls the "Stadium Problem".=A0 That is not to say that > devices must be entirely quiescent all the time. >=20 > Finding the right balance here is the trick. >=20 > Eliot >=20 -- --- tte@cs.fau.de From nobody Mon Jul 16 20:49:54 2018 Return-Path: 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 BD32C130E99 for ; Mon, 16 Jul 2018 20:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 ASlQBm3XnLSE for ; Mon, 16 Jul 2018 20:49:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F8E128CF3 for ; Mon, 16 Jul 2018 20:49:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4821F58C4B4; Tue, 17 Jul 2018 05:49:44 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 29FC64402CB; Tue, 17 Jul 2018 05:49:44 +0200 (CEST) Date: Tue, 17 Jul 2018 05:49:44 +0200 From: Toerless Eckert To: "Owen Friel (ofriel)" Cc: "Owen Friel (ofriel)" , Michael Richardson , "anima@ietf.org" , Eliot Lear Message-ID: <20180717034944.qbmtrvgdtxim5ogl@faui48f.informatik.uni-erlangen.de> References: <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 03:49:53 -0000 Thanks, probably better to use the high frequency meeting options we have this week than extending this thread too much right now. I guess my highest level point is that i could see benefit in using the wifi case you folks want to drive to build out document(s) for some generic pieces we're missing like cloud registrar (BRSI is just a stub IMHO), and really try to have the wifi doc only do the wifi specific piece - and inherit any components we could equally use for non-wifi scenarios from such shared additional docs. Cheers Toerless On Tue, Jul 17, 2018 at 12:55:23AM +0000, Owen Friel (ofriel) wrote: > > > -----Original Message----- > From: Anima On Behalf Of Toerless Eckert > Sent: Tuesday 17 July 2018 00:30 > To: Owen Friel (ofriel) > Cc: Michael Richardson ; anima@ietf.org; Eliot Lear > Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg > > On Mon, Jul 16, 2018 at 08:01:23PM +0000, Owen Friel (ofriel) wrote: > [ofriel] Are we making the assumption that all networks are well behaved and a Registrar will actually reject devices it does not explicitly own? What about a rogue network where the operator does not own the connecting devices but the registrar accepts them anyway? That is the issue here. > > I think Brians comment was abouut fixing BRSKI to re-include text we lost in rev -08. The details of that text are not too relevant except IMHO giving some examples, as it did in -07. > > For the benefit of BRSKI becoming RFC, i would like to really only ask the minimum necessary to fix this piece, but not draw it into the larger discussion here related to your draft. > [ofriel] Agreed. I think the point Eliot and I are making is that the BRSKI draft is fine as is (with that edit Brian pointed out) and does not need to explicitly address the Wi-Fi SSID rogue network issue. And its worth pointing out that the BRSKI draft does not preclude building a solution for that rogue network SSID issue either (we have discussed this at length with Max). The draft-friel-brski-over-802dot11 draft starts to touch on some mechanisms for how to address the SSID selection issue, and that is a potential place to start to document possible solutions. > > As you point out, we can never be sure that rogue domains are not simply accepting devices they do not own. But we can build secure pledges by making MASA more secure and not hand out vouchers without more than the minimum necessary logging. That is not saying that the MASA should do more than just logging for every device, for example if the MASA supports both lightbulbs and core routers, it's clear that the MASA policies could be different. > > And this "sales" integration could be simply that the MASA requires some simple identity for a domains registrar. E.g: verify some domains email, credit-card number, ... something easily automated and good enough to track back the bad guy with enough likelihood. > > Cheers > Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Jul 16 20:54:15 2018 Return-Path: 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 83FE3130E99 for ; Mon, 16 Jul 2018 20:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 26ztTeiwZcmu for ; Mon, 16 Jul 2018 20:54:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C540130DEF for ; Mon, 16 Jul 2018 20:54:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E20F72008C; Tue, 17 Jul 2018 00:09:54 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 094582686; Mon, 16 Jul 2018 23:49:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0703F267E; Mon, 16 Jul 2018 23:49:39 -0400 (EDT) From: Michael Richardson To: "Anoop Kumar Pandey" cc: "'Toerless Eckert'" , anima@ietf.org In-Reply-To: <007501d4182c$6985efc0$3c91cf40$@cdac.in> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> <007501d4182c$6985efc0$3c91cf40$@cdac.in> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 03:54:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Anoop Kumar Pandey wrote: > Anyone can present certificate of anyone else (it=E2=80=99s public). = That=E2=80=99s > why I proposed use of digital signature and later verification to > establish the identity of both JRC and Pledge. Presenting a certificate of another party doesn't work. TLS and other protocols don't just use a certificate, but they use the related private key to sign part of the transaction. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW01nT4CLcPvd0N1lAQKJAQgAlG6fKFrGTGbefmmXr6dkACI2B9wP+oLn 4fAiGpTdCfU3W1PN3YTmPCCx32/rPAul+aZGpXKqXjfw4XaF2mKKNVrzyGq65WjW E7v3fGeJop//G26ykFSZPzb4TYKZXbGccbLr8Rfh0sdQfDvw26dtFKPYXCgB6nNV ToiCXxqpsFopPMC0DhMLq3ToVM6N4kcEhElly85UYFcUmhZAU4Jj5AP/o5D50ezh jRiuEdAFHrX5qMEBGHcFvNl5at2d9gRSTtmjPQSpOwNb/01cb6QM9stQl3hlb3NV 0/FSNsEmBgWUrHAKPej6EFFdK60XEb++ocS8V9lFAfgTPbAr38F1Lw== =91Qi -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 16 20:55:52 2018 Return-Path: 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 81035130DEF for ; Mon, 16 Jul 2018 20:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 8tmWX2Q2S0t4 for ; Mon, 16 Jul 2018 20:55:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE6C124C04 for ; Mon, 16 Jul 2018 20:55:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 83CA12008C; Tue, 17 Jul 2018 00:11:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A3A392686; Mon, 16 Jul 2018 23:51:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A2F48267E; Mon, 16 Jul 2018 23:51:13 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: anima@ietf.org In-Reply-To: <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 03:55:51 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > The problem is that the manufacturer doesn't have enough context to > make decisions as to which network to join. That is the challenge. So... who knows then? I'm asking seriously. You are looking down (like god) with knowledge that apparently isn't in the network. So please explain. > On 12.07.18 17:12, Michael Richardson wrote: =20=20=20=20 > Eliot Lear wrote: >> involved. What a manufacturer wants to avoid is a pledge joining a >> network where the MASA just does the logging and does no validation, >> without any other means to determine that the device is on the >> correct network. Otherwise, the pledge (we could call it the >> "station" in this context) could simply home to the wrong network, >> and even resetting the device won't get you to the right network. > I don't understand how the "manufacturer" can have a desire ("the ple= dge > avoid joining a network ...") that is different from the MASA's desir= e. > The MASA *is* the expression manufacturer's desire. > If the manufacturer has sales channel information that indicates the = Pledge > is on the wrong network, it should not issue a voucher. > So the situation you describe makes no sense to me. > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW01nroCLcPvd0N1lAQJrMQf/Wh87fYsSg97ZOH8KTxPC7R+4ZSh37cN1 fGAfA4jWfCRVCgA6y6cDTImC8eXIn8GsnZxt9DIwcJjBQVo58WOu9cLx3qM70guq RSaONSTp6Z5x8TnukL4W/57AIz8FL7qD4nGj18uC+SkOZ5eO58XEA9jBHtqH8VF3 9RYbv2DgzmRnegmzqVwjsXWiAM9nsOGdOTNtJKPuZvvGdcK7TO0wxdMdh6Lm4ZbX gZQfUEu2An6RXlMuVlyxo5cuCg0pbKSzcJFmq2PsYXhPJiLlddOIgYJt0f6N4X6V 8iJv4fPn8QhW2Wf61IJz1zdXJPf6LYwNsMJEc/AXKgUk2yYKmQEcJw== =GiHJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 16 21:00:57 2018 Return-Path: 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 E25DA130EAF for ; Mon, 16 Jul 2018 21:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 Rvi1eb9qFftD for ; Mon, 16 Jul 2018 21:00:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7273D130DEF for ; Mon, 16 Jul 2018 21:00:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C7BE2008C; Tue, 17 Jul 2018 00:16:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 32C3D2686; Mon, 16 Jul 2018 23:56:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2FE93267E; Mon, 16 Jul 2018 23:56:20 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" , "Owen Friel \(ofriel\)" cc: Eliot Lear In-Reply-To: <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 04:00:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Owen Friel (ofriel) wrote: > I think its more accurate to state: > =E2=80=9CWhat a CUSTOMER wants to avoid is a pledge joining a network= where > the MASA just does the logging and does no validation, without any > other means to determine that the device is on the correct network.= =E2=80=9D > E.g. I plug in a wi-fi device and it connects to the SSID of the > company on the floor below me. Ah! This I can comprehend. > The MASA cannot help with this unless there is complex sales channel > integration and the MASA explicitly knows in advance exactly what > network each pledge will be connecting to. A potential option is to > also require the registrar to provide some proof of ownership to the > MASA in the VoucherRequest. Max, Kent and I discussed the possibility that there would be a QR code in the packaging that would act as proof of ownership. What we concluded was that this would be a protocol on-top-of BRSKI. Instead of trying to integrate that into BRSKI, what the QR code would do is permit the Registrar to set up *sales channel integration* with the MASA. This would be a new extension to the BRSKI-MASA channel. This requires the MASA to cooperate. If the vendor doesn't support that, then the answer is that you bought the wrong product :-) I hope to start a document on this this summer as part of work I'm doing to build a secure home gateway for IoT use. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW01o4YCLcPvd0N1lAQL6xwf/QszwgR8fFr9xs24Hf84V6ZKMxR46ApV2 dJ3nfAQ/+ZWHpwa2Uodmn3GAIcCctDakfcMqCYCHN3P7yls+WVvptrR7r39ApIBW ILPZ9xyw4ZEcm8MgxpxId9W7IrbYGOpb/Zx/VLUUqtC4YC8YozA6mXu4luRDbrnQ oX1QhZMgVRpPerTcdk7m9pBve0PwV4TiOUiXHIqYEf2ja+Ehoo6Gr3f1NKdQ9np7 QftAZErFlaztk4RqT3eWyh9zDBU+0m2dL82kmyI2xfv2Y77mPlC2vtvEWC+1YJmn q2M/HIvym0pLyAVOfKd/NY2XLyWepYlGetPca4Hgu4SjInfsYSUkWg== =TNhb -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 16 21:03:41 2018 Return-Path: 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 1AD74130E99 for ; Mon, 16 Jul 2018 21:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 p22MTf9j0a5s for ; Mon, 16 Jul 2018 21:03:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018CB124C04 for ; Mon, 16 Jul 2018 21:03:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 93A812008C for ; Tue, 17 Jul 2018 00:19:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A7EB42686; Mon, 16 Jul 2018 23:59:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A5A5D267E for ; Mon, 16 Jul 2018 23:59:05 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 04:03:40 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > That is so far outside the scope of the autonomic networking > infrastructure application of BRSKI that I don't see why we'd even > mention it. It's a case=20 > that definitely needs to fail hard in the autonomic context. Actually, the only thing lacking is the sales channel integration. If the MASA knows the intended owner, then everything works. > If we want to extend the scope of BRSKI to cover BYOD on insecure WiF= i, I > think that's for some other WG. I don't know if it's for another WG or not, but Owen's document deals with this... I'm not sure I'd call it "BYOD", exactly... Bring a not-yet-Owned Device, that you'd like to Own, and get pOwned. And the WiFi is insecure, because the device doesn't (yet) have accesss to the secure WiFi. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW01phoCLcPvd0N1lAQJ2+wf+Pbb3Yz83PUhh3lCqM/BbJiMIommvTERD itWBhkA9xCW5WpkFcbkELl220FJ+0uo4drkN0gpZApngqzPg/8vmU1eHuBpOn9PE w68p38MXX9yRU2o1qykF7AlZOGpgrzjdjsVjXw0FzZSF2sKmnfaIufI/tQdckRtu /QQO39GoEIateULw5mpNcHGeN9kaiSQW/9a5FOrOuruTRKVsheE8zBhc2F+milVy Jo/m+Wmc+sAKrsHhVRD8dPADEhyhmTrdVS0iAOVyMVXeZPrMpXcJY5XQdM6emYds XhB9xu9OkPqCFTERZoY7mynTpE8S8JkIvXaXYr+Ja39LKc45RGmgEQ== =YSPM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 16 21:12:15 2018 Return-Path: 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 0FA7B130EAA for ; Mon, 16 Jul 2018 21:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 SXh_ZzbB7e-o for ; Mon, 16 Jul 2018 21:12:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8110E124C04 for ; Mon, 16 Jul 2018 21:12:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 261D02008C for ; Tue, 17 Jul 2018 00:27:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 32EAD2686; Tue, 17 Jul 2018 00:07:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 30A97267E for ; Tue, 17 Jul 2018 00:07:39 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <20180715173334.hnxtjtilql7in7as@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> <388b5570-320f-99e2-71af-6eb298f7d7cf@cisco.com> <20180715173334.hnxtjtilql7in7as@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 04:12:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > The way to IMHO unconfuse this is to separate out the discussion > about how to get the voucher, and if at all, how to signal the right > SSID to a pledge. Yup... please see the work that is occuring in 6tisch. The technology is 802.15.4, and so the Stadium isn't full of smartphones, b= ut rather it's a parking garage of intelligent cars, or an industrial setting. The one-touch (PSK) mechanism that includes the network info: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ The zero-touch mechanism that is constrained BRSKI: https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch= -join/ The Enhanced Beacon that provides a bit of information as to what network might be worth joining: https://datatracker.ietf.org/doc/draft-richardson-6tisch-enrollment-e= nhanced-beacon/ (now adopted. I should post under correct name) How to pick the PANID is not specified yet. Mostly the same as picking an SSID.=20 =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW01riICLcPvd0N1lAQKHoAf/XoIY2zDifG49erYjn4YdjHteyd7Oxvwj qAnV86URzeGmtwi8LeJXja/dgB6MTtbtVqKFbr5kWbxs/iLPrtM/lENjIoIktzMh NukG1WJF7lRaeGlht/CQIeFk+6PpoIo78sj3Q60OJmaQBg6tPEpfx1kIjfDBoRuD SGp6mI3+l42W9uxaJCM3oEMHe8aP/rBfYnZDDSWMgT5XJpsn7heOiS6R/k5pAMRu Ua0w2B7pStOoykgRkB5UmlOdfCfG406RyDHwpgEDdgp/ybaQTmWkkVUquMpQlljB nPQcGwiI67Po/ImcmRXzedGEVE+P+f33cKHU0FCrJHrlY/PJBu3WNQ== =hOGB -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 16 21:54:12 2018 Return-Path: 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 6283E130EB9 for ; Mon, 16 Jul 2018 21:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 vENcmrmOc66B for ; Mon, 16 Jul 2018 21:54:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376D21274D0 for ; Mon, 16 Jul 2018 21:54:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E59FB2008C for ; Tue, 17 Jul 2018 01:09:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D471F2686; Tue, 17 Jul 2018 00:49:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D2196267E for ; Tue, 17 Jul 2018 00:49:35 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> References: <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] "Rogue" Domains vs audit-only MASA policies X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 04:54:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > As you point out, we can never be sure that rogue domains are not > simply accepting devices they do not own. But we can build secure Please explain how this works. A Registrar that accepts a device that has an audit-only MASA is not rogue. It's doing exactly the right thing. I think the problem is that some people think they are going to sell $100K BFRs with audit-only policies? > the MASA should do more than just logging for every device, for > example if the MASA supports both lightbulbs and core routers, it's > clear that the MASA policies could be different. And given the ability to embed different URLs in the IDevID certificate, I'd want to run two completely different MASA :-) > And this "sales" integration could be simply that the MASA requires > some simple identity for a domains registrar. E.g: verify some > domains email, credit-card number, ... something easily > automated and good enough to track back the bad guy with enough > likelihood. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW011XYCLcPvd0N1lAQIMnQgAtUBlwoIpIU6mI8AnaqOOM40kYTGJTWuM GT9Xa1trnY4uVUgvA39J/FCeS89whMS/q9tuS2BeQz9oHX2CU+JD4GcgPR1FMXNp QF0PJcnz8JGwIp2JPGZUHztlLrAA+hyOUePtxeQ+4hYtc9KdCBwhU5W/k0EOjJbI hlbecQID5J4Lc7iUGn7ypnQSlPHcNnx+CfUvY9AAUsWjVmBbGzG/zTOn6tcxWSLG XPmjjUs+swDdrK2X/GVjn+oa/A0fCaMDHZF3gr1hEhGP/3rsfMjOUmjGowZHYyd5 MgjFPtjRj6FE3oHGtQ9zkyaGlxetDNKyu/NzI2EgJbT9Wt6L3rfS2g== =7q2M -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 16 22:24:10 2018 Return-Path: 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 8B199130F2B for ; Mon, 16 Jul 2018 22:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 AC1GDAw_n3xP for ; Mon, 16 Jul 2018 22:24:06 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB117130E6C for ; Mon, 16 Jul 2018 22:24:05 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B48C058C4B4; Tue, 17 Jul 2018 07:24:01 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A00FA4402CB; Tue, 17 Jul 2018 07:24:01 +0200 (CEST) Date: Tue, 17 Jul 2018 07:24:01 +0200 From: Toerless Eckert To: Michael Richardson Cc: "Owen Friel (ofriel)" , anima@ietf.org Message-ID: <20180717052401.p7be5si2brm3bxsx@faui48f.informatik.uni-erlangen.de> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <20180715071928.4jrzecdfh3gmaveq@faui48f.informatik.uni-erlangen.de> <92b114963bbe465e887b6186b97ecc55@XCH-RCD-012.cisco.com> <3763.1531803050@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3763.1531803050@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 05:24:09 -0000 *arghhh* Thanks, Michael! Not sure how i got that permutation bug into my email. Sorry for the confusion. Cheers Toerless On Tue, Jul 17, 2018 at 12:50:50AM -0400, Michael Richardson wrote: > > Owen Friel (ofriel) wrote: > > I've associated draft-friel-brski-over-802dot11 to anima so folks will > > see it in data tracker. Next time post new work for a particular WG > > with draft---, that will make it happen > > automatically. > > while draft-group-friel-whatever would work, the tradition is that it > should be draft-friel-group-whatever :-) > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Jul 17 04:10:28 2018 Return-Path: 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 A5457130DCD for ; Tue, 17 Jul 2018 04:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1gXIyLW5-GMS for ; Tue, 17 Jul 2018 04:10:25 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2EF130E11 for ; Tue, 17 Jul 2018 04:10:25 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id l25-v6so585816ioh.12 for ; Tue, 17 Jul 2018 04:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+0SorCOYgg5joqnvitlePOoMJABvdC/BjI8Fd8MPcpk=; b=THeLL3VzLNTUbrKIT/cmSxn7tArL4KUMPgArOZSMv3G4/Bl0i+oxrTLS8lGlSNFVKD BCE1Q7Srh2WAvHSp/LPxYNyYDhk0K8YjB3K7Sly22Zxpn79R7nO4Fdp1tt2u+EBsgzwU Z99A9AP/JqeIp9jpBvRu2WOgRkDyujxq9R+lQq1+a9LJf3N4KEWVpG0AI9f4OK9o5cfb yW4OVp5vsAP07LIMtf24c8S/tDKZB0vt5XxSyMs2E9Csep8gRoCSV8x1Z/54gLNAiF4M LsXaPSPlppnF/JjMpPuu9pYNGgsdGzd6URy1+VQAbWa5hi60HgDFAJKRMMqcyZnzBMP7 zeow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+0SorCOYgg5joqnvitlePOoMJABvdC/BjI8Fd8MPcpk=; b=ivecnQkJfm1qY1RLoZdy6zck2HkReFmjy0gX16s5LvhpWPMCmwGTXsJSXFhuwQ+Z8n R6+wIrDzuloqrcH/k3re0yfnZsSg033hy7E4TdMhzOGHih27q87/3JtyyVkMYurMX4Ef K9tpsrK4xYRBJ2xZ1kaIhD40dShQFROCY9YUhHG52nTDIw2oemHun4Hg2/MPHfLvF3/z OdJJI8e+S5BaoUIqKGkkdA3y8MJpiVdhWJNZejldEBCYNZmfsXpZ7L2RFLVAsEgo+OUG mCUsThTp75t50GTw5IWjlw1nZT4RMqZyv3Z2n6cir1dR/pyPVl4wx0FNpkNq0W+EktnB lS8w== X-Gm-Message-State: AOUpUlGLmkEH0uJ1uR6XBZveB/GCtyi3rI0mPZMjktbMqD+2nyhFD5qD XT7KIKlM3Mx5RQCBvpE1maAslw== X-Google-Smtp-Source: AA+uWPwbk7jlOBhYq635Ua7mRMOWyUxycx2q2LNyLaFDuWyoDjurrWG2+IVnG+1FxTsOmfAzb+YISQ== X-Received: by 2002:a6b:9303:: with SMTP id v3-v6mr904417iod.264.1531825824104; Tue, 17 Jul 2018 04:10:24 -0700 (PDT) Received: from [31.133.156.209] (dhcp-9cd1.meeting.ietf.org. [31.133.156.209]) by smtp.gmail.com with ESMTPSA id d10-v6sm291034iob.4.2018.07.17.04.10.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 04:10:23 -0700 (PDT) To: anima@ietf.org References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <3077.1531799945@localhost> From: Brian E Carpenter Message-ID: Date: Tue, 17 Jul 2018 23:10:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3077.1531799945@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 11:10:27 -0000 On 17/07/2018 15:59, Michael Richardson wrote: > > Brian E Carpenter wrote: > > That is so far outside the scope of the autonomic networking > > infrastructure application of BRSKI that I don't see why we'd even > > mention it. It's a case > > that definitely needs to fail hard in the autonomic context. > > Actually, the only thing lacking is the sales channel integration. > If the MASA knows the intended owner, then everything works. Sure. But that is surely out of scope for the purposes of getting the BRSKI document into the RFC Editor queue, which is what we need to do next... > > If we want to extend the scope of BRSKI to cover BYOD on insecure WiFi, I > > think that's for some other WG. > > I don't know if it's for another WG or not, but Owen's document deals with > this... I'm not sure I'd call it "BYOD", exactly... Bring a not-yet-Owned > Device, that you'd like to Own, and get pOwned. And the WiFi is insecure, > because the device doesn't (yet) have accesss to the secure WiFi. Indeed. But I really don't see why ANIMA would handle this. Brian From nobody Tue Jul 17 21:49:39 2018 Return-Path: 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 5AA3E130DEF for ; Tue, 17 Jul 2018 21:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 zfbMjv1dmKzf for ; Tue, 17 Jul 2018 21:49:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8F5128CF3 for ; Tue, 17 Jul 2018 21:49:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8166258C56F; Wed, 18 Jul 2018 06:49:29 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 668944402CB; Wed, 18 Jul 2018 06:49:29 +0200 (CEST) Date: Wed, 18 Jul 2018 06:49:29 +0200 From: Toerless Eckert To: Michael Richardson Cc: "anima@ietf.org" Message-ID: <20180718044929.3oxnsogegzzxtrxm@faui48f.informatik.uni-erlangen.de> References: <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> <3735.1531802975@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3735.1531802975@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] "Rogue" Domains vs audit-only MASA policies X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 04:49:37 -0000 On Tue, Jul 17, 2018 at 12:49:35AM -0400, Michael Richardson wrote: > Toerless Eckert wrote: > > As you point out, we can never be sure that rogue domains are not > > simply accepting devices they do not own. But we can build secure > > Please explain how this works. > A Registrar that accepts a device that has an audit-only MASA is not > rogue. It's doing exactly the right thing. You don't legally own such a pledge just because you claim it on a MASA, but doing so could easily be interpreted to be at least theft of service. > I think the problem is that some people think they are going to > sell $100K BFRs with audit-only policies? Bad Feeble Router ? ;-) > > the MASA should do more than just logging for every device, for > > example if the MASA supports both lightbulbs and core routers, it's > > clear that the MASA policies could be different. > > And given the ability to embed different URLs in the IDevID certificate, > I'd want to run two completely different MASA :-) And Trust Anchors. Epecially when you want to ve free to sell off individual product lines in a large company. Cheers Toerless > > And this "sales" integration could be simply that the MASA requires > > some simple identity for a domains registrar. E.g: verify some > > domains email, credit-card number, ... something easily > > automated and good enough to track back the bad guy with enough > > likelihood. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > From nobody Wed Jul 18 07:23:43 2018 Return-Path: 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 69F86130DFF for ; Wed, 18 Jul 2018 07:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JslVqQ88mNq1 for ; Wed, 18 Jul 2018 07:23:38 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AF3130E14 for ; Wed, 18 Jul 2018 07:23:38 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 72-v6so4382276itw.3 for ; Wed, 18 Jul 2018 07:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:organization:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=B/vh75A1PLJwrY7qSILjGaAQ/QXoK5mbDN/US2eNci4=; b=ItEL/SPMpUwLZUZ0c/rpx84qDnQR5Qo6yMJ4JiAF9mrIVHERrRUvpbEHfYDRGCw3BK fFrZ1i34doKraJ7C7PgvXqIXWQ0N3WjobJWMCUBvQOGeMNqCLpbCD5ah/XWjijBFGX7N 8J2Lem1nz7AgpqM7LLR2deueGePiq0DvQhuey+/Y7jPffq0wB8Jz8X3HPU7vr84T7TXi C8/Th+6llhfN7UWVMBriWW0UeZu8ZyOKuFxiCmK8HXXGEzdovl2QDJkkh0Di2BZ0IXxh zGG/3qEQxqleFOUhWX5jnbdjW70tGnVQAUwOZlw9IOZ9/cd3oWJDY0eU5f1bpOEW5fuS qPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:organization:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=B/vh75A1PLJwrY7qSILjGaAQ/QXoK5mbDN/US2eNci4=; b=BD5LBAyRGIKke/t98J+T4PuHkhMgcuS0RrTNw3m4IhfpnG63v94SzJ/E4IOJ5GTTbV lj042M+vzaEID+4pZBPAdrPrZssTiX8vXm7ngi8sOWL8sYA/381hPCsDKunb/Ri4QtN3 JJBVtarZm1rjm1a/LQFhh+H730BwNNRASKTqlbijJM7UGcwaWvrlFx2Uy3cLkD8CNHU0 q1K/DpxN1dzPS2wH5RNc3zaauqxF4y8FoD2nwJ/Ess4Is7XcKlXIXZRaqz5B7zDTOdVM yDbjZU5Rm7mj+Vd+jmR+YBrRRP4VrVlstdhI2+6zLbaaqjajJ2g6UWM4sso7NItEgRSC XqgQ== X-Gm-Message-State: AOUpUlHG5U0q3lQJBfu6/IVmGzgt19vp+aZgRU6FGbPsqGgkdVLsOmZ7 kl+J/MkBV8uCZYYHH/fil3aJCA== X-Google-Smtp-Source: AAOMgpcEg9PP9AVgvjq3/yBZnZfWCkt/a9aZSY0qgTwUJfDQlNq4Ig1fPF7VfcD81L0xMQ3lKo81Cw== X-Received: by 2002:a24:57cc:: with SMTP id u195-v6mr2158764ita.142.1531923817241; Wed, 18 Jul 2018 07:23:37 -0700 (PDT) Received: from [31.133.141.87] (dhcp-8d57.meeting.ietf.org. [31.133.141.87]) by smtp.gmail.com with ESMTPSA id t14-v6sm1513676iog.5.2018.07.18.07.23.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 07:23:36 -0700 (PDT) To: Toerless Eckert Cc: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: <7a275716-aa05-b14b-8755-f1422295edd7@gmail.com> Date: Thu, 19 Jul 2018 02:23:38 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] ACP admission control X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 14:23:42 -0000 Toerless, I didn't find your admission control "policeman" in the ACP draft. I did find this: > Policies if candidate ACP nodes should receive a domain > certificate or not, for example based on the devices LDevID as in > BRSKI. The ACP registrar may have a whitelist or blacklist of > devices serialNumbers from teir LDevID. To me that's all we really need to say in the ACP protocol spec, and we could say the same thing in BRSKI, but we may need to say more about how this might work in a future draft. Brian From nobody Wed Jul 18 07:37:01 2018 Return-Path: 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 BBF8E130E3C for ; Wed, 18 Jul 2018 07:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 O2WnDvbsVph2 for ; Wed, 18 Jul 2018 07:36:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316891311A6 for ; Wed, 18 Jul 2018 07:36:31 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1009E58C582; Wed, 18 Jul 2018 16:36:27 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EF82F4402CB; Wed, 18 Jul 2018 16:36:26 +0200 (CEST) Date: Wed, 18 Jul 2018 16:36:26 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20180718143626.zzf5g3jh6kfgul62@faui48f.informatik.uni-erlangen.de> References: <7a275716-aa05-b14b-8755-f1422295edd7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a275716-aa05-b14b-8755-f1422295edd7@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] ACP admission control X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 14:36:45 -0000 Thanks, Brian I didn't remember if i had written it as an entity (policeman) or a function, so its written as a function. Yes, i agree. I would be happy for BRSKI if it also said as litte. I was planning to define this function as a YANG procedural call from registry to policy controller in an ANI YANG model. Cheers Toerless On Thu, Jul 19, 2018 at 02:23:38AM +1200, Brian E Carpenter wrote: > Toerless, > > I didn't find your admission control "policeman" in the ACP draft. > I did find this: > > > Policies if candidate ACP nodes should receive a domain > > certificate or not, for example based on the devices LDevID as in > > BRSKI. The ACP registrar may have a whitelist or blacklist of > > devices serialNumbers from teir LDevID. > > To me that's all we really need to say in the ACP protocol spec, and we > could say the same thing in BRSKI, but we may need to say more about > how this might work in a future draft. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 18 08:38:28 2018 Return-Path: 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 101351311AD for ; Wed, 18 Jul 2018 08:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 ylUZyeXRj0SO for ; Wed, 18 Jul 2018 08:38:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CD1130F63 for ; Wed, 18 Jul 2018 08:38:21 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D626E58C582; Wed, 18 Jul 2018 17:38:15 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C390B4402CB; Wed, 18 Jul 2018 17:38:15 +0200 (CEST) Date: Wed, 18 Jul 2018 17:38:15 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Anima WG Message-ID: <20180718153815.aqlhbbiznkzb2l5t@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] draft-ietf-anima-grasp-api discussion X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 18 Jul 2018 15:38:27 -0000 Have still not gotten around to do a more thorough review. The one top of mind thought is that the draft is not well selling the purpose and benefit of GRASP to developers. Whether they want to call their software ASA or not. given enough time i'd probably like to propose text for that purpose, e.g.: -> Grasp is meant to provide a simpler way to develop new "control plane" protocols. Instead of building one-off TLV protocols - Uses CBOR, so programming with appropriate tool chains should be similarily easy as is development of web signaling via JSON (e.g.: in javascript). - GRASP itself is a very constraint set of common message header definitions. - If a new protocol only requires peer-to-peer communication between nodes, it should be easy to use simple GRASP libraries linked to the application. - Typically, GRASP should be run on top of a security layer. If the nodes that need to communicat with each other have for example certificates to mutually authenticate each other, GRASP would run on top of TLS/dTLS using those certificates for mutual authentication. -> If there is underlying infrastructure to suport these functions, GRASP also support discovery mechanisms: - Link-local discovery via link-local multicasted announce/query methods This is easy to support whenever networks support link-local multicasting. - network wide discovery via hop-by-hop flooding with loop prevention. - One infrastructure supporting this is when GRASP is run across the ACP. Something along these lines. However we can pimp it up ;-) Cheers Toerless E.g.: In-Reply-To: <51e53957-4ccd-6d15-713a-6b7f7571ede5@gmail.com> On Mon, Apr 23, 2018 at 11:50:35AM +1200, Brian E Carpenter wrote: > A few comments on the issues raised at IETF 101: > > > 2c. GRASP Application Program Interface (API) - 10min > > 9:55 - 10:05, by Bing Liu, draft-ietf-anima-grasp-api > > [Sheng Jiang] Why "current API lacks support explicit locators for an objective > > " is an issue? It's straightforward to just expose it. And let the ASAs > > decide whether to use it. > > [Bing] We're not very sure whether it is good to open such detailed thing to > > ASAs by the GRASP module. > > I think it is straightforward. In fact, I already added it to the Python > code, as an optional parameter for the register_obj() call. I found a > use for it in one variant of my demo implementation of BRSKI discovery. > > So do people think the API description should include this? > > > [Sheng] Error codes between API and GRASP module and error codes inside the > > GRASP are different. If it is the latter, it should be in GRASP document. > > [Bing] It's inside the GRASP, but it is mostly regarding to ASAs. > > (Errata: it is actually in the API not in GRASP messages.) > > Right. But it's still an open question whether most of the > return codes should be standardised or implementation-dependent. > > The first four IMHO definitely need to be standard: > > ok = 0 #"Call succeeded" > declined = 1 #"Declined" > noReply = 2 #"No reply" > unspec = 3 #"Unspecified error" > > > [Toerless Eckert] The main issue to me would be that the functionality > > expressed over grasp is meant to be application information, so the trouble > > is to establish cross application standards. I try to do that in the DNS-SD > > draft which is trying to say okay whatever application you are if you're > > trying to signal a service then here is a standard for that and I think > > that's the type of functional document not an API document. > > Correct, it's almost an API on top of the API ;-) > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Wed Jul 18 17:27:27 2018 Return-Path: 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 8FD0713107F for ; Wed, 18 Jul 2018 17:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 5bPdPVnlxokJ for ; Wed, 18 Jul 2018 17:27:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DAB8130E4F for ; Wed, 18 Jul 2018 17:27:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D6272008C; Wed, 18 Jul 2018 20:43:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E6DEA1A76; Wed, 18 Jul 2018 20:22:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E49131A54; Wed, 18 Jul 2018 20:22:47 -0400 (EDT) From: Michael Richardson To: Toerless Eckert cc: "anima\@ietf.org" In-Reply-To: <20180718044929.3oxnsogegzzxtrxm@faui48f.informatik.uni-erlangen.de> References: <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> <3735.1531802975@localhost> <20180718044929.3oxnsogegzzxtrxm@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] "Rogue" Domains vs audit-only MASA policies X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:27:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: >> Toerless Eckert wrote: >> > As you point out, we can never be sure that rogue domains are not >> > simply accepting devices they do not own. But we can build secure >>=20 >> Please explain how this works. >> A Registrar that accepts a device that has an audit-only MASA is not >> rogue. It's doing exactly the right thing. > You don't legally own such a pledge just because you claim it on a MA= SA, > but doing so could easily be interpreted to be at least theft of serv= ice. That's an interesting legal concern. (To address Brian's concern about scope: I want the document to go the IESG too, but if this is a potential sticking point with the IESG, then it's better to address it sooner) >> I think the problem is that some people think they are going to >> sell $100K BFRs with audit-only policies? > Bad Feeble Router ? ;-) Big Fu^WFriendly Router. >> > the MASA should do more than just logging for every device, for >> > example if the MASA supports both lightbulbs and core routers, it's >> > clear that the MASA policies could be different. >>=20 >> And given the ability to embed different URLs in the IDevID certific= ate, >> I'd want to run two completely different MASA :-) > And Trust Anchors. Epecially when you want to ve free to sell off > individual product lines in a large company. In the non-constrained (CMS/PKCS7) case, one can make the MASA trust anchor embedded in the pledge as abstract (i.e. with as deep a CA hierarchy) as you like. It's only in the COSE case (which isn't in *this* document), that th= ere are issues with having a signing hierarchy deeper than one level. So I wrote before that we need an operational document for the domain registrar and ACP. Clearly we need operational advice for the manufacturer as well. Maybe someone should author a book... "ANIMA for dummies" =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW0/Z1YCLcPvd0N1lAQKYzwgAnmc+9cIv9znNpahFl3+ThLIknAm61IfM OxzskZnzpQHeCHCaaPQkH4PDhRgAKourYAKC/0eSiZwIkj/f8k8hgcTRalOc6GLo ZEKM++e2YQQo0P1tXrBG7fiHUVePrGfKl985pdwV5vG2upJfqrN987gB2Qb5oHO2 AnAojn/Wg0aT9xjkcKBLqgmT1dJgycg4pXMJF+cwocSqm1qk4HG78IzzriaByNvt G+PefYqZZon8F2Z0XTmdZIiFAyi5MWIBGNaoOURFHDvKS0pI5D1OsIVwE5y2Z8Ni XTVcwi30LZesI6Y0wCgCbxDHTwE8Tg1uVGHj2LNP/6Fk4PmSLf/wUQ== =Sc3R -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 18 17:34:12 2018 Return-Path: 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 34A1013108E for ; Wed, 18 Jul 2018 17:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 qVIbNuxmVZqk for ; Wed, 18 Jul 2018 17:34:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D000B13104D for ; Wed, 18 Jul 2018 17:34:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8925D2008C; Wed, 18 Jul 2018 20:49:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CCB961A76; Wed, 18 Jul 2018 20:29:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CA90B1A54; Wed, 18 Jul 2018 20:29:33 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <4205.1531408349@localhost> <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <3077.1531799945@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 00:34:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> > If we want to extend the scope of BRSKI to cover BYOD on insecure >> > WiFi, I=20 >> > think that's for some other WG. mcr> I don't know if it's for another WG or not, but Owen's document de= als mcr> with this... I'm not sure I'd call it "BYOD", exactly... Bring a mcr> not-yet-Owned Device, that you'd like to Own, and get pOwned. And mcr> the WiFi is insecure, because the device doesn't (yet) have accesss mcr> to the secure WiFi.=20 > Indeed. But I really don't see why ANIMA would handle this. If you say that it's out of scope for bootstrapping-keyinfra, then I agree. I think that it is in scope for ANIMA to specify a way to build and bootstr= ap ACP tunnels over wifi, USB and BTLE (RFC7668). We want to do this because it provides a way for devices in cabinet A of a datacenter to find their partners in adjacent cabinet B. Yes, there might be a 100G fiber between them... but it might be mis-installed, and/or the lambdas might be wrong, etc. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW0/baoCLcPvd0N1lAQIBMQf+PoGzpHojXmLJBtEYSVIRBi8+KSTCJwLd K+oVXoGP1vXBFKEJ7PKFMJ/k895FJzr/NYHs7YgGxfnkWWISmxHg79gLtnnzl6rT WFi0voEy9FkbUg9bCtW5GTaC8Hp8HhXZWraMe4mdcLM+dhO7bSxxxvrJlTUJkUI8 bil4ctVWieg8docZFHfV5rUl+nEJ8SzwCBOo48JnxyaLnaAZ8RyGYii8JTolZLcf 4A8fiybeuJp/7J1jgQGrZDx/KPvI0R4BzQb4wWycq0MH3CNgweOu5ZWZujGN47X1 ysOkYq0Ua5gd1FQ+yBAol6CkBbNxa02DnIUifvQEVqzZQbYl6RaBLQ== =FBRp -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 18 21:54:22 2018 Return-Path: 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 74B32130E76 for ; Wed, 18 Jul 2018 21:54:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ZtUP4F0SNSFY for ; Wed, 18 Jul 2018 21:54:18 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B69130E53 for ; Wed, 18 Jul 2018 21:54:17 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id w6J4rfmV015689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 10:23:41 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id w6J4r8Mo013270; Thu, 19 Jul 2018 10:23:08 +0530 X-AuthUser: anoop Received: from CERTINPC ([223.31.121.163]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id w6J4r3jq020590; Thu, 19 Jul 2018 10:23:06 +0530 From: "Anoop Kumar Pandey" To: "'Michael Richardson'" Cc: "'Toerless Eckert'" , References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> <007501d4182c$6985efc0$3c91cf40$@cdac.in> <2981.1531799379@localhost> In-Reply-To: <2981.1531799379@localhost> Date: Thu, 19 Jul 2018 10:23:02 +0530 Message-ID: <00c001d41f1c$631123c0$29336b40$@cdac.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFAzvEfV8gDGlfdQPkEn1OSJPe5FQHjX3D4AdayjmICGbwlNAJnXrCGAkQ1+OABfsLvMKVcp+lA Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: w6J4r8Mo013270 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.199, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-1.985, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_40 -0.18) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: w6J4rfmV015689 X-CDAC-PUNE-MailScanner-From: anoop@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 04:54:21 -0000 >Presenting a certificate of another party doesn't work. >TLS and other protocols don't just use a certificate, but they use the rel= ated private key to sign part of the transaction. " private key to sign ": That's digital signature. In case of TLS only publ= ic key is used to encrypt and share the symmetric key which is used in late= r communication. No digital signature required. -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]=20 Sent: 17 July 2018 09:20 To: Anoop Kumar Pandey Cc: 'Toerless Eckert' ; anima@ietf.org Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg Anoop Kumar Pandey wrote: > Anyone can present certificate of anyone else (it=E2=80=99s public). = That=E2=80=99s > why I proposed use of digital signature and later verification to > establish the identity of both JRC and Pledge. Presenting a certificate of another party doesn't work. TLS and other protocols don't just use a certificate, but they use the rela= ted private key to sign part of the transaction. --=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 ---------------------------------------------------------------------------= ---------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------------------------------------- From nobody Thu Jul 19 16:09:04 2018 Return-Path: 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 72DA9129C6B for ; Thu, 19 Jul 2018 16:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 y_cH7aWS8omn for ; Thu, 19 Jul 2018 16:08:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB31130DD2 for ; Thu, 19 Jul 2018 16:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4000; q=dns/txt; s=iport; t=1532041739; x=1533251339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tQ3pvSxSUD9uP7++U/fR+WcIWINzAqFBj+EkRmdJ76g=; b=OIxgeRrjbE6hycNc4HQhzDcuEdTybCBWkbcs3oQ2gyBWt3kziBzV+qUl QZZ+4P/oje/3JcFCLUmyU5hWxQ0tzpfYZBdpXtChOq+reD8s064LxiEgO 571vuVU9n0LFFw/Xl38CN48MAnuPvNWDuub2OSjUwHKXyWCxaFVEeDMq1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAACyGVFb/4oNJK1TCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDTWN/KAqDdIgEjDCCDIM4kgMUgWYLGAuBVIJ1AheCbiE?= =?us-ascii?q?0GAECAQECAQECbRwMhTYBAQEEAQEhEToLDAQCAQgRBAEBAQICIwMCAgIlCxQ?= =?us-ascii?q?BCAgCBAENBQiDGYF/D6oDgS6KUYELhl96HoFXPyZqAYJBIi6DGQEBAgGBIQk?= =?us-ascii?q?BCAoBRYJbglUChjmBGBmRfgkChTxPiReBTIQSiBaKP4c3AhEUgSQdOGFxcBU?= =?us-ascii?q?7gmkJhSRUhRSFPm8BAYkygR+BGgEB?= X-IronPort-AV: E=Sophos;i="5.51,376,1526342400"; d="scan'208";a="208286650" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2018 23:08:58 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w6JN8wRS022521 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2018 23:08:58 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Jul 2018 18:08:57 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Thu, 19 Jul 2018 18:08:57 -0500 From: "Owen Friel (ofriel)" To: Anoop Kumar Pandey , "'Michael Richardson'" CC: "'Toerless Eckert'" , "anima@ietf.org" Thread-Topic: [Anima] Revision of scope of MASA in the BRSKI - Reg Thread-Index: AdQU9lov3Wb7Fr4uTsS8ayosQAZGLgBWBpoAAHy30wAAAZCxgAACKK8AAAGGHQABVTGwgABmy+YAABu4NoA= Date: Thu, 19 Jul 2018 23:08:57 +0000 Message-ID: References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> <007501d4182c$6985efc0$3c91cf40$@cdac.in> <2981.1531799379@localhost> <00c001d41f1c$631123c0$29336b40$@cdac.in> In-Reply-To: <00c001d41f1c$631123c0$29336b40$@cdac.in> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.81.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:09:03 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbmltYSA8YW5pbWEtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFub29wIEt1bWFyIFBhbmRleQ0KU2VudDogVGh1cnNk YXkgMTkgSnVseSAyMDE4IDA1OjUzDQpUbzogJ01pY2hhZWwgUmljaGFyZHNvbicgPG1jcitpZXRm QHNhbmRlbG1hbi5jYT4NCkNjOiAnVG9lcmxlc3MgRWNrZXJ0JyA8dHRlQGNzLmZhdS5kZT47IGFu aW1hQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FuaW1hXSBSZXZpc2lvbiBvZiBzY29wZSBvZiBN QVNBIGluIHRoZSBCUlNLSSAtIFJlZw0KDQo+UHJlc2VudGluZyBhIGNlcnRpZmljYXRlIG9mIGFu b3RoZXIgcGFydHkgZG9lc24ndCB3b3JrLg0KPlRMUyBhbmQgb3RoZXIgcHJvdG9jb2xzIGRvbid0 IGp1c3QgdXNlIGEgY2VydGlmaWNhdGUsIGJ1dCB0aGV5IHVzZSB0aGUgcmVsYXRlZCBwcml2YXRl IGtleSB0byBzaWduIHBhcnQgb2YgdGhlIHRyYW5zYWN0aW9uLg0KDQoiIHByaXZhdGUga2V5IHRv IHNpZ24gIjogVGhhdCdzIGRpZ2l0YWwgc2lnbmF0dXJlLiBJbiBjYXNlIG9mIFRMUyBvbmx5IHB1 YmxpYyBrZXkgaXMgdXNlZCB0byBlbmNyeXB0IGFuZCBzaGFyZSB0aGUgc3ltbWV0cmljIGtleSB3 aGljaCBpcyB1c2VkIGluIGxhdGVyIGNvbW11bmljYXRpb24uIE5vIGRpZ2l0YWwgc2lnbmF0dXJl IHJlcXVpcmVkLg0KDQpbb2ZyaWVsXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0 NiNzZWN0aW9uLTcuNC44IGFuZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi10bHMtdGxzMTMtMjgjc2VjdGlvbi00LjQuMyBleHBsYWluIGhvdyB0aGUgY2xpZW50IHVzZXMg aXRzIGNlcnQgcHJpdmF0ZSBrZXkgdG8gc2lnbiB0aGUgVExTIGhhbmRzaGFrZSB0cmFuc2NyaXB0 LiBJZiBjbGllbnQgZG9lc27igJl0IGtub3cgdGhlIHByaXZhdGUga2V5LCBpdCBjYW50IGdlbmVy YXRlIHRoZSBDZXJ0aWZpY2F0ZVZlcmlmeSBhbmQgVExTIGZhaWxzLg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBSaWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZA c2FuZGVsbWFuLmNhXSANClNlbnQ6IDE3IEp1bHkgMjAxOCAwOToyMA0KVG86IEFub29wIEt1bWFy IFBhbmRleSA8YW5vb3BAY2RhYy5pbj4NCkNjOiAnVG9lcmxlc3MgRWNrZXJ0JyA8dHRlQGNzLmZh dS5kZT47IGFuaW1hQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FuaW1hXSBSZXZpc2lvbiBvZiBz Y29wZSBvZiBNQVNBIGluIHRoZSBCUlNLSSAtIFJlZw0KDQoNCkFub29wIEt1bWFyIFBhbmRleSA8 YW5vb3BAY2RhYy5pbj4gd3JvdGU6DQogICAgPiBBbnlvbmUgY2FuIHByZXNlbnQgY2VydGlmaWNh dGUgb2YgYW55b25lIGVsc2UgKGl04oCZcyBwdWJsaWMpLiBUaGF04oCZcw0KICAgID4gd2h5IEkg cHJvcG9zZWQgdXNlIG9mIGRpZ2l0YWwgc2lnbmF0dXJlIGFuZCBsYXRlciB2ZXJpZmljYXRpb24g dG8NCiAgICA+IGVzdGFibGlzaCB0aGUgaWRlbnRpdHkgb2YgYm90aCBKUkMgYW5kIFBsZWRnZS4N Cg0KUHJlc2VudGluZyBhIGNlcnRpZmljYXRlIG9mIGFub3RoZXIgcGFydHkgZG9lc24ndCB3b3Jr Lg0KVExTIGFuZCBvdGhlciBwcm90b2NvbHMgZG9uJ3QganVzdCB1c2UgYSBjZXJ0aWZpY2F0ZSwg YnV0IHRoZXkgdXNlIHRoZSByZWxhdGVkIHByaXZhdGUga2V5IHRvIHNpZ24gcGFydCBvZiB0aGUg dHJhbnNhY3Rpb24uDQoNCi0tIA0KXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9k ZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbIA0KXSAgIE1pY2hhZWwg UmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzICAgICAgICB8IG5ldHdvcmsgYXJj aGl0ZWN0ICBbIA0KXSAgICAgbWNyQHNhbmRlbG1hbi5jYSAgaHR0cDovL3d3dy5zYW5kZWxtYW4u Y2EvICAgICAgICB8ICAgcnVieSBvbiByYWlscyAgICBbIA0KCQ0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClsgQy1EQUMgaXMgb24gU29jaWFsLU1lZGlhIHRvby4gS2luZGx5IGZvbGxvdyB1cyBhdDoNCkZh Y2Vib29rOiBodHRwczovL3d3dy5mYWNlYm9vay5jb20vQ0RBQ0lORElBICYgVHdpdHRlcjogQGNk YWNpbmRpYSBdDQoNClRoaXMgZS1tYWlsIGlzIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVu ZGVkIHJlY2lwaWVudChzKSBhbmQgbWF5DQpjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlDQppbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsIGFuZCBkZXN0cm95DQph bGwgY29waWVzIGFuZCB0aGUgb3JpZ2luYWwgbWVzc2FnZS4gQW55IHVuYXV0aG9yaXplZCByZXZp ZXcsIHVzZSwNCmRpc2Nsb3N1cmUsIGRpc3NlbWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5n IG9yIGNvcHlpbmcgb2YgdGhpcyBlbWFpbA0KaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgYXBw cm9wcmlhdGUgbGVnYWwgYWN0aW9uIHdpbGwgYmUgdGFrZW4uDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBbmltYSBtYWls aW5nIGxpc3QNCkFuaW1hQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2FuaW1hDQo= From nobody Fri Jul 20 06:31:17 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8211213115C; Fri, 20 Jul 2018 06:31:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carl Moberg To: Cc: anima@ietf.org, draft-ietf-anima-constrained-voucher.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153209347046.4248.5071400952066996817@ietfa.amsl.com> Date: Fri, 20 Jul 2018 06:31:10 -0700 Archived-At: Subject: [Anima] Yangdoctors early review of draft-ietf-anima-constrained-voucher-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 13:31:11 -0000 Reviewer: Carl Moberg Review result: Ready with Nits I have reviewed this document as part of the YANG doctors directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document includes two YANG modules: - ietf-cwt-voucher@2018-02-07.yang - ietf-cwt-voucher-request@2018-02-07.yang These are relatively small modules consisting of a single grouping each, and are used to augment single leafs into a grouping from an external module (ietf-voucher). A couple of nits: - The modules use the 'cwt' acronym in their names, but that acronym is only spelled out in the Normative References section. Suggest spelling it out in the description field in the modules and in the draft itself. - Both modules have the same top-level description. Suggest revising the wording to describe the specific content of each module such that they are unique. - I would suggest running both modules through 'pyang -f yang' for consistent formatting. The diffs are related to whitespace, quotations and comments (including a modename in each module) - Sections 6.2.1. and 6.3.1. both provide YANG tree diagrams of the groupings defined. These groupings are defined in RFC8366 and only one of the leafs are defined in the local document. It might be worth pointing this fact out for clarity. From nobody Fri Jul 20 11:28:23 2018 Return-Path: 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 34508130F17 for ; Fri, 20 Jul 2018 11:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 3epmua6F-3nR for ; Fri, 20 Jul 2018 11:28:17 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9795A129385 for ; Fri, 20 Jul 2018 11:28:17 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 014AB58C4B1; Fri, 20 Jul 2018 20:28:13 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E271E4402CB; Fri, 20 Jul 2018 20:28:12 +0200 (CEST) Date: Fri, 20 Jul 2018 20:28:12 +0200 From: Toerless Eckert To: Michael Richardson Cc: "anima@ietf.org" Message-ID: <20180720182812.wlw5swvuak34xxwh@faui48f.informatik.uni-erlangen.de> References: <2bc5e605-db14-dd24-05d7-4170f176b103@cisco.com> <523b2a1dc6654463921771ebb045eda8@XCH-ALN-012.cisco.com> <43bea659-f221-0331-1272-0714279705de@cisco.com> <20180716232958.3k6zg7swvqmlbcrs@faui48f.informatik.uni-erlangen.de> <3735.1531802975@localhost> <20180718044929.3oxnsogegzzxtrxm@faui48f.informatik.uni-erlangen.de> <15565.1531959767@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15565.1531959767@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] "Rogue" Domains vs audit-only MASA policies X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:28:21 -0000 On Wed, Jul 18, 2018 at 08:22:47PM -0400, Michael Richardson wrote: > >> Please explain how this works. > >> A Registrar that accepts a device that has an audit-only MASA is not > >> rogue. It's doing exactly the right thing. > > > You don't legally own such a pledge just because you claim it on a MASA, > > but doing so could easily be interpreted to be at least theft of service. > > That's an interesting legal concern. > (To address Brian's concern about scope: I want the document to go the > IESG too, but if this is a potential sticking point with the IESG, > then it's better to address it sooner) I don't think Brian raised an issue aobut this point. The only new issue raised was the broken reference to the section about authorizing the pledge by the domain. See the new github issue i opened. The audit-only log is IMHO a great new option to explore and see where it would fall out on the legal side if there is abuse (claims made by non-legal owners). > >> > the MASA should do more than just logging for every device, for > >> > example if the MASA supports both lightbulbs and core routers, it's > >> > clear that the MASA policies could be different. > >> > >> And given the ability to embed different URLs in the IDevID certificate, > >> I'd want to run two completely different MASA :-) > > > And Trust Anchors. Epecially when you want to ve free to sell off > > individual product lines in a large company. > > In the non-constrained (CMS/PKCS7) case, one can make the MASA trust anchor > embedded in the pledge as abstract (i.e. with as deep a CA hierarchy) as you > like. It's only in the COSE case (which isn't in *this* document), that there > are issues with having a signing hierarchy deeper than one level. I think we're in violent agreement. > So I wrote before that we need an operational document for the domain > registrar and ACP. Clearly we need operational advice for the manufacturer > as well. Maybe someone should author a book... "ANIMA for dummies" Well, this is an OPS WG, so its perfectly fine to elaborate on informational operational aspects in our document. Even BCP. And if you find a formal language to express operational processes i bet we could even go standard ;-) Cheers Toerless > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Jul 20 14:05:47 2018 Return-Path: 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 409E6130E4C for ; Fri, 20 Jul 2018 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dRANNT1Tgpfq for ; Fri, 20 Jul 2018 14:05:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C49130DFA for ; Fri, 20 Jul 2018 14:05:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D64D52008D; Fri, 20 Jul 2018 17:21:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 57D1B263F; Fri, 20 Jul 2018 17:01:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5574AD1; Fri, 20 Jul 2018 17:01:08 -0400 (EDT) From: Michael Richardson To: "Anoop Kumar Pandey" cc: "'Toerless Eckert'" , anima@ietf.org In-Reply-To: <00c001d41f1c$631123c0$29336b40$@cdac.in> References: <007b01d414f8$313d68a0$93b839e0$@cdac.in> <5778.1530989932@localhost> <20180710062956.qa5gllnk3m4jlkgp@faui48f.informatik.uni-erlangen.de> <004901d4181d$b02f8710$108e9530$@cdac.in> <20180710081634.wnyekmphisoqq2ro@faui48f.informatik.uni-erlangen.de> <007501d4182c$6985efc0$3c91cf40$@cdac.in> <2981.1531799379@localhost> <00c001d41f1c$631123c0$29336b40$@cdac.in> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Revision of scope of MASA in the BRSKI - Reg X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 21:05:46 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Anoop Kumar Pandey wrote: >> Presenting a certificate of another party doesn't work. >> TLS and other protocols don't just use a certificate, but they use t= he >> related private key to sign part of the transaction.=20 > " private key to sign ": That's digital signature. In case of TLS only > public key is used to encrypt and share the symmetric key which is us= ed > in later communication. No digital signature required. And, in order to encrypt something "to" the public key, the private key use= d. This might help: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/= sy10670_.htm =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW1JNkYCLcPvd0N1lAQKO0Qf9EWY549xTGvqfNdJbsPeCWmBBPyTvCt5v NNDh9TTH7JSo2D0MPPgtgwcf4N9woDnhwYLSgv55A1gb+nJwugmhf2yLg4sYDQGl Xthxxtfa0afnXMBN5+QGXaUZBCsgPjF4jCVcK/tO9JOPbPS6ioWaj1J8SSMOq2E8 ZCacL/O9vgt3UKZlWpp92h5wAczkZrqGmxBuS8U9C0BtesI5sS8gqsx5TDbIdtHR E3GgsjzsDN1NdWITUNxBpO5rNVIz3fDAfNgE9YwKz2LHNd+nCfDLnRJbEmsWqvWp M+6vF3biBMD2KRotRys1PQht6SIW3KCJCZbBdFNZjWwBWMxuBf4pKw== =IaEV -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 20 15:03:03 2018 Return-Path: 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 3602C131115; Fri, 20 Jul 2018 15:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 GJZf63QcczM5; Fri, 20 Jul 2018 15:02:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40FA1310E9; Fri, 20 Jul 2018 15:02:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DDD32008D; Fri, 20 Jul 2018 18:18:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 77B99263F; Fri, 20 Jul 2018 17:58:16 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 757CFD1; Fri, 20 Jul 2018 17:58:16 -0400 (EDT) From: Michael Richardson To: Carl Moberg cc: yang-doctors@ietf.org, anima@ietf.org, draft-ietf-anima-constrained-voucher.all@ietf.org In-Reply-To: <153209347046.4248.5071400952066996817@ietfa.amsl.com> References: <153209347046.4248.5071400952066996817@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] Yangdoctors early review of draft-ietf-anima-constrained-voucher-00 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 22:02:59 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Carl Moberg wrote: > I have reviewed this document as part of the YANG doctors directorate= 's > ongoing effort to review all IETF documents being processed by the > IESG. These Thank you! > A couple of nits: > - The modules use the 'cwt' acronym in their names, but that acronym = is > only spelled out in the Normative References section. Suggest spelling > it out in the description field in the modules and in the draft > itself. We changed it to constrained in a version which is probably not yet published, because it was only change. > - Both modules have the same top-level description. Suggest revising > the wording to describe the=20 > specific content of each module such that they are unique. > I would suggest=20 > running both modules through 'pyang -f yang' for consistent > formatting. The diffs are related to whitespace, quotations and > comments (including a modename=20 > in each module) Generally, my experience is that one has to get the wrapping of the YANG module "short" enough so that it does not exceed the .txt format output when embedded in the RFC. Does pyang -f yang help here? > - Sections 6.2.1. and 6.3.1. both provide YANG tree diagrams of > the groupings defined. These groupings are defined in RFC8366 and only > one of the leafs are defined in the local document. It might be worth > pointing this fact out for clarity. okay, I'll add a note about that. https://github.com/anima-wg/constrained-voucher/commit/6d274f13e3c553efc714= c0f06c195f924ad880ff =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW1Ja9YCLcPvd0N1lAQLvowf/TVkcGtat1bqcme5eFC0KDxiVFcteIm9D 4UwY3HeZKqIy6gzFUAPEA1pcaricjQx5g7LMTB4XkYW2F5GH6GngRL9h4LuSZEJ6 E9rN5di3zjOodnoLvHOxsKAc/Our1edgJnMvMxC25K6Ri2GXxXbSvW71BKcYbtr7 +dN9NXQ00m2xgRMBnjjYvA9fe6w8lFaU9lIHoIuYk4tysoL497JlnVbB+HT8ZnNm k9rWqMZIYTyoeTIQDchy4lfqqujAheY43qs3dw2SK1uTxQbYrBgges9me+K9uNKw fZ2hQvV8Ii4em1XMSUCmTJi2BEVrE6T0/T+m/2E9mNwVmG2iUD/ukA== =Mr57 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 22 19:14:48 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1531413109A; Sun, 22 Jul 2018 19:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153231208604.23012.10077186169272862057@ietfa.amsl.com> Date: Sun, 22 Jul 2018 19:14:46 -0700 Archived-At: Subject: [Anima] Secdir telechat review of draft-ietf-anima-autonomic-control-plane-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 02:14:46 -0000 Reviewer: Liang Xia Review result: Has Issues I have provided the secdir review on -13 of the draft. I have the same conclusion as before: this document is well-written and considers security issues carefully throughout the whole architecture. But I don't see your author's response to my -13 secdir review, so please double check you had addressed all my previous comments and nits. Besides above, I think the draft is ready. From nobody Mon Jul 23 11:58:19 2018 Return-Path: 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 EC3FD130E02 for ; Mon, 23 Jul 2018 11:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 Q4qrrBrPIV6R for ; Mon, 23 Jul 2018 11:58:15 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50773130DD9 for ; Mon, 23 Jul 2018 11:58:14 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B09A958C4AF for ; Mon, 23 Jul 2018 20:58:10 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9E3E14402CB; Mon, 23 Jul 2018 20:58:10 +0200 (CEST) Date: Mon, 23 Jul 2018 20:58:10 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20180723185810.hc6kva3sdlmhvibt@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] ANIMA FYI: presentation for DINRG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 18:58:18 -0000 DINRG is a new proposed IRTF research group "Decentralized Internet INfrastructure Research Group". On friday last week at te DINRG meeting, i presented my view of how DINRG and ANIMA could collaborate, explaining also how ANIMA was born out of work done at NMRG. In summary, i am hoping that folks working on DINRG items might have input to our ASA/Autonomic Function technologies. Slides are here: https://datatracker.ietf.org/meeting/102/materials/slides-102-dinrg-dinrg-anima-toerless-eckert-00 For our existing ANI it may make sense to think about more decentralized approaches to the current bootstrap protocol/mechanisms that all are based on single-domain decision points such as CA, policy managers and registrars. I've summarived that existing bootstrap model on slide 10 and brainstormed multi-administrative-domain/decentralied approaches using the current thinking about distributed ledgers, decision making and blockchains on slide 11. Comments welcome! Cheers Toerless From nobody Mon Jul 23 13:04:36 2018 Return-Path: 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 9374B130E25 for ; Mon, 23 Jul 2018 13:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 UdXw75Ws9qTP for ; Mon, 23 Jul 2018 13:04:32 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA1612F1A6 for ; Mon, 23 Jul 2018 13:04:32 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 10A3458C4AF for ; Mon, 23 Jul 2018 22:04:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id F26CE4402CB; Mon, 23 Jul 2018 22:04:27 +0200 (CEST) Date: Mon, 23 Jul 2018 22:04:27 +0200 From: Toerless Eckert To: anima@ietf.org Message-ID: <20180723200427.xgswy522jrhwnwqd@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] FYI: Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 20:04:36 -0000 Thanks, Sean Let me add the LAMPS working group mailing list so we have more eyes on this. [blind copying anima WG mailing list so WG members interested in this disus can subscribe to LAMPS WG mailing list (spasm@ietf.org) ] Inline replies/Q's to your analysis at the end of this mail. To repeat and expand the goal of this discussion from what i was saying that the LAMPS mike in IETF102: - In ANIMA draft-ietf-anima-autonomic-control-plane (ACP), we use EST (RFC7030) to renew certificates. We would like to make installations with short-lived certificates work reliable, but devices may be disconnected longer than the short-lived time, so renewal may only happen after the cert is expired. - In the ANIMA WG, we seem to not be clear on the rules for renewing expired certs. RFC7030 section 3.3.2 sounds as if it mandatory for the EST server to validate the client certificate according to RFC5280, so we where concluding that an expired client certificate might not be something that the client could use if he wanted to comply to all IETF PKIX regulations. [ technically it would of course be fine to us the expired client certificate, and it might be necessary to use it because for renewals, the certificate to be renewed must be carried in the TLS authentication (if i understand it correctly, it would not be re-signaled inside the EST connection because the EST server wants to have prof of posession of the cert by the client, and thats done by TLS and does not need to be duplicate). ] - Yaron reminded me that in draft-ietf-acme-star certificates renewed certificates are not handled as an entity that requires authentication of the recipient but instead something that can be pre-created and cached in various places to overcome problems with nomadic connectivity. This to me looks like quite different from the approach by EST. - My thinking is somewhat in the middle between what i think EST says and what draft-ietf-acme-star says: - In EST, you do want identification with the pre-existing (expired) certificate. - The proof of posession of the expired certificate can help the registrar to determine aliveness of the client and reset any policy that could exist to determine whether the client is dead (after a long enough period of time) and stop reneweing certificates. - The proof of posession is also necessary IMHO when rekeying is required. - Which brings us back to Seans analysis of existing PKIX texts: (inline) On Mon, Jul 23, 2018 at 08:08:10AM -0400, Sean Turner wrote: > Toreless, > > I do not believe there is any prohibition against the use of expired or even revoked certificates for renew/rekey in the PKIX suite of RFCs. That wold be great. > The path validation algorithm in 5280 does consider whether the certificate is revoked/expired, but does hard fail on that status. But that would contradict your above statement, would it not ? With RFC7030 3.3.2 requiring RFC5280, it would have to fail for expired certificates. No ? > There???s nothing in the management protocols 2986 (PKCS#10), 5272 (CMC), and 4210 (CMP) about it either. Ok, so we can ignore those docs ;-) > But, the real reason it might be allowed is based on the CP (Certificate Policy) and that follows 3647; this RFC does have sections on "Identification and authentication for re-key after revocation???; I say ???might??? here because it is a policy decision (some CPs I???ve written allow it some do not). Ok, so RFC3647 does seem to not describe the case of a purely expired certificate, but just the re-keying of a certificate that was revoked, and even in that case it would be permitted based on a policy, so it would be ok. Seems to leave 5280 as the existing doc standing in the way ? If so, how to most easily fix this ? Cheers Toerless > spt > > > On Jul 19, 2018, at 17:29, Toerless Eckert wrote: > > > > Sean, > > > > wrt to the reply you gave me in Lamps wrt to: > > "Do existing authoritative IETF PKIX documents permit to use expired > > certificates as authentication for certificate renewal" > > > > Could you please point us to the reference that you mentioned whether > > or not this is allowed by current PKI standards ? > > > > Note that specifically in the case of BRSKI, we are talking about > > using an expired client cert in a TLS connection to an RA, so that > > TLS connection would only be used for renewal. > > > > Aka: I am not even sure if the expired cert would need to be "permitted" > > for this operartion by a PKIX document and/or by TLS. > > > > To me this is key missing piece to make ANIMA enrollment/renewal > > rock-solid in the face of non-contiguous full reachability of RA/CA. > > > > If we know and can point to how this is permissible it should > > be simple for us to have short informative text explaining this > > crucial option. > > > > Thanks! > > Toerless From nobody Mon Jul 23 14:16:08 2018 Return-Path: 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 1B6C4130F63; Mon, 23 Jul 2018 14:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 N42mQzEuFfA5; Mon, 23 Jul 2018 14:16:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DD6C130E73; Mon, 23 Jul 2018 14:16:04 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id CC4FD58C4AF; Mon, 23 Jul 2018 23:15:59 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 954674402CB; Mon, 23 Jul 2018 23:15:59 +0200 (CEST) Date: Mon, 23 Jul 2018 23:15:59 +0200 From: Toerless Eckert To: Liang Xia Cc: secdir@ietf.org, anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org Message-ID: <20180723211559.f2u4ydl55ns5yhgo@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Secdir early review of draft-ietf-anima-autonomic-control-plane-13 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 21:16:07 -0000 Hi Frank, Mea maxima culpa. Your -13 review below was probably overlooked by me when integrating all received feeedbac from -13 into 14/15/16, although it looks more as if i did fix most of the stuff from your review but then forgot to send a reply. This is integretated into -17, i didn't push a new version up, but you can check it at: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-17.txt Replies inline below Cheers Toerless On Fri, Feb 23, 2018 at 07:28:05PM -0800, Liang Xia wrote: > Reviewer: Liang Xia > Review result: Has Issues > > In general, this document is well-written and considers security issues > carefully throughout the whole architecture. Thanks! > > nits: > Abstract: /or not misconfigured/or misconfigured/ Was fixed n -16. > the fifth paragraph of section 6.1: the last ")" is redundant, therefore can be > deleted Fixed. > some section titles don't comply the rule of starting from a capital letter Hmm.. checked -13 and -16 but could not find anything besides: (-16) A.3.3.2 mDNS and ... This starts with small letter because "mDNS" is a unique name with a lower letter, i think this is correct. If we're unsure, RFC editor would be best to resolve later on. (-16) Titles are all draft names and this section will be removed anyhow for RFC. > section 6.5 > /("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", > see [RFC7296] > /("IP security", see [RFC4301] and "Internet Key Exchange protocol version 2", > see [RFC7296])/ What change do you suggest, looks identical ? > suggestion: > all the Figures (e.g., Figure 1,2...) should have a title for explanation Done in -16. > section 2, please update the last paragraph to reference RFC8174 to indicate > that lowercase versions of the keywords are not normative Done in -16. > Section 11 (Security Considerations) Since section 9.2 has described the > self-protection properties of ACP well, it may be useful in this section to > mention them as a whole. Hmm.. Didn't want to reiterate too much text that is already written out in the document, but instead inserted a reference to section 9.2 into the security section. From nobody Mon Jul 23 16:30:06 2018 Return-Path: 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 E613B130F32 for ; Mon, 23 Jul 2018 16:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 czXy299d-ejA for ; Mon, 23 Jul 2018 16:30:02 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2AF130E91 for ; Mon, 23 Jul 2018 16:30:02 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id r1-v6so1444770pgp.11 for ; Mon, 23 Jul 2018 16:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MfIMgGFRBbDbIGVdmcH4BLCDo866PKYYreXnBP8UdCA=; b=LSB6d/dDqeWZL7qFBsXbp2rB9uOzws5AHnFOXOw3T6acqTkFIWkHjxiz87oTQJwJ6K 7osCM0mDyf+WtSgkXK3SvykiQntZX+/5FZryQU0dU6cRrJ+Ic9Fh1F61xz+JZBi2pzyJ mBbBz8MEEZPIlqOv87ogNbVZzAYU5f2pbLePs+hlUm+OujDE9+oX78P7MSVOAAAYVrHP cj/8J9SJc4pthPWNrBEiAyC+IlnFbYtWNxiCtuext/ZIPGz7ZkjUrzZuucSumUNQ0DCV 8ZRFdamWhi7Sq4+iThBInAVGkwLKg/R4mRy1KnPlmvl0v64TAuhIKN3dOi6bNaJZbkur Z96g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MfIMgGFRBbDbIGVdmcH4BLCDo866PKYYreXnBP8UdCA=; b=J0Q78XfHoR3NBfk3YvIIalsdfmx9YTm2m/BH2IsHBFJDjuCMd3owFjcUrI77F5wzr0 KDAK7U6kTBTRhjaC7paiUOkU1Efy5E7cU7RxySPLd6D/xAOPu1LvHJ3wGpsHb4f41AnX d+kC9dywkeM5KIhnbS+ZErIe3z6Yx7QfDauz7xQQ01bQlo5ChqONv43/wdj5pbK6NyAW lBubcR4M8423Hu6lcJEg312+X6t4ke1nXY+hCCcQXkN6foECXtWaiDt+0hkVWZ3OPIdY yc6AZJyJXAy+rI0i+wm997Y+R70ToGUefjvpzX6devHbBJ5RqSVA40382NtLStlydhkY ESog== X-Gm-Message-State: AOUpUlFm1Q3xIxfvpNRUzqhqjmp+s8MX6DqWfg8cavrpTV0yDPEIJ0Sd 4J2D36q706FQYZOuNfyyWthScmG5 X-Google-Smtp-Source: AAOMgpeDowzyeHfa5o2CKQsL4YuD5qgXkMd0D3SGzeIx1ywkqQG7o4anGXeXLB6nZaF3sJm08G5kTw== X-Received: by 2002:a63:1b17:: with SMTP id b23-v6mr14101707pgb.275.1532388602034; Mon, 23 Jul 2018 16:30:02 -0700 (PDT) Received: from [130.216.38.134] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.134]) by smtp.gmail.com with ESMTPSA id i62-v6sm14806240pge.66.2018.07.23.16.29.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 16:30:01 -0700 (PDT) To: Toerless Eckert References: <20180723185810.hc6kva3sdlmhvibt@faui48f.informatik.uni-erlangen.de> Cc: anima@ietf.org From: Brian E Carpenter Message-ID: <54a529e2-3d19-99f1-bb5b-73cbc87f5192@gmail.com> Date: Tue, 24 Jul 2018 11:29:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180723185810.hc6kva3sdlmhvibt@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ANIMA FYI: presentation for DINRG X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 23:30:05 -0000 Toerless, Good slides. Unfortunately an agenda clash meant that I could not attend DINRG. Can you tell us whether there was any discussion after your presentation? Regards Brian On 24/07/2018 06:58, Toerless Eckert wrote: > DINRG is a new proposed IRTF research group > "Decentralized Internet INfrastructure Research Group". > > On friday last week at te DINRG meeting, i presented my view > of how DINRG and ANIMA could collaborate, explaining also how > ANIMA was born out of work done at NMRG. > > In summary, i am hoping that folks working on DINRG items might > have input to our ASA/Autonomic Function technologies. > > Slides are here: > > https://datatracker.ietf.org/meeting/102/materials/slides-102-dinrg-dinrg-anima-toerless-eckert-00 > > For our existing ANI it may make sense to think about more decentralized > approaches to the current bootstrap protocol/mechanisms that all are > based on single-domain decision points such as CA, policy managers > and registrars. I've summarived that existing bootstrap model on slide 10 > and brainstormed multi-administrative-domain/decentralied approaches > using the current thinking about distributed ledgers, decision making > and blockchains on slide 11. > > Comments welcome! > > Cheers > Toerless > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Jul 24 15:45:17 2018 Return-Path: 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 6CC44131218 for ; Tue, 24 Jul 2018 15:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qreCEkVMUr1B for ; Tue, 24 Jul 2018 15:45:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3471A131217 for ; Tue, 24 Jul 2018 15:45:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 728A120090 for ; Tue, 24 Jul 2018 19:01:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D2B0E17FB; Tue, 24 Jul 2018 18:45:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CEA7517C3 for ; Tue, 24 Jul 2018 18:45:11 -0400 (EDT) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] functional differences for constrained voucher X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 22:45:16 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Toerless asked, aside from the encoding differences, are there differences between CMS-signed JSON and COSE-signed CBOR in voucher definitions. a) RFC8366 vouchers can contain additional anchors (see other email) and thus can have intermediate CAs. =20=20=20 b) RFC8366 vouchers are pinned to a PKIX key, while constrained vouchers are (optionally) pinned to a Raw Public Key. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW1er94CLcPvd0N1lAQIf5ggAsKbWMW3mVEckO1PCqgKUU4ADimiEpq1X 9vxXDPIn6IMVoxVOkCJY5sDe/DYktRAuxCaOppx3V9QA8rf+8rakS1iWXgM6xALe GsIsBRjRhyZtJTbYindmWzbuL8mM7Da/rv7ISrkvePAe2D9JPUoJtsMl36VWCRHV RNNbmyF9wRu/puSEAXVSZY3NM0azxbjXMZP4d7J3B36OCqiV6jkSe0Uo/d4q+4m6 CeCa0b2gpwqZ2FNUcyyN4wyyjVuS16fqfiKWz1ObVU2YcBCFE/RrsgbfD5Xuw2H8 7MXUWQ5VTqjHbzGO3uDy3YQWJVSU5Vm+1CwyBd9hW+sm2zzZPcrsMA== =xrzU -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 24 18:22:44 2018 Return-Path: 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 DD044130F0A; Mon, 23 Jul 2018 12:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 FH5QrItoOSJT; Mon, 23 Jul 2018 12:46:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754E3130EE2; Mon, 23 Jul 2018 12:46:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 46C0D58C4AF; Mon, 23 Jul 2018 21:46:23 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 33F6E4402CB; Mon, 23 Jul 2018 21:46:23 +0200 (CEST) Date: Mon, 23 Jul 2018 21:46:23 +0200 From: Toerless Eckert To: Sean Turner , spasm@ietf.org Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org Message-ID: <20180723194623.7niwhsz4tnigwern@faui48f.informatik.uni-erlangen.de> References: <20180719212936.mroidiansyiurjra@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: X-Mailman-Approved-At: Tue, 24 Jul 2018 18:22:43 -0700 Subject: [Anima] Renewing (short lived) certs with EST (RFC7030) [was: Re: Sean: Permissibility of expired cert renewal] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 19:46:30 -0000 Thanks, Sean Let me add the LAMPS working group mailing list so we have more eyes on this. [Bcc anima WG mailing list so WG members interested in this disus can subscribe to LAMPS WG mailing list (spasm@ietf.org) ] Inline replies/Q's to your analysis at the end of this mail. To repeat and expand the goal of this discussion from what i was saying that the LAMPS mike in IETF102: - In ANIMA draft-ietf-anima-autonomic-control-plane (ACP), we use EST (RFC7030) to renew certificates. We would like to make installations with short-lived certificates work reliable, but devices may be disconnected longer than the short-lived time, so renewal may only happen after the cert is expired. - In the ANIMA WG, we seem to not be clear on the rules for renewing expired certs. RFC7030 section 3.3.2 sounds as if it mandatory for the EST server to validate the client certificate according to RFC5280, so we where concluding that an expired client certificate might not be something that the client could use if he wanted to comply to all IETF PKIX regulations. [ technically it would of course be fine to us the expired client certificate, and it might be necessary to use it because for renewals, the certificate to be renewed must be carried in the TLS authentication (if i understand it correctly, it would not be re-signaled inside the EST connection because the EST server wants to have prof of posession of the cert by the client, and thats done by TLS and does not need to be duplicate). ] - Yaron reminded me that in draft-ietf-acme-star certificates renewed certificates are not handled as an entity that requires authentication of the recipient but instead something that can be pre-created and cached in various places to overcome problems with nomadic connectivity. This to me looks like quite different from the approach by EST. - My thinking is somewhat in the middle between what i think EST says and what draft-ietf-acme-star says: - In EST, you do want identification with the pre-existing (expired) certificate. - The proof of posession of the expired certificate can help the registrar to determine aliveness of the client and reset any policy that could exist to determine whether the client is dead (after a long enough period of time) and stop reneweing certificates. - The proof of posession is also necessary IMHO when rekeying is required. - Which brings us back to Seans analysis of existing PKIX texts: (inline) On Mon, Jul 23, 2018 at 08:08:10AM -0400, Sean Turner wrote: > Toreless, > > I do not believe there is any prohibition against the use of expired or even revoked certificates for renew/rekey in the PKIX suite of RFCs. That wold be great. > The path validation algorithm in 5280 does consider whether the certificate is revoked/expired, but does hard fail on that status. But that would contradict your above statement, would it not ? With RFC7030 3.3.2 requiring RFC5280, it would have to fail for expired certificates. No ? > There???s nothing in the management protocols 2986 (PKCS#10), 5272 (CMC), and 4210 (CMP) about it either. Ok, so we can ignore those docs ;-) > But, the real reason it might be allowed is based on the CP (Certificate Policy) and that follows 3647; this RFC does have sections on "Identification and authentication for re-key after revocation???; I say ???might??? here because it is a policy decision (some CPs I???ve written allow it some do not). Ok, so RFC3647 does seem to not describe the case of a purely expired certificate, but just the re-keying of a certificate that was revoked, and even in that case it would be permitted based on a policy, so it would be ok. Seems to leave 5280 as the existing doc standing in the way ? If so, how to most easily fix this ? Cheers Toerless > spt > > > On Jul 19, 2018, at 17:29, Toerless Eckert wrote: > > > > Sean, > > > > wrt to the reply you gave me in Lamps wrt to: > > "Do existing authoritative IETF PKIX documents permit to use expired > > certificates as authentication for certificate renewal" > > > > Could you please point us to the reference that you mentioned whether > > or not this is allowed by current PKI standards ? > > > > Note that specifically in the case of BRSKI, we are talking about > > using an expired client cert in a TLS connection to an RA, so that > > TLS connection would only be used for renewal. > > > > Aka: I am not even sure if the expired cert would need to be "permitted" > > for this operartion by a PKIX document and/or by TLS. > > > > To me this is key missing piece to make ANIMA enrollment/renewal > > rock-solid in the face of non-contiguous full reachability of RA/CA. > > > > If we know and can point to how this is permissible it should > > be simple for us to have short informative text explaining this > > crucial option. > > > > Thanks! > > Toerless From nobody Wed Jul 25 10:39:57 2018 Return-Path: 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 0743B130E82 for ; Wed, 25 Jul 2018 10:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 jlNdtUnLpMCB for ; Wed, 25 Jul 2018 10:39:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C1C129385 for ; Wed, 25 Jul 2018 10:39:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A27E20008; Wed, 25 Jul 2018 13:56:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D41A967; Wed, 25 Jul 2018 13:39:51 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D09C264; Wed, 25 Jul 2018 13:39:51 -0400 (EDT) From: Michael Richardson To: "Brian E. Carpenter" , anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima] limited domain X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 25 Jul 2018 17:39:55 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Just watching the recording... Like Toerless, I am not sure what you are proposing to do exactly. How does what we need to do differ from what MIF (failed?) to do? I was hoping that the ID would tell me more, but it didn't manage that yet. (When you say, which "node" is a member of the domain, I think you mean to say, "which interface on a node" is a member of the domain... ?) =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW1i15ICLcPvd0N1lAQIrZQgAgyiEJ97MQy7K13xFhrcvYTWwTvfERDJh q9eozgvU22vN1qQ/RoUZFscVuebKQm8qWk55RJ5YT1fklfBr6PiheN22vtCeBSJ9 noPGjBhxv0HkVzEkie+3SJ42fsmIjM/rJY46RVYDFuSGr83Ntp+0TpgdOAV+bDlA WnofwEK3Xbhmdk0wavnNYATsR1uvRwT+D7XyZYp8XNBhbdA4CHgQiYr6RrE3um9h FSHFu1Y/qpdUJ2W/Vpv05a5puTlqbjRzFQot1M1AHfhB248lim0o9VvfnTPWPo7z eri+RRC/BaakGlD1xG6XRSCHvSnqYRDZYm8Id+MaR213ig1RYX7wCw== =aZDR -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 25 13:37:10 2018 Return-Path: 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 09D82130E0A for ; Wed, 25 Jul 2018 13:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gT1aIYWvzebL for ; Wed, 25 Jul 2018 13:37:06 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04718130DE4 for ; Wed, 25 Jul 2018 13:37:06 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id y5-v6so6046390pgv.1 for ; Wed, 25 Jul 2018 13:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=eP83DIae4fJ9V4zgw9hcSA8fRlws7bpjcXuLMvHhyj4=; b=PHSvdf1M7kfeSWVmQJEqZk+tc5xFg+N9K0oKvEtuhL2rYcJYbNmnu/E0GeJStb1fow KlJXoxUjxLneDrppeHf6x/Ehc+xHMOnYp70SoooaIcWWpo1cy+k9ZjyJTbMhQqiJGQ8Q A4jk5ilYunRHMvqH0cD7f6fVJ2IuouJq9KN72vWJeAD3mzNk7PI4/rJrs6lcvliaRWPq RKKVQ3+VaXWVQTRw1Kc8TdABkmQzyrCr8Jw3Nrf8EyKNtZPcbwg2L+wSr3sOIAsaIUwR tiJlS/eNR2/oq4cNGBiGX00PYC3ygufu0utaRuJVt5Q1qC/RyiNCPQrHLPwZkGEo2dbq FaFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eP83DIae4fJ9V4zgw9hcSA8fRlws7bpjcXuLMvHhyj4=; b=bvzQZ20abujXct4QJra3pUTusFuyrzvLAO1y9HUvagousdsfpslTv6oOGnBKAE5Fje jWPAoQDkR+BEhpVCnDAH3xxkEWiPFB9nZIJ+jfMa8tvPh8TZ4PHG1ulTFWQwSReTrz68 61qDBSyDUJZmMJDMRE82E7vZzFMDlEPWGJKTLRTGfNk1kotj2MQuz3h7EdS1l9JC5X1T gdsWQdgZFXVK8Yw/+/XeR3nLbo5kdnuiLnn2QBOwpV/OfmM0O8iOMqVc7VxWdXTufslW wlhdyLLQTb5a0WjGq1Y8V7n/zCsURZtd1sEn0qH/J3zWgMZM0KAQwaWpiMV4vBiMlHHT iayA== X-Gm-Message-State: AOUpUlES3N652oxeOXunIT4joHWvXpFR6xc0W/hp0XPpOazo1GRFug82 /In0JtyPXcHxKbSJFER4Yp/KYwdS X-Google-Smtp-Source: AAOMgpcsVnDeWBJnpTzIzyAU2hJFO2KoN6aoo5fS3mbAxbSpAqa90sUWpn9p8t8X9ytLB7USNiEe7g== X-Received: by 2002:a63:f756:: with SMTP id f22-v6mr21602973pgk.289.1532551025183; Wed, 25 Jul 2018 13:37:05 -0700 (PDT) Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id f67-v6sm26326323pfe.75.2018.07.25.13.37.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 13:37:04 -0700 (PDT) To: Michael Richardson , anima@ietf.org References: <15259.1532540391@localhost> From: Brian E Carpenter Message-ID: <2687e245-88da-b165-af83-d78e90a189b0@gmail.com> Date: Thu, 26 Jul 2018 08:37:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <15259.1532540391@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] limited domain X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 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, 25 Jul 2018 20:37:08 -0000 On 26/07/2018 05:39, Michael Richardson wrote: > > Just watching the recording... > > Like Toerless, I am not sure what you are proposing to do exactly. > How does what we need to do differ from what MIF (failed?) to do? Well, MIF did produce PVDs, but IMHO that was a completely different problem space. I think the correct question is how does the problem differ from the one solved by BRSKI+ACP, plus the missing bit of Anima, which is how to identify roles within the ANI and where the edge of the autonomic domain is. Our feeling is that this is a more general concept than just autonomics. (For example: Segment routing assumes that we know where the SR domain edge is. DETNET assumes that we know where the domain edge is. Diffserv assumes the same thing. Up to know, we only know because we configure the interior and edge nodes explicitly.) > I was hoping that the ID would tell me more, but it didn't manage that yet. OK, we'll try harder ;-). I will be giving these ideas a run at greater length at the APAN research workshop in Auckland on August 6th. > (When you say, which "node" is a member of the domain, I think you mean to > say, "which interface on a node" is a member of the domain... ?) I think that depends on the scenario. (Do you think that individual interfaces should have an IDevID?) Thanks Brian From nobody Wed Jul 25 20:30:19 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26D130F5E; Wed, 25 Jul 2018 20:30:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Toerless Eckert To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Cc: anima-chairs@ietf.org, Toerless Eckert , iesg-secretary@ietf.org, anima@ietf.org, tte+ietf@cs.fau.de Message-ID: <153257581862.7282.2455483571375545858.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2018 20:30:18 -0700 Archived-At: Subject: [Anima] Publication has been requested for draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 03:30:19 -0000 Toerless Eckert has requested publication of draft-ietf-anima-bootstrapping-keyinfra-16 as Proposed Standard on behalf of the ANIMA working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ From nobody Wed Jul 25 20:33:50 2018 Return-Path: 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 E88EC130F5E; Wed, 25 Jul 2018 20:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 TtBQdyd5Xc1u; Wed, 25 Jul 2018 20:33:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5B7130F53; Wed, 25 Jul 2018 20:33:46 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EAE1D58C4C5; Thu, 26 Jul 2018 05:33:41 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D83614402CB; Thu, 26 Jul 2018 05:33:41 +0200 (CEST) Date: Thu, 26 Jul 2018 05:33:41 +0200 From: Toerless Eckert To: draft-ietf-anima-bootstrapping-keyinfra.authors@ietf.org Cc: anima@ietf.org Message-ID: <20180726033341.ldp6m44qz34suvht@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: [Anima] Pls. fix nits for draft-ietf-anima-bootstrapping-keyinfra-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 03:33:49 -0000 As i haven't seen replies to the original email i sent 2 weeks ago wrt. to nits for the draft, i'll append it again here. I have also appended these these nits to the shepherd writeup for the benefit of AD/IETF/IESG reviewers as i have just finished the shepherd writeup and pushed the document to the IESG. Cheers Toerless Dear authors of draft-ietf-anima-bootstrapping-keyinfra Please review and accordingly resolve the following nits in revision -16. These are result of shepherd lookup and from Brian: A) Downward references RFC3542 is a normative reference that is not referenced in the document either remove or move into informational so as not to create an unnecessary normative downward reference. RFC7228 is a normative reference referenced in the document even though it is an informational document. I am writing into the shepherd doc that i think this is an appropriate downrev given how we only use it for terminology but derive requirements through classifications by that terminology ("constrained"). let me know if from your experience you think this is inappropriate and you'd rather like to move it to informational. B) IANA There is one candidate NIT where i am looking for your guidance, also given possible future work: The IANA section asks for the creation of a registry entitled: _Voucher Status Telemetry Attributes_. Even if IANA allocates registries with just one table, i am going to suggest that the ask is changed to create a registry "Voucher Parameter registry" with one table called "Voucher Status Telemetry Attribute". Especially in the likely expectation that future work might come up with more voucher parameters. Please change the wording in the IANA section accordingly. C) Expert reviewer Any suggested expert reviewer for the new voucher registry Short of an answer, If not, i'll recommend IANA to ask authors of RFC8366. D) https://github.com/anima-wg/anima-bootstrap/issues/66 rev -16 section 5.2 has an unresolved EDNOTE pointing to a section for "Pledge Authorization". That section was last D.1.3.2. in -07 and was then removed when D.* was integrated back and the rest of D was removed in -08. I can not find offhand any stubs of D.1.3.2 integrated elsewhere into the text, so i would suggest to reintroduce an appropriate subset of that section (aka: anything you think is uncontentuous). From nobody Thu Jul 26 15:32:22 2018 Return-Path: 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 7C64813124A for ; Thu, 26 Jul 2018 15:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 bol43gldhpbX for ; Thu, 26 Jul 2018 15:32:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E57012777C for ; Thu, 26 Jul 2018 15:32:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C00CC20008; Thu, 26 Jul 2018 18:48:32 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 804781787; Thu, 26 Jul 2018 18:32:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7D4E41781; Thu, 26 Jul 2018 18:32:15 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: anima@ietf.org In-Reply-To: <2687e245-88da-b165-af83-d78e90a189b0@gmail.com> References: <15259.1532540391@localhost> <2687e245-88da-b165-af83-d78e90a189b0@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] limited domain X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 22:32:19 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> Just watching the recording... >>=20 >> Like Toerless, I am not sure what you are proposing to do exactly. >> How does what we need to do differ from what MIF (failed?) to do? > Well, MIF did produce PVDs, but IMHO that was a completely different > problem space. I think the correct question is how does the problem > differ from the one solved by BRSKI+ACP, plus the missing bit of > Anima, which is how to identify roles within the ANI and where the > edge of the autonomic domain is. Our feeling is that this is a more > general concept than just autonomics. > (For example: Segment routing assumes that we know where the SR > domain edge is. DETNET assumes that we know where the domain edge > is. Diffserv assumes the same thing. Up to know, we only know > because we configure the interior and edge nodes explicitly.) I think that I comprehend the problem you described. I don't understand the scope of the solution you imagine. Is it terminology? Is it a new protocol? Your point about how does it differ from the ACP boundaries is an interesti= ng one. Let's consider a mature ISP or Data Center operator or Enterprise with a fully functional ACP. The DC operator has ToR switches that they manage, and their customers have "things" in the cabinets that see a default route and stacks of IP-level transit. Are the customer devices in the cabinets, or the desktop PCs within the domain? Probably not for the customer devices... maybe for the desktop PCs. Maybe not. I think that for the set of scenarios your document outlines the answers va= ry widely as well... quite possibly different scenarios could overlap, and yet have different boundaries. >> I was hoping that the ID would tell me more, but it didn't manage th= at yet. > OK, we'll try harder ;-). I will be giving these ideas a run at great= er > length at the APAN research workshop in Auckland on August 6th. okay, that sounds like a good way to get feedback. >> (When you say, which "node" is a member of the domain, I think you m= ean to >> say, "which interface on a node" is a member of the domain... ?) > I think that depends on the scenario. (Do you think that > individual interfaces should have an IDevID?) Sometimes yes. Mostly, no. Should they have different LDevIDs might be a more interesting question, and I think having different LDevIDs might happen with some frequency in some scenarios. Network Function Virtualization brings another layer to this. (I don't expect BRSKI to bootstrap the other LDevIDs, but rather the ACP for the physical devices would provide a mechanism by which virtual routers wou= ld be created for customers) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBW1pL74CLcPvd0N1lAQII+Qf/T4Gx7TeZ3gGUVyxSdvwtACJ3r+rIGlLC gcrFee9XBSLcHsxUHrA0R+5Pir0oK36goMA5rVFfoK1TM/cUPWFsV8izWD4yM9pW SBhqHJC236sZbiYl9tZ1hYnkSPNmx5wxtYxzWvfM9rtM7poF2IqzKWk89o7UP0qH JBFiNEr5eABKup84UO1G49jc6PcldQukikWTap6tYB64ZhCmYqdlLOlHGzZjy4J+ r7jeHU9pvFcr/LSTL6REoq29pr5e2P9OOJAn61UsPVyFN9Wl3Epd1m08cQzYpO/z hEU5Oj9gdoBaj1xuA3+kFjFssIO/VT8LAmDEoXiHB08Va+tcRykp+A== =+//q -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 31 17:05:59 2018 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A8130EB4; Tue, 31 Jul 2018 17:05:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies To: Cc: anima@ietf.org, ietf@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153308194697.3384.1689302422182872423@ietfa.amsl.com> Date: Tue, 31 Jul 2018 17:05:47 -0700 Archived-At: Subject: [Anima] Genart telechat review of draft-ietf-anima-autonomic-control-plane-16 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.27 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 00:05:47 -0000 Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-anima-autonomic-control-plane-16 Reviewer: Elwyn Davies Review Date: 2018-07-31 IETF LC End Date: 2018-02-26 IESG Telechat date: 2018-08-02 Summary: This document is ready but has a fair number of nits still to fix, particularly in the earlier part of the document. There are also some language issues to address which the RFC Editor will deal with. My issues from the Last Call review have been addressed. Major issues: None Minor issues: None Nits/editorial comments: General: There are three remaining examples of "intent" rather than "Intent". General: There are five instances of the construction -> "quoted text" () in s2. Need to remove -> and () in each case. This may be down to tool problems - there is a comment in the revisions list. S1, para 5: s/The ACP is designed to remains/The ACP is designed to remain/ s1, para 5: s/The details how this achieved are defined in Section 6./The details of how this achieved are described in Section 6./ s1, bullet point #1: s/supports directly/directly supports/ s1, bullet point #3: s/network/(Data-Plane) network/ S1, last para: s/Defined Networking (SDN) (see [RFC7426]), style automation/Defined Networking- (SDN-)style (see [RFC7426]) automation/ S1.1, para 2: Operational Technology is a term that is not very well-known - a reference would help. Unfortunately it seems that the text of ISA99 that defines the term is not freely available. Suggestions of a freely available alternative? s1.1, para 3: Although RPL is in the glossary in s2, this instance occurs before s2 is announced, so it would be worth adding RPL (Routing Protocol for Low-power and Lossy Networks - RFC6550) s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP domain certificate". S2, "ACP Domain": 'of nodes with ->"ACP domain' . Remove "->" and ()? s2. "ACP Loopback interface": Need to expand VRF on first use. s2, "ACP secure channel": As wrtten this equates a security association with a secure channel. Suggest: NEW: ACP secure channel: A sequence of links established hop-by-hop between adjacent ACP nodes with a security association established for each link using the ACP secure channel protocol and the ACP Domain Certificate. The channel is used to carry traffic of the ACP VRF separated from Data-Plane traffic in-band over the same links as the Data-Plane. ENDS s2, "Data-Plane": s/non-autonomic/by means other than autonomically/ s2, "GRASP": s/required/REQUIRED/ s2, "in-band (management)": fix up two instances of -> ... (). s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the reference to s6.10.5 hasn't been translated. s2, "(virtual) out-of-band network": fix up one instance of -> ... (); s/where historically/were historically/; In next to last sentence s/out of band/out-of-band/ s2, "ULA": s/are the first 48 bit/is the first 48 bits/ s2, "(ACP) Zone": s/protocols details/protocol's details/ s3.1: s/This way/In this way/; possibly s/other processes/single instamces of other processes/??? s3.2, last para: s/like/such as/ [like: Yuck!] s3.3, para 1: s/managment/management/ s3.3, first bullet: s/out of Band/out-of-Band/ s4, ACP2: The phrase "(can block easily at edge)" needs additional explanation. s4, ACP4: s/generic. Usable/generic, that is it MUST/ s4, last para: Need to expand eACP. s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/ s5, lata para: s/This way/In this way/ s6.1, para 4: Trailing colon s/b period. s6.1.1, last para on page 20: s/":" are not/The character ":" is not/ s6.1.1, last but 2 para: s/information element it,/information element,/(probably) s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; s/peers domain/peer's domain/ s6.1.3.1, last para: Expand ttl on first use. s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain certificate/; s/nodes ACP/node's ACP/ s6.3, para 2: s/State Less/Stateless/ s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network with reasonably fast/ s6.12: s/hop by hop/hop-by-hop/ s8.2.1, bullets 2 and 3: s/vrf/VRF/