From nobody Wed Oct 2 15:43:04 2019 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 212BC12010D for ; Wed, 2 Oct 2019 15:43: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_HELO_NONE=0.001, 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 TH8You8vNL67 for ; Wed, 2 Oct 2019 15:43:00 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 5EF841200FF for ; Wed, 2 Oct 2019 15:43:00 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id y72so389241pfb.12 for ; Wed, 02 Oct 2019 15:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zL08zzlacTzsodrjCf5/M3cyHmy03y4gW9S9EJnmYXk=; b=c8fid93QX3lY/KSwiZ5zg/dmwGEXJrc5b/LyvXvnb6G0lNCnPafZK8/GY2cG/1+VbB SsF5DWR+TWhOMiYEvPwnw8I5VCGPYyy1nGX144i8PgACkjT6ZjHG+rQyGW5XBCdsunfy QhPEcMrr9hNsE4cqQ2Uz1cmrsu66nGm3ZvPDJuTc1pwGSnr5hne5CYbIcqC1NEuxTOpz pq+OnO6CKLG9JtsS71+D4VvzNZNZL+6EMnYoDMhL/NJW+/qGSNDy69+LfLLnKo/PcivR cChaQbTzhWmHxdYAYEVn/MOXfy1WM4E7l/+ACsw8c/rhDPrJR1Lr04ChxP69QJ4RyG0z PIfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zL08zzlacTzsodrjCf5/M3cyHmy03y4gW9S9EJnmYXk=; b=JDXh+vz/aUGKekbzmxzTi9BYyX/0gznz2xyJHmc5jcgT/pUSMozBCfqTYV2SBcPkvG D1m0vD6olcMCjvpenWEGfhOo/ZZNigPK9J8FbfREfbwPPj/uo1pJ4Gpi9JLq06z5i1iL ipIiRpZ5m2I1UF08vokAZ1RBrusE+dB8sZxcoyngvv1tQohLHOGYJ40SpJnFpYNYIsfR fsBXgFl6JqmNBHlVviKTbPV+e7ymif4jYOnfpu1Z3rG1Ii6HDVO1r1bMONlOpjobKMzr u8WB4wyFMQXVVMUydRTFJZwoJDfBaXbDYZtqwRBsohSG/HPchcqiitDzApa1imWwoB2B r0rg== X-Gm-Message-State: APjAAAVHKYBMYg0yrvyrEsiR2BTYKtGLb2UYm87NhGs2BBPKsRwmS5eK ckkcYaDL80wv+NTnM4VrXFUa1ESb X-Google-Smtp-Source: APXvYqxg/Ft0iQoJ+B9JcujsC+j7B3bpASRJUg69YS/5GDWt78r4vYvpbQQ6nu39b8v5sew4u0wECA== X-Received: by 2002:a63:475d:: with SMTP id w29mr6227747pgk.46.1570056179586; Wed, 02 Oct 2019 15:42:59 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id v8sm275190pje.6.2019.10.02.15.42.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2019 15:42:58 -0700 (PDT) References: <157005596514.8880.4849983453449254660@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <157005596514.8880.4849983453449254660@ietfa.amsl.com> Message-ID: Date: Thu, 3 Oct 2019 11:42:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157005596514.8880.4849983453449254660@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-l2acp-scenarios-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 22:43:02 -0000 Hi, This version is updated to consider MACSE security as discussed at IETF 105. (We also added a brief discussion of WPA2.) Brian + Bing -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-l2acp-scenarios-01.txt Date: Wed, 02 Oct 2019 15:39:25 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scenarios and Requirements for Layer 2 Autonomic Control Planes Authors : Brian Carpenter Bing Liu Filename : draft-carpenter-anima-l2acp-scenarios-01.txt Pages : 7 Date : 2019-10-02 Abstract: This document discusses scenarios and requirements for Autonomic Control Planes (ACPs) constructed and secured at Layer 2. These would be alternatives to an ACP constructed and secured at the network layer. A secure ACP is required as the substrate for the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-l2acp-scenarios/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-l2acp-scenarios-01 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-l2acp-scenarios-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-l2acp-scenarios-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Oct 3 17:33:42 2019 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 E42B81208A4; Thu, 3 Oct 2019 17:33:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, tte+ietf@cs.fau.de X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157014922089.1620.2883206808489166126.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2019 17:33:40 -0700 Archived-At: Subject: [Anima] anima - New Meeting Session Request for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 00:33:41 -0000 A new meeting session request has just been submitted by Toerless T. Eckert, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Toerless Eckert Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: Chair Conflict: bier pim mboned 6man 6lo 6tisch ace Technology Overlap: roll homenet netconf detnet nmrg Key Participant Conflict: cfrg saag intarea opsarea dinrg panrg People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: Please avoid meeting on friday due to travel constraints of chair. It would be nice to have the 1.5 hour meeting first. --------------------------------------------------------- From nobody Fri Oct 4 06:44:06 2019 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 66B95120046; Fri, 4 Oct 2019 06:44:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: anima-chairs@ietf.org, ibagdona@gmail.com, anima@ietf.org, tte+ietf@cs.fau.de X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157019664334.1139.7773128242552782955.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2019 06:44:03 -0700 Archived-At: Subject: [Anima] anima - Update to a Meeting Session Request for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 13:44:04 -0000 An update to a meeting session request has just been submitted by Toerless T. Eckert, a Chair of the anima working group. --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Toerless Eckert Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1 Hour Number of Attendees: 80 Conflicts to Avoid: Chair Conflict: bier pim mboned 6man 6lo 6tisch ace Technology Overlap: roll homenet netconf emu Key Participant Conflict: cfrg saag intarea opsarea dinrg panrg nmrg detnet People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: Please avoid meeting on friday due to travel constraints of chair. It would be nice to have the 1.5 hour meeting first. --------------------------------------------------------- From nobody Sun Oct 6 12:34:22 2019 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 EC9421200B6; Sun, 6 Oct 2019 12:34:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <157039045985.6647.1332815270220564723@ietfa.amsl.com> Date: Sun, 06 Oct 2019 12:34:19 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-grasp-api-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 19:34:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) Authors : Brian Carpenter Bing Liu Wendong Wang Xiangyang Gong Filename : draft-ietf-anima-grasp-api-04.txt Pages : 29 Date : 2019-10-06 Abstract: This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted to the support for asynchronicity in various languages and operating systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-grasp-api-04 https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-api-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-api-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 6 12:37:33 2019 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 44A8C120072 for ; Sun, 6 Oct 2019 12:37:30 -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_HELO_NONE=0.001, 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 ZH5VkFwbf34U for ; Sun, 6 Oct 2019 12:37:28 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 669B9120048 for ; Sun, 6 Oct 2019 12:37:28 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id x127so7217708pfb.7 for ; Sun, 06 Oct 2019 12:37:28 -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=sZx9KeQEdnIhs7eSOHqLicP1o85tL9wY8WqryCfLetQ=; b=r/2mLWHYNev0v03n9Pmmwl3F5TXPpWlk1UxGVUFezi5qT9fvhj2QV+/e7T3rbENT7E 1XHaF4SPgJP/HNt+3Oa/P0EPSPGp+YUxuuvfElJKU79O4LTUEVR8lPdwWgXtF1z4m7+R a1DYCdm7lyKxGbrkHme0/+o8NC4kLuDJqRgOQqI33Z+ueGh/1xIdDXf6s0sk/a5pMgG8 plm1zHSsqE3HzRHKKzWhFMdS4aJniDKbEXhKbAgewLFaVl9qqT388sGPxzeeyB6TVbya Ty0bjDXtNFVLIwMa7iBO1Ik3C7ndWaLUWob6+ZpVVQHF9XtrdAF8rbxP7AvrqpEwKxbx djgg== 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=sZx9KeQEdnIhs7eSOHqLicP1o85tL9wY8WqryCfLetQ=; b=hizCQ74vdrBXFRjeCIuAYCbwgIjHxIyPpTKkVMjWVDKW8KBo2CfWxtLvoMQ+kudYZX 79Hrxm3luNAQYn5Ao0Lz/hm34267CgAzdQdNcknDS7BIlttMplmTG6rYa22UNaSX4sIM rqMTdZEZPZ1PH7pdurkm5pYVRaFbJEcrkUpTZ1b3AgPbyDgDnju/R2yt9iZNPyItf8Jb J6l1skhhHPCKIwzcM4myYVscRVPCpRSXN+80C+TM1pmdvyK4WnxoAu5mXtwzGqAzk9fy P+1jXBt2dH+wZDQ08uPvvd4y2bEwNaWveCxo4VXYWO3bFVYXFx/7dgAHm++pnyjKpop3 ZHvg== X-Gm-Message-State: APjAAAXcSj8OEc28DooMjkBO/w3zJJakOmshqxQwWqCwAKRLO4/XU9dW mXHG7iQRU9YBn0WMq1GtUr/EPpt8 X-Google-Smtp-Source: APXvYqwSXjAFcAVrR53v9dSn3Qw1kN9EC0eRj6Z5cmbvk6R0yrjsDjxdR4/xIgQUhDUI2VjJ6tLzWQ== X-Received: by 2002:a62:2b51:: with SMTP id r78mr28503965pfr.149.1570390647391; Sun, 06 Oct 2019 12:37:27 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id b185sm13210695pfg.14.2019.10.06.12.37.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Oct 2019 12:37:26 -0700 (PDT) To: anima@ietf.org References: <157039045985.6647.1332815270220564723@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Mon, 7 Oct 2019 08:37:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157039045985.6647.1332815270220564723@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-ietf-anima-grasp-api-04.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 19:37:31 -0000 Hi, This version is in response to several reviews: Improved discussion of layering, mentioned daemon. Added callbacks and improved description of asynchronous operations. Described use case for 'session_nonce'. More explanation of 'asa_nonce'. Change 'discover' to use 'age_limit' instead of 'flush'. Clarified use of 'dry run'. Editorial improvements. Regards Brian Carpenter On 07-Oct-19 08:34, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > > Title : Generic Autonomic Signaling Protocol Application Program Interface (GRASP API) > Authors : Brian Carpenter > Bing Liu > Wendong Wang > Xiangyang Gong > Filename : draft-ietf-anima-grasp-api-04.txt > Pages : 29 > Date : 2019-10-06 > > Abstract: > This document is a conceptual outline of an application programming > interface (API) for the Generic Autonomic Signaling Protocol (GRASP). > Such an API is needed for Autonomic Service Agents (ASA) calling the > GRASP protocol module to exchange autonomic network messages with > other ASAs. Since GRASP is designed to support asynchronous > operations, the API will need to be adapted to the support for > asynchronicity in various languages and operating systems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-anima-grasp-api-04 > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-api-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-api-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Oct 7 20:56:10 2019 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 9BC22120111; Mon, 7 Oct 2019 20:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 AHg4rBvsgQ0t; Mon, 7 Oct 2019 20:56:06 -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 9358D1200E3; Mon, 7 Oct 2019 20:56:06 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C40D21FB2A0AA01EC56C; Tue, 8 Oct 2019 04:56:03 +0100 (IST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 8 Oct 2019 04:56:03 +0100 Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 8 Oct 2019 04:56:02 +0100 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 8 Oct 2019 04:56:02 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Tue, 8 Oct 2019 11:55:59 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFw== Date: Tue, 8 Oct 2019 03:55:59 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@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.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 03:56:09 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all anima, We have been allocated two sessions of 1.5 + 1 hour for the ANIMA WG meetin= g for IETF-106 (Singapore). We are now starting to collect agenda items for= the sessions. Please send your request for agenda by October 31th, Thursda= y, to anima-chairs@ietf.org and both chairs' = email. Please note that email to a single chair may cause single-point fail= ure. 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. As you may observed, we now have the new WG charter in the place, but still= , we have the priority to complete the current WG documents over to adopt a= ny new work. Please send us (anima-chairs at ietf.org) requests for time slot by October 31th, Thursday and inc= lude: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 106, Montreal can be found at: https://www.ietf.org/how/meetings/106/ 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, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all anima,

 


We have been allocated two sessions =
of 1.5 + 1 hour for the ANIMA WG meeting for IETF-106 (Singapore). We a=
re now starting to collect agenda items for the sessions. Please send your =
request for agenda by October 31th, Thursday, to anima-chairs@ietf.org<m=
ailto:anima-chairs@ietf.org> and both chairs' email. Please note that em=
ail to a single chair may cause single-point failure.

 


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.


 


As you may observed, we now have the=
 new WG charter in the place, but still, we have the priority to complete t=
he current WG documents over to adopt any new work.


 


Please send us (anima-chairs at ietf.org<https://ietf.org/><http://ietf.org%3Chttps/ietf.org/)=
>) requests for time slot by October 31th, Thursday and include:


 


Name of time slot:=



Name of draft(s):<=
/pre>

Time requested:

Presenter name(s):=



 


More details about the IETF 106, Mon=
treal can be found at:


 


https://www.ietf.org/how/meetings/106/=



 


Again, presenters and draft authors =
please invoke active discussions in the ANIMA list. Mail list is a very goo=
d place to discuss and reach consensus on technical issues.


 


Best regards,

 


Sheng


 
--_000_5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2NKGEML515MBXchi_-- From nobody Fri Oct 11 19:23:34 2019 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 CAA5D1200DE; Fri, 11 Oct 2019 19:23:31 -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_HELO_NONE=0.001, 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 aCqfkbKOO9Ag; Fri, 11 Oct 2019 19:23:30 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 4D98812004F; Fri, 11 Oct 2019 19:23:30 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id w8so5275742plq.5; Fri, 11 Oct 2019 19:23:30 -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=pk9FkjtL9WESeYinNcrwn4pEWtMzj8rWh4bhKJGG9LA=; b=cvFHjjXOXQB3u0JJX2pjRwRwsWlAN7k3ZZbSKIMA0+VNO+14f+vFSLnNPLWYRY+4e0 Jn437Q6eCgkpKyXCYP/Xjpou8G5p0E7r0MnkuSRSOrbLP/PDxNWHLAzlnppCU+z9okXJ kfHjvf367fxdP2hH0cU0UDcm3mTiffpiXUR/uKpCo+qcVF+nR/Xi8AUPJldt3juMvbhZ Ti3PtCg+Qklp8N0zQG0Ho64a+5QaTuyLyZMf2Jl9vBjMKbnxjFyh723zdyX4+4s4YOmB 7oC0MWLOssNyEh1CyxZhpHWhPxukzhb9Wt0gbSk4O2ypXjF4mh1AHzdYf43hlv2f3qjV 7e/g== 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=pk9FkjtL9WESeYinNcrwn4pEWtMzj8rWh4bhKJGG9LA=; b=lffzvex2Rtqs22hA1b7rKCKI5EmJoy7aHZLnjwi+eTglmATTgrzBRg6Z5Jz14NN4JR ojmzXYBtk47VPkXjGrnNjCvlGwe9dhkUrkhQXkOPYLarOG/bxqU76WJyiyZ0d1xN4CIW Li6zYJSqO6sx6xWN1knChZbbPwG4s79VvSpLS+VF0VM/lCXJ4t77krAp2tQW5F1F2MD5 faEBZA/oCfXKxYVUUrWQlyfAn289r+JrwrXVbB+z/3983vLgcvFyfIjBEFYF+X0C9mX+ er7fi4dIpI44V4YBst0QehcloIL1rR1HSfqjLCVw0BDJwuIXEZuoZe9P+siWFu1TbrGX EZPQ== X-Gm-Message-State: APjAAAXoL0BzN37ki/3RCGdUCUqlSJnpnfnxFyw47p1v1JPCGROUXRQ4 SiUxnbO/N0v42gPEkJc6XwLZ32aS X-Google-Smtp-Source: APXvYqx2No3TDbj5ZTJOAUc1/2x81G6LB84ZhVCgfg5hZ2h0UNiwwuvxdjuDng+ZvkaI11Ws7VPrNg== X-Received: by 2002:a17:902:7d92:: with SMTP id a18mr13393473plm.102.1570847009556; Fri, 11 Oct 2019 19:23:29 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id l72sm15127256pjb.7.2019.10.11.19.23.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 19:23:29 -0700 (PDT) To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> From: Brian E Carpenter Message-ID: <9c2b49de-9a65-f4ec-5a00-fbe9d167b133@gmail.com> Date: Sat, 12 Oct 2019 15:23:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@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] Call for agenda ANIMA @ IETF 106, Singapore [draft-ietf-anima-grasp-api] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 02:23:32 -0000 Hi, We recently posted draft-ietf-anima-grasp-api-04 following review comments. We believe this is ready for WG Last Call, but that is a decision for the chairs. For now we'd like to reserve a slot in the WG meeting. The purpose is not presentation, but simply a final chance for WG comments. If we have a WG last call before the meeting, we can cancel the slot. > Name of time slot: GRASP API > Name of draft(s): draft-ietf-anima-grasp-api-04 > Time requested: 10 minutes > Presenter name(s): Brian Carpenter Regards Brian Carpenter From nobody Fri Oct 11 19:27:16 2019 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 42E48120113; Fri, 11 Oct 2019 19:27: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_HELO_NONE=0.001, 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 xH_T40sl3I2c; Fri, 11 Oct 2019 19:27:13 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 E27C012004F; Fri, 11 Oct 2019 19:27:12 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id y22so7127453pfr.3; Fri, 11 Oct 2019 19:27:12 -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-language:content-transfer-encoding; bh=nnIG1CmEoACkPDc4XGTiiu07HM6P1Y/V81/mGI4rmtE=; b=idb0DVlxRzOc+Mz1xQf56mufcvfAGpUiRjpFMa5MVw4mu5eC0zg23XMGs8VWb5tslt I8L3HTtqpDAdRRXPY9yIr7x3WoPaGAbh4Ep9W1bgc3MCbUkC96GxjWfWryw0ZBuznqq2 K7Oa+B552ZeVcQDLHb8nEwevGP2HvbQC9sTNMvLSYL63rnDSZHyZdAmtpX53ojYfShFI m5wyryWHHJOn+aUgMQ6kp9LQwoVeiZaXiYcac+zlGk++n07sHe5uFUhoyyMOKoSBEyko I38DAUAG2It9Fyc4vSPw3cVZrJItXdn8VyBHw1zyKnfOKCc+ED9eagWabJB0MZfbb8uW BzmA== 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-language :content-transfer-encoding; bh=nnIG1CmEoACkPDc4XGTiiu07HM6P1Y/V81/mGI4rmtE=; b=q2cLFZxkXw5bMv7Lk+mZCTpKKe8U0xlep+86jwQ/grfgPs9V+08q/tBE0LQXffpUdD 6vZGZDeEoIGHcrt7ywNAo9Rdv+rupTUaZy5d3BeHLm6a4josk3gSiuS4V3X7CxeYI17m Unsw57gs5zaXcFedIpm0SVOLhtzqd+DLBNzEW3mkG5hDPpTnAvO+16/JJsS2Q4OuUVXe pucRUheGluR1xjKSArgsDw9qeENPKUOawODrAzYZVekiVJ3I43daYyRHJtW4IM1GhVcy x0r2jbxk5+svpVYEUgkXpirKSKBBful4fKrrUEYZ3qKPI0argKNlS8WRl3Ws3XVjNwX5 lmgA== X-Gm-Message-State: APjAAAUlp+lcTHFjIn4hFdRGVdeML2B5nAQEvyYuk5raR27ZrA2eic/6 SBrdvCyWK+7ow2IxAPexZ9NiSUkw X-Google-Smtp-Source: APXvYqwWFfc7iKbK375xC6CjP2nzWwsg6CM+zwe614j9L/XAG57UWrQnNuQ0SBS2uaeB31PdDBcbTA== X-Received: by 2002:a17:90a:9306:: with SMTP id p6mr21203933pjo.16.1570847232001; Fri, 11 Oct 2019 19:27:12 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id f17sm9049254pgd.8.2019.10.11.19.27.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 19:27:11 -0700 (PDT) From: Brian E Carpenter To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Message-ID: Date: Sat, 12 Oct 2019 15:27:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@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] Call for agenda ANIMA @ IETF 106, Singapore [draft-carpenter-anima-l2acp-scenarios] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 02:27:15 -0000 Hi, We recently posted draft-carpenter-anima-l2acp-scenarios-01 following the discussion at IETF 105. We'd like to briefly present the updates and get WG opinions whether this work should be adopted. > Name of time slot: Layer 2 ACP > Name of draft(s): draft-ietf-anima-grasp-api-04 > Time requested: 15 minutes > Presenter name(s): Brian Carpenter Regards Brian Carpenter From nobody Fri Oct 11 19:33:10 2019 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 23A71120113; Fri, 11 Oct 2019 19:33:09 -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_HELO_NONE=0.001, 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 ZLjFbqvz83nt; Fri, 11 Oct 2019 19:33:07 -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 BA37412004F; Fri, 11 Oct 2019 19:33:07 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id p30so6812973pgl.2; Fri, 11 Oct 2019 19:33:07 -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-language:content-transfer-encoding; bh=a+3Im/MqE5jT9oTNDfGWtCtX5bNiqRvJY7e+tvDPPt4=; b=DH3OtbFS7L/WqMagi+CKV8fRpC2LQjzURbvVqHUZrfj5LJOThYMa4HOQhSbb0hMgzo fpwD9ABKdREz4jTfadsb6/IRC7mQGJLRHKyG8TTgQbqC6TqgASNm6Xr4IikwPfdlQUf2 0pPosHUWqApGbEmg3fzvf2DIsTUXl5uLM1Q0H1EUyCow/HSTM/jDZ4vCJbb/rxKoGZTy tHxTvV4IZ6gSVxJbOFQlXPKy3jcnJd3SQPOHFZzdwk0+LFoV/nSOWAO3qerLGLN/XUE3 TEAs4fbB7YLlqCoMSxLD0yRCWEtN7gqq80zI1dEUFtlowa8Yn88iC57T70k1CnY97lEE GJWw== 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-language :content-transfer-encoding; bh=a+3Im/MqE5jT9oTNDfGWtCtX5bNiqRvJY7e+tvDPPt4=; b=MJZmgh0VDOCBEd13aufOoLbrxdgGYFGIQBieA/JP90p3gv7iphBHgAYimq4VPDGlvN 7w9El3VgV3HPTuuzsIUMxE87m9/Li0T0h4TkBXzmYBnRaQO+Pe8AO0wNGDacuYji2D/p LJoA36rS1U8L2++sfl15/NStrNQkhL4pGKjkyI9E/cIPtBDsxSo2nX0DKpgNnKJc1om+ md8033vKNiZ1FsGDRrhgqSP6MR9ygofsGNMA0qiSVzbOgb159ajY5y4IA89Lp2Fa8Gon XjgV2HUA1yG2TfAAVQtPO0dfYRncocA3xlj2YlaUf1VtCqpXfp1WoF9ovtYD/epXy5NG Zs+Q== X-Gm-Message-State: APjAAAU57yUMRJZDr5ujfvCOvWjpTY8oThU/F9wEwuVHPFXZpiSUETis Oue7Jif0gqTND/dtir02/eyRiEuE X-Google-Smtp-Source: APXvYqxpVnFlSLMeGpUjgiFUvR7dNoqJoC7tD0egzpC8KDPmcIjfmHFqWOxnycVrGaj77k+BuM+Ojw== X-Received: by 2002:aa7:90da:: with SMTP id k26mr19955495pfk.127.1570847586945; Fri, 11 Oct 2019 19:33:06 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id h6sm14232212pfg.123.2019.10.11.19.33.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Oct 2019 19:33:06 -0700 (PDT) From: Brian E Carpenter To: Sheng Jiang , "anima@ietf.org" Cc: "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Message-ID: Date: Sat, 12 Oct 2019 15:33:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@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] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 02:33:09 -0000 Hi, It seems time for the WG to discuss seriously what to do about the environment for Autonomic Service Agents (ASAs). We could have this discussion around an existing draft, but the main goal would be to discuss what the WG needs to do in this area. If the Chairs prefer to take responsibility for this topic, that would be excellent. > Name of time slot: ASA environment > Name of draft(s): draft-carpenter-anima-asa-guidelines-07 > Time requested: 30 minutes > Presenter name(s): Brian Carpenter (but not alone!) Regards Brian Carpenter From nobody Sat Oct 12 14:00:12 2019 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 CDA641200B2; Sat, 12 Oct 2019 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 G7ASKMnDzzUP; Sat, 12 Oct 2019 14:00:10 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FBF12006A; Sat, 12 Oct 2019 14:00:10 -0700 (PDT) Received: from dooku.sandelman.ca (94-168-11-122.static.v4.ziggozakelijk.nl [94.168.11.122]) by relay.sandelman.ca (Postfix) with ESMTPS id CEF101F456; Sat, 12 Oct 2019 21:00:08 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C0F07834; Sat, 12 Oct 2019 23:00:08 +0200 (CEST) From: Michael Richardson To: Brian E Carpenter cc: Sheng Jiang , "anima@ietf.org" , "anima-chairs@ietf.org" In-reply-to: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Comments: In-reply-to Brian E Carpenter message dated "Sat, 12 Oct 2019 15:27:07 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1539.1570914008.1@dooku.sandelman.ca> Date: Sat, 12 Oct 2019 23:00:08 +0200 Message-ID: <1540.1570914008@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [draft-carpenter-anima-l2acp-scenarios] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 21:00:11 -0000 Brian E Carpenter wrote: > We recently posted draft-carpenter-anima-l2acp-scenarios-01 following > the discussion at IETF 105. > We'd like to briefly present the updates and get WG opinions whether > this work should be adopted. Can we find some MACsec expertise? From nobody Sat Oct 12 14:02:24 2019 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 BD57512010F for ; Sat, 12 Oct 2019 14:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8S2W0urPU3C6 for ; Sat, 12 Oct 2019 14:02:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DAB1200B2 for ; Sat, 12 Oct 2019 14:02:21 -0700 (PDT) Received: from dooku.sandelman.ca (94-168-11-122.static.v4.ziggozakelijk.nl [94.168.11.122]) by relay.sandelman.ca (Postfix) with ESMTPS id 3970B1F456 for ; Sat, 12 Oct 2019 21:02:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2ED80834; Sat, 12 Oct 2019 23:02:20 +0200 (CEST) From: Michael Richardson To: "anima\@ietf.org" In-reply-to: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Comments: In-reply-to Brian E Carpenter message dated "Sat, 12 Oct 2019 15:33:02 +1300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sat, 12 Oct 2019 23:02:20 +0200 Message-ID: <1648.1570914140@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 21:02:23 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > It seems time for the WG to discuss seriously what to do about the > environment for Autonomic Service Agents (ASAs). We could have this > discussion around an existing draft, but the main goal would be to > discuss what the WG needs to do in this area. +1 I think that we need to spend some high-level time discussing what happens next, now that we have completed the ACP work (ACP, BRSKI, architecture) {Our AD tells me that BRSKI will return to the IESG at a call very soon} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2iP1sACgkQlUzhVv38 QpBCKwf+JFAT3v9tmmOVeVSSM3Nk0OKcfEVoINo5XGvCgwkWbZWn6l5qdodc76sB fWPQX/ugPSSYru8ii9wpwpzUpap1xM1vO6bu3VYnmwZk2jS/H9eNY0Ov4obYVzOz xybC5CHlF30Oyv4pBzErxNXB0ht6JGy6pBG21+3Ln5G4KDLB4Jvpr1NrMleL3JcA Ma+pcFWUVpYoBP1hFC3Mkzl9AsKbDp0r6fqMgo5DyywUhuD6kTCKtoOVoHHMtrhF AAUf7yPSQnBHSJMJ+aJ8W+A8Mgzs1z85TXojt77hvd2PyFbTOZlXDRxJaWrqz+3v YhCvzMwl7kkGrAdC3p3zeK0qbkjx8Q== =zJyb -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 12 14:12:54 2019 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 C4D671208C5; Sat, 12 Oct 2019 14:12:42 -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_HELO_NONE=0.001, 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 cPkbjn7mumV6; Sat, 12 Oct 2019 14:12:41 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 3A72A1208B2; Sat, 12 Oct 2019 14:12:41 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id u20so6142146plq.4; Sat, 12 Oct 2019 14:12:41 -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=qlwkH+l3fHKwijz8AsQ7dvNZfNlMqrBjJk9tz/NQuMU=; b=nEV1vaQ3vQ3HVXZkkL+YSQLNvodnH8y5UtcpQ4kXmGt2PlLz0dkiDO52T6H0wzZhhd ftB5vloJCf6/iRNN3X2CDozZhEaihInN+4LIV1Mw0naG8f6KI+dedLh0Hq7KSTYIvsUB /y3PVeW/LPOzymIjc6MF9daDorhEPXY7oA1Jb//tKswnvJ9cV3VDi7PI5g68rHaQEUOu Qs+8j0Hekcz1qOBpkaox4IiyWJWNHkrnS4au0nVl3mZPN1VJ3AgF+hA2/3N9MBdK8yA3 DUYlCyvVlGurxt1qYOcPxfqsG71+0eXy9v8gba3eIaF4Hw4fQGXS9Uqf05FzClw898XL bNFQ== 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=qlwkH+l3fHKwijz8AsQ7dvNZfNlMqrBjJk9tz/NQuMU=; b=R618mI4SAiOEKopbUKpoPXVnY9X4EIfk4HZK660PKllZd1apAReBeo5oU0t0II4CEw X02A53xvH5+y3+Qg1a6O3vFN+/gnsDGlrNVJG9oa8WgRCTU4KGjrW9vYNtadRovbzUZV ym7zB4Wdp9Z/hlDoPbfJPPxZRQfSisVxOp2TBynLCr5H2V93UaRuI3c0LbvlQic2lSi6 4inlZXlvGIi+siHkUx6IgORUy05EU2vMYzglfxi/8wUFY0C2maFGkwWGM0swLlKm0ndF UyvnSjOZCvMXEQuV/pDcaphgcbQEGx2BCVHr0Sgc9Q8O2snHexy11X+b7Z4yKIul898G z4NA== X-Gm-Message-State: APjAAAXTlTQgmhvULZzTEj04rue64BJWptBdhzntfX/L9BWbjveZI1sF TKsmISgniCuE449kyvbknE2XpZpB X-Google-Smtp-Source: APXvYqxqeQd83VEozCNmWZfpFLckTVG7bolPZ56mdIglTXjn49aXVnMONME7zXrExYhTpwUJKtonrw== X-Received: by 2002:a17:902:8505:: with SMTP id bj5mr20902840plb.296.1570914760189; Sat, 12 Oct 2019 14:12:40 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id y17sm16486267pfo.171.2019.10.12.14.12.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Oct 2019 14:12:39 -0700 (PDT) To: Michael Richardson , Nancy Cam-Winget Cc: "anima@ietf.org" , "anima-chairs@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <1540.1570914008@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: <274dc965-0da0-4f9d-a12c-028124c71098@gmail.com> Date: Sun, 13 Oct 2019 10:12:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1540.1570914008@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [draft-carpenter-anima-l2acp-scenarios] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 21:12:54 -0000 On 13-Oct-19 10:00, Michael Richardson wrote: > Brian E Carpenter wrote: > > We recently posted draft-carpenter-anima-l2acp-scenarios-01 following > > the discussion at IETF 105. > > > We'd like to briefly present the updates and get WG opinions whether > > this work should be adopted. > > Can we find some MACsec expertise? Good question. Nancy, as the WG's security advisor, any suggestions for that? Thanks Brian From nobody Sat Oct 12 14:16:04 2019 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 C76A6120096 for ; Sat, 12 Oct 2019 14:16: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_HELO_NONE=0.001, 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 9RTl-4IolMVv for ; Sat, 12 Oct 2019 14:16:01 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 1991512002E for ; Sat, 12 Oct 2019 14:16:01 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id q15so6128277pll.11 for ; Sat, 12 Oct 2019 14:16:01 -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=bvqm89uhnMIOZ1u9SSWeWUoIsWo7PJ27Eh9zvwdKEU4=; b=EWAL9ubLQjg/R2m+vt/5+PnQ8VAhH2bmUWYPsi6vCZGdZRFGCExEpaIcCoUpdPqKzN cFuzocI6qrHKhdtq3vjIpn1EFvi0B5zIlUVSf/11cTIebvqrGadS81rQu8VWWah+RVwG qdH/xqpm2X8E1LbDKLtJIqPCflQOrxQZu6QUp4n+6ld4V9WieE1kPfI09I/kB7LI+ZnX HOMbucNreXt8zJcXtSNZ3/Zd70sCsA8qEGllcVV96+EyJpVH5t/c1twC1c03DlqoW03K gUdy/A1x7fId84NrXX+9+78dokd2pFyn11JgVLEtSQnVN5e2Lh1ntuWplEHWoGlJbQDn ttDg== 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=bvqm89uhnMIOZ1u9SSWeWUoIsWo7PJ27Eh9zvwdKEU4=; b=Ece5+K7Q5SESbVM2qhyMnDrcMvBvYfcLMjkrEwsLLxM/k4rq8m1+RAGIVnCkDHFiQO PdNwPbvS02t0HmVT3L+suVAMxYDjbHYLP5LDdBVuAjKcf34HM2lSRA0Qx/DkJGBesXCu WShtEBhytQpnSMMxaQuvVjR1YqCOzjxbKizNAoUD/8Q07rxXnVr9W0BJ1FokTmAiyGLf ATFleJ4aRNiJ4a7Uqx5ECqZzDllG8BzRmCg/htL0mYlrEmuR1U1OeNXVSauJ64rNUvpe s0v6RVXbWZN5cKpMqArxEdDPRcJcyxQONpJG0wOhsw5MgFX3bKKpAqSP1+Vvt07K3qlJ 5X/Q== X-Gm-Message-State: APjAAAX6lovgJulibUC9kIKsRtTgVhlz1bsfJYF89xfkVYwSp7w5uHpd 5G3CnQTCaMSYhDBSHglKoqVb7YQU X-Google-Smtp-Source: APXvYqzEF0g0mKQkYCdxQx9Q7el1d15041uwUvlmqELtsUsYqx2gG3lWApP62ZA/SmtnfMOgAWGJ7Q== X-Received: by 2002:a17:902:465:: with SMTP id 92mr21979048ple.85.1570914960215; Sat, 12 Oct 2019 14:16:00 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id h4sm13075777pfg.159.2019.10.12.14.15.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Oct 2019 14:15:59 -0700 (PDT) To: Michael Richardson , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <1648.1570914140@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: Date: Sun, 13 Oct 2019 10:15:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1648.1570914140@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2019 21:16:03 -0000 On 13-Oct-19 10:02, Michael Richardson wrote: > > Brian E Carpenter wrote: > > It seems time for the WG to discuss seriously what to do about the > > environment for Autonomic Service Agents (ASAs). We could have this > > discussion around an existing draft, but the main goal would be to > > discuss what the WG needs to do in this area. > > +1 > > I think that we need to spend some high-level time discussing what happens > next, now that we have completed the ACP work (ACP, BRSKI, architecture) > > {Our AD tells me that BRSKI will return to the IESG at a call very soon} Good. What about draft-ietf-anima-autonomic-control-plane-20, which had only one DISCUSS left on the previous version? Brian From nobody Sat Oct 12 21:53:38 2019 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 CEB9F120100; Sat, 12 Oct 2019 21:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <157094241575.1368.11692727174528463365@ietfa.amsl.com> Date: Sat, 12 Oct 2019 21:53:35 -0700 Archived-At: Subject: [Anima] Secdir telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 04:53:36 -0000 Reviewer: Christian Huitema Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready with nits. The draft-28 is much improved from the version that I originally reviewed, or even from the intermediate version 20. The issues flagged in the original review are now addressed. The draft now develops options for "nonceless vouchers", which allows for offline onboarding scenario and addresses one of the concerns expressed in my initial review. It also develops a TOFU option for MASA servers, which has different security properties than the initial design. That may be a useful mode of operation, and the related security issues are discussed in subsection 11.4 of the security consideration sections. Draft 28 addresses scenarios like "death of a manufacturer" that were flagged in the first reviews. Generally, I find the revised security consideration section much more developed and comprehensive than in the original drafts. Draft 28 adds an extended privacy consideration section, which is welcome. On the other hand, the authors may consider toning down the commentary text in section 10.3, "The so-called "call-home" mechanism that occurs as part of the BRSKI-MASA connection standardizes what has been deemed by some as a sinister mechanism for corporate oversight of individuals." That text was already in draft-20, but feels a bit too petulant for standard track RFC. I flagged a couple of technical nits: I have a minor concern with the text on TLS usage in section 5.1 and 5.2. In section 5.1, BRSKI-EST TLS establishment details, I read "Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED." Does that mean that BRSKI-EST TLS servers MAY reject connection attempts using a TLS version lower than 1.2, or maybe that pledges SHOULD refuse connections if the server tries to negotiate a TLS version lower than 1.2? We have experience in other deployments that even "low end" vendors will not cheap lower security solutions if that leads to interop failures, and that having at least some implementations being strict in what they accept is a good way to raise the bar for everybody. Same issue in section 5.2, regarding BRSKI MASA connections. In section 5.4.1, "This document does not make a specific recommendation" (regarding whether to use public PKI, DANE, or pinned certificates for MASA authentication. That's probably fine from a security point of view, but the absence of at least one recommended solution ay well end up causing interesting interoperability issues. Editorial Nits: In section 1.4, the text says "The major intended beneficiary is that it possible to use the credentials deployed by this protocol to secure the Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane])." I think you mean "benefit" instead of "beneficiary". In section 2.3.1, the text says "The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]." I understand that you mean that according to [IDevId] the field SHOULD be present, but calling that a "SHOULD field" is jargon. In section 7.4.1, I read that "A MASA has the option of not including a nonce is in the voucher, and/or not requiring one to be present in the voucher-request." The "is in" looks like some kind of typo. In section 10.2, typo, "arbtirary" for "arbitrary". From nobody Sun Oct 13 01:39:21 2019 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 36CB4120112; Sun, 13 Oct 2019 01:39:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dan Romascanu Message-ID: <157095596011.20750.2703747454081790983@ietfa.amsl.com> Date: Sun, 13 Oct 2019 01:39:20 -0700 Archived-At: Subject: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 08:39:20 -0000 Reviewer: Dan Romascanu Review result: Ready with Issues 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-bootstrapping-keyinfra-?? Reviewer: Dan Romascanu Review Date: 2019-10-13 IETF LC End Date: None IESG Telechat date: 2019-10-17 Summary: Ready with Issues This document specifies automated bootstrapping of an Autonomic Control Plane by creating a Remote Secure Key Infrastructure (acronym BRSKI) using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Christian Huitema and Jari Arkko have performed early reviews of previous versions of the document for SecDir and Gen-ART. As far as I can tell, most if not all of their major concerns concerning applicability and security have been addressed in the latest versions. A few more minor issues described below would better be clarified before approval. I also observe that the document has consistent Operational implications but there is no OPS-DIR review so far, as well as a YANG module and several other references to YANG, but there is no YANG Doctors review. I hope that these will be available prior to the IESG review. Major issues: Minor issues: 1. The Pledge definition in section 1.2: > Pledge: The prospective device, which has an identity installed at the factory. while in the Introduction: > ... new (unconfigured) devices that are called pledges in this document. These two definitions seem different. The definition in 1.2 does not include the fact that the device is 'new (unconfigured'. Also, arguably 'identity installed at the factory' may be considered a form of configuration. 2. The document lacks an Operational Considerations section, which I believe is needed, taking into consideration the length and complexity of the document. There are many operational issues spread across the document concerning the type and resources of devices, speed of the bootstrapping process, migration pass, impact on network operation. I suggest to consider adding such a section pointing to the place where these issues are discussed and adding the necessary information if missing. Appendix A.1 in RFC 5706 can be used as a checklist of the issues to be discussed in such a section. 3. Section 5.4: > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. What is the reason for using 'encouraged'? Why not RECOMMENDED? Nits/editorial comments: 1. The Abstract includes: 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' Later in the document BRSKI is idefined as a protocol. It would be good to clarify if BRSKI = BRSKI protocol 2. In Section 1 - Introduction, 3rd paragraph: s/it's default modes/its default modes/ s/it's strongest modes/its strongest modes/ 3. Please expand non-obvious acronyms at first occurrence: EST protocol, LLNs, REST interface, LDAP, GRASP, CDDL, CSR 4. I would suggest alphabetic order listing of the terms in section 1.2 5. Section 1.3.1 - a reference for LDevID would be useful 6. Section 7: s/Use of the suggested mechanism/Use of the suggested mechanisms/ From nobody Mon Oct 14 07:50:35 2019 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 07D22120110; Mon, 14 Oct 2019 07:50:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.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-FayU7WZK-z; Mon, 14 Oct 2019 07:50:30 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150124.outbound.protection.outlook.com [40.107.15.124]) (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 CF858120106; Mon, 14 Oct 2019 07:50:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=edrphcAG95kLQZTQof2ZfKtSBvbSBXrtht5AnT4n8RE0RZWtl2Sf0U8FJ1XnpF8nw0pI3qMRjSv4NeNrb0qiz62a8zaEPEjJLz6aMz73Ev9deigsP35zEHmdjmy3cit2rIpvVYo2kZjiW/TjN6bS+e1h9dA/UsD5Byf06elYgqu1KXHBnA263ZuZZ6U/3/PfBwzx2pFpjOMLOVmUWKvtnKmDZiPCqtiXfpKPYIkaJ1F4cjWEULs+6DyiLqfwfwkGChNIWz0OEjAh10DQE0yx38tDznpu6jsgZyiOAzkg/b8TI0Sb72CARHyqlWM5wzozsnBXjjv4ld6PA8Opl5oQdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lMHE4/r0SQ80b9lhArnowaO5nCO5+5Locq3xomJkTX4=; b=ah4L6+rhMe92D+HjMryUgEsi37bojfuJMOt/0r+MzOVPGMG96Dfj4nsJTi+Qe2pflB7jigaxuh+iYE4/oWb4BQGsYk/fbZnYCrWeH5pO4duczhubr+1m4kWgnxjM5F5qgZL8vndAyTnFyntRZbLWOlepQXl7/IkS2KMBCKVeCvHX+h96NYOMqJ4uF7LcfFO+8rshsRVGhuAEO06kLAFgLbpx5+fgvf7reV1SIijlCoCzfQiDVUNcTcLmm4AjT/FCSNvpQf+siiRX57LXv29FoYb2/X5VMSptBysh7PizO4Tf2qd2NLOP/uf4nDn4/Dhd5KAGb/cmU7awEnwTPX42Jg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lMHE4/r0SQ80b9lhArnowaO5nCO5+5Locq3xomJkTX4=; b=HzLswwIz1rv2mwK7QfdjonnOcRRyojZkGzB60kRWVaFduVPWIss+0U9Kx4nvNzlzVDBUySAD8LhMEiPQ7XTNFnxz/G1D5aEaEaWPlPwr4GIeKvwFXlKgn17HmSdp+vecgR3AYTztgyz0Dqxe3Yjxqi1WFhbUxzqQt4oDEdWySdw= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0355.EURP190.PROD.OUTLOOK.COM (10.161.64.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Mon, 14 Oct 2019 14:50:23 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::9db:9b27:7118:48dc]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::9db:9b27:7118:48dc%7]) with mapi id 15.20.2347.023; Mon, 14 Oct 2019 14:50:23 +0000 From: Esko Dijk To: "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" CC: "anima@ietf.org" Thread-Topic: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 Thread-Index: AQHVgaG9zAFQo+S+FUuSBtMsWvKuKadaNnxQ Date: Mon, 14 Oct 2019 14:50:23 +0000 Message-ID: References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> In-Reply-To: <157095596011.20750.2703747454081790983@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3102:5a00:4c8a:ff15:68b0:e4ae] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba4a16cc-1898-4918-1540-08d750b5d7b6 x-ms-traffictypediagnostic: AM5P190MB0355: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39830400003)(366004)(136003)(346002)(199004)(189003)(13464003)(14444005)(6116002)(4326008)(256004)(33656002)(966005)(2501003)(508600001)(25786009)(52536014)(71200400001)(71190400001)(450100002)(5660300002)(4001150100001)(2906002)(14454004)(316002)(55016002)(305945005)(102836004)(7736002)(9686003)(186003)(6436002)(7696005)(64756008)(76176011)(66556008)(66476007)(6506007)(66446008)(66946007)(53546011)(74316002)(5640700003)(486006)(44832011)(76116006)(2351001)(8676002)(46003)(446003)(476003)(11346002)(229853002)(86362001)(81166006)(81156014)(6916009)(6246003)(6306002)(99286004)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P190MB0355; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5pGz7EHFFrDjySoVMf2q2A6jdH73U63o13DwLNVUd2Euvz6vRiGGWhRV+ov8SQt7T4A2oArKljFt+RfUEEtyyrtxq1ZVD4SMnBKRQH8rL5zoIh/MqSKuC9aFsAInVYws3c8oUx7mZDf0L+Y5zz3YIb/8dJ8vdQ21mpaYdvdeqPGawKNbHAlAE6aRIrNMQWke5cvnudcZYs2koX63Mq6SKLSOmbcTpM9ayy3sPxxCki3UQL7hD+cDrnzZFWoTth9nnLqiVjc61hnf/DFKEJEZDivf2i8c0z1g0JDXzuHkCGyWmywD0oLRJ5J2rRtle8hxY9+nfTDEcDMUyhdMUQkygYBNM5G0LQzcKlK+CXxXwQY7EkGwiIKSKQFZxREl16ZtnFTBlySp5Qzdvjggiy8JcgOa3QthDWQx2mZXlm9SmKWoVdx5HXCCRgL8ll/ZP3OLqFXWnYfi7Yr38ecdIyw0/w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: ba4a16cc-1898-4918-1540-08d750b5d7b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 14:50:23.1921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R+A9WxKEVBj/804l2pDWKsAcz29tk876TSo8NCAFH+nF8/lM8rDqJng8FId81OzzN/G1i3LTv5rASTSlIlNLWzzHQI+tKw2lZOoTYlgx3g0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0355 Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 14:50:33 -0000 QmVzaWRlcyB0aGUgbWlub3IgaXNzdWVzIG1lbnRpb25lZCBpbiB0aGUgR2VuLUFSVCByZXZpZXcs IHRoZXJlIGFsc28gc3RpbGwgYSBjb3VwbGUgb2Ygb3BlbiBpc3N1ZXMgaW4gdGhlIHRyYWNrZXIg aHR0cHM6Ly9naXRodWIuY29tL2FuaW1hLXdnL2FuaW1hLWJvb3RzdHJhcC9pc3N1ZXMgDQpTaG91 bGRuJ3QgdGhlc2UgYmUgcmVzb2x2ZWQgYWxzbz8gT3IgaXMgaXQgYWxyZWFkeSBwbGFubmVkIHRv IGRvIHRoYXQgbGF0ZXI/ICBSZWplY3Rpb24gb2YgaXNzdWVzIGlzIGFsc28gZmluZSBvZiBjb3Vy c2UgYXMgbG9uZyBhcyBhbGwgaXNzdWVzIGFyZSBjbG9zZWQgYmVmb3JlIHRoZSBkb2N1bWVudCBn ZXRzIHB1Ymxpc2hlZCENCg0KQmVzdCByZWdhcmRzDQpFc2tvDQoNCkVza28gRGlqayBJb1QgQ29u c3VsdGFuY3kgfMKgIEVtYWlsL1NreXBlOiBlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmzCoMKg wqAgfMKgwqAgKzMxIDYgMTI2NCAyMTAzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBBbmltYSA8YW5pbWEtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhbiBSb21h c2NhbnUgdmlhIERhdGF0cmFja2VyDQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMTMsIDIwMTkgMTA6 MzkNClRvOiBnZW4tYXJ0QGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBw aW5nLWtleWluZnJhLmFsbEBpZXRmLm9yZzsgZHJvbWFzY2FAZ21haWwuY29tOyBpZXRmQGlldGYu b3JnOyBhbmltYUBpZXRmLm9yZw0KU3ViamVjdDogW0FuaW1hXSBHZW5hcnQgdGVsZWNoYXQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0yOA0KDQpSZXZp ZXdlcjogRGFuIFJvbWFzY2FudQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMNCg0K SSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdl bmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVu dHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gUGxlYXNl IHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVm b3JlIHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQoNCkZvciBtb3JlIGluZm9y bWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCg0KPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWFuaW1hLWJv b3RzdHJhcHBpbmcta2V5aW5mcmEtPz8NClJldmlld2VyOiBEYW4gUm9tYXNjYW51DQpSZXZpZXcg RGF0ZTogMjAxOS0xMC0xMw0KSUVURiBMQyBFbmQgRGF0ZTogTm9uZQ0KSUVTRyBUZWxlY2hhdCBk YXRlOiAyMDE5LTEwLTE3DQoNClN1bW1hcnk6IFJlYWR5IHdpdGggSXNzdWVzDQoNClRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGF1dG9tYXRlZCBib290c3RyYXBwaW5nIG9mIGFuIEF1dG9ub21pYyBD b250cm9sIFBsYW5lIGJ5IGNyZWF0aW5nIGEgUmVtb3RlIFNlY3VyZSBLZXkgSW5mcmFzdHJ1Y3R1 cmUgKGFjcm9ueW0gQlJTS0kpIHVzaW5nIG1hbnVmYWN0dXJlciBpbnN0YWxsZWQgWC41MDkgY2Vy dGlmaWNhdGVzLCBpbiBjb21iaW5hdGlvbiB3aXRoIGEgbWFudWZhY3R1cmVyJ3MgYXV0aG9yaXpp bmcgc2VydmljZSwgYm90aCBvbmxpbmUgYW5kIG9mZmxpbmUuDQoNCkNocmlzdGlhbiBIdWl0ZW1h IGFuZCBKYXJpIEFya2tvIGhhdmUgcGVyZm9ybWVkIGVhcmx5IHJldmlld3Mgb2YgcHJldmlvdXMg dmVyc2lvbnMgb2YgdGhlIGRvY3VtZW50IGZvciBTZWNEaXIgYW5kIEdlbi1BUlQuIEFzIGZhciBh cyBJIGNhbiB0ZWxsLCBtb3N0IGlmIG5vdCBhbGwgb2YgdGhlaXIgbWFqb3IgY29uY2VybnMgY29u Y2VybmluZyBhcHBsaWNhYmlsaXR5IGFuZCBzZWN1cml0eSBoYXZlIGJlZW4gYWRkcmVzc2VkIGlu IHRoZSBsYXRlc3QgdmVyc2lvbnMuIEEgZmV3IG1vcmUgbWlub3IgaXNzdWVzIGRlc2NyaWJlZCBi ZWxvdyB3b3VsZCBiZXR0ZXIgYmUgY2xhcmlmaWVkIGJlZm9yZSBhcHByb3ZhbC4NCg0KSSBhbHNv IG9ic2VydmUgdGhhdCB0aGUgZG9jdW1lbnQgaGFzIGNvbnNpc3RlbnQgT3BlcmF0aW9uYWwgaW1w bGljYXRpb25zIGJ1dCB0aGVyZSBpcyBubyBPUFMtRElSIHJldmlldyBzbyBmYXIsIGFzIHdlbGwg YXMgYSBZQU5HIG1vZHVsZSBhbmQgc2V2ZXJhbCBvdGhlciByZWZlcmVuY2VzIHRvIFlBTkcsIGJ1 dCB0aGVyZSBpcyBubyBZQU5HIERvY3RvcnMgcmV2aWV3LiBJIGhvcGUgdGhhdCB0aGVzZSB3aWxs IGJlIGF2YWlsYWJsZSBwcmlvciB0byB0aGUgSUVTRyByZXZpZXcuDQoNCk1ham9yIGlzc3VlczoN Cg0KTWlub3IgaXNzdWVzOg0KDQoxLiBUaGUgUGxlZGdlIGRlZmluaXRpb24gaW4gc2VjdGlvbiAx LjI6DQoNCj4gUGxlZGdlOiAgVGhlIHByb3NwZWN0aXZlIGRldmljZSwgd2hpY2ggaGFzIGFuIGlk ZW50aXR5IGluc3RhbGxlZCBhdA0KICAgICAgdGhlIGZhY3RvcnkuDQoNCndoaWxlIGluIHRoZSBJ bnRyb2R1Y3Rpb246DQoNCj4gLi4uIG5ldyAodW5jb25maWd1cmVkKSBkZXZpY2VzIHRoYXQgYXJl IGNhbGxlZCBwbGVkZ2VzIGluIHRoaXMNCiAgIGRvY3VtZW50Lg0KDQpUaGVzZSB0d28gZGVmaW5p dGlvbnMgc2VlbSBkaWZmZXJlbnQuIFRoZSBkZWZpbml0aW9uIGluIDEuMiBkb2VzIG5vdCBpbmNs dWRlIHRoZSBmYWN0IHRoYXQgdGhlIGRldmljZSBpcyAnbmV3ICh1bmNvbmZpZ3VyZWQnLiBBbHNv LCBhcmd1YWJseSAnaWRlbnRpdHkgaW5zdGFsbGVkIGF0IHRoZSBmYWN0b3J5JyBtYXkgYmUgY29u c2lkZXJlZCBhIGZvcm0gb2YgY29uZmlndXJhdGlvbi4NCg0KMi4gVGhlIGRvY3VtZW50IGxhY2tz IGFuIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIHdoaWNoIEkgYmVsaWV2ZSBp cyBuZWVkZWQsIHRha2luZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhlIGxlbmd0aCBhbmQgY29tcGxl eGl0eSBvZiB0aGUgZG9jdW1lbnQuDQpUaGVyZSBhcmUgbWFueSBvcGVyYXRpb25hbCBpc3N1ZXMg c3ByZWFkIGFjcm9zcyB0aGUgZG9jdW1lbnQgY29uY2VybmluZyB0aGUgdHlwZSBhbmQgcmVzb3Vy Y2VzIG9mIGRldmljZXMsIHNwZWVkIG9mIHRoZSBib290c3RyYXBwaW5nIHByb2Nlc3MsIG1pZ3Jh dGlvbiBwYXNzLCBpbXBhY3Qgb24gbmV0d29yayBvcGVyYXRpb24uIEkgc3VnZ2VzdCB0byBjb25z aWRlciBhZGRpbmcgc3VjaCBhIHNlY3Rpb24gcG9pbnRpbmcgdG8gdGhlIHBsYWNlIHdoZXJlIHRo ZXNlIGlzc3VlcyBhcmUgZGlzY3Vzc2VkIGFuZCBhZGRpbmcgdGhlIG5lY2Vzc2FyeSBpbmZvcm1h dGlvbiBpZiBtaXNzaW5nLiBBcHBlbmRpeCBBLjEgaW4gUkZDIDU3MDYgY2FuIGJlIHVzZWQgYXMg YSBjaGVja2xpc3Qgb2YgdGhlIGlzc3VlcyB0byBiZSBkaXNjdXNzZWQgaW4gc3VjaCBhIHNlY3Rp b24uDQoNCjMuIFNlY3Rpb24gNS40Og0KDQo+IFVzZSBvZiBUTFMgMS4zIChvciBuZXdlcikgaXMg ZW5jb3VyYWdlZC4gIFRMUyAxLjIgb3IgbmV3ZXIgaXMNCiAgIFJFUVVJUkVELg0KDQpXaGF0IGlz IHRoZSByZWFzb24gZm9yIHVzaW5nICdlbmNvdXJhZ2VkJz8gV2h5IG5vdCBSRUNPTU1FTkRFRD8N Cg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQoNCjEuIFRoZSBBYnN0cmFjdCBpbmNsdWRlczoN Cg0KJ1RvIGRvIHRoaXMgYSBSZW1vdGUgU2VjdXJlIEtleSBJbmZyYXN0cnVjdHVyZSAoQlJTS0kp IGlzIGNyZWF0ZWQnDQoNCkxhdGVyIGluIHRoZSBkb2N1bWVudCBCUlNLSSBpcyBpZGVmaW5lZCBh cyBhIHByb3RvY29sLiBJdCB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgaWYgQlJTS0kgPSBCUlNL SSBwcm90b2NvbA0KDQoyLiBJbiBTZWN0aW9uIDEgLSBJbnRyb2R1Y3Rpb24sIDNyZCBwYXJhZ3Jh cGg6DQoNCnMvaXQncyBkZWZhdWx0IG1vZGVzL2l0cyBkZWZhdWx0IG1vZGVzLw0Kcy9pdCdzIHN0 cm9uZ2VzdCBtb2Rlcy9pdHMgc3Ryb25nZXN0IG1vZGVzLw0KDQozLiBQbGVhc2UgZXhwYW5kIG5v bi1vYnZpb3VzIGFjcm9ueW1zIGF0IGZpcnN0IG9jY3VycmVuY2U6IEVTVCBwcm90b2NvbCwgTExO cywgUkVTVCBpbnRlcmZhY2UsIExEQVAsIEdSQVNQLCBDRERMLCBDU1INCg0KNC4gSSB3b3VsZCBz dWdnZXN0IGFscGhhYmV0aWMgb3JkZXIgbGlzdGluZyBvZiB0aGUgdGVybXMgaW4gc2VjdGlvbiAx LjINCg0KNS4gU2VjdGlvbiAxLjMuMSAtIGEgcmVmZXJlbmNlIGZvciBMRGV2SUQgd291bGQgYmUg dXNlZnVsDQoNCjYuIFNlY3Rpb24gNzoNCg0Kcy9Vc2Ugb2YgdGhlIHN1Z2dlc3RlZCBtZWNoYW5p c20vVXNlIG9mIHRoZSBzdWdnZXN0ZWQgbWVjaGFuaXNtcy8NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQW5pbWEgbWFpbGluZyBsaXN0DQpBbmlt YUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K From nobody Mon Oct 14 07:57:01 2019 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 DF8A5120103; Mon, 14 Oct 2019 07:56:58 -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 4Ho65o916Zb0; Mon, 14 Oct 2019 07:56:57 -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 1549512002F; Mon, 14 Oct 2019 07:56:57 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 913E1C7FE8980229D4C2; Mon, 14 Oct 2019 15:56:54 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 14 Oct 2019 15:56:54 +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.0439.000; Mon, 14 Oct 2019 22:56:51 +0800 From: Sheng Jiang To: Brian E Carpenter , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] Thread-Index: AQHVgKVl21Y9pLlKqEavOuxeJ6T67adaMzfQ Date: Mon, 14 Oct 2019 14:56:51 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299BC81B6@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.170.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 14:56:59 -0000 SGksIEJyaWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgZW1haWxzLiBZb3VyIHRocmVlIGFwcGxpY2F0 aW9ucyBmb3IgdGhyZWUgdGltZSBzbG90cyBhcmUgbm90ZWQuIFRoZSBjaGFpcnMgd2lsbCBhbGxv Y2F0ZSB0aW1lIGFjY29yZGluZyB0byB0aGUgb3ZlcmFsbCByZWNlaXZlZCBhcHBsaWNhdGlvbnMu DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NCj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMTIsIDIwMTkgMTA6MzMgQU0NCj4g VG86IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+OyBhbmltYUBpZXRmLm9yZw0K PiBDYzogYW5pbWEtY2hhaXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIENhbGwg Zm9yIGFnZW5kYSBBTklNQSBAIElFVEYgMTA2LCBTaW5nYXBvcmUgW0FTQXNdDQo+IA0KPiBIaSwN Cj4gDQo+IEl0IHNlZW1zIHRpbWUgZm9yIHRoZSBXRyB0byBkaXNjdXNzIHNlcmlvdXNseSB3aGF0 IHRvIGRvIGFib3V0IHRoZQ0KPiBlbnZpcm9ubWVudCBmb3IgQXV0b25vbWljIFNlcnZpY2UgQWdl bnRzIChBU0FzKS4gV2UgY291bGQgaGF2ZSB0aGlzDQo+IGRpc2N1c3Npb24gYXJvdW5kIGFuIGV4 aXN0aW5nIGRyYWZ0LCBidXQgdGhlIG1haW4gZ29hbCB3b3VsZCBiZSB0byBkaXNjdXNzDQo+IHdo YXQgdGhlIFdHIG5lZWRzIHRvIGRvIGluIHRoaXMgYXJlYS4gSWYgdGhlIENoYWlycyBwcmVmZXIg dG8gdGFrZSByZXNwb25zaWJpbGl0eQ0KPiBmb3IgdGhpcyB0b3BpYywgdGhhdCB3b3VsZCBiZSBl eGNlbGxlbnQuDQo+IA0KPiA+IE5hbWUgb2YgdGltZSBzbG90OiBBU0EgZW52aXJvbm1lbnQNCj4g PiBOYW1lIG9mIGRyYWZ0KHMpOiBkcmFmdC1jYXJwZW50ZXItYW5pbWEtYXNhLWd1aWRlbGluZXMt MDcNCj4gPiBUaW1lIHJlcXVlc3RlZDogMzAgbWludXRlcw0KPiA+IFByZXNlbnRlciBuYW1lKHMp OiBCcmlhbiBDYXJwZW50ZXIgKGJ1dCBub3QgYWxvbmUhKQ0KPiANCj4gUmVnYXJkcw0KPiAgICBC cmlhbiBDYXJwZW50ZXINCg0K From nobody Mon Oct 14 13:22:47 2019 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 C9CF6120888; Mon, 14 Oct 2019 13:22:46 -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, SPF_HELO_NONE=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 fHARrakPoUrK; Mon, 14 Oct 2019 13:22:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232D512011B; Mon, 14 Oct 2019 13:22:44 -0700 (PDT) Received: from dooku.sandelman.ca (94-168-11-122.static.v4.ziggozakelijk.nl [94.168.11.122]) by relay.sandelman.ca (Postfix) with ESMTPS id 706721F455; Mon, 14 Oct 2019 20:22:42 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id CC0DECB3; Mon, 14 Oct 2019 22:23:33 +0200 (CEST) From: Michael Richardson To: Esko Dijk cc: "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "anima@ietf.org" In-reply-to: References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> Comments: In-reply-to Esko Dijk message dated "Mon, 14 Oct 2019 14:50:23 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19164.1571084613.1@dooku.sandelman.ca> Date: Mon, 14 Oct 2019 22:23:33 +0200 Message-ID: <19165.1571084613@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 20:22:47 -0000 Esko Dijk wrote: > Besides the minor issues mentioned in the Gen-ART review, there also > still a couple of open issues in the tracker > https://github.com/anima-wg/anima-bootstrap/issues Shouldn't these be > resolved also? Or is it already planned to do that later? Rejection of > issues is also fine of course as long as all issues are closed before > the document gets published! Mostly, I have just not closed them properly. From nobody Tue Oct 15 02:41:14 2019 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 916DE1200B3; Tue, 15 Oct 2019 02:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 UIwEneKLLc47; Tue, 15 Oct 2019 02:40:59 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150091.outbound.protection.outlook.com [40.107.15.91]) (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 5BDC3120071; Tue, 15 Oct 2019 02:40:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AGGgumTzzue/rMVap+C0Xv9NC1HMaQAfV5skEIWQfbBtL1pSHMVJRs4TSU91QpfqD9H8ZE40ygGZqaMoXL3bFN9AFAGpOzlNKwx5HHTHtCnnzBLjBsjGCPEyXa0OQw6c8P+gepViemdBdLYmVoyo31erqN3gWP2iD49kl6KBrr04P897ckQW5No/nuj8lvBEQKGlD3EOjEm8LdtRyB6C8PS3oN67CDXsALN9LiLHMwaKFUOzAf9T1pFNi3pVvlAUbmn7jFyogLJTq+TRfNH3F8kzapYTA3d2koj202UCRtGG/2WoTrl0D+majJ+2ytJRXvgQmRa8Toz1giqJCewgzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wXQW8r2Fego80+ajSLKVBvfcSj3qHK9k18R/qsL6SZI=; b=W4/eH63880kE33Iyz7mgtbpGZg+tPudeSiImCz6X/cRtzBJYiYq0jh2J8CwDL06aFpxt9uT3pM9X3yZU69zwu6M9e5sUxZoK8X3kTH4Nid/qQCA565dx0tHGKnWNk/rUXLqgHQp/uHEDTjmtB1zl6ZE6bXWyKMQLRmIDNoyJHwYuj5o+R1ckZmLJm1ZgoOy9fqnoj2AW/7RbURtrub9QyaGcXOVVNUAdeZ/E95Ts68dF1FwD6FKvpnkcdM0Qe5CUV5D8IV1Ikeflw33WujZoLBG76gdXPUTjq0mAUJ33cYW9fp4wgV7Bm+0BFyJTTXXKSdVmwYTZ/72MgA6EHRksAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wXQW8r2Fego80+ajSLKVBvfcSj3qHK9k18R/qsL6SZI=; b=MmLt82/qjTJsMEoJcpVAe7imaaWNqVaYPZUCO1f3ZjYB6WltTpEtA8XQ6lylYNld4DwL9o4FTJuAmeYVf4nrodJtDaUkiKnuRB86ewepZ4tbMmRnBZ0d6PoYB61Z5ii7P2uoBPqKXCCw/QcnMtowAEyG15WLiwFC3sRqcoezKEg= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4756.eurprd07.prod.outlook.com (52.135.148.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.11; Tue, 15 Oct 2019 09:40:57 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2347.021; Tue, 15 Oct 2019 09:40:56 +0000 From: tom petch To: "ietf@ietf.org" CC: "ibagdona@gmail.com" , "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , "anima@ietf.org" , "anima-chairs@ietf.org" Thread-Topic: Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard Thread-Index: AQHVgzykl57Q6XfH+kOO3A4LVPhmCw== Date: Tue, 15 Oct 2019 09:40:56 +0000 Message-ID: <00ef01d5833c$5202f6a0$4001a8c0@gateway.2wire.net> References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::13) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3a5df90-ae96-4c8e-a648-08d75153c74e x-ms-traffictypediagnostic: AM0PR07MB4756: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(346002)(376002)(199004)(189003)(13464003)(6916009)(54906003)(1556002)(4720700003)(4326008)(50226002)(99286004)(486006)(44716002)(476003)(8936002)(62236002)(9686003)(6512007)(5660300002)(2501003)(66066001)(6306002)(14454004)(3846002)(6116002)(478600001)(966005)(316002)(6246003)(71200400001)(5640700003)(71190400001)(6436002)(14444005)(305945005)(86362001)(25786009)(256004)(6486002)(7736002)(14496001)(81686011)(386003)(6506007)(81816011)(76176011)(26005)(229853002)(2351001)(102836004)(66946007)(81156014)(52116002)(66476007)(66556008)(64756008)(186003)(8676002)(1730700003)(44736005)(66446008)(61296003)(81166006)(446003)(2906002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4756; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kSL8ZDwPTYQ9aKNHx6JpVAWMZ2wshjAEcuDdR/ltDgo9oeMpO77PQBXPvG4N0r4teWtj/fSoP0qDb6Kf6IboReHvPhJtQkQ60l9rrUkqQ/4nKCKnjRH1ORk0+MDUx5QWM4l47afgD3yicbVOht5u+DqYJ3BIDW01CWeDm0OGb3b3p2MU73yP3NdSPjQrU8o6RN8ZZ2vneR0B3tJ07cjCGQkwpoRDCnOlk3fpNUzPn9uZu7B5tWNw9IIThZ7I1RNYU/b0zuD6nnfRWHxntvjo3cD0dWZPFosL3kR2eQ7Ch15A8p+NOLcfjJbuJcA2tPo0eATTJwCG0JEpQzjdDMXBLdmInDEsMa7NMgmR54mdQ7wIVokF5V54qz6dF/4M5hrIX/rDhcbr9DPnHzEXcxpdgs3Q8qCUpAxsNL8CbdXVzJBiEyqHKHzSujckPVfk0+0+4/DActEeTR+fNgVLsWUNIQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3a5df90-ae96-4c8e-a648-08d75153c74e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 09:40:56.8577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IsPApghdyiQ2altz04d9kdp1yR9Uyq7ux/A6FCq+gQ51PXRcSpcImQWWW026qwhK0OV5mK9+bqsPmYz2h8o3Pw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4756 Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 09:41:02 -0000 UHJvbXB0ZWQgYnkgRGFuJ3Mgb3BlcmF0aW9uYWwgcmV2aWV3IEkgZ2xhbmNlZCBhdCB0aGUgWUFO RyB3aGljaCBkb2VzDQppbmRlZWQgbmVlZCBzb21lIHdvcmsuDQoNClRoZXJlIGFyZSB0d28gbW9k dWxlcyBpbiB0aGUgSS1ELA0KaWV0Zi12b3VjaGVyLXJlcXVlc3QNCmlldGYtbXVkLWJyc2tpLW1h c2ENCnRoZSBsYXR0ZXIgYmVpbmcgaW4gYW4gYXBwZW5kaXg7IEkgYW0gdW5jbGVhciB3aGV0aGVy IG9yIG5vdCB0aGlzDQphcHBlbmRpeCBpcyBOb3JtYXRpdmUuLg0KDQpJQU5BIENvbnNpZGVyYXRp b25zIHJlZ2lzdGVycyBhIG5hbWVzcGFjZSBmb3IgdGhlIHNlY29uZDsgaXQgZG9lcyBub3QNCnJl Z2lzdGVyIGVpdGhlciBtb2R1bGUuDQoNClhYWFggaXMgdXNlZCB0byByZWZlciB0byB0d28gSS1E LCBvbmUgb2Ygd2hpY2ggYXBwZWFycyBub3QgdG8gZXhpc3QsIHRoZQ0Kb3RoZXIgd291bGQgYXBw ZWFyIHRvIGJlIGEgcHVibGlzaGVkIFJGQy4NCg0KVGhlIGZpcnN0IG1vZHVsZSByZWZlcmVuY2Vz IFJGQzgwNDAgd2hpY2ggaXMgbm90IGluIHRoZSByZWZlcmVuY2VzIGZvcg0KdGhlIEktRA0KDQpU aGUgZmlyc3QgbW9kdWxlIGNvbnRhaW5zDQpzZWUgW1JGQzg0NDZdKQ0Kd2hpY2ggd291bGQgYmUg YmV0dGVyIGFzIGEgWUFORyByZWZlcmVuY2UgY2xhdXNlIGFuZCBzaG91bGQgbm90IGNvbnRhaW4N CltdDQoNClRoZSBzZWNvbmQgbW9kdWxlIGxhY2tzIGEgcmVmZXJlbmNlIGNsYXVzZSBmb3IgaXRz IGltcG9ydHMNCg0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgbGFjayB0aGUgcmVxdWlyZWQgYm9p bGVyIHBsYXRlIGZvciBZQU5HIG1vZHVsZXMNCg0KVGhlIHNlY29uZCBtb2R1bGUgbGFja3MgQ29w eXJpZ2h0DQoNClRvbSBQZXRjaA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206ICJUaGUgSUVTRyIgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KVG86ICJJRVRGLUFubm91 bmNlIiA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiA8aWJhZ2RvbmFAZ21haWwuY29tPjsN CjxkcmFmdC1pZXRmLWFuaW1hLWJvb3RzdHJhcHBpbmcta2V5aW5mcmFAaWV0Zi5vcmc+OyA8YW5p bWFAaWV0Zi5vcmc+Ow0KPGFuaW1hLWNoYWlyc0BpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE1h eSAyMSwgMjAxOSAxMDoyMSBQTQ0KDQo+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3Qg ZnJvbSB0aGUgQXV0b25vbWljIE5ldHdvcmtpbmcNCkludGVncmF0ZWQNCj4gTW9kZWwgYW5kIEFw cHJvYWNoIFdHIChhbmltYSkgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBkb2N1bWVudDogLQ0K PiAnQm9vdHN0cmFwcGluZyBSZW1vdGUgU2VjdXJlIEtleSBJbmZyYXN0cnVjdHVyZXMgKEJSU0tJ KScNCj4gICA8ZHJhZnQtaWV0Zi1hbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJhLTIwLnR4dD4g YXMgUHJvcG9zZWQNClN0YW5kYXJkDQo+DQo+IFRoaXMgaXMgYSBzZWNvbmQgTGFzdCBDYWxsLiBJ b1QgRGlyZWN0b3JhdGUgcmV2aWV3IHdhcyBkb25lIGFmdGVyIHRoZQ0KQU5JTUENCj4gV0cgTGFz dCBDYWxsIGFuZCBjb25zZW5zdXMgdG8gcmVxdWVzdCB0aGUgcHVibGljYXRpb24sIGFuZCB0aGF0 IHJldmlldw0KcmVzdWx0ZWQNCj4gaW4gc3Vic3RhbnRpYWwgY2hhbmdlcyB0byB0aGUgZG9jdW1l bnQuDQo+DQo+IFRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBm ZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KZmluYWwNCj4gY29tbWVudHMgb24gdGhpcyBhY3Rpb24u IFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KPiBpZXRmQGlldGYub3Jn IG1haWxpbmcgbGlzdHMgYnkgMjAxOS0wNi0wNC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5 DQpiZQ0KPiBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBs ZWFzZSByZXRhaW4gdGhlDQpiZWdpbm5pbmcgb2YNCj4gdGhlIFN1YmplY3QgbGluZSB0byBhbGxv dyBhdXRvbWF0ZWQgc29ydGluZy4NCj4NCj4gQWJzdHJhY3QNCj4NCj4NCj4gICAgVGhpcyBkb2N1 bWVudCBzcGVjaWZpZXMgYXV0b21hdGVkIGJvb3RzdHJhcHBpbmcgb2YgYW4gQXV0b25vbWljDQo+ ICAgIENvbnRyb2wgUGxhbmUuICBUbyBkbyB0aGlzIGEgcmVtb3RlIHNlY3VyZSBrZXkgaW5mcmFz dHJ1Y3R1cmUNCihCUlNLSSkNCj4gICAgaXMgY3JlYXRlZCB1c2luZyBtYW51ZmFjdHVyZXIgaW5z dGFsbGVkIFguNTA5IGNlcnRpZmljYXRlLCBpbg0KPiAgICBjb21iaW5hdGlvbiB3aXRoIGEgbWFu dWZhY3R1cmVyJ3MgYXV0aG9yaXppbmcgc2VydmljZSwgYm90aCBvbmxpbmUNCj4gICAgYW5kIG9m ZmxpbmUuICBCb290c3RyYXBwaW5nIGEgbmV3IGRldmljZSBjYW4gb2NjdXIgdXNpbmcgYSByb3V0 YWJsZQ0KPiAgICBhZGRyZXNzIGFuZCBhIGNsb3VkIHNlcnZpY2UsIG9yIHVzaW5nIG9ubHkgbGlu ay1sb2NhbCBjb25uZWN0aXZpdHksDQo+ICAgIG9yIG9uIGxpbWl0ZWQvZGlzY29ubmVjdGVkIG5l dHdvcmtzLiAgU3VwcG9ydCBmb3IgbG93ZXIgc2VjdXJpdHkNCj4gICAgbW9kZWxzLCBpbmNsdWRp bmcgZGV2aWNlcyB3aXRoIG1pbmltYWwgaWRlbnRpdHksIGlzIGRlc2NyaWJlZCBmb3INCj4gICAg bGVnYWN5IHJlYXNvbnMgYnV0IG5vdCBlbmNvdXJhZ2VkLiAgQm9vdHN0cmFwcGluZyBpcyBjb21w bGV0ZSB3aGVuDQo+ICAgIHRoZSBjcnlwdG9ncmFwaGljIGlkZW50aXR5IG9mIHRoZSBuZXcga2V5 IGluZnJhc3RydWN0dXJlIGlzDQo+ICAgIHN1Y2Nlc3NmdWxseSBkZXBsb3llZCB0byB0aGUgZGV2 aWNlIGJ1dCB0aGUgZXN0YWJsaXNoZWQgc2VjdXJlDQo+ICAgIGNvbm5lY3Rpb24gY2FuIGJlIHVz ZWQgdG8gZGVwbG95IGEgbG9jYWxseSBpc3N1ZWQgY2VydGlmaWNhdGUgdG8NCnRoZQ0KPiAgICBk ZXZpY2UgYXMgd2VsbC4NCj4NCj4NCj4NCj4NCj4gVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZp YQ0KPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hbmltYS1i b290c3RyYXBwaW5nLWtleWluZnJhDQovDQo+DQo+IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJh Y2tlZCB2aWENCj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt YW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYQ0KL2JhbGxvdC8NCj4NCj4gVGhlIGZvbGxvd2lu ZyBJUFIgRGVjbGFyYXRpb25zIG1heSBiZSByZWxhdGVkIHRvIHRoaXMgSS1EOg0KPg0KPiAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yODE2Lw0KPiAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci8zMjMzLw0KPiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci8yNDYzLw0KPg0KPg0KPg0KPiBUaGUgZG9jdW1lbnQgY29udGFpbnMgdGhlc2Ugbm9y bWF0aXZlIGRvd253YXJkIHJlZmVyZW5jZXMuDQo+IFNlZSBSRkMgMzk2NyBmb3IgYWRkaXRpb25h bCBpbmZvcm1hdGlvbjoNCj4gICAgIHJmYzgzNjg6IFVzaW5nIGFuIEF1dG9ub21pYyBDb250cm9s IFBsYW5lIGZvciBTdGFibGUgQ29ubmVjdGl2aXR5DQpvZiBOZXR3b3JrIE9wZXJhdGlvbnMsIEFk bWluaXN0cmF0aW9uLCBhbmQgTWFpbnRlbmFuY2UgKE9BTSkNCihJbmZvcm1hdGlvbmFsIC0gSUVU RiBzdHJlYW0pDQo+DQo+DQo+DQoNCg== From nobody Tue Oct 15 02:41:19 2019 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 B16C6120071; Tue, 15 Oct 2019 02:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 K9o6LdhP1NjI; Tue, 15 Oct 2019 02:41:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150091.outbound.protection.outlook.com [40.107.15.91]) (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 E02331200B2; Tue, 15 Oct 2019 02:40:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gQ3Wi98I0H0QAUBQrbtua5rwvxTKFYbJ/Z46dkZNWgG/GL94S7LmTxTZ3leT0iRlVWM97PGnmTAI4codpHrdCpHMyZ2AvWYga5XvK8snUldDlo2/MOWhWqxKW+k4E0/AwmmJfqgZnwN2ZXj//akQgsnh3a4rEHfdp6A9ANfHzN04tnsWkQ4vMz2C1m4i2J4AnU3782NXuDdJ/yo8rCIfgMBnOCv5VTn2GqcpY8TKLA0WkGkOnp46rHFDM/97K+tWRnpj1f536YYVQSbeV06X3krT2/BVgNWjxD3l3p83nCD/5lOFIj6rKa4TRsGxW8EczegSKdBc4UX5q3U8TR/noA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JeUpI9FaKLDp6Bgl/JMfX7/nD3yoGLnCmGcv9NT5bIY=; b=WQIRifURnR7HDyxuSbg7yFYukLOlLye6ucb9rTAQSVa1JLdTK6W3kg+Iqb9WjAxBLHa+pENM7dUXKkxR4M6gc3V09NU1KiFpKcf0TiSE1r/URpwiRNE//kfauHyZSlD3KMq63lLLs5qAwFPiZ01CB5da7p9KTQ/aH2E8cwsNngdMU3QLiNPVEyLy7peUEZG3WNEZ0YWQljyCwPadpPamm1vqw91sawnuYkFXxglyQzjuvrR9IOpNWjfr4YEvUE1zYxzXEbFC+twqJ/MrcRaXw2HUBncyZhZsQVyz2I73BTe6l0H43/RJwInC+qpLrBqC2AwD0KXUQV/LZUgxh8FHKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JeUpI9FaKLDp6Bgl/JMfX7/nD3yoGLnCmGcv9NT5bIY=; b=UJhx1WPC3zs3ZTWBZlbDcdoNH1KGXxE/qWXxMne33vo55+wI7uuJcYjHOyAmi/bSOS52XoJ81hXO+ouryfhDpmx1JWWoXx9xM9Pd86FwA4nkzA5xbVKaNinST281uBQ+Tf0Sx3XdSyFhDQm3NsomHwpxin8ftdrdf4aX8uyHO98= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4756.eurprd07.prod.outlook.com (52.135.148.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.11; Tue, 15 Oct 2019 09:40:57 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2347.021; Tue, 15 Oct 2019 09:40:57 +0000 From: tom petch To: Dan Romascanu , "gen-art@ietf.org" CC: "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "dromasca@gmail.com" , "ietf@ietf.org" , "anima@ietf.org" Thread-Topic: Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 Thread-Index: AQHVgzylZL/55Dso/kSfI5QixLQChA== Date: Tue, 15 Oct 2019 09:40:57 +0000 Message-ID: <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::13) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9cc88cb8-1f43-45e1-4d8b-08d75153c7f0 x-ms-traffictypediagnostic: AM0PR07MB4756: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(39860400002)(346002)(376002)(199004)(189003)(13464003)(54906003)(1556002)(4720700003)(4326008)(50226002)(99286004)(486006)(44716002)(476003)(8936002)(62236002)(9686003)(6512007)(110136005)(5660300002)(2501003)(66066001)(6306002)(14454004)(3846002)(6116002)(478600001)(316002)(6246003)(71200400001)(71190400001)(6436002)(14444005)(305945005)(4001150100001)(86362001)(25786009)(256004)(6486002)(7736002)(14496001)(81686011)(386003)(6506007)(81816011)(76176011)(26005)(229853002)(102836004)(66946007)(81156014)(52116002)(66476007)(66556008)(64756008)(186003)(8676002)(44736005)(66446008)(61296003)(81166006)(446003)(2906002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4756; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: doekoj6NY50F8tg0BtrS6mf1z1SAc0BMubj/R1/GyNR/BD/VmjMgK01EEpduPlL4oJH4Vs/d++8+xRYZEvyIvZ7IXQNbcXg9Gw5oXh78BXy+rUfEb1AK5sZSkcQ8Swe4Cf41AoJ29CpVVDWkSXFTiTr7aSbHft61me55LeOiBQk7LH4Uvj6AH/I3J/hSSRuOoekS5VyEXTs0+XnFRslomwOOwmKhMeJQhp+UMVucQYRgmEHXNhADg7hAFrH6k5RFxDhIFAWVxQw2v8G20NOkyDHijcrNDAegOL4MEbBuD7JvGygxkLQaUenamVMzz+Fr4kNNoRPxt3oSYbPmZQM97BWu3kxbZh8MpkJXi7554xCyZXSii0uHa4MZjUdhOU/GXPX6Mok3P36fy06oPxVtNDjiWCKh8rigI+/xh8jGdHE4KK0f1afrWCz84nveHcuukd4434slq1LLS7aMZjwPNQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cc88cb8-1f43-45e1-4d8b-08d75153c7f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2019 09:40:57.6163 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8p2WnHD9AbZcFs/aXS6gcmp9Yha201OPWfDDdINYmhgAwkjxJlGSQSiKIo7NQ/liTXGzMvO86Ut6xn3BhgdgFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4756 Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 09:41:02 -0000 RGFuDQoNCkkgaGFkIGEgcXVpY2sgbG9vayBhdCB0aGUgWUFORyBhbmQgaXQgZG9lcyBpbmRlZWQg bmVlZCBzb21lIHdvcmsgSU1ITy4NCkkgaGF2ZSBwb3N0ZWQgYSBzZXBhcmF0ZSBlLW1haWwgbGlz dGluZyB3aGF0IEkgc2F3Lg0KDQpUb20gUGV0Y2gNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQpGcm9tOiAiRGFuIFJvbWFzY2FudSB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGll dGYub3JnPg0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDEzLCAyMDE5IDk6MzkgQU0NCg0KPiBSZXZp ZXdlcjogRGFuIFJvbWFzY2FudQ0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0K Pg0KPiBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBU aGUgR2VuZXJhbCBBcmVhDQo+IFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCj4gYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRGIENo YWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91cg0KPiBkb2N1bWVudCBzaGVw aGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4N Cj4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KPg0KPiA8aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCj4NCj4gRG9jdW1l bnQ6IGRyYWZ0LWlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0/Pw0KPiBSZXZpZXdl cjogRGFuIFJvbWFzY2FudQ0KPiBSZXZpZXcgRGF0ZTogMjAxOS0xMC0xMw0KPiBJRVRGIExDIEVu ZCBEYXRlOiBOb25lDQo+IElFU0cgVGVsZWNoYXQgZGF0ZTogMjAxOS0xMC0xNw0KPg0KPiBTdW1t YXJ5OiBSZWFkeSB3aXRoIElzc3Vlcw0KPg0KPiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhdXRv bWF0ZWQgYm9vdHN0cmFwcGluZyBvZiBhbiBBdXRvbm9taWMNCkNvbnRyb2wgUGxhbmUNCj4gYnkg Y3JlYXRpbmcgYSBSZW1vdGUgU2VjdXJlIEtleSBJbmZyYXN0cnVjdHVyZSAoYWNyb255bSBCUlNL SSkgdXNpbmcNCj4gbWFudWZhY3R1cmVyIGluc3RhbGxlZCBYLjUwOSBjZXJ0aWZpY2F0ZXMsIGlu IGNvbWJpbmF0aW9uIHdpdGggYQ0KbWFudWZhY3R1cmVyJ3MNCj4gYXV0aG9yaXppbmcgc2Vydmlj ZSwgYm90aCBvbmxpbmUgYW5kIG9mZmxpbmUuDQo+DQo+IENocmlzdGlhbiBIdWl0ZW1hIGFuZCBK YXJpIEFya2tvIGhhdmUgcGVyZm9ybWVkIGVhcmx5IHJldmlld3Mgb2YNCnByZXZpb3VzDQo+IHZl cnNpb25zIG9mIHRoZSBkb2N1bWVudCBmb3IgU2VjRGlyIGFuZCBHZW4tQVJULiBBcyBmYXIgYXMg SSBjYW4gdGVsbCwNCm1vc3QgaWYNCj4gbm90IGFsbCBvZiB0aGVpciBtYWpvciBjb25jZXJucyBj b25jZXJuaW5nIGFwcGxpY2FiaWxpdHkgYW5kIHNlY3VyaXR5DQpoYXZlIGJlZW4NCj4gYWRkcmVz c2VkIGluIHRoZSBsYXRlc3QgdmVyc2lvbnMuIEEgZmV3IG1vcmUgbWlub3IgaXNzdWVzIGRlc2Ny aWJlZA0KYmVsb3cgd291bGQNCj4gYmV0dGVyIGJlIGNsYXJpZmllZCBiZWZvcmUgYXBwcm92YWwu DQo+DQo+IEkgYWxzbyBvYnNlcnZlIHRoYXQgdGhlIGRvY3VtZW50IGhhcyBjb25zaXN0ZW50IE9w ZXJhdGlvbmFsDQppbXBsaWNhdGlvbnMgYnV0DQo+IHRoZXJlIGlzIG5vIE9QUy1ESVIgcmV2aWV3 IHNvIGZhciwgYXMgd2VsbCBhcyBhIFlBTkcgbW9kdWxlIGFuZA0Kc2V2ZXJhbCBvdGhlcg0KPiBy ZWZlcmVuY2VzIHRvIFlBTkcsIGJ1dCB0aGVyZSBpcyBubyBZQU5HIERvY3RvcnMgcmV2aWV3LiBJ IGhvcGUgdGhhdA0KdGhlc2Ugd2lsbA0KPiBiZSBhdmFpbGFibGUgcHJpb3IgdG8gdGhlIElFU0cg cmV2aWV3Lg0KPg0KPiBNYWpvciBpc3N1ZXM6DQo+DQo+IE1pbm9yIGlzc3VlczoNCj4NCj4gMS4g VGhlIFBsZWRnZSBkZWZpbml0aW9uIGluIHNlY3Rpb24gMS4yOg0KPg0KPiA+IFBsZWRnZTogIFRo ZSBwcm9zcGVjdGl2ZSBkZXZpY2UsIHdoaWNoIGhhcyBhbiBpZGVudGl0eSBpbnN0YWxsZWQgYXQN Cj4gICAgICAgdGhlIGZhY3RvcnkuDQo+DQo+IHdoaWxlIGluIHRoZSBJbnRyb2R1Y3Rpb246DQo+ DQo+ID4gLi4uIG5ldyAodW5jb25maWd1cmVkKSBkZXZpY2VzIHRoYXQgYXJlIGNhbGxlZCBwbGVk Z2VzIGluIHRoaXMNCj4gICAgZG9jdW1lbnQuDQo+DQo+IFRoZXNlIHR3byBkZWZpbml0aW9ucyBz ZWVtIGRpZmZlcmVudC4gVGhlIGRlZmluaXRpb24gaW4gMS4yIGRvZXMgbm90DQppbmNsdWRlDQo+ IHRoZSBmYWN0IHRoYXQgdGhlIGRldmljZSBpcyAnbmV3ICh1bmNvbmZpZ3VyZWQnLiBBbHNvLCBh cmd1YWJseQ0KJ2lkZW50aXR5DQo+IGluc3RhbGxlZCBhdCB0aGUgZmFjdG9yeScgbWF5IGJlIGNv bnNpZGVyZWQgYSBmb3JtIG9mIGNvbmZpZ3VyYXRpb24uDQo+DQo+IDIuIFRoZSBkb2N1bWVudCBs YWNrcyBhbiBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCB3aGljaCBJDQpiZWxp ZXZlIGlzDQo+IG5lZWRlZCwgdGFraW5nIGludG8gY29uc2lkZXJhdGlvbiB0aGUgbGVuZ3RoIGFu ZCBjb21wbGV4aXR5IG9mIHRoZQ0KZG9jdW1lbnQuDQo+IFRoZXJlIGFyZSBtYW55IG9wZXJhdGlv bmFsIGlzc3VlcyBzcHJlYWQgYWNyb3NzIHRoZSBkb2N1bWVudA0KY29uY2VybmluZyB0aGUNCj4g dHlwZSBhbmQgcmVzb3VyY2VzIG9mIGRldmljZXMsIHNwZWVkIG9mIHRoZSBib290c3RyYXBwaW5n IHByb2Nlc3MsDQptaWdyYXRpb24NCj4gcGFzcywgaW1wYWN0IG9uIG5ldHdvcmsgb3BlcmF0aW9u LiBJIHN1Z2dlc3QgdG8gY29uc2lkZXIgYWRkaW5nIHN1Y2ggYQ0Kc2VjdGlvbg0KPiBwb2ludGlu ZyB0byB0aGUgcGxhY2Ugd2hlcmUgdGhlc2UgaXNzdWVzIGFyZSBkaXNjdXNzZWQgYW5kIGFkZGlu ZyB0aGUNCm5lY2Vzc2FyeQ0KPiBpbmZvcm1hdGlvbiBpZiBtaXNzaW5nLiBBcHBlbmRpeCBBLjEg aW4gUkZDIDU3MDYgY2FuIGJlIHVzZWQgYXMgYQ0KY2hlY2tsaXN0IG9mDQo+IHRoZSBpc3N1ZXMg dG8gYmUgZGlzY3Vzc2VkIGluIHN1Y2ggYSBzZWN0aW9uLg0KPg0KPiAzLiBTZWN0aW9uIDUuNDoN Cj4NCj4gPiBVc2Ugb2YgVExTIDEuMyAob3IgbmV3ZXIpIGlzIGVuY291cmFnZWQuICBUTFMgMS4y IG9yIG5ld2VyIGlzDQo+ICAgIFJFUVVJUkVELg0KPg0KPiBXaGF0IGlzIHRoZSByZWFzb24gZm9y IHVzaW5nICdlbmNvdXJhZ2VkJz8gV2h5IG5vdCBSRUNPTU1FTkRFRD8NCj4NCj4gTml0cy9lZGl0 b3JpYWwgY29tbWVudHM6DQo+DQo+IDEuIFRoZSBBYnN0cmFjdCBpbmNsdWRlczoNCj4NCj4gJ1Rv IGRvIHRoaXMgYSBSZW1vdGUgU2VjdXJlIEtleSBJbmZyYXN0cnVjdHVyZSAoQlJTS0kpIGlzIGNy ZWF0ZWQnDQo+DQo+IExhdGVyIGluIHRoZSBkb2N1bWVudCBCUlNLSSBpcyBpZGVmaW5lZCBhcyBh IHByb3RvY29sLiBJdCB3b3VsZCBiZQ0KZ29vZCB0bw0KPiBjbGFyaWZ5IGlmIEJSU0tJID0gQlJT S0kgcHJvdG9jb2wNCj4NCj4gMi4gSW4gU2VjdGlvbiAxIC0gSW50cm9kdWN0aW9uLCAzcmQgcGFy YWdyYXBoOg0KPg0KPiBzL2l0J3MgZGVmYXVsdCBtb2Rlcy9pdHMgZGVmYXVsdCBtb2Rlcy8NCj4g cy9pdCdzIHN0cm9uZ2VzdCBtb2Rlcy9pdHMgc3Ryb25nZXN0IG1vZGVzLw0KPg0KPiAzLiBQbGVh c2UgZXhwYW5kIG5vbi1vYnZpb3VzIGFjcm9ueW1zIGF0IGZpcnN0IG9jY3VycmVuY2U6IEVTVA0K cHJvdG9jb2wsIExMTnMsDQo+IFJFU1QgaW50ZXJmYWNlLCBMREFQLCBHUkFTUCwgQ0RETCwgQ1NS DQo+DQo+IDQuIEkgd291bGQgc3VnZ2VzdCBhbHBoYWJldGljIG9yZGVyIGxpc3Rpbmcgb2YgdGhl IHRlcm1zIGluIHNlY3Rpb24NCjEuMg0KPg0KPiA1LiBTZWN0aW9uIDEuMy4xIC0gYSByZWZlcmVu Y2UgZm9yIExEZXZJRCB3b3VsZCBiZSB1c2VmdWwNCj4NCj4gNi4gU2VjdGlvbiA3Og0KPg0KPiBz L1VzZSBvZiB0aGUgc3VnZ2VzdGVkIG1lY2hhbmlzbS9Vc2Ugb2YgdGhlIHN1Z2dlc3RlZCBtZWNo YW5pc21zLw0KPg0KPg0KDQo= From nobody Tue Oct 15 04:25:32 2019 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 A920B120114; Tue, 15 Oct 2019 04:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=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 kjgAOinCK_iR; Tue, 15 Oct 2019 04:25:28 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) (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 47B7712010D; Tue, 15 Oct 2019 04:25:28 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x9FBPHHF009242 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Oct 2019 13:25:17 +0200 Received: from DEFTHW99ER9MSX.ww902.siemens.net (defthw99er9msx.ww902.siemens.net [139.22.70.94]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x9FBPGmS029819 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Oct 2019 13:25:17 +0200 Received: from DENBGAT9ERHMSX.ww902.siemens.net (139.22.70.143) by DEFTHW99ER9MSX.ww902.siemens.net (139.22.70.94) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 15 Oct 2019 13:25:16 +0200 Received: from DEFTHW99EL1MSX.ww902.siemens.net ([169.254.2.98]) by DENBGAT9ERHMSX.ww902.siemens.net ([139.22.70.143]) with mapi id 14.03.0468.000; Tue, 15 Oct 2019 13:25:15 +0200 From: "Fries, Steffen" To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" , "Brockhaus, Hendrik" , Eliot Lear Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFwFtz52w Date: Tue, 15 Oct 2019 11:25:15 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 11:25:31 -0000 Hi Sheng, We are currently in the process of updating the draft on BRSKI-AE. I would = like to give a status update on this work. I will upload the new version in= the next couple of days. > Name of time slot: BRSKI-AE Updates > Name of draft(s): draft-fries-anima-brski-async-enroll-02 > Time requested: 15 min > Presenter name(s): Steffen Fries Best regards Steffen From nobody Tue Oct 15 09:31:06 2019 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 CDD991201C6 for ; Tue, 15 Oct 2019 09:31:03 -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_HELO_NONE=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 zmY1kcUkCiPQ for ; Tue, 15 Oct 2019 09:31:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE1012010F for ; Tue, 15 Oct 2019 09:31:01 -0700 (PDT) Received: from dooku.sandelman.ca (214-137-20-31.ftth.glasoperator.nl [31.20.137.214]) by relay.sandelman.ca (Postfix) with ESMTPS id 3714E1F455; Tue, 15 Oct 2019 16:30:59 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 492B5A56; Tue, 15 Oct 2019 18:31:52 +0200 (CEST) From: Michael Richardson To: tom petch cc: "ibagdona@gmail.com" , "anima@ietf.org" In-reply-to: <00ef01d5833c$5202f6a0$4001a8c0@gateway.2wire.net> References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <00ef01d5833c$5202f6a0$4001a8c0@gateway.2wire.net> Comments: In-reply-to tom petch message dated "Tue, 15 Oct 2019 09:40:56 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24451.1571157112.1@dooku.sandelman.ca> Date: Tue, 15 Oct 2019 18:31:52 +0200 Message-ID: <24452.1571157112@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Last Call: (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 16:31:04 -0000 Thank you Tom, I'll try to fix the issues you found this week. From nobody Tue Oct 15 20:44:57 2019 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 A7997120849 for ; Tue, 15 Oct 2019 20:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 zYLpD-BNd_fD for ; Tue, 15 Oct 2019 20:44:53 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 6B04212084F for ; Tue, 15 Oct 2019 20:44:53 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id p1so13417072pgi.4 for ; Tue, 15 Oct 2019 20:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=S4hsUb2XrqI3jvOXV2ZdsBWfVOCh5hVW7fX9Ljh6Pi8=; b=oiN8bhffe2FzxohCcsi3wHP1R4mkg3iPz6dQdyWizk3R2x+hWPkmaTSGX9D0OdilWt E1A+2pKB9Z0pmgSxrvCABN4PwnxWfjcUmQMtgUl6CCJYo3tWIaxPefQP5l63XIKjIXfk ncWOSd29irxUE6AvN+LRspyw44g6pOHY1eWwK9eb55l4uidGfdVfmhBVPp8LP5l57WjV 92ZDnsG+327yGNbmMmEF7sgsniOdg4+sj97qcDjbIxTWRFs7qyxQTLAZ52mpyog973LW b8COWji0PuniZO14HZ/cPjIBVfDvoMLUI5rDs59Ta9miIaAHE4g6pUJt7tCKCuMipZGw 75+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=S4hsUb2XrqI3jvOXV2ZdsBWfVOCh5hVW7fX9Ljh6Pi8=; b=bwwsF4zEvEx09E69+hdSmPbffkLVmRefNo4uyu9Q/ddKnlHciZAddkHodcKeQmtAWt wcljfkJy0l1NbI8JicarqubGAJA2vDsS34EAAHqfWar/WtHYstq6aBk0KrYdzVg0GAdv Y6eMAoVzSfPwj63jfOv+MdiNqk4jZQe8nB0XsKtZhhUB0h/kd9xLrJJa6Cpu+NLyBius cQJQ2mmtT5t2COJj8wYPNhOpTSqYw2/Ho0642BXnOYsXXcl9kS+ZzqtiJ9XR7pzbnIiw Fl6H/105v3XyquaAD1ybgBit/+QcHOckZAFmz0BTxqvLKlRpL4OdTHMvmhzdaZyn2MQV HukA== X-Gm-Message-State: APjAAAUS3m7fKRczXDRr0EvznDUMCxCG8XAryrd0gd21/0RRLWp10d1g lyaTrjgi4jvLkQdBtR4IsdzvcLcK X-Google-Smtp-Source: APXvYqzXbDw7gisrEn/PhDMDZ1I4NLaQex6RSbiINa1BLfsfjYiUxap480p6rcujxJDl8q2umTDX6g== X-Received: by 2002:a63:6506:: with SMTP id z6mr41437600pgb.65.1571197492477; Tue, 15 Oct 2019 20:44:52 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id e4sm20547231pff.22.2019.10.15.20.44.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2019 20:44:51 -0700 (PDT) References: <157119680788.27903.13179607309356466653@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <157119680788.27903.13179607309356466653@ietfa.amsl.com> Message-ID: <3da214d4-2c4f-ca4d-a337-0db93efc1a46@gmail.com> Date: Wed, 16 Oct 2019 16:44:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157119680788.27903.13179607309356466653@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] QUADS for GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 03:44:56 -0000 Hi, This week I got a bit bored waiting for a working ACP for use with my GRASP prototype, so I decided to implement some quick and dirty security (QUADS) for GRASP, which is effectively a simple ACP emulated just above the transport layer, using symmetric crypto with shared keys. I have running code (about half a day's work, of which the majority was understanding how to use the Python 'cryptography' module). I need to do some more work before pushing it to GitHub, however. There's a draft (see below). Comments and discussion very welcome. Regards Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-quads-grasp-00.txt Date: Tue, 15 Oct 2019 20:33:27 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Quick and Dirty Security for GRASP Author : Brian Carpenter Filename : draft-carpenter-anima-quads-grasp-00.txt Pages : 5 Date : 2019-10-15 Abstract: A secure substrate is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Security method using symmetric cryptography and preconfigured keys or passwords. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-quads-grasp-00 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-quads-grasp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Oct 16 00:30:04 2019 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 B5DEA12084F for ; Wed, 16 Oct 2019 00:30:01 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 B616NAxwwYxh for ; Wed, 16 Oct 2019 00:30:00 -0700 (PDT) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-pr2fra01on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e18::71a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F2B12002E for ; Wed, 16 Oct 2019 00:29:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F79TXQF0k8RC6l/7Z7WIVkBYetOy9gnuQZtcwGPYwLpdkC5g8WGHsP0u62lM5u8y1x3oiL0Oz/+8SYo3O4uFni+cDCdCPLqjWO7m2HQj5XIzJsG/bcrQHMtQz+MkJJ1LfLMTHtmtN9xdj1YR4eIfVzFNgvK8yGdW/hGkvls4kx/AFtTKV3vis7Ji1CF8y0QcsHdVF+FL5oW+WLqZrssPigVlexjzSz1jRYoFDDfrkvQ0UZgXgiwF+KMGxn6mikIoEV04SgucWbDOEhD546amphN+oUc2nyNFevATkAQUSHhD1ibH38bbXF5f+pvMoCD9KkOAZPXWfw3wMu/O515tfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ckueFEW8+HBEIpugz1LfoUEyNztqQAh7M7sIdSHjmPs=; b=SkP6F6joY97nQlgIqzaxXcxDBeQjmybvCmND+OHXrs58NREJZxyNN0UWiDs1qo0fe6cVept1p9e/S/9Rg6/pi9Qs0Z448XptYv98+HUaTUZuj1RSi5IR+GPMd6DGBc9XcizQP39RoCWpW5QfJZhrOX/6B4z/JbmX/arbRFqrmMfqzD1h0mxUWnlNjExyemoGZY1s8oROSfPYuJqH6L4W5nngHji0GRCLAL98/7c3kc6eVpTybz3FUYl3BCgqXVF5MqmR1TxwY1qnOShMKToNh6tQhQeYzQqUDoIb85ux43pyxOMEBgdJf8rsSrnEeLDkm2HEqb+4bb8jz4jvBh9vrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ckueFEW8+HBEIpugz1LfoUEyNztqQAh7M7sIdSHjmPs=; b=Rkbgbq/xfEDwrJi7tEwQdWb1/+YkpWMlQHhxvAjESkeedGFZfyra6tpsc/SPrMOaZbfgF0ino7n+mkXLROIhjhLstCITD9jfWI/tLvqdVUE+ZgZyUGSBCuo/Cn4bC31diCYH7NCz3TKTdV7WOk2zVeaE/S17J6VsbPJSWQXrbgM= Received: from PR1PR07MB4891.eurprd07.prod.outlook.com (20.177.208.146) by PR1PR07MB5084.eurprd07.prod.outlook.com (20.177.211.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.11; Wed, 16 Oct 2019 07:29:57 +0000 Received: from PR1PR07MB4891.eurprd07.prod.outlook.com ([fe80::9d2d:b0:f626:5b53]) by PR1PR07MB4891.eurprd07.prod.outlook.com ([fe80::9d2d:b0:f626:5b53%7]) with mapi id 15.20.2347.021; Wed, 16 Oct 2019 07:29:57 +0000 From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] Thread-Index: AQHVgKVpo9p21120/EqJatHIKdB8FqdXf2EAgAVkmpA= Date: Wed, 16 Oct 2019 07:29:57 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <1648.1570914140@dooku.sandelman.ca> In-Reply-To: <1648.1570914140@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=laurent.ciavaglia@nokia.com; x-originating-ip: [91.171.237.229] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2b9bc69-d948-4c1e-1a36-08d7520aa57e x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: PR1PR07MB5084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(396003)(39860400002)(376002)(366004)(13464003)(199004)(189003)(51444003)(66066001)(55016002)(52536014)(229853002)(6116002)(25786009)(2906002)(71190400001)(86362001)(14444005)(256004)(71200400001)(3846002)(478600001)(76116006)(2501003)(486006)(476003)(5660300002)(66556008)(66476007)(64756008)(66446008)(66946007)(6436002)(26005)(186003)(53546011)(6506007)(102836004)(110136005)(316002)(7736002)(7696005)(446003)(305945005)(11346002)(99286004)(76176011)(9686003)(14454004)(8676002)(81156014)(6246003)(81166006)(33656002)(8936002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5084; H:PR1PR07MB4891.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lvoVvKCle2XCZRC9ZRcAaNSD1PqWuMeQ9q/JjGr0EVHrhIAfUOAupBKsHkvOjcUrLiENdwK0p5sSOX7tIIZTYEHH4kOCeXpdriRCMBPivmI8oj7KUbum/v4iybB0pUpQsY7bGz5xQ/x77lJy0wQQAYRip02tCTjFJAekZt6/fc4v/XS1EnH2G5VS/wNG/P57xFZewaCQdkZKiHl9WV4mgNWt8t4HxaKKXrWH+tlNX+03mZGYw1LscFhZPpottFF/t3BDa6hTfC3i4sbtXyOy0xjLDpZOzmOygnN/m3K9PPZg77DMGMb51dbQmo+4nCNQ6a8rvW4qB7deX6asHyY7eiVnt1pC+nDTTrhfVdLyts0c21shpDNQDlBBz7ZgXH585OGrPjPVYac0ql8vjhjgJQSviuxl/llsFXJ9cORmTMY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2b9bc69-d948-4c1e-1a36-08d7520aa57e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 07:29:57.4270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nMQ31lNg80DPdIWK2zgi7rc3j0nJIqSj3qndQB6k2bQK9Q5uUV4X0LdMFt126VVg+uEQx4l0JzNSK7+8ifanycDfUWLtDK7O/s478CMmRVs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5084 Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 07:30:02 -0000 > -----Original Message----- > From: Anima On Behalf Of Michael Richardson > Sent: Saturday, October 12, 2019 23:02 > To: anima@ietf.org > Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs] >=20 >=20 > Brian E Carpenter wrote: > > It seems time for the WG to discuss seriously what to do about the > > environment for Autonomic Service Agents (ASAs). We could have this > > discussion around an existing draft, but the main goal would be to > > discuss what the WG needs to do in this area. >=20 > +1 >=20 > I think that we need to spend some high-level time discussing what happen= s > next, now that we have completed the ACP work (ACP, BRSKI, architecture) >=20 +1 too. I think documents draft-carpenter-anima-asa-guidelines and draft-peloso-ani= ma-autonomic-function bring some views about the question. Agree with Brian= we should not limit to these docs for the discussion. There is also recent work started in ETSI ZSM ISG on Enablers (ZSM009-1), S= olutions (ZSM009-2) and Advanced Topics (ZSM009-3) for Closed-Loop Automati= on (not far from the definition of an ASA). Best regards, Laurent. =20 From nobody Wed Oct 16 03:51:30 2019 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 E6AA3120043; Wed, 16 Oct 2019 03:51:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <157122308193.7928.3899842894004508765.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 03:51:21 -0700 Archived-At: Subject: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 10:51:22 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS points. Some comments below were still applicable to -27, but some might be out of date. In 2.3.2: As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in this extension, including the scheme, iauthority, and ipath. As a consideration to constrained systems, this MAY be reduced to only the iauthority, in which case a scheme of "https://" and ipath of "/.well-known/est" is to be assumed, as explained in section Section 5. This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here. This would also avoid the need to use SHOULD and MAY above. In 2.3.2: "https" URI scheme needs a Normative reference. 2.7. Cloud Registrar If the pledge uses a well known URI for contacting a cloud registrar an Implicit Trust Anchor database (see [RFC7030]) MUST be used to authenticate service as described in [RFC6125]. Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified: a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards allowed in any of these? From nobody Wed Oct 16 07:50:14 2019 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 07075120930; Wed, 16 Oct 2019 07:50:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157123740701.7846.2279800529937414763.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 07:50:07 -0700 Archived-At: Subject: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 14:50:08 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS points. Original COMMENT below. ------ I think this document would benefit from two concise lists, with notes about which items in each list are defined in this document and which ones are not defined: (1) what is operationally required of a manufacturer to support BRSKI, and (2) what is operationally required of a domain owner to support BRSKI. = Section 2.3.1 = What precisely is meant by "TPM identification"? Could a citation be provided? = Section 10.1 = "The domain can maintain some privacy since it has not necessarily been authenticated and is not authoritatively bound to the supply chain." What does this mean? That the domain can expect the manufacturer not to trust the domainID because it hasn't been authenticated? = Section 10.2 = "The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer: that an enterprise/ISP purchases routing products is hardly worth mentioning. Deviations would, however, be notable." What does the last sentence mean? From nobody Wed Oct 16 07:56:26 2019 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 D5A3F12002E; Wed, 16 Oct 2019 07:56:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 07:56:17 -0700 Archived-At: Subject: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 14:56:18 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Apologies for the multiple emails, I failed to realize there was a new Gen-ART review for this document. The follow-up from the Gen-ART review seems to indicate that a YANG doctor review of this document is needed and/or that the YANG issues raised by Tom Petch need fixing. Is there a plan to get either of those done? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my original DISCUSS points. Please respond to the full Gen-ART review. Original COMMENT below. ------ I think this document would benefit from two concise lists, with notes about which items in each list are defined in this document and which ones are not defined: (1) what is operationally required of a manufacturer to support BRSKI, and (2) what is operationally required of a domain owner to support BRSKI. = Section 2.3.1 = What precisely is meant by "TPM identification"? Could a citation be provided? = Section 10.1 = "The domain can maintain some privacy since it has not necessarily been authenticated and is not authoritatively bound to the supply chain." What does this mean? That the domain can expect the manufacturer not to trust the domainID because it hasn't been authenticated? = Section 10.2 = "The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer: that an enterprise/ISP purchases routing products is hardly worth mentioning. Deviations would, however, be notable." What does the last sentence mean? From nobody Wed Oct 16 07:57:33 2019 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 E71BD12011F; Wed, 16 Oct 2019 07:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=cooperw.in header.b=COLRUlAm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iUyLeGMC 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 eNcmy3rfraIe; Wed, 16 Oct 2019 07:57:29 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57E4120118; Wed, 16 Oct 2019 07:57:29 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3CBD321AEF; Wed, 16 Oct 2019 10:57:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 16 Oct 2019 10:57:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=z iCoIGJXo8gyqn/IvpyKPm6wYAD7fxgvP9/CZy6t2DM=; b=COLRUlAmyLmgr9HLs YsNH0VoXcyJ0PBXsQGfKNM+UuXxAN5kWKDBx457LIzqc86TGbfMvoAIB4IPkF1TV yagfOn4YTu/TpWklztRi4JdM9FCJDaQ7vJxCI2FtiH0td/Bv+mdIGlNWfs3xjIjK 0IsHvpO2Rg79MxcUQ7gd2q04xS7CbsKuBjw+T1PrsJ0LMBp0ee2i+bWqOm4v7ATv fV1e3NBdIvmgKva2lwO2CDTHSGj0Wx+2P2ZNjM24aaW5e+7i8anCA6vooszjkTAk MisvCqnEO4E52egFvM+4vgaQpFBUbybVdKHI/Ut4LiSqaE6XWUuHljh4HAbAlAy0 GASnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ziCoIGJXo8gyqn/IvpyKPm6wYAD7fxgvP9/CZy6t2 DM=; b=iUyLeGMCndxVN6vu8p/0njOmS1AW3NZcqJ9jijLQiCbZu4+2b4OFi0DcO EXxUxP7RcY7tQMWyT1VJQGNXhp+Q6jjZuslLzuBoro7tzKylk9Yf0JTCA+5i3Svn H/2Uea6BTEVSy/zBZqqUtIvWexzMJJb9vw6fS1eTDFYaKlSJbhPyfbxWbGL7wfyL oHvzxa+5hCbbwhMiTq/bK+SiYdDQsWSB5eFhgaHNMb1xYITbzCW2algiSFxPWwPH d9Lha/E0D/6wN+9Y0BG3kI9X0wUlsDA0bhuwbKJzB7ttXJfJ6cW6Se3Jdv2KWTdh Q86AjBJBk+iwF08iNzV3BHq68JDzA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeehgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekgeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from dhcp-10-150-9-159.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 3088580059; Wed, 16 Oct 2019 10:57:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> Date: Wed, 16 Oct 2019 10:57:23 -0400 Cc: "gen-art@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "ietf@ietf.org" , "anima@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6CF1EF8F-EE0D-4BE6-B2C2-4C91883A881B@cooperw.in> References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> To: tom petch , Dan Romascanu X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 14:57:32 -0000 Dan, thanks for your review. Tom, thanks for your response. I entered a = DISCUSS ballot to make sure the issues with the YANG modules get fixed. = I also noted the need for a response to the full Gen-ART review. Alissa > On Oct 15, 2019, at 5:40 AM, tom petch wrote: >=20 > Dan >=20 > I had a quick look at the YANG and it does indeed need some work IMHO. > I have posted a separate e-mail listing what I saw. >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Dan Romascanu via Datatracker" > Sent: Sunday, October 13, 2019 9:39 AM >=20 >> Reviewer: Dan Romascanu >> Review result: Ready with Issues >>=20 >> 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. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-anima-bootstrapping-keyinfra-?? >> Reviewer: Dan Romascanu >> Review Date: 2019-10-13 >> IETF LC End Date: None >> IESG Telechat date: 2019-10-17 >>=20 >> Summary: Ready with Issues >>=20 >> This document specifies automated bootstrapping of an Autonomic > Control Plane >> by creating a Remote Secure Key Infrastructure (acronym BRSKI) using >> manufacturer installed X.509 certificates, in combination with a > manufacturer's >> authorizing service, both online and offline. >>=20 >> Christian Huitema and Jari Arkko have performed early reviews of > previous >> versions of the document for SecDir and Gen-ART. As far as I can = tell, > most if >> not all of their major concerns concerning applicability and security > have been >> addressed in the latest versions. A few more minor issues described > below would >> better be clarified before approval. >>=20 >> I also observe that the document has consistent Operational > implications but >> there is no OPS-DIR review so far, as well as a YANG module and > several other >> references to YANG, but there is no YANG Doctors review. I hope that > these will >> be available prior to the IESG review. >>=20 >> Major issues: >>=20 >> Minor issues: >>=20 >> 1. The Pledge definition in section 1.2: >>=20 >>> Pledge: The prospective device, which has an identity installed at >> the factory. >>=20 >> while in the Introduction: >>=20 >>> ... new (unconfigured) devices that are called pledges in this >> document. >>=20 >> These two definitions seem different. The definition in 1.2 does not > include >> the fact that the device is 'new (unconfigured'. Also, arguably > 'identity >> installed at the factory' may be considered a form of configuration. >>=20 >> 2. The document lacks an Operational Considerations section, which I > believe is >> needed, taking into consideration the length and complexity of the > document. >> There are many operational issues spread across the document > concerning the >> type and resources of devices, speed of the bootstrapping process, > migration >> pass, impact on network operation. I suggest to consider adding such = a > section >> pointing to the place where these issues are discussed and adding the > necessary >> information if missing. Appendix A.1 in RFC 5706 can be used as a > checklist of >> the issues to be discussed in such a section. >>=20 >> 3. Section 5.4: >>=20 >>> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is >> REQUIRED. >>=20 >> What is the reason for using 'encouraged'? Why not RECOMMENDED? >>=20 >> Nits/editorial comments: >>=20 >> 1. The Abstract includes: >>=20 >> 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' >>=20 >> Later in the document BRSKI is idefined as a protocol. It would be > good to >> clarify if BRSKI =3D BRSKI protocol >>=20 >> 2. In Section 1 - Introduction, 3rd paragraph: >>=20 >> s/it's default modes/its default modes/ >> s/it's strongest modes/its strongest modes/ >>=20 >> 3. Please expand non-obvious acronyms at first occurrence: EST > protocol, LLNs, >> REST interface, LDAP, GRASP, CDDL, CSR >>=20 >> 4. I would suggest alphabetic order listing of the terms in section > 1.2 >>=20 >> 5. Section 1.3.1 - a reference for LDevID would be useful >>=20 >> 6. Section 7: >>=20 >> s/Use of the suggested mechanism/Use of the suggested mechanisms/ >>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 16 08:19:09 2019 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 1350C12002E; Wed, 16 Oct 2019 08:19:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <157123914799.7818.11835598135548310108.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 08:19:07 -0700 Archived-At: Subject: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 15:19:08 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) §1.3.2 (Constrained environments): "Those types of networks SHOULD NOT use this solution." The use of Normative language seems out of place: if this document is not applicable to constrained environments, then there's no way to enforce (SHOULD NOT)... s/SHOULD NOT/should not (2) §2.1: In Figure 2, should the "rejected" action be a result of step 3 (instead of 2)? | | | +------v-------+ | | (2) Identity | ^------------+ | | rejected +------+-------+ | | | +------v-------+ | | (3) Request | | | Join | | +------+-------+ | | (3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]./The serialNumber field is defined in [RFC5280], and is a recommended field in [IDevID]. Note that SHOULD is not used properly here because it does not have a Normative quality (as it refers to the other document). I'm assuming that the replacement is "recommended" (per rfc2119), but it may be "required". (4) [nits] s/Bootstrapping to is complete/Bootstrapping is complete §1: "This bootstrap process satisfies the [RFC7575] section 3.3 of making all operations secure by default." Satisfies the what? Requirement, maybe? s/explains the details applicability/explains the detailed applicability s/out-of-band" information"/out-of-band" information s/This section applies is normative for uses with an ANIMA ACP./This section is normative for uses with an ANIMA ACP. s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Manufacturer Usage Description Specification s/might be previous deployed/might be previously deployed s/were receives by/were received from s/{{...}}/[...] From nobody Wed Oct 16 08:50:29 2019 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 69318120802; Wed, 16 Oct 2019 08:50:27 -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, SPF_HELO_NONE=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 VoQmi0ufxDpW; Wed, 16 Oct 2019 08:50:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5910D1207FD; Wed, 16 Oct 2019 08:50:25 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-25-21.mtg.ripe.net [193.0.25.21]) by relay.sandelman.ca (Postfix) with ESMTPS id 3A0DA1F455; Wed, 16 Oct 2019 15:50:24 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 859F1D34; Wed, 16 Oct 2019 17:51:17 +0200 (CEST) From: Michael Richardson To: Alissa Cooper cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-reply-to: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> Comments: In-reply-to Alissa Cooper via Datatracker message dated "Wed, 16 Oct 2019 07:56:17 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 16 Oct 2019 17:51:17 +0200 Message-ID: <19715.1571241077@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 15:50:28 -0000 --=-=-= Content-Type: text/plain Alissa Cooper via Datatracker wrote: > Apologies for the multiple emails, I failed to realize there was a new Gen-ART > review for this document. The follow-up from the Gen-ART review seems to > indicate that a YANG doctor review of this document is needed and/or that the > YANG issues raised by Tom Petch need fixing. Is there a plan to get either of > those done? I'm working on those fixes today. Also at RIPE79, and have two more conference calls, so I don't think I'll get it done before your call tomorrow, but it could happen :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2nPHUACgkQlUzhVv38 QpA6mAf6AoSh8deHi8Qh8dgWE7ZwCj5/YtqQTY37W9DdKsfW2nE5mtAHwphc10oR dlwWzHP9DaSI3c+VoDxS0IGgZ/XWu3eDzM7+3K8BCb7w48fkJYS0YRU1HCoNzMz8 UJVCHFxdlLs4MnklyTh4E15Z+e6ql1//1v8c9xxHa3pfEB9jvOPMv9HJkNZ+Btl7 PwCqZ4CAEA+zhFS27nEFk/uW6aTzXXgT57ceiJpC/K2Pe+ppNgMWQAeDrbyG2tHq IW5P+C7xfKzgxCynd+2xsXM0z7esW3C6bj3YZnIDYa0LS24Jxybrh2H8VN/T6+hm +DEOo8jgIbHcV2SsDHrV3fIJnS7jXg== =x3AI -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 16 11:04:42 2019 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 571BB12080C; Wed, 16 Oct 2019 11:04:40 -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_HELO_NONE=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 x4f8LWZGwySP; Wed, 16 Oct 2019 11:04:37 -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 B922D1200FD; Wed, 16 Oct 2019 11:04:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 483713897A; Wed, 16 Oct 2019 14:02:11 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0ABF6B54; Wed, 16 Oct 2019 14:04:35 -0400 (EDT) To: anima@ietf.org, iesg@ietf.org References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> From: Michael Richardson Message-ID: <07d95e86-28a5-6e7d-fb62-6915192e1c02@sandelman.ca> Date: Wed, 16 Oct 2019 14:04:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <157095596011.20750.2703747454081790983@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 18:04:41 -0000 On 2019-10-13 4:39 a.m., Dan Romascanu via Datatracker wrote: > Reviewer: Dan Romascanu > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area Thank you for this. I will the majority of your issues with a -29 that I'll post this week. Given that most of your issues are minor, I don't think that they will affect the views of the IESG on Thursday, so I might not post it before Thursday's IESG call. Here is a diff though: https://tinyurl.com/y5l4xz3z > I also observe that the document has consistent Operational implications but > there is no OPS-DIR review so far, as well as a YANG module and several other > references to YANG, but there is no YANG Doctors review. I hope that these will > be available prior to the IESG review. On the topic of YANG Doctor: I think that we did ask for a review at some point a long time ago.. Kent Watsen, one of the authors is also one of the YANG Doctors, so I feel pretty confident that we got that part right, but I agree, we could have asked more clearly. (Update: Tom has done one, and I'll act on it) I don't know why we have no OPS-DIR review. I see in the DT that an ARTART review is pending as well for today. > 1. The Pledge definition in section 1.2: > >> Pledge: The prospective device, which has an identity installed at > the factory. > > while in the Introduction: > >> ... new (unconfigured) devices that are called pledges in this > document. > > These two definitions seem different. The definition in 1.2 does not include > the fact that the device is 'new (unconfigured'. Also, arguably 'identity > installed at the factory' may be considered a form of configuration. To me IDevID that is installed is not really any different than the fact that the device has firmware loaded. If a router needs to be told in the factory that it is a 24+4 switch, I don't consider that configuration, and this is really no different. There is no site-specific configuration is the point. I've made the text between the two places a bit more consistent. > 2. The document lacks an Operational Considerations section, which I believe is > needed, taking into consideration the length and complexity of the document. > There are many operational issues spread across the document concerning the > type and resources of devices, speed of the bootstrapping process, migration > pass, impact on network operation. I suggest to consider adding such a section > pointing to the place where these issues are discussed and adding the necessary > information if missing. Appendix A.1 in RFC 5706 can be used as a checklist of > the issues to be discussed in such a section. I took a look through 5706, and through the Appendix A.1. (I really like the RFC2119-non-text in 5706, and I will use it myself) I had already started two documents: Operational Considerations for Manufacturer Authorized Signing Authority, and Operational Considerations for BRSKI Registrar, but they are just skeletons. I think that a great deal of the ANIMA ACP Operational Considerations are covered in the ACP document. So while I agree that we need the content you are asking for, I'm reluctant to add this new section at this time. Part of this is because I'm not sure that we know enough yet: there are only two known implementations of MASA, and we still have some interop gotchas that we haven't had time to solve those yet. Or to put it another way: trying to make up Operational Considerations is probably going to get in the way of actually gaining operational experience :-) > 3. Section 5.4: > >> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > REQUIRED. > > What is the reason for using 'encouraged'? Why not RECOMMENDED? RECOMMENDED is a synonym for SHOULD. SHOULD is too strong at this point. There are no technical reasons why TLS 1.2 is good enough if you implement it wisely. We already had this discussion with SecAD, etc. A product manager might delay shipping in order to wait for the TLS 1.3 libraries to get through FIPS if we wrote SHOULD, etc. > Nits/editorial comments: > > 1. The Abstract includes: > > 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' > > Later in the document BRSKI is identified as a protocol. It would be good to > clarify if BRSKI = BRSKI protocol I have changed the abstract to say: To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, pronounced "brewski". > 2. In Section 1 - Introduction, 3rd paragraph: > > s/it's default modes/its default modes/ > s/it's strongest modes/its strongest modes/ fixed. > 3. Please expand non-obvious acronyms at first occurrence: EST protocol, Seems to be done correctly. > LLNs, fixed > REST interface, updated, and added reference. > LDAP, This is used once to say that we don't support it, despite RFC5280 describing it. We don't expand HTTP or FTP on that line though. I feel that the RFC5280 reference is good here. > GRASP, CDDL, CSR done. > 4. I would suggest alphabetic order listing of the terms in section 1.2 okay. Done. (everyone sing the alphabet song...) > > 5. Section 1.3.1 - a reference for LDevID would be useful added. It's a 802.1AR term. > 6. Section 7: > > s/Use of the suggested mechanism/Use of the suggested mechanisms/ fixed. I will post -29 once I have dealt with the new DISCUSS comments and YANG Doctor comments. From nobody Wed Oct 16 11:23:22 2019 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 0672A12092C; Wed, 16 Oct 2019 11:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 32SDNGotIJ46; Wed, 16 Oct 2019 11:23:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F837120116; Wed, 16 Oct 2019 11:23:02 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:64:42:5650:5f0a:e07a:7e5f]) by relay.sandelman.ca (Postfix) with ESMTPS id 570051F455; Wed, 16 Oct 2019 18:23:00 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 13225E8B; Wed, 16 Oct 2019 20:23:53 +0200 (CEST) From: Michael Richardson To: Alexey Melnikov , "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-reply-to: <157122308193.7928.3899842894004508765.idtracker@ietfa.amsl.com> References: <157122308193.7928.3899842894004508765.idtracker@ietfa.amsl.com> Comments: In-reply-to Alexey Melnikov via Datatracker message dated "Wed, 16 Oct 2019 03:51:21 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 16 Oct 2019 20:23:53 +0200 Message-ID: <30385.1571250233@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Alexey Melnikov's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 18:23:10 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov via Datatracker wrote: > Some comments below were still applicable to -27, but some might be out of date. > In 2.3.2: (I've updated the text below from the -28 version, which does not use IRLs) doc> A complete URI MAY be in this extension, including the 'scheme', doc> 'authority', and 'path', The complete URI will typically be used in doc> diagnostic or experimental situations. Typically, (and in doc> consideration to constrained systems), this SHOULD be reduced to only doc> the 'authority', in which case a scheme of "https://" ([RFC7230] doc> section 2.7.3) and 'path' of "/.well-known/est" is to be assumed, as doc> explained in Section 5. > This is not a problem per se, but mixing absolute URIs and iauthority in the > same field makes me rather uncomfortable. Maybe you can define ABNF for this > field to make it crystally clear what is allowed here. This would also avoid > the need to use SHOULD and MAY above. The above reference to section 5 is vague, and I think it has gone lame, and I've removed it. There is a single sentence in 5.0 that probably used to say more. The logic here (on the Registrar): if(strchr(text, '/')) { /* WHOLE URL is present */ url = text; } else snprintf(somebuffer, sizeof(somebuffer), "https://%s/.well-known/est", text); url = somebuffer; } ruby: def self.canonicalize_masa_url(url) return nil unless url if !url.blank? and !url.include?("/") url = "https://" + url + "/.well-known/est/" end # always have a trailing / unless url[-1]=='/' url = url + '/' end url end I'll have to think about how to explain this in ABNF. I would need to reference the RFC7230 ABNF and create some hybrid item. It seems like a lot. > In 2.3.2: "https" URI scheme needs a Normative reference. I think that the new text deals with this already. > 2.7. Cloud Registrar doc> If the pledge uses a well known URI for contacting a cloud registrar doc> an Implicit Trust Anchor database (see [RFC7030]) MUST be used to doc> authenticate service as described in [RFC6125]. > Just referencing RFC 6125 is not clear enough, as there are lots of parameters > that need to be specified: > a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed > b) are wildcards allowed in any of these? I've added text:n The use of a DNS-ID for validation is appropriate, and it may include wildcard compnents on the left-mode side. {i.e. what browsers and curl does. I feel that surely this must be specified somewhere more precisely?} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2nYDgACgkQlUzhVv38 QpDjCAgAq9gQTaobkGB5Ve86BZOMd6N6mP6d7n9oeHgal9tr5S5iVMYdIpd2JNY0 Xct4s8t9okeUxXSf0eySiHg0ct4AXdxM2OM9x6+tz8AIhSnqiHKHmJwx2s7HzMJU 9acEnJ9d2mgNk5ITpUSaMHnC2vPnoI9QTSWrnDZWxELPF/cHm2qJbTxy1u7B8cB/ 4WDq1AGN2e9l6DwY5zGTq4RCGHaD9lUKIWYpC4M4aECP5m8WxNGi/cyjK+n66n0E W52NVPca8Yr8ZVuILwQOrdQ1t6Jb5GLEy6LUFAyDEZLllEBui5kVCMxLfhXgpWWT q35BWzOpda2zjSOx65MaNkvbPnPpKA== =ApHx -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 16 12:47:06 2019 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 DC1CC1200FA; Wed, 16 Oct 2019 12:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 5lJy--AaCSp0; Wed, 16 Oct 2019 12:47:01 -0700 (PDT) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 79E9D120020; Wed, 16 Oct 2019 12:47:01 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id o16so3871574ilq.7; Wed, 16 Oct 2019 12:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+3YvdDGINQXZbw3/AP1V+z61W+jgUY0aNfbavWebm9Y=; b=UBrrjoH0rFGfy6GNj2KKW2vf6inUd9XalZD4aLF3nNOkKgBgvgWuUrE37SUqwT+86G tehD+D62fKCsjgln0DnndZIKXx7Cd+8+EH4dw/gG/Z/veT1uTgimhPEw0lp5trXeiv9O IoD4Kc1JBIwvoEg9nN9BOb/2Jtg/It5tioZ2jBbmiz8cItj+BuanlcBSzc0JBk0HWCE1 yLNv3H9j1SDe7KdQRgrCQ5CdhOzMd9Tj7GL4uuFGS+ZExeFzjgFgidbOaU1FPTdx98H5 WhJi57jLrVCjgnwQdy3MbqewuKbmH+NkNqtr08mbb3Nmx+dMkiX/eRdr0qZ53scEVj+5 YsJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+3YvdDGINQXZbw3/AP1V+z61W+jgUY0aNfbavWebm9Y=; b=YT6Jr4y9UtR6qy/O2eQw/jrwSAOiXOHGkfGz2h6OAnWZQpKC7DSeNczqvZOff581aL gag3UG96ZdjReXKk8zmXKME3Kh+LEQnYvizHs1h/c48l6Qlj3cwL2NFUQYHlYo0d3IQ2 qXmv96nwKuFwBDp5VEoYgG96r1BgytE1ZHMyjhCxdgwIesXD35N+NPpd5sVEgKdzUUI9 +qu2CjYfr4xL2xP8k2LT/PVdECNgsrBKI/wKxCTKv+DBkVOSj+fyrn6d4HOM+v6GAifj rr33uvcPxNMGQrWnEDbTRM9pnyE7ciL+vlvbCAuF1kaunwpXO+m/A8Um+hHVuJdNg9I4 veUQ== X-Gm-Message-State: APjAAAVi1joULEm1q+4Qn1NDTDa2x6uhpoGsfPOwRRmTBT98UsqQdfEA bTa+4z5lrjydLgrBZzOaCXLXLCVwmZNcqoi8yUs= X-Google-Smtp-Source: APXvYqwPUUdfdBJjqzSzzc1gU+v7BfNfieesvbhi9tu0oc3fAIsBVLiTqgwi78txoZVbIZaaqrujQdZ+tTseWR+BYwY= X-Received: by 2002:a92:83c5:: with SMTP id p66mr14251805ilk.204.1571255220722; Wed, 16 Oct 2019 12:47:00 -0700 (PDT) MIME-Version: 1.0 References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> <07d95e86-28a5-6e7d-fb62-6915192e1c02@sandelman.ca> In-Reply-To: <07d95e86-28a5-6e7d-fb62-6915192e1c02@sandelman.ca> From: Dan Romascanu Date: Wed, 16 Oct 2019 22:46:48 +0300 Message-ID: To: Michael Richardson Cc: anima@ietf.org, The IESG Content-Type: multipart/alternative; boundary="00000000000048630805950c5d64" Archived-At: Subject: Re: [Anima] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 19:47:04 -0000 --00000000000048630805950c5d64 Content-Type: text/plain; charset="UTF-8" Hi Michael, Sounds good. Thanks for addressing my comments. Regards, Dan On Wed, Oct 16, 2019 at 9:04 PM Michael Richardson wrote: > On 2019-10-13 4:39 a.m., Dan Romascanu via Datatracker wrote: > > Reviewer: Dan Romascanu > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Thank you for this. > I will the majority of your issues with a -29 that I'll post this week. > Given that most of your issues are minor, I don't think that they will > affect the views of the IESG on Thursday, so I might not post it before > Thursday's IESG call. > > Here is a diff though: https://tinyurl.com/y5l4xz3z > > > I also observe that the document has consistent Operational implications > but > > there is no OPS-DIR review so far, as well as a YANG module and several > other > > references to YANG, but there is no YANG Doctors review. I hope that > these will > > be available prior to the IESG review. > > On the topic of YANG Doctor: I think that we did ask for a review at > some point a long time ago.. Kent Watsen, one of the authors is also one > of the YANG Doctors, so I feel pretty confident that we got that part > right, but I agree, we could have asked more clearly. (Update: Tom has > done one, and I'll act on it) > > I don't know why we have no OPS-DIR review. > I see in the DT that an ARTART review is pending as well for today. > > > 1. The Pledge definition in section 1.2: > > > >> Pledge: The prospective device, which has an identity installed at > > the factory. > > > > while in the Introduction: > > > >> ... new (unconfigured) devices that are called pledges in this > > document. > > > > These two definitions seem different. The definition in 1.2 does not > include > > the fact that the device is 'new (unconfigured'. Also, arguably 'identity > > installed at the factory' may be considered a form of configuration. > > To me IDevID that is installed is not really any different than the fact > that the device has firmware loaded. If a router needs to be told in the > factory that it is a 24+4 switch, I don't consider that configuration, > and this is really no different. > There is no site-specific configuration is the point. > I've made the text between the two places a bit more consistent. > > > 2. The document lacks an Operational Considerations section, which I > believe is > > needed, taking into consideration the length and complexity of the > document. > > There are many operational issues spread across the document concerning > the > > type and resources of devices, speed of the bootstrapping process, > migration > > pass, impact on network operation. I suggest to consider adding such a > section > > pointing to the place where these issues are discussed and adding the > necessary > > information if missing. Appendix A.1 in RFC 5706 can be used as a > checklist of > > the issues to be discussed in such a section. > > I took a look through 5706, and through the Appendix A.1. > (I really like the RFC2119-non-text in 5706, and I will use it myself) > > I had already started two documents: Operational Considerations for > Manufacturer Authorized Signing Authority, and Operational > Considerations for BRSKI Registrar, but they are just skeletons. > I think that a great deal of the ANIMA ACP Operational Considerations > are covered in the ACP document. > > So while I agree that we need the content you are asking for, I'm > reluctant to add this new section at this time. Part of this is because > I'm not sure that we know enough yet: there are only two known > implementations of MASA, and we still have some interop gotchas that we > haven't had time to solve those yet. > Or to put it another way: trying to make up Operational Considerations > is probably going to get in the way of actually gaining operational > experience :-) > > > > 3. Section 5.4: > > > >> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > > REQUIRED. > > > > What is the reason for using 'encouraged'? Why not RECOMMENDED? > > RECOMMENDED is a synonym for SHOULD. > SHOULD is too strong at this point. There are no technical reasons why > TLS 1.2 is good enough if you implement it wisely. > We already had this discussion with SecAD, etc. > A product manager might delay shipping in order to wait for the TLS 1.3 > libraries to get through FIPS if we wrote SHOULD, etc. > > > Nits/editorial comments: > > > > 1. The Abstract includes: > > > > 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' > > > > Later in the document BRSKI is identified as a protocol. It would be > good to > > clarify if BRSKI = BRSKI protocol > > I have changed the abstract to say: > > To do this a Secure Key Infrastructure is > bootstrapped. This is done using manufacturer installed > X.509 certificates, in combination with a manufacturer's > authorizing > service, both online and offline. We call this process the > Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, > pronounced "brewski". > > > > 2. In Section 1 - Introduction, 3rd paragraph: > > > > s/it's default modes/its default modes/ > > s/it's strongest modes/its strongest modes/ > > fixed. > > > 3. Please expand non-obvious acronyms at first occurrence: EST protocol, > > Seems to be done correctly. > > > LLNs, > > fixed > > > REST interface, > updated, and added reference. > > > LDAP, > > This is used once to say that we don't support it, despite RFC5280 > describing it. We don't expand HTTP or FTP on that line though. > I feel that the RFC5280 reference is good here. > > > GRASP, CDDL, CSR > > done. > > > > 4. I would suggest alphabetic order listing of the terms in section 1.2 > > okay. Done. (everyone sing the alphabet song...) > > > > > 5. Section 1.3.1 - a reference for LDevID would be useful > > added. It's a 802.1AR term. > > > 6. Section 7: > > > > s/Use of the suggested mechanism/Use of the suggested mechanisms/ > > fixed. > I will post -29 once I have dealt with the new DISCUSS comments and YANG > Doctor comments. > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --00000000000048630805950c5d64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

Sounds good. Tha= nks for addressing my comments.

Regards,

Dan


On Wed, Oct 16, 2019 at 9:04 PM Mic= hael Richardson <mcr+ietf@san= delman.ca> wrote:
On 2019-10-13 4:39 a.m., Dan Romascanu via Datatracker wrote: > Reviewer: Dan Romascanu
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
Thank you for this.
I will the majority of your issues with a -29 that I'll post this week.=
Given that most of your issues are minor, I don't think that they will =
affect the views of the IESG on Thursday, so I might not post it before Thursday's IESG call.

Here is a diff though:=C2=A0 https://tinyurl.com/y5l4xz3z

> I also observe that the document has consistent Operational implicatio= ns but
> there is no OPS-DIR review so far, as well as a YANG module and severa= l other
> references to YANG, but there is no YANG Doctors review. I hope that t= hese will
> be available prior to the IESG review.

On the topic of YANG Doctor: I think that we did ask for a review at
some point a long time ago.. Kent Watsen, one of the authors is also one of the YANG Doctors, so I feel pretty confident that we got that part
right, but I agree, we could have asked more clearly. (Update: Tom has
done one, and I'll act on it)

I don't know why we have no OPS-DIR review.
I see in the DT that an ARTART review is pending as well for today.

> 1. The Pledge definition in section 1.2:
>
>> Pledge:=C2=A0 The prospective device, which has an identity instal= led at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the factory.
>
> while in the Introduction:
>
>> ... new (unconfigured) devices that are called pledges in this
>=C2=A0 =C2=A0 =C2=A0document.
>
> These two definitions seem different. The definition in 1.2 does not i= nclude
> the fact that the device is 'new (unconfigured'. Also, arguabl= y 'identity
> installed at the factory' may be considered a form of configuratio= n.

To me IDevID that is installed is not really any different than the fact that the device has firmware loaded. If a router needs to be told in the factory that it is a 24+4 switch, I don't consider that configuration, =
and this is really no different.
There is no site-specific configuration is the point.
I've made the text between the two places a bit more consistent.

> 2. The document lacks an Operational Considerations section, which I b= elieve is
> needed, taking into consideration the length and complexity of the doc= ument.
> There are many operational issues spread across the document concernin= g the
> type and resources of devices, speed of the bootstrapping process, mig= ration
> pass, impact on network operation. I suggest to consider adding such a= section
> pointing to the place where these issues are discussed and adding the = necessary
> information if missing. Appendix A.1 in RFC 5706 can be used as a chec= klist of
> the issues to be discussed in such a section.

I took a look through 5706, and through the Appendix A.1.
(I really like the RFC2119-non-text in 5706, and I will use it myself)

I had already started two documents: Operational Considerations for
Manufacturer Authorized Signing Authority, and Operational
Considerations for BRSKI Registrar, but they are just skeletons.
I think that a great deal of the ANIMA ACP Operational Considerations
are covered in the ACP document.

So while I agree that we need the content you are asking for, I'm
reluctant to add this new section at this time.=C2=A0 Part of this is becau= se
I'm not sure that we know enough yet: there are only two known
implementations of MASA, and we still have some interop gotchas that we haven't had time to solve those yet.
Or to put it another way: trying to make up Operational Considerations
is probably going to get in the way of actually gaining operational
experience :-)


> 3. Section 5.4:
>
>> Use of TLS 1.3 (or newer) is encouraged.=C2=A0 TLS 1.2 or newer is=
>=C2=A0 =C2=A0 =C2=A0REQUIRED.
>
> What is the reason for using 'encouraged'? Why not RECOMMENDED= ?

RECOMMENDED is a synonym for SHOULD.
SHOULD is too strong at this point.=C2=A0 There are no technical reasons wh= y
TLS 1.2 is good enough if you implement it wisely.
We already had this discussion with SecAD, etc.
A product manager might delay shipping in order to wait for the TLS 1.3 libraries to get through FIPS if we wrote SHOULD, etc.

> Nits/editorial comments:
>
> 1. The Abstract includes:
>
> 'To do this a Remote Secure Key Infrastructure (BRSKI) is created&= #39;
>
> Later in the document BRSKI is identified as a protocol. It would be g= ood to
> clarify if BRSKI =3D BRSKI protocol

I have changed the abstract to say:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To do this a Secure Key Infrastructure is=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bootstrapped.=C2=A0 This is done using ma= nufacturer installed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X.509 certificates, in combination with a= manufacturer's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorizing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0service, both online and offline.=C2=A0 W= e call this process the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bootstrapping Remote Secure Key Infrastru= cture (BRSKI) protocol,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounced "brewski".


> 2. In Section 1 - Introduction, 3rd paragraph:
>
> s/it's default modes/its default modes/
> s/it's strongest modes/its strongest modes/

fixed.

> 3. Please expand non-obvious acronyms at first occurrence: EST protoco= l,

Seems to be done correctly.

> LLNs,

fixed

> REST interface,
updated, and added reference.

> LDAP,

This is used once to say that we don't support it, despite RFC5280
describing it.=C2=A0 We don't expand HTTP or FTP on that line though. I feel that the RFC5280 reference is good here.

=C2=A0> GRASP, CDDL, CSR

done.


> 4. I would suggest alphabetic order listing of the terms in section 1.= 2

okay. Done.=C2=A0 =C2=A0(everyone sing the alphabet song...)

>
> 5. Section 1.3.1 - a reference for LDevID would be useful

added. It's a 802.1AR term.

> 6. Section 7:
>
> s/Use of the suggested mechanism/Use of the suggested mechanisms/

fixed.
I will post -29 once I have dealt with the new DISCUSS comments and YANG Doctor comments.

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--00000000000048630805950c5d64-- From nobody Wed Oct 16 14:11:49 2019 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 47F06120111; Wed, 16 Oct 2019 14:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 whmY3YkKMCay; Wed, 16 Oct 2019 14:11:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7976D12007C; Wed, 16 Oct 2019 14:11:45 -0700 (PDT) Received: from dooku.sandelman.ca (214-137-20-31.ftth.glasoperator.nl [31.20.137.214]) by relay.sandelman.ca (Postfix) with ESMTPS id B5E781F455; Wed, 16 Oct 2019 21:11:43 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3B7CF1034; Wed, 16 Oct 2019 23:12:37 +0200 (CEST) From: Michael Richardson To: Alissa Cooper cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-reply-to: <157123740701.7846.2279800529937414763.idtracker@ietfa.amsl.com> References: <157123740701.7846.2279800529937414763.idtracker@ietfa.amsl.com> Comments: In-reply-to Alissa Cooper via Datatracker message dated "Wed, 16 Oct 2019 07:50:07 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 16 Oct 2019 23:12:37 +0200 Message-ID: <10034.1571260357@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 21:11:47 -0000 --=-=-= Content-Type: text/plain Alissa Cooper via Datatracker wrote: > I think this document would benefit from two concise lists, with notes about > which items in each list are defined in this document and which ones are not > defined: (1) what is operationally required of a manufacturer to support BRSKI, > and (2) what is operationally required of a domain owner to support > BRSKI. Please see a diff at: https://tinyurl.com/y5l4xz3z I will not get to the YANG Doctor review before the IESG call tomorrow, so I won't post -29 until I do. I have add a section with this list: 9.1. Operational Requirements . . . . . . . . . . . . . . . . 70 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 70 9.1.2. Domain Owner Operational Requirements . . . . . . . . 71 9.1.3. Device Operational Requirements . . . . . . . . . . . 72 I have placed it under the Applicability statement to ACP, as I think that other users might need to change things. > = Section 2.3.1 = > What precisely is meant by "TPM identification"? Could a citation be > provided? In -28 we don't have the words TPM identification. We ripped the TPM identification out a few revisions ago. It was a point form about a subjectAltName that might come from the 4108 HardwareModuleName. The text was there as a workaround for legacy/deployed TPM modules out there; it turns out the concerns were ill-founded. > = Section 10.1 = > "The domain can maintain some privacy since it has not necessarily been > authenticated and is not authoritatively bound to the supply chain." > What does this mean? That the domain can expect the manufacturer not to trust > the domainID because it hasn't been authenticated? A domain that didn't want to leave so many traces in the audit-log could cycle through different key pairs much like we do with IPv6 temporary addresses. > = Section 10.2 = > "The above situation is to be distinguished from a residential/ > individual person who registers a device from a manufacturer: that an > enterprise/ISP purchases routing products is hardly worth mentioning. > Deviations would, however, be notable." > What does the last sentence mean? That text was changed in -28 to: The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer. Individuals do not tend to have multiple offices, and their registrar is likely on the same network as the device. A manufacturer that sells switching/routing products to enterprises should hardly be surprised if additional purchases switching/routing products are purchased. Deviations from a historical trend or an establish baseline would, however, be notable. -- ] 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 =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2nh8QACgkQlUzhVv38 QpA9LQgAixLyEED7N7YJfCYI0NPFu+Db+d/JyknlakQ+mJZ9omxeWYD6FlCCfcBT hMQPx1Rm0NY2kXD8rp+l9ke1Y2r2VfYegJ2rHocoJ2u7JC+CgF/6oQwOLLbLaHvZ qw3aXBHT4gVhLMbSRhc8iASls2k8NG9za/H8zFfRyaa5ei9azQmedih6PXLaRpIg xDeMqHN5+sfxp7LBv0QJk4Ixf4uA5Q9mD+a2oInWdI+zdJuTUlLLzZvo/vsv/hAT kjOe+hjafpiAx1dMwm4oi+Bmby1YH0wqORxUhWZmhaReIy71Ud5SQIJRQwzUj+RX pO4VwpHvuAWiCT+/BaB/k3nFbN0evA== =AWh3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 16 14:34:23 2019 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 4FB7A12083B; Wed, 16 Oct 2019 14:34:19 -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, SPF_HELO_NONE=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 QmEiAFfeVFoc; Wed, 16 Oct 2019 14:34:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C895120833; Wed, 16 Oct 2019 14:34:16 -0700 (PDT) Received: from dooku.sandelman.ca (214-137-20-31.ftth.glasoperator.nl [31.20.137.214]) by relay.sandelman.ca (Postfix) with ESMTPS id 77ECA1F455; Wed, 16 Oct 2019 21:34:13 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id B0BAC1034; Wed, 16 Oct 2019 23:35:06 +0200 (CEST) From: Michael Richardson To: Alvaro Retana cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima@ietf.org, anima-chairs@ietf.org In-reply-to: <157123914799.7818.11835598135548310108.idtracker@ietfa.amsl.com> References: <157123914799.7818.11835598135548310108.idtracker@ietfa.amsl.com> Comments: In-reply-to Alvaro Retana via Datatracker message dated "Wed, 16 Oct 2019 08:19:07 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 16 Oct 2019 23:35:06 +0200 Message-ID: <11343.1571261706@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 21:34:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alvaro Retana via Datatracker wrote: > (1) =C2=A71.3.2 (Constrained environments): "Those types of networks = SHOULD NOT use > this solution." The use of Normative language seems out of place: if= this > document is not applicable to constrained environments, then there's = no way to > enforce (SHOULD NOT)... s/SHOULD NOT/should not okay, fixed. > (2) =C2=A72.1: In Figure 2, should the "rejected" action be a result = of step 3 > (instead of 2)? The Pledge provides it's identity to the JRC at step 2. (Effectively during the TLS setup) If the JRC doesn't like (invalid manufacturer), then the TLS connection does not complete. It doesn't get to attempt to join. If the voucher doesn't check out, then it's Enroll Failure. > (3) s/The serialNumber fields is defined in [RFC5280], and is a SHOUL= D field in > [IDevID]./The serialNumber field is defined in [RFC5280], and is a re= commended > field in [IDevID]. Note that SHOULD is not used properly here becau= se it does > not have a Normative quality (as it refers to the other document). I= 'm > assuming that the replacement is "recommended" (per rfc2119), but it = may be > "required". 802.1AR says it is SHOULD. We need to increase this to MUST. RECOMMENDED is a synonym for SHOULD according to 2119. REQUIRED is a synonym for MUST, so if I changed it to REQUIRED then it would still be a problem according to your thinking...? So I could reword as: IDevID certificates for use with this protocol are REQUIRED to include the "serialNumber" attribute with the device's unique serial number (from [IDevID] section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard attributes). which might be an easier read. Please let me know if I am mis-understandin= g you. > (4) [nits] > s/Bootstrapping to is complete/Bootstrapping is complete Thanks. > =C2=A71: "This bootstrap process satisfies the [RFC7575] section 3.3 = of making all > operations secure by default." Satisfies the what? Requirement, > maybe? requirements, yes, thank you. > s/explains the details applicability/explains the detailed > applicability thank you. > s/out-of-band" information"/out-of-band" information fixed. > s/This section applies is normative for uses with an ANIMA ACP./This = section is > normative for uses with an ANIMA ACP. fixed. > s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Ma= nufacturer > Usage Description Specification I can't find that in -28, I think it was already fixed. > s/might be previous deployed/might be previously deployed fixed. > s/were receives by/were received from > s/{{...}}/[...] Oh. markdown style infested the XML document. I think this is my last .xml document. At least, I hope. Your changes in the diff: https://tinyurl.com/y5l4xz3z YANG doctor comments to come for -29, sometime after the RIPE IOT session tomorrow. =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----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2njQoACgkQlUzhVv38 QpBW7wf/T1/gIRuFM7/LS6sMmTXyFTH7efkdO2g5TavBLLSHU+y4J6lL9jMVL6gA mMPd3N7hQyVPANJQVXi7C4crx/whqsaLYaLTn9Pr0uhha9hPD3G5P6FRQRmlKXC7 Sznvp9BPl+uMupfwjaOj5POyZ5rJ31ER6J44VSOTzzMo8/TizNYjr6MZ1XOM5kLc bwtbOPtxv/qj5vDWI5hV5Xf4Hcfa39HPGyJ+7bIC2ml5jit5wKzBvYXb7bFr7ozb /uKlyFIYT/Iyj/G8hRljhvOksnN/NvGfiMyIugqDZbwl+YHmVAqGsrxNna2EYcq/ ZTnNIjO6ofWm2E32AGfVcZDxiyZrWQ== =aNOr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 16 15:10:03 2019 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 A5AD5120086; Wed, 16 Oct 2019 15:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Cx0zK-gV5tLT; Wed, 16 Oct 2019 15:09:51 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450: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 AD1C612004A; Wed, 16 Oct 2019 15:09:50 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id c4so55629edl.0; Wed, 16 Oct 2019 15:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=watnlkCovFLjSRKzm0LzZY9sB0S+H0/UE9uiP89TZoU=; b=aa5g2RTsHW4T0dxC8TQk1u9po3KTWIMN6BgJlVa56h0oXUTcFy8tWBJUM3qH9GQKRZ XOYUV7iNVCXcPwK2j/UDlE/PKFFVgAqRNihHY+1nmCSNxOHTj3Vdnx3TK6CY26iI3soA rA/711h18P0Xyus6DCq7JM7oq++iG7vpKBG0SYDphTRINwyru/Vav8y+1T/sC3YyGbXG yL3cnjx4mlxxa9fr7dBoSNq8BTEeqm3c2XtYOr9SNbgCrzrBq20oErDNGf0NryIhvpgK rkS21rBM8WpTP5QgdhOxvHkiY8rK3W+qvQRXmGtorwiZRWu79gr2koGgx3aSvHfwuz70 YUfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=watnlkCovFLjSRKzm0LzZY9sB0S+H0/UE9uiP89TZoU=; b=NFCAzDLFyZ53JCXf5+mEdVOZHbKaSnHWoWQXsRlqbBiKjlhr6fVAMdw5ryGhJIUyzD 9p+jjtC7GfhKc3I0rPxfTKceCCLKHirGIHtOk95p/nCSgRRUJI48LYaj0AR5xmvKXKQH HTqV6g2d3wj7Om84+dlNOREwTdOr5tBpWNK+f0jBVZWnR0oE7A0fgRQtQ5nP1Yne8wUs /vHe2I5Yqwjcqxldzlmn1ARzFi6atnPwWTYM6HbVL5edg1awBo5lJS5DXzPINOKHAI2X K2fT2rVyDvFbEiUuXTLDRonTUGTuPJsKKVbJw3Wjep0cBT9AlsxK9YCAcbbWqZ8F7pu3 1jjg== X-Gm-Message-State: APjAAAVgr79whmzwdn8Kft2JTgyOdGz0ogOl8Ik2+jQlowG6sNRMiG9e OYdYf3fcsTvXcsVMfdTz6srTRIVEtKcH3A2BSVg= X-Google-Smtp-Source: APXvYqxkLGlmCST+rp4l17AU/RlVQFgeU7RYnItDcSD745PiuzclV8Rx8YeZQ2c/PDeNGJK0rXUUfwPjZ7bggxNv/MQ= X-Received: by 2002:a17:906:cd11:: with SMTP id oz17mr552549ejb.71.1571263789293; Wed, 16 Oct 2019 15:09:49 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 17 Oct 2019 00:09:48 +0200 From: Alvaro Retana In-Reply-To: <11343.1571261706@dooku.sandelman.ca> References: <157123914799.7818.11835598135548310108.idtracker@ietfa.amsl.com> <11343.1571261706@dooku.sandelman.ca> MIME-Version: 1.0 Date: Thu, 17 Oct 2019 00:09:48 +0200 Message-ID: To: Michael Richardson Cc: anima-chairs@ietf.org, anima@ietf.org, Toerless Eckert , The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org Content-Type: multipart/alternative; boundary="00000000000002636e05950e5c1c" Archived-At: Subject: Re: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 22:09:53 -0000 --00000000000002636e05950e5c1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On October 16, 2019 at 5:34:13 PM, Michael Richardson (mcr+ietf@sandelman.c= a) wrote: Michael: Hi! > (3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD field in > [IDevID]./The serialNumber field is defined in [RFC5280], and is a recommended > field in [IDevID]. Note that SHOULD is not used properly here because it does > not have a Normative quality (as it refers to the other document). I'm > assuming that the replacement is "recommended" (per rfc2119), but it may be > "required". 802.1AR says it is SHOULD. We need to increase this to MUST. RECOMMENDED is a synonym for SHOULD according to 2119. REQUIRED is a synonym for MUST, so if I changed it to REQUIRED then it woul= d still be a problem according to your thinking...? So I could reword as: IDevID certificates for use with this protocol are REQUIRED to include the "serialNumber" attribute with the device's unique serial number (from [IDevID] section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard attributes). which might be an easier read. Please let me know if I am mis-understanding you. The original text sounded as if you were characterizing the field specified in rfc5280. The new text specifies that the serialNumber MUST be there. If that is what you meant from the start, then I=E2=80=99m ok with it. :-) Thanks! Alvaro. --00000000000002636e05950e5c1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On October 16, 2019 at 5:34:13 PM, Michael Richardson (= mcr+ietf@sandelman.ca) wrote:<= /font>

<= /div>
Michael:

Hi!

> (3) s/The serialNumber fields is defined in [RFC5280], and is a SHO= ULD field in=C2=A0
> [IDevID]./The serialNumber field is defined = in [RFC5280], and is a recommended=C2= =A0
> field in [IDevID]. Not= e that SHOULD is not used properly here because it does=C2=A0
> n= ot have a Normative quality (as it refers to the other document). I'm=C2=A0
> assuming that the replacement is "recommended" (= per rfc2119), but it may be=C2=A0
> "required".=C2=A0

802.1AR says it is SHOULD. We need to increase this = to MUST.=C2=A0
RECOMMENDED is a synonym for SHOULD according to 2119= .=C2=A0
REQUIRED is a synonym for MUST, so if I changed it to REQUIR= ED then it would=C2=A0<= br style=3D"color:rgb(0,0,0);font-variant-caps:normal;letter-spacing:normal= ;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo= rd-spacing:0px">still be a problem according to your thinking= ...?=C2=A0

So I could reword as:=C2=A0

IDevID certificates for use with this protocol are REQUIRED to<= span class=3D"Apple-converted-space">=C2=A0
<= span style=3D"color:rgb(0,0,0);font-variant-caps:normal;letter-spacing:norm= al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;= word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inlin= e!important">include the "serialNumber" attribute with the device= 's unique=C2=A0
serial number (from [IDevID] section 7.2.8, and = [RFC5280] section=C2=A0=
4.1.2.4's list of standard attributes).<= span class=3D"Apple-converted-space">=C2=A0
<= br style=3D"color:rgb(0,0,0);font-variant-caps:normal;letter-spacing:normal= ;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo= rd-spacing:0px">which might be an easier read. Please let me = know if I am mis-understanding you.= =C2=A0

The original text sounded as if you were characterizing the fie= ld specified in rfc5280.

The new text= specifies that the serialNumber MUST be there.=C2=A0 If that is what you m= eant from the start, then I=E2=80=99m ok with it. :-)

Thanks!

Alvaro.


--00000000000002636e05950e5c1c-- From nobody Wed Oct 16 18:09:40 2019 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 5CD2F120019; Wed, 16 Oct 2019 18:09:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2019 18:09:39 -0700 Archived-At: Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 01:09:39 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- One remaining item of clarity in the Section 7 from my previous DISCUSS position: ** Section 7. Per “This section is considered non-normative in the generality of the protocol. Use of the suggested mechanism here MUST be detailed in specific profiles of BRSKI, such as in Section 9.” -- Can you please clarify “non-normative in the generality of the protocol”? If I take the perspective of an implementer, it seems like a black-and-white issue – either this section is normative or not (I either have to conform or not). -- what this MUST is requiring isn’t clear. Practically, why would using any of these mechanisms in this section require further elaboration? I’d offer an alternative introduction to this section to address these ambiguities: OLD A common requirement of bootstrapping is to support less secure operational modes for support specific use cases. The following sections detail specific ways that the pledge, registrar and MASA can be configured to run in a less secure mode for the indicated reasons. This section is considered non-normative in the generality of the protocol. Use of the suggested mechanism here MUST be detailed in specific profiles of BRSKI, such as in Section 9. NEW A common requirement of bootstrapping is to support less secure operational modes for support specific use cases. This section suggests a range of mechanisms that would alter the security assurance of BRSKI to accommodate alternative deployment architectures and mitigate lifecycle management issues identified in Section 10.4 – 10.7. They are presented here as informative (non-normative) design guidance for future standardization activities. It would be expected that subsets of these mechanisms could be profiled with an accompanying applicability statements similar to the one described in Section 9. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my previous COMMENTS. I remain concerned that the current text continues to only normatively specify the behavior in the first part of the lifecycle that BRSKI-enabled equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business. I appreciate that this scope is the consensus of the WG. Therefore, thank you for all of the efforts made in recent version of the draft to more substantively document (if not fully specify) these later lifecycle activities. ** Abstract. Per “Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged.”, the rational for the lower security models as described in Section 7 do not appear to be “legacy”. ** Section 1.5 Per “Upon successfully validating a voucher artifact, a status telemetry MUST be returned. See Section 5.7.” Is a “voucher artifact” the same as a “voucher”? ** Section 5.9.4. Per “In the case of a SUCCESS the Reason string is omitted. The SubjectKeyIdentifier is included so that the server can record the successful certificate distribution.”. Given the single example in Figure 18, it isn’t clear how to represent the SubjectKeyIdentifier in JSON. ** Section 10.3. Per “[t]he so-called "call-home" mechanism that occurs as part of the BRSKI-MASA connection standardizes what has been deemed by some as a sinister mechanism for corporate oversight of individuals. ([livingwithIoT] and [IoTstrangeThings] for a small sample).” -- Thanks for including this text about the “call-home” mechanism. However the references don’t seem like a fit. Both references appear to focus on the regular “call home” activity of these device rather than the narrow, on-time one-time onboarding process. The nature of the “call-home” isn’t just about privacy (as these articles imply), but also lock-in. -- It isn't appropriate to characterize concerns about the BRISKI-MASA link as “sinister mechanisms ...”. ** Section 10.7. Per “It is anticipated that specialist service providers will come to exist that deal with the creation of vouchers in much the same way that many companies have outsourced email, advertising and janitorial services.”, I don’t think this is a fair analogy. Delegating the voucher process to an entity would take active cooperation of the manufacturer. If the manufacture is out of business, there is not guarantee this would have been put in place (or those assets were acquired in the liquidation) ** Section 11.5.2.2 prescribes that the operator of a MASA “MUST issue a firmware update to all devices that had that key as a trust anchor”. This suggests a required capability to update trust anchors. However, Section 7.4.3 discusses a similar (albeit more flexible) practice but this is non-normative and deemed reduced security. Why the dissidence? ** Please respond to Christian Huitema’s new SECDIR review items (thank you again, Christian!) on clarifying the TLS version negotiation and certificates for MASA authentication. ** Editorial Nits: Section 3.4. Typo. s/occurence/occurrence/ Section 4. These sentences didn’t parse for me – “This section applies is normative for uses with an ANIMA ACP. The use of GRASP mechanism part of the ACP.” Section 4. Reference expansion issue?. s/{{RFC8446}}/[RFC8446]/ Section 5.1. Typo. s/progess/progress/ Section 5.2. Editorial. Per “The media type is the same as defined in [RFC8366]. and is also …”, the start of the second sentence shouldn’t be “and is …” Section 5.2. Editorial. s/then there a On-Path Attacker (MITM)/then there is an On-Path Attacker (MITM)/ Section 4.1. Recommend clarity on the non-normative behavior. s/While the GRASP M_FLOOD mechanism is passive for the pledge, the optional other methods (mDNS, and IPv4 methods) are active./While the GRASP M_FLOOD mechanism is passive for the pledge, the non-normative, optional methods (mDNS, and IPv4 methods) described in Appendix A are active./ Section 5.7. Editorial s/The client HTTP POSTs the following to the server at the URI ".well-known URI "/voucher_status"./ The client sends an HTTP POSTs to the server at the URI ".well-known URI "/voucher_status". Section 7.2. Typo. s/dependant/dependent/ Section 7.4.1. Typo. s/A MASA has the option of not including a nonce is in the voucher/A MASA has the option of not including a nonce in the voucher/ Section 7.4.2. Typo. s/ nuissance/nuisance/ Section 7.4.3. Typo. s/overwitten/overwritten/ Section 7.4.3. Typo. s/responsability/responsibility/ Section 10.2. Duplicate word. s/the the/the/ Section 10.2. Typo. s/ arbitrary/ arbitrary/ Section 10.2 Typo. s/coorelate/correlate/ Section 10.3. Typo. s/the the/the/ Section 10.4. Typo. s/absense/absence/ Section 10.6. Typo. s/gratuitiously/gratuitously/ Section 10.6. Duplicate Word. s/Section Section/Section/ Section 10.6. Duplicate Word. s/an an/an/ Section 11.2. Typo. s/particulary/particularly/ Section 11.3. Typo. s/occurence/occurrence/ Section 11.5. Typo. s/proceedures/procedures/ Section 11.5. Sometime is amiss with reference expansions – s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT]/ Section 11.5.2.1. Typo. s/opportunies/opportunities/ ==[ summary of old DISCUSS ]== (1) Section 5.7. The format of a pledge status telemetry message seems underspecified. (2) Section 5.8.1. The format of the MASA audit log seems underspecified. Is the JSON snippet presented here normative to describe the MASA audit log response? (3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative? (4) Thank you for documenting “manufacturer control issues” in Sections 10.3 and 10.4. It helpfully lays justifies the current design approach. I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol” is exactly what is needed. My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business. The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modes”. Specifically: ** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4) ** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case). For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension. This is a substantial amount of work, and may be an area for future standardization work”. Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging. From nobody Thu Oct 17 00:39:45 2019 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 1E11112006F; Thu, 17 Oct 2019 00:39:43 -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 gsT44SSDT_Hh; Thu, 17 Oct 2019 00:39:41 -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 C38C3120018; Thu, 17 Oct 2019 00:39:41 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5EFED7F4462C6A5682BC; Thu, 17 Oct 2019 08:39:39 +0100 (IST) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Oct 2019 08:39:38 +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.0439.000; Thu, 17 Oct 2019 15:39:28 +0800 From: Sheng Jiang To: "Fries, Steffen" , "anima@ietf.org" CC: "anima-chairs@ietf.org" , "Brockhaus, Hendrik" , Eliot Lear Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFwFtz52wAF6G1gA= Date: Thu, 17 Oct 2019 07:39:27 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299BD14D3@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.170.117] 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] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 07:39:43 -0000 Hi, Steffen, Thanks for your emails. Your application for time slot are noted. The chair= s will allocate time according to the overall received applications. Best regards, Sheng > -----Original Message----- > From: Fries, Steffen [mailto:steffen.fries@siemens.com] > Sent: Tuesday, October 15, 2019 7:25 PM > To: Sheng Jiang ; anima@ietf.org > Cc: anima-chairs@ietf.org; Brockhaus, Hendrik > ; Eliot Lear > Subject: RE: Call for agenda ANIMA @ IETF 106, Singapore >=20 > Hi Sheng, >=20 > We are currently in the process of updating the draft on BRSKI-AE. I woul= d like > to give a status update on this work. I will upload the new version in th= e next > couple of days. >=20 > > Name of time slot: BRSKI-AE Updates > > Name of draft(s): draft-fries-anima-brski-async-enroll-02 > > Time requested: 15 min > > Presenter name(s): Steffen Fries >=20 > Best regards > Steffen >=20 From nobody Thu Oct 17 01:07:33 2019 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 98C3A120143; Thu, 17 Oct 2019 01:07:24 -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, SPF_HELO_NONE=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 1mIi2eniTBbN; Thu, 17 Oct 2019 01:07:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8299A120115; Thu, 17 Oct 2019 01:07:22 -0700 (PDT) Received: from dooku.sandelman.ca (dhcp-25-21.mtg.ripe.net [193.0.25.21]) by relay.sandelman.ca (Postfix) with ESMTPS id 02A581F455; Thu, 17 Oct 2019 08:07:20 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1932A10B6; Thu, 17 Oct 2019 10:08:13 +0200 (CEST) From: Michael Richardson To: Alvaro Retana cc: anima-chairs@ietf.org, anima@ietf.org, Toerless Eckert , The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org In-reply-to: References: <157123914799.7818.11835598135548310108.idtracker@ietfa.amsl.com> <11343.1571261706@dooku.sandelman.ca> Comments: In-reply-to Alvaro Retana message dated "Thu, 17 Oct 2019 00:09:48 +0200." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 17 Oct 2019 10:08:13 +0200 Message-ID: <19993.1571299693@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 08:07:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {fixing quoting. I had no idea what Alvaro wanted to say otherwise} Alvaro Retana wrote: alvaro> (3) s/The serialNumber fields is defined in [RFC5280], and is a alvaro> SHOULD field in [IDevID]./The serialNumber field is defined in = [RFC5280], and is a alvaro> recommended field in [IDevID]. Note that SHOULD is not used alvaro> properly here because it does not have a Normative quality (as = it alvaro> refers to the other document). I'm assuming that the replacement alvaro> is "recommended" (per rfc2119), but it may be "required". mcr> 802.1AR says it is SHOULD. We need to increase this to MUST. mcr> RECOMMENDED is a synonym for SHOULD according to 2119. mcr> REQUIRED is a synonym for MUST, so if I changed it to REQUIRED the= n it would mcr> still be a problem according to your thinking...? mcr> So I could reword as: mcr> IDevID certificates for use with this protocol are REQUIRED to mcr> include the "serialNumber" attribute with the device's unique mcr> serial number (from [IDevID] section 7.2.8, and [RFC5280] section mcr> 4.1.2.4's list of standard attributes). mcr> which might be an easier read. Please let me know if I am mis-unde= rstanding mcr> you. alvaro> The original text sounded as if you were characterizing the fie= ld alvaro> specified in rfc5280. alvaro> The new text specifies that the serialNumber MUST be there. If= that is alvaro> what you meant from the start, then I=E2=80=99m ok with it. :-) So you prefer the reworded text, and I will use that in -29. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2oIWwACgkQlUzhVv38 QpDzGAf/R4eVhpxumRXYHs4ZbOJyvekDUQmc691w3rir6wNOrnE+kdVUHX8skg8E 92EoBqw3WOWk1nRiMgMImDWei1ng8jXpyc5FB1XJ4Yk4ccTKg4LrgSqlt7rW9DZQ 5qmyG3s7aqHfGItQjVSrEpZovkBNErBHJQc2I/FwER/8x2JcliAy1BAFnL3cig/n ZC4HZz1KdO2DT6m9+TqInMAVgWt3o/cSEprnQdDw3ofL6TrOac6KotLhP1/yJPkJ yZIUSR+gKhkdezInBUnjhAIGIHBxjgR838hz8/0geQ+hjMeHJ7cdgKMuw9Ob4Ifq KIObwuKfxvOvs9BRntesm1SgKc4Itw== =argY -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 17 07:08:52 2019 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 CDC0B12000F; Thu, 17 Oct 2019 07:08:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2019 07:08:49 -0700 Archived-At: Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 14:08:50 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the time and attention to detail put into addressing my previous Discuss and Comment points. I have one new Discuss-level point and one that I think may have been missed (probably because I inadvertently numbered two points with the same number). (16) The audit log response (Section 5.8.1) describes the nonce as a JSON string, but the RFC 8366 nonce is a binary value. I think we need to describe some mapping procedure (such as always base64-encoding as is done for domainID, even if the original nonce is itself base64-encoded random data) in order to be fully functional. % (1) The text of the document suffers from lack of clarity throughout about % whether the nonce-ful operation is mandatory or not, with several % figures and discussions making declarative statements about nonce usage % and others saying that nonce usage is optional. (See COMMENT.) [keep in mind when reading] % (5.1) the new /enrollstatus EST endpoint seems under-specified. Shame on me, I reused (5) for two points and have renumbered this to (5.1) so we don't miss it again. We don't anywhere give a formal description of the contents of the POST body; there's just an example JSON object. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [All new comments for the -28] Please respond to the secdir re-review. Abstract nit: hyphenate "manufacturer-installed" or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for nit: maybe "deployment models with less-stringent security requirements"? Section 1 [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process satisfies the [RFC7575] section 3.3 of making all operations secure by default. Other users of the BRSKI protocol will need to provide nit: missing "requirement" between manufacturer and owner: in it's default modes it provides a cryptographic transfer of control to the initial owner. In it's strongest modes, it leverages sales channel information to identify nit: s/it's/its/ Section 1.2 domainID: The domain IDentity is a unique hash based upon the Registrar CA's certificate. Section 5.8.2 specifies how it is calculated. nit: the grammar here is weird; I'd suggest s/hash based upon/value derived from/ MASA Audit-Log: A list of previous owners maintained by the MASA on a per device (per pledge) basis. Described in Section 5.8.1. nit: maybe "anonymized list" since the MASA doesn't really track owners directly? Ownership Tracker: An Ownership Tracker service on the global Internet. The Ownership Tracker uses business processes to accurately track ownership of all devices shipped against domains that have purchased them. Although optional, this component allows vendors to provide additional value in cases where their sales and distribution channels allow for accurately tracking of such ownership. Ownership tracking information is indicated in nit: either "accurate tracking of" or "accurately tracking" ANI: The Autonomic Network Infrastructure as defined by [I-D.ietf-anima-reference-model]. This document details specific requirements for pledges, proxies and registrars when they are part of an ANI. Maybe refer to section 9 specifically? Section 2.3.1 The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]. IDevID certificates for use with this protocol nit: s/fields/field/ Section 2.5.1 The pledge is the device that is attempting to join. The pledge can talk to the Join Proxy using link-local network connectivity. In most cases, the pledge has no other connectivity until the pledge completes the enrollment process and receives some kind of network credential. I'd consider s/can talk to/is assumed to talk to/. Section 2.5.3 The registrar uses an Implicit Trust Anchor database for authenticating the BRSKI-MASA TLS connection MASA certificate. The registrar uses a different Implicit Trust Anchor database for authenticating the BRSKI-EST TLS connection pledge client certificate. Configuration or distribution of these trust anchor databases is out-of-scope of this specification. Configuration or distribution of this trust anchor databases is out- of-scope of this specification. Note that the trust anchors in/ excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. We seem to duplicate the "out-of-scope" text at the end/start of the two paragraphs (and the second paragraph uses the definite article "the" as if it was only talking about one of the two trust anchor databases). Section 2.6.1 A pledge with a real time clock in which it has confidence in, MUST check the above time fields in all certificates and signatures that ir processes. nits: s/ir/it/, and s/in// from "in which it has confidence in" (your choice which one). Section 2.6.2 year certificate lifetimes. Registrars SHOULD be configurable on a per-manufacturer basis to ignore pledge lifetimes when they did not follow the RFC5280 recommendations. nit: we want "they" to be the manufacturer, not the registrar, so we can't use this pronoun. Section 2.7 be more important in the future. In the ANIMA ACP scope, new devices will be quarantined behind a Join Proxy. I can't decide whether the reader would benefit from being hit with a hammer of "and as such will only have link-local connectivity, to the Join Proxy". The use of "quarantined" makes me lean towards "not"... Section 3 In my previous comment, I said: % The "proximity-registrar-cert" leaf is used in the pledge voucher- % requests. This provides a method for the pledge to assert the % registrar's proximity. % % "proximity" in what sense? How much verification/confidence needs to be % done? (Also, I would have expected the assertion to go the other way; % that the registrar asserts the pledge's proximity -- how does the pledge % have a way to know that the registrar is nearby when the proxy is % transparent?) We talked about this some, but I think we're still making an unstated assumption that there is a link-local or pre-ACP connection involved. Making that an explicit assumption would be helpful. Section 3.3 Example (2) The following example illustrates a registrar voucher- request. The 'prior-signed-voucher-request' leaf is populated with the pledge's voucher-request (such as the prior example). The pledge's voucher-request is a binary CMS signed object. In the JSON encoding used here it must be base64 encoded. The nonce and assertion MAY be carried forward from the pledge request to the registrar request. The serial-number is extracted from the pledge's Client Certificate from the TLS connection. See Section 5.5. Since this is an example, the "MAY be carried forward" feels out of place -- while it's true in the general case, this is not the place to say it; we can just describe what the example does, here. Also, we should probably give a reference for base64 (not necessarily here), such as Section 4 of RFC 4648. Section 4 This section applies is normative for uses with an ANIMA ACP. The nit: pick one of "applies to" or "is normative for". use of GRASP mechanism part of the ACP. Other users of BRSKI will nit: missing "is" Section 4 Registrar itself. In this scenario the pledge is unaware that there is no proxing occurring. This is useful for Registrars which are nit: s/proxing/proxying/ Section 4.3 The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds. The frequency of sending MUST be such nits: "default period" (or similar); s/be not/NOT be/ Section 5 While EST section 3.2 does not insist upon use of HTTP persistent connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use nit: comma after parenthetical, not before. Section 5.1 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. How painful would it be to require 1.3 at this point? RFC 8446 has been out for more than a year, and the TLS WG is leaning on me to tighten up on this... IDevID certificate is out-of-scope of this specification. Note that the trust anchors in/excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. I can't tell if we want to bring the division into two distinct trust anchor databases into this discussion as well. A self-signed certificate for the Registrar is acceptable as the voucher will validate it. nit: "will" applies only when everything works, so maybe "can" or "will validate it in the case of successful enrollment". A pledge that can connect to multiple registries concurrently SHOULD nit: s/registries/Regitstrars/ Section 5.3 on the authenticated identity presented. For different networks, examples of Automated acceptance may include: nit: s/A/a/ Section 5.4 Section 2.8. The mechanisms in [RFC6125] SHOULD be used authentication of the MASA. Some vendors will establish explicit (or nit: s/used/used for/ Also, we tend to require that people using 6125 specify what name type in the cert to verify (e.g., DNS-ID) against what expected name. It would be pretty easy to convince me that we don't need to do that here, though. Section 5.4 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. As above, how painful would requiring 1.3 be? client certificate. Registrars SHOULD also permit an HTTP Basic and Digest authentication to be configured. nit: s/an// Section 5.4.1 be uniquely identified. This can be done by any stateless method that HTTPS supports: such as with HTTP Basic or Digest authentication nit: this colon is not appropriate usage. Stateful methods involving API tokens, or HTTP Cookies are not recommended. nit: zero commas or two, around "or HTTP Cookies", but one is right out. This document does not make a specific recommendation as there is likely different tradeoffs in different environments and product nit: s/is/are/ Section 5.5 idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure a uniqueness of the serial-number. In the case of nonceless (offline) voucher-request, then an appropriate value needs to be configured from the same out-of-band source as the serial-number. nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if you don't take that, the "a" is superfluous in the current formulation). prior-signed-voucher-request: The signed pledge voucher-request SHOULD be included in the registrar voucher-request. The entire CMS signed structure is to be included, base64 encoded for transport in the JSON structure. I think we need a ref for (which) base64. The MASA verifies that the registrar voucher-request is internally consistent but does not necessarily authenticate the registrar certificate since the registrar MAY not be known to the MASA in advance. The MASA performs the actions and validation checks I suggest s/MAY not be known/MAY be unknown/. Section 5.5.2 The registrar's certificate chain is extracted from the signature method. The entire registrar certificate chain was included in the CMS structure, as specified in Section 5.5. This CA certificate will be used to populate the "pinned-domain-cert" of the voucher being issued. By saying "this CA certificate", are we excluding use cases where the pinned-domain-cert is not the global root CA of the organization (or is the implication just that you don't send the rest of the chain)? Section 5.5.5 voucher-request MUST include a 'proximity-registrar-cert' that is consistent with to the certificate used to sign the registrar nit: s/to// (first one) Section 5.5.6 The MASA populates the audit-log with the nonce that was verified. If a nonceless voucher is issued, then the audit-log is to be populated with the JSON value "null". The quotes around "null" are perhaps anti-helpful. Section 5.6.1 The pledge MUST verify that the voucher nonce field is accurate and matches the nonce the pledge submitted to this registrar, or that the voucher is nonceless (see Section 7.2). In my previous Discuss position I had asked: % Is the pledge supposed to accept a nonceless voucher in response to a % nonce-ful voucher request? and we had some discussion that helped clarify the intent. I just have a suggested rewording, that I *think* is entirely editorial and might reduce the potential for confusion: NEW The pledge MUST verify the nonce information in the voucher. If present, the nonce in the voucher must match the nonce the pledge submitted to the registrar; vouchers with no nonce can also be accepted (according to local policy). Section 5.7 The Status field indicates if the voucher was acceptable. Boolean values are acceptable. nit: I suggest """acceptable, as a boolean, where "true" indicates the voucher was acceptable""". The version, and status fields MUST be present. The Reason field SHOULD be present whenever the status field is negative. The Reason- Context field is optional. nit: no comma after "version". nit: s/negative/false/ The keys to this JSON hash are case-insensitive. Figure 15 shows an example JSON. This (case-insensitivity) seems to be a drastic divergence from the RFC 8259 standard behavior and as such would require some justification. nit: s/hash/object/ Section 5.8.1 It's hard to call Figure 17 an "example" when it doesn't conform to the CDDL schema... The domainID is a binary value calculated SubjectKeyIdentifier according to Section 5.8.2. It is encoded once in base64 in order to be transported in this JSON container. nit: I suggest "binary SubjectKeyIdentifier value calculated" Section 5.8.2 used as the domainID. If not, then it is the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs nit: drop "is to be used" or "then it is". Section 5.8.3 A relatively simple policy is to white list known (internal or external) domainIDs. To require all vouchers to have a nonce. nit: sentence fragment. Alternatively to require that all nonceless vouchers be from a subset nit: comma after "alternatively". (Hmm, this is also a sentence fragment.) Section 5.9.4 In order to communicate this indicator, the client HTTP POSTs the following to the server at the new EST endpoint at "/.well-known/est/ enrollstatus". "The following" is just more text, not a formal description of a protocol element. "reason-context": "Additional information" Is this supposed to be a string or a JSON object similar to /voucher_status? Section 6 When used within BRSKI, the original RFC7030 EST endpoints remain Base64 encoded, but the new BRSKI end points which send and receive binary artifacts (specifically, /requestvoucher) are binary. That The other two occurrences spell this "/.well-known/est/requestvoucher". Section 7.2 The following are a list of alternatives behaviours that the pledge can be programmed to implement. These behaviours are not mutually exclusive, nor are they dependant upon other. Some of these methods nits: singular/plural mismatch "are"/"list"; "upon each other" Section 7.3 A registrar can choose to accept devices using less secure methods. These methods are acceptable when low security models are needed, as the security decisions are being made by the local administrator, but they MUST NOT be the default behavior: I'm having a hard time parsing "low security models"; the best I can come up with is "threat models where low security is adequate". Section 7.4.1 A MASA has the option of not including a nonce is in the voucher, nit: s/is// and/or not requiring one to be present in the voucher-request. This results in distribution of a voucher that never expires and in effect "expires-on" is distinct from the nonce-ful freshness check, so I think some additional wordsmithing is in order. This is useful to support use cases where registrars might not be online during actual device deployment. nit: there's enough intervening text that we should probably replace "this is" with "nonceless vouchers are". authorized to provide this functionality to this customer. The MASA is RECOMMENDED to use this functionality only in concert with an enhanced level of ownership tracking (out-of-scope.) I suggest s/out-of-scope/the details of which are out of scope for this document/. Section 7.4.2 functionality. This provides a proof-of-proximity check that reduces the need for ownership verification. I suggest reiterating the assumption that pledge and JP are on a link-local connection; whether or not to reiterate that JP and registrar have a trust relationship (with respect to not falsifying proximity information) is less clear to me. Section 7.4.3 We might benefit from some introductory text here to suggest that updating/extending trust anchors would be desirable in the case of a vanished or uncooperative manufacturer. This weaker factor reset might leave valuable credentials on the device and this may be unacceptable to some owners. nit: s/factor/factory/ Section 9 Provider organizations. Equivalent enterprises that has significant layer-3 router connectivity also will find significant benefit, nit: s/has/have/ In the ACP, the Join Proxy is found to be proximal because communication between the pledge and the join proxy is exclusively on nit(?) My dictionary doesn't list anything for "proximal" that is a good match for "with proximity"; might be worth double-checking. asssertion is satisfied. Other uses of BRSKI will need make similar analysis if they use proximity. nit: maybe "proximity information" or "proximity assertions". Section 10.3 While the contents of the signed part of the pledge voucher request can not be changed, they are not encrypted at the registrar. The ability to audit the messages by the owner of the network a mechanism to defend against exfiltration of data by a nefarious pledge. Both nit: missing verb ("is a mechanism", "provides a mechanism", etc.) The manufacturer knows the IP address of the Registrar, but it can not see the IP address of the device itself. The manufacturer can not track the device to a detailed physical or network location, only to the the location of the Registrar itself. That is likely to be at nit: we probably don't need the last "itself". is likely on the same network as the device. A manufacturer that sells switching/routing products to enterprises should hardly be surprised if additional purchases switching/routing products are purchased. Deviations from a historical trend or an establish nit: we probably only need one of "purchases" and "purchased". Section 10.6 Section Section 7.4.3 describes some ways in which a manufacturer nit: duplicate "Section". Section 10.7 existing products. Said products might be previous deployed and need to be re-initialized, purchased used, or just kept in a warehouse as long-term spares. nit: s/previous deployed and need/previously deployed that need/ Section 11.2 In particular implementations should pay attention to the advance in [RFC4086] section 3, particulary section 3.4. Devices which are reset to factory default in order to perform a second bootstrap with a new owner MUST NOT seed their random number generators in the same way. nit: s/same way/same way across bootstraps/ Section 11.3 We had some discussion around my previous comment: % Additionally, in order to successfully use the resulting voucher the % Rm would have to attack the pledge and return it to a bootstrapping % enabled state. This would require wiping the pledge of current % % ... and I think there is a different attack if the Rm is in a position % to delay or drop network traffic between the pledge and the intended % registrar, to cause Rm's voucher to be delivered first even though it is % generated after the intended registrar's authorization process. The % intended registrar would need to require reports on voucher processing % status (or investigate their absence) in order to detect such a case. but I can't remember if we decided that we didn't need to discuss the risk in the document. Section 11.5 This next section examines the risk due to a compromised MASA key. This is followed by examination of the risk of a compromised manufacturer IDevID signing key. The third section sections below nit: I think these appear in the other order. Section 13.1 [cabforumaudit] and [dnssecroot] probably would be fine as just informative references. Appendix D.2 An RFC Editor note about the RFC 8366 assignment of OID 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples properly use that assigned OID now? From nobody Thu Oct 17 13:55:47 2019 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 2B6D0120867; Thu, 17 Oct 2019 13:55:45 -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, SPF_HELO_NONE=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 QPRDLkWnEdIA; Thu, 17 Oct 2019 13:55:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6E9120271; Thu, 17 Oct 2019 13:55:40 -0700 (PDT) Received: from dooku.sandelman.ca (214-137-20-31.ftth.glasoperator.nl [31.20.137.214]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F82A1F47F; Thu, 17 Oct 2019 20:55:36 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id DC9BB10B6; Thu, 17 Oct 2019 22:56:30 +0200 (CEST) From: Michael Richardson To: Roman Danyliw , Christian Huitema cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-reply-to: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com> References: <157127457937.7863.815173980398917672.idtracker@ietfa.amsl.com> Comments: In-reply-to Roman Danyliw via Datatracker message dated "Wed, 16 Oct 2019 18:09:39 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 17 Oct 2019 22:56:30 +0200 Message-ID: <8262.1571345790@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 20:55:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {please excuse me if this is a resend} {ALSO responding to Christian's third review comments. https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-keyinfra= -28-secdir-telechat-huitema-2019-10-12/ } Roman Danyliw via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > One remaining item of clarity in the Section 7 from my previous DISCU= SS > position: > ** Section 7. Per =E2=80=9CThis section is considered non-normative = in the generality > of the protocol. Use of the suggested mechanism here MUST be detaile= d in > specific profiles of BRSKI, such as in Section 9.=E2=80=9D > -- Can you please clarify =E2=80=9Cnon-normative in the generality of= the protocol=E2=80=9D? > If I take the perspective of an implementer, it seems like a black-an= d-white > issue =E2=80=93 either this section is normative or not (I either hav= e to conform or > not). Section 7 is a pallette of items that might apply. If you are in the applicability as defined by Section 9 (ACP), then you need to read the MUSTs in that section. > I=E2=80=99d offer an alternative introduction to this section to addr= ess these > ambiguities: ... > NEW > A common requirement of bootstrapping is to support less secure opera= tional I've adapted it slight to read: A common requirement of bootstrapping is to support less secure operational modes for support specific use cases. This section suggests a range of mechanisms that would alter the security assurance of BRSKI to accommodate alternative deployment architectures and mitigate lifecycle management issues identified in Section 10. They are presented here as informative (non-normative) design guidance for future standardization activities. Section 9 provides standardization applicability statements for the ANIMA ACP. Other users would be expected that subsets of these mechanisms could be profiled with an accompanying applicability statements similar to the one described in Section 9. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Thank you for addressing my previous COMMENTS. > I remain concerned that the current text continues to only normativel= y specify > the behavior in the first part of the lifecycle that BRSKI-enabled eq= uipment > might see -- equipment on first sale as long as the manufacturer supp= orts it or > stays in business. I appreciate that this scope is the consensus of = the WG. > Therefore, thank you for all of the efforts made in recent version of= the draft > to more substantively document (if not fully specify) these later lif= ecycle > activities. I also continue to be concerned. I have started some work on a more complex voucher mechanism that would support the second sale. Roman Danyliw via Datatracker wrote: > ** Abstract. Per =E2=80=9CSupport for lower security models, includi= ng devices > with minimal identity, is described for legacy reasons but not > encouraged.=E2=80=9D, the rational for the lower security models as d= escribed > in Section 7 do not appear to be =E2=80=9Clegacy=E2=80=9D. I will truncate the sentence after "minimal identity" > ** Section 1.5 Per =E2=80=9CUpon successfully validating a voucher ar= tifact, a > status telemetry MUST be returned. See Section 5.7.=E2=80=9D Is a = =E2=80=9Cvoucher > artifact=E2=80=9D the same as a =E2=80=9Cvoucher=E2=80=9D? Yes. RFC8366 describes "voucher artifacts", and so we try to use that term consistently to describe the object. > ** Section 5.9.4. Per =E2=80=9CIn the case of a SUCCESS the Reason st= ring is > omitted. The SubjectKeyIdentifier is included so that the server can > record the successful certificate distribution.=E2=80=9D. Given the = single > example in Figure 18, it isn=E2=80=99t clear how to represent the > SubjectKeyIdentifier in JSON. Hmm. Thank you. In the success situation, one would have used a TLSClientCertificate to connect, so it would come from there. In the failure situation, I'm not sure; I haven't implemented that code yet. I will consult with my co-autho= rs. > ** Section 10.3. Per =E2=80=9C[t]he so-called "call-home" mechanism = that > occurs as part of the BRSKI-MASA connection standardizes what has been > deemed by some as a sinister mechanism for corporate oversight of > individuals. ([livingwithIoT] and [IoTstrangeThings] for a small > sample).=E2=80=9D > -- Thanks for including this text about the =E2=80=9Ccall-home=E2=80= =9D mechanism. > However the references don=E2=80=99t seem like a fit. Both reference= s appear > to focus on the regular =E2=80=9Ccall home=E2=80=9D activity of these= device rather > than the narrow, on-time one-time onboarding process. The nature of > the =E2=80=9Ccall-home=E2=80=9D isn=E2=80=99t just about privacy (as = these articles imply), but > also lock-in. While I agree with you, the devices mentioned in the above references die if they can't call home AT ANY TIME. Not just at onboarding. So, the oversight present in BRSKI is just less effective than other devices. > -- It isn't appropriate to characterize concerns about the BRISKI-MASA > link as =E2=80=9Csinister mechanisms ...=E2=80=9D. Did you read the review comments back in November/December 2018? :-) if you are arguing that I'm using too alarmist language, I will accept suggests for less alarmist language. > ** Section 10.7. Per =E2=80=9CIt is anticipated that specialist serv= ice > providers will come to exist that deal with the creation of vouchers = in > much the same way that many companies have outsourced email, > advertising and janitorial services.=E2=80=9D, I don=E2=80=99t think = this is a fair > analogy. Delegating the voucher process to an entity would take acti= ve > cooperation of the manufacturer. If the manufacture is out of > business, there is not guarantee this would have been put in place (or > those assets were acquired in the liquidation) Recent changes remind that the manufacturer needs to escrow their keys. If the manufacturer is out of business, then where will you get security updates from? Do you want to enable a secondary market for devices with decade old security holes? > ** Section 11.5.2.2 prescribes that the operator of a MASA =E2=80=9CM= UST issue > a firmware update to all devices that had that key as a trust anchor= =E2=80=9D. > This suggests a required capability to update trust anchors. However, > Section 7.4.3 discusses a similar (albeit more flexible) practice but > this is non-normative and deemed reduced security. Why the dissidenc= e? If you lose your key, you'll have to update the firmware to update the anch= ors. If you have implemented 7.4.3, then it might be that you can do less. However, in one version of 7.4.3, a factory reset might restore the original (lost) keys, which is why a firmware update would in general be needed. > ** Please respond to Christian Huitema=E2=80=99s new SECDIR review it= ems (thank > you again, Christian!) on clarifying the TLS version negotiation and > certificates for MASA authentication. {Things which originate from the datatracker like these reviews seem to miss my inbox, or maybe my eyes think it's spam; yet I get list traffic in general. I've had words with my spam filter supplier, but I wonder if it's really my frontal cortex} Christian asks: I have a minor concern with the text on TLS usage in section 5.1 and 5.2. In section 5.1, BRSKI-EST TLS establishment details, I read "Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED." Does th= at mean that BRSKI-EST TLS servers MAY reject connection attempts using a T= LS version lower than 1.2, or maybe that pledges SHOULD refuse connections = if the server tries to negotiate a TLS version lower than 1.2? We have experience in other deployments that even "low end" vendors will not che= ap lower security solutions if that leads to interop failures, and that having at least some implementations being strict in what they accept is= a good way to raise the bar for everybody. Same issue in section 5.2, regarding BRSKI MASA connections. BRSKI-EST TLS SHOULD reject TLS versions lower than 1.2. Is there another other than: TLS 1.2 or newer is REQUIRED to say this? Christian also complains: In section 5.4.1, "This document does not make a specific recommendatio= n" (regarding whether to use public PKI, DANE, or pinned certificates for MASA authentication. That's probably fine from a security point of view, but the absence of at least one recommended solution ay well end up causing interesting interoperability issues. There is perhaps some confusion here. I am extending the sentence to be clearer: This document does not make a specific recommendation on how the MASA authenticates the Registrar I learnt yesterday at RIPE that increasing amounts of HTTPS traffic is no l= onger browser originated but rather APIs with pinned keys or TLSA/DANE keys, and keys pinned by DNSSEC in DANE are growing in utility for non-browser use. I think that we would have liked to specify DANE, but have been reluctant to do so. In general we do not think that CABFORUM certificates are likely to fit the required policy for Registrars, as they likely use a key from a private enterprise/domain CA. I have addressed Christian's nits and your nits as well. > Section 4. These sentences didn=E2=80=99t parse for me =E2=80=93 =E2= =80=9CThis section applies > is normative for uses with an ANIMA ACP. The use of GRASP mechanism > part of the ACP.=E2=80=9D This sentence has already been replaced. > Section 4.1. Recommend clarity on the non-normative behavior. s/Whi= le > the GRASP M_FLOOD mechanism is passive for the pledge, the optional > other methods (mDNS, and IPv4 methods) are active./While the GRASP > M_FLOOD mechanism is passive for the pledge, the non-normative, > optional methods (mDNS, and IPv4 methods) described in Appendix A are > active./ fixed. > Section 5.7. Editorial s/The client HTTP POSTs the following to the > server at the URI ".well-known URI "/voucher_status"./ The client sen= ds > an HTTP POSTs to the server at the URI ".well-known URI > "/voucher_status". fixed. > Section 10.2. Typo. s/ arbitrary/ arbitrary/ Not sure... did we both typo something? > Section 11.5. Sometime is amiss with reference expansions =E2=80=93 > s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT= ]/ fixed already > =3D=3D[ summary of old DISCUSS ]=3D=3D (1) Section 5.7. The format o= f a pledge > status telemetry message seems underspecified. > (2) Section 5.8.1. The format of the MASA audit log seems > underspecified. Is the JSON snippet presented here normative to > describe the MASA audit log response? CDDL added for this. > My concern is that even with the current applicability statement in > Section 9, the current text appears to have only standardized the fir= st > part of the lifecycle that BRSKI equipment might see -- equipment on > first sale as long as the manufacturer supports it or stays in > business. I want to ask again if we think that equipment without access to security patches should be resold. (I buy Dan Geer premise at https://www.youtube.com/watch?v=3DnT-TGvYOBpI, b= tw) 1) Anyone who can security patch the system after the manufacturer goes out= of business can fix the trust anchors. 2) customers have asked for source code escrow for decades. I remember preparing 150M QIC tapes for the Blackhole firewall for the lawyers back in 1995. If I had BRSKI, the signing keys would be on that tape. This is just not new. If Nortel customers failed to ask for that, well.= .. 3) However, there are concerns in the (public) transportation industry abou= t having the manufacturer be aware of when spares are deployed. I have started a document that would make the pledge evaluation of the voucher more complex, but would effectively fill in the offline and/or second sale process. If the WG feels that this document should wait an additional 12-24 months f= or that work to reach some level of maturity (including running code), then le= t's wait! > The text doesn=E2=80=99t appear to cover the practical aspects of > the proposed mitigations in Section 10.5 or the situations described = in > Section 10.3/10.4 =E2=80=93 various situations possible in the full l= ifecycle > usage of a BRSKI device and needed support the =E2=80=9Cadditional op= erational > modes=E2=80=9D. Specifically: > ** There appears to be little discussion on how > owners/manufacturers/vendors can facilitate second sale/used equipment > beyond narrative words (in Section 10.3 and 10.4) > ** There is appears to be little discussion on how to practically > implement a MASA (i.e., the offline use case). For example, (Per > Section 10.5) =E2=80=9CA manufacturer could provide a mechanism to ma= nage the > trust anchors and built-in certificates (IDevID) as an extension. Th= is > is a substantial amount of work, and may be an area for future > standardization work=E2=80=9D. Without the ability to change anchors= on the > device the additional operational modes such as offline mode seems > challenging. I have proposed a BOF/WG to deal with Lifecycle Security issues in IoT devi= ces to Ignas. A number of people believe that it would attempt to boil the ocean. I think that with proactive charing and diligent work that we can make prog= ress. I did a talk today at RIPE79 about the quarantine/remediation life cycle possibilities. I'm not sure operators/ISPs are ready for this yet. Changes so far are at: https://tinyurl.com/y5l4xz3z I will post -29 once I get through the YANG DOCTOR comments and Ben's comme= nts. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl2o1X4ACgkQlUzhVv38 QpCCnQf8DsuoZ2eFclm3lbEECPyE124JD657bq7VLbMzwk/eAbHu/MwQsfx77Ucf hAMpdRgTjT+ePIntsA+67njVUZlDtR/wMdZHth/44H3iyGV9TFYzbeLit5Bbj8u3 jByFGkgUCaR6ECVjyXpkBIGZvsKf8u+xWLnYKqiEH5dNMqs40HdJ2rR5RBSaN/6Q +c8X0NuPKhFwDDWKhA8oYzOv7g+IKHoWRi9tRvrEPcVqSqpd5yQahlJpvouAQ8eF KkiQBLsPLtfYxQH1G5VLvoaZUuLR35c2lvX4+FQvyAdfOKGuBPc2Y/UcDyNvqjJc G1jcgGPURxn9/lh+rM8+sxxV37hMDQ== =8EBl -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 17 18:24:13 2019 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 6E3AF120086; Thu, 17 Oct 2019 18:24:11 -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_HELO_NONE=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 bhv4SSE3N0im; Thu, 17 Oct 2019 18:24:09 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 F381D12003F; Thu, 17 Oct 2019 18:24:08 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9I1NqIn007874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 21:23:55 -0400 Date: Thu, 17 Oct 2019 18:23:52 -0700 From: Benjamin Kaduk To: draft-ietf-anima-bootstrapping-keyinfra@ietf.org Cc: The IESG , tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20191018012352.GB43312@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 01:24:11 -0000 On Thu, Oct 17, 2019 at 07:08:49AM -0700, Benjamin Kaduk via Datatracker wrote: > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > % (1) The text of the document suffers from lack of clarity throughout about > % whether the nonce-ful operation is mandatory or not, with several > % figures and discussions making declarative statements about nonce usage > % and others saying that nonce usage is optional. (See COMMENT.) > > [keep in mind when reading] This was just supposed to be a note to myself and should be ignored; I was in a hurry and forgot to trim it before pushing "send". Sorry about that. I also have some more comments that didn't make it into my ballot position; please consider them as well. I will put them in the datatracker for posterity, but will have it not generate an additional mail since the mostly-duplicate contents would be confusing. Section 2 Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of bidirectional? 3. Request to join the discovered registrar. A unique nonce is included ensuring that any responses can be associated with this particular bootstrapping attempt. This still seems to assume nonce-ful operation, which IIUC remains required for pledge voucher-requests; only registrar-voucher-requests have the option of being nonceless. So, this seems okay as-is, right? 4. Imprint on the registrar. This requires verification of the manufacturer service provided voucher. A voucher contains nit: hyphenate "manufacturer-service-provided" Section 2.3.1 The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]. IDevID certificates for use with this protocol MUST include the "serialNumber" attribute with the device's unique serial number (from [IDevID] section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard attributes). This is 4.1.2.2 (or just 4.1.2) from RFC 5280. Section 2.4 I note that both Figure 2 and Figure 4 have a step labeled "Identity", but the description accompanying Figure 2 describes the step as "Identify itself"; perhaps the 'f' form is more appropriate everywhere? Section 2.8 Note that the registrar can only select the configured MASA URL based on the trust anchor -- so manufacturers can only leverage this approach if they ensure a single MASA URL works for all pledge's associated with each trust anchor. nit: s/pledge's/pledges/ Section 3 Voucher-requests are how vouchers are requested. The semantics of the vouchers are described below, in the YANG model. nit: semantics of vouchers, or voucher requests? Section 3.3 Figure 6: JSON representation of example Voucher-Request I suggest adding "(unsigned)" or "prior to CMS wrapping". Section 3.4 refine "voucher/assertion" { mandatory false; description "Any assertion included in voucher requests SHOULD be ignored by the MASA."; If this is true, why do we propagate the assertion from pledge voucher-request to registrar voucher-request? Section 4.1 Each possible proxy offer SHOULD be attempted up to the point where a voucher is received: while there are many ways in which the attempt may fail, it does not succeed until the voucher has been validated. nit: I suggest "valid voucher is received". Section 5 o The pledge requests and validates a voucher using the new REST calls described below. nit: I think the validation is local and does not use the REST call. o The registrar forwards the voucher to the pledge when requested. I suggest "validates and forwards" to cover the case where the registrar applies policy. Section 5.2 nonce: The pledge voucher-request MUST contain a cryptographically strong random or pseudo-random number nonce. (see [RFC4086]) Doing so ensures Section 2.6.1 functionality. The nonce MUST NOT be This section reference reads kind of strangely. (Also, full stop after parenthetical, not before.) proximity-registrar-cert: In a pledge voucher-request this is the first certificate in the TLS server 'certificate_list' sequence (see [RFC5246]) presented by the registrar to the pledge. That is, it is the end-entity certificate. This MUST be populated in a pledge voucher-request if the "proximity" assertion is populated. nit: there is no "proximity" field to be populated; it's the "assertion" field that's populated with the value "proximity". Section 5.5 serial-number: The serial number of the pledge the registrar would like a voucher for. The registrar determines this value by parsing the authenticated pledge IDevID certificate. See Section 2.3. The registrar MUST verify that the serial number field it parsed matches the serial number field the pledge provided in its voucher-request. This provides a sanity check useful for detecting error conditions and logging. The registrar MUST NOT simply copy the serial number field from a pledge voucher request as that field is claimed but not certified. (Just to be clear, the serial-number field is optional in the pledge's voucher-request.) Section 5.6.2 intervals according to the backoff timer described earlier. Attempts SHOULD be repeated as failure may be the result of a temporary inconsistently (an inconsistently rolled registrar key, or some other mis-configuration). The inconsistently could also be the result an active MITM attack on the EST connection. nit: only one of these "inconsistently"s is correct; the others should be "inconsistency". Section 5.8 although it results in additional network traffic. The relying MASA implementation MAY leverage internal state to associate this request with the original, and by now already validated, voucher-request so as to avoid an extra crypto validation. It seems that doing so would turn the voucher-request into a bearer token for retrieving audit-log information (if the MASA accepts unauthenticated clients). Section 5.8.2 If the "pinned-domain-cert" certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, then it is the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs to be calculated by both MASA (to populate the audit-log), and by the Registrar (to recognize itself). nit: maybe "to recognize itself in the audit log"? Section 5.9 The pledge SHOULD follow the BRSKI operations with EST enrollment operations including "CA Certificates Request", "CSR Attributes" and "Client Certificate Request" or "Server-Side Key Generation", etc. This is a relatively seamless integration since BRSKI REST calls (I think we decided to not call this REST.) Section 7.3 4. A registrar MAY ignore unrecognized nonceless log entries. This could occur when used equipment is purchased with a valid history being deployed in air gap networks that required permanent vouchers. "nonceless" and "permanent" are related but subtly different concepts, given the potential for an expiration date in a nonceless voucher. Section 7.4.3 As a third option, the manufacturer's trust anchors could be entirely overwitten with local trust anchors. A factory default would never restore those anchors. This option comes with a lot of power, but also a lot of responsability: if the new anchors are lost the manufacturer may be unable to help. nit: perhaps we refer to the private key portions of the anchors. Section 11 I am somewhat embarassed that I did not previously note that the mechanism used to generate the domainID needs to be second-preimage-resistant or an attacker can claim to be a registrar for a domain that already exists. Section 11.2 Although the nonce used by the Pledge in the voucher-request does not require a strong cryptographic randomness, the use of TLS in all of the protocols in this document does. We discuss the need for strong randomness in the nonce in Section 11.3, so it's not clear this is actually true. Thanks! -Ben From nobody Thu Oct 17 20:57:34 2019 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 D812912011B; Thu, 17 Oct 2019 20:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 MEIP3GI4j8hu; Thu, 17 Oct 2019 20:57:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 60489120052; Thu, 17 Oct 2019 20:57:28 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9I3vFOE014818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 23:57:19 -0400 Date: Thu, 17 Oct 2019 20:57:15 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20191018035715.GD43312@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> <20412.1568670397@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20412.1568670397@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 03:57:33 -0000 While recovering from today's telechat, I noticed that I seem to have never replied to this one! (Luckily, there's not much to say...) On Mon, Sep 16, 2019 at 05:46:37PM -0400, Michael Richardson wrote: > > Combining your August 9 and September 3 emails, and removing resolved items. > > https://tinyurl.com/y2kmjqmm for diffs aginst -26. > (also includes changes for Alexey) > Submitting -27 in process. > > Benjamin Kaduk wrote: > >> This was asked by Eric as well. > >> It's the Subject Key Identifier that we want. > >> https://tools.ietf.org/html/rfc5280#section-4.2.1.2 > >> > >> It's only guaranteed to exist in CA certificates. > >> Do you think we can demand that the extension be present in IDevID? > > > I'm doubtful that we have enough leverage to make that stick. > > Subsequent discussion with my co-authors has pointed out that the > certificate that will be pinned in the voucher (as pinned-domain-cert) is the > *domain cert*, that is, the domain's CA. As a CA, will most likely have the > right SubjectKeyIdentifier calculated already. Maybe I've just been reading too many copies of different text in flux, but I'm not sure that the current text gives me a clear picture of who picks what will be pinned and how much choice they have in the matter. But, if it's the "root" (last certificate in the chain) presented by the registrar for the provisional TLS connection, I think things are pretty self-consistent about it. > We had updated section 5.8.2 in -26 to clarify things. > We moved the domainID definition out of the terminology section (which is > where the SHA-1 stuff was), to point at 5.8.2, and point to rfc7469, which > provides an algorithm agile definition. > > >> > 5. Enroll. After imprint an authenticated TLS (HTTPS) connection > >> > exists between pledge and registrar. Enrollment over Secure > >> > Transport (EST) [RFC7030] is then used to obtain a domain > >> > certificate from a registrar. > >> > >> > Isn't this step optional? > >> > >> so, I can change the word to "can" rather than "is" > > > (and fix up the grammar, but) sure > > missing "be" added to section 2.1, point 5. > > doc> 1. Uniquely identifying the pledge by the Distinguished Name (DN) > doc> and subjectAltName (SAN) parameters in the IDevID. The unique > doc> identification of a pledge in the voucher objects are derived > doc> from those parameters as described below. > > >> > These unique identifiers can (by design) be used for tracking, so let's > >> > be sure that we talk about any privacy considerations with them, later. > >> > I see a mention in passing in Section 10.2, at least... > > >> Are you asking for a forward reference to 10.2? I will add this. > >> I think that section 10.2 is pretty clear about this. > >> I don't think it's mentioned just in passing. > > > It looks like the main coverage here is: > > > o the identity of the device being enrolled (down to the serial- > > number!). > > > and the discussion in the last three paragraphs or so. > > I do appreciate the importance of distinguishing between the high-end > > router and the human users (and we will have a long hard think about it > > again when BRSKI profiles for IoT use come through, I'm sure), so thank you > > for that. But I'm not sure that we clearly draw the connection to "the > > manufacturer knows the identity of the device being enrolled" to "and can > > guess where it is, and definitely knows who the owner is, and can > > potentially follow that over time if the device has to reenroll". Now, for > > the high-end router case there is literally nothing new here -- the vendor > > is assumed to already be doing inventory tracking of which customers have > > which routers! But I think it's important to make the connection from > > "knows identity" to "tracking", since this topic will come up for any use > > of BRSKI in other situations. > > I've tweaked some text, in section 10.3, but I feel I am just moving the > chairs around on the Titanic here. > > doc> 3. Secure auto-discovery of the pledge's MASA by the registrar (see > doc> Section 2.8). > > ben> I don't think this is an ironclad property, since the crypto chain is > ben> slightly limited and you are in effect trusting the pledge to hand you > ben> something that says "use this issuer" but without as much crypto to back > ben> that up as we might want. We have to know that the given manufacturer > ben> that signed the IDevID actually is associated with the device we're > ben> trying to bootstrap, which can probably be arranged but I don't remember > ben> being called out explicitly. > > mcr> There are two issues here. > > mcr> One is the question of what is the list of acceptable manufacturers (below). > mcr> The second part is whether a pledge could provide a fake IDevID to > mcr> the Registrar. The pledge is doing TLS ClientCertificate, so the TLS > mcr> has proven that the pledge has the private key corresponding to the > mcr> certificate presented. I conclude that an arbitrary IDevID can not be > mcr> provided by the Pledge; it has to be linked to SOME manufacturer. Some > > > Well, it has to be linked to some entity that signed the IDevID. That may > > or may not be a manufacturer, but the Registrar does have the capability to > > look at what signed the IDevID and apply a whitelist of known, verified, > > manufacturers. > > Yes. Even if we throw full Remote Attestation at the problem, if the > Registrar decides to trust Malware Inc. to attest to it's BFR's then it's > gonna have Malware. > > mcr> manufacturer A could point it's product at MASA B, but I don't see how this > mcr> is an issue if MASA B will issues vouchers that pledge A can verify. > > mcr> (The pledge could have a variety of certificates from > mcr> a variety of sources, perhaps all bound to the same public key, I guess, and > mcr> since the Registrar sends it's certificate first, the pledge could present > mcr> different identities to different networks. I think that this is a feature, > mcr> not a bug. It reminds that "Kenmore" brand appliances were made by a variety > mcr> of manufacturers, but I don't see my dishwasher can know what identity > mcr> to use until after there is communication with the MASA) > > ben> Sure, that is probably a feature at least in some cases. > ben> But can we assume that a given pledge has a single distinguished > ben> MASA? > > Yes. Okay. I think that means I don't want to ask for any text changes as a result. > ben> The pledge gives the registrar a thing that says "go here for my MASA", and > ben> the registrar can do a fair bit of validation on that, but there's still > ben> potentially some control in the pledge's hands about where the registrar > ben> goes to, and lots of room for attack by hostile pledges if the registrar is > ben> buggy. > > Buggy in what way? > A registrar which allows any manufacturer's IDevID can be fooled^Wconvinced into talking > to a MASA of a malicious pledge's choice. > > ben> It's not like there's a single authoritative (global) database of (device, > ben> MASA) pairs that we can query and have unconditional trust is giving the > ben> right result (and validating what device we're looking up, even). Things > ben> are fragmented, and at the protocol level, we can't be confident that we > ben> wouldn't get a different (valid!) answer if we asked somewhere else, or > ben> asked a slightly different question. > > It's not inconceivable to me that some specialized CAs (akin to the Extended > Validation certificates) could come to be that would sign the > ServerCertificates for MASA from entities that comply to some industry led criteria. > > ben> (And, given the track record of Web > ben> PKI CAs, I expect some baseline level of bogus IDevIDs to be out > ben> there.) > > I'm not exactly sure how this would occur, but I concede that this could be > the case. > > mcr> The question then becomes how the Registrar comes to trust/verify the > mcr> pledge's IDevID. We had a long discussion about this during the directorate > mcr> reviews and going back to Feb. 2018. I thought that we resolved this. > mcr> Issues > mcr> https://github.com/anima-wg/anima-bootstrap/issues/120 > mcr> https://github.com/anima-wg/anima-bootstrap/issues/43 > mcr> https://github.com/anima-wg/anima-bootstrap/issues/46 > mcr> A thread starts here: > mcr> https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs > mcr> > mcr> Some changes that we made for this: > mcr> https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54 > > ben> Maybe, "Configuration or distribution of these trust anchor databases is > ben> out-of-scope of this specification. Note that the trust anchors > ben> in/excluded from the database will affect which manufacturers' devices are > ben> acceptable to the registrar as pledges, and can also be used to limit the > ben> set of MASAs that are trusted for enrollment."? > > Added. > > doc> Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage > doc> extensions in the IDevID certificate. Any restrictions included > >> > >> > I only got my hands on the 2018 rev of [IDevID], but that one does not > >> > actually talk about extendedKeyUsage. > >> > mcr> Max was the editor of the 2009 edition, and we pointed at it. > mcr> I don't seem to be able to get the 2018 edition. > > ben> I think we could probably reword this to just acknowledge that [IDevID] > ben> acknowledges that adding restrictions in the certificate can limit > ben> applicability, and since these are long-lived, usually you don't want to > ben> throw random extra restrictions into them. > > > Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of > discusses keyUsage and > - extendedKeyUsage extensions in the IDevID certificate. Any > - restrictions included reduce the utility of the IDevID and so > - this specification RECOMMENDS that no key usage restrictions be included. > - Additionally, section 4.2.1.3 does not > + extendedKeyUsage extensions in the IDevID certificate. > + acknowledges that adding restrictions > + in the certificate limits applicability of these long-lived > + certificates. This specification emphasizes this point, and > + therefore RECOMMENDS that no key usage restrictions be included. > + This is consistent with section 4.2.1.3, > + which does not > require key usage restrictions for end entity certificates. > > > > mcr> The pledge extracts it from it's IDevID. > mcr> The registrar extracts it again from the IDevID that it sees. > mcr> It's seems hard to construct an attack where the provisional TLS connection > mcr> is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders > mcr> here.... the cross-check seems useful, but maybe in the end, it's a left-over > mcr> From when voucher-requests could be unsigned. > > ben> I don't actually have a big complaint, here (and am definitely not asking > ben> to change the wire bits!). Perhaps we could go easy on "unique" or maybe > ben> just acknowledge that there's supposed to be a 1:1 map between serial > ben> number and IDevID. (Or not, of course.) > > Text previously added: > In the context of BRSKI, pledges have a 1:1 relationship > with a "serial-number". > > >> In the ANI case, we are likely doing this over wired links (long-haul fiber > >> or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch > >> use, this would be WIFI / 802.15.4. > >> > >> What is needed is a three-party zero-knowledge proof, but how would the > >> Registrar identify the third party (the MASA)? > >> > >> You are right to worry, but I don't know what to do about this. > > > I don't, either. Well, I do: "document it and move on", but that still > > leaves a bad taste in my mouth. > > Just added: > > > The certificate of the Registrar is rather arbtirary from the > point of view of the BRSKI protocol. As no > validations are expected to be done, the contents could be easily > pseudonymized. Any device that can see a join proxy would be > able to connect to the Registrar and learn the identity of the > network in question. Even if the contents of the certificate > are pseudonymized, it would be possible to coorelate different > connections in different locations belong to the same > entity. This is unlikely to present a significant privacy concern > to ANIMA ACP uses of BRSKI, but may be a concern to other users > of BRSKI. > > > The certificate of the Pledge could be revealed by a malicious > Join Proxy that performed a MITM attack on the provisional TLS > connection. Such an attacker would be able to reveal the > identity of the Pledge to third parties if it chose to so. > > > Research into a mechanism to do multi-step, multi-party authenticated > key agreement, incorporating some kind of zero-knowledge proof > would be valuable. Such a mechanism would ideally avoid > disclosing identities until pledge, registrar and MASA agree to > the transaction. Such a mechanism would need to discover the > location of the MASA without knowing the identity of the pledge, > or the identity of the MASA. This part of the problem may be unsolveable. > > > >> > Section 2.5.1 > >> > >> > The pledge is the device that is attempting to join. Until the > >> > pledge completes the enrollment process, it has link-local network > >> > connectivity only to the proxy. > >> > >> > nit(?): I think there is a subtle difference in meaning between "only > >> > has link-local network connectivity to the proxy" and this text, and I'm > >> > not sure which is intended. > >> > >> I'm confused. > > > The current text asserts that it has link-local connectivity, and further > > that the extent of this connectivity is limited to the proxy. My > > alternative asserts that it can only talk to the proxy over this link-local > > connectivity, but leaves open the possibility of other avenues of > > communication (e.g., a WWAN card). > > changed to: > > The pledge is the device that is attempting to join. > The pledge can talk to the Join Proxy using link-local network > connectivity. In most cases, the pledge has no other > connectivity until the pledge completes the enrollment process > and receives some kind of network credential. > > > >> > Section 2.6.1 > >> > >> > Many devices when bootstrapping do not have knowledge of the current > >> > time. Mechanisms such as Network Time Protocols cannot be secured > >> > until bootstrapping is complete. Therefore bootstrapping is defined > >> > in a method that does not require knowledge of the current time. A > >> > >> > nit: I'd suggest maybe "framework", "scenario", or "environment" rather > >> > than "method". > >> > >> done. > >> > >> > Section 2.6.2 > >> > >> > [RFC5280] explains that long lived pledge certificates "SHOULD be > >> > assigned the GeneralizedTime value of 99991231235959Z". Registrars > >> > >> > This misses the important "for the notAfter field" part. > > > (The above and below were separate comments; not sure if that came > > through.) > > I think that I got it. It says: > > > explains that > long lived pledge certificates "SHOULD be assigned the > GeneralizedTime value of 99991231235959Z" for the notAfter field. > > > ben> I don't see the connection between "configure itself to become the > ben> local registrar" and "contact a well-known URI of a cloud registrar". > >> > >> In a completely Greenfield situation, where there is no local infrastructure > >> at all, given an appropriately magic "Intent" (remember where this WG > >> started...), then a cloud registrar could inform a device that it is > >> to become the Registrar. How this would work depends upon the details > >> of the magic unicorn Intent (see failed SUPA WG). > > > Ah. So the cloud registrar is an extra-featureful registrar that can do > > more than just register things. I get it now, but am not sure how to best > > word it. > > I don't know what it can do, because it's not in scope. > > >> > If the pledge uses a well known URI for contacting a cloud registrar > >> > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > >> > authenticate service as described in [RFC6125]. This is consistent > >> > ben> Would this be more likely to be installed by the manufacturer or > ben> device owner? > >> > >> Manufacturer, as it's implicit. That's how EST works today. > > > So you think "implicit" is enough and adding something like "burned-in" or > > "manufacturer-assigned" is overkill? > > It says: > a manufacturer-assigned Implicit Trust Anchor database (see ) MUST > > now. > > >> There is a TLS connection between them. Yes, it could go anywhere. > >> The proxy was link-local, and the proxy pointed the connection at the > >> Registrar. I guess it would be useful if the proxy was stateful, and > >> contributed another cryptographic layer for non-ACP cases. > >> > >> In the ACP case, the Registrar knows it can trust the proxy because it's on > >> the ACP, and is connecting from an ULA address that is part of the ACP. > >> > >> Yes, the Registrar could be anywhere, but the proxy makes it appear > >> to be on the local link. > >> > >> I'm not sure what else I can add to the text. > > > "There is a TLS connection between a and b" says almost nothing without > > some additional context -- there are millions of machines I can make a TLS > > connection to from here. I assume that the unstated context here is that > > the pledge is expected to be in a limited-connectivity environment, so the > > fact that the network allowed the connection through to the registrar > > conveys meaning. But I don't remember anything in this document that > > actually validates that the pledge really is in a limited network > > environment. Could some rogue node ("attacker") be trying to talk to a > > proxy or registrar directly, from somewhere else in the network? How would > > we tell? > > There is a TLS connection from the ACP's ULA/128 to ULA/128 implies that it's not going > the Internet directly. > > A rogue node could be on the join network (the one with link-local > connectivity), and could operate and announce a Join Proxy. > > What could it do? > a) it could have some other backhaul (1200-baud modem, LTE, 100G, etc.) that > connects it to some (other?) Registrar. Whether or not this is a malicious > attack, or just another possible network depends upon intent (in the legal > sense, not the SUPA sense) > > b) it could double proxy the traffic to another Join Proxy on the real > network. It could then observe TLS framing, which for TLS 1.2 means > observing certificates. If it does not mount a MITM attack, then > it is not clear to me what it causes. > If it does mount a MITM attack, then it is just a malicious registrar, > and either it succeeds in getting a voucher issued (because the MASA > agrees), or it fails and the pledge moves on. > > If the legitimate Registrar has a rogue Proxy on it's ACP network, then > that's a great concern, but it's really not any different than (b). > > I'm not sure what point I'm missing is. I'm just reiterating that we have to be careful how we talk about the proximity assertion; in the absence of knowing that the pledge is trying to join the ACP and is talking to a member of the ACP over a link-local address, there's not much to draw from the fact that there's a TLS connection. The -28 is in pretty decent shape about this, though I think I noted one or two places in ballot. > >> But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to > >> allow for some fancy HTTP/3 we know nothing about :-) > > > :) > > > Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP > > persistent connections", though? > > I am using the latter now. Please double-check; I think I saw one in the -28 (but didn't make a note of where). > >> I have an open request to *** MAX *** to clarify this part. > >> > >> > o The registrar performs log verifications in addition to local > >> > authorization checks before accepting optional pledge device > >> > enrollment requests. > >> > >> > Maybe give us a section reference to what the "log validations" are? > >> > >> We decided that we did not have enough experience to write normative language > >> here. (It's not an Internet Standard) > > > It doesn't have to be normative, but some discussion of things that might > > come into consideration during that process could still be useful. > > Section 5.8.3 has a fair bit of text on the log verificiations. > I've added a forward reference. Section 5.8.3 finishes with: > > A relatively simple policy is to white list known (internal or > external) domainIDs. To require all vouchers to have a nonce. > Alternatively to require that all nonceless vouchers be from a subset > (e.g. only internal) of domainIDs. If the policy is violated a > simple action is to revoke any locally issued credentials for the > pledge in question or to refuse to forward the voucher. The > Registrar MUST then refuse any EST actions, and SHOULD inform a human > via a log. A registrar MAY be configured to ignore (i.e. override > the above policy) the history of the device but it is RECOMMENDED > that this only be configured if hardware assisted (i.e. TPM > anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported. > > And that's all the comments that I see. > I believe I'm done. We need to get you a prize for responding to so many comments. Thanks again! -Ben From nobody Fri Oct 18 05:14:01 2019 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 8E1EB1200B4; Fri, 18 Oct 2019 05:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 DIqn_-FEUpUa; Fri, 18 Oct 2019 05:13:46 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80132.outbound.protection.outlook.com [40.107.8.132]) (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 04C5B1200B3; Fri, 18 Oct 2019 05:13:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cv73SNsGF/SPqDx5c0di8CqA2ijbcKAnOIlj51rLy5eoMffBLL9QgSVRCWLB5kbC5mj4SqNpeTe1k/hdrMbk7uZvG9BuJskxICixx3Vx+JYvPTCPpgo/AkEw9pjrz1rlGIW0XnCQJJRC2SpbPewUA1HRgM952+FEbjxi5QkvpbwhVbEQeiA7l8Lj/Vei0rnGjQZ3nQOMckbwcZ8/u8jN8WN2N+ForUC9y8u1AMdAf5+f6fRe5zue25E2lG4OVCdQEJI2+6RXGdcrYgeNR89rfkCynr0rWPE4Y/1OBBsMGMoFW65XScEhp8TsFe/Bbkpwk6tUtjLO+P35RG8S7A6IjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h3N3kVpa98JmPCefCVvxZVemwtOrqky9deYnimYwFx4=; b=nhDZMdhUrqrFLQqd9zhTvvZmxk7ML1s9y1Xc/kMIGL8Lw5GTzTC0Dd0FfB4lnWSE7kwWvyaoMte2Nngk7+6H9kPmv5VVdXymXQLnSLrNZ0Z4qA8Q2BQ8LFTPw1IaC1wXkizSlzGR49enmCbv/py3L5ndTai3uwNaalHfZmoeg+9e1F0bZjD8aYHZXoRD1BUx/9+t1XBP1ByI1tcvFfqWts04lxn0SC45YpqxTZOgexCMkpnHblPTy9cyh/rLRa1yM8ZMOeuTN+XAtYEtxPSMihP43MBDJQfpuASnPM4O2fmS9tghdxdWBHB3AWpIzxeJsNVpZ8tjhm7t6McuCmnweQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h3N3kVpa98JmPCefCVvxZVemwtOrqky9deYnimYwFx4=; b=W04WtnhUoGqRawsLGR/ppomxu4ucCqdfj4lXyGAXewTHM1zQfjglM73asVjJ4qW2aodet9U+euVAf+DgvZTEovehGIM+xE0zIrFz1HEV0KRj9aboFyXkTesiaznrAWKDVkCQ67ScwG1xiHE2ePb2WxjtKov9M5U8eBxmoRAe8yo= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB6148.eurprd07.prod.outlook.com (20.178.115.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Fri, 18 Oct 2019 12:13:42 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2347.021; Fri, 18 Oct 2019 12:13:42 +0000 From: tom petch To: Alissa Cooper , Dan Romascanu CC: "gen-art@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "ietf@ietf.org" , "anima@ietf.org" Thread-Topic: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 Thread-Index: AQHVgzylZL/55Dso/kSfI5QixLQChA== Date: Fri, 18 Oct 2019 12:13:42 +0000 Message-ID: <048901d585ad$25f8dac0$4001a8c0@gateway.2wire.net> References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> <6CF1EF8F-EE0D-4BE6-B2C2-4C91883A881B@cooperw.in> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0455.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::35) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 83da6717-0faf-40fb-0583-08d753c49de4 x-ms-traffictypediagnostic: AM0PR07MB6148: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(376002)(396003)(366004)(13464003)(189003)(199004)(50226002)(5660300002)(61296003)(71190400001)(186003)(26005)(52116002)(6116002)(71200400001)(81166006)(81156014)(3846002)(446003)(476003)(14496001)(486006)(966005)(478600001)(54906003)(110136005)(8676002)(8936002)(4720700003)(14454004)(316002)(44736005)(6486002)(99286004)(6436002)(229853002)(2906002)(1556002)(305945005)(256004)(66066001)(14444005)(7736002)(386003)(53546011)(25786009)(102836004)(6506007)(81686011)(81816011)(76176011)(4001150100001)(62236002)(44716002)(86362001)(66946007)(66476007)(66556008)(64756008)(66446008)(4326008)(6246003)(9686003)(6512007)(6306002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6148; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: j4GdWIjzPGRnwtLX9xCUjsb+i849HSdWVRGlGjU8HgjlLXh5iMNY3ew+WtNWKAS54/Gqbq/8KpPMEPWPVJpmrvqnEu3tZg1LaACtjp+qbWA4aBf2FH38sxvFq7I7wK0U5nw7RtYqj/MSbV6usnn4rK21+P6hcEIUPEQ3rbc1AP2k+aq1lG8btB70Bnx7WlkJOlr5GyggMTM7FNu+gFyU3tX5Xc1HKyMDSm7QnC9dIGu06aSd5FZbWBr7jfysDlsXq/2v0pS7deTt3ieFNVf1CAUqAEWZZUFvgZfOVaxQSN0GOmR2TPOvvaYrxUdCtUL42VFVLlaXLwaHYFwTAIBiow6R2tcAgP20H9BraUEKX2yb4tCI271bW+YyPE4+3dKayleVAg3WRgiAPQO/SYxBS3aZFm5n3jm4EeRsR4ZapbIydAc1wr6LuR8THXGRjaKkj499w7Fuf9cuFCYTRCrswQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7257EB86BF131C4D9125A6043516421A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83da6717-0faf-40fb-0583-08d753c49de4 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 12:13:42.5735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vu0snAt/i22mqRRr9emXqrGBs6oBB+B9z5IExzmGVmv8ZS6BqtEw5GqMgfeJNVamiLHVe3WPgzWXBSVIArblLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6148 Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 12:13:49 -0000 Looking some more at this I-D, I have more concerns about the YANG module. My review is informal - I recommend that the WG Chair request a formal review because I may be missing something particularly in connection with the 'refine' statements. The I-D has namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; prefix "vch"; whereas RFC8366, which it augments, has namespace "urn:ietf:params:xml:ns:yang:ietf-voucher"; prefix vch; Different module, same prefix; this contradicts a SHOULD NOT in RFC8407. Further, this I-D defines import ietf-voucher { prefix v; i.e. does not use the prefix defined in RFC8366. This contradicts a MUST in RFC8407. There is a discrepancy between the e-mail addresses of the authors of the YANG module and of the I-D, for Author: Kent Watsen Author: Toerless Eckert I note that the e-mail addresses for the YANG module are the same as those for the YANG module in RFC8366; I do not know which are correct. contact "WG Web: should be https: and usually points to datatracker.ietf.org not tools Tom Petch ----- Original Message ----- From: "Alissa Cooper" To: "tom petch" ; "Dan Romascanu" Cc: ; ; ; Sent: Wednesday, October 16, 2019 3:57 PM Dan, thanks for your review. Tom, thanks for your response. I entered a DISCUSS ballot to make sure the issues with the YANG modules get fixed. I also noted the need for a response to the full Gen-ART review. Alissa > On Oct 15, 2019, at 5:40 AM, tom petch wrote: > > Dan > > I had a quick look at the YANG and it does indeed need some work IMHO. > I have posted a separate e-mail listing what I saw. > > Tom Petch > > > ----- Original Message ----- > From: "Dan Romascanu via Datatracker" > Sent: Sunday, October 13, 2019 9:39 AM > >> Reviewer: Dan Romascanu >> Review result: Ready with Issues >> >> 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-bootstrapping-keyinfra-?? >> Reviewer: Dan Romascanu >> Review Date: 2019-10-13 >> IETF LC End Date: None >> IESG Telechat date: 2019-10-17 >> >> Summary: Ready with Issues >> >> This document specifies automated bootstrapping of an Autonomic > Control Plane >> by creating a Remote Secure Key Infrastructure (acronym BRSKI) using >> manufacturer installed X.509 certificates, in combination with a > manufacturer's >> authorizing service, both online and offline. >> >> Christian Huitema and Jari Arkko have performed early reviews of > previous >> versions of the document for SecDir and Gen-ART. As far as I can tell, > most if >> not all of their major concerns concerning applicability and security > have been >> addressed in the latest versions. A few more minor issues described > below would >> better be clarified before approval. >> >> I also observe that the document has consistent Operational > implications but >> there is no OPS-DIR review so far, as well as a YANG module and > several other >> references to YANG, but there is no YANG Doctors review. I hope that > these will >> be available prior to the IESG review. >> >> Major issues: >> >> Minor issues: >> >> 1. The Pledge definition in section 1.2: >> >>> Pledge: The prospective device, which has an identity installed at >> the factory. >> >> while in the Introduction: >> >>> ... new (unconfigured) devices that are called pledges in this >> document. >> >> These two definitions seem different. The definition in 1.2 does not > include >> the fact that the device is 'new (unconfigured'. Also, arguably > 'identity >> installed at the factory' may be considered a form of configuration. >> >> 2. The document lacks an Operational Considerations section, which I > believe is >> needed, taking into consideration the length and complexity of the > document. >> There are many operational issues spread across the document > concerning the >> type and resources of devices, speed of the bootstrapping process, > migration >> pass, impact on network operation. I suggest to consider adding such a > section >> pointing to the place where these issues are discussed and adding the > necessary >> information if missing. Appendix A.1 in RFC 5706 can be used as a > checklist of >> the issues to be discussed in such a section. >> >> 3. Section 5.4: >> >>> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is >> REQUIRED. >> >> What is the reason for using 'encouraged'? Why not RECOMMENDED? >> >> Nits/editorial comments: >> >> 1. The Abstract includes: >> >> 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' >> >> Later in the document BRSKI is idefined as a protocol. It would be > good to >> clarify if BRSKI =3D BRSKI protocol >> >> 2. In Section 1 - Introduction, 3rd paragraph: >> >> s/it's default modes/its default modes/ >> s/it's strongest modes/its strongest modes/ >> >> 3. Please expand non-obvious acronyms at first occurrence: EST > protocol, LLNs, >> REST interface, LDAP, GRASP, CDDL, CSR >> >> 4. I would suggest alphabetic order listing of the terms in section > 1.2 >> >> 5. Section 1.3.1 - a reference for LDevID would be useful >> >> 6. Section 7: >> >> s/Use of the suggested mechanism/Use of the suggested mechanisms/ >> >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Fri Oct 18 09:38:32 2019 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 DD33812000F; Fri, 18 Oct 2019 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.734 X-Spam-Level: * X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 FCXE9uNcHPTW; Fri, 18 Oct 2019 09:38:28 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70128.outbound.protection.outlook.com [40.107.7.128]) (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 AC23D120103; Fri, 18 Oct 2019 09:38:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jxsJxxLcSyrJT8uSIF9LBsKJdHoZACL5eOvtLZOY8nsg/MY8HCd6R4YdrV1fysZe6ePkz7a8LoUJs9fhdUmWq49012xzFfsgUUJk3o2x9qKdEgLuBxg9CHOF9pNHyHANrZU9OjfqtjpxkMcmd+z7pUN7vMxIhaD1cbxs7ZXp/C937NSOoowJ9Reu6LFTlrQkYHI+Km+kbID02SD4005ZHwOkon7t2lUkugP2PKayYMz1jZ0hKLOiazkMKj0BnARaJxyls6DwTpc3l2m3HCjx9K2OAT3FNW1zeE8rsfbe44gqE00PL7oK5eexh9Q3E8lVDVF1t1vznQbwvVD3/Tt6OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/aAKMaHAUqEyUi++QRZB5bXqjluacy69hV8Y7vaVRi0=; b=JcjPdPScI4i7hwj3E1T5CdlOZmVRd23Ml7y2t9hNzZpiZ2gGF1snZa2wsKguS85mkS2U2KYWGX6TThXBO6yinaxD4cjubaJ4PNGfmghx+/KcZNNgISeDb7AncoE3Gw84ETkfvIeREhsucVzN35G0JaKp/Gj70Z/7sIFBS4HueVVPyO6ueMQUldt4tftfB9IzPU3lmEBlVfdjKjss+Kp/+gQwYPjTzFLpluBymUjZ7dPkBG6hh5rU+SJhWhbTFQevKRv1vAjzFDKpbX2id3qwVd86e3ui+mpvNSzz5ps1+lKPR+F1lj+Ld25e6lyMEez1auzMHFVvgsnBqnUQpL/vbg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/aAKMaHAUqEyUi++QRZB5bXqjluacy69hV8Y7vaVRi0=; b=cv8Z7ai9+AjUwaJqKirNTUCLjqKTsk0gUJTkqbdMlVlamNuyQ0bAN6lY37OYmtuZ4wh1r+cNIlM6WttBXJlfLEH1Y0fagx6UsC7wxcj4xpIclPvZjd7YyqP98eri4Cgn2IzsOq8o/CVldwJDX5jAKBloUYVPMviPCUafPWiNZ6U= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB6340.eurprd07.prod.outlook.com (10.186.173.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.16; Fri, 18 Oct 2019 16:38:24 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2347.021; Fri, 18 Oct 2019 16:38:24 +0000 From: tom petch To: tom petch , Alissa Cooper , Dan Romascanu CC: "gen-art@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "ietf@ietf.org" , "anima@ietf.org" Thread-Topic: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 Thread-Index: AQHVhdJ1yd94RaKkVUSX4P9kACAk8w== Date: Fri, 18 Oct 2019 16:38:24 +0000 Message-ID: <010f01d585d2$20570d60$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0352.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::28) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1be132e-aa0d-4ed3-33b4-08d753e9980c x-ms-traffictypediagnostic: AM0PR07MB6340: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 01949FE337 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(366004)(376002)(136003)(13464003)(199004)(189003)(14444005)(54906003)(99286004)(476003)(81686011)(81816011)(26005)(52116002)(966005)(66446008)(229853002)(296002)(4001150100001)(316002)(44716002)(6486002)(6436002)(8936002)(44736005)(102836004)(66556008)(6116002)(66946007)(62236002)(256004)(3846002)(486006)(5660300002)(2906002)(14496001)(50226002)(53546011)(14454004)(6506007)(386003)(66476007)(64756008)(7736002)(71190400001)(81166006)(81156014)(66066001)(1556002)(71200400001)(66574012)(61296003)(8676002)(4326008)(6306002)(305945005)(25786009)(86362001)(4720700003)(110136005)(9686003)(478600001)(6246003)(6512007)(186003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6340; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s6gaI0GkC5pnlKWdkC5UA3aDUHdRSTWwSDRIfbB1rhoI/E0xrGo33DECfSKQQQHGeyvlpdBXPnT3HeTIEm0HDs5m41mM4o7M93xUa+Ft1cX9nJHRpSC7Bc0R2PLK6gAShhC5I3fSf9fmD0w+3TtURuNFgf3T/ksyYnZtiFONKUceZrCtHSZs+7LKfT3jr46dTcV9c7CcAv8EzMW1k2zuTzCbrriEZ3LW1TO/NyPngPLs6oijUL+8xfug1ykYTx0L8T6WhhpwGuQRajqBLGOmLHekIV58+UWj2kK0nOm8fMxk3mimPphtey5k3wgHVoufQKFDmSw6OSF+DA3Xlkx/kui8ZvYf/TGBnmavzZ7PTZVY74dwH3dQ9PyBJgeOwezcWEbxR/PK11NgAFO24ImXYABzD7uPyrDNldwgbN9l8B3NhVaU1ZdeVdmNwRksVzEii/S5/bhviEfJzQ5VpWP7fQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1be132e-aa0d-4ed3-33b4-08d753e9980c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 16:38:24.3874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GvpDdTYaUR735tLV7poVI0wna6xOWqmasKR9GSGFraTkF0ChG1gIXlEII7IqlPK0wcjr+/QfCwGK74PS6Cs2fw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6340 Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 16:38:30 -0000 A third set of comments The refine look ok to me (but I still recommend a formal review) leaf proximity-registrar-cert { description .. as specified by RFC 5280, .. as specified in ITU-T X.690. needs references; I suggest reference "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; plus [ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, . in the I-D Normative References Appendix A. IPv4 and non-ANI operations / The secification/ The specification/ Sorry for the bitty postings; more haste less speed. Tom Petch ----- Original Message ----- From: "tom p." To: "Alissa Cooper" ; "Dan Romascanu" Cc: ; ; ; Sent: Friday, October 18, 2019 1:11 PM Subject: Re: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 > Looking some more at this I-D, I have more concerns about the YANG > module. My review is informal - I recommend that the WG Chair request a > formal review because I may be missing something particularly in > connection with the 'refine' statements. > > The I-D has > namespace > "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; > prefix "vch"; > whereas RFC8366, which it augments, has > namespace "urn:ietf:params:xml:ns:yang:ietf-voucher"; > prefix vch; > Different module, same prefix; this contradicts a SHOULD NOT in RFC8407. > > Further, this I-D defines > import ietf-voucher { > prefix v; > i.e. does not use the prefix defined in RFC8366. This contradicts a > MUST in RFC8407. > > There is a discrepancy between the e-mail addresses of the authors of > the YANG module and of the I-D, for > Author: Kent Watsen > Author: Toerless Eckert > I note that the e-mail addresses for the YANG module are the same as > those for the YANG module in RFC8366; I do not know which are correct. > > contact > "WG Web: > should be https: and usually points to datatracker.ietf.org not tools > > Tom Petch > > ----- Original Message ----- > From: "Alissa Cooper" > To: "tom petch" ; "Dan Romascanu" > > Cc: ; > ; ; > > Sent: Wednesday, October 16, 2019 3:57 PM > > Dan, thanks for your review. Tom, thanks for your response. I entered a > DISCUSS ballot to make sure the issues with the YANG modules get fixed. > I also noted the need for a response to the full Gen-ART review. > > Alissa > > > > On Oct 15, 2019, at 5:40 AM, tom petch wrote: > > > > Dan > > > > I had a quick look at the YANG and it does indeed need some work IMHO. > > I have posted a separate e-mail listing what I saw. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Dan Romascanu via Datatracker" > > Sent: Sunday, October 13, 2019 9:39 AM > > > >> Reviewer: Dan Romascanu > >> Review result: Ready with Issues > >> > >> 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-bootstrapping-keyinfra-?? > >> Reviewer: Dan Romascanu > >> Review Date: 2019-10-13 > >> IETF LC End Date: None > >> IESG Telechat date: 2019-10-17 > >> > >> Summary: Ready with Issues > >> > >> This document specifies automated bootstrapping of an Autonomic > > Control Plane > >> by creating a Remote Secure Key Infrastructure (acronym BRSKI) using > >> manufacturer installed X.509 certificates, in combination with a > > manufacturer's > >> authorizing service, both online and offline. > >> > >> Christian Huitema and Jari Arkko have performed early reviews of > > previous > >> versions of the document for SecDir and Gen-ART. As far as I can > tell, > > most if > >> not all of their major concerns concerning applicability and security > > have been > >> addressed in the latest versions. A few more minor issues described > > below would > >> better be clarified before approval. > >> > >> I also observe that the document has consistent Operational > > implications but > >> there is no OPS-DIR review so far, as well as a YANG module and > > several other > >> references to YANG, but there is no YANG Doctors review. I hope that > > these will > >> be available prior to the IESG review. > >> > >> Major issues: > >> > >> Minor issues: > >> > >> 1. The Pledge definition in section 1.2: > >> > >>> Pledge: The prospective device, which has an identity installed at > >> the factory. > >> > >> while in the Introduction: > >> > >>> ... new (unconfigured) devices that are called pledges in this > >> document. > >> > >> These two definitions seem different. The definition in 1.2 does not > > include > >> the fact that the device is 'new (unconfigured'. Also, arguably > > 'identity > >> installed at the factory' may be considered a form of configuration. > >> > >> 2. The document lacks an Operational Considerations section, which I > > believe is > >> needed, taking into consideration the length and complexity of the > > document. > >> There are many operational issues spread across the document > > concerning the > >> type and resources of devices, speed of the bootstrapping process, > > migration > >> pass, impact on network operation. I suggest to consider adding such > a > > section > >> pointing to the place where these issues are discussed and adding the > > necessary > >> information if missing. Appendix A.1 in RFC 5706 can be used as a > > checklist of > >> the issues to be discussed in such a section. > >> > >> 3. Section 5.4: > >> > >>> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > >> REQUIRED. > >> > >> What is the reason for using 'encouraged'? Why not RECOMMENDED? > >> > >> Nits/editorial comments: > >> > >> 1. The Abstract includes: > >> > >> 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' > >> > >> Later in the document BRSKI is idefined as a protocol. It would be > > good to > >> clarify if BRSKI =3D BRSKI protocol > >> > >> 2. In Section 1 - Introduction, 3rd paragraph: > >> > >> s/it's default modes/its default modes/ > >> s/it's strongest modes/its strongest modes/ > >> > >> 3. Please expand non-obvious acronyms at first occurrence: EST > > protocol, LLNs, > >> REST interface, LDAP, GRASP, CDDL, CSR > >> > >> 4. I would suggest alphabetic order listing of the terms in section > > 1.2 > >> > >> 5. Section 1.3.1 - a reference for LDevID would be useful > >> > >> 6. Section 7: > >> > >> s/Use of the suggested mechanism/Use of the suggested mechanisms/ > >> > >> > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art > From nobody Fri Oct 18 19:46:03 2019 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 171FB120271 for ; Fri, 18 Oct 2019 19:46: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_HELO_NONE=0.001, 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 u5iYC4khqQCf for ; Fri, 18 Oct 2019 19:46:00 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 6019B120104 for ; Fri, 18 Oct 2019 19:46:00 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id e13so4335748pga.7 for ; Fri, 18 Oct 2019 19:46:00 -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=Rkvb9H1Rr8bfg9tA/PFbt1cN+6dWcdqaKJ5excDd+c4=; b=ezMW6eUSfCg9VLO8FPpUjIZbCpe7/Qtqmn6g1XIg+mXcfwQpnjnPHFYXjxapthlgBn NtEHa6VOBYhfBQVddsVF/aJK94vhyPE0B4kseABPD8u0ar9Bva1fU0J061YrdAF9GL02 lwLILvpQ65VfbjLB9SGlJLrsaWxy3h3HkJXc4jnS9BuC2hkWNsb2bnMB2bY3zGlv6r/i NYWVL00UpcNbirgHPiREALp0XVkC/swcp0KxWXrSn4WAaJyeavN2bfvlmETA2JRfTL7A FIAFTNetmSxBmpreBdWuvUQXMGkYPQxluu6Ix25x7JJEEmAMmoXqDFoZYCNMH1i+DUJJ rrIw== 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=Rkvb9H1Rr8bfg9tA/PFbt1cN+6dWcdqaKJ5excDd+c4=; b=E2VLYvHG/ZGHh+MKEXPJmv5eEOFvet1qxAQJRRPWxE74E1M3lv63XPm582rLDRBawB K770OSb+RUBff50ul7Ux45+2dcjLjeOaR7LSCYikUUGnhooQHMfwrdCiTF8ggNWs9n93 fqZl8mwLfWoaD0lumu7I9TA6931EP56n2wN6liXzTSRMzjsfbrbM7guhxSpxAt4Fhc+I UyLoaTIqT+SJIzOp2UczBnRWXxC78otxEoikMXsF6p3SOZ69pug1i0+3aoycXP6XLOP3 3OO882vgtepJjvXogl3KAjg3J6y8vuCOwr4SgxXwm8JEU9OXwDrrvjoHKO0qGyoIaGV6 X2gA== X-Gm-Message-State: APjAAAVP9OglI7QD8T5OirOmHAds5TXl1kC9YyY9zcFV839f2dMbDlWN M0WrzLXtgdjefXZ1vlkkxVAs3zraDDA= X-Google-Smtp-Source: APXvYqzAYlGFzfYNGwSjzvB0588e++q+Ot9O2SV5z67PVRAO2oV+GyxDsJaOkk7vn0W3jEoJxIqA9w== X-Received: by 2002:aa7:9ec5:: with SMTP id r5mr9983921pfq.230.1571453159340; Fri, 18 Oct 2019 19:45:59 -0700 (PDT) Received: from [192.168.178.30] (233.148.69.111.dynamic.snap.net.nz. [111.69.148.233]) by smtp.gmail.com with ESMTPSA id b3sm6388920pjp.13.2019.10.18.19.45.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Oct 2019 19:45:58 -0700 (PDT) To: Anima WG References: <157119680788.27903.13179607309356466653@ietfa.amsl.com> <3da214d4-2c4f-ca4d-a337-0db93efc1a46@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 19 Oct 2019 15:45:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <3da214d4-2c4f-ca4d-a337-0db93efc1a46@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] QUADS for GRASP - code release X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 02:46:02 -0000 Hi, I've posted a new version of the GRASP Python prototype, with QUADS security, to GitHub at https://github.com/becarpenter/graspy . The updated files are graspy.pdf (Documentation) <=== start here grasp.py (GRASP core and API) gremlina.py (a stand-alone GRASP daemon) quadsmaker.py (QUADS key making utility) Regards Brian On 16-Oct-19 16:44, Brian E Carpenter wrote: > Hi, > > This week I got a bit bored waiting for a working ACP for use with my > GRASP prototype, so I decided to implement some quick and dirty security > (QUADS) for GRASP, which is effectively a simple ACP emulated just above > the transport layer, using symmetric crypto with shared keys. > > I have running code (about half a day's work, of which the majority was > understanding how to use the Python 'cryptography' module). I need to do > some more work before pushing it to GitHub, however. > > There's a draft (see below). Comments and discussion very welcome. > > Regards > Brian > > -------- Forwarded Message -------- > Subject: I-D Action: draft-carpenter-anima-quads-grasp-00.txt > Date: Tue, 15 Oct 2019 20:33:27 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Quick and Dirty Security for GRASP > Author : Brian Carpenter > Filename : draft-carpenter-anima-quads-grasp-00.txt > Pages : 5 > Date : 2019-10-15 > > Abstract: > A secure substrate is required by the Generic Autonomic Signaling > Protocol (GRASP) used by Autonomic Service Agents. This document > describes QUADS, a QUick And Dirty Security method using symmetric > cryptography and preconfigured keys or passwords. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-carpenter-anima-quads-grasp-00 > https://datatracker.ietf.org/doc/html/draft-carpenter-anima-quads-grasp-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Tue Oct 22 07:48:17 2019 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 25AA7120152 for ; Tue, 22 Oct 2019 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 M-6oi61vv0mN for ; Tue, 22 Oct 2019 07:48:14 -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 DA580120013 for ; Tue, 22 Oct 2019 07:48:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AEDBB3897A for ; Tue, 22 Oct 2019 10:45:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D29498F for ; Tue, 22 Oct 2019 10:48:12 -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] which base64 for RFC8366... original! X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 14:48:16 -0000 --=-=-= Content-Type: text/plain In answering DISCUSSes on BRSKI, I came up the question of do the YANG-serialization-to-JSON rules specify which base64 (original or urlsafe) encoding is to be used for "binary" types? RFC8366 only references RFC7950, which only peripherally mentions JSON, but it does say: 9.8.2. Lexical Representation Binary values are encoded with the base64 encoding scheme (see Section 4 in [RFC4648]). 9.8.3. Canonical Form The canonical form of a binary value follows the rules of "Base 64 Encoding" in [RFC4648]. but maybe this only applies to XML-serialization.... searching further: So, why doesn't RFC8366 reference: https://datatracker.ietf.org/doc/rfc7951/ 6.6. The "binary" Type A "binary" value is represented as a JSON string -- base64 encoding of arbitrary binary data. The representation is identical to the lexical representation of the "binary" type in XML; see Section 9.8 in [RFC7950]. AHA, so it should be original base64, even though the first paragraph is a bit ambiguous, it does refer to 7950, which is not ambiguous. I wonder if this is worth an errata clarifying this for RFC8366? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2vFqwACgkQgItw+93Q 3WVksggAqXn8syrba2R6+/zzq72hc8wVNSTJzQx8tbMqQT4zjEiv1TNmThMK3bN/ nMFG8lYRQhghZeTijA+30q7dq8FD3lIu9lDo1GeLgkNSLkuM7W4Df/nXDiUYqEa0 Jk7SRtI3Gn3gG76MPRDc2wH3YP9k7HJj4M9CqJvluCIjOGf82kMMwvehjMOlKrEE Qf94PWQwhFF05T0KeUXBtfDanWaQTcSW2WEXh2lUgE041MMWQyATmZKy8gVdAl+V Xj2Y+4A8g2bQN+Q6T9J2s4E23yEF8H/VPT+WsjEL0IjMDiB2d0saBYK2BlMPe3XT L0C0ho+NpNqJ++5Zubr/54cEN7q3yA== =6Y8M -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 22 08:39:35 2019 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 DE435120043 for ; Tue, 22 Oct 2019 08:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 ocJm6rAsEbBZ for ; Tue, 22 Oct 2019 08:39:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A031A120073 for ; Tue, 22 Oct 2019 08:39:32 -0700 (PDT) Received: from [192.168.217.110] (p5089AE1C.dip0.t-ipconnect.de [80.137.174.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46yHkC0yYRzyYt; Tue, 22 Oct 2019 17:39:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <15459.1571755692@localhost> Date: Tue, 22 Oct 2019 17:39:33 +0200 Cc: anima@ietf.org X-Mao-Original-Outgoing-Id: 593451571.933713-c7fe12519f326f54c7c2f7484c07c58c Content-Transfer-Encoding: quoted-printable Message-Id: <4C61CD6A-EDFB-4521-8811-858085E84BC4@tzi.org> References: <15459.1571755692@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] which base64 for RFC8366... original! X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 15:39:35 -0000 > On Oct 22, 2019, at 16:48, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > In answering DISCUSSes on BRSKI, I came up the question of do the > YANG-serialization-to-JSON rules specify which base64 (original > or urlsafe) encoding is to be used for =E2=80=9Cbinary" types? Legacy (RFC 4648 Section 4 =3D non-URL-safe, with padding). Look at the examples, which give it away by always ending in =3D=3D :-) > RFC8366 only references RFC7950, which only peripherally mentions = JSON, but it does say: >=20 > 9.8.2. Lexical Representation >=20 > Binary values are encoded with the base64 encoding scheme (see > Section 4 in [RFC4648]). There it is. The YANG-to-JSON rules are in RFC 7951. 6.6. The "binary" Type A "binary" value is represented as a JSON string -- base64 encoding of arbitrary binary data. The representation is identical to the lexical representation of the =E2=80=9Cbinary" type in XML; see Section 9.8 in [RFC7950]. So this is legacy, too. > 9.8.3. Canonical Form >=20 > The canonical form of a binary value follows the rules of "Base 64 > Encoding" in [RFC4648]. >=20 > but maybe this only applies to XML-serialization.... searching = further: >=20 > So, why doesn't RFC8366 reference: > https://datatracker.ietf.org/doc/rfc7951/ No idea. But then, RFC 8366 says The voucher artifact is a JSON [RFC8259] document that conforms with a data model described by YANG [RFC7950], is encoded using the rules defined in [RFC8259], and is signed using (by default) a CMS structure [RFC5652]. which is pretty much devoid of meaning. > I wonder if this is worth an errata clarifying this for RFC8366? Yes, but maybe the WG should decide first what was intended=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Oct 22 13:24:06 2019 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 6867D120041; Tue, 22 Oct 2019 13:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 9lRU67vWnuoU; Tue, 22 Oct 2019 13:23: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 20E7C120077; Tue, 22 Oct 2019 13:23:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D0B563897A; Tue, 22 Oct 2019 16:21:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C358B77; Tue, 22 Oct 2019 16:23:51 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-reply-to: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> Comments: In-reply-to Benjamin Kaduk via Datatracker message dated "Thu, 17 Oct 2019 07:08:49 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [NITS] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 20:23:57 -0000 --=-=-= Content-Type: text/plain Hi, this got quite long. I've split this up into nits and substantive comments. This email is about the nits... it should all be boring and uncontroversial, requiring no answers from you, I hope. Please see a diff at: https://tinyurl.com/y5l4xz3z Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > [All new comments for the -28] > Please respond to the secdir re-review. > Abstract > nit: hyphenate "manufacturer-installed" done. > or on limited/disconnected networks. Support for lower security > models, including devices with minimal identity, is described for > nit: maybe "deployment models with less-stringent security > requirements"? I had actually edited the abstract into leaving that sentence incomplete, now fixed. > Section 1 > [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process > satisfies the [RFC7575] section 3.3 of making all operations secure by > default. Other users of the BRSKI protocol will need to provide > nit: missing "requirement" already fixed it seems > between manufacturer and owner: in it's default modes it provides a > cryptographic transfer of control to the initial owner. In it's > strongest modes, it leverages sales channel information to identify > nit: s/it's/its/ already fixed. > Section 1.2 > domainID: The domain IDentity is a unique hash based upon the > Registrar CA's certificate. Section 5.8.2 specifies how it is > calculated. > nit: the grammar here is weird; I'd suggest s/hash based upon/value > derived from/ done. > MASA Audit-Log: A list of previous owners maintained by the MASA on > a per device (per pledge) basis. Described in Section 5.8.1. > nit: maybe "anonymized list" since the MASA doesn't really track owners > directly? done. > Ownership Tracker: An Ownership Tracker service on the global > Internet. The Ownership Tracker uses business processes to accurately > track ownership of all devices shipped against domains that have > purchased them. Although optional, this component allows vendors to > provide additional value in cases where their sales and distribution > channels allow for accurately tracking of such ownership. Ownership > tracking information is indicated in > nit: either "accurate tracking of" or "accurately tracking" fixed. > ANI: The Autonomic Network Infrastructure as defined by > [I-D.ietf-anima-reference-model]. This document details specific > requirements for pledges, proxies and registrars when they are part of > an ANI. > Maybe refer to section 9 specifically? okay. > Section 2.3.1 > The serialNumber fields is defined in [RFC5280], and is a SHOULD > field in [IDevID]. IDevID certificates for use with this protocol > nit: s/fields/field/ fixed a different way for Christian. > Section 2.5.3 > The registrar uses an Implicit Trust Anchor database for > authenticating the BRSKI-MASA TLS connection MASA certificate. The > registrar uses a different Implicit Trust Anchor database for > authenticating the BRSKI-EST TLS connection pledge client certificate. > Configuration or distribution of these trust anchor databases is > out-of-scope of this specification. > Configuration or distribution of this trust anchor databases is out- > of-scope of this specification. Note that the trust anchors in/ > excluded from the database will affect which manufacturers' devices are > acceptable to the registrar as pledges, and can also be used to limit > the set of MASAs that are trusted for enrollment. > We seem to duplicate the "out-of-scope" text at the end/start of the > two paragraphs (and the second paragraph uses the definite article > "the" as if it was only talking about one of the two trust anchor > databases). okay. keeping the second version, changing this->these. > Section 2.6.1 > A pledge with a real time clock in which it has confidence in, MUST > check the above time fields in all certificates and signatures that ir > processes. > nits: s/ir/it/, and s/in// from "in which it has confidence in" (your > choice which one). done. > Section 2.6.2 > year certificate lifetimes. Registrars SHOULD be configurable on a > per-manufacturer basis to ignore pledge lifetimes when they did not > follow the RFC5280 recommendations. > nit: we want "they" to be the manufacturer, not the registrar, so we > can't use this pronoun. Should be pledge, fixed. > Section 2.7 > be more important in the future. In the ANIMA ACP scope, new > devices will be quarantined behind a Join Proxy. > I can't decide whether the reader would benefit from being hit with a > hammer of "and as such will only have link-local connectivity, to the > Join Proxy". The use of "quarantined" makes me lean towards "not"... agreed. > Section 3.3 doc> Example (2) The following example illustrates a registrar voucher- doc> request. The 'prior-signed-voucher-request' leaf is populated with the doc> pledge's voucher-request (such as the prior example). The pledge's doc> voucher-request is a binary CMS signed object. In the JSON encoding doc> used here it must be base64 encoded. The nonce and assertion MAY be doc> carried forward from the pledge request to the registrar request. The doc> serial-number is extracted from the pledge's Client Certificate from doc> the TLS connection. See Section 5.5. > Since this is an example, the "MAY be carried forward" feels out of > place -- while it's true in the general case, this is not the place to > say it; we can just describe what the example does, here. Agreed, I will change that to "have been carried forward" > Section 4 > This section applies is normative for uses with an ANIMA ACP. The > nit: pick one of "applies to" or "is normative for". The text now says: doc> This section is normative for uses with an ANIMA ACP. > use of GRASP mechanism part of the ACP. Other users of BRSKI will > nit: missing "is" already fixed. > Section 4 > Registrar itself. In this scenario the pledge is unaware that there > is no proxing occurring. This is useful for Registrars which are > nit: s/proxing/proxying/ fixed, ty. > Section 4.3 > The M_FLOOD message MUST be sent periodically. The default SHOULD > be 60 seconds, the value SHOULD be operator configurable but SHOULD be > not smaller than 60 seconds. The frequency of sending MUST be such > nits: "default period" (or similar); s/be not/NOT be/ fixed. > Section 5 > While EST section 3.2 does not insist upon use of HTTP persistent > connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use > nit: comma after parenthetical, not before. fixed. doc> A self-signed certificate for the Registrar is acceptable as the doc> voucher will validate it. > nit: "will" applies only when everything works, so maybe "can" or "will > validate it in the case of successful enrollment". okay. > A pledge that can connect to multiple registries concurrently SHOULD > nit: s/registries/Regitstrars/ fixed. > Section 5.3 > on the authenticated identity presented. For different networks, > examples of Automated acceptance may include: > nit: s/A/a/ fixed. > Section 5.4 > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > REQUIRED. > As above, how painful would requiring 1.3 be? Consistently with the text above: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. TLS 1.3 (or newer) SHOULD be available. > client certificate. Registrars SHOULD also permit an HTTP Basic and > Digest authentication to be configured. > nit: s/an// fixed. > Section 5.4.1 > be uniquely identified. This can be done by any stateless method > that HTTPS supports: such as with HTTP Basic or Digest authentication > nit: this colon is not appropriate usage. ok. > Stateful methods involving API tokens, or HTTP Cookies are not > recommended. > nit: zero commas or two, around "or HTTP Cookies", but one is right > out. ok. > This document does not make a specific recommendation as there is > likely different tradeoffs in different environments and product > nit: s/is/are/ ok. > Section 5.5 > idevid-issuer: The Issuer value from the pledge IDevID certificate > is included to ensure a uniqueness of the serial-number. In the case > of nonceless (offline) voucher-request, then an appropriate value needs > to be configured from the same out-of-band source as the serial-number. > nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if > you don't take that, the "a" is superfluous in the current > formulation). ok. doc> The MASA verifies that the registrar voucher-request is internally doc> consistent but does not necessarily authenticate the registrar doc> certificate since the registrar MAY not be known to the MASA in doc> advance. The MASA performs the actions and validation checks > I suggest s/MAY not be known/MAY be unknown/. ok. > Section 5.5.5 doc> voucher-request MUST include a 'proximity-registrar-cert' that is doc> consistent with to the certificate used to sign the registrar > nit: s/to// (first one) ok > Section 5.6.1 doc> The pledge MUST verify that the voucher nonce field is accurate and doc> matches the nonce the pledge submitted to this registrar, or that the doc> voucher is nonceless (see Section 7.2). > In my previous Discuss position I had asked: % Is the pledge supposed > to accept a nonceless voucher in response to a % nonce-ful voucher > request? and we had some discussion that helped clarify the intent. I > just have a suggested rewording, that I *think* is entirely editorial > and might reduce the potential for confusion: NEW The pledge MUST > verify the nonce information in the voucher. If present, the nonce in > the voucher must match the nonce the pledge submitted to the registrar; > vouchers with no nonce can also be accepted (according to local > policy). okay. > Section 5.7 doc> The Status field indicates if the voucher was acceptable. Boolean doc> values are acceptable. > nit: I suggest """acceptable, as a boolean, where "true" indicates the > voucher was acceptable""". ok doc> The version, and status fields MUST be present. The Reason field doc> SHOULD be present whenever the status field is negative. The Reason- doc> Context field is optional. > nit: no comma after "version". nit: s/negative/false/ ok doc> The keys to this JSON hash are case-insensitive. Figure 15 shows an doc> example JSON. > This (case-insensitivity) seems to be a drastic divergence from the RFC > 8259 standard behavior and as such would require some justification. > nit: s/hash/object/ okay, changed this to lower case. > Section 5.8.1 doc> It's hard to call Figure 17 an "example" when it doesn't conform to the doc> CDDL schema... fixed. doc> The domainID is a binary value calculated SubjectKeyIdentifier doc> according to Section 5.8.2. It is encoded once in base64 in order to doc> be transported in this JSON container. > nit: I suggest "binary SubjectKeyIdentifier value calculated" ok. > Section 5.8.2 doc> used as the domainID. If not, then it is the SPKI Fingerprint as doc> described in [RFC7469] section 2.4 is to be used. This value needs > nit: drop "is to be used" or "then it is". ok > Section 5.8.3 doc> A relatively simple policy is to white list known (internal or doc> external) domainIDs. To require all vouchers to have a nonce. > nit: sentence fragment. ok. doc> Alternatively to require that all nonceless vouchers be from a doc> subset > nit: comma after "alternatively". (Hmm, this is also a sentence > fragment.) ok. > Section 5.9.4 doc> In order to communicate this indicator, the client HTTP POSTs the doc> following to the server at the new EST endpoint at "/.well-known/est/ doc> enrollstatus". > "The following" is just more text, not a formal description of a > protocol element. > "reason-context": "Additional information" > Is this supposed to be a string or a JSON object similar to > /voucher_status? Yes, fixed this to be consistent. > Section 6 doc> When used within BRSKI, the original RFC7030 EST endpoints remain doc> Base64 encoded, but the new BRSKI end points which send and receive doc> binary artifacts (specifically, /requestvoucher) are binary. That > The other two occurrences spell this "/.well-known/est/requestvoucher". ok. > Section 7.2 doc> The following are a list of alternatives behaviours that the pledge doc> can be programmed to implement. These behaviours are not mutually doc> exclusive, nor are they dependant upon other. Some of these methods > nits: singular/plural mismatch "are"/"list"; "upon each other" fixed. > Section 7.4.1 > A MASA has the option of not including a nonce is in the voucher, > nit: s/is// already fixed. doc> This is useful to support use cases where registrars might not be doc> online during actual device deployment. > nit: there's enough intervening text that we should probably replace > "this is" with "nonceless vouchers are". ok. doc> authorized to provide this functionality to this customer. The MASA doc> is RECOMMENDED to use this functionality only in concert with an doc> enhanced level of ownership tracking (out-of-scope.) > I suggest s/out-of-scope/the details of which are out of scope for this > document/. ok. > Section 7.4.2 doc> functionality. This provides a proof-of-proximity check that doc> reduces the need for ownership verification. > I suggest reiterating the assumption that pledge and JP are on a > link-local connection; whether or not to reiterate that JP and > registrar have a trust relationship (with respect to not falsifying > proximity information) is less clear to me. ok. > Section 7.4.3 > We might benefit from some introductory text here to suggest that > updating/extending trust anchors would be desirable in the case of a > vanished or uncooperative manufacturer. ok. doc> This weaker factor reset might leave valuable credentials on the doc> device and this may be unacceptable to some owners. > nit: s/factor/factory/ ok. > Section 9 doc> Provider organizations. Equivalent enterprises that has significant doc> layer-3 router connectivity also will find significant benefit, > nit: s/has/have/ ok. doc> In the ACP, the Join Proxy is found to be proximal because doc> communication between the pledge and the join proxy is exclusively on > nit(?) My dictionary doesn't list anything for "proximal" that is a > good match for "with proximity"; might be worth double-checking. I find it: https://www.dictionary.com/browse/proximal?r=75&src=ref&ch=dic doc> asssertion is satisfied. Other uses of BRSKI will need make similar doc> analysis if they use proximity. > nit: maybe "proximity information" or "proximity assertions". ok. > Section 10.3 doc> While the contents of the signed part of the pledge voucher request doc> can not be changed, they are not encrypted at the registrar. The doc> ability to audit the messages by the owner of the network a mechanism doc> to defend against exfiltration of data by a nefarious pledge. Both > nit: missing verb ("is a mechanism", "provides a mechanism", etc.) fixed. doc> The manufacturer knows the IP address of the Registrar, but it can doc> not see the IP address of the device itself. The manufacturer can not doc> track the device to a detailed physical or network location, only to doc> the the location of the Registrar itself. That is likely to be at > nit: we probably don't need the last "itself". okay. doc> is likely on the same network as the device. A manufacturer that doc> sells switching/routing products to enterprises should hardly be doc> surprised if additional purchases switching/routing products are doc> purchased. Deviations from a historical trend or an establish > nit: we probably only need one of "purchases" and "purchased". agreed. > Section 10.6 doc> Section Section 7.4.3 describes some ways in which a manufacturer > nit: duplicate "Section". fixed. > Section 10.7 doc> existing products. Said products might be previous deployed and doc> need to be re-initialized, purchased used, or just kept in a warehouse doc> as long-term spares. > nit: s/previous deployed and need/previously deployed that need/ fixed. > Section 11.2 doc> In particular implementations should pay attention to the advance in doc> [RFC4086] section 3, particulary section 3.4. Devices which are reset doc> to factory default in order to perform a second bootstrap with a new doc> owner MUST NOT seed their random number generators in the same way. > nit: s/same way/same way across bootstraps/ fixed. > Section 11.5 > This next section examines the risk due to a compromised MASA key. > This is followed by examination of the risk of a compromised > manufacturer IDevID signing key. The third section sections below > nit: I think these appear in the other order. done. > Section 13.1 > [cabforumaudit] and [dnssecroot] probably would be fine as just > informative references. okay. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2vZVcACgkQgItw+93Q 3WUQeQgArYCbT4hsWD/AXzVbYSSjfDK7Xn9Y6Hv/cwUvvMnFKsZfH0DINrgaJ5ZZ COiGFCzhzYVjeXirusb7L6jPfWQDRgthYDbYxi4QNpCviQmbQnajfRlzR57dM1WD S4WVktWyKo9qlSSigEYcvtMYZknTplQlp1M/RClWFbSLCdZyeB6zQcQZBMEnzuQ5 4LfnJNrCo4kmbAQFgmtpDy0bPzY5hYSQcAy9XmmTcQ34huv14Qrc2npNGt/MS0wd phxvIc46CVUI9z62/SElCpsqhFSbTcbEHVNAp2Y2qBT9N/ej2mSBG8ETRJRY3Fmv +hJc7q2pWppoEzM3CRKBlIPpq6h/Rg== =KDQn -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 22 13:24:13 2019 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 E1918120812; Tue, 22 Oct 2019 13:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 ooNzhfXyP358; Tue, 22 Oct 2019 13:23:58 -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 8222F120041; Tue, 22 Oct 2019 13:23:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 828ED38986; Tue, 22 Oct 2019 16:21:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 777EC77; Tue, 22 Oct 2019 16:23:57 -0400 (EDT) To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org In-reply-to: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> Comments: In-reply-to Benjamin Kaduk via Datatracker message dated "Thu, 17 Oct 2019 07:08:49 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 X-Attribution: mcr 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 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Tue, 22 Oct 2019 16:23:57 -0400 Message-ID: <25780.1571775837@localhost> Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [COMMENTS] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2019 20:24:10 -0000 --=-=-= Content-Type: text/plain Hi, this got quite long. I've split this up into nits and substantive comments. This email is about the substantive comments. Please see a diff at: https://tinyurl.com/y5l4xz3z Benjamin Kaduk via Datatracker wrote: > Thanks for the time and attention to detail put into addressing my > previous Discuss and Comment points. I have one new Discuss-level > point and one that I think may have been missed (probably because I > inadvertently numbered two points with the same number). > (16) The audit log response (Section 5.8.1) describes the nonce as a > JSON string, but the RFC 8366 nonce is a binary value. I think we need > to describe some mapping procedure (such as always base64-encoding as > is done for domainID, even if the original nonce is itself > base64-encoded random data) in order to be fully functional. In the JSON mapping of the YANG, binary values are always base64 encoded, as JSON does not support binary values. This would be an issue in the constrained-voucher CBOR mapping through. > % (1) The text of the document suffers from lack of clarity throughout > about % whether the nonce-ful operation is mandatory or not, with > several % figures and discussions making declarative statements about > nonce usage % and others saying that nonce usage is optional. (See > COMMENT.) > [keep in mind when reading] > % (5.1) the new /enrollstatus EST endpoint seems under-specified. > Shame on me, I reused (5) for two points and have renumbered this to > (5.1) so we don't miss it again. We don't anywhere give a formal > description of the contents of the POST body; there's just an example > JSON object. Agreed, and there is a comment about the subjectKeyInfo. I had opened issue: https://github.com/anima-wg/anima-bootstrap/issues/141 last week when I started writing this. We have resolved this ticket as follows: The original purpose of the subjectKeyIdentifier was to indicate which keypair the client (pledge) had attempted to enroll. Upon successful enrollment, a new TLS connection is started (usually), which proves that the enrollment is success, and so no KeyIdentifier is needed. In the case of a failure, the existing TLS connection is maintained, so the server (Registrar) can associate the failure with the previous attempt to enroll. This change (removing the subjectKeyIdentifier) was made in -05, but the prose was not updated. The use of a subjectKeyIdentifier, which might no longer be a SHA-1 hash of a public key, is problematic, as the CSR does not include an appropriate KeyIdentifier, so the server would be left trying to calculate it, using the default (and now obsolete) SHA-1 mechanism. Including the KeyIdentifier has proved more trouble than benefit. Esko has complained that we have 14 open issues; that's probably negligence on my part about not closing them as we solved the issues. So we also closed all but three "auth48" tickets that had been opened. > Section 2.5.1 > The pledge is the device that is attempting to join. The pledge can > talk to the Join Proxy using link-local network connectivity. In most > cases, the pledge has no other connectivity until the pledge completes > the enrollment process and receives some kind of network credential. > I'd consider s/can talk to/is assumed to talk to/. okay. some have complained this isn't strong enough. Maybe MUST talk to? > Section 3 > In my previous comment, I said: > % The "proximity-registrar-cert" leaf is used in the pledge voucher- % > requests. This provides a method for the pledge to assert the % > registrar's proximity. > % > % "proximity" in what sense? How much verification/confidence needs to > be % done? (Also, I would have expected the assertion to go the other > way; % that the registrar asserts the pledge's proximity -- how does > the pledge % have a way to know that the registrar is nearby when the > proxy is % transparent?) > We talked about this some, but I think we're still making an unstated > assumption that there is a link-local or pre-ACP connection involved. > Making that an explicit assumption would be helpful. I have added the following text to make this assumption explicit: + + This network proximity results from the following properties in the + ACP context: the pledge is connected to the Join Proxy + () using a Link-Local IPv6 connection. + While the Join Proxy does not participate in any meaningful sense in + the cryptography of the TLS connection (such as via a Channel + Binding), the Registrar can observe that the connection is via the + private ACP (ULA) address of the join proxy, and could not come from + outside the ACP. The Pledge must therefore be at most one IPv6 + Link-Local hop away from an existing node on the ACP. + + + Other users of BRSKI will need to define other kinds of assertions if + the network proximity described above does not match their needs. + ==== > Also, we should probably give a reference for base64 (not necessarily > here), such as Section 4 of RFC 4648. And to the lead in, I've referenced RFC4648, which this is the first reference to base64.
This section provides voucher-request examples for illustration - purposes. The contents of the certificate have been elided + purposes. JSON encoding rules specify that any binary + content by base64 encoded (). + The contents of the certificate have been elided > Section 5.1 > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > REQUIRED. > How painful would it be to require 1.3 at this point? RFC 8446 has > been out for more than a year, and the TLS WG is leaning on me to > tighten up on this... Yes, but how many FIPS-140 validated TLS 1.3 implementations are there that are drop-in available to router platforms with 3-5 year R&D cycles? OpenSSL is FIPS for 1.0.1 and 1.0.2 which do not include TLS 1.3, for instance (which is 1.1.x). WolfSSL has FIPS-140 for TLS 1.3 (to read the press releases), and some entities could drop it in, but others might have license issues. How about if I change the text to say: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the Pledge side. TLS 1.3 (or newer) SHOULD be available on the Registrar server interface, and the Registrar client interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS 1.2 MAY be used. Getting TLS 1.3 on a web framework platform is not that hard if it does not need FIPS-140. Mandating that 1.3 be available reduces the domino effect that keeps systems from organically upgrading. doc> IDevID certificate is out-of-scope of this specification. Note that doc> the trust anchors in/excluded from the database will affect which doc> manufacturers' devices are acceptable to the registrar as pledges, and doc> can also be used to limit the set of MASAs that are trusted for doc> enrollment. > I can't tell if we want to bring the division into two distinct trust > anchor databases into this discussion as well. I think that there are a bunch of considerations which go rather far into how the domain owner wants to operate things. I have started a document: Operational Considerations for BRSKI Registrar but, it's just a shell so far. > Section 5.4 doc> Section 2.8. The mechanisms in [RFC6125] SHOULD be used doc> authentication of the MASA. Some vendors will establish explicit (or > nit: s/used/used for/ Also, we tend to require that people using 6125 > specify what name type in the cert to verify (e.g., DNS-ID) against > what expected name. It would be pretty easy to convince me that we > don't need to do that here, though. diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml index 8f82c58..4394881 100644 --- a/dtbootstrap-anima-keyinfra.xml +++ b/dtbootstrap-anima-keyinfra.xml @@ -1912,9 +1912,14 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]> connection and uses the MASA URL obtained as described in . The mechanisms in SHOULD be used authentication of the - MASA. Some vendors will establish explicit (or private) trust - anchors for validating their MASA; this will typically done as - part of a sales channel integration. + MASA using a DNS-ID that matches that which is found in the IDevID. + Registrars MAY include a mechanism to override the MASA URL on a + manufacturer-by-manufacturer basis, and within that override it is + appropriate to provide alternate anchors. + This will typically used by some vendors to establish explicit + (or private) trust + anchors for validating their MASA that is part of a sales channel + integration. > Section 5.4 > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > REQUIRED. > As above, how painful would requiring 1.3 be? Consistently with the text above: Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. TLS 1.3 (or newer) SHOULD be available. > Section 5.5 > prior-signed-voucher-request: The signed pledge voucher-request > SHOULD be included in the registrar voucher-request. The entire CMS > signed structure is to be included, base64 encoded for transport in the > JSON structure. > I think we need a ref for (which) base64. I looked through. RFC8366 does not reference RFC7951 (it should), which explains JSON serialized YANG. RFC7951 and RFC7950 specify original base64. {I am annoyed that we aren't using base64url in a Postel-rule compatibility mode everywhere...} Section 3.3 already referenced 7951, btw I have added the text to section 5: BRSKI uses existing CMS message formats for existing EST operations. BRSKI uses JSON [RFC8259] for all new operations defined here, and voucher formats. In all places where a binary value must be carried in a JSON string, the use of base64 format ([RFC4648] section 4) is to be used, as per [RFC7951] section 6.6. > Section 5.5.2 doc> The registrar's certificate chain is extracted from the signature doc> method. The entire registrar certificate chain was included in the CMS doc> structure, as specified in Section 5.5. This CA certificate will be doc> used to populate the "pinned-domain-cert" of the voucher being issued. > By saying "this CA certificate", are we excluding use cases where the > pinned-domain-cert is not the global root CA of the organization (or is > the implication just that you don't send the rest of the chain)? Yes. 1) There may not be a global root CA for the organization. It could be self-signed. 2) The registrar gets to decide which thing it wants pinned. 3) The pledge is expected to have enough certificate chaining to deal with either situation. (This has changed: at one point memcmp() was considered enough) 4) the EST /cacerts request lets the Pledge "upgrade" to an organizational anchor. > Section 5.5.6 doc> The MASA populates the audit-log with the nonce that was verified. doc> If a nonceless voucher is issued, then the audit-log is to be populated doc> with the JSON value "null". > The quotes around "null" are perhaps anti-helpful. _null_ is a JSON literal. Are you complaining that some people might write: nonce: "null" rather than nonce: null ? doc> The keys to this JSON hash are case-insensitive. Figure 15 shows an doc> example JSON. > This (case-insensitivity) seems to be a drastic divergence from the RFC > 8259 standard behavior and as such would require some justification. > nit: s/hash/object/ okay, changed this to lower case. > Section 7.3 doc> A registrar can choose to accept devices using less secure methods. doc> These methods are acceptable when low security models are needed, as doc> the security decisions are being made by the local administrator, but doc> they MUST NOT be the default behavior: > I'm having a hard time parsing "low security models"; the best I can > come up with is "threat models where low security is adequate". Does this work for you: 7.2. Pledge security reductions - The following are a list of alternatives behaviours that the pledge - can be programmed to implement. These behaviours are not mutually - exclusive, nor are they dependent upon other. Some of these methods - enable offline and emergency (touch based) deployment use cases. - Normative language is used as these behaviours are referenced in - later sections in a normative fashion. + The following is a list of alternative behaviours that the pledge can + be programmed to implement. These behaviours are not mutually + exclusive, nor are they dependent upon each other. Some of these + methods enable offline and emergency (touch based) deployment use + cases. Normative language is used as these behaviours are referenced + in later sections in a normative fashion. > Section 7.4.1 doc> and/or not requiring one to be present in the voucher-request. This doc> results in distribution of a voucher that never expires and in effect > "expires-on" is distinct from the nonce-ful freshness check, so I think > some additional wordsmithing is in order. A Pledge will not, in general, have a real time clock it can rely on. A nonced voucher is fresh, while a nonceless one is not. I have changed this to: This results in distribution of a voucher that may never expire and in doc> In the ACP, the Join Proxy is found to be proximal because doc> communication between the pledge and the join proxy is exclusively on > nit(?) My dictionary doesn't list anything for "proximal" that is a > good match for "with proximity"; might be worth double-checking. I find it: https://www.dictionary.com/browse/proximal?r=75&src=ref&ch=dic > Section 11.3 > We had some discussion around my previous comment: > % Additionally, in order to successfully use the resulting voucher the > % Rm would have to attack the pledge and return it to a bootstrapping % > enabled state. This would require wiping the pledge of current > % > % ... and I think there is a different attack if the Rm is in a > position % to delay or drop network traffic between the pledge and the > intended % registrar, to cause Rm's voucher to be delivered first even > though it is % generated after the intended registrar's authorization > process. The % intended registrar would need to require reports on > voucher processing % status (or investigate their absence) in order to > detect such a case. > but I can't remember if we decided that we didn't need to discuss the > risk in the document. I think that the explanation if pretty complete. > Appendix D.2 > An RFC Editor note about the RFC 8366 assignment of OID > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples > properly use that assigned OID now? We got a MASA URL Extension OID for: 1.3.6.1.5.5.7.1.32 the examples date from before that, and do not use it yet. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2vZV0ACgkQgItw+93Q 3WVPqAf/ZgVnMEdUsXEfbv2OXfkkOFb7iXG4JrgV3o0vgLBGltiYzKA4M1urDSPo cIKo1yB7lRjGAWXCsqykNx/hs0ChxoFBmhqsmp8XWmdpIFcnhlbw9V3cUdNf3KcE 0Ew0cGOEHndEkKAbrqZ8PnITUAPhU2qplz+PbNIA95rCGjffeikX2ChtvYFesp9k gha5hkBFWV9nz2RI+lGkJHsd5znaJC3E7JfEI/MFFtSQTHUeTu2H20thPPjSRSgE x/RvRnR9W6zzpPE+7AIMikLC5+voiqBJ679szojBe/woqfIMxIVvwbTVanOhkXT+ r7yp5TFuY3Me/brWMcxhhZwj+hB0yw== =WOCo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 23 02:14:28 2019 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 7FAD01200B4; Wed, 23 Oct 2019 02:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 i-QiabDmyUVL; Wed, 23 Oct 2019 02:14:24 -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 0E60D12007A; Wed, 23 Oct 2019 02:14:24 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 97365A7AF72C1405213D; Wed, 23 Oct 2019 10:14:21 +0100 (IST) Received: from fraeml717-chm.china.huawei.com (10.206.15.13) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 23 Oct 2019 10:14:21 +0100 Received: from fraeml719-chm.china.huawei.com (10.206.15.15) by fraeml717-chm.china.huawei.com (10.206.15.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 23 Oct 2019 11:14:20 +0200 Received: from fraeml719-chm.china.huawei.com ([10.206.15.15]) by fraeml719-chm.china.huawei.com ([10.206.15.15]) with mapi id 15.01.1713.004; Wed, 23 Oct 2019 11:14:20 +0200 From: Xun Xiao To: Sheng Jiang , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFwL9MpKw Date: Wed, 23 Oct 2019 09:14:20 +0000 Message-ID: <38ab284f860b4aa9b78a0f0549943c79@huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.99.168] Content-Type: multipart/alternative; boundary="_000_38ab284f860b4aa9b78a0f0549943c79huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 09:14:27 -0000 --_000_38ab284f860b4aa9b78a0f0549943c79huaweicom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi ANIMA chairs, We would like to apply a slot for our draft. Name of time slot: Either Tue. Afternoon Session II or Wed. Afternoon Sessi= on III is fine Name of draft(s): draft-liu-anima-grasp-distribution-11 Time requested: 5-10 mins Presenter name(s):Artur Hecker Best Regards, Xun Xiao (=1B$B>S?W=1B(B) Advanced Wireless Technology Lab Munich Research Center Huawei Technologies Co.,Ltd. From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Tuesday, 8 October 2019 05:56 To: anima@ietf.org Cc: anima-chairs@ietf.org Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore Hi, all anima, We have been allocated two sessions of 1.5 + 1 hour for the ANIMA WG meetin= g for IETF-106 (Singapore). We are now starting to collect agenda items for= the sessions. Please send your request for agenda by October 31th, Thursda= y, to anima-chairs@ietf.org> and both chairs' email. Please = note that email to a single chair may cause single-point failure. 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. As you may observed, we now have the new WG charter in the place, but still= , we have the priority to complete the current WG documents over to adopt a= ny new work. Please send us (anima-chairs at ietf.org) requests for time slot by October 31th, Thursday and inc= lude: Name of time slot: Name of draft(s): Time requested: Presenter name(s): More details about the IETF 106, Montreal can be found at: https://www.ietf.org/how/meetings/106/ 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, Sheng --_000_38ab284f860b4aa9b78a0f0549943c79huaweicom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable 
Hi ANIMA chairs,
 
We would like to apply a slot for our draft.
 
Name of time slot: Either Tue. Afternoon Session II=
 or Wed. Afternoon Session III is fine
Name of draft(s): draft-liu-anima-grasp-distributio=
n-11
Time requested: 5-10 mins
Presenter name(s):Artur Hecker

=
 




Best Regards,


 


Xun Xiao (=1B$B>S?W=1B(B)


Advanced Wireless Technology Lab


Munich Research Center


Huawei Technologies Co.,Ltd.=





=
 






From: =
Anima [mailto:anima-bounces@ietf.org]
On Behalf Of Sheng Jiang

Sent: Tuesday, 8 October 2019 05:56

To: anima@ietf.org

Cc: anima-chairs@ietf.org

Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore






 =



Hi, all anima,


 


We have been allocated two sessions of 1.5 + 1 =
hour for the ANIMA WG meeting for IETF-106 (Singapore). We are now starting=
 to collect agenda items for the sessions. Please send your request for age=
nda by October 31th, Thursday, to anima-chairs@ietf.org<mailto:anima-chairs=
@ietf.org> and both chairs' email. Please note that email to a singl=
e chair may cause single-point failure.


 


As normal, the priority among these non-charter wor=
k items would be: these that have active discussion in mail list, then thes=
e have submitted drafts, and topics without drafts.


 


As you may observed, we now have the new WG charter=
 in the place, but still, we have the priority to complete the current WG d=
ocuments over to adopt any new work.


 


Please send us (anima-chairs at ietf.org<=
;https://ietf.org/><http://ietf.org%3Chttps/ietf.org/)>) reque=
sts for time slot by October 31th, Thursday and include:<=
/pre>

 


Name of time slot:


Name of draft(s):


Time requested:


Presenter name(s):


 


More details about the IETF 106, Montreal can be fo=
und at:


 


=
https://www.ietf.org/how/meetings/106/


 


Again, presenters and draft authors please invoke a=
ctive discussions in the ANIMA list. Mail list is a very good place to disc=
uss and reach consensus on technical issues.


 


Best regards,


 


Sheng


 
--_000_38ab284f860b4aa9b78a0f0549943c79huaweicom_-- From nobody Wed Oct 23 05:26:26 2019 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 763801200D8 for ; Wed, 23 Oct 2019 05:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 YyTMsV8k2kks for ; Wed, 23 Oct 2019 05:26:21 -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 870601208BE for ; Wed, 23 Oct 2019 05:26:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 764FD3897A; Wed, 23 Oct 2019 08:23:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C52076D; Wed, 23 Oct 2019 08:26:18 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: anima@ietf.org In-Reply-To: <4C61CD6A-EDFB-4521-8811-858085E84BC4@tzi.org> References: <15459.1571755692@localhost> <4C61CD6A-EDFB-4521-8811-858085E84BC4@tzi.org> 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] which base64 for RFC8366... original! X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 12:26:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: >> So, why doesn't RFC8366 reference: >> https://datatracker.ietf.org/doc/rfc7951/ > No idea. > But then, RFC 8366 says > The voucher artifact is a JSON [RFC8259] document that conforms with > a data model described by YANG [RFC7950], is encoded using the rules > defined in [RFC8259], and is signed using (by default) a CMS > structure [RFC5652]. > which is pretty much devoid of meaning. Well, it does tell you that the YANG to be serialized. It whould have reference 7951 though. >> I wonder if this is worth an errata clarifying this for RFC8366? > Yes, but maybe the WG should decide first what was intended=E2=80=A6 I'm an author.... we intended for binary stuff to get base64-encoded, but I don't think any of us quite understood enough about the different flavours. I would have preferred that RFC7951 had maybe said that it shall be base64URL, but that base64 shall be tolerated. It's irksome because JWS specifies base64URL, and the JSON spec is silent. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2wRuoACgkQgItw+93Q 3WW+cggAmMotU1/WBcvJu0/qjOdsSoST4V3FP1aSFgR+qwFaaMAX3BcmnSqLXlwr kDhiDrxmuOsw7xv7qo44CTiOvf9muVONgTGBQtVPCLrwEuJezqgGWoNjn4Y/Mv9o je9vFGQSrbxj2DufVYgtBYzhDwI/88xOdH59MheELqtqZ/3C8HRwVrf9L6YpcGUI HYfewZQKRWw34WQOkhvSC8V2r4x8YtTCCAByUyGsnLpFDCYSnvBz7UKcGre119WX YmfAV6wbvlyHlsAR/tn6npbli/rv3UUSiZq5aQ8iU5MtbeVgyotuysJpSIv199z8 cAObDVOOgxx+fa+PJSaImU+rPz3SOQ== =zC3L -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 23 21:14:52 2019 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 AE2C4120114 for ; Wed, 23 Oct 2019 21:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 MllF6KC3GvIm for ; Wed, 23 Oct 2019 21:14:50 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 EB00812006E for ; Wed, 23 Oct 2019 21:14:49 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id f14so13393287pgi.9 for ; Wed, 23 Oct 2019 21:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cHmY2/gr90C53Q/ecsjpatpTE0xGzjX9epfWD2gk+hU=; b=hY9u7Kp2hI+uqzEw3ioNm1OC0Y75c6atPHYT4KEhMEQZO03gNl6pGySzTbywsx6GCC bsSkMfzlwKYqDjQIwC3oKVqPsSXZz3q+O0fRc2fEI1DDUXW7r2QWWu8YOioVq9+NMKxt /d40Jdk1cQlkXXKg9I2F399qX/RRmzk1pT8yx2z+dG7LnTeqZPKO9QmLe32uyeM8qToK W0K4HleIxWaTLDt3XFuAg5x7jrAIRZCZpPJLNaeWlIecboE5gnCWN4UMzvzxgn+sIIDd BOuKKMyEfEmJkijYQ7uPKZjHJEcYasHcZEOw0suvMQygKhgyFS1CowF5gsAypa8CVH4g ClCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cHmY2/gr90C53Q/ecsjpatpTE0xGzjX9epfWD2gk+hU=; b=AvmD1u2gvB9QlSNkfniCJ+axpCEbEqr4p6RWvo53ECZ/ml9Pqu7Wj1y+rNIXAPU9KE e1MjaBO0TnlvbBZTuVXOfdybLsSNieJ55Vw1wwRuFhRbj2L08hnZ4hgRzcUDN6Y+Ass5 U8Z5ClH8+ptFHwim5Bm4GMd3lOTYtq0/OUxKEQu9Z2+jgmg1WJryxX8hOQ1omGFDjeVh nFvcgOCZSqju5Fl0FhvUq9g5zWZ1u62OBLaXtFz20o9m0CMTVkQlfRQq81O+sNRngWCx JXajG2vQCtFtN1wMDIRKJhf6YjBgkuZ2OhM2fIRrl79OkASk29tQ30FeR7lRmsUSF4v5 l/zA== X-Gm-Message-State: APjAAAX8XgX5nfSsxUzRwBY244cUkchTrgab+9s58zEOczIN3lQuaZ6y VlFFMYIGq+YBU637yzkdiV4RIAnt X-Google-Smtp-Source: APXvYqxM15v6QnljGtXpui0sxrKqmLND/fzIT/hKuT6V/sJ8Lfguv0ndSetVTK6YJaYe+gKOg3nHqw== X-Received: by 2002:a63:7c4f:: with SMTP id l15mr14036416pgn.408.1571890488986; Wed, 23 Oct 2019 21:14:48 -0700 (PDT) Received: from [192.168.178.30] (98.145.69.111.dynamic.snap.net.nz. [111.69.145.98]) by smtp.gmail.com with ESMTPSA id l72sm893906pjb.7.2019.10.23.21.14.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Oct 2019 21:14:48 -0700 (PDT) References: <157188974981.22007.9882764724822906988@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <157188974981.22007.9882764724822906988@ietfa.amsl.com> Message-ID: <94272857-9c5a-ef7e-1533-d789113b15e6@gmail.com> Date: Thu, 24 Oct 2019 17:14:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157188974981.22007.9882764724822906988@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-quads-grasp-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 04:14:52 -0000 Hi, I left a challenge for myself in QUADS which I have now tackled, in the form of QUick And Dirty Security Key Infrastructure (QUADSKI), described in this update. It's based 100% on using GRASP to distribute its own AES/CBC keys, secured by RSA. Despite the name, it isn't intended to compete with BRSKI; it just makes QUADS security a little better. I need to polish and document the demo implementation before I push it to GitHub, but it does work. If anybody wants to play, I will be in Singapore. I'd like to test it on more of a network that I have at home. All you need is an up to date Python 3 environment and some courage. Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-quads-grasp-01.txt Date: Wed, 23 Oct 2019 21:02:29 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Quick and Dirty Security for GRASP Author : Brian Carpenter Filename : draft-carpenter-anima-quads-grasp-01.txt Pages : 8 Date : 2019-10-23 Abstract: A secure substrate is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Security method using symmetric cryptography and preconfigured keys or passwords. It also describes a simplistic QUADS Key Infrastructure based on asymmetric cryptography used over insecure instances of GRASP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-quads-grasp-01 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-quads-grasp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-quads-grasp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Oct 23 22:37:00 2019 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 9F52D12022C; Wed, 23 Oct 2019 22:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 bOjy2bMHpDOm; Wed, 23 Oct 2019 22:36:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1F03012020A; Wed, 23 Oct 2019 22:36:52 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9O5aal4029367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 01:36:39 -0400 Date: Wed, 23 Oct 2019 22:36:36 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, anima@ietf.org Message-ID: <20191024053636.GG69013@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <25780.1571775837@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25780.1571775837@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [COMMENTS] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 05:36:58 -0000 On Tue, Oct 22, 2019 at 04:23:57PM -0400, Michael Richardson wrote: > > Hi, this got quite long. > I've split this up into nits and substantive comments. > This email is about the substantive comments. > Please see a diff at: https://tinyurl.com/y5l4xz3z Thanks; I'll put some editorial nits at the end of this message. > Benjamin Kaduk via Datatracker wrote: > > Thanks for the time and attention to detail put into addressing my > > previous Discuss and Comment points. I have one new Discuss-level > > point and one that I think may have been missed (probably because I > > inadvertently numbered two points with the same number). > > > (16) The audit log response (Section 5.8.1) describes the nonce as a > > JSON string, but the RFC 8366 nonce is a binary value. I think we need > > to describe some mapping procedure (such as always base64-encoding as > > is done for domainID, even if the original nonce is itself > > base64-encoded random data) in order to be fully functional. > > In the JSON mapping of the YANG, binary values are always base64 encoded, as > JSON does not support binary values. I apparently forgot that we were going through a YANG->JSON encoding when I wrote the above, sorry for that. But thank you for the extra reminders about base64-encoding that are in the latest copy. > This would be an issue in the constrained-voucher CBOR mapping through. > > > % (1) The text of the document suffers from lack of clarity throughout > > about % whether the nonce-ful operation is mandatory or not, with > > several % figures and discussions making declarative statements about > > nonce usage % and others saying that nonce usage is optional. (See > > COMMENT.) > > > > > [keep in mind when reading] > > > % (5.1) the new /enrollstatus EST endpoint seems under-specified. > > > Shame on me, I reused (5) for two points and have renumbered this to > > (5.1) so we don't miss it again. We don't anywhere give a formal > > description of the contents of the POST body; there's just an example > > JSON object. > > Agreed, and there is a comment about the subjectKeyInfo. > > I had opened issue: https://github.com/anima-wg/anima-bootstrap/issues/141 > last week when I started writing this. > > We have resolved this ticket as follows: > > The original purpose of the subjectKeyIdentifier was to indicate which > keypair the client (pledge) had attempted to enroll. Upon successful > enrollment, a new TLS connection is started (usually), which proves that the > enrollment is success, and so no KeyIdentifier is needed. > In the case of a failure, the existing TLS connection is maintained, so > the server (Registrar) can associate the failure with the previous attempt > to enroll. > This change (removing the subjectKeyIdentifier) was made in -05, but the > prose was not updated. The use of a subjectKeyIdentifier, which might no > longer be a SHA-1 hash of a public key, is problematic, as the CSR does > not include an appropriate KeyIdentifier, so the server would be left > trying to calculate it, using the default (and now obsolete) SHA-1 > mechanism. Including the KeyIdentifier has proved more trouble than > benefit. The removal of SKI seems okay, but I'm still looking for something like "the body of the POST is a JSON object with the following [whoops, I forget the right terminology for name/value pairs]" > Esko has complained that we have 14 open issues; that's probably negligence > on my part about not closing them as we solved the issues. > So we also closed all but three "auth48" tickets that had been opened. > > > Section 2.5.1 > > > The pledge is the device that is attempting to join. The pledge can > > talk to the Join Proxy using link-local network connectivity. In most > > cases, the pledge has no other connectivity until the pledge completes > > the enrollment process and receives some kind of network credential. > > > I'd consider s/can talk to/is assumed to talk to/. > > okay. some have complained this isn't strong enough. > Maybe MUST talk to? I don't have a strong opinion on this, but it feels like something that will probably be different for ACP vs. other deployments -- MUST feels right for ACP but is probably not universal. > > Section 3 > > > In my previous comment, I said: > > > % The "proximity-registrar-cert" leaf is used in the pledge voucher- % > > requests. This provides a method for the pledge to assert the % > > registrar's proximity. > > % > > % "proximity" in what sense? How much verification/confidence needs to > > be % done? (Also, I would have expected the assertion to go the other > > way; % that the registrar asserts the pledge's proximity -- how does > > the pledge % have a way to know that the registrar is nearby when the > > proxy is % transparent?) > > > We talked about this some, but I think we're still making an unstated > > assumption that there is a link-local or pre-ACP connection involved. > > Making that an explicit assumption would be helpful. > > I have added the following text to make this assumption explicit: > > + > + This network proximity results from the following properties in the > + ACP context: the pledge is connected to the Join Proxy > + () using a Link-Local IPv6 connection. > + While the Join Proxy does not participate in any meaningful sense in > + the cryptography of the TLS connection (such as via a Channel > + Binding), the Registrar can observe that the connection is via the > + private ACP (ULA) address of the join proxy, and could not come from > + outside the ACP. The Pledge must therefore be at most one IPv6 > + Link-Local hop away from an existing node on the ACP. > + > + > + Other users of BRSKI will need to define other kinds of assertions if > + the network proximity described above does not match their needs. > + Thank you! > ==== > > > Also, we should probably give a reference for base64 (not necessarily > > here), such as Section 4 of RFC 4648. > > And to the lead in, I've referenced RFC4648, which this is the first > reference to base64. > >
> This section provides voucher-request examples for illustration > - purposes. The contents of the certificate have been elided > + purposes. JSON encoding rules specify that any binary > + content by base64 encoded (). > + The contents of the certificate have been elided > > > > Section 5.1 > > > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > > REQUIRED. > > > How painful would it be to require 1.3 at this point? RFC 8446 has > > been out for more than a year, and the TLS WG is leaning on me to > > tighten up on this... > > Yes, but how many FIPS-140 validated TLS 1.3 implementations are there that > are drop-in available to router platforms with 3-5 year R&D cycles? > OpenSSL is FIPS for 1.0.1 and 1.0.2 which do not include TLS 1.3, for > instance (which is 1.1.x). I take it that FIPS-140 validation is required for those $100k BFRs, then? > WolfSSL has FIPS-140 for TLS 1.3 (to read the press releases), and some > entities could drop it in, but others might have license issues. > > How about if I change the text to say: > > Use of TLS 1.3 (or newer) is encouraged. > TLS 1.2 or newer is REQUIRED on the Pledge side. > TLS 1.3 (or newer) SHOULD be available on the Registrar server interface, > and the Registrar client interface, but TLS 1.2 MAY be used. > TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS > 1.2 MAY be used. That's an okay compromise on the 1.3-encouragement front, but I don't think that everyone will read "Foo server interface" and "Foo client interface" in the same way. > Getting TLS 1.3 on a web framework platform is not that hard if it does not > need FIPS-140. Mandating that 1.3 be available reduces the domino effect > that keeps systems from organically upgrading. > > doc> IDevID certificate is out-of-scope of this specification. Note that > doc> the trust anchors in/excluded from the database will affect which > doc> manufacturers' devices are acceptable to the registrar as pledges, and > doc> can also be used to limit the set of MASAs that are trusted for > doc> enrollment. > > > I can't tell if we want to bring the division into two distinct trust > > anchor databases into this discussion as well. > > I think that there are a bunch of considerations which go rather far into how > the domain owner wants to operate things. I have started a document: > Operational Considerations for BRSKI Registrar > > but, it's just a shell so far. Okay. > > Section 5.4 > > doc> Section 2.8. The mechanisms in [RFC6125] SHOULD be used > doc> authentication of the MASA. Some vendors will establish explicit (or > > > nit: s/used/used for/ Also, we tend to require that people using 6125 > > specify what name type in the cert to verify (e.g., DNS-ID) against > > what expected name. It would be pretty easy to convince me that we > > don't need to do that here, though. > > diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml > index 8f82c58..4394881 100644 > --- a/dtbootstrap-anima-keyinfra.xml > +++ b/dtbootstrap-anima-keyinfra.xml > @@ -1912,9 +1912,14 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]> > connection and uses the MASA URL obtained as described in > . The mechanisms in > SHOULD be used authentication of the > - MASA. Some vendors will establish explicit (or private) trust > - anchors for validating their MASA; this will typically done as > - part of a sales channel integration. > + MASA using a DNS-ID that matches that which is found in the IDevID. > + Registrars MAY include a mechanism to override the MASA URL on a > + manufacturer-by-manufacturer basis, and within that override it is > + appropriate to provide alternate anchors. > + This will typically used by some vendors to establish explicit > + (or private) trust > + anchors for validating their MASA that is part of a sales channel > + integration. > > > > Section 5.4 > > > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > > REQUIRED. > > > As above, how painful would requiring 1.3 be? > > Consistently with the text above: > > Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > REQUIRED. TLS 1.3 (or newer) SHOULD be available. > > > > Section 5.5 > > > prior-signed-voucher-request: The signed pledge voucher-request > > SHOULD be included in the registrar voucher-request. The entire CMS > > signed structure is to be included, base64 encoded for transport in the > > JSON structure. > > > I think we need a ref for (which) base64. > > I looked through. > RFC8366 does not reference RFC7951 (it should), which explains JSON > serialized YANG. RFC7951 and RFC7950 specify original base64. > {I am annoyed that we aren't using base64url in a Postel-rule compatibility > mode everywhere...} > > Section 3.3 already referenced 7951, btw > > I have added the text to section 5: > BRSKI uses existing CMS message formats for existing EST operations. > BRSKI uses JSON [RFC8259] for all new operations defined here, and > voucher formats. In all places where a binary value must be carried > in a JSON string, the use of base64 format ([RFC4648] section 4) is > to be used, as per [RFC7951] section 6.6. > > > Section 5.5.2 > > doc> The registrar's certificate chain is extracted from the signature > doc> method. The entire registrar certificate chain was included in the CMS > doc> structure, as specified in Section 5.5. This CA certificate will be > doc> used to populate the "pinned-domain-cert" of the voucher being issued. > > > By saying "this CA certificate", are we excluding use cases where the > > pinned-domain-cert is not the global root CA of the organization (or is > > the implication just that you don't send the rest of the chain)? > > Yes. > 1) There may not be a global root CA for the organization. It could be self-signed. > 2) The registrar gets to decide which thing it wants pinned. > 3) The pledge is expected to have enough certificate chaining to deal with > either situation. (This has changed: at one point memcmp() was considered enough) > 4) the EST /cacerts request lets the Pledge "upgrade" to an organizational anchor. > > > Section 5.5.6 > > doc> The MASA populates the audit-log with the nonce that was verified. > doc> If a nonceless voucher is issued, then the audit-log is to be populated > doc> with the JSON value "null". > > > The quotes around "null" are perhaps anti-helpful. > > _null_ is a JSON literal. Are you complaining that some people might write: > nonce: "null" > rather than > nonce: null > ? I am indeed. Perhaps "the JSON primitive null", but I'm starting to think I should stop trying to wordsmith this... > doc> The keys to this JSON hash are case-insensitive. Figure 15 shows an > doc> example JSON. > > > This (case-insensitivity) seems to be a drastic divergence from the RFC > > 8259 standard behavior and as such would require some justification. > > nit: s/hash/object/ > > okay, changed this to lower case. > > > Section 7.3 > > doc> A registrar can choose to accept devices using less secure methods. > doc> These methods are acceptable when low security models are needed, as > doc> the security decisions are being made by the local administrator, but > doc> they MUST NOT be the default behavior: > > > I'm having a hard time parsing "low security models"; the best I can > > come up with is "threat models where low security is adequate". > > Does this work for you: > > 7.2. Pledge security reductions > > - The following are a list of alternatives behaviours that the pledge > - can be programmed to implement. These behaviours are not mutually > - exclusive, nor are they dependent upon other. Some of these methods > - enable offline and emergency (touch based) deployment use cases. > - Normative language is used as these behaviours are referenced in > - later sections in a normative fashion. > + The following is a list of alternative behaviours that the pledge can > + be programmed to implement. These behaviours are not mutually > + exclusive, nor are they dependent upon each other. Some of these > + methods enable offline and emergency (touch based) deployment use > + cases. Normative language is used as these behaviours are referenced > + in later sections in a normative fashion. (That diff is fine with me, though it's the wrong one. What's in the linked diff for Section 7.3 is also fine.) > > > Section 7.4.1 > > doc> and/or not requiring one to be present in the voucher-request. This > doc> results in distribution of a voucher that never expires and in effect > > > "expires-on" is distinct from the nonce-ful freshness check, so I think > > some additional wordsmithing is in order. > > A Pledge will not, in general, have a real time clock it can rely on. > A nonced voucher is fresh, while a nonceless one is not. > I have changed this to: > > This > results in distribution of a voucher that may never expire and in Thanks. > doc> In the ACP, the Join Proxy is found to be proximal because > doc> communication between the pledge and the join proxy is exclusively on > > > nit(?) My dictionary doesn't list anything for "proximal" that is a > > good match for "with proximity"; might be worth double-checking. > > I find it: > https://www.dictionary.com/browse/proximal?r=75&src=ref&ch=dic I mean, my dictionary finds it *as a word*, just not with a definition that looks great for how you're using it here. > > Section 11.3 > > > We had some discussion around my previous comment: > > > % Additionally, in order to successfully use the resulting voucher the > > % Rm would have to attack the pledge and return it to a bootstrapping % > > enabled state. This would require wiping the pledge of current > > % > > % ... and I think there is a different attack if the Rm is in a > > position % to delay or drop network traffic between the pledge and the > > intended % registrar, to cause Rm's voucher to be delivered first even > > though it is % generated after the intended registrar's authorization > > process. The % intended registrar would need to require reports on > > voucher processing % status (or investigate their absence) in order to > > detect such a case. > > > but I can't remember if we decided that we didn't need to discuss the > > risk in the document. > > I think that the explanation if pretty complete. > > > Appendix D.2 > > > An RFC Editor note about the RFC 8366 assignment of OID > > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples > > properly use that assigned OID now? > > We got a MASA URL Extension OID for: > 1.3.6.1.5.5.7.1.32 > > the examples date from before that, and do not use it yet. I will update my Discuss position to help us remember. editorial nits on the linked diff: Section 2.5.3 talks about the set of MASA that are trusted being limited by the MASA TA database, but in the paragraph about the BRSKI-EST client TA database. s/described Appendix B/described in Appendix B/ (sorry, section number not visible from diff; maybe 40% through the diff) Section 5.4 is missing an "for" in "SHOULD be used for authentication of the MASA". s/accesptable/acceptable/ Figure 17 is introduced as an "abstract example", though it seems more of a concrete one after this diff. -Ben From nobody Fri Oct 25 14:20:31 2019 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 5F5761209B8; Fri, 25 Oct 2019 14:12:17 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793738.2724.16832709253179852821.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:17 -0700 Archived-At: Subject: [Anima] anima - Requested sessions have been scheduled for IETF 106 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:14:09 -0000 Dear Toerless Eckert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. anima Session 1 (1:00 requested) Tuesday, 19 November 2019, Afternoon Session III 1710-1840 Room Name: Sophia size: 200 --------------------------------------------- anima Session 2 (1:30 requested) Wednesday, 20 November 2019, Afternoon Session II 1520-1650 Room Name: Hullet size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/anima.ics Request Information: --------------------------------------------------------- Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Toerless Eckert Number of Sessions: 2 Length of Session(s): 1 Hour, 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: Chair Conflict: bier pim mboned 6man 6lo 6tisch ace Technology Overlap: emu netconf homenet roll Key Participant Conflict: nmrg panrg dinrg opsarea intarea saag cfrg detnet People who must be present: Toerless T. Eckert Sheng Jiang Ignas Bagdonas Resources Requested: Special Requests: Please avoid meeting on friday due to travel constraints of chair. It would be nice to have the 1.5 hour meeting first. --------------------------------------------------------- From nobody Mon Oct 28 14:50:26 2019 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 974E9120098; Mon, 28 Oct 2019 14:50:16 -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_HELO_NONE=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 7R4hhJXdvyrj; Mon, 28 Oct 2019 14:50: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 6750B120096; Mon, 28 Oct 2019 14:50:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 61DAF3897A; Mon, 28 Oct 2019 17:47:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 799CC3BF0; Mon, 28 Oct 2019 17:50:10 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, The IESG , tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20191018012352.GB43312@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 21:50:17 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: > I also have some more comments that didn't make it into my ballot position; > please consider them as well. I will put them in the datatracker for > posterity, but will have it not generate an additional mail since the > mostly-duplicate contents would be confusing. > Section 2 > Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of > bidirectional? I guess maybe unidirectional towards the Pledge makes more sense. (Some would argue that the Pledge contains trust anchors pointing at the Vendor) doc> 3. Request to join the discovered registrar. A unique nonce is doc> included ensuring that any responses can be associated with this doc> particular bootstrapping attempt. > This still seems to assume nonce-ful operation, which IIUC remains > required for pledge voucher-requests; only registrar-voucher-requests > have the option of being nonceless. So, this seems okay as-is, right? Correct. doc> 4. Imprint on the registrar. This requires verification of the doc> manufacturer service provided voucher. A voucher contains > nit: hyphenate "manufacturer-service-provided" ok. > Section 2.3.1 doc> The serialNumber fields is defined in [RFC5280], and is a SHOULD doc> field in [IDevID]. IDevID certificates for use with this protocol doc> MUST include the "serialNumber" attribute with the device's unique doc> serial number (from [IDevID] section 7.2.8, and [RFC5280] section doc> 4.1.2.4's list of standard attributes). > This is 4.1.2.2 (or just 4.1.2) from RFC 5280. Thank you. > Section 2.4 doc> I note that both Figure 2 and Figure 4 have a step labeled "Identity", doc> but the description accompanying Figure 2 describes the step as doc> "Identify itself"; perhaps the 'f' form is more appropriate doc> everywhere? okay. > Section 2.8 doc> Note that the registrar can only select the configured MASA URL based doc> on the trust anchor -- so manufacturers can only leverage this doc> approach if they ensure a single MASA URL works for all pledge's doc> associated with each trust anchor. > nit: s/pledge's/pledges/ ok. > Section 3 doc> Voucher-requests are how vouchers are requested. The semantics of doc> the vouchers are described below, in the YANG model. > nit: semantics of vouchers, or voucher requests? voucher-requests, fixed. > Section 3.3 doc> Figure 6: JSON representation of example Voucher-Request > I suggest adding "(unsigned)" or "prior to CMS wrapping". I've added: These examples show the JSON prior to CMS wrapping. to the intro. > Section 3.4 doc> refine "voucher/assertion" { doc> mandatory false; doc> description "Any assertion included in voucher doc> requests SHOULD be ignored by the MASA."; > If this is true, why do we propagate the assertion from pledge > voucher-request to registrar voucher-request? Clarified to say: description "Any assertion included in registrar voucher requests SHOULD be ignored by the MASA."; The assertion in the prior-signed-voucher-request (or Pledge Voucher-Request) may well be examined by the MASA. > Section 4.1 doc> Each possible proxy offer SHOULD be attempted up to the point where a doc> voucher is received: while there are many ways in which the attempt doc> may fail, it does not succeed until the voucher has been validated. > nit: I suggest "valid voucher is received". okay. > Section 5 doc> o The pledge requests and validates a voucher using the new REST doc> calls described below. > nit: I think the validation is local and does not use the REST call. changed to: The pledge requests a voucher using the new REST calls described below. This voucher is then validated. doc> o The registrar forwards the voucher to the pledge when requested. > I suggest "validates and forwards" to cover the case where the registrar > applies policy. the whole text is: The registrar requests and validates the voucher from the MASA. The registrar forwards the voucher to the pledge when requested. so validates is already in the previous point, I think. > Section 5.2 doc> nonce: The pledge voucher-request MUST contain a cryptographically doc> strong random or pseudo-random number nonce. (see [RFC4086]) Doing doc> so ensures Section 2.6.1 functionality. The nonce MUST NOT be > This section reference reads kind of strangely. (Also, full stop after > parenthetical, not before.) reworked some text. doc> proximity-registrar-cert: In a pledge voucher-request this is the doc> first certificate in the TLS server 'certificate_list' sequence doc> (see [RFC5246]) presented by the registrar to the pledge. That doc> is, it is the end-entity certificate. This MUST be populated in a doc> pledge voucher-request if the "proximity" assertion is populated. > nit: there is no "proximity" field to be populated; it's the "assertion" > field that's populated with the value "proximity". we have reworked the text, including the assertion and text. > Section 5.5 doc> serial-number: The serial number of the pledge the registrar would doc> like a voucher for. The registrar determines this value by doc> parsing the authenticated pledge IDevID certificate. See doc> Section 2.3. The registrar MUST verify that the serial number doc> field it parsed matches the serial number field the pledge doc> provided in its voucher-request. This provides a sanity check doc> useful for detecting error conditions and logging. The registrar doc> MUST NOT simply copy the serial number field from a pledge voucher doc> request as that field is claimed but not certified. > (Just to be clear, the serial-number field is optional in the pledge's > voucher-request.) We have a discussion last week about this. We are making it mandatory; it is to be used as check against what is in the IDevID. We had made it optional to avoid repeating and dealing with what if it not equal, but realized that we wanted it as a safety check. > Section 5.6.2 doc> intervals according to the backoff timer described earlier. Attempts doc> SHOULD be repeated as failure may be the result of a temporary doc> inconsistently (an inconsistently rolled registrar key, or some other doc> mis-configuration). The inconsistently could also be the result an doc> active MITM attack on the EST connection. > nit: only one of these "inconsistently"s is correct; the others should > be "inconsistency". okay > Section 5.8 doc> although it results in additional network traffic. The relying MASA doc> implementation MAY leverage internal state to associate this request doc> with the original, and by now already validated, voucher-request so doc> as to avoid an extra crypto validation. > It seems that doing so would turn the voucher-request into a bearer > token for retrieving audit-log information (if the MASA accepts > unauthenticated clients). That's what's intended. > Section 5.8.2 doc> If the "pinned-domain-cert" certificate includes the doc> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be doc> used as the domainID. If not, then it is the SPKI Fingerprint as doc> described in [RFC7469] section 2.4 is to be used. This value needs doc> to be calculated by both MASA (to populate the audit-log), and by the doc> Registrar (to recognize itself). > nit: maybe "to recognize itself in the audit log"? okay. > Section 5.9 doc> The pledge SHOULD follow the BRSKI operations with EST enrollment doc> operations including "CA Certificates Request", "CSR Attributes" and doc> "Client Certificate Request" or "Server-Side Key Generation", etc. doc> This is a relatively seamless integration since BRSKI REST calls > (I think we decided to not call this REST.) It was "RESTful" that was disliked, and we reference "REST", and I've changed these to API calls. > Section 7.3 doc> 4. A registrar MAY ignore unrecognized nonceless log entries. This doc> could occur when used equipment is purchased with a valid history doc> being deployed in air gap networks that required permanent doc> vouchers. > "nonceless" and "permanent" are related but subtly different concepts, > given the potential for an expiration date in a nonceless voucher. s/permanent/offline/ > Section 7.4.3 doc> As a third option, the manufacturer's trust anchors could be entirely doc> overwitten with local trust anchors. A factory default would never doc> restore those anchors. This option comes with a lot of power, but doc> also a lot of responsability: if the new anchors are lost the doc> manufacturer may be unable to help. > nit: perhaps we refer to the private key portions of the anchors. agreed, changed. > Section 11 > I am somewhat embarassed that I did not previously note that the > mechanism used to generate the domainID needs to be > second-preimage-resistant or an attacker can claim to be a registrar for > a domain that already exists. Right now, that's in: 5.8.2. Calculation of domainID The domainID is a binary value (a BIT STRING) that uniquely identifies a Registrar by the "pinned-domain-cert" If the "pinned-domain-cert" certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs to be calculated by both MASA (to populate the audit-log), and by the Registrar (to recognize itself). We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to replace it appropriately. > Section 11.2 doc> Although the nonce used by the Pledge in the voucher-request does not doc> require a strong cryptographic randomness, the use of TLS in all of doc> the protocols in this document does. > We discuss the need for strong randomness in the nonce in Section 11.3, > so it's not clear this is actually true. We don't think that the voucher nonce has to be of the same quality as something that goes into a KDF. It is at the level of TCP Sequeunce number, not seed for generating a private key... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl23YpIACgkQgItw+93Q 3WW3rgf/Sm/xNQfxTTVHhcTKzx9Zd5xzgEmV/C6E9HQps9KO/6piU8h0zVwvnjIJ SMELxhKmNFfl3OVrtwOTwsZywfGnI7TnB7XIEVrwjaDsrFX2Mn40sDLnof3fRO6c QfMuwkaj9pYac1WvgS+qQI+XuZcqst2VxJ2EkoMrZ+Xdl7/7sB6D3Y5gj+7Jf5qf KZTUjALt/0vcAhkeyf9Prs8ZDTOdA0u+Xe6Bw7pXbf47ocqI2L6G/yDu0QNsRK0m 6VO3ZE95L86Ek7tLpcew2YfJD3uMBS05AHL6SwiSzs/IraCcXvdZkXbeU0Elq0ug exgpfNQo4KBzyjo2im7cNBPxDk9oOg== =i9dH -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 28 14:54:37 2019 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 18EB1120096; Mon, 28 Oct 2019 14:54:36 -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_HELO_NONE=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 ERnhetZdMizU; Mon, 28 Oct 2019 14:54:34 -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 DFD1D12008A; Mon, 28 Oct 2019 14:54:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A650B3897A; Mon, 28 Oct 2019 17:51:50 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BDC8A3BF0; Mon, 28 Oct 2019 17:54:32 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20191018035715.GD43312@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> <20412.1568670397@localhost> <20191018035715.GD43312@kduck.mit.edu> 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 21:54:36 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: >> >> But, that's why we have SHOULD, and the SHOULD (vs MUST) part was >> really to >> allow for some fancy HTTP/3 we know nothing about :-) >> >> > :) >> >> > Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP >> > persistent connections", though? >> >> I am using the latter now. > Please double-check; I think I saw one in the -28 (but didn't make a > note of where). I found a second instance of 1.1, and removed it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl23Y5gACgkQgItw+93Q 3WVhpAgAjaKNJ6yGr2+kOv+AuFrgtNuYow5ECXtFRNHo+A3+wRhweyM9hiFHCxBb EnNITYRdCiyn/oRbVbEXoj3ChbR9yQHMqQhaiSM7PTpPLu5B/zMzm08tqhBGUjWw xweTKOBYBlGxYInH1SbrmzmJNkRAj1Hljr756gVWyE9f22YFvurZkC4BWsHcaRn1 IZbPehk/1zcdUsd+Rk6ZCS7OV688uUJ0PNfjhl9nhWEvGigpWL66onHFdo9a0XXX 6md9zV7InhRACvXYHx2NVGveRkjJpW8Hsk0KJovr6iuRAQ62HcvcffPWPXN5H2l9 9hIahHrJ27hl+ef2NjTK4AKDO1wjWg== =JCHn -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 28 15:06:54 2019 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 1E0FC12099E; Mon, 28 Oct 2019 15:06:31 -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_HELO_NONE=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 gMZNlZ3UD3B7; Mon, 28 Oct 2019 15:06:29 -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 1737C12094F; Mon, 28 Oct 2019 15:06:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B263F3897A; Mon, 28 Oct 2019 18:03:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CE9133BF0; Mon, 28 Oct 2019 18:06:23 -0400 (EDT) From: Michael Richardson To: tom petch cc: Alissa Cooper , Dan Romascanu , "gen-art\@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.all\@ietf.org" , "ietf\@ietf.org" , "anima\@ietf.org" In-Reply-To: <048901d585ad$25f8dac0$4001a8c0@gateway.2wire.net> References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> <6CF1EF8F-EE0D-4BE6-B2C2-4C91883A881B@cooperw.in> <048901d585ad$25f8dac0$4001a8c0@gateway.2wire.net> 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] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 22:06:35 -0000 --=-=-= Content-Type: text/plain tom petch wrote: > Looking some more at this I-D, I have more concerns about the YANG > module. My review is informal - I recommend that the WG Chair request a > formal review because I may be missing something particularly in > connection with the 'refine' statements. > The I-D has namespace > "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; prefix "vch"; > whereas RFC8366, which it augments, has namespace > "urn:ietf:params:xml:ns:yang:ietf-voucher"; prefix vch; Different > module, same prefix; this contradicts a SHOULD NOT in RFC8407. okay, so I shoudl change it to "vcr" for VouCher Request then? I think that this will have affects on the constrained-voucher document, but that is easily fixed. > Further, this I-D defines import ietf-voucher { prefix v; i.e. does not > use the prefix defined in RFC8366. This contradicts a MUST in RFC8407. okay, got it, fixed it. > There is a discrepancy between the e-mail addresses of the authors of > the YANG module and of the I-D, for > Author: Kent Watsen Author: Fixed. > Toerless Eckert I note that the e-mail addresses for the YANG module > are the same as those for the YANG module in RFC8366; I do not know > which are correct. People moved to different companies since publication :-) > contact "WG Web: should be https: > and usually points to datatracker.ietf.org not tools Fixed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl23Zl8ACgkQgItw+93Q 3WWnbQf/bJrySdXUgLWK/XuCk6YEady21/Z549MIcLE+99Vsq0jOxXP43XBarwNp NMLPfF+Dz/sZAOXDuEzVrywAMLfAVEk5caGxpqW4iSfS9SUi7F09jdFogjazfPFJ sP4djT5Vltx/x2tXjBikgRLpcmj8CELuR/NMjGThYXkyzj/zRNglrLJ6b5YoFsk8 3o+nldKT8JvPTY/gx7ws7txs3ojhcaqKMVoarfDFzcByTizTWbz00cZLZqOqXpy9 5N+Bjrob82lYGS0vocb+AgWCLeRlTCXBlIaR8sKfyk8nlZG9bfVXS946U39pVsfA rfzMETMmua2torE0bZjFjmqR2UHDRg== =eFfM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 28 15:22:45 2019 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 0DC4A12008A; Mon, 28 Oct 2019 15:22:44 -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_HELO_NONE=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 aTZOepzu3ciB; Mon, 28 Oct 2019 15:22:42 -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 7769B12006B; Mon, 28 Oct 2019 15:22:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 90C913897A; Mon, 28 Oct 2019 18:19:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 97E093BF0; Mon, 28 Oct 2019 18:22:41 -0400 (EDT) From: Michael Richardson To: tom petch cc: Alissa Cooper , Dan Romascanu , "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "gen-art@ietf.org" , "ietf@ietf.org" , "anima@ietf.org" In-Reply-To: <010f01d585d2$20570d60$4001a8c0@gateway.2wire.net> References: <010f01d585d2$20570d60$4001a8c0@gateway.2wire.net> 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 Date: Mon, 28 Oct 2019 18:22:41 -0400 Message-ID: <30213.1572301361@localhost> Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 22:22:44 -0000 >A third set of comments > >The refine look ok to me (but I still recommend a formal review) > > leaf proximity-registrar-cert { > description > .. as specified by RFC 5280, > .. as specified in ITU-T X.690. >needs references; I suggest okay. RFC5280 is already referenced. Added: [ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, . -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Mon Oct 28 15:28:16 2019 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 D904F12008A; Mon, 28 Oct 2019 15:28:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <157230169382.16071.14951092402108793210@ietfa.amsl.com> Date: Mon, 28 Oct 2019 15:28:13 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-29.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 22:28:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-29.txt Pages : 117 Date : 2019-10-28 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-29 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 28 15:29:00 2019 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 49D4112008A; Mon, 28 Oct 2019 15:28:53 -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_HELO_NONE=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 5N6IQb8P_U72; Mon, 28 Oct 2019 15:28:51 -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 A7EEA120033; Mon, 28 Oct 2019 15:28:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8977D3897A; Mon, 28 Oct 2019 18:26:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB0383BF0; Mon, 28 Oct 2019 18:28:50 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20191018035715.GD43312@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> <20412.1568670397@localhost> <20191018035715.GD43312@kduck.mit.edu> 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2019 22:28:53 -0000 --=-=-= Content-Type: text/plain I have posted -29, which includes all changes in the past two weeks, including the informal YANG Doctor review. Name: draft-ietf-anima-bootstrapping-keyinfra Revision: 29 Title: Bootstrapping Remote Secure Key Infrastructures (BRSKI) Document date: 2019-10-28 Group: anima Pages: 117 URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-29.txt Status: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ Htmlized: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-29 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-29 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl23a6IACgkQgItw+93Q 3WX6zQgAq0bi+o3Cw4X1zizgBU7Pngush3dvO7FtaYwIrDWVRbmuq98sn0dDNrNA PyRpruD+Y4HXTVzeBibHYLb76L6vRTmPRpAMWW+yBTxzyFsJU8FzERmqcAorSyQd ISRyLfd3rV0hrB81BEpW95tt0gJ2UB1hI71YqspuoHKdo8NZDdRG/94pojaYqcBr aWofc5FpkaDO6g0CiH9fn/qVYf/IpK44b/Yy4mvnEw6RTIoalj9boQHL8sBH90rJ d8F7H+i8Pybaq5bQlV4btyXlxXCMQQURNZS6hv3vkIluIzLUAshMCEGaknxu1WWo bo8Mzks8+VJzrHQUU3MV3sIKUjOWlg== =pMCW -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 28 20:19:03 2019 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 297C5120047; Mon, 28 Oct 2019 20:19:02 -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_HELO_NONE=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 hF62nWFNOLaT; Mon, 28 Oct 2019 20:19:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 01A31120046; Mon, 28 Oct 2019 20:18:59 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9T3IisX017305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Oct 2019 23:18:46 -0400 Date: Mon, 28 Oct 2019 20:18:43 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, The IESG , tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20191029031843.GO69013@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22000.1572299410@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 03:19:02 -0000 Trimming heavily, with great thanks for the numerous updates... On Mon, Oct 28, 2019 at 05:50:10PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > I also have some more comments that didn't make it into my ballot position; > > please consider them as well. I will put them in the datatracker for > > posterity, but will have it not generate an additional mail since the > > mostly-duplicate contents would be confusing. > [...] > > doc> o The registrar forwards the voucher to the pledge when requested. > > > I suggest "validates and forwards" to cover the case where the registrar > > applies policy. > > the whole text is: > The registrar requests and validates the voucher from the MASA. > > The registrar forwards the voucher to the pledge when > requested. > > so validates is already in the previous point, I think. Indeed. Apparently the page break caused me to forget; sorry for the noise :( > > Section 5.8 > > doc> although it results in additional network traffic. The relying MASA > doc> implementation MAY leverage internal state to associate this request > doc> with the original, and by now already validated, voucher-request so > doc> as to avoid an extra crypto validation. > > > It seems that doing so would turn the voucher-request into a bearer > > token for retrieving audit-log information (if the MASA accepts > > unauthenticated clients). > > That's what's intended. I can see why that functionality is needed, but it seems likely to introduce some privacy and/or security considerations to document. It's a bit too late in the day for me to reason through them, though. > > Section 11 > > > I am somewhat embarassed that I did not previously note that the > > mechanism used to generate the domainID needs to be > > second-preimage-resistant or an attacker can claim to be a registrar for > > a domain that already exists. > > Right now, that's in: > > 5.8.2. Calculation of domainID > > The domainID is a binary value (a BIT STRING) that uniquely > identifies a Registrar by the "pinned-domain-cert" > > If the "pinned-domain-cert" certificate includes the > SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > used as the domainID. If not, the SPKI Fingerprint as described in > [RFC7469] section 2.4 is to be used. This value needs to be > calculated by both MASA (to populate the audit-log), and by the > Registrar (to recognize itself). > > We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to > replace it appropriately. That's all good and admirable; I'm suggesting that we add a note in the security considerations of this document noting that we rely on the domainID (however determined) to be second-preimage-resistant. > > Section 11.2 > > doc> Although the nonce used by the Pledge in the voucher-request does not > doc> require a strong cryptographic randomness, the use of TLS in all of > doc> the protocols in this document does. > > > We discuss the need for strong randomness in the nonce in Section 11.3, > > so it's not clear this is actually true. > > We don't think that the voucher nonce has to be of the same quality as something that > goes into a KDF. It is at the level of TCP Sequeunce number, not seed for > generating a private key... I mean, we literally say "Reducing the possibility of this is why the pledge is mandated to generate a strong random or pseudo-random number nonce." So to also say "the nonce [...] does not require a strong cryptographic randomness" seems to be in conflict with the former statement. Are you saying that "strong random" and "strong cryptographic random" mean different things, or am I misreading the document in some other way? Thanks, Ben From nobody Mon Oct 28 23:33:42 2019 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 BFF751200B8; Mon, 28 Oct 2019 23:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, 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 be7ao2JW0xAZ; Mon, 28 Oct 2019 23:33:30 -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 762EA120048; Mon, 28 Oct 2019 23:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8235; q=dns/txt; s=iport; t=1572330810; x=1573540410; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=E3hCIsvtt3jec9PGtC3hq/RSsvQtcDHTTJF945Jer/0=; b=ZNDrDsehR/VT9WIZg1YUeJ3pXo9SFQT8FkwcOKcd4Kck9xqdnhwEyYvy /jiAHZaSQ5z0+jb6+tBTEvNUfKXi2SOEpo/hu2iOJr1QQcTWJpUAfj+59 6hr26Gdj3USDxdoxu08pF8BipL3R7QaqZmpa8agI3ZOvjeO2rLs51jUeK Q=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAAD03Ldd/xbLJq1lDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF7gRyCRAEgEiqNK4duJYcyi1iICgI?= =?us-ascii?q?HAQEBCQMBAS8BAYRAAoNwOBMCAwkBAQQBAQECAQUEbYVDhVEBAQEDAXkFCws?= =?us-ascii?q?YIwtXBhODIgGCVyCwGYInhU6EcBCBNoFTilSBf4E4DBOCTD6IB4IsBJY2lzK?= =?us-ascii?q?CLoIzgRORaBuOHIs+pHGDFgIEBgUCFYFpIiqBLjMaCBsVZQGCQT4SEBSDPo1?= =?us-ascii?q?TPEADMJAbAQE?= X-IronPort-AV: E=Sophos;i="5.68,243,1569283200"; d="asc'?scan'208,217";a="18559777" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Oct 2019 06:33:01 +0000 Received: from [10.61.202.222] ([10.61.202.222]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x9T6X0ub019867 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Oct 2019 06:33:00 GMT From: Eliot Lear Message-Id: <521DE6A8-0839-4D52-AB9F-7F6717AFA5DB@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1DFD681E-0CD9-49F4-8762-4E0A340016F8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 29 Oct 2019 07:32:59 +0100 In-Reply-To: <20191029031843.GO69013@kduck.mit.edu> Cc: Michael Richardson , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org To: Benjamin Kaduk References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.202.222, [10.61.202.222] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 06:33:32 -0000 --Apple-Mail=_1DFD681E-0CD9-49F4-8762-4E0A340016F8 Content-Type: multipart/alternative; boundary="Apple-Mail=_5C9263BA-2AC1-490F-8B3B-395947EFA70C" --Apple-Mail=_5C9263BA-2AC1-490F-8B3B-395947EFA70C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 29 Oct 2019, at 04:18, Benjamin Kaduk wrote: >=20 > I mean, we literally say "Reducing the possibility of this is why the > pledge is mandated to generate a strong random or pseudo-random number > nonce." So to also say "the nonce [...] does not require a strong > cryptographic randomness" seems to be in conflict with the former > statement. > Are you saying that "strong random" and "strong cryptographic random" = mean > different things, or am I misreading the document in some other way? I would just drop the statement. The whole point of the nonce is to = prevent replay attacks, so why would we want to weaken that? Eliot --Apple-Mail=_5C9263BA-2AC1-490F-8B3B-395947EFA70C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On 29 Oct 2019, at 04:18, Benjamin Kaduk = <kaduk@mit.edu> = wrote:

I mean, we literally say = "Reducing the possibility of this is why the
pledge is mandated to generate a = strong random or pseudo-random number
nonce."  So to also say "the nonce [...] does not = require a strong
cryptographic randomness" seems to be in conflict with the = former
statement.
Are you saying that "strong random" and "strong cryptographic = random" mean
different = things, or am I misreading the document in some other = way?


I would just drop the statement. =  The whole point of the nonce is to prevent replay attacks, so why = would we want to weaken that?

Eliot
= --Apple-Mail=_5C9263BA-2AC1-490F-8B3B-395947EFA70C-- --Apple-Mail=_1DFD681E-0CD9-49F4-8762-4E0A340016F8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl233RsACgkQh7ZrRtnS ejO+YggAkx6M4IeB1yA6KKRVZi4yCMOEtq1cqWqakl7027SWRngvAJSgXT7fk95c sL4WElsgOx/JjImd4HrQYOmVe6oSlz3yrmGBtJLla12RbkfvVgb7oXf0zDUMbpEP GImhNFMNwh0tzj3WXGY2Zs3H1/1Jo66QSCiFOFgCzGnm96dSqXjaucPWABkGXRMR ykofWg58D+NezACAZEP9F0bE3P+pLTpAFIIScMgJff1iR0ahhw9GrA9R14Laio4G 0Vdhd7xcjDmsjjN8Dp+uAstA9mYN3TS6YAnUm4Y/1AZIEYxpE4SqSQchce+LVJzl s4pGKZOJSeTlG2bNdif8Z4OCjKdf3w== =K8WN -----END PGP SIGNATURE----- --Apple-Mail=_1DFD681E-0CD9-49F4-8762-4E0A340016F8-- From nobody Tue Oct 29 02:37:32 2019 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 8CE59120120; Tue, 29 Oct 2019 02:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4TdOcr7jUCmq; Tue, 29 Oct 2019 02:37:28 -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 044E512002E; Tue, 29 Oct 2019 02:37:28 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6E41C2D2665F7E47125C; Tue, 29 Oct 2019 09:37:25 +0000 (GMT) Received: from lhreml719-chm.china.huawei.com (10.201.108.70) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 29 Oct 2019 09:37:25 +0000 Received: from lhreml719-chm.china.huawei.com (10.201.108.70) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 29 Oct 2019 09:37:24 +0000 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 29 Oct 2019 09:37:24 +0000 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.0439.000; Tue, 29 Oct 2019 17:37:06 +0800 From: Sheng Jiang To: Xun Xiao , "anima@ietf.org" CC: "anima-chairs@ietf.org" Thread-Topic: Call for agenda ANIMA @ IETF 106, Singapore Thread-Index: AdV9jBLkoEaxILscRaKWE42MKoRSFwL9MpKwAS7hR8A= Date: Tue, 29 Oct 2019 09:37:06 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299C01FA5@NKGEML515-MBX.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9299B9FAD2@NKGEML515-MBX.china.huawei.com> <38ab284f860b4aa9b78a0f0549943c79@huawei.com> In-Reply-To: <38ab284f860b4aa9b78a0f0549943c79@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.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9299C01FA5NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 09:37:31 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299C01FA5NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFhpYW8sDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgZW1haWxzLiBZb3VyIGFwcGxpY2F0aW9u IGZvciB0aW1lIHNsb3QgYXJlIG5vdGVkLiBUaGUgY2hhaXJzIHdpbGwgYWxsb2NhdGUgdGltZSBh Y2NvcmRpbmcgdG8gdGhlIG92ZXJhbGwgcmVjZWl2ZWQgYXBwbGljYXRpb25zLg0KDQoNCg0KQmVz dCByZWdhcmRzLA0KDQoNCg0KU2hlbmcNCg0KRnJvbTogWHVuIFhpYW8NClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAyMywgMjAxOSA1OjE0IFBNDQpUbzogU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdA aHVhd2VpLmNvbT47IGFuaW1hQGlldGYub3JnDQpDYzogYW5pbWEtY2hhaXJzQGlldGYub3JnDQpT dWJqZWN0OiBSRTogQ2FsbCBmb3IgYWdlbmRhIEFOSU1BIEAgSUVURiAxMDYsIFNpbmdhcG9yZQ0K DQoNCkhpIEFOSU1BIGNoYWlycywNCg0KDQoNCldlIHdvdWxkIGxpa2UgdG8gYXBwbHkgYSBzbG90 IGZvciBvdXIgZHJhZnQuDQoNCg0KDQpOYW1lIG9mIHRpbWUgc2xvdDogRWl0aGVyIFR1ZS4gQWZ0 ZXJub29uIFNlc3Npb24gSUkgb3IgV2VkLiBBZnRlcm5vb24gU2Vzc2lvbiBJSUkgaXMgZmluZQ0K DQpOYW1lIG9mIGRyYWZ0KHMpOiBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aW9uLTEx DQoNClRpbWUgcmVxdWVzdGVkOiA1LTEwIG1pbnMNCg0KUHJlc2VudGVyIG5hbWUocyk6QXJ0dXIg SGVja2VyDQoNCkJlc3QgUmVnYXJkcywNCg0KWHVuIFhpYW8gKNCk0bgpDQpBZHZhbmNlZCBXaXJl bGVzcyBUZWNobm9sb2d5IExhYg0KTXVuaWNoIFJlc2VhcmNoIENlbnRlcg0KSHVhd2VpIFRlY2hu b2xvZ2llcyBDby4sTHRkLg0KDQpGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTaGVuZyBKaWFuZw0KU2VudDogVHVlc2RheSwgOCBPY3RvYmVy IDIwMTkgMDU6NTYNClRvOiBhbmltYUBpZXRmLm9yZzxtYWlsdG86YW5pbWFAaWV0Zi5vcmc+DQpD YzogYW5pbWEtY2hhaXJzQGlldGYub3JnPG1haWx0bzphbmltYS1jaGFpcnNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbQW5pbWFdIENhbGwgZm9yIGFnZW5kYSBBTklNQSBAIElFVEYgMTA2LCBTaW5nYXBv cmUNCg0KDQpIaSwgYWxsIGFuaW1hLA0KDQoNCg0KV2UgaGF2ZSBiZWVuIGFsbG9jYXRlZCB0d28g c2Vzc2lvbnMgb2YgMS41ICsgMSBob3VyIGZvciB0aGUgQU5JTUEgV0cgbWVldGluZyBmb3IgSUVU Ri0xMDYgKFNpbmdhcG9yZSkuIFdlIGFyZSBub3cgc3RhcnRpbmcgdG8gY29sbGVjdCBhZ2VuZGEg aXRlbXMgZm9yIHRoZSBzZXNzaW9ucy4gUGxlYXNlIHNlbmQgeW91ciByZXF1ZXN0IGZvciBhZ2Vu ZGEgYnkgT2N0b2JlciAzMXRoLCBUaHVyc2RheSwgdG8gYW5pbWEtY2hhaXJzQGlldGYub3JnPG1h aWx0bzphbmltYS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmFuaW1hLWNoYWlyc0BpZXRmLm9yZyUz Y21haWx0bzphbmltYS1jaGFpcnNAaWV0Zi5vcmc+PiBhbmQgYm90aCBjaGFpcnMnIGVtYWlsLiBQ bGVhc2Ugbm90ZSB0aGF0IGVtYWlsIHRvIGEgc2luZ2xlIGNoYWlyIG1heSBjYXVzZSBzaW5nbGUt cG9pbnQgZmFpbHVyZS4NCg0KDQoNCkFzIG5vcm1hbCwgdGhlIHByaW9yaXR5IGFtb25nIHRoZXNl IG5vbi1jaGFydGVyIHdvcmsgaXRlbXMgd291bGQgYmU6IHRoZXNlIHRoYXQgaGF2ZSBhY3RpdmUg ZGlzY3Vzc2lvbiBpbiBtYWlsIGxpc3QsIHRoZW4gdGhlc2UgaGF2ZSBzdWJtaXR0ZWQgZHJhZnRz LCBhbmQgdG9waWNzIHdpdGhvdXQgZHJhZnRzLg0KDQoNCg0KQXMgeW91IG1heSBvYnNlcnZlZCwg d2Ugbm93IGhhdmUgdGhlIG5ldyBXRyBjaGFydGVyIGluIHRoZSBwbGFjZSwgYnV0IHN0aWxsLCB3 ZSBoYXZlIHRoZSBwcmlvcml0eSB0byBjb21wbGV0ZSB0aGUgY3VycmVudCBXRyBkb2N1bWVudHMg b3ZlciB0byBhZG9wdCBhbnkgbmV3IHdvcmsuDQoNCg0KDQpQbGVhc2Ugc2VuZCB1cyAoYW5pbWEt Y2hhaXJzIGF0IGlldGYub3JnPGh0dHBzOi8vaWV0Zi5vcmcvPjxodHRwOi8vaWV0Zi5vcmclM0No dHRwcy9pZXRmLm9yZy8pPik8aWV0Zi5vcmclM2NodHRwczovaWV0Zi5vcmcvJTNlJTNjaHR0cDov aWV0Zi5vcmclM0NodHRwcy9pZXRmLm9yZy8pJTNlKT4gcmVxdWVzdHMgZm9yIHRpbWUgc2xvdCBi eSBPY3RvYmVyIDMxdGgsIFRodXJzZGF5IGFuZCBpbmNsdWRlOg0KDQoNCg0KTmFtZSBvZiB0aW1l IHNsb3Q6DQoNCk5hbWUgb2YgZHJhZnQocyk6DQoNClRpbWUgcmVxdWVzdGVkOg0KDQpQcmVzZW50 ZXIgbmFtZShzKToNCg0KDQoNCk1vcmUgZGV0YWlscyBhYm91dCB0aGUgSUVURiAxMDYsIE1vbnRy ZWFsIGNhbiBiZSBmb3VuZCBhdDoNCg0KDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2hvdy9tZWV0 aW5ncy8xMDYvDQoNCg0KDQpBZ2FpbiwgcHJlc2VudGVycyBhbmQgZHJhZnQgYXV0aG9ycyBwbGVh c2UgaW52b2tlIGFjdGl2ZSBkaXNjdXNzaW9ucyBpbiB0aGUgQU5JTUEgbGlzdC4gTWFpbCBsaXN0 IGlzIGEgdmVyeSBnb29kIHBsYWNlIHRvIGRpc2N1c3MgYW5kIHJlYWNoIGNvbnNlbnN1cyBvbiB0 ZWNobmljYWwgaXNzdWVzLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQoNCg0KU2hlbmcNCg0K --_000_5D36713D8A4E7348A7E10DF7437A4B9299C01FA5NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Xiao,<= /p>

 

Thanks for your emails. Your= application for time slot are noted. The chairs will allocate time accordi= ng to the overall received applications.

 

Best regards,

 

Sheng

 

From: Xun Xiao
Sent: Wednesday, October 23, 2019 5:14 PM
To: Sheng Jiang <jiangsheng@huawei.com>; anima@ietf.org
Cc: anima-chairs@ietf.org
Subject: RE: Call for agenda ANIMA @ IETF 106, Singapore<= /span>

 

Hi ANIMA chairs,

 


We would like to apply a slot for ou=
r draft.


 


Name of time slot: Either Tue. After=
noon Session II or Wed. Afternoon Session III is fine

Name of draft(s): draft-liu-anima-gr=
asp-distribution-11


Time requested: 5-10 mins=



Presenter name(s):Artur Hecker<=
/o:p>


 




Best Regards,


 


Xun Xiao (=D0=A4=D1=B8)


Advanced Wireless Techn=
ology Lab


Munich Research Center<=
o:p>


Huawei Technologies Co.=
,Ltd.




 






From: Anima [mailto:anima-bounces@ietf.org]
On Behalf Of Sheng Jiang

Sent: Tuesday, 8 October 2019 05:56

To: anima@ietf.org

Cc: anima-chairs@ietf.org

Subject: [Anima] Call for agenda ANIMA @ IETF 106, Singapore






 


Hi, all anima,

 


We have been allocated two sessions =
of 1.5 + 1 hour for the ANIMA WG meeting for IETF-106 (Singapore). We a=
re now starting to collect agenda items for the sessions. Please send your =
request for agenda by October 31th, Thursday, to anima-chairs@ietf.org<mail=
to:anima-chairs@ietf.org> and both chairs' email. Please note that e=
mail to a single chair may cause single-point failure.

 


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.


 


As you may observed, we now have the=
 new WG charter in the place, but still, we have the priority to complete t=
he current WG documents over to adopt any new work.


 


Please send us (anima-chairs at ietf.org<https://ietf.org/><http://ietf.org%3Chttps/ietf.org/)=
>) requests for time slot by October 31th, Thursday and include:


 


Name of time slot:=



Name of draft(s):<=
/pre>

Time requested:

Presenter name(s):=



 


More details about the IETF 106, Mon=
treal can be found at:


 


https://www.ietf.org/how/meetings/106/=



 


Again, presenters and draft authors =
please invoke active discussions in the ANIMA list. Mail list is a very goo=
d place to discuss and reach consensus on technical issues.


 


Best regards,

 


Sheng


 
--_000_5D36713D8A4E7348A7E10DF7437A4B9299C01FA5NKGEML515MBXchi_-- From nobody Tue Oct 29 02:44:27 2019 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 44CF312013B; Tue, 29 Oct 2019 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 LSf0MM_uuDXU; Tue, 29 Oct 2019 02:44:12 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60099.outbound.protection.outlook.com [40.107.6.99]) (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 02BF51201CE; Tue, 29 Oct 2019 02:44:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eFS+3fFS4y99UhWa/o+bbRA4CteF7e0NcWHhP5xexZ05rRPjYvPKyKfRwXdcz2ydEq7GX5GYWEpankhPmp+cLmsPu02BMUfs2zJgZlqvNITwuADAnQDXjUhdTzO7E8Zhwci0EhpnkxbBl66J3uPJXAJdN4ib0qfXnNDla4T5vytHx3fWrE2kX6MXy/gs8AWqGLZSSEaumvW2jflNC/DQyoSX+zU0vCPVh2m+mrS77dVIMkRZArAQ1omjobv7d+e18Ak3Brp3/CdnTIWFke+oEeTjDctsFZEjYKL+Q/nvFUKk1uHQqhpe8UEfDGQKQMYth7jXvm6dr7JyMfzHS+8cSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=meIQD6TSZqgwiZBVYEeLW69w79F8xq5Wy2qX5RZD3qU=; b=WIS48i59AbXKTF8Rbj4HOi6TU+GIQXusbies+xduhaBR35iAKZbAQG0aXwcUPuPteOKcQtIfj8fFN8337Rs4LyNBjuD1hS77X8x/uA13BQ6h2t7TU1UZP65JEwvLgp9FQMej0Y3ip//leldUTjewvu6znxm6KJR0Onkgzi9EXO43fA/8OpVBzaTMux4ssjyrHh1pKGVY7W8AEn4THf3CosRLruiYpzCAw0QWrJKMpS71Quh8rPy4zh0Jj6a2OCLsEK67TPCUDeFpmnB/R3AYsIP/yOnIqoVE/GI3xB2xW7i84Mu65gOlMdupjJuBbN/LRV8Ojz2dPu57Qrkoz6GFEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=meIQD6TSZqgwiZBVYEeLW69w79F8xq5Wy2qX5RZD3qU=; b=Mm7s320hQJAZXJfGhkaRbYKQnK85fzLneWmjy7lI9ngeAn7Iz7RJeHu+fI2z6w0lV7e8omdBHhnLNsy59x8f2ZpHSlOIgIOBXS/7qaNA2LyzhavdIUXUJ13FE0Cq/CccXd2w/Clmb2d/GEEHd8y5qYcVS9HYuh1twBFfIHebFxI= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB5444.eurprd07.prod.outlook.com (20.178.23.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Tue, 29 Oct 2019 09:44:09 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2%3]) with mapi id 15.20.2387.016; Tue, 29 Oct 2019 09:44:09 +0000 From: tom petch To: Michael Richardson CC: Alissa Cooper , Dan Romascanu , "gen-art@ietf.org" , "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "anima@ietf.org" , Last Call Thread-Topic: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 Thread-Index: AQHVgzylZL/55Dso/kSfI5QixLQChA== Date: Tue, 29 Oct 2019 09:44:09 +0000 Message-ID: <00f101d58e3d$08cd01e0$4001a8c0@gateway.2wire.net> References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> <6CF1EF8F-EE0D-4BE6-B2C2-4C91883A881B@cooperw.in> <048901d585ad$25f8dac0$4001a8c0@gateway.2wire.net> <26165.1572300383@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0372.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::24) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7a99bb4-60e6-4820-18c2-08d75c548c12 x-ms-traffictypediagnostic: AM0PR07MB5444: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(51444003)(13464003)(189003)(199004)(14496001)(316002)(6306002)(9686003)(256004)(66476007)(50226002)(305945005)(476003)(6512007)(14444005)(66556008)(5660300002)(54906003)(62236002)(61296003)(4326008)(66946007)(446003)(44716002)(486006)(386003)(6116002)(3846002)(6506007)(186003)(102836004)(6246003)(26005)(2906002)(52116002)(81816011)(8676002)(7736002)(6486002)(478600001)(86362001)(44736005)(66446008)(6436002)(25786009)(66066001)(14454004)(64756008)(8936002)(99286004)(4720700003)(81166006)(71200400001)(229853002)(81156014)(76176011)(1556002)(81686011)(71190400001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5444; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eD+HsuYHHK1WgeZXVWptSvSqkD5FIqMUii1DTw1b/MilCk/hnuq0A4OrBZ1bB+tayiJ2YET2LjKBxqQXhr4u1VRqUd5QluNWx0i82hs68kyzU69VbX2/x9/ax8rrl1GccTUyX40nas4Q0mihXeILObVL13jbd4m5YhwBqDyPy3zAYSMl2rnlTSJJy4J3P6BitgIfYnEqoCT7qQdHyFdz/mg+C4Ftzp+M3A0KcEOORft/hfpuOiNKXA4UKbIys1PX0DtBZtAba12pYaAhZ8GPKpKMOZnPwDp5waIAIWW0FoMSvlbSvohqZmssMPrCpYBZHDvKHpvpeVIK1XvIhm6aBU0SZk05j2sMk5oayDeTcxLgcnet9oqeWLOyr4S/WwUlr7zZYxrVOLXkCK3LXeXhxoFzt3k9GvWHnlEfshzq+ZbPMubljn5vzHH5x9OxfHXtI5xC5/bk+Kl/2Eum9Wt94xBwzWbr7K4A2S7IMmTnMqw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7a99bb4-60e6-4820-18c2-08d75c548c12 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 09:44:09.7276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3O7TaLAi6fA++qshbZ3mcI33JpnWT4L47L3SDf2v234nR7uJliqhI0chz6mYVCKwhzG9GJRsoRMUGFlrRibQgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5444 Archived-At: Subject: Re: [Anima] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 09:44:26 -0000 seeing if I can switch from ietf to Last Call inline Tom Petch ----- Original Message ----- From: "Michael Richardson" Sent: Monday, October 28, 2019 10:06 PM > tom petch wrote: > > Looking some more at this I-D, I have more concerns about the YANG > > module. My review is informal - I recommend that the WG Chair request a > > formal review because I may be missing something particularly in > > connection with the 'refine' statements. > > > The I-D has namespace > > "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; prefix "vch"; > > whereas RFC8366, which it augments, has namespace > > "urn:ietf:params:xml:ns:yang:ietf-voucher"; prefix vch; Different > > module, same prefix; this contradicts a SHOULD NOT in RFC8407. > > okay, so I shoudl change it to "vcr" for VouCher Request then? > I think that this will have affects on the constrained-voucher document, but > that is easily fixed. I would go for 'vchr' since voucher is 'vch' in RFC8366 and 'r' can then mean request. but then the voucher extension is 'vcj'. So, just a personal preference for 'vchr'; else ok for this e-mail Tom Petch > > Further, this I-D defines import ietf-voucher { prefix v; i.e. does not > > use the prefix defined in RFC8366. This contradicts a MUST in RFC8407. > > okay, got it, fixed it. > > > There is a discrepancy between the e-mail addresses of the authors of > > the YANG module and of the I-D, for > > Author: Kent Watsen Author: > > Fixed. > > > Toerless Eckert I note that the e-mail addresses for the YANG module > > are the same as those for the YANG module in RFC8366; I do not know > > which are correct. > > People moved to different companies since publication :-) > > > contact "WG Web: should be https: > > and usually points to datatracker.ietf.org not tools > > Fixed. > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- From nobody Tue Oct 29 04:49:53 2019 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 BC7BC120154; Tue, 29 Oct 2019 04:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 U-L4OwZkJbj3; Tue, 29 Oct 2019 04:49:42 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E9A120041; Tue, 29 Oct 2019 04:49:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k8u6TT+XLX5vvU31n6X1jmYdWWG/4Lmemg+4+ZaxcGFp9k5oXX3Evbn1Gl5Rj8uy6hHgB7sZ9dHalpF7hHcaoSz3CkNAxx8pRVw4l9+SGtWIg0Kke1zt7dg5X8vTdnwJvm9S9ngm+akrp5kFDDmFEXVnw4sZPcMeO9JAitbnpuOarWkLWibjhxfxZYVXdWSkQDXCTPXUcC2lyaMFNuoUXL0sMO0ls4KyMmOXPZ52wniq5K1sJvJFSzB3rXiyy40kKNhvoE6OvLoOHUCRfCTAM7HFqwRxVDJLo4MSV0kVQn6WUwge4xdrJAM0k1tUTcO1hJSpwBAUBYaI8tvsQy17HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KvUL2peRa5iy6lHUn595dmRBlZroxIaKtlCDOBvL3pM=; b=Jee8L3lzSrlJvBEuQ8KetSfbgfXOAIOvDK4zFv103tcxD3hh00v1QVZ2kpWTgEPytwxdllY77wNQWbcswlvlrzDfuFX6W36u2L3PvWzBIlEVGqU4jq2AnAm1lxs7HnjsjAomM5wA/5CFpQnGO6quOOeVkugYKP5EBK2jtdyF47zZmC0Afc7tFIlX1FIVl6sTzlOFHep5Osfymg2q1eYLSEghYFiGFxOSV7KRN2mDA2Upm3lkR1OLzLIduQfTrkGywgT/Yvee8HkPAnlVNwmgRaqaEPLdO35YEWiJgdWIIXU26cR4emUHyuA7ORi2TQ/gbf7ZVBrRC9r/ybROqljUyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KvUL2peRa5iy6lHUn595dmRBlZroxIaKtlCDOBvL3pM=; b=s816Gjg5ue2ediPmjZNwvH/Co7Eu3EIXL0Jc/Xptf/1hZCRO9b9nqzUTKT4AEToMElayeOJUiyTuinzFbrJ3Iz98bHFkzZcsEP5Su3JzTQLo0zF70dYKnl9yA1cqwgPdRs+jdGwi2/1LgwjmREyOOOJJY7XoFtVIcxBMJPzgKMI= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4001.eurprd07.prod.outlook.com (52.134.82.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.17; Tue, 29 Oct 2019 11:49:39 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2%3]) with mapi id 15.20.2387.016; Tue, 29 Oct 2019 11:49:39 +0000 From: tom petch To: Michael Richardson CC: "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" , "gen-art@ietf.org" , Alissa Cooper , Last Call , Dan Romascanu , "anima@ietf.org" Thread-Topic: [Last-Call] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 Thread-Index: AQHVgzylZL/55Dso/kSfI5QixLQChA== Date: Tue, 29 Oct 2019 11:49:39 +0000 Message-ID: <065201d58e4e$912aeb40$4001a8c0@gateway.2wire.net> References: <157095596011.20750.2703747454081790983@ietfa.amsl.com> <00f001d5833c$52aacf60$4001a8c0@gateway.2wire.net> <6CF1EF8F-EE0D-4BE6-B2C2-4C91883A881B@cooperw.in> <048901d585ad$25f8dac0$4001a8c0@gateway.2wire.net> <26165.1572300383@localhost> <00f101d58e3d$08cd01e0$4001a8c0@gateway.2wire.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0363.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::15) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e183fcc-a423-4057-005d-08d75c66147a x-ms-traffictypediagnostic: AM0PR07MB4001: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3173; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(39860400002)(376002)(346002)(51444003)(13464003)(189003)(199004)(478600001)(2906002)(305945005)(44716002)(26005)(66556008)(7736002)(966005)(6116002)(61296003)(66476007)(86362001)(62236002)(9686003)(6512007)(66446008)(14444005)(256004)(3846002)(64756008)(66946007)(6306002)(14454004)(316002)(44736005)(1556002)(6486002)(71190400001)(54906003)(50226002)(25786009)(4326008)(81686011)(6436002)(14496001)(6246003)(8936002)(8676002)(81156014)(81166006)(486006)(76176011)(446003)(6506007)(386003)(476003)(5660300002)(102836004)(4720700003)(99286004)(52116002)(186003)(81816011)(66066001)(71200400001)(229853002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4001; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: svAXfGNA2we6fd81rR8VTyHV0LnwzFoXvvZC2Vp8z9DYaLu2Dc9PQHUHfeIj5/1ReqEQrvkEahaRQYVK0e0smuVbnLdgQQtrGqa/LdNeT89IYMzhOFAxXvUI2bJSORO+pxnMuHN4zXYuDGTSMoghjtfhhaWkEIU8OYyIbYN+/3d2enzAe/HbPO374QutQA7puTxpqpF0gVOFSyIvPW5cSF21161sjQ9rHZQL7bc1hNAcBAGgtLVMufPXpkhz79D/SwbHrH3WWBaOfH1j2hmJtfFgEU7algVoo2uWD/Mwxxs0HfN85PSQHPGolCxNQooImdJ5StTvl6d4jmmAtE3ptTHOJSobbc0Otm68WTLGWWiqxphzsPreF/Z/wFCdjuyhFYSHNNZtDSzOQ/SIoSkBePuQmwhqJjFBOxz+vnAgf7dSy7cAWpsHCAOxybZJrUKUO/elZ2fG1UZuC94TaxmbhZpcYGu+0A3Q27Nxs+jvZfc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e183fcc-a423-4057-005d-08d75c66147a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2019 11:49:39.8292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RlrbH61YyEDIwsjmmFrjInUA+SMxU2dnjCOgx3BBXO52fRjGfpW+Qx2eUVqgkl+casV6rKyJhVzxc8Zpm4zRuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4001 Archived-At: Subject: Re: [Anima] [Last-Call] [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 11:49:45 -0000 Michael I just saw -29 after my last message and it still needs work. Appendix C confuses me. The reference to it from IANA Considerations suggests that it is Normative but there is nothing in it to say that it is and my take is that by default it is Informational. It contains a YANG module which - lacks references on import statements - lacks authors - lacks copyright - is not listed in IANA Considerations - has http: not https: - has a reference clause with a different title to that of the I-D - mixes URI and URL all in 35 lines :-) The YANG module in s.3.4 - references RFC8040 which is not in the I-D References - references Voucher Profile for Bootstrapping Protocols whereas this I-D has a title of Bootstrapping Remote Secure Key Infrastructures (BRSKI) - has // Grouping defined for future usage whereas the grouping is used in the previous YANG statement which leaves me puzzled - lacks YANG reference statements for leaf proximity-registrar-cert { i.e. RFC5280, X.690, RFC8446 - has [RFC8446] which looks like an XML/HTML anchor where a YANG module must be plain text - IANA Considerations does not register either module, 3.4 or Appendix C, as per RFC6020 s.14 - Security Consideratrions does not include the required YANG considerations which in turn generates further Normative References - Appendix A /The secification/The specification/ Tom Petch ----- Original Message ----- From: "tom petch" To: "Michael Richardson" Cc: ; ; "Alissa Cooper" ; "Last Call" ; "Dan Romascanu" ; Sent: Tuesday, October 29, 2019 9:44 AM > seeing if I can switch from ietf to Last Call > inline > > Tom Petch > > ----- Original Message ----- > From: "Michael Richardson" > Sent: Monday, October 28, 2019 10:06 PM > > > tom petch wrote: > > > Looking some more at this I-D, I have more concerns about the > YANG > > > module. My review is informal - I recommend that the WG Chair > request a > > > formal review because I may be missing something particularly in > > > connection with the 'refine' statements. > > > > > The I-D has namespace > > > "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; prefix > "vch"; > > > whereas RFC8366, which it augments, has namespace > > > "urn:ietf:params:xml:ns:yang:ietf-voucher"; prefix vch; > Different > > > module, same prefix; this contradicts a SHOULD NOT in RFC8407. > > > > okay, so I shoudl change it to "vcr" for VouCher Request then? > > I think that this will have affects on the constrained-voucher > document, but > > that is easily fixed. > > I would go for 'vchr' since voucher is 'vch' in RFC8366 and 'r' can then > mean request. but then the voucher extension is 'vcj'. So, just a > personal preference for 'vchr'; else ok for this e-mail > > Tom Petch > > > > Further, this I-D defines import ietf-voucher { prefix v; i.e. > does not > > > use the prefix defined in RFC8366. This contradicts a MUST in > RFC8407. > > > > okay, got it, fixed it. > > > > > There is a discrepancy between the e-mail addresses of the > authors of > > > the YANG module and of the I-D, for > > > Author: Kent Watsen Author: > > > > Fixed. > > > > > Toerless Eckert I note that the e-mail addresses for the YANG > module > > > are the same as those for the YANG module in RFC8366; I do not > know > > > which are correct. > > > > People moved to different companies since publication :-) > > > > > contact "WG Web: should be > https: > > > and usually points to datatracker.ietf.org not tools > > > > Fixed. > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Tue Oct 29 09:08:20 2019 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 33CF112006E; Tue, 29 Oct 2019 09:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 UiNNFE-S0NA1; Tue, 29 Oct 2019 09:08:16 -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 6234212002F; Tue, 29 Oct 2019 09:08:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DB7E3818F; Tue, 29 Oct 2019 12:05:31 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 678D485F; Tue, 29 Oct 2019 12:08:14 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, The IESG , tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20191029031843.GO69013@kduck.mit.edu> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> 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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 16:08:18 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: >> > Section 5.8 >> doc> although it results in additional network traffic. The relying MASA doc> implementation MAY leverage internal state to associate this request doc> with the original, and by now already validated, voucher-request so doc> as to avoid an extra crypto validation. >> >> > It seems that doing so would turn the voucher-request into a bearer >> > token for retrieving audit-log information (if the MASA accepts >> > unauthenticated clients). >> >> That's what's intended. > I can see why that functionality is needed, but it seems likely to > introduce some privacy and/or security considerations to document. It's a > bit too late in the day for me to reason through them, though. I think that they are in fact documented! >> We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to >> replace it appropriately. > That's all good and admirable; I'm suggesting that we add a note in the > security considerations of this document noting that we rely on the > domainID (however determined) to be second-preimage-resistant. The voucher is not pinned to the domainID, but to the actual certificate. Distinguishing the domainID for a moment from the thing in the certificate that hashes the public key when it is signed, if a second-preimage attack against the domainID would allow phony entries to be placed in the audit log. Assuming that the domainID is calculated using the same hash that is used in the certificate signature, then a second-preimage attack would break all of the certificates, period. I have added a section saying this, but it seems that our reference to RFC7469 already deals with this. >> > Section 11.2 >> doc> Although the nonce used by the Pledge in the voucher-request does not doc> require a strong cryptographic randomness, the use of TLS in all of doc> the protocols in this document does. >> >> > We discuss the need for strong randomness in the nonce in Section 11.3, >> > so it's not clear this is actually true. >> >> We don't think that the voucher nonce has to be of the same quality as >> something that >> goes into a KDF. It is at the level of TCP Sequeunce number, not seed for >> generating a private key... > I mean, we literally say "Reducing the possibility of this is why the > pledge is mandated to generate a strong random or pseudo-random number > nonce." So to also say "the nonce [...] does not require a strong > cryptographic randomness" seems to be in conflict with the former > statement. > Are you saying that "strong random" and "strong cryptographic random" mean > different things, or am I misreading the document in some other way? A Cryptographically Strong Sequence is more than enough. (section 6.2 of RFC4086). We don't need a "unguessable random number" (seed) section 5. Maybe I'm splitting hairs here. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl24Y+4ACgkQgItw+93Q 3WXR5wf7BLF7hTgJ0ea3svH/HoxaluHaB7wJnFH18CR7L+l3M+aiY2YfXA20yvc0 84hHp3rDA9p49H7RI6Bb+6jehdwWHFLZGGIjtJLWiumC2vG56inPodo2jh7ncYBQ B/5udhkL+vCG3Eoez/zq4rQuTnKvzOt9XEqFR3pGPdUXMWCw0k23KLX6bfmJWmd/ kHLxOGzrsfDcaWVfidpumrepTDJquCKO70UM0KvcZHrUudF5gt5HuAWfsonVGbmf /1Rr/+Nb+iQQ16EA9zRs/I1LOV8WUFKsPPxY+gwqY6oOY8uTyF01+vPBAkoZXl6S x8TKmYgyua3+Tt20DcUAHNO8icen1g== =3FDk -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 29 09:09:51 2019 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 8B0C41200A4; Tue, 29 Oct 2019 09:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 7FxJy_xy-978; Tue, 29 Oct 2019 09:09:41 -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 F06A512001A; Tue, 29 Oct 2019 09:09:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E97003818F; Tue, 29 Oct 2019 12:06:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3320085F; Tue, 29 Oct 2019 12:09:40 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: Benjamin Kaduk , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: <521DE6A8-0839-4D52-AB9F-7F6717AFA5DB@cisco.com> References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> <521DE6A8-0839-4D52-AB9F-7F6717AFA5DB@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] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 16:09:43 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: >> I mean, we literally say "Reducing the possibility of this is why the >> pledge is mandated to generate a strong random or pseudo-random number >> nonce." So to also say "the nonce [...] does not require a strong >> cryptographic randomness" seems to be in conflict with the former >> statement. >> Are you saying that "strong random" and "strong cryptographic random" mean >> different things, or am I misreading the document in some other way? > I would just drop the statement. The whole point of the nonce is to > prevent replay attacks, so why would we want to weaken that? I don't want someone to think that they need to include an additional source of hardware entropy just for the nonce. They already need a well seeded PRNG (RFC4086) for TLS operation, and that's more than enough. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl24ZEMACgkQgItw+93Q 3WUq7wgAmtnsZEZJRQJzCtTLPPYsKxbYpxSf3CmsC8PFXf+gmMiuLJ8lTYZP5eVY HGQuD/i581wr5GyI2OOyx0cdgFe3P8RIvYiczGtaLOpJG6GC6k7RbUezMdZE/xEo dTNH9ZlblkPWdmeQfT6yr5rOv/awy9hVCvqLstGHAV8sBMjggG4EIsxLRn3ZTJeX B6A2br8Ew32L2FOb9qxUfTH3kvJcNJruOSG52DBsss5C4Uh2YI/z8FW7Ia6DC/OI CtnUR4W4j19Wu4CIj9Ny8FMFnHp2cvfcRd4hE6iQFlx0tesEo4kkYXRIpmt8GA3H riysBV0k7Hhxbr9CM0cTNZ/rfHk2Jg== =cIaZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 29 19:34:09 2019 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 B5D421200A3 for ; Tue, 29 Oct 2019 19:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 a7jSoPL4KgL9 for ; Tue, 29 Oct 2019 19:34:05 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 B194812009E for ; Tue, 29 Oct 2019 19:34:05 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id c7so439132pfo.12 for ; Tue, 29 Oct 2019 19:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GHbqWiqFRf2YRS0AxCMV20pGO3xqp/goIwOen4rTVVg=; b=auqd46CzpztVpkwKgYfaD7ohH5Qr2Pf7g5/Jm55hKSg6BEhaGQaMdpZBGc71a7uGyU SFDKSGVAjo3/uvTjd9TW4EXfOoZIjdB/BcsiiNXJQCjoA259Zv9aPRnZkWxolmDiEM21 BUmjvvxYxPxiS/OekseddLHDhqwxcvx4JoGek3H+venRLwFuZ+2CwhV4H+Nn6CxIyo8F 6pkrp8bhQ0gOx5TgAJgYEDTMQj9zujlnSFaZAhktrwABMxYNv+pLeTMGdJAC8YHUN2Ow cYLdVNXHBOw8eUp8nUeaceHhI1Db140z7Ayv5ufSCaGvB7WgGpvwrty47bCoWKV7Joup wDDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GHbqWiqFRf2YRS0AxCMV20pGO3xqp/goIwOen4rTVVg=; b=eLE+051bbLxulAlDCeJOMZ9zgvbPTE2mNYsDH8CClPNxj3OdKkWhpv3nX+tcNWEcl0 dXJeHQ4lbakkx9nLBSBexDiGGx0a1ey43Qj/hKwAVZV5Srj8TD4ZX4hqbdJVcNWmJ7bx 9L09KLa+Csd/53PI1RUmUlrcXsT1QrnVVuYZoA0D3DwCmnpzv30pLsMo11veg+092TzC Ck3Sm+kMOfYwCsFo+1RRdgb7pdp9Za68GELhDk9yz8zsw6w5L5Bghi/zxhsrWqKPehbR JHlMx0K0WoVjURjvTtMh2PEAxsyXY0a51JR9ISQbPS2BEoCbzlDdkE3+/u6N7drrI/20 3JbQ== X-Gm-Message-State: APjAAAVNNoIvnbx0w60iXQmXwWDWNGSbQ3bKl65LdF8fneR1ht6jDWLq sr+SOUunENbe/UhhYpNewihsmwOn X-Google-Smtp-Source: APXvYqzJ8xWrZrYgZE4DF7QFhrU9EYMPrXFjPEyNDFu8uWejm7mqM1C7UwEpoS3aCW6oDympOfi08Q== X-Received: by 2002:a63:1b07:: with SMTP id b7mr30964387pgb.166.1572402844720; Tue, 29 Oct 2019 19:34:04 -0700 (PDT) Received: from [192.168.178.30] (46.137.69.111.dynamic.snap.net.nz. [111.69.137.46]) by smtp.gmail.com with ESMTPSA id q185sm488128pfc.153.2019.10.29.19.34.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Oct 2019 19:34:03 -0700 (PDT) References: <157240177304.3222.18217404947328031420@ietfa.amsl.com> To: Anima WG From: Brian E Carpenter Organization: University of Auckland X-Forwarded-Message-Id: <157240177304.3222.18217404947328031420@ietfa.amsl.com> Message-ID: <1af4feb3-b18e-abb6-198b-9e3bf6820645@gmail.com> Date: Wed, 30 Oct 2019 15:34:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <157240177304.3222.18217404947328031420@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-quads-grasp-02.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 02:34:08 -0000 This, I promise, is the last update before Singapore. I've added some crypto details on the QUADSKI key exchange, and a few clarifications. A reader familiar with BRSKI may note that the QUADSKI server replaces the role of the BRSKI Registrar, and an unencrypted GRASP daemon replaces the role of the BRSKI Join Proxy. And of course what the pledge does is quite different from BRSKI. I have posted QUADS and QUADSKI code at https://github.com/becarpenter/graspy; please start with the relevant section in graspy.pdf (page 18). Since this is really a side track from ANIMA's work, I don't intend to ask for a slot in the WG meeting, but if anyone would like me to arrange a side meeting please let me know off list. Regards Brian -------- Forwarded Message -------- Subject: I-D Action: draft-carpenter-anima-quads-grasp-02.txt Date: Tue, 29 Oct 2019 19:16:13 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Quick and Dirty Security for GRASP Author : Brian Carpenter Filename : draft-carpenter-anima-quads-grasp-02.txt Pages : 9 Date : 2019-10-29 Abstract: A secure substrate is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Security method using symmetric cryptography and preconfigured keys or passwords. It also describes a simplistic QUADS Key Infrastructure based on asymmetric cryptography used over insecure instances of GRASP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-anima-quads-grasp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-carpenter-anima-quads-grasp-02 https://datatracker.ietf.org/doc/html/draft-carpenter-anima-quads-grasp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-quads-grasp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Oct 30 07:58:07 2019 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 4C22C120847 for ; Wed, 30 Oct 2019 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 pbOevcBlm1SL for ; Wed, 30 Oct 2019 07:58:02 -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 31C51120841 for ; Wed, 30 Oct 2019 07:58:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F2A7E3818F for ; Wed, 30 Oct 2019 10:55:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A5B6085F for ; Wed, 30 Oct 2019 10:58:00 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: References: 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] BRSKI-Cloud discussion (from private thread) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 14:58:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It was written privately that: > =E2=80=9CA 406 (Not Acceptable) ... The registrar SHOULD use this res= ponse if > it determines > the pledge is unacceptable due to inventory control, MASA audit-logs, > or any other reason. > =E2=80=9D > Michael: Its not clear in draft-29, but I am reading into this that if > ownership tracking is supported, that if the wrong Local Registrar > (i.e. not the owner) requests a voucher for a pledge, the MASA should > return a 406 response code. yes, that's what's expected. In explaining BRSKI via animated slideware about how things work (yestesday= ), it has occured to me that MASA ought to probably restrict or delay simultan= eous voucher-requests from different domainIDs if they have no sales-channel integration. (There is a youtube screencast) There is otherwise a kind of race condition that could occur. That allows one domainID to clearly claim the device, and proceed to enrollment (or fail) before the other one makes an attempt. Back to the Cloud-Registrar: > If we are using any of the other 3 options =E2=80=9CVoucher Request H= andled by > Cloud Registrar=E2=80=9D, the local domain does not see the Voucher r= esponse at > all. Voucher Request/Response handling is all done by the Cloud > Registrar. The response voucher needs to include a pinned-domain-cert linking to the Local Registrar so that the 3xx redirect can validate the Local Registrar correctly. I think that we should have a discussion about option 2 (redirect at ENROLL) vs option 3 (redirect via Voucher). I'm not sure why we need both cases. > I think it looks like we need to do either > (i) =E2=80=9CVoucher Request Redirected to Local Domain > Registrar=E2=80=9D where the cloud 3xxs the Voucher request and the P= ledge > resends the Voucher Request via the local registrar (which you were > trying to avoid) OR > (ii) =E2=80=9CVoucher Request Handled by Cloud Registrar= =E2=80=9D option 2 > or 3 *and* somehow get the pledge to include the Voucher in the EST > enrol API. This means that, similar to your flow in your slide, the > device has to treat the Voucher kind of like a Bearer token and inclu= de > the Voucher in the HTTP Authorization header of the EST enrol > request. So logically following on from that, it seems like it would > mean defining a new HTTP =E2=80=9CAuthorization: Voucher xxx=E2=80=9D= type, similar to > HTTP =E2=80=9CAuthorization: Bearer xxx=E2=80=9D=E2=80=A6 Michael =E2= =80=93 have you ever considered > that scenario at all? A Voucher being used kinda like an OAuth Bearer > token..? I don't think that I really understood the situation that waranteed it! The question is whether the Local Registrar is an EST-only Registrar, or if speaks BRSKI. As an alternative to a new form of authentication, the Registrar, upon seei= ng a client connect with an IDevID containing a serial number and a MASA URL, could do a voucher-request to the MASA, and receive in response, the same voucher that was issued to the Pledge. As another alternative, the Voucher-Request POST that the Pledge does, could be answered with a 201 Created and a Location: for the voucher object. The Pledge would retrieve it, and then, put that URL into a Referer: header fie= ld on the POST. Let's talk about the "3xx" responses. From Wikipedia: 301 Moved Permanently This and all future requests should be directed to the given URI. 302 Found (Previously "Moved temporarily") Tells the client to look at (browse to) another URL. 302 has been super= seded by 303 and 307. This is an example of industry practice contradicting t= he standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[22] but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status code= s 303 and 307 to distinguish between the two behaviours.[23] However, some Web applications and frameworks use the 302 status code as if it were the 303. 303 See Other (since HTTP/1.1) The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a= new GET request to the given URI. 304 Not Modified (RFC 7232) Indicates that the resource has not been modified since the version spe= cified by the request headers If-Modified-Since or If-None-Match. In such case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.[26] 305 Use Proxy (since HTTP/1.1) The requested resource is available only through a proxy, the address f= or which is provided in the response. For security reasons, many HTTP clie= nts (such as Mozilla Firefox and Internet Explorer) do not obey this status code.[27] 306 Switch Proxy No longer used. Originally meant "Subsequent requests should use the specified proxy."[28] 307 Temporary Redirect (since HTTP/1.1) In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 3= 02 was historically implemented, the request method is not allowed to be chang= ed when reissuing the original request. For example, a POST request should= be repeated using another POST request.[29] It seems that we should probably be answering the voucher-request POST with 307. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl25pPgACgkQgItw+93Q 3WWLuggAtvfF7Bo81D3J1/zL7mffF0SLThkTgYdEbShZws/vcBriryZyAoKq9Ys5 xGqwSoRYEDwY5gNldgqgx5ClFASOSLqlzRFBukrG34kns1zO4GngtA+BzKGdAYuZ ElJmGqJzAHKR5C13ZoVb/V7QQ/JQlU2WZNYtVEq31gjO1foVQWN3iSd8cvODq4Z/ Tny3xkkfKRlhDNLdo+U3vz7q8mHDA6IvBYYD1m0MRawCXtCVlO2BNNzvstJuiYyp sj9yZuwHeaFVZw54J0hpSEUYTLGp47rZjzb+x35QrDE3ldvN5yx6D7hjYKb/HfF3 0M8leaus+0UBJDYI6g924MWNyb7Esg== =hmUg -----END PGP SIGNATURE----- --=-=-=--