From nobody Sat Feb 1 13:46:16 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659FF1200F9; Sat, 1 Feb 2020 13:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ls_XKe39cMS; Sat, 1 Feb 2020 13:46:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB98B12004A; Sat, 1 Feb 2020 13:46:08 -0800 (PST) Received: from dooku.sandelman.ca (dc3829c8a.static.telenet.be [195.130.156.138]) by relay.sandelman.ca (Postfix) with ESMTPS id EB53B1F45B; Sat, 1 Feb 2020 21:46:04 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3BEDA1A38D2; Sat, 1 Feb 2020 22:46:04 +0100 (CET) From: Michael Richardson To: Benjamin Kaduk cc: "spasm\@ietf.org" , EMU WG In-reply-to: <20200118034732.GZ80030@kduck.mit.edu> References: <26119.1579299579@localhost> <20200118034732.GZ80030@kduck.mit.edu> Comments: In-reply-to Benjamin Kaduk message dated "Fri, 17 Jan 2020 19:47:32 -0800." X-Mailer: MH-E 8.6; nmh 1.7.1-RC3; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sat, 01 Feb 2020 22:46:04 +0100 Message-ID: <22097.1580593564@dooku> Archived-At: Subject: Re: [Emu] [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP. X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 21:46:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable {did I answer this already?} Benjamin Kaduk wrote: > You mention in a couple places that EAP server certificate should be > identifying an rfc822Name DN, and I think I'm confused about what you > mean. (I suspect I'm seeing "rfc822Name" and jumping to what ACP doe= s, > which is wrong.) Could you walk through an example of what that would > look like to help un-confuse me? There is no connection to the ACP situation. I think that the idea is that the ESSID would be set to an FQDN, and the EAP-TLS server certificate would have the same FQDN in the rfc822Name. Given ACME dns-01 type challenge, that would provide evidence that the entity was authoritative for the name. In a LE ACME certificate that w= as issued via dns-01, I found two policy OIDS: 1.3.6.1.4.1.44947.1.1.1 (unknow= n) and 2.23.140.1.2.1 (domain-validated). I think that domain-validated can mean http-01 or dns-01, but I don't know. I don't know if the above mechanism really works. I don't think that this would matter if the goal was TEAP-BRSKI, because we can pin an EE certificate from any origin. Once the voucher is issued, then the pledge will download a new set of trust anchors, so it doesn't really matter once the device is enrolled.=20=20 It can then use the new trust anchor with (any) other EAP mechanisms to con= nect afterwards. Critically, if the trust anchor is a public anchor, then the client needs to pin the rfc822Name as well as the anchor, otherwise any EE issued by the public trust anchor could be a valid authenticator. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl418ZsACgkQlUzhVv38 QpA0wwf9GOSKSH5jBBoOezrPZ96V80bMASTgqSPV5+IZBgPlOpqFVNZfgJ8FX1Bw DYYzqXnPywRxTXyD9tTvzMnAtK0UzShNurMAV1f6hqmf/ZjJGKiDqDk5uSyBOLFx bYGiP3Y86KXd7jCGzqLUMIyDqJTLPvWr+5BJOfYige6kIB+DijUxgwvsb5MI/OpS ud+7KQLDyr7HFasZaB0bOGJMRoRAkXW+f/mc0opLyjJfptrR5Os0PRpwSnFs2Fn7 ctYENFqFyHqWVH6OLnzHmOspFzIYFpHoDD2yTATSPR8u7nh7AvksECTDdK4557WN KnRP7bvw4MZyQf3Z3C5x90MuYaCDUg== =sS8b -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 28 14:36:48 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6902B3A1B2F; Fri, 28 Feb 2020 14:35:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: emu@ietf.org, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292930641.19931.13093360950579390164@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:06 -0800 Archived-At: Subject: [Emu] emu - Requested session has been scheduled for IETF 107 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:13 -0000 Dear Mohit Sethi, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. emu Session 1 (2:00 requested) Tuesday, 24 March 2020, Afternoon Session I 1330-1530 Room Name: Regency E size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/emu.ics Request Information: --------------------------------------------------------- Working Group Name: EAP Method Update Area Name: Security Area Session Requester: Mohit Sethi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: saag tls cfrg lwig Technology Overlap: curdle uta secdispatch oauth mls t2trg pearg lake Key Participant Conflict: sacm quic kitten bier acme 6lo lamps abcd ace People who must be present: Jari Arkko Joseph A. Salowey Roman Danyliw Alan DeKok John Mattsson Mohit Sethi Resources Requested: Special Requests: If possible, please schedule early on during the IETF week. ---------------------------------------------------------