From nobody Tue Jun 23 21:00: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 935B11B328A for ; Tue, 23 Jun 2015 21:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 TmkReWADEPzR for ; Tue, 23 Jun 2015 21:00:10 -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 B9DBD1B3289 for ; Tue, 23 Jun 2015 21:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2; q=dns/txt; s=iport; t=1435118411; x=1436328011; h=date:from:to:subject:message-id:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=fi1x5f/oaD1vtSZKFTRSiSIkyvt6MLkUQS20q3/Kvlr64mGscDMWVp/C VeILKeSTUUZnrj1V7yx0ORbrmtxJmXEa+iTy+HAy7fPkC+BKbQ5NcB6CH UhMKSh2gdFcbdosSrdCwhyQ+IqRvx9mSPZDxrEQP8gwkFCHMwixIvFSGI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcCgBpKopV/5RdJa1bgxCGOrhrCYkkOBQBAQEBAQEBgQYEhEIhNEc0BYkLpn6WBpAdAQEBBwEBAQEBHZBtgwGBFAWMfYcCi1ABmDUmhBoegnkBAQE X-IronPort-AV: E=Sophos;i="5.13,669,1427760000"; d="scan'208";a="9791289" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jun 2015 04:00:10 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5O409LV003188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jun 2015 04:00:09 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 t5O4084i024845 for ; Tue, 23 Jun 2015 21:00:09 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t5O408BC024843 for anima-bootstrap@ietf.org; Tue, 23 Jun 2015 21:00:08 -0700 Date: Tue, 23 Jun 2015 21:00:08 -0700 From: Toerless Eckert To: anima-bootstrap@ietf.org Message-ID: <20150624040008.GF27147@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 mailing-list/archive 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, 24 Jun 2015 04:00:11 -0000 From nobody Wed Jun 24 07:07: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 00DAC1A92E7 for ; Wed, 24 Jun 2015 07:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 vWdKptHoF3DZ for ; Wed, 24 Jun 2015 07:07:33 -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 8C0B71A92F4 for ; Wed, 24 Jun 2015 07:06:30 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 663B82002A for ; Wed, 24 Jun 2015 10:21:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9EEDF63AE8; Wed, 24 Jun 2015 10:06:29 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 864C563AD9 for ; Wed, 24 Jun 2015 10:06:29 -0400 (EDT) From: Michael Richardson To: anima-bootstrap@ietf.org X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Jun 2015 10:06:29 -0400 Message-ID: <11466.1435154789@sandelman.ca> Sender: mcr@sandelman.ca Archived-At: Subject: [Anima-bootstrap] 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: Wed, 24 Jun 2015 14:07:36 -0000 --=-=-= Content-Type: text/plain [this is a repost to put something in this list] The bootstrap design team is still bootstrapping, but Max, Toerless and I have had three 1hr phone conferences (May 29 meeting cancelled). They have been Friday at 1700UTC, but are now Thursday at 1400UTC, and will occur June 11 as well. A doodle poll to confirm a regular time will go out next week once the list of parties has been identified. I think that the AD still has to approve things. We started with a discussion of the charter for the DT, and how it relates to the charter for the WG, and the result is at: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap the places where it says "OWN" means, it's in scope for this DT, where it says REQUIRE, means that we are assuming it as input, and where it says PROVIDE, means that they are outputs. We continued with a recap discussion and partial walkthrough of draft-pritikin-anima-bootstrapping-keyinfra-01 We have some ideas about terminology that we think might be useful along the lines of ducking/imprinting (cf: Konrad Lorenz and http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also thought of fraternities and pledges. If you didn't grow up with http://en.wikipedia.org/wiki/Animal_House, or http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide some explanation. The idea that during the bootstrap process, there is a period when the network (the ACP aka fraternity) and the new node (the peldge) check each other out for fitness. Wikipedia says this about fraternities: Requirements may be imposed on those wishing to pledge either by the school or the organization itself, often including a minimum grade point average, wearing a pledge pin, learning about the history and structure of the organization, and performing public service. When a school places an age or tenure requirement on joining, this is called "deferred recruitment", as joining is deferred for a semester or year. The pledgeship period also serves as a probationary period in which both the organization and the pledge decide if they are compatible and will have a fulfilling experience. In today's telecon, we discussed some of the 6tisch specific requirements on bootstrap, specifically: 1) the "pledges" (or joining nodes) are constrained in CPU, code space, and energy (if battery powered, etc) 2) more importantly, the network is very constrained, 250Kbit/s max, 127 byte fraglets, and 6tisch likely would be configured to further restricts the bandwidth in the network available to joining nodes. Calculations suggest that just transmitting a DH pair and associated parts between adjacent nodes could take between 2 and 40s. 3) most protocols will require an authorization protocol that will need to travel through the LLN mesh up to a non-constrained node. The convergence of many such setup processes may well overwhelm the parts of the network closer to the root of the tree. Congestion is an issue, and retransmissions cost energy. I explained some the ideas/conclusions from draft-richardson-6tisch-security-architecture-02 and draft-richardson-6tisch--security-6top-04, which were: a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top") plans for 6tisch node/PCE communication, maximizing code reuse. b) initiating the secure bootstrap process from the non-constrained side, and having the constrained nodes remain silent after an initial "hello" packet, allowed the network manager to protect, conserve and prioritize the join bandwidth. c) 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, and the Server sends it's certificate payload first. The non-constrained node (or "JCE" == Join Coordination Entity) will receive that certificate, and can consult whatever network (or human) resources is needs to before responding with a Client Certificate that will satisfy the constrained node. It can also know via Trusted CA extension what certificate chain (if any) it needs to provide. It is observed that point (c) is not essential; that a similiar thing can be accomplished with less grace using SNI (RFC6066) and some other extensions. Note that while 6tisch is/plans-to specify that 6top is the protocol that runs over the resulting CoAP/DTLS channel, and that secure join to 6tisch consists of provisioning certain identities and parameters through that channel, the resulting channel could be used for anything. We also noted that in the context of two routers plugged in together on a lonesome grassy knoll would need to form a secure connection; that one needs to be the initiator ("client") and the other the responder ("server") is obvious, but whether both systems need to always support both roles is open for discussion. Perhaps in the constrained case, it is acceptable that constrained devices can always be responders, and in the non-constrained case, they assume both roles. I also note, recalling I was told that one implementation of the ACP consists of IKEv2 initiated channels over IPv6-link-local addresses, that the essential properties the bootstrap design team intends to provide work just fine for IKEv2 as they do for DTLS. I don't know if the ANIMA signaling protocol should occur before such a channel is established, or inside of this (provisional) channel, or whether it should instead run inside IKEv2 (maybe inside EAP). I note that 6tisch has a few potential, "I am here" messages, with RPL DAOs and Efficient-ND (E)AROs being the two ones. GDNP or HNCP or just IKE-port-500 messages are in my opinion also possibilities. -- 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) iQEVAwUBVYq5ZYCLcPvd0N1lAQIdOQf9Ec//tDyfAkboay37+h6tyi98V9Cd8E3k SsworT6s/cbBAQC1gIXG71n3K0jEKA18/eLRRipzidsFxBDyTCv3KZ605Skc+Opg 5d1vjitvKabSkh14A0fMoDeojepKZgM+/4VgDlwvqlou0FYQyAFh5VKaMPascFpd ogml24sddIrx7MYX+wTxM6FTWNZsrfJ2ufkFU8Un5iD4HHed8hNDsITPLmuGhRKN vu2PEdykVgyEJxMwOwL3JZ96N5lddI94DV0nWKXIaU7+22fduJ/Zc+7QvIX7P/Up NxtFXZgcd+tFGINmr+DimGHrJ8UmyW0DCFlOc7zEIcHakgROK7jc9Q== =y5Oy -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 24 09:18:44 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 E26661B2AEF for ; Wed, 24 Jun 2015 09:18:43 -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 KksraYND4USZ for ; Wed, 24 Jun 2015 09:18:41 -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 81F731B2AE7 for ; Wed, 24 Jun 2015 09:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8894; q=dns/txt; s=iport; t=1435162721; x=1436372321; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DZRgL5lJrwthASXuJ8hw7mEsXDSnJ3zBP668/FStiKI=; b=lkbXqPoo575n/poy9dc319MIaZa4GEyEemWWbJb1V072E+n6eEQyWCvY eUgqtPIDUjvXsYofEJDbAefsXUqavgYJFTtebKWbAUgTZ06IK4OG97ZU9 hzVuaC2jrAkN9aC4U2UDABi8KwfI2lKMR8DCWGBltcOwStekFx6APcei9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C/BQAW14pV/5pdJa1bgxFUXwa8HoJXgkKDNAKBSTsRAQEBAQEBAYEKhCIBAQEEOi4FGAQCAQgRAQMBAQsUCQcyFAMGCAIEARIIiCcNzWABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qCdAGBKB4aOAaDEYEUBYZ+hjeGUAGEV4gzhx2PYSaDem+BAwQ/gQIBAQE X-IronPort-AV: E=Sophos;i="5.13,672,1427760000"; d="scan'208";a="162250450" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 24 Jun 2015 16:18:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t5OGIene026636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jun 2015 16:18:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 11:18:40 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] a repost of summary Thread-Index: AQHQrocviq2FNvhePUuxrNGp+pPsbJ270Cjg Date: Wed, 24 Jun 2015 16:18:39 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3C98@xmb-rcd-x14.cisco.com> References: <11466.1435154789@sandelman.ca> In-Reply-To: <11466.1435154789@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.160.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima-bootstrap] 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: Wed, 24 Jun 2015 16:18:44 -0000 Michael, team,=20 I wasn't involved in the charter definition, so I have a few questions, ref= erring mostly to the design team charter at https://tools.ietf.org/wg/anima= /trac/wiki/Bootstrap%20Design%20Team%20Charter:=20 - Probably a nit: I'm missing the words "trust infrastructure". To me, we'r= e setting up a trust infrastructure, and we also need to discuss the setup = of the registrar, CA, not only the bootstrapping elements. The word "trust"= is completely missing - is there are reason for it?=20 - Goal 1: Is this the certificate format and fields?=20 - Goal 2: I think security needs to also be discussed in the reference mode= l, we need to see how we can split that? Or do you see that the bootstrap d= oc would cover that all?=20 - I think there is overlap with the netconf zero-touch work, and we should = probably be explicit: Do we want to find common groud (would hope so), or i= s it too late? Since that has been discussed, we should be explicit about t= his point I think. Which other groups do you have in mind when talking abou= t "adjacent IETF WGs"? Can we list them?=20 - somewhere the charter should state more explicitly: Define protocols and = data models for the bootstrap process. I guess that's goal 3, but it sounds= cryptic. To me, we need 1) requirements, 2) a protocol, 3) a data model, i= ncluding certificate format and fields.=20 - in the reference model I'm referring to the bootstrap process in a new wa= y, in the ASA thinking. There is an ASA for a new element, one for the prox= y, and one for the registrar. (Previously those functions were included in = the infrastructure, but logically they should be ASAs). Do you agree with t= his thinking, and if so, should we adopt this wording here as well?=20 - Do we want to include downloading a config? (I read "optimized configurat= ion distribution) - somehow that doesn't seem to be in scope, in my reading= . Can we exclude that? To me, the process ends when the device has a domain= cert.=20 - The milestone is very cryptic. Are we planning a new spin of draft-pritik= in before the IETF? Or is this a completely new draft? you say "draft(s)" -= what does that mean?=20 Michael > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: 24 June 2015 16:06 > To: anima-bootstrap@ietf.org > Subject: [Anima-bootstrap] a repost of summary >=20 >=20 > [this is a repost to put something in this list] >=20 > The bootstrap design team is still bootstrapping, but Max, Toerless and I > have had three 1hr phone conferences (May 29 meeting cancelled). They > have been Friday at 1700UTC, but are now Thursday at 1400UTC, and will > occur June 11 as well. A doodle poll to confirm a regular time will go o= ut > next week once the list of parties has been identified. > I think that the AD still has to approve things. >=20 > We started with a discussion of the charter for the DT, and how it relate= s to > the charter for the WG, and the result is at: > https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap >=20 > the places where it says "OWN" means, it's in scope for this DT, where it > says REQUIRE, means that we are assuming it as input, and where it says > PROVIDE, means that they are outputs. >=20 > We continued with a recap discussion and partial walkthrough of > draft-pritikin-anima-bootstrapping-keyinfra-01 >=20 > We have some ideas about terminology that we think might be useful along > the lines of ducking/imprinting (cf: Konrad Lorenz and > http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also > thought of fraternities and pledges. If you didn't grow up with > http://en.wikipedia.org/wiki/Animal_House, or > http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide > some explanation. The idea that during the bootstrap process, there is a > period when the network (the ACP aka fraternity) and the new node (the > peldge) check each other out for fitness. Wikipedia says this about > fraternities: > Requirements may be imposed on those wishing to pledge either by the > school or the organization itself, often including a minimum grade poi= nt > average, wearing a pledge pin, learning about the history and structur= e of > the organization, and performing public service. When a school places = an > age > or tenure requirement on joining, this is called "deferred recruitment= ", as > joining is deferred for a semester or year. The pledgeship period also > serves > as a probationary period in which both the organization and the pledge > decide > if they are compatible and will have a fulfilling experience. >=20 > In today's telecon, we discussed some of the 6tisch specific requirements > on bootstrap, specifically: > 1) the "pledges" (or joining nodes) are constrained in CPU, code space,= and > energy (if battery powered, etc) > 2) more importantly, the network is very constrained, 250Kbit/s max, 12= 7 > byte fraglets, and 6tisch likely would be configured to further > restricts the bandwidth in the network available to joining nodes. > Calculations suggest that just transmitting a DH pair and associated > parts between adjacent nodes could take between 2 and 40s. > 3) most protocols will require an authorization protocol that will need= to > travel through the LLN mesh up to a non-constrained node. The > convergence of many such setup processes may well overwhelm the > parts of > the network closer to the root of the tree. Congestion is an issue, > and retransmissions cost energy. >=20 > I explained some the ideas/conclusions from > draft-richardson-6tisch-security-architecture-02 > and draft-richardson-6tisch--security-6top-04, which were: > a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top") > plans > for 6tisch node/PCE communication, maximizing code reuse. >=20 > b) initiating the secure bootstrap process from the non-constrained sid= e, > and having the constrained nodes remain silent after an initial "hel= lo" > packet, allowed the network manager to protect, conserve and priorit= ize > the join bandwidth. >=20 > c) it turns out there is an additional benefit in making the constraine= d > node the TLS "Server" -- side. Specifically, it means that the selec= tion > of crypto parameters is done by the more constrained device, and the > Server sends it's certificate payload first. The non-constrained no= de > (or "JCE" =3D=3D Join Coordination Entity) will receive that certifi= cate, > and can consult whatever network (or human) resources is needs to > before responding with a Client Certificate that will satisfy the > constrained node. It can also know via Trusted CA extension what > certificate chain (if any) it needs to provide. >=20 > It is observed that point (c) is not essential; that a similiar thing can= be > accomplished with less grace using SNI (RFC6066) and some other > extensions. >=20 > Note that while 6tisch is/plans-to specify that 6top is the protocol that= runs > over the resulting CoAP/DTLS channel, and that secure join to 6tisch cons= ists > of provisioning certain identities and parameters through that channel, = the > resulting channel could be used for anything. >=20 > We also noted that in the context of two routers plugged in together on a > lonesome grassy knoll would need to form a secure connection; that one > needs to be the initiator ("client") and the other the responder ("server= ") is > obvious, but whether both systems need to always support both roles is > open for discussion. Perhaps in the constrained case, it is acceptable t= hat > constrained devices can always be responders, and in the non-constrained > case, they assume both roles. >=20 > I also note, recalling I was told that one implementation of the ACP cons= ists > of IKEv2 initiated channels over IPv6-link-local addresses, that the esse= ntial > properties the bootstrap design team intends to provide work just fine fo= r > IKEv2 as they do for DTLS. >=20 > I don't know if the ANIMA signaling protocol should occur before such a > channel is established, or inside of this (provisional) channel, or wheth= er it > should instead run inside IKEv2 (maybe inside EAP). >=20 > I note that 6tisch has a few potential, "I am here" messages, with RPL DA= Os > and Efficient-ND (E)AROs being the two ones. GDNP or HNCP or just > IKE-port-500 messages are in my opinion also possibilities. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jun 24 09:38: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 95E021B2B0D for ; Wed, 24 Jun 2015 09:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 W8n-wQJszdxT for ; Wed, 24 Jun 2015 09:38:37 -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 0B1741AC3FF for ; Wed, 24 Jun 2015 09:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11257; q=dns/txt; s=iport; t=1435163917; x=1436373517; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gnQE5b8YmcufYyrF+DB1xDiBZkbPc63ggktmpBA5/5M=; b=H2e5P8iEEvOolkzzUNOx21JDeI0nzb1xMBgER52TuDP9Hmym2npdgp+Z 1NSDi1U27czmzQzU1VFwXwOwyMa8SAnziHWvO9Vm9n0qJWZthti0ZPOpf HbiowesdrTGAJiKduOaGeCEkd8PdXyw9V2AGlHysyjydUqRvmY9gbRyql A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBQCD3IpV/51dJa1RAQmDEVRlvQ2BaIdBOhIBAQEBAQEBgQqEKSdHHQGBACcEER2IFA2nHqYuAQEBAQEFAQEBAQEBARcEikiFJQYBAwEGAQaDaYEUBZQFAYRXhnmYOCaDekKBMAEIFyOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,673,1427760000"; d="scan'208";a="4320958" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jun 2015 16:38:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5OGcZZL010773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jun 2015 16:38:35 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.52]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 11:38:35 -0500 From: "Max Pritikin (pritikin)" To: "anima-bootstrap@ietf.org" Thread-Topic: Meeting notes from 6/24 Thread-Index: AQHQrpw25He/nRrryEWW5og8lcmLtA== Date: Wed, 24 Jun 2015 16:38:35 +0000 Message-ID: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.79.40] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [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: Wed, 24 Jun 2015 16:38:39 -0000 Today we walked through the bootstrapping document ToC and discussed curren= t active work areas and solicited suggestions for additional areas. This is= of course on top of the general guidance of open discussion on this list a= nd active feedback from subgroup members to provide document text suggestio= ns.=20 What follows is the current ether-pad including active notes from todays co= nversation. - max IETF 93 IMPORTANT DATES =95 2015-07-06 (Monday) submission cutoff (e.g. our doc needs to be done a= nd done by then) https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-01 Table of Contents 1. Introduction [only 1st para] . . . . . . . . . . . . . . . . . . . = . . . . . 3 (MCR) 1.1. Problem Statement [other para's of the intro] [AI] nail down the device types that are in scope 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 define pledge and imprint part define authorization and authentication (rfc4949) Include architectural overview terms/entities (e.g. Factory/Factory= CA) map names: new entity, proxy, registrar to EAP (supplicant, authent= icator, authentication server) =95 glossary to define how we're using authC/authZ (not in intro) 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 = (MAX) limit to registrar/new-entity interaction (via proxy) this describes a message based protocol that runs over another (unsecure= d) transport, TBD by specific situation. =20 =20 3. Operational Overview . . . . . . . . . . . . . . . . . . . . 7 MCR: This is actually the "domain operator point of view" ... the story = from the operators perspective "this is the initial state of the system and how it was instantiated" MCR: this might be too soon to detail how to admin the system, first the= y want to know what the system does for them Tesla doesn't start by saying "first you need to build a chain of electr= ic 'gas' stations" This a good argument for moving this later in the document 3.1. Instantiating the Domain Certification Authority . . . . 7 3.2. Instantiating the Registrar . . . . . . . . . . . . . . . 7 This could be an ASA [autonomic service agent] that can be the registr= ar The automated registrar selection is in the scope of signaling documen= t The proxy needs to be aware of the selection! 3.3. Accepting New Entities . . . . . . . . . . . . . . . . . 8 =20 For each New Entity the Registrar is informed *of* the unique identifi= er =20 3.4. Automatic Enrolment of Devices . . . . . . . . . . . . . 9 3.5. Operating the Network . . . . . . . . . . . . . . . . . . 9 =20 =20 =20 =20 =20 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 9 Make this a section of "overall flow" promote the "behavior of" subsections to 5, 6, 7 etc 4.1. Behavior of a new entity . . . . . . . . . . . . . . . . 10 "Device's Point of View" Perhaps expand to show the state machine for the Device 4.1.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . 11 discovery is all that should be covered here. the communications bet= ween the proxy and the registrar should be discussed in s4.2 4.1.2. Receiving and accepting the Domain Identity . . . . . 12 Should there be a state where the device will no longer "returns to = discovery state"?=20 MAX: "no!" :) MCR: maybe[?] (MAY)=20 This is the question of "can a device prevent itself from being st= olen or trojan'd"?=20 Is there an in scope use case for this? Open for continued conversation. 4.1.3. Enrollment . . . . . . . . . . . . . . . . . . . . . 13 Allow direct entry into this state to support non-zero touch Support console for RFC7030 s4.1.1 'Bootstrap Distribution of CA Cer= tificates' with "engage a human user" MCR would like to specify the exact format of the "fingerprint"=20 MAX use the URL bootstrapping model Discussion of IDevID displayed in browser; how to deal with this? Is= it in scope for this document? Is this a 'console port' model? 4.1.4. After Enrollment . . . . . . . . . . . . . . . . . . 13 maintain brightline between enrollment and configuration but accept that for optimization some configuration information migh= t be delivered during enrollment clients and servers SHOULD support TLS session resumption. allowing = for efficient handoff across this line with appropriate security considerations to be addressed: for exampl= e a constrained device might be better=20 served by the server's sharing the=20 resumption token rather than being forced to use poor entropy. this = is worth discussion. perhaps this new=20 session is a DTLS COAP on a different port. =20 perhaps this allows the s4.1.1 proxy communications to now be transi= tioned to a direct connection =20 4.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 13 s4.1.1 hypothesizes existing protocol for proxy<->registrar communicat= ions. (s4.1.1 is about device discovery of proxy. toerless points out that m= aybe we collect proxy discussion into one section) AI: we need to pick one here as normative toerless: perhaps just choose a model or models (e.g. EAP) but allow a= n alternate anima doc to be more prescriptive until we have more clarity here we'll have to structure this into its = own document section and provide flexibility AI: include text about what requirements are being made on the transpo= rt protocol such that potential protocols can be evaluated. [[this is probably a good 1st step for selecting a norma= tive method anyway]]. Sounds like this is the first step. [[this is also a good to understand the device types to be supported. = but recall that the device's that are in scope will feedback requirements h= ere. so this will be a give/take discussion]] AI: to pick one and argue for it. "proof by confrontatio= n" EAP-TLS is discussed strongly in the 6/24 call with awareness that con= strained devices might be troubled (PANA also) MCR: worried about what this protocol "lives in"; argues that we need = to be able to support the EAP model but not necessarily EAP-TLS We need to indicate how the registrar is discovered. The outward requirement from bootstrap -> signaling, is that the proto= col should be architectually capable of working with EAP-like protocols. (i= f not EAP itself) (IKEv2, PANA, 1x, TLS, DHCP all likely support the model) =20 4.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 14 4.3.1. Authenticating the Device . . . . . . . . . . . . . . 14 Discussion of IDevID displayed in browser; how to deal with this? Is= it in scope for this document? 4.3.2. Accepting the Entity . . . . . . . . . . . . . . . . 14 4.3.3. Claiming the new entity . . . . . . . . . . . . . . . 15 4.4. Behavior of the MASA Service . . . . . . . . . . . . . . 15 4.4.1. Issue Authorization Token and Log the event . . . . . 16 4.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 16 4.5. Leveraging the new key infrastructure / next steps . . . 16 4.5.1. Network boundaries . . . . . . . . . . . . . . . . . 16 =20 =20 =20 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 17 5.1. EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Request bootstrap token . . . . . . . . . . . . . . . . . 18 5.3. Request MASA authorization token . . . . . . . . . . . . 18 5.4. Request MASA authorization log . . . . . . . . . . . . . 19 6. Reduced security operational modes . . . . . . . . . . . . . 20 need to clarify why each reduced security mode might be necessary [additional scenario for #5: not uncommon to resale equipement: need to = rekey it all] =20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 [THREAT: can an attacker regain control using a nonceless masa token for= some=20 [short period of time before returning the device to the current owner; = is there [a way to 'rekey' the device to stop this? re: IDevID it?] 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 22 * Virtual Factory move text to deal with virtual machines here (from architectural overv= iew) this is related to the "non-802.1AR" discussion here we indicate the 'blob' of data that can be inserted instead of the IDevID, which is used for client authentication 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22 =20 Perhaps a reference toward a doc (TCG? IEEE?) about best practices for= IDevID insertion (e.g. how not to keep the CA root key in manufacturing facility)=20 =3D=3D=3D=3D=3D=3D=3D For next week (6/4): AI: michael to do section #1 (6/11 - still open) AI: max to do section #2 (6/11 - still open)=20 agenda plan: 6stich overlap discussion [[completed 6/4]] continued Table of Contents driven walk through https://mailarchive.ietf.org/arch/msg/anima-signaling/oJzM0fuaniZ_PxO27Bcg_= la4MdU - email summary. =3D=3D=3D=3D=3D=3D 6band:=20 The scope of this mailing list is mainly to address threat analysis of 6lo = networks, secure bootstrapping and evaluating solutions for constrained nod= e devices in constrained-L2-access technology networks. The problem scope i= s limited to secure network access/bootstrapping of the 6lo nodes. This int= erest group may also discuss interfaces between network layer and Applicati= on layer for sharing security association. The scope of this work does not = include Application level security work . The goal is to identify existing = candidate technologies or needs for new development of bootstrapping mechan= isms. OUR RESPONSE: There is no clear use case discussion ("no clear constraints"= ).=20 For example the anima charter paragraph 7 states: "The ANIMA working group = focuses on professionally-managed networks" and provides examples. Can we s= ee a similar statement from 6band.=20 Devices that are professionally managed would be in scope of anima --- but = since anima bootstrapping is intended to provide a zero-touch solution we e= ncourage continued conversation and the possibility of re-using the work in= whatever the 6band scope turns out to be. PLAN: wait out until their mailing list gets going and then approach them w= ith this discussion. The three of us have subscribed to the 6band mailing l= ist.=20 From nobody Wed Jun 24 09:50:11 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 1FFBA1B2B64 for ; Wed, 24 Jun 2015 09:50:09 -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 X5kfw8FjMzI9 for ; Wed, 24 Jun 2015 09:50:06 -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 158771B2B63 for ; Wed, 24 Jun 2015 09:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12628; q=dns/txt; s=iport; t=1435164605; x=1436374205; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dK1L2mfxKnkCO1ywRME3ndRkB+J+jFoZIeR0Oo3lFtk=; b=j+1yoe56cJL1/zMU3iQiYa/m6HVkS/4NFrDgemD7918MXK6wuxq6EhpG 2Xie+21VQK2mn6MtT5nFTnW4AOElosWe7uHWzVy80/qeirVebjJkoReeW zv3Cq6r9TbFIQ1uf5BhGImsJeFggBfc66bvoxDhYXhLP1d4Hj02geLvwe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAwBE34pV/4kNJK1RAQmDEVRfBrweZgmBXAyFdgKBSTgUAQEBAQEBAYEKhCIBAQEDAQEBASQTNBAHBAIBCBEEAQELFAkHJwsUCQgCBAEQAggTiAwIDc1OAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKSIEChCMGAQMBBgEGGjgGgxGBFAWUBQGEV58xJoN6Qi2BAwEIFyOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,673,1427760000"; d="scan'208";a="9964220" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jun 2015 16:50:04 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5OGo4ZJ005138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jun 2015 16:50:04 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 11:50:04 -0500 From: "Michael Behringer (mbehring)" To: "Max Pritikin (pritikin)" , "anima-bootstrap@ietf.org" Thread-Topic: Meeting notes from 6/24 Thread-Index: AQHQrpw25He/nRrryEWW5og8lcmLtJ273TDw Date: Wed, 24 Jun 2015 16:50:04 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@xmb-rcd-x14.cisco.com> References: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@cisco.com> In-Reply-To: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@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.160.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 24 Jun 2015 16:50:09 -0000 Thanks for sharing.=20 A high level question up front: When we wrote draft-pritikin, we started fr= om the premise that the draft should describe the most secure model as a re= ference, then in section 6, explains alternative models which may be less s= ecure, but more useful for certain environments. Are we still sticking to t= his philosophy "describe best possible, and separately less secure alternat= ives"? (I hope so ;-)=20 I can review section 3, if that is considered useful. I understand that thi= ngs may change, but it doesn't harm to document current understanding.=20 Michael > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On > Behalf Of Max Pritikin (pritikin) > Sent: 24 June 2015 18:39 > To: anima-bootstrap@ietf.org > Subject: [Anima-bootstrap] Meeting notes from 6/24 >=20 >=20 > Today we walked through the bootstrapping document ToC and discussed > current active work areas and solicited suggestions for additional areas.= This > is of course on top of the general guidance of open discussion on this li= st > and active feedback from subgroup members to provide document text > suggestions. >=20 > What follows is the current ether-pad including active notes from todays > conversation. >=20 > - max >=20 >=20 > IETF 93 IMPORTANT DATES > * 2015-07-06 (Monday) submission cutoff (e.g. our doc needs to be > done and done by then) >=20 >=20 >=20 > https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-0= 1 >=20 > Table of Contents >=20 > 1. Introduction [only 1st para] . . . . . . . . . . . . . . . . . . = . . . . . . 3 (MCR) > 1.1. Problem Statement [other para's of the intro] > [AI] nail down the device types that are in scope > 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 > define pledge and imprint part > define authorization and authentication (rfc4949) > Include architectural overview terms/entities (e.g. Factory/Facto= ry CA) > map names: new entity, proxy, registrar to EAP (supplicant, > authenticator, authentication server) > * glossary to define how we're using authC/authZ (not in intro) > 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 = (MAX) > limit to registrar/new-entity interaction (via proxy) > this describes a message based protocol that runs over another > (unsecured) transport, TBD by specific situation. >=20 >=20 > 3. Operational Overview . . . . . . . . . . . . . . . . . . . . 7 > MCR: This is actually the "domain operator point of view" ... the stor= y from > the operators perspective > "this is the initial state of the system and how it was instantiated" > MCR: this might be too soon to detail how to admin the system, first t= hey > want to know what the system does for them > Tesla doesn't start by saying "first you need to build a chain of elec= tric 'gas' > stations" > This a good argument for moving this later in the document > 3.1. Instantiating the Domain Certification Authority . . . . 7 > 3.2. Instantiating the Registrar . . . . . . . . . . . . . . . 7 > This could be an ASA [autonomic service agent] that can be the regis= trar > The automated registrar selection is in the scope of signaling docum= ent > The proxy needs to be aware of the selection! > 3.3. Accepting New Entities . . . . . . . . . . . . . . . . . 8 >=20 > For each New Entity the Registrar is informed *of* the unique identi= fier >=20 > 3.4. Automatic Enrolment of Devices . . . . . . . . . . . . . 9 > 3.5. Operating the Network . . . . . . . . . . . . . . . . . . 9 >=20 >=20 >=20 >=20 >=20 > 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 9 > Make this a section of "overall flow" > promote the "behavior of" subsections to 5, 6, 7 etc >=20 > 4.1. Behavior of a new entity . . . . . . . . . . . . . . . . 10 > "Device's Point of View" > Perhaps expand to show the state machine for the Device > 4.1.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . 11 > discovery is all that should be covered here. the communications > between the proxy and the registrar > should be discussed in s4.2 > 4.1.2. Receiving and accepting the Domain Identity . . . . . 12 > Should there be a state where the device will no longer "returns t= o > discovery state"? > MAX: "no!" :) > MCR: maybe[?] (MAY) > This is the question of "can a device prevent itself from being = stolen or > trojan'd"? > Is there an in scope use case for this? > Open for continued conversation. > 4.1.3. Enrollment . . . . . . . . . . . . . . . . . . . . . 13 > Allow direct entry into this state to support non-zero touch > Support console for RFC7030 s4.1.1 'Bootstrap Distribution of CA > Certificates' with "engage a human user" > MCR would like to specify the exact format of the "fingerprint" > MAX use the URL bootstrapping model > Discussion of IDevID displayed in browser; how to deal with this? = Is it in > scope for this document? Is this a 'console port' model? > 4.1.4. After Enrollment . . . . . . . . . . . . . . . . . . 13 > maintain brightline between enrollment and configuration > but accept that for optimization some configuration information mi= ght > be delivered during enrollment > clients and servers SHOULD support TLS session resumption. allowin= g for > efficient handoff across this line > with appropriate security considerations to be addressed: for exam= ple a > constrained device might be better > served by the server's sharing the > resumption token rather than being forced to use poor entropy. thi= s is > worth discussion. perhaps this new > session is a DTLS COAP on a different port. > perhaps this allows the s4.1.1 proxy communications to now be > transitioned to a direct connection >=20 > 4.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 13 > s4.1.1 hypothesizes existing protocol for proxy<->registrar > communications. > (s4.1.1 is about device discovery of proxy. toerless points out that= maybe > we collect proxy discussion into one section) > AI: we need to pick one here as normative > toerless: perhaps just choose a model or models (e.g. EAP) but allow= an > alternate anima doc to be more prescriptive > until we have more clarity here we'll have to structure this into it= s own > document section and provide flexibility > AI: include text about what requirements are being made on the > transport protocol such that potential protocols can > be evaluated. [[this is probably a good 1st step for selecting a nor= mative > method anyway]]. Sounds like this is the first step. > [[this is also a good to understand the device types to be supported= . but > recall that the device's that are in scope will feedback requirements her= e. > so this will be a give/take discussion]] > AI: to pick one and argue for it. "proof by confrontat= ion" > EAP-TLS is discussed strongly in the 6/24 call with awareness that > constrained devices might be troubled (PANA also) > MCR: worried about what this protocol "lives in"; argues that we nee= d to > be able to support the EAP model but not necessarily EAP-TLS > We need to indicate how the registrar is discovered. > The outward requirement from bootstrap -> signaling, is that the pro= tocol > should be architectually capable of working with EAP-like protocols. (if = not > EAP itself) > (IKEv2, PANA, 1x, TLS, DHCP all likely support the model) >=20 > 4.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 14 > 4.3.1. Authenticating the Device . . . . . . . . . . . . . . 14 > Discussion of IDevID displayed in browser; how to deal with this? = Is it in > scope for this document? > 4.3.2. Accepting the Entity . . . . . . . . . . . . . . . . 14 > 4.3.3. Claiming the new entity . . . . . . . . . . . . . . . 15 > 4.4. Behavior of the MASA Service . . . . . . . . . . . . . . 15 > 4.4.1. Issue Authorization Token and Log the event . . . . . 16 > 4.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 16 > 4.5. Leveraging the new key infrastructure / next steps . . . 16 > 4.5.1. Network boundaries . . . . . . . . . . . . . . . . . 16 >=20 >=20 >=20 > 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 17 > 5.1. EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . . 18 > 5.2. Request bootstrap token . . . . . . . . . . . . . . . . . 18 > 5.3. Request MASA authorization token . . . . . . . . . . . . 18 > 5.4. Request MASA authorization log . . . . . . . . . . . . . 19 > 6. Reduced security operational modes . . . . . . . . . . . . . 20 > need to clarify why each reduced security mode might be necessary > [additional scenario for #5: not uncommon to resale equipement: need t= o > rekey it all] >=20 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > [THREAT: can an attacker regain control using a nonceless masa token f= or > some > [short period of time before returning the device to the current owner= ; is > there > [a way to 'rekey' the device to stop this? re: IDevID it?] >=20 > 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 22 >=20 > * Virtual Factory > move text to deal with virtual machines here (from architectural > overview) > this is related to the "non-802.1AR" discussion > here we indicate the 'blob' of data that can be inserted instead of > the IDevID, which is used for client authentication >=20 > 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 > 9.2. Informative References . . . . . . . . . . . . . . . . . 22 >=20 > Perhaps a reference toward a doc (TCG? IEEE?) about best practices f= or > IDevID insertion > (e.g. how not to keep the CA root key in manufacturing facility) >=20 > =3D=3D=3D=3D=3D=3D=3D > For next week (6/4): > AI: michael to do section #1 (6/11 - still open) > AI: max to do section #2 (6/11 - still open) > agenda plan: 6stich overlap discussion [[completed 6/4]] > continued Table of Contents driven walk through >=20 > https://mailarchive.ietf.org/arch/msg/anima- > signaling/oJzM0fuaniZ_PxO27Bcg_la4MdU - email summary. >=20 > =3D=3D=3D=3D=3D=3D > 6band: >=20 > The scope of this mailing list is mainly to address threat analysis of 6l= o > networks, secure bootstrapping and evaluating solutions for constrained > node devices in constrained-L2-access technology networks. The problem > scope is limited to secure network access/bootstrapping of the 6lo nodes. > This interest group may also discuss interfaces between network layer and > Application layer for sharing security association. The scope of this wor= k > does not include Application level security work . The goal is to identif= y > existing candidate technologies or needs for new development of > bootstrapping mechanisms. > OUR RESPONSE: There is no clear use case discussion ("no clear > constraints"). > For example the anima charter paragraph 7 states: "The ANIMA working > group focuses on professionally-managed networks" and provides > examples. Can we see a similar statement from 6band. > Devices that are professionally managed would be in scope of anima --- bu= t > since anima bootstrapping is intended to provide a zero-touch solution we > encourage continued conversation and the possibility of re-using the work > in whatever the 6band scope turns out to be. > PLAN: wait out until their mailing list gets going and then approach them > with this discussion. The three of us have subscribed to the 6band mailin= g > list. >=20 >=20 > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Wed Jun 24 10:01:05 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 4E2361B2B75 for ; Wed, 24 Jun 2015 10:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 xapTSoyAZqhV for ; Wed, 24 Jun 2015 10:01:00 -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 4D23C1B2B61 for ; Wed, 24 Jun 2015 10:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13785; q=dns/txt; s=iport; t=1435165260; x=1436374860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cxzdbtQy4xwIQXilBGy1ii/hkeT4U6RXMCv2fT6xWFo=; b=YcQOIghfkLt3XTEi/NS4y/KYoaz3FdUXCLh1jdjCkbNcyguK/NKfMVMW 4qxl/x8VhK2Bpsc6k8k34aYt7XmCbQL9QAMBD7CIUlhQdIWvw+3ApmGeE JD7NlKIjPJbFNYIbErHZejS0BmMPHvtZtU8T1GUSLdygyD9ALVrwfcL+s E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CyAwAy4YpV/5RdJa1RAQmDEVRSDQa9BAmBXAyFdgKBSjgUAQEBAQEBAYEKhCIBAQEDAQEBASRHCwUHBAIBCBEEAQEoBycLFAkIAgQOAwIbiAwIDc0/AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKSIEChCMGAQMBBgEGGDMHBoMRgRQFlAUBhFeGeYE6kyKDXCaDekItgQMBCBcjgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,673,1427760000"; d="scan'208";a="4327890" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jun 2015 17:00:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5OH0wZl012969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jun 2015 17:00:58 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.52]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 12:00:58 -0500 From: "Max Pritikin (pritikin)" To: "Michael Behringer (mbehring)" Thread-Topic: Meeting notes from 6/24 Thread-Index: AQHQrpw25He/nRrryEWW5og8lcmLtJ273TDwgABYGgA= Date: Wed, 24 Jun 2015 17:00:57 +0000 Message-ID: References: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@xmb-rcd-x14.cisco.com> In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.79.40] Content-Type: text/plain; charset="Windows-1252" Content-ID: <853FD229B7E1114EBE02BE1349C33D64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima-bootstrap@ietf.org" 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: Wed, 24 Jun 2015 17:01:03 -0000 On Jun 24, 2015, at 10:50 AM, Michael Behringer (mbehring) wrote: > Thanks for sharing.=20 >=20 > 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 altern= atives"? (I hope so ;-)=20 I believe this is still the plan. Section6 includes the discussion of =93Re= duced security operational modes=94 and I haven=92t seen pushback that thes= e should be buried within the other sections.=20 There is plenty of discussion about the transport protocol operational mode= s (and requirements upon) as captured in the meeting notes around sections = s4.1.1 and s4.2. Although currently discussed as a =93model=94 or =93transp= ort=94 with limited effect on the protocol security details I brought up to= day the point that various models for the proxy impact the security threat = modeling and might have impacts on section6.=20 >=20 > I can review section 3, if that is considered useful. I understand that t= hings may change, but it doesn't harm to document current understanding.=20 Current changes for section3 are mostly planned to be the addition of disti= nct state machines for each element. If you focus your review on what state= s are implied or not-implied then your feedback would be most helpful!=20 - max >=20 > Michael >=20 >=20 >> -----Original Message----- >> From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On >> Behalf Of Max Pritikin (pritikin) >> Sent: 24 June 2015 18:39 >> To: anima-bootstrap@ietf.org >> Subject: [Anima-bootstrap] Meeting notes from 6/24 >>=20 >>=20 >> Today we walked through the bootstrapping document ToC and discussed >> current active work areas and solicited suggestions for additional areas= . This >> is of course on top of the general guidance of open discussion on this l= ist >> and active feedback from subgroup members to provide document text >> suggestions. >>=20 >> What follows is the current ether-pad including active notes from todays >> conversation. >>=20 >> - max >>=20 >>=20 >> IETF 93 IMPORTANT DATES >> * 2015-07-06 (Monday) submission cutoff (e.g. our doc needs to be >> done and done by then) >>=20 >>=20 >>=20 >> https://tools.ietf.org/html/draft-pritikin-anima-bootstrapping-keyinfra-= 01 >>=20 >> Table of Contents >>=20 >> 1. Introduction [only 1st para] . . . . . . . . . . . . . . . . . . = . . . . . . 3 (MCR) >> 1.1. Problem Statement [other para's of the intro] >> [AI] nail down the device types that are in scope >> 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 >> define pledge and imprint part >> define authorization and authentication (rfc4949) >> Include architectural overview terms/entities (e.g. Factory/Facto= ry CA) >> map names: new entity, proxy, registrar to EAP (supplicant, >> authenticator, authentication server) >> * glossary to define how we're using authC/authZ (not in intro) >> 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 = (MAX) >> limit to registrar/new-entity interaction (via proxy) >> this describes a message based protocol that runs over another >> (unsecured) transport, TBD by specific situation. >>=20 >>=20 >> 3. Operational Overview . . . . . . . . . . . . . . . . . . . . 7 >> MCR: This is actually the "domain operator point of view" ... the stor= y from >> the operators perspective >> "this is the initial state of the system and how it was instantiated" >> MCR: this might be too soon to detail how to admin the system, first t= hey >> want to know what the system does for them >> Tesla doesn't start by saying "first you need to build a chain of elec= tric 'gas' >> stations" >> This a good argument for moving this later in the document >> 3.1. Instantiating the Domain Certification Authority . . . . 7 >> 3.2. Instantiating the Registrar . . . . . . . . . . . . . . . 7 >> This could be an ASA [autonomic service agent] that can be the regis= trar >> The automated registrar selection is in the scope of signaling docum= ent >> The proxy needs to be aware of the selection! >> 3.3. Accepting New Entities . . . . . . . . . . . . . . . . . 8 >>=20 >> For each New Entity the Registrar is informed *of* the unique identi= fier >>=20 >> 3.4. Automatic Enrolment of Devices . . . . . . . . . . . . . 9 >> 3.5. Operating the Network . . . . . . . . . . . . . . . . . . 9 >>=20 >>=20 >>=20 >>=20 >>=20 >> 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 9 >> Make this a section of "overall flow" >> promote the "behavior of" subsections to 5, 6, 7 etc >>=20 >> 4.1. Behavior of a new entity . . . . . . . . . . . . . . . . 10 >> "Device's Point of View" >> Perhaps expand to show the state machine for the Device >> 4.1.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . 11 >> discovery is all that should be covered here. the communications >> between the proxy and the registrar >> should be discussed in s4.2 >> 4.1.2. Receiving and accepting the Domain Identity . . . . . 12 >> Should there be a state where the device will no longer "returns t= o >> discovery state"? >> MAX: "no!" :) >> MCR: maybe[?] (MAY) >> This is the question of "can a device prevent itself from being = stolen or >> trojan'd"? >> Is there an in scope use case for this? >> Open for continued conversation. >> 4.1.3. Enrollment . . . . . . . . . . . . . . . . . . . . . 13 >> Allow direct entry into this state to support non-zero touch >> Support console for RFC7030 s4.1.1 'Bootstrap Distribution of CA >> Certificates' with "engage a human user" >> MCR would like to specify the exact format of the "fingerprint" >> MAX use the URL bootstrapping model >> Discussion of IDevID displayed in browser; how to deal with this? = Is it in >> scope for this document? Is this a 'console port' model? >> 4.1.4. After Enrollment . . . . . . . . . . . . . . . . . . 13 >> maintain brightline between enrollment and configuration >> but accept that for optimization some configuration information mi= ght >> be delivered during enrollment >> clients and servers SHOULD support TLS session resumption. allowin= g for >> efficient handoff across this line >> with appropriate security considerations to be addressed: for exam= ple a >> constrained device might be better >> served by the server's sharing the >> resumption token rather than being forced to use poor entropy. thi= s is >> worth discussion. perhaps this new >> session is a DTLS COAP on a different port. >> perhaps this allows the s4.1.1 proxy communications to now be >> transitioned to a direct connection >>=20 >> 4.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 13 >> s4.1.1 hypothesizes existing protocol for proxy<->registrar >> communications. >> (s4.1.1 is about device discovery of proxy. toerless points out that= maybe >> we collect proxy discussion into one section) >> AI: we need to pick one here as normative >> toerless: perhaps just choose a model or models (e.g. EAP) but allow= an >> alternate anima doc to be more prescriptive >> until we have more clarity here we'll have to structure this into it= s own >> document section and provide flexibility >> AI: include text about what requirements are being made on the >> transport protocol such that potential protocols can >> be evaluated. [[this is probably a good 1st step for selecting a nor= mative >> method anyway]]. Sounds like this is the first step. >> [[this is also a good to understand the device types to be supported= . but >> recall that the device's that are in scope will feedback requirements he= re. >> so this will be a give/take discussion]] >> AI: to pick one and argue for it. "proof by confrontat= ion" >> EAP-TLS is discussed strongly in the 6/24 call with awareness that >> constrained devices might be troubled (PANA also) >> MCR: worried about what this protocol "lives in"; argues that we nee= d to >> be able to support the EAP model but not necessarily EAP-TLS >> We need to indicate how the registrar is discovered. >> The outward requirement from bootstrap -> signaling, is that the pro= tocol >> should be architectually capable of working with EAP-like protocols. (if= not >> EAP itself) >> (IKEv2, PANA, 1x, TLS, DHCP all likely support the model) >>=20 >> 4.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 14 >> 4.3.1. Authenticating the Device . . . . . . . . . . . . . . 14 >> Discussion of IDevID displayed in browser; how to deal with this? = Is it in >> scope for this document? >> 4.3.2. Accepting the Entity . . . . . . . . . . . . . . . . 14 >> 4.3.3. Claiming the new entity . . . . . . . . . . . . . . . 15 >> 4.4. Behavior of the MASA Service . . . . . . . . . . . . . . 15 >> 4.4.1. Issue Authorization Token and Log the event . . . . . 16 >> 4.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 16 >> 4.5. Leveraging the new key infrastructure / next steps . . . 16 >> 4.5.1. Network boundaries . . . . . . . . . . . . . . . . . 16 >>=20 >>=20 >>=20 >> 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 17 >> 5.1. EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . . 18 >> 5.2. Request bootstrap token . . . . . . . . . . . . . . . . . 18 >> 5.3. Request MASA authorization token . . . . . . . . . . . . 18 >> 5.4. Request MASA authorization log . . . . . . . . . . . . . 19 >> 6. Reduced security operational modes . . . . . . . . . . . . . 20 >> need to clarify why each reduced security mode might be necessary >> [additional scenario for #5: not uncommon to resale equipement: need t= o >> rekey it all] >>=20 >> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 >> [THREAT: can an attacker regain control using a nonceless masa token f= or >> some >> [short period of time before returning the device to the current owner= ; is >> there >> [a way to 'rekey' the device to stop this? re: IDevID it?] >>=20 >> 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 22 >>=20 >> * Virtual Factory >> move text to deal with virtual machines here (from architectural >> overview) >> this is related to the "non-802.1AR" discussion >> here we indicate the 'blob' of data that can be inserted instead of >> the IDevID, which is used for client authentication >>=20 >> 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 >> 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 >> 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 >> 9.2. Informative References . . . . . . . . . . . . . . . . . 22 >>=20 >> Perhaps a reference toward a doc (TCG? IEEE?) about best practices f= or >> IDevID insertion >> (e.g. how not to keep the CA root key in manufacturing facility) >>=20 >> =3D=3D=3D=3D=3D=3D=3D >> For next week (6/4): >> AI: michael to do section #1 (6/11 - still open) >> AI: max to do section #2 (6/11 - still open) >> agenda plan: 6stich overlap discussion [[completed 6/4]] >> continued Table of Contents driven walk through >>=20 >> https://mailarchive.ietf.org/arch/msg/anima- >> signaling/oJzM0fuaniZ_PxO27Bcg_la4MdU - email summary. >>=20 >> =3D=3D=3D=3D=3D=3D >> 6band: >>=20 >> The scope of this mailing list is mainly to address threat analysis of 6= lo >> networks, secure bootstrapping and evaluating solutions for constrained >> node devices in constrained-L2-access technology networks. The problem >> scope is limited to secure network access/bootstrapping of the 6lo nodes= . >> This interest group may also discuss interfaces between network layer an= d >> Application layer for sharing security association. The scope of this wo= rk >> does not include Application level security work . The goal is to identi= fy >> existing candidate technologies or needs for new development of >> bootstrapping mechanisms. >> OUR RESPONSE: There is no clear use case discussion ("no clear >> constraints"). >> For example the anima charter paragraph 7 states: "The ANIMA working >> group focuses on professionally-managed networks" and provides >> examples. Can we see a similar statement from 6band. >> Devices that are professionally managed would be in scope of anima --- b= ut >> since anima bootstrapping is intended to provide a zero-touch solution w= e >> encourage continued conversation and the possibility of re-using the wor= k >> in whatever the 6band scope turns out to be. >> PLAN: wait out until their mailing list gets going and then approach the= m >> with this discussion. The three of us have subscribed to the 6band maili= ng >> list. >>=20 >>=20 >> _______________________________________________ >> Anima-bootstrap mailing list >> Anima-bootstrap@ietf.org >> https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Wed Jun 24 10:04:51 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 D9F841B2B8D for ; Wed, 24 Jun 2015 10:04:49 -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 0sMa9_oIYkHE for ; Wed, 24 Jun 2015 10:04:47 -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 42AF11B2B8A for ; Wed, 24 Jun 2015 10:04:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 10C222002A for ; Wed, 24 Jun 2015 13:19:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D5BE563AE8; Wed, 24 Jun 2015 13:04:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B693863AD9 for ; Wed, 24 Jun 2015 13:04:45 -0400 (EDT) From: Michael Richardson To: anima-bootstrap@ietf.org X-Attribution: mcr 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: [Anima-bootstrap] design team document 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, 24 Jun 2015 17:04:50 -0000 --=-=-= Content-Type: text/plain I have taken the draft-pritikin document, renamed it to dtbootstrap-anima-keyinfra, and put it on github at: https://github.com/ietf-roll/anima-bootstrap Max, I don't recall where we were with this ... please point me at your github IDs so that I can add them to add, or just fork and send pull requests. I propose to post this to datatracker as -00 on Monday, regardless of the state that it is in. -- 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) iQEVAwUBVYrjKoCLcPvd0N1lAQK/2wf/d1gW4TGd6gRBKEfjFethbZrTfBKAci4K GbPaYSoVgv+tdjxkH2/8gpicYnucy3PhTbR7K6ZKInGHBh2MwN240SFwF3JVZPvz f3Lo76R6yOrU0TfPNtYorIx0aJnMJSm7adnPTbYbGZ6l/8p5ioVWrNLh973Dzu0G MzdKx+O6HeR/cI0+jIzrdcAssTNupxNJZLiHTMpPDq3FVeZNHLBm8PDS5Yp9J9VF txRsYTyGWtuwTbB1OawijNMba4T934/mBliTsh1V5vKvYr9+xy0QjKFXNZW+nDUf X+Ry/w60pRQw9Insn62CJ8fw3DTIoyxskX4pIojJsBXFd51d2pakxQ== =MT1t -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 24 10:10:03 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 402B31B2B93 for ; Wed, 24 Jun 2015 10:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_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 qA4RgjOxe1_8 for ; Wed, 24 Jun 2015 10:10:02 -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 D5DE41B2B75 for ; Wed, 24 Jun 2015 10:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1435165801; x=1436375401; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VpgS4ADfTgKb5Dev0ro2tHrsRzSHVb37Lv0+aOB4CmA=; b=MmZmX4tYQW++6qORkyvWvzd5Sj+0fjRWXTIMLoO49912ylzJ4Sm38s81 sSoTnVurqjQlv9wIfjTlYpHJjo/2VfEdrgHSdzYsUtvBJiKjtN6GNewZX gYKofBuvqGuZjQyJdbHrJIdj1v0tHvBl9asYFspZcw9UFzbouljSJ5H3x M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AyBAAF5IpV/4UNJK1bgxFUXwa8HmYJgWaCRIM0AoFLOBQBAQEBAQEBgQqEIgEBAQQ6SwQCAQgRBAEBCxQJBzIUCQgCBAESCIgnDc1SAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLSoRVOAaDEYEUBZQFAYRXiDOEEI8Sg1wmg3pvgUaBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,673,1427760000"; d="scan'208";a="9968469" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jun 2015 17:10:01 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5OHA1Qt001200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jun 2015 17:10:01 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 24 Jun 2015 12:10:00 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] design team document Thread-Index: AQHQrp/tpoBvIM8Gd0mQ1RAT4twR0J2746Xw Date: Wed, 24 Jun 2015 17:09:59 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3DAA@xmb-rcd-x14.cisco.com> References: <20193.1435165485@sandelman.ca> In-Reply-To: <20193.1435165485@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.160.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima-bootstrap] design team document 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, 24 Jun 2015 17:10:03 -0000 What does the "dt" stand for?=20 And, what's the delta to the current draft-pritikin?=20 Can you please add my github id: mbehring. Michael > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: 24 June 2015 19:05 > To: anima-bootstrap@ietf.org > Subject: [Anima-bootstrap] design team document >=20 >=20 > I have taken the draft-pritikin document, renamed it to dtbootstrap-anima= - > keyinfra, and put it on github at: > https://github.com/ietf-roll/anima-bootstrap >=20 > Max, I don't recall where we were with this ... please point me at your > github IDs so that I can add them to add, or just fork and send pull requ= ests. >=20 > I propose to post this to datatracker as -00 on Monday, regardless of the > state that it is in. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Thu Jun 25 08:55:33 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 8369F1A1A9D for ; Thu, 25 Jun 2015 08:55:31 -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 2ETJm3Dah0fa for ; Thu, 25 Jun 2015 08:55:27 -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 E478C1A0119 for ; Thu, 25 Jun 2015 08:55:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E4CA9200A3; Thu, 25 Jun 2015 12:10:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 587BE63AE8; Thu, 25 Jun 2015 11:55:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4009463AD9; Thu, 25 Jun 2015 11:55:24 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3DAA@xmb-rcd-x14.cisco.com> References: <20193.1435165485@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3DAA@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: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] design team document 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, 25 Jun 2015 15:55:31 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > What does the "dt" stand for? "Design Team" > And, what's the delta to the current draft-pritikin? at this point, it might be zero. > Can you please add my github id: mbehring. done. Note that it is in a pseudo-organization "ietf-roll" -- 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) iQEVAwUBVYwka4CLcPvd0N1lAQLSQwf+IXgpf5SVEe452vV9t2/mO7CQn7PhlUwH E0ieUhYSpK45RnW/bHViApqY8bdbol3wO7S02D6TQokbngnbSg1OTxTeAORjNiEZ ff6sIFgTxcmmcF0pJ+0EGAUdLNHRxkhp1vUP2bo6/mgnG7I8f+CrJT8jHbAzVgWg dt8mpnalThDBAvV4EbXedaRLm2uxNQtfTfuLIC6PjG/aBA6A2cSzotkt8zc1XhgJ csPZZ1aG5679Kb42pZLpzFSrm/W7gsZAh8X8FFnMdxm237jzG52sRUYFTVupEgk1 IbsO550SDWFsTR05HXk+St0CO3tSSJvKmVGst+wlq5066hb0kIInNQ== =l6jd -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 25 11:07:50 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 A45CD1A8AB9 for ; Thu, 25 Jun 2015 11:07:47 -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 7MkM9_4jh5YU for ; Thu, 25 Jun 2015 11:07:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2D11A8A7F for ; Thu, 25 Jun 2015 11:07:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8CECE200A3 for ; Thu, 25 Jun 2015 14:22:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A642A63AE8; Thu, 25 Jun 2015 14:07:43 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A10963AD9 for ; Thu, 25 Jun 2015 14:07:43 -0400 (EDT) From: Michael Richardson To: "anima-bootstrap\@ietf.org" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3C98@xmb-rcd-x14.cisco.com> References: <11466.1435154789@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3C98@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: Subject: [Anima-bootstrap] MB review of Bootstrap charter (was: 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: Thu, 25 Jun 2015 18:07:47 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: mb> - Probably a nit: I'm missing the words "trust infrastructure". To me, mb> we're setting up a trust infrastructure, and we also need to discuss mb> the setup of the registrar, CA, not only the bootstrapping mb> elements. The word "trust" is completely missing - is there are reason mb> for it? The document does discuss registrar, CA, etc, but we have not been discussing those in our meeting. I think that the interface to those things are relatively well described by current specifications: but there will be profile work require, I'm sure. mb> - Goal 1: Is this the certificate format and fields? I wasn't sure what "Goal" text you are referring to here, then I realized that you were referring to the DT Charter text that says: > Goal one: Provide a normative definition for the concept of a > Domain's Identity. I'm not sure that we have really much work to do in certificate format and fields. The IDevID 802.1AR document is woefully underspecified on what goes into the SubjectAltName, and I think we need to be more precise here, and maybe that will require a new document. (such as: https://tools.ietf.org/html/draft-richardson-6tisch-idevid-cert-01 which is entirely stolen from RFC3779 ) mb> - Goal 2: I think security needs to also be discussed in the reference mb> model, we need to see how we can split that? Or do you see that the mb> bootstrap doc would cover that all? Here is the text from the charter: > Goal two: Define the target underlying security model of an autonomic > network, in which autonomic devices are enrolled with a local > certificate (e.g: IEEE 802.1AR LDevID) identifying the autonomic > domain that they belong to by hash of the public key of the trust > anchor. I think that the important part for the reference model is that: "Devices have 802.1AR IDevIDs, with replaceable LDevIDs" Should the reference model/framework include ideas of device resell, and the problems of supply chain management? If so, then I would love to have a place to put those considerations. mb> - I think there is overlap with the netconf zero-touch work, and we mb> should probably be explicit: Do we want to find common groud (would mb> hope so), or is it too late? Since that has been discussed, we should mb> be explicit about this point I think. Which other groups do you have in mb> mind when talking about "adjacent IETF WGs"? Can we list them? I think that netconf zero-touch work is useful and interesting, but I also see it as in some ways completely unrelated. That might be just how I regard the work, as a kind of uber-secure, NAT and end-user friendly replacement for DHCPv4+TFTP to get configuration files/boot images. As such, in the netconf situation, devices show up on (preconfigured) networks, and call home (for various definitions of "home") to get a configuration has been determined by mechanisms out of scope. In ANIMA, devices only call home to establish ownership and to affect delegation of of trust. The network that they are "plugged" into may be hostile, may be unconfigured or mis-configured... Further, the goal of the bootstrap is not to establish the configuration of the device, but rather to build a trust relationship with other devices so that each device can derive it's own configuration. Having said, this the bootstrap work could be used to provide security to the zero-touch work, or the netconf zero-touch process could be used to install the locally significant certificates that bootstrap is about. Or EST or 6top or.. mb> - somewhere the charter should state more explicitly: Define protocols mb> and data models for the bootstrap process. I guess that's goal 3, but mb> it sounds cryptic. To me, we need 1) requirements, 2) a protocol, 3) a mb> data model, including certificate format and fields. Goal 3 is about how to use the LDevID; this might mean explaining how it fits into TLS, DTLS, IKEv2, DHCPv6, SEND or some other protocol that the signaling system might base it's security on. mb> - in the reference model I'm referring to the bootstrap process in a mb> new way, in the ASA thinking. There is an ASA for a new element, one mb> for the proxy, and one for the registrar. (Previously those functions mb> were included in the infrastructure, but logically they should be mb> ASAs). Do you agree with this thinking, and if so, should we adopt mb> this wording here as well? If you are saying that the proxy and the registrar are functions that the network should realize that it needs to provide, and therefore should be described as ASAs, then I agree. This implies that we have to run the signaling protocol recursively, and that we have to have more than one instance of the signaling protocol: one insecure instance, and possibly multiple secure instances. One shouldn't assume there is a single network being assembled.. after all, a field can contain many picnics: https://www.pinterest.com/pin/216595063299304430/ mb> - Do we want to include downloading a config? (I read "optimized mb> configuration distribution) - somehow that doesn't seem to be in scope, mb> in my reading. Can we exclude that? To me, the process ends when the mb> device has a domain cert. Max, can you say more about Goal five? mb> - The milestone is very cryptic. Are we planning a new spin of mb> draft-pritikin before the IETF? Or is this a completely new draft? mb> you say "draft(s)" - what does that mean? Yes, spin it. > Michael >> the charter for the WG, and the result is at: >> https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap Charter: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap%20Design%20Team%20Charter -- 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) iQEVAwUBVYxDb4CLcPvd0N1lAQKIHQf/b9wzU+KpNBOb0TazxrPng0K56ymULWHp c9+aicUNOC+JFkcLOLEZoLlSwtS01n4eF8g4X/9ocLJYAu3kXlPVhkFhp5POkpqU Ug1CkJzuhWrEPgacsGvnKEJun5Z2MG+HA1DAnx4d0fLgj9BxqaCWeQHXQP2yhOfp LY+Ne5UDJs/aJPaLrszcHj8+dOXLGIUMJqPpugHeJ3mjholPQpeNuX5agAf4J+MZ YYrmOUpp2u91KCfidyBp3+Do7IVfxQTJdfdZ0aGFTeqAerDyg8ZX14FRcX4V/sEa U2fVjs4JIFuq85fwqgLfiYto/WKnuoA9MnkwTHH3uybeEmZqbQBB2w== =PUN1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 25 11:09:47 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 9DF241A9251 for ; Thu, 25 Jun 2015 11:09: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 zU0T5TUb27RD for ; Thu, 25 Jun 2015 11:09:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02B01A9250 for ; Thu, 25 Jun 2015 11:09:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D9EB6200A3 for ; Thu, 25 Jun 2015 14:24:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 20E5763AE8; Thu, 25 Jun 2015 14:09:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 02BD063AD9 for ; Thu, 25 Jun 2015 14:09:42 -0400 (EDT) From: Michael Richardson To: "anima-bootstrap\@ietf.org" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@xmb-rcd-x14.cisco.com> References: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@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: 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: Thu, 25 Jun 2015 18:09:45 -0000 --=-=-= Content-Type: text/plain 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. 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. -- 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) iQEVAwUBVYxD5YCLcPvd0N1lAQLEbgf8C6Isc6fOCTBR7q1MpDRcUeHYRINT5YH0 a2k2SM4B59mqzGS2KCeF/vLGMrARuqbftXDbU837Ovzprmynyxh0FqMivBiojE/o F8bip3OJ31BhCgrxcLWvM+WUpxv3YePIKRkKOiU40/hwRzM1UMHcYLyY6QMqNO2d P4XcuXSZTNV2wxzvSsqbJHOM7oafQY9IkIFSjkXdp3UyERxghxabl624IvxmcrUk UtuJVMlCn3xNxXvdPywRUzRv9o4N+GXrUwJLbGnSI6B+QEnRvjz3db9lYvyFz1V1 r93SwZ6uk5ScqDap6jbDRI6QIeVO/98z5ANEdrVDt+2XxWxXj63ygg== =RaI2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 00:03: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 C69EC1B3469 for ; Fri, 26 Jun 2015 00:03:22 -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 y7DJaORLKhxS for ; Fri, 26 Jun 2015 00:03:21 -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 025021B344B for ; Fri, 26 Jun 2015 00:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1904; q=dns/txt; s=iport; t=1435302200; x=1436511800; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=02QA7ZPuqsbdwvZL0nfFbnh+r9uLH4KMTrfxyX4eIKg=; b=hv0574biDZIbsAMqoiYlI+VgseQtilAQzhLZmuD16Bc8IuJisNqZAN6q iaFWlwBTF2H9gA1Gg2iMS8QnCxpo2PUI5jbxq7GKgcETAtb0jPcJ0i2lJ 9cV6ACTKVKgCi2/LDs8u6z01HfvQ00oEOitR/xSbpgWTIy0QhCTCGTui1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8AwAI+IxV/5hdJa1bgxGBMwa8KGYJh14CgTc4FAEBAQEBAQGBCoQiAQEBAwE6RAcEAgEIEQQBAQEKFAkHMhQJCAIEARIIiB8Izl0BAQEBAQEBAQEBAQEBAQEBAQEBARiLSoRVOAaDEYEUAQSUBgGkCiaCDByBUm+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,682,1427760000"; d="scan'208";a="4850991" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 26 Jun 2015 07:03:20 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q73KUS009540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 07:03:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.179]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 26 Jun 2015 02:03:20 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] Meeting notes from 6/24 Thread-Index: AQHQrpw25He/nRrryEWW5og8lcmLtJ273TDwgAH9n4CAAINGsA== Date: Fri, 26 Jun 2015 07:03:19 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF5C41@xmb-rcd-x14.cisco.com> References: <6CC122F1-FAC4-4A06-BBC0-D32C8BAEBD2D@cisco.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF22FF3D12@xmb-rcd-x14.cisco.com> <19598.1435255781@sandelman.ca> In-Reply-To: <19598.1435255781@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 26 Jun 2015 07:03:23 -0000 > -----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 >=20 >=20 > 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 se= cure > > model as a reference, then in section 6, explains alternative model= s > > 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 ;-) >=20 > I think that this is the best way. Good - we're on the same page.=20 =20 > 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:= =20 1. the act of mitigating, or lessening the force or intensity of something = unpleasant, as wrath, pain, grief, or extreme circumstances:=20 Social support is the most important factor in the mitigation of stress amo= ng adolescents. 2. the act of making a condition or consequence less severe:=20 the mitigation of a punishment. 3. the process of becoming milder, gentler, or less severe.=20 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 s= ecure options, you SHOULD feel bad :-)=20 Call it "less secure options" - that's what it is.=20 Michael