From nobody Sun Jul 5 16:25:16 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775FA1A8739 for ; Sun, 5 Jul 2015 16:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZx3fY23jgSH for ; Sun, 5 Jul 2015 16:25:14 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 471601A8734 for ; Sun, 5 Jul 2015 16:25:14 -0700 (PDT) Received: by pacgz10 with SMTP id gz10so11307610pac.3 for ; Sun, 05 Jul 2015 16:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TR4RcS+LZ5DdYlTYQvd7URjsCGc6M2gPF9S99WvnZBo=; b=Hn5NVlO3qzmdCm7qhB5Z+sNL4nzlRaht8mo80MQm6432Ho6jZ8Qdzp0xtG679sAdsl NVcSyAr0cJM7rbX7R4q4i67YeqsKA2jsnfsaKU6HqQHFFs5NiIAxdKNPo3VWVXKHD1eh rGMbRny4yEHaH+A79U0w+8RB6RSJXPLf8nRIeMrxhzNj1oqbjOuFuN6FVJkHKkCwhZEH R9J/5xI5l5HS+4K14ptBTh6UYAMxXY1WpoJzIsaeH7ILFdcUY1neMRzifrTXids6FzNJ s+BF1NY5TUi0yWmpWHrtvR9EYmHEpWQ5R0BeVt2I9Z/BbZ5J8nog6DyD6l/f/ClZKbn0 PmJQ== X-Received: by 10.66.146.100 with SMTP id tb4mr99353753pab.70.1436138713916; Sun, 05 Jul 2015 16:25:13 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id oa14sm15973728pdb.47.2015.07.05.16.25.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2015 16:25:12 -0700 (PDT) Message-ID: <5599BCD2.1080306@gmail.com> Date: Mon, 06 Jul 2015 11:25:07 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Richardson , anima-bootstrap@ietf.org References: <11466.1435154789@sandelman.ca> In-Reply-To: <11466.1435154789@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima-bootstrap] Crypto parameters [Re: a repost of summary] X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 23:25:15 -0000 I'm in catch-up mode: On 25/06/2015 02:06, Michael Richardson wrote: ... > it turns out there is an additional benefit in making the constrained > node the TLS "Server" -- side. Specifically, it means that the selection > of crypto parameters is done by the more constrained device, Point taken, but isn't that also an exposure to a downgrade attack by a bad actor pretending to be constrained in order to reduce algorithm or key strength? Brian From nobody Sun Jul 5 16:27:14 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C121A8742 for ; Sun, 5 Jul 2015 16:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmeWDIlqGJyg for ; Sun, 5 Jul 2015 16:27:11 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41411A8741 for ; Sun, 5 Jul 2015 16:27:11 -0700 (PDT) Received: by pdjd13 with SMTP id d13so94815147pdj.0 for ; Sun, 05 Jul 2015 16:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uc7HIFIxyTd0fR7VBrO7cxuniSQ9+zR6+GPmaIiExbU=; b=TawZcsHvELg4UwfiRnv3hfl3zAkeeB8OA9M5uG9qANRrN8iyNVDKLry4Rj22fdoebE hR1UMzUu2F+plx0E8MTprgpmdeDg+X9nW0CHWzJw9ZBfpiXWsmv7OMG+D2WCcNY/IdwU Lw+YQuKgfO6b2YlF3KYNddWy6moRneLVk2/3sOhR2EdtaTfzgJdTYN4lhcX3csuSGUnL rD9MItyvcwI6HeO+BqgPgdEC15KvIR/vksngugZdNlt3TxNLCDWFTK4WTbQxbxU+uwPd UVaGbjmYURPYi2mN6RkuXDbuXDtwvdLjpUQh851T607ImNLoTblBKNj0spZOmU6iGkmx VN2A== X-Received: by 10.68.229.200 with SMTP id ss8mr100308816pbc.150.1436138831333; Sun, 05 Jul 2015 16:27:11 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id xv9sm15966680pbc.2.2015.07.05.16.27.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2015 16:27:09 -0700 (PDT) Message-ID: <5599BD49.5060301@gmail.com> Date: Mon, 06 Jul 2015 11:27:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Michael Behringer (mbehring)" , Michael Richardson , "anima-bootstrap@ietf.org" References: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@xmb-rcd-x14.cisco.com> <19598.1435255781@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5C41@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5C41@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima-bootstrap] Meeting notes from 6/24 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 23:27:13 -0000 below... On 26/06/2015 19:03, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On >> Behalf Of Michael Richardson >> Sent: 25 June 2015 20:10 >> To: anima-bootstrap@ietf.org >> Subject: Re: [Anima-bootstrap] Meeting notes from 6/24 >> >> >> Michael Behringer (mbehring) wrote: >> > A high level question up front: When we wrote draft-pritikin, we >> > started from the premise that the draft should describe the most secure >> > model as a reference, then in section 6, explains alternative models >> > which may be less secure, but more useful for certain environments. Are >> > we still sticking to this philosophy "describe best possible, and >> > separately less secure alternatives"? (I hope so ;-) >> >> I think that this is the best way. > > Good - we're on the same page. > >> I wanted to describe the less secure ways as "mitigations" --- things you do >> because you are unable to do a secure(r) thing. Brian Carpenter did not like >> that term, and I'm still trying to understand why. > > That term doesn't sound right to me either. From dictionary.reference.com: > > 1. the act of mitigating, or lessening the force or intensity of something unpleasant, as wrath, pain, grief, or extreme circumstances: > Social support is the most important factor in the mitigation of stress among adolescents. > > 2. the act of making a condition or consequence less severe: > the mitigation of a punishment. > > 3. the process of becoming milder, gentler, or less severe. > > 4. a mitigating circumstance, event, or consequence. > > bottom line: to me "mitigation" is a positive thing (see definition 3). It's making something bad feel less bad. I think if you take any of the less secure options, you SHOULD feel bad :-) > > Call it "less secure options" - that's what it is. Exactly. Brian > Michael > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > From nobody Sun Jul 5 16:34:52 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC581A8718 for ; Sun, 5 Jul 2015 16:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKnU6E-HVW0u for ; Sun, 5 Jul 2015 16:34:49 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (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 4FA281A7018 for ; Sun, 5 Jul 2015 16:34:49 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so94548370pdb.2 for ; Sun, 05 Jul 2015 16:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=6wYwm666IxYwAoPKG9kNTS6JMEolYVoNurX6mKV/6w4=; b=PMjK3Uy9t69VMc2gsaMGsw+ESSVQmlxU3S7QpPrf9dZMRst4RQxSEZFeNO2GU/yK1B hb3qrQklg2fw3FArhEIkw8n2wwvOmuoXpX5DvYfra0w3htnSEnXJfuJlf4UOZRofmV8U 2bW51ImZIO0U1jBwVSB68SZ8mOXgsFE5IUV1r8EAY7TUs94DoqrxtojNQgGTW3EiwIaG BNmAQ9nRMcoyzmxALw6Qw8o629LVKZXopfKlLAo5Y1gCPyvjy2sCtgsQRbaIK+JKkrkX pJrz2Wq7rkOJ6II5T0IXi9jK/9EzbPBGwgtSeeQR2MUkyNR4dQWaXv2+uChNfbkOP1wO 3EmQ== X-Received: by 10.66.231.42 with SMTP id td10mr97921012pac.98.1436139289037; Sun, 05 Jul 2015 16:34:49 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by mx.google.com with ESMTPSA id a7sm3339071pbu.0.2015.07.05.16.34.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Jul 2015 16:34:47 -0700 (PDT) Message-ID: <5599BF13.60405@gmail.com> Date: Mon, 06 Jul 2015 11:34:43 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: anima-bootstrap@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima-bootstrap] Scope question X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 23:34:50 -0000 The design team charter at http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap%20Design%20Team%20Charter leaves two scope questions open for me. 1. Is the scope *all* nodes in a network, or only the nodes taking part in autonomic operations (i.e. nodes that are part of the ACP and/or run Anima signaling)? 2. Is the scope limited to physical nodes? Or in other words, do entities like virtual machines or ASAs inherit credentials from the physical node containing them? Regards Brian From nobody Sun Jul 5 17:46:41 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A331B29C5 for ; Sun, 5 Jul 2015 17:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrys0piTZMjd for ; Sun, 5 Jul 2015 17:46:39 -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 49D241B29C4 for ; Sun, 5 Jul 2015 17:46:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 46D9820012 for ; Sun, 5 Jul 2015 21:02:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 38FBF63AEC; Sun, 5 Jul 2015 20:46:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1D32363AE8 for ; Sun, 5 Jul 2015 20:46:37 -0400 (EDT) From: Michael Richardson To: anima-bootstrap@ietf.org In-Reply-To: <5599BCD2.1080306@gmail.com> References: <11466.1435154789@sandelman.ca> <5599BCD2.1080306@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] Crypto parameters [Re: a repost of summary] X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 00:46:40 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I'm in catch-up mode: On 25/06/2015 02:06, Michael Richardson wrote: > ... >> it turns out there is an additional benefit in making the constrained >> node the TLS "Server" -- side. Specifically, it means that the >> selection of crypto parameters is done by the more constrained device, > Point taken, but isn't that also an exposure to a downgrade attack by a > bad actor pretending to be constrained in order to reduce algorithm or > key strength? The bad actor would have to conduct a man-in-the-middle attack. (If it's just pretending to be another device, then it's just some kind of impersonation attack) Once the bad actor had done the MITM to substitute poorer crypto, the initiator (the domain owner/registrar) would then have to incorrectly accept a cipher that it didn't propose. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZnP6YCLcPvd0N1lAQKSXwgAhMhjWnIj3rxUpklxRJaJQvRttwggfGyE FTwThmZ4sPvB2HiQKWEQwI97KIi3WEO58f/xqs3aQ2eCCXjA29Oh/cb6/UTyMUfQ up11BxBPWNjjIBbKW+oojWRrzF9FJavER+AHKnnE6SwMr7bqYXCXILaOQaNDOegV lb90knfKuI2GoKpaLgApkMXL+q65XRZw0e6KEPuTTGgcVarcEW+j1t7pNfu/nlTV 8UYwBoPCBN2L0WU3UDus7iwbAVgUKEE5mbr+15l6PsWBZQlVri7W8jZKWwUVS3Pg gyzTUVFirvt29nL+fJ1wYpqfg+UHFsu+g9IqHUlvh/6iXOSI4fGIWw== =Kov7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 5 17:54:37 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9951B29D3 for ; Sun, 5 Jul 2015 17:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDXgNwlTIWWt for ; Sun, 5 Jul 2015 17:54:35 -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 2C92E1B29D1 for ; Sun, 5 Jul 2015 17:54:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C11820012 for ; Sun, 5 Jul 2015 21:10:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6B38D63AEC; Sun, 5 Jul 2015 20:54:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49BA863AE8 for ; Sun, 5 Jul 2015 20:54:34 -0400 (EDT) From: Michael Richardson To: anima-bootstrap@ietf.org In-Reply-To: <5599BF13.60405@gmail.com> References: <5599BF13.60405@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] Scope question X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 00:54:36 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > The design team charter at > http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap%20Design%20Team%20Charter > leaves two scope questions open for me. > 1. Is the scope *all* nodes in a network, or only the nodes taking part > in autonomic operations (i.e. nodes that are part of the ACP and/or run > Anima signaling)? Only those taking part autonomic operation... > 2. Is the scope limited to physical nodes? Or in other words, do > entities like virtual machines or ASAs inherit credentials from the > physical node containing them? While I would expect ASAs running on a node to have some kind of access to the hosts credentials, but we should consider possibility that we need to issue additional (transitive) credentials to individual ASAs. As for virtual machines running on a host, in general, they would have to join the ACP through their own seperate bootstrap process. As they don't have vendors, it could be that they would be provisioned through the same transitive process as the ASAs, once we figure out how to do that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVZnRx4CLcPvd0N1lAQI3Vwf/cH4CsIOio2GG7I9jvnPtqW+3FOKrdJsP /UjatyzybVDTcC52CpEsYER3QUhxX0haxEOmRMN6/P9OI1gUiIfMvqWR0akaLn2g VXZxYCov7nwE6MysAs+Wda/xL60T+h4tI4byn9gShsiSMDKZUMVCt8cOB9ecYwfi pIbmfHfX2kVl13tzP8qys3jYWsCbxpNBwQETOJSnKHs1d+cjKYkBC0rYUqhe2+c4 ogBIvKPJULqV+pdOf9KKMzGhVHICgu7E7OINkk2UvuZZxgt76uwNyk2SJ9C7CEbo KsUG8zDUUKmJWJRGoagE6CsWCkyHwEXVptK1SXmtFBjAb4U2Lg+drQ== =jDGA -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 5 20:29:56 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36B61B2A72 for ; Sun, 5 Jul 2015 20:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DnZ6dz_olX for ; Sun, 5 Jul 2015 20:29:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7651B2A70 for ; Sun, 5 Jul 2015 20:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1344; q=dns/txt; s=iport; t=1436153393; x=1437362993; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=eDn5Vmf8Gyfewz9zzL06qG8zkjh89IGSmNkFthznOlM=; b=j0biPgJBI7dU2TUlvBqpIXDn7qUMy5SY+8WRtOOzepPinNeNNptiyWDq qWtO1uO9aQbaR4JXHZ57rLb7tVl2flzV6TSI25cawwxauupod9kxlsEqU TDdb51RBXjtKHVfGm1tQLKobtCVB1awm3pxicw1Br4HHN/zpg7FQeEaf3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9BACn9ZlV/4QNJK1cgxJUYL1egWQMhXUCgSM5EwEBAQEBAQGBCoQkAQEEAQEBNzQLEAsYCSUPBRM2E4gvDcdlAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tLhC1ZB4QrBY0Ihw2EYocFAYF+llgmhBseMQGBA4FHAQEB X-IronPort-AV: E=Sophos;i="5.15,412,1432598400"; d="scan'208";a="12849653" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 06 Jul 2015 03:29:52 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t663Tq6q014091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2015 03:29:52 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t663Tphl001484; Sun, 5 Jul 2015 20:29:51 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t663TpOl001483; Sun, 5 Jul 2015 20:29:51 -0700 Date: Sun, 5 Jul 2015 20:29:51 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150706032951.GX27147@cisco.com> References: <5599BF13.60405@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5599BF13.60405@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [Anima-bootstrap] Scope question X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 03:29:54 -0000 To keep us focussed on moving towards RFCs, i would first look into the following Prio1: Prio1, in charter: Bootstrap of certificate on physical devices that are AN devices: bootstrap+signaling+ACP+ASA sharing the certificate. And then beyond it: PrioN > 1, in charter: Bootstrap for logical autonomic devices/VMs/ASA that need separate certificates from the underlying system. Outside current charter: Reuse of bootstrap in non-AN devices - eg: without the rest of autonomic and potentially with different protocols. Cheers Toerless On Mon, Jul 06, 2015 at 11:34:43AM +1200, Brian E Carpenter wrote: > The design team charter at > http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap%20Design%20Team%20Charter > leaves two scope questions open for me. > > 1. Is the scope *all* nodes in a network, or only the nodes taking > part in autonomic operations (i.e. nodes that are part of the ACP > and/or run Anima signaling)? > > 2. Is the scope limited to physical nodes? Or in other words, do > entities like virtual machines or ASAs inherit credentials from > the physical node containing them? > > Regards > Brian > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Fri Jul 10 11:49:42 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98141A1AE3 for ; Fri, 10 Jul 2015 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtijZ99QEQIw for ; Fri, 10 Jul 2015 11:49:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23771A036F for ; Fri, 10 Jul 2015 11:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4824; q=dns/txt; s=iport; t=1436554178; x=1437763778; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0lHufJFwBko3CHd1LIZWH6SwxwZcExwvROMDpjGMfKI=; b=PVZgt9qExXL6l9ZGu48tC0Hp/JPj90PPdPdpqYNrZVQCVitft/kxsPnf 2JcPec3EOS3tcZA6m4u8j65R8nK4F7gzsq8057vMiFgee0YGfvCMh1977 +dOHXNRwEW+OQserhi6KCrWhC5xCy1Z16bsOGGP4PPhKN/A8/NuKKaRYF c=; X-IronPort-AV: E=Sophos;i="5.15,448,1432598400"; d="scan'208";a="8768298" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jul 2015 18:49:38 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6AInbMO005601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2015 18:49:38 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6AInbJd016697; Fri, 10 Jul 2015 11:49:37 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6AInaSC016696; Fri, 10 Jul 2015 11:49:36 -0700 Date: Fri, 10 Jul 2015 11:49:36 -0700 From: Toerless Eckert To: "Ersue, Mehmet (Nokia - DE/Munich)" , anima-bootstrap@ietf.org Message-ID: <20150710184936.GA16597@cisco.com> References: <20150602021008.GA578@cisco.com> <5583DB01.6060201@cisco.com> <20150710152711.GO27147@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150710152711.GO27147@cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: ext Kent Watsen , "anima-chairs@tools.ietf.org" , "ops-ads@tools.ietf.org" , Mahesh Jethanandani , Benoit Claise , ext Terry Manderson Subject: Re: [Anima-bootstrap] Short slot in Netconf Session WAS:RE: [Anima] Call for Volunteer - ANIMA bootstrap design team X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 18:49:40 -0000 Thanks a lot, Mehmet, this is great. Including the design team alias. We will prepare for that slot! Cheers Toerless [sorry, resend, mistyped bootstrap team alias] On Fri, Jul 10, 2015 at 09:32:47AM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote: > Dear Toerless, Sheng Jiang, > > Netconf co-chairs are planning a short slot in the Netconf session for the bootstrap design team. > > Can anybody from the design team join the Netconf session (Thursday 13:00) and inform the Netconf WG on the goals, schedule and progress verbally? The exact time for this short slot can be arranged in a flexible manner. > > Thank you very much for your consideration. > > Cheers, > Mehmet > > -----Original Message----- > From: ext Terry Manderson [mailto:terry.manderson@icann.org] > Sent: Monday, June 22, 2015 3:42 AM > To: Benoit Claise; Ersue, Mehmet (Nokia - DE/Munich); ext Kent Watsen; anima-chairs@tools.ietf.org > Cc: Mahesh Jethanandani; ops-ads@tools.ietf.org > Subject: Re: [Anima] Call for Volunteer - ANIMA bootstrap design team > > All, > > I have previously advised the ANIMA chairs to remain in the bounds of > their charter, especially with their 2 design teams. And I believe that > this is understood. My impression is that if anything comes along that > calls out for additional work in NETCONF I'm sure that the ANIMA DT > leaders and the ANIMA chairs will flag that. > > I would urge NETCONF folk to join the bootstrap design team to assist, and > guide as appropriate. Should there need to be inter-WG discussions do > raise the topic and work through it. I will be happy to help facilitate if > needed. > > Thanks > Terry > > On 19/06/2015 7:04 pm, "Benoit Claise" wrote: > > >Dear ANIMA chairs, Terry, > > > >[including more people in the cc list, to have a single discussion] > > > >Mehmet, NETCONF chairs, asked me this question: "I just would like to > >remind that I need to understand how the two activities are overlapping > >and how we should see and handle them." > >I'm not too sure how to answer, and I would like to get your opinion. > > > >Regards, Benoit > >> Hi Kent, Benoit, > >> > >> thank you for the update. > >> > >> I think we need to clarify how far the Bootstrap work is overlapping > >>with the NETCONF WG item ZeroTouch. > >> AFAIU it is defined to be more broad and as a result it is covering > >>most of the ZeroTouch goals. > >> > >> If there is indeed such overlapping which decimates the ZeroTouch draft > >>this I believe is not good. > >> > >> @Benoit: Please let us know how you think. > >> > >> Cheers, > >> Mehmet > >> > >> -----Original Message----- > >> From: ext Kent Watsen [mailto:kwatsen@juniper.net] > >> Sent: Tuesday, June 02, 2015 4:45 AM > >> To: netconf-chairs@tools.ietf.org > >> Subject: FW: [Anima] Call for Volunteer - ANIMA bootstrap design team > >> > >> > >> FYI - I want to contribute to this effort, but I also want to push > >> ZeroTouch over the finish line... Please advise. > >> > >> I assume doing so would weaken if not decimate the ZeroTouch draft, > >>though > >> the end solution may be better... > >> > >> Thanks, > >> Kent > >> > >> > >> On 6/1/15, 10:10 PM, "Toerless Eckert" wrote: > >> > >>> Dear all, > >>> > >>> we are calling for volunteers to form the bootstrap design team for > >>> ANIMA. We have selected two editors, Max Pritikin and Michael > >>>Richardson. > >>> The charter and goals for the bootstrap design team are outlined on its > >>> wiki page: > >>> > >>> http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap > >>> > >>> Because of the intended design team work, we expect that the design > >>>team > >>> members would need to spend at least half a day per week on this > >>>project > >>> for maybe 4..6 month, but it should become less afterwards. We would > >>>like > >>> to limit the design team to one year (or shorter if the goals are > >>>reached > >>> faster of course). > >>> > >>> As WG chairs we will participate and help of course in the design team > >>> primarily for logistics and alignment with other IETF effort. The > >>>design > >>> team discussions will be open to for all interested ANIMA participants > >>> even if they can not make the above time commtments. > >>> > >>> Please reply by end of the week if you are interested to contribute. If > >>> you > >>> are just interested to follow the work without commitment, please > >>> wait until we have created the mailing list. > >>> > >>> Thank you very much > >>> > >>> Sheng + Toerless > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >> . > >> From nobody Sun Jul 19 08:18:17 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7C1A8F3F for ; Sun, 19 Jul 2015 08:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BX3ys4lyErD for ; Sun, 19 Jul 2015 08:18:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3D61A8AB6 for ; Sun, 19 Jul 2015 08:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=879; q=dns/txt; s=iport; t=1437319095; x=1438528695; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Tj3Mg7PmU/cNJ7w0J7WQuDvtq0Tw0Isyyv9YMQoKx58=; b=coQHMQbgO9XEMdRLkR2tBSjLRo8uKNwppkKj0gVSubIHRu6CgvIPtMFq yJKOKYKe8OmZGtS+IW0gOHcyuv1a8s3MQwCcpnKNYrCLTkQFkAgtrhRnu X5cUnyDWpbUblR9HlJf07qnC6NRGqfhq2f2uQea4Zf+kfqjecslk7jtp6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwDCvqtV/4UNJK1TCYMTgT0Gu18Jh2wCgRs4FAEBAQEBAQGBCoQjAQEBBDpLBAIBCBEEAQELFAkHMhQJCAIEARIIiCbHJgEBAQEBAQEBAQEBAQEBAQEBAQEBGItMhCoDKDgGgxGBFAEElFIBpScmg3xvgQRDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,503,1432598400"; d="scan'208";a="12979356" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jul 2015 15:18:15 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6JFIE4u025979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Jul 2015 15:18:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.42]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sun, 19 Jul 2015 10:18:14 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] Scope question Thread-Index: AQHQt3syqJl/2MPkKkWdKxyAWCZwIp3N8YEAgBTqngA= Date: Sun, 19 Jul 2015 15:18:14 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF2300D45B@xmb-rcd-x14.cisco.com> References: <5599BF13.60405@gmail.com> <4529.1436144074@sandelman.ca> In-Reply-To: <4529.1436144074@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.90.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima-bootstrap] Scope question X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 15:18:16 -0000 > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: 06 July 2015 02:55 > To: anima-bootstrap@ietf.org > Subject: Re: [Anima-bootstrap] Scope question [...] > > 2. Is the scope limited to physical nodes? Or in other words, do > > entities like virtual machines or ASAs inherit credentials from the > > physical node containing them? >=20 > While I would expect ASAs running on a node to have some kind of access t= o > the hosts credentials, but we should consider possibility that we need to > issue additional (transitive) credentials to individual ASAs. Hmmm... Can you expand on that? So far I'm thinking of a node (virtual or r= eal) to have an identity, and an ASA in my mind is like an application. Whe= n would we need a cert for an ASA?=20 =20 Michael From nobody Wed Jul 22 00:33:54 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA4B1ACE29 for ; Wed, 22 Jul 2015 00:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0yQiLGYCPXk for ; Wed, 22 Jul 2015 00:09:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ECE51ACE22 for ; Wed, 22 Jul 2015 00:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10036; q=dns/txt; s=iport; t=1437548954; x=1438758554; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3gnjcPvOQEdSU96uAG/RUyarkMbtyFZOV6IVNCZZLw4=; b=JuE7uPUyJWCCGWrxgGpZfQESUL5zTcLRdr/jKV0hkIRHuCi295FWfZ56 pOXL7r+wcWu/ngUfb3fWdJoH3dRo7AoYMXrldgWZu/9rLZe2L/6TJI9Xp KcMLnkDLsVB3rvHFJ2CpDFPy9Q3b6KiAmVOJ7ejVzSk+z1/W8U890j8Og U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQDdQK9V/5BdJa1BFwOCSA8+VGkGvB8JdgV8hX8CgUM4FAEBAQEBAQGBCoQjAQEBAgItOSECAgEIEQQBAQsKBAwKGwYRHQcBAQEBAwESCIgRAxINPLpli0UNhS4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBItIgT0BgQ+BdRMhDAsRB4J/gRQFhwlPhgmGdgGEdIUUQYMrFYQHjAqDR4NhJoINHIEET28BgQMEP4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,521,1432598400"; d="scan'208,217";a="171142313" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 22 Jul 2015 07:09:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6M79DLZ025856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 07:09:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.112]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 02:09:12 -0500 From: "Michael Behringer (mbehring)" To: "Toerless Eckert (eckert)" , "Max Pritikin (pritikin)" , "Jason Coleman (colemaj)" , "mcr+ietf@sandelman.ca" , "ietf@sandeep.de" , "alper.yegin@yegin.org" , "jiangsheng@huawei.com" , "leo.liubing@huawei.com" , "brian.e.carpenter@gmail.com" , "kwatsen@juniper.net" , "anima-bootstrap@ietf.org" Thread-Topic: Weekly Webex invite for anima bootstrap team meeting Thread-Index: AdCq3XIOlfGppXwlS+iXiAzrSXhA3gZb8+tw Date: Wed, 22 Jul 2015 07:09:11 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9E@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0411@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0411@xmb-rcd-x14.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.45] Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9Exmbrcdx14ciscoc_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 00:33:42 -0700 Subject: Re: [Anima-bootstrap] Weekly Webex invite for anima bootstrap team meeting X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:09:17 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9Exmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are we having this meeting today, in person? Or is it cancelled? Michael -----Original Appointment----- From: Toerless Eckert (eckert) Sent: 20 June 2015 00:15 To: Toerless Eckert (eckert); Max Pritikin (pritikin); Jason Coleman = (colemaj); mcr+ietf@sandelman.ca; ietf@sandeep.de; Michael Behringer (mbehr= ing); alper.yegin@yegin.org; jiangsheng@huawei.com; leo.liubing@huawei.com;= brian.e.carpenter@gmail.com; kwatsen@juniper.net; anima-bootstrap@ietf.org Subject: Weekly Webex invite for anima bootstrap team meeting When: 22 July 2015 07:00-08:00 (UTC-08:00) Pacific Time (US & Canada)= . Where: Webex - Video/Audio So Wednesday 7 AM PST seems to be the best slot - it fits everybody e= xcept Brian and myself, and I think I can get the other meeting moved. Mich= ael Richardson also mentioned that we may be on/off 1 hour due to daylight = saving times, so let me shoot the meeting invite out here with outlook and = webex, and see if this still works for everybody else. Cheers Toerless -- Do not delete or change any of the following text. -- Join WebEx meeting Meeting number: 200 557 721 Meeting password: boot If you are the host, you can use the meeting host key to pass the hos= t privilege to another participant or to start the meeting from a video con= ferencing system or application. To find the host key for this meeting, go = here. Join by phone +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) Access code: 200 557 721 Global call-in numbers | Toll-free calling r= estrictions Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio an= d other information sent during the session to be recorded, which may be di= scoverable in a legal matter. By joining this session, you automatically co= nsent to such recordings. If you do not consent to being recorded, discuss = your concerns with the host or do not join the session.. --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9Exmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Are we having this meeting today, in person? O= r is it cancelled?
 
Michael
 
-----Original Appointment-----
From: Toerless Eckert (eckert)
Sent: 20 June 2015 00:15
To: Toerless Eckert (eckert); Max Pritikin (pritikin); Jason Coleman= (colemaj); mcr+ietf@sandelman.ca; ietf@sandeep.de; Michael Behringer (= mbehring); alper.yegin@yegin.org; jiangsheng@huawei.com; leo.liubing@huawei= .com; brian.e.carpenter@gmail.com; kwatsen@juniper.net; anima-bootstrap@ietf.org
Subject: Weekly Webex invite for anima bootstrap team meeting
When: 22 July 2015 07:00-08:00 (UTC-08:00) Pacific Time (US & Ca= nada).
Where: Webex - Video/Audio
 
 
 
So Wednesday 7 AM PST seems to be the best slot – it fits ever= ybody except Brian and myself, and I think I can get the other meeting move= d. Michael Richardson also mentioned that we may be on/off 1 hour due to daylight saving times, so let me shoot the meet= ing invite out here with outlook and webex, and see if this still works for= everybody else.

Cheers
    Toerless
 
 
-= - Do not delete or change any of the = following text. -- &= nbsp;
 
 
Join WebEx meeting  
Meeting number: 200 557 721 
Meeting password: boot 
 

If you are the host, you can use the meeting host key to pass the hos= t privilege to another participant or to start the meeting from a video con= ferencing system or application. To find the host key for this meeting, go here.

Join by = phone = ;
+1-866-432-9903 Call-in toll-free number (US/Canada)=  
+1-408-525-6800 Call-in toll number (US/Canada) 
Access code: 200 557 721 
Global call-in numbers<= /u>&nbs= p; |  Toll-free calling restrictions=   
 
 
Can't join the meeting? Contact support.  
 
IMPORTANT NOTICE: Please note that this WebEx service allows audio a= nd other information sent during the session to be recorded, which may be d= iscoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not c= onsent to being recorded, discuss your concerns with the host or do not joi= n the session..=
 
 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9Exmbrcdx14ciscoc_-- From nobody Wed Jul 22 00:33:56 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530301B2CDA for ; Wed, 22 Jul 2015 00:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdLXftJ6XtGq for ; Wed, 22 Jul 2015 00:31:44 -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 789041B2CA1 for ; Wed, 22 Jul 2015 00:31:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3FE3204F8; Wed, 22 Jul 2015 03:48:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B2EC863AEC; Wed, 22 Jul 2015 03:31:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9E1CD63AE8; Wed, 22 Jul 2015 03:31:41 -0400 (EDT) From: Michael Richardson To: "Michael Behringer (mbehring)" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9E@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0411@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9E@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 00:33:42 -0700 Cc: "Toerless Eckert \(eckert\)" , "ietf@sandeep.de" , "Max Pritikin \(pritikin\)" , "alper.yegin@yegin.org" , "leo.liubing@huawei.com" , "anima-bootstrap@ietf.org" , "kwatsen@juniper.net" , "Jason Coleman \(colemaj\)" , "jiangsheng@huawei.com" Subject: Re: [Anima-bootstrap] Weekly Webex invite for anima bootstrap team meeting X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:31:45 -0000 In the middle of IETF week? I think we aren't having the telecon! From nobody Wed Jul 22 00:33:57 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4438B1B2CE1 for ; Wed, 22 Jul 2015 00:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYq7TXlMuiJw for ; Wed, 22 Jul 2015 00:33:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86F91B2CDE for ; Wed, 22 Jul 2015 00:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=651; q=dns/txt; s=iport; t=1437550401; x=1438760001; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XUG5tzLHk9MoSbUuFW1gosv8DFNsHGpyfW5Wt69XWXc=; b=B8m6DlDIBB5RiOZ3PR4Wj2nAFQGcrfTDqLlcrEhqJVpaJFnMKZcL5s49 CuFInetCRD6SxjNDo6l8rY0kvbz6qCz49mTjuU2upfcpKS4Vuj5hFA4rN LI160dym4RFRWcaYlHc8pOzXUqFM/LldGzrvBoBgr2DpTqO+Z3z411kUT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQAHRq9V/4ENJK1bgxWBPQa8Aod2AoFEOhIBAQEBAQEBfwuEIwEBAQQ6PwwEAgEIEQQBAQsUCQchERQJCAEBBA4FCIgRAxLGag2FLgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIE9AYEPgggxBwaDEYEUAQSUVwGKSZNRhygmg3xvAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,521,1432598400"; d="scan'208";a="171085514" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 22 Jul 2015 07:33:21 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6M7XL7x011866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 07:33:21 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.112]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 02:33:20 -0500 From: "Michael Behringer (mbehring)" To: "mcr@sandelman.ca" Thread-Topic: Weekly Webex invite for anima bootstrap team meeting Thread-Index: AdCq3XIOlfGppXwlS+iXiAzrSXhA3gZb8+twAAtGroAACnGzQA== Date: Wed, 22 Jul 2015 07:33:20 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF23014C69@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0411@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9E@xmb-rcd-x14.cisco.com> <12335.1437550301@sandelman.ca> In-Reply-To: <12335.1437550301@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.213.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 00:33:43 -0700 Cc: "Toerless Eckert \(eckert\)" , "ietf@sandeep.de" , "Max Pritikin \(pritikin\)" , "alper.yegin@yegin.org" , "leo.liubing@huawei.com" , "anima-bootstrap@ietf.org" , "kwatsen@juniper.net" , "Jason Coleman \(colemaj\)" , "jiangsheng@huawei.com" Subject: Re: [Anima-bootstrap] Weekly Webex invite for anima bootstrap team meeting X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:33:23 -0000 The question is whether this is replaced by an on-site meeting, really.=20 Michael > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: 22 July 2015 09:32 > To: Michael Behringer (mbehring) > Cc: Toerless Eckert (eckert); Max Pritikin (pritikin); Jason Coleman (col= emaj); > ietf@sandeep.de; alper.yegin@yegin.org; jiangsheng@huawei.com; > leo.liubing@huawei.com; brian.e.carpenter@gmail.com; > kwatsen@juniper.net; anima-bootstrap@ietf.org > Subject: Re: Weekly Webex invite for anima bootstrap team meeting >=20 >=20 > In the middle of IETF week? > I think we aren't having the telecon! >=20 From nobody Wed Jul 22 01:02:58 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07E11ACE2C for ; Wed, 22 Jul 2015 00:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3-71Rnu5LBv for ; Wed, 22 Jul 2015 00:42:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212001B2D3B for ; Wed, 22 Jul 2015 00:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=938; q=dns/txt; s=iport; t=1437550924; x=1438760524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fx1s703cbHJhvLjQEuA73UZwb87ceC0n3KEGP3CTit8=; b=ZorcXkGtm7KbzAwjMhGGFbLl7q8QYee+13t/7+KKeRbD/NsmrmGZGZAu 8IqRpv8hmVxW8+nyl24aXsW6txva3Woe69cv8fsYEi8foPZZ2k9MuawXB I9AAZrCauJo8V6NNQqnPM4yjqySh+E3kgH0R9Fxv+CO6qXPPk8gWnrsZ7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQDcSK9V/4MNJK1cgxWBLg/DcwKBRDsRAQEBAQEBAYEKhCMBAQEDATo/BQcEAgEIEQQBAQEeCQchERQJCAEBBA4FiBkDCgjGaA2FLgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIE9AYEPggYzBwaDEYEUAQSUVwGKSYFokWmHKCaCGoFibwGCSgEBAQ X-IronPort-AV: E=Sophos;i="5.15,521,1432598400"; d="scan'208";a="11956637" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2015 07:42:04 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6M7g4vd023099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 07:42:04 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 02:42:03 -0500 From: "Max Pritikin (pritikin)" To: "Michael Behringer (mbehring)" Thread-Topic: Weekly Webex invite for anima bootstrap team meeting Thread-Index: AdCq3XIOlfGppXwlS+iXiAzrSXhA3gZb8+twAAtGroAACnGzQP//W4YZ Date: Wed, 22 Jul 2015 07:42:03 +0000 Message-ID: <7C09D11C-B722-4C90-B21E-F7AC94084159@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF0411@xmb-rcd-x14.cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF23014B9E@xmb-rcd-x14.cisco.com> <12335.1437550301@sandelman.ca>, <3AA7118E69D7CD4BA3ECD5716BAF28DF23014C69@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF23014C69@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 01:02:57 -0700 Cc: "Toerless Eckert \(eckert\)" , "ietf@sandeep.de" , "mcr@sandelman.ca" , "alper.yegin@yegin.org" , "leo.liubing@huawei.com" , "anima-bootstrap@ietf.org" , "kwatsen@juniper.net" , "Jason Coleman \(colemaj\)" , "jiangsheng@huawei.com" Subject: Re: [Anima-bootstrap] Weekly Webex invite for anima bootstrap team meeting X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 07:42:12 -0000 I assumed it was replaced by the onsite. =20 But if MCR wants to have a chance to chat (since he is remote) I'm open to = having a conversation.=20 - max > On Jul 22, 2015, at 9:33 AM, Michael Behringer (mbehring) wrote: >=20 > The question is whether this is replaced by an on-site meeting, really.=20 >=20 > Michael >=20 >> -----Original Message----- >> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] >> Sent: 22 July 2015 09:32 >> To: Michael Behringer (mbehring) >> Cc: Toerless Eckert (eckert); Max Pritikin (pritikin); Jason Coleman (co= lemaj); >> ietf@sandeep.de; alper.yegin@yegin.org; jiangsheng@huawei.com; >> leo.liubing@huawei.com; brian.e.carpenter@gmail.com; >> kwatsen@juniper.net; anima-bootstrap@ietf.org >> Subject: Re: Weekly Webex invite for anima bootstrap team meeting >>=20 >>=20 >> In the middle of IETF week? >> I think we aren't having the telecon! >=20 From nobody Wed Jul 22 05:54:23 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8023A1B330A for ; Wed, 22 Jul 2015 05:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pm_r-AGC9fY for ; Wed, 22 Jul 2015 05:54:16 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA941B330C for ; Wed, 22 Jul 2015 05:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47; q=dns/txt; s=iport; t=1437569645; x=1438779245; h=date:from:to:subject:message-id:mime-version; bh=ktKze9+T2z8DD0OEcctTciUxpIk7eej47k2Z0YGX6MA=; b=LA5c/Vty5Ll1d44fppkf9WGBu29RMqspTbHmYZj11APYsg7V4Zte8DPr MmlvXtLZsR2oH1ICfM84m0Qv+H2eH57Yg5f1Ta60ozoUdUkx+H47KonT1 iiy9OYk4S/R6czkMEmeCGHdP1EHfQajexPJEVQI8q2l7ajX2B/l1L298M 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AhAwD6ka9V/5FdJa1bgxWBPbt9CYlFOBQBAQEBAQEBgQqEQyF7NAVciC6mXaYWAQoBAQEekG+EFQWNK4csjDEBmRImhBweMYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="171214630" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP; 22 Jul 2015 12:53:46 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6MCrjHj031132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Jul 2015 12:53:45 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6MCriGZ031752 for ; Wed, 22 Jul 2015 05:53:44 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6MCriLT031750 for anima-bootstrap@ietf.org; Wed, 22 Jul 2015 05:53:44 -0700 Date: Wed, 22 Jul 2015 05:53:44 -0700 From: Toerless Eckert To: anima-bootstrap@ietf.org Message-ID: <20150722125344.GX1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Anima-bootstrap] test for anima-bootstrap X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:54:17 -0000 -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Jul 22 06:04:30 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47B1B333E for ; Wed, 22 Jul 2015 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQYB0X70999d for ; Wed, 22 Jul 2015 06:04:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE9C1B3341 for ; Wed, 22 Jul 2015 06:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38978; q=dns/txt; s=iport; t=1437570255; x=1438779855; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wAfpyK9Lhru4FLHiv6qWb4U2/XIvWnSTZvrFKOMjUtk=; b=mCviUCJ4bzx3eKdTq+K74wObWG3Eb/5n+iw47zIxSmAsM/2xvUgA0JO2 Unq9It7ZH0psFaaXAN1kPRylXoFAXrkx9XkRI5G43HIIWnmUB3d5Ge2u9 vy5XFfJr3nIu1IK+elEInSTMJRcrcMjbSySUzjomaC/4evzV6rrYl6VK2 c=; X-Files: draft-pritikin-anima-bootstrapping-keyinfra-diags.txt : 8771 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQDfk69V/4MNJK1RAQmDFVRpBoUmticqCYF3hB6BYQKBTTgUAQEBAQEBAX8LhCQBAQQaDUUCCxACAQg4BwcCMBQRAgQOBQ6IIA3MZwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIQpAQMOFBwWAQQHAgKDE4EUAQSHDo1JAYI1gj+CYIRdgUNGg1eLGIQ5g2ERFYFfgh1vAYEDQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="txt'?scan'208,217";a="17668189" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP; 22 Jul 2015 13:04:14 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6MD4Evh032000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 13:04:14 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 08:04:13 -0500 From: "Max Pritikin (pritikin)" To: "robert.cragie@gridmerge.com" Thread-Topic: [Anima] Ownership Concept Thread-Index: AQHQZn+Wm4eAxWuLS02QOiRijuPZe50siH6AgAErG4CAAORAgIAAqhaAgAAKs4CAAAlUAIAAbsyA///G6uSAA1+gAIACsoiAgAKxFICAsDW3gA== Date: Wed, 22 Jul 2015 13:04:13 +0000 Message-ID: References: <5511E12E.9050002@gmx.net> <5511E359.10600@gmail.com> <5512DE41.6030209@gmail.com> <77FA386512F0D748BC7C02C36EB1106D956D45@szxeml557-mbs.china.huawei.com> <7912.1427385447@sandelman.ca> <77FA386512F0D748BC7C02C36EB1106D95700F@szxeml557-mbs.china.huawei.com> <1F85BE1D-44A3-420A-8852-A4BA0DE213AC@cisco.com> <247ADDB2-807D-4AB5-A814-58381A929EB5@cisco.com> <551BC405.3070204@gridmerge.com> In-Reply-To: <551BC405.3070204@gridmerge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.205] Content-Type: multipart/mixed; boundary="_004_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima-bootstrap@ietf.org" , "Hedanping \(Ana\)" Subject: Re: [Anima-bootstrap] [Anima] Ownership Concept X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:04:28 -0000 --_004_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_ Content-Type: multipart/alternative; boundary="_000_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_" --_000_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Robert, good to meet you in person today. I=92m picking up this old thread = but any references I make concern the current version of the document as fo= und here: https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-02 The bootstrap design team wiki is here: http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap Please *please* feel free to join the mailing list and/or meetings. The fee= dback is appreciated even as I admit this thread petered out. I=92ve modifi= ed this thread to go to the bootstrap design team rather than anima at larg= e. Anyway, back to the thread, On Apr 1, 2015, at 12:10 PM, Robert Cragie > wrote: Hi Max, Thanks for your responses. Further responses inline, bracketed by Robert On 30/03/2015 18:03, Max Pritikin (pritikin) wrote: There are certainly cases where I can see this being used but conceptually = it is not much different to a whitelist on the registrar. The registrar is owned and operated by the domain owner. The cloud service = is not. I argue MASA substantially simplifies the threat model. I see now that the purpose of the MASA service is not online whitelist= ing, and the difference in the domain authority and the MASA. The only other operation it seems to do is to sign the domain certificate. = But the registrar could also do this - so I guess this is really combining = MASA and registrar in a single box. Either way, the NE has to have the doma= in public key, whether the MASA or the Registrar is authorised to issue dom= ain certificates on behalf of the Domain CA and any other public keys relev= ant to the certificate chain. The MASA does not sign certs So why is it called a "signing authority" then? Confusing. I can see i= t may sign authorisation tokes (see later). Correct, it is called the =93manufacturer authorized signing authority (MAS= A)=94 because it is signing something, the authorization token, using an au= thorized key issued by the manufacturer trust anchor. Understood. It signs the =93proof of logging=94 things we called =93authori= zation tokens=94. Please feel free to suggest terms that resonate. I think "authorization token" is fine. There needs to be more detail = on the process, that's all. So please explain the authorisation token in more detail and what leads to = its generation. This is a bit more than just logging. The authorization token contains a signed statement to the device indicatin= g that: a) the MASA is aware the device is joining this domain b) the MASA has logged information about how the device is joining this dom= ain (e.g. was a nonce involved) It would be entirely fair to call this some sort of =93proof of logging tok= en=94 instead of an authorization token! s4.1.2: NE only joins a domain if an authorization token is provided. This = behavior of the NE ensures that a log of the authorization token is also a = log of every time the NE joins a domain. OK s4.3.2: Registrar only allows the device to join the domain if the devices = history (e.g. the log information) doesn=92t show it has joined Mallory=92s= domain. Or, if the registar doesn=92t care, maybe it just doesn=92t check. I would imagine Mallory's purpose is to manipulate the joining to mak= e it look as if the NE didn't join Mallory's domain. Right. And the device refusing to join Mallory=92s domain until and =91auth= orization token=92 from the MASA server is presented provides a proof that = logging has captured this event. This directly mitigates the threat that Ma= llory attempts to manipulate the NE to join without this being logged. I see that the MASA check is auxiliary and optional The current draft indicates that MASA verification of Mallory=92s identity = is mandated when nonce-less tokens are requested. But that this is optional= the rest of the time with associated DoS risks as discussed in the securit= y considerations. I=92m totally open to improvements if we can meet the oth= er requirements. s4.3.3: Registrar MUST claim the device, obtaining an authorization token a= nd ensuring a log entry is generated, in order to get the device to trust i= t. OK As far as I can see (and please correct me if I am wrong), the Mallory/hone= ypot detection isn't really shown in Figure 1. See Figure 2 here: https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-02#= section-3 "[ still accept device?]=94 is a reference to the registrar verifying the l= og information, detecting Mallory and deciding what to do. The customer=92s= network can of course decide to ignore the security risk or to block the d= evice from joining. In figure1 note that =93device history log=94 and =93authorization token=94= are sent to the Domain from the MASA. The Domain then decides =93still acc= ept device?=94 based on the log information. This is the Registrar checking= for Mallory. If the log information shows an unknown/unexpected log entry = then Mallory has been detected. It is still the Domain=92s policy decision about continuing. For this to work, the NE would have to send details of the registrar it has= received, presumably relayed by the registrar itself (OCSP)? The logging information from the MASA provides information about previous d= omains the NE has joined. If Mallory has compromised the NE then we can=92t= depend on the NE to expose this information. Ummm=85 didn=92t follow you completely. I suggest keeping the log informati= on in the cloud and delivering it to the registrar from there because I don= =92t trust the NE to reveal that it is has been corrupted by Mallory. I think what is missing is that the request needs to come from the NE= and contain information about the Domain the NE thinks it is connecting to= as well as the NE. Otherwise Mallory could successfully act as MITM and co= nvince the NE that it is a legitimate domain. See attached diagrams. Then the MASA service sends a signed authorisation token back, attesting th= e validity of the Registrar. A honeypot would not be able to provide valid = credentials so at that point would fail. Correct, the Mallory domain would have to contact the MASA to obtain a sign= ed authorization token which ensures that the event has been logged. Diagram re-attached. In the MiTM diagram a couple of points stand out: a) the MiTM is acting exactly like the anima proxy b) the MiTM isn=92t engaged in the exchange with MASA so the resulting auth= orization is for the =91domain=92 not the =91MiTM=92 c) The NE will reject the "!!MD information!!=94 because it is not signed b= y the same Trust Anchor as is indicated in the authorization token d) Enrollment with the MiTM will similarly fail The MiTM in this diagram is ultimately blocked from gaining control of NE b= ut does successfully DoS the bootstrapping. Of course it could have done th= at by shipping packets to /dev/null (given the topology shown). Your suggestion to bind the domain identity (in the final diagram) also wor= ks to mitigate this threat. The reason I reject this, even though it is bet= ter at the mitigation, is that it prevents cases where the MASA service is = contacted in advance in this (abbreviated) flow: .. Domain=97=97> MASA .. Domain<=97 authz token MASA .. time passes, NE shipped NE=97> Domain [air gap] MASA unreachable NE<=97info Domain [air gap] MASA unreachable In this case the domain pre-fetches the MASA responses using the the noncel= ess method and can now present the token to the NE even when the MASA is un= reachable or out of business. If this isn=92t clear from the current doc it= sounds like expanding on this requirement is a good working group task (up= date to the doc is in order). Thanks again for the conversation, - max If a honeypot tried to use a honeypot MASA, it wouldn't have the private ke= y to sign the authorisation token so that would fail to. If the honeypot cl= aims the MASA is unreachable - another failure. So I agree, a good way to s= implify the threat model. Regarding the honeypot (Mallory) attack - the NE is going to find out it's = a honeypot as the honeypot will not be able to issue valid domain certifica= tes. The NE can't identify a "valid" domain certificate so I don't believe this = is correct. It could if it were pre-provisioned with the Registrar's public key an= d Domain CA public key. As you point out, in Section 2, "As a service offer= ing the MASA can incorporate many of the bootstrapping elements (such as th= e Registrar and the Domain CA) into the overall service." So surely in this= case, there is no separation of CAs? For any given domain one could do this. But it doesn=92t work at scale or i= f the target domain isn=92t known when the device leaves the vendor. All the more reason for the additional data needed at the beginning o= f the sequence (Domain ID sent to NE) Robert --_000_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <296BA2ABA9AA14459229909124C97653@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Robert, good to meet you in person today. I=92m picking up this old th= read but any references I make concern the current version of the document = as found here:

The bootstrap design team wiki is here:
Please *please* feel free to join the mailing list and/or meetings. Th= e feedback is appreciated even as I admit this thread petered out. I=92ve m= odified this thread to go to the bootstrap design team rather than anima at= large. 

Anyway, back to the thread, 

On Apr 1, 2015, at 12:10 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:

Hi Max,

Thanks for your responses. Further responses inline, bracketed by <RCC2&= gt;</RCC2>

Robert

On 30/03/2015 18:03, Max Pritikin (pritiki= n) wrote:

There are certainly cases where I can see this being used but conceptu= ally it is not much different to a whitelist on the registrar.

The registrar is owned and operated by the domain owner. The cloud ser= vice is not. I argue MASA substantially simplifies the threat model. <= /div>

<RCC>I see now that the purpose of the MASA service is not onlin= e whitelisting, and the difference in the domain authority and the MASA.<= ;/RCC>

The only other operation it seems to do is to sign the domain certific= ate. But the registrar could also do this - so I guess this is really combi= ning MASA and registrar in a single box. Either way, the NE has to have the= domain public key, whether the MASA or the Registrar is authorised to issue domain certificates on behalf= of the Domain CA and any other public keys relevant to the certificate cha= in.
The MASA does not sign certs

<RCC>So why is it called a "signing authority" then? C= onfusing. I can see it may sign authorisation tokes (see later).

Correct, it is called the =93manufacturer authorized signing authority= (MASA)=94 because it is signing something, the authorization token, using = an authorized key issued by the manufacturer trust anchor. 


Understood. It signs the =93proof of logging=94 things we called =93au= thorization tokens=94. Please feel free to suggest terms that resonate.
<RCC2>I think "authorization token" is fine. There needs to= be more detail on the process, that's all.</RCC2>
<RCC>
So please explain the authorisation token in more detail and what lead= s to its generation. This is a bit more than just logging.

The authorization token contains a signed statement to the device indi= cating that:
a) t= he MASA is aware the device is joining this domain
b) t= he MASA has logged information about how the device is joining this domain<= /div>
(e.g= . was a nonce involved)
It would be entirely fair to call this some sort of =93proof of loggin= g token=94 instead of an authorization token!

s4.1.2: NE only joins a domain if an authorization token is provided. = This behavior of the NE ensures that a log of the authorization token is al= so a log of every time the NE joins a domain.
<RCC2>OK</RCC2>

s4.3.2: Registrar only allows the device to join the domain if the dev= ices history (e.g. the log information) doesn=92t show it has joined Mallor= y=92s domain. Or, if the registar doesn=92t care, maybe it just doesn=92t c= heck.
<RCC2>I would imagine Mallory's purpose is to manipulate the joining = to make it look as if the NE didn't join Mallory's domain.

Right. And the device refusing to join Mallory=92s domain until and = =91authorization token=92 from the MASA server is presented provides a proo= f that logging has captured this event. This directly mitigates the threat = that Mallory attempts to manipulate the NE to join without this being logged.

I see that the MASA check is auxiliary and optiona= l</RCC2>

The current draft indicates that MASA verification of Mallory=92s iden= tity is mandated when nonce-less tokens are requested. But that this is opt= ional the rest of the time with associated DoS risks as discussed in the se= curity considerations. I=92m totally open to improvements if we can meet the other requirements. 


s4.3.3: Registrar MUST claim the device, obtaining an authorization to= ken and ensuring a log entry is generated, in order to get the device to tr= ust it.
<RCC2>OK</RCC2>

As far as I can see (and please correct me if I am wrong), the Mallory= /honeypot detection isn't really shown in Figure 1.

See Figure 2 here:

"[ still accept device?]=94 is a reference to the registrar verif= ying the log information, detecting Mallory and deciding what to do. The cu= stomer=92s network can of course decide to ignore the security risk or to b= lock the device from joining. 


In figure1 note that =93device history log=94 and =93authorization tok= en=94 are sent to the Domain from the MASA. The Domain then decides =93stil= l accept device?=94 based on the log information. This is the Registrar che= cking for Mallory. If the log information shows an unknown/unexpected log entry then Mallory has been detected. 

It is still the Domain=92s policy decision about continuing. 
For this to work, the NE would have to send details of the registrar i= t has received, presumably relayed by the registrar itself (OCSP)?

The logging information from the MASA provides information about previ= ous domains the NE has joined. If Mallory has compromised the NE then we ca= n=92t depend on the NE to expose this information. 


Ummm=85 didn=92t follow you completely. I suggest keeping the log info= rmation in the cloud and delivering it to the registrar from there because = I don=92t trust the NE to reveal that it is has been corrupted by Mallory.
<RCC2>I think what is missing is that the request needs to come from = the NE and contain information about the Domain the NE thinks it is connect= ing to as well as the NE. Otherwise Mallory could successfully act as MITM = and convince the NE that it is a legitimate domain. See attached diagrams.</RCC2>
Then the MASA service sends a signed authorisation token back, attesti= ng the validity of the Registrar. A honeypot would not be able to provide v= alid credentials so at that point would fail.

Correct, the Mallory domain would have to contact the MASA to obtain a= signed authorization token which ensures that the event has been logged.&n= bsp;

Diagram re-attached. 

In the MiTM diagram a couple of points stand out:
a) the MiTM is acting exactly like the anima proxy
b) the MiTM isn=92t engaged in the exchange with MASA so the resulting= authorization is for the =91domain=92 not the =91MiTM=92
c) The NE will reject the "!!MD information!!=94 because it is no= t signed by the same Trust Anchor as is indicated in the authorization toke= n
d) Enrollment with the MiTM will similarly fail

The MiTM in this diagram is ultimately blocked from gaining control of= NE but does successfully DoS the bootstrapping. Of course it could have do= ne that by shipping packets to /dev/null (given the topology shown). <= /div>

Your suggestion to bind the domain identity (in the final diagram) als= o works to mitigate this threat. The reason I reject this, even though it i= s better at the mitigation, is that it prevents cases where the MASA servic= e is contacted in advance in this (abbreviated) flow:

.. D= omain=97=97> MASA
.. D= omain<=97 authz token MASA
.. time passes, NE shipped
NE=97> <= /span>Domain [air gap] MASA unreachable
NE<=97info Domain [air gap] MASA unreachable
In this case the domain pre-fetches the MASA responses using the the n= onceless method and can now present the token to the NE even when the MASA = is unreachable or out of business. If this isn=92t clear from the current d= oc it sounds like expanding on this requirement is a good working group task (update to the doc is in order).<= /div>

Thanks again for the conversation, 

- max


If a honeypot tried to use a honeypot MASA, it wouldn't have the priva= te key to sign the authorisation token so that would fail to. If the honeyp= ot claims the MASA is unreachable - another failure. So I agree, a good way= to simplify the threat model.
</RCC>
 

Regarding the honeypot (Mallory) attack - the NE is going to find out = it's a honeypot as the honeypot will not be able to issue valid domain cert= ificates.

The NE can't identify a "valid" domain certificate so I don'= t believe this is correct. 

<RCC>It could if it were pre-provisioned with the Registrar's pu= blic key and Domain CA public key. As you point out, in Section 2, "As= a service offering the MASA can incorporate many of the bootstrapping elem= ents (such as the Registrar and the Domain CA) into the overall service." So surely in this case, there is no se= paration of CAs?</RCC> 

For any given domain one could do this. But it doesn=92t work at scale= or if the target domain isn=92t known when the device leaves the vendor.
<RCC2>All the more reason for the additional data needed at the begin= ning of the sequence (Domain ID sent to NE)</RCC2>

Robert
<draft-pritikin-anima-bootstrapping-keyinfra-diags.txt><= /blockquote>
--_000_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_-- --_004_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_ Content-Type: text/plain; name="draft-pritikin-anima-bootstrapping-keyinfra-diags.txt" Content-Description: draft-pritikin-anima-bootstrapping-keyinfra-diags.txt Content-Disposition: attachment; filename="draft-pritikin-anima-bootstrapping-keyinfra-diags.txt"; size=8771; creation-date="Wed, 22 Jul 2015 13:04:13 GMT"; modification-date="Wed, 22 Jul 2015 13:04:13 GMT" Content-ID: Content-Transfer-Encoding: base64 ICAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLSsNCiAgIHwgIE5ldyAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICAgICAgICB8ICBNQVNBICAgICB8DQogICB8IEVudGl0eSAgfCAgICAgICAgICAg ICAgICB8ICBEb21haW4gIHwgICAgICAgICAgICAgICAgfCAgU2VydmljZSAgfA0KICAgfCAgICAg ICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgKEludGVy bmV0KXwNCiAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHw8LS0tLS0tLWRpc2NvdmVy eS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8LS0tODAy LjFBUiBjcmVkZW50aWFsLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgIFsgYWNjZXB0IGRldmljZT8gXSAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwtLS04MDIuMUFSIGlkZW50aXR5LS0tLS0tLS0+fA0KICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICB8LS0tRG9tYWluIElELS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIFtk ZXZpY2UgYmVsb25nc10NCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgW3RvIGRvbWFpbj8gICAgXQ0KICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIFt1cGRhdGUgYXVkaXQgbG9n XQ0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS1kZXZp Y2UgaGlzdG9yeSBsb2ctLS0tLS18DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHw8LS0gYXV0aG9yaXphdGlvbiB0b2tlbi0tLS0tfA0KICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAg ICAgICAgICAgICAgWyBzdGlsbCBhY2NlcHQgZGV2aWNlP10gICAgICAgICAgICAgICB8DQogICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgIHw8LS0tLWF1dGhvcml6YXRpb24gdG9rZW4tLS18ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICB8PC0tLS1kb21haW4gaW5mb3JtYXRpb24tLS0tfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICBbYXV0aCB0b2tlbiB2YWxpZD9d ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgfC0tLS1kb21haW4gZW5yb2xtZW50LS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgIHw8LS0tLWRvbWFpbiBjZXJ0aWZpY2F0ZS0tLS18ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K DQpDdXJyZW50IG1vZGVsLiBJc3N1ZSBpcyB0aGF0IGEgTUlUTSBjb3VsZCBzcG9vZiBpdHNlbGYg YXMgYSB2YWxpZCBkb21haW4gZHVlIHRvIHRoZSBsaW1pdGVkIGFiaWxpdHkgb2YgdGhlIE5FIHRv IGNoZWNrOg0KDQogICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICAg ICAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKw0KICAg fCAgTmV3ICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAg ICAgICAgICB8ICAgICAgICAgICAgICAgIHwgIE1BU0EgICAgIHwNCiAgIHwgRW50aXR5ICB8ICAg ICAgICAgICAgICAgIHwgICBNSVRNICAgfCAgICAgICAgICAgICAgIHwgIERvbWFpbiAgfCAgICAg ICAgICAgICAgICB8ICBTZXJ2aWNlICB8DQogICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAo SW50ZXJuZXQpfA0KICAgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCiAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHw8LS0tLS0tLWRpc2Nv dmVyeS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgfC0tLTgwMi4xQVIgY3JlZGVudGlhbC0tLS0tPnwgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQog ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS04MDIuMUFSIGNyZWRlbnRpYWwt LS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgWyBhY2NlcHQgZGV2aWNlPyBdICAg ICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICB8LS0tODAyLjFBUiBpZGVudGl0eS0tLS0tLS0tPnwNCiAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS1Eb21haW4gSUQt LS0tLS0tLS0tLS0tLS0+fA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICBbZGV2aWNlIGJlbG9uZ3NdDQogICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICBbdG8gZG9tYWluPyAgICBdDQogICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICBbdXBkYXRlIGF1ZGl0IGxvZ10N CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS1kZXZpY2Ug aGlzdG9yeSBsb2ctLS0tLS18DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tIGF1dGhvcml6YXRpb24gdG9rZW4tLS0tLXwN CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgWyBzdGlsbCBhY2NlcHQgZGV2aWNl P10gICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tYXV0aG9yaXphdGlvbiB0 b2tlbi0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICB8PC0tLS1kb21haW4gaW5mb3JtYXRpb24tLS0tfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgfDwtLS0tYXV0aG9yaXphdGlvbiB0b2tlbi0tLXwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICB8PC0tLS0tISFNRCBpbmZvcm1hdGlvbiEhLS0tfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogIFthdXRoIHRva2VuIHZhbGlkP10gICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwtLS0tZG9tYWlu IGVucm9sbWVudC0tLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgfDwtLS0tISFNRCBjZXJ0aWZpY2F0ZSEhLS0tLXwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQpNRDogTWFsbG9yeSBEb21h aW4NClRoaXMgY2FuIGJlIGZpeGVkIGJ5IGJpbmRpbmcgdGhlIERvbWFpbiBJRCB3aXRoIHRoZSBO RSBJRCBhbmQgc2VuZGluZyBib3RoIHRvIE1BU0Egc2VydmljZSwgb3JpZ2luYXRpbmcgZnJvbSB0 aGUgTkUuIFRoaXMgbGltaXRzIHRoZSBSZWdpc3RyYXIgdG8gYSBwYXNzLXRocm91Z2ggc2Vydmlj ZSAoaXQgY2FuIGF1Z21lbnQgdGhlIGZsb3cgd2l0aCBpdHMgb3duIERvbWFpbiBJRCkuIE1BU0Eg Y2FuIHRoZW4gY2hlY2sgYSkgdGhlIE5FIGlzIHZhbGlkLCBiKSB0aGUgRG9tYWluIHRoZSBORSBp cyBpbiBjb250YWN0IHdpdGggaXMgdmFsaWQgYW5kIGMpIHRoZSBEb21haW4gaXQgcmVjZWl2ZWQg dGhlIHJlcXVlc3QgZnJvbSBpcyB2YWxpZC4NCg0KICAgICAgIA0KICAgKy0tLS0tLS0tLSsgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCiAg IHwgIE5ldyAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICB8 ICBNQVNBICAgICB8DQogICB8IEVudGl0eSAgfCAgICAgICAgICAgICAgICB8ICBEb21haW4gIHwg ICAgICAgICAgICAgICAgfCAgU2VydmljZSAgfA0KICAgfCAgICAgICAgIHwgICAgICAgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgKEludGVybmV0KXwNCiAgICstLS0tLS0t LS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgIHw8LS0tLS0tLWRpc2NvdmVyeS0tLS0tLS0tLT58ICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8PC0tLURvbWFpbiBJRC0tLS0tLS0tLS0t LS0tfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwtLS04 MDIuMUFSIGNyZWRlbnRpYWwtLS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICB8LS0tQm91bmQgRG9tYWluIElELS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgIFsgYWNjZXB0IGRl dmljZT8gXSAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwtLS04MDIuMUFSIGlkZW50aXR5LS0tLS0tLS0+fA0KICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8LS0tQm91bmQgRG9tYWluIElELS0tLS0tLS0tPnwN CiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLURvbWFpbiBJRC0tLS0tLS0t LS0tLS0tLT58DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICBbZGV2aWNlIGJlbG9uZ3NdDQogICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIFt0byBkb21haW4/ICAgIF0NCiAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICBbdXBkYXRlIGF1ZGl0IGxvZ10NCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgIHw8LS0tZGV2aWNlIGhpc3RvcnkgbG9nLS0tLS0tfA0KICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC0tLUJvdW5kIERvbWFpbiBJRC0tLS0tLS0tLXwNCiAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS1Eb21haW4gSUQtLS0tLS0tLS0t LS0tLS18DQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0gYXV0aG9yaXph dGlvbiB0b2tlbi0tLS0tfA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAgWyBz dGlsbCBhY2NlcHQgZGV2aWNlP10gICAgICAgICAgICAgICB8DQogICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHw8 LS0tLUJvdW5kIERvbWFpbiBJRC0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICB8PC0tLS1Eb21haW4gSUQtLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgfDwtLS0tYXV0aG9yaXphdGlvbiB0b2tlbi0tLXwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHw8LS0tLWRvbWFpbiBpbmZvcm1hdGlvbi0tLS18 ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogIFthdXRoIHRva2VuIHZh bGlkP10gICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICB8LS0tLWRvbWFpbiBlbnJvbG1lbnQtLS0tLS0+fCAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgfDwtLS0tZG9tYWluIGNlcnRpZmljYXRlLS0tLXwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICANCkknbSBub3Qgc3VyZSBh bGwgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBsYXRlciBmbG93cyBpcyByZXF1aXJlZCBidXQgdGhl IEJvdW5kIERvbWFpbiBJRCBpcyB0aGUgaW1wb3J0YW50IGFkZGl0aW9uLiAgICAgICA= --_004_C82C1BC28B35444B9D5EACB650F8B90Cciscocom_-- From nobody Wed Jul 22 06:44:27 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07E51B2DA8; Wed, 22 Jul 2015 06:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idiwENlnhJWU; Wed, 22 Jul 2015 06:44:23 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985CD1A6FF1; Wed, 22 Jul 2015 06:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=844; q=dns/txt; s=iport; t=1437572663; x=1438782263; h=date:from:to:subject:message-id:mime-version; bh=hblbTQGxE3voxlxdbNatNDXBR1/JtV9hFpL0LnGHSxc=; b=hgoO+pgMtFVeZpijpEOrSrNsmxwuIWLrpu8oHDwNd2pzE3pmvaxMCw6r pjN3zXbxfJl/ycUEZAtuE2EgWd8cLrjOGil9GbihzwtsHmf4HM4fFM8nK gle/e92FQlh0v+eG6oGZe6+ndgCL0FjJg8zMAUdWEBUdA5Rrztzwso7xB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGBQC2na9V/40NJK1bgxXHCjwQAQEBAQEBAYEKhGQ0RzQFSohAzRgBAQEBBgEBAQEBARyPbxACAYNugRQFjSuHLIwxAZkSJoQcHoJ8AQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="170785709" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 22 Jul 2015 13:44:22 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6MDiMcM009057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2015 13:44:22 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id t6MDiLqi002309; Wed, 22 Jul 2015 06:44:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t6MDiLmI002308; Wed, 22 Jul 2015 06:44:21 -0700 Date: Wed, 22 Jul 2015 06:44:21 -0700 From: Toerless Eckert To: anima-bootstrap@ietf.org, anima@ietf.org Message-ID: <20150722134421.GC1667@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Anima-bootstrap] administrativa: anima-bootstrap: mailing list "issue" fixed X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:44:25 -0000 I saw a couple of messages bounce that where sent to anima-bootstrap including one i had sent myself. This is fixed now. There are two common problems with IETF mailing lists: You send an email to a list you're not subscribed and get a bounce. This is fixed by putting the "global whitelist" into the mailing list, that the list of all email addresses used in any IETF mailing list. You send an email and it gets bounced...because there where too many To/Cc on the mail. Happens easily after you group-reply to a longer thread where recipients start to add up on every reply - as well as on webex-invites where everybody who ever accepted the meeting is also tracked. This is now fixed on all anima maling list by having raised the cailing where this policy kicks in. Default was too low (< 10). Cheers Toerless From nobody Wed Jul 22 08:30:15 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60D01B2EB8 for ; Wed, 22 Jul 2015 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3HUmacErhyk for ; Wed, 22 Jul 2015 05:03:32 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A059F1B2EB4 for ; Wed, 22 Jul 2015 05:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7341; q=dns/txt; s=iport; t=1437566612; x=1438776212; h=from:to:subject:date:message-id:mime-version; bh=vlNkRjo58a9Z9HnGF7SYvGnPE2Mr/Oww/3ZRQJRyZFU=; b=f4suq9dg4bQDlzQEDepWeFRtAh+Snz3wI+Kj7Frj5+9YWgC82EUbjCih IKNi9tFSTGlGsthnMbJJpioKDXdrXHSCHMjHyBvgou9AZoAL153qDf5Vm mq+PH0FSwGH9xV1QeMmv9ji94vlhUMQ+5yl41wUIVDKoJPQGyFMIVHFLm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGAQB8ha9V/5RdJa1BFwOCSA8+VGkGu3cJdgV8hX+BTjgUAQEBAQEBAYEKhCMBAgICZiEEAQgVAhUEDAMiFxQJBwMBAwESiC4NPLp4kQcBAQEBAQEEAQEBAQEBARsEi0iBPQGDBDQMHAeEEwWHWIx/AYR0hRSCKYFDFYQIj1GDYSaCDQ0PgQRPbwGBRoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208,217";a="171098780" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2015 12:03:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6MC3Vbb012063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 12:03:31 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.77]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 07:03:31 -0500 From: "Toerless Eckert (eckert)" To: "Max Pritikin (pritikin)" , "Jason Coleman (colemaj)" , "mcr+ietf@sandelman.ca" , "ietf@sandeep.de" , "Michael Behringer (mbehring)" , "alper.yegin@yegin.org" , "jiangsheng@huawei.com" , "leo.liubing@huawei.com" , "brian.e.carpenter@gmail.com" , "kwatsen@juniper.net" , "anima-bootstrap@ietf.org" Thread-Topic: Weekly Webex invite for anima bootstrap team meeting Thread-Index: AQHQxHZtlfGppXwlS+iXiAzrSXhA3g== Date: Wed, 22 Jul 2015 12:03:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.24.110.131] Content-Type: multipart/alternative; boundary="_000_D1D5533E775F0eckertciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2015 08:30:13 -0700 Subject: Re: [Anima-bootstrap] Weekly Webex invite for anima bootstrap team meeting X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:03:34 -0000 --_000_D1D5533E775F0eckertciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have no competing meeting during this slot. I'll be happy to dial into th= e meeting to Sync with MichaelR. Any chance to find a room with a phone so we can sit to= gether ? From: eckert@cisco.com When: 4:00 PM - 5:00 PM July 22, 2015 Subject: Weekly Webex invite for anima bootstrap team meeting Location: Webex - Video/Audio So Wednesday 7 AM PST seems to be the best slot ? it fits everybody except = Brian and myself, and I think I can get the other meeting moved. Michael Ri= chardson also mentioned that we may be on/off 1 hour due to daylight saving= times, so let me shoot the meeting invite out here with outlook and webex,= and see if this still works for everybody else. Cheers Toerless -- Do not delete or change any of the following text. -- Join WebEx meeting Meeting number: 200 557 721 Meeting password: boot If you are the host, you can use the meeting host key to pass the host priv= ilege to another participant or to start the meeting from a video conferenc= ing system or application. To find the host key for this meeting,go here. Join by phone +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) Access code: 200 557 721 Global call-in numbers | Toll-free calling restric= tions Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session.. --_000_D1D5533E775F0eckertciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <70989B6503586A43A15AB88B0006863F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I have no competing meeting during this slot. I'll be happy to dial in= to the meeting to
Sync with MichaelR. Any chance to find a room with a phone so we can s= it together ?

From: eckert@cisco.com
When: 4:00 PM - 5:00 PM July 22, 20= 15
Subject: Weekly Webex invite for an= ima bootstrap team meeting
Location: Webex - Video/Audio


So Wednesday 7 AM PST seems to be the best slot ? it fits everybody ex= cept Brian and myself, and I think I can get the other meeting moved. Micha= el Richardson also mentioned that we may be on/off 1 hour due to daylight s= aving times, so let me shoot the meeting invite out here with outlook and webex, and see if this still work= s for everybody else.

Cheers
    Toerless
 
 
-- Do not delete or change any= of the following text. --  
 
 
Join WebEx meeting  
Meeting number: 200 557 7= 21 
Meeting password: = boot 
 

If you are the host, you = can use the meeting host key to pass the host privilege to another particip= ant or to start the meeting from a video conferencing system or application= . To find the host key for this meeting,go here.

Join by phone 
+1-866-432-99= 03 Call-in toll-free number (US/Canada) 
+1-408-525-68= 00 Call-in toll number (US/Canada) 
Access code: 200 557 721<= /font> 
Global call-in numbers  |  Toll-free calling restrictions  
 
 
Can't join the meeting? Contact support.  
 
IMPORTANT NOTICE: Please = note that this WebEx service allows audio and other information sent during= the session to be recorded, which may be discoverable in a legal matter. B= y joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discu= ss your concerns with the host or do not join the session..
--_000_D1D5533E775F0eckertciscocom_-- From nobody Thu Jul 23 05:21:12 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE71A92EE for ; Thu, 23 Jul 2015 05:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HxjdlCKzYKd for ; Thu, 23 Jul 2015 05:21:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5811A0BE8 for ; Thu, 23 Jul 2015 05:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=472; q=dns/txt; s=iport; t=1437653994; x=1438863594; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=w42/WfLIKoLLLFM7wDkdhrjR/jVfH1RF09fuvYYunRs=; b=bXAQD705fg+5vJF6/TcPNjXnLQgTqvpyxKxerbag6TtyeT0MjTQSltBl tIKjnG6KJJEzeT1KMUWFtuVj4qV6V+Z422RVGwBc8RQV4mQSiiU/aQxV+ iuGvD2cwbPSB1o5Zj8JZZlui8xQy4oTuHlgndxIdVRAYHY8ae7oFLe4n2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AkAwCK27BV/5tdJa1cgxVUaQa7VwmBdYdLOBQBAQEBAQEBfwuEKAIdHVEBPkInBIhBDaUupX8BAQEBAQUBAQEBAQEBARYEk3GBFAWUYAGMOZkbJmODGW8BgUaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,530,1432598400"; d="scan'208";a="12359538" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2015 12:19:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6NCJsGm002203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 12:19:54 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 07:19:53 -0500 From: "Max Pritikin (pritikin)" To: "anima-bootstrap@ietf.org" Thread-Topic: Lack of automated EAP configuration Thread-Index: AQHQxUHhtGe8SwY5IkCcqrPHcsSk9A== Date: Thu, 23 Jul 2015 12:19:53 +0000 Message-ID: <67989C82-474F-47BB-A0E4-35FE3CA0FF73@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.106.241] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima-bootstrap] Lack of automated EAP configuration X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 12:21:08 -0000 Folks this was presented at saag today: https://www.ietf.org/proceedings/93/slides/slides-93-saag-1.pdf This is a call for a bootstrapping config method for enterprise EAP use cas= es, with a pointer to existing XML based config files.=20 This is weakly related to our discussions and at least being aware would fi= t in our charter directive to work with other IETF groups. (Not sure if the= re is an action for us at this point, just sharing).=20 - max= From nobody Mon Jul 27 18:22:00 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC421A8F50; Sun, 26 Jul 2015 17:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_24_48=1.34, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 H5LXOcczS-hg; Sun, 26 Jul 2015 17:58:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE691A8F3A; Sun, 26 Jul 2015 17:58:42 -0700 (PDT) Received: from sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 5524122085; Sun, 26 Jul 2015 20:58:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 2FE9C627D7; Sat, 25 Jul 2015 20:51:42 -0400 (EDT) From: Michael Richardson To: Malisa Vucinic In-reply-to: <5507CADA-01BA-45AA-A76F-2A13D5B54BDA@imag.fr> References: <5507CADA-01BA-45AA-A76F-2A13D5B54BDA@imag.fr> Comments: In-reply-to Malisa Vucinic message dated "Fri, 15 May 2015 18:21:42 -0700." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 X-Attribution: mcr MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 25 Jul 2015 20:51:42 -0400 Message-ID: <15927.1437871902@dooku.sandelman.ca> Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 18:21:59 -0700 Cc: Thomas Watteyne , 6tisch@ietf.org Subject: Re: [Anima-bootstrap] [6tisch] questions about draft-richardson-security-6top X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2015 00:58:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Malisa Vucinic wrote: > [the rest of the discussion shifted to [6tisch] joining security start > and end states] hi, sorry to take so long to reply.... I'm sure you have the same experience of putting off the most important emails, because they deserve a well thoug= ht out response...=20=20 > On 13 May 2015, at 09:43, Michael Richardson = wrote: >> So, here, I think you are imagining using some kind of pre-provision= ed >> session-resumption ticket to replace the initial TLS handshake. I >> think that this is something that one could imagine: the initial TLS >> handshake is done at the factory, and then, based upon a bearer toke= n, >> the factories' MASAS (see >> draft-pritikin-anima-bootstrapping-keyinfra-01) might return that. = Is >> this what you are thinking about? > So this would be a clean way of doing what I had in mind. I guess an > obvious concern in this case would be how the initial TLS handshake c= an > be done at the factory during mass production in a scalable manner. I think it depends a lot on what part of the "factory" you are in. How do factories' load "Manufacturer Installed Certificates" (often called: MIC. Too confusing a term. We need another TLA for this) now? If my manufacturing process included a "bed-of-nails" test, then I might do it at that point via JTAG, otherwise, doing it via JTAG during or after the QA process seems like the best way to me. Being able to have the device zerotouch boot the first time might be a major win for the QA process too. > I was thinking more of something like this: > Consider the joining node JN_1 which was imprinted with symmetric key > K_1. MASA keeps track which JNs were imprinted with which keys. MASA > and all of its nodes use the recommended ticket format from Section 4 > of RFC 5077. Nodes get shipped, deployed. > 1. JN_1 initiates the join process with the local network, sends its > IDevID via JA to the JCE. > 2. JCE asks MASA about JN_1 over https. MASA=E2=80=99s factory sold t= he nodes > to the owner of JCE so MASA already knows that JCE is the rightful > owner of JN_1. > 3. Then, MASA can generate 48 random bytes to be used as the master > secret for session between JCE and JN_1. Obviously, MASA is a trusted > third party. MASA generates the rest of the ticket, using as key_name > the fingerprint of K_1 and also includes the cipher suite knowing what > ciphers JN_1 supports, as it manufactured it after all. MASA encrypts > the ticket using K_1. > 4. MASA sends to the JCE the encrypted ticket and the plaintext versi= on > of it (this is what an RFC 5077 client possesses anyways, it does > however not know K_1). > 5. JCE can now start the abbreviated handshake with JN_1, including t= he > encrypted ticket in ClientHello. > 6. JN_1 decrypts the ticket using K_1, takes the session state from t= he > ticket as normally done in RFC 5077 and verifies that it supports the > cipher. Then it can continue the abbreviated handshake with JCE. This would all work well. The 5077/Section 4 format does not include any information about the end point identifiers, so that's fine. All in all, it's very Kerberos-like. > If MASA decides to share K_1 with JCE, JCE can also generate the > session ticket without any involvement of MASA. All in all, by making > an assumption on out-of-band exchange of supported ciphers and MASA as > a trusted third party, I think one could get the DTLS handshake done = in > 4-6, instead of 10-12 packets. Does that make sense and do you think = it > is worth the trouble? One can go further, and provide K_1 in the form of a QR code with the devic= e. Or one can provide a bearer token in the QR code, which when provided to the MASA, convinces the MASA to either hand over K_1, or as you suggested, hand over the session resumption ticket. My understanding of Quantum Cryptography is not great; but I what I understand is that asymmetric algorithms (RSA, ECDSA) are more susectible. As K_1 would be the key to a symmetric algorithm, it might be less vulnerab= le over a long (~20 year) time frame between the device being manufacturered, being warehoused, and then deployed. A concern with 1/2 is that the device does not have to prove it (still) possesses the private part of the IDevID. Instead, K_1 has replaced that. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVtC8cAAoJEKD0KQ7Gj3P2BxQIALs3GMSVjeJLx0h5UtOX+TN/ aFdOLL/Q8/Sem2SfhCHNjlb43yBPxyqV/NVj/NHCQz+LgX+0IH5NGMauBPqG76Uv qSHK2prkWpcUcRpyicg7QQ59gNNjtiD/yugVKWYdswIi1zxNZkFO3Q92lTp+StQ1 cLhMw0HA/EixbSbf86ebnIoNZyfXXBTCwJ1wG6EW4Pje/MR7itsLQ1L4S2GG3XZf QOovpOjpCKPnDdWZWN1o6SDKQ5H0c2grjcU1VtR5Gn+7oemEHnJaue5kJEG8zYc9 qF1WNYJknZ+iUi/dZW4islCRG7ndjUr5PV5okCwmM+B0uP8VFJxkhBMidP6Bg/Y= =5uJU -----END PGP SIGNATURE----- --=-=-=--