From nobody Fri Nov 1 04:08:13 2019 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 0FD771200E0; Fri, 1 Nov 2019 04:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCKyxxZ7_KWj; Fri, 1 Nov 2019 04:08:10 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE07A12004E; Fri, 1 Nov 2019 04:08:09 -0700 (PDT) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C8D15425; Fri, 1 Nov 2019 11:08:04 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <35D3B09D-B540-4465-BA4F-8EB3C34A167B@ericsson.com> Date: Fri, 1 Nov 2019 07:08:03 -0400 Cc: Joseph Salowey , Eliot Lear , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <575D1FD8-9C81-4DA7-B542-71B6D78E7BAC@deployingradius.com> <35D3B09D-B540-4465-BA4F-8EB3C34A167B@ericsson.com> To: John Mattsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Fri, 01 Nov 2019 11:08:12 -0000 On Nov 1, 2019, at 6:15 AM, John Mattsson = wrote: > I strongly support working group adoption of = draft-dekok-emu-tls-eap-types. Can we make sure to get this document = going, I agree that this is a very needed draft. I think it should = include updates for everything people wants to use. I do not think = draft-ietf-emu-eap-tls13 strictly have to wait for = draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should = be published shortly after. I will do an update to my document shortly. I also added an issue with the EAP-TLS document on GitHub. The = suggestion is to add text which explains how (and why) the EAP Identity = is chosen during resumption: --- The EAP Identity used in resumption SHOULD be the same EAP Identity as = was used during the original authentication. This requirement allows EAP = packets to be routable through an AAA infrastructure to the same = destination as the original authentication. The alternative is to derive the EAP Identity from the identity used = inside of TLS. This derivation is common practice when using = certificates, and works because the "common name" field in the = certificate is typically compatible with EAP, and it contains a routable = identifier such as an email address. This practice cannot be used for = resumption, as the PSK identity may be a binary blob, and it might not = contain a routable realm as suggested by RFC 7542. In some cases, the PSK identity is derived by the underlying TLS = implementation, and cannot be controlled by the EAP authenticator. These = limitations make the PSK identity unsuitable for use as the EAP = Identity. --- Alan DeKok. From nobody Fri Nov 1 04:54:08 2019 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 862E6120838; Fri, 1 Nov 2019 04:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJQW_uYY3Kii; Fri, 1 Nov 2019 04:54:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A03120834; Fri, 1 Nov 2019 04:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8986; q=dns/txt; s=iport; t=1572609244; x=1573818844; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=sWFj0hvAJmkfLOXMsykb5QkNGV/uDaKF/2zlx7Alm2Y=; b=JpJXO3QiMABIP+jr/x22dkUDojg2W9sUdD6/VnvqK2ckspvLsjpDa/ja sJ4npqgUXKHsN5StnuFftJCBWo3pkovMZZREGmVO2c4q7uasClJhTggD3 Z3o2SwR7j/LtDPX23pInB7+IjSvcndtxbVPfvsPnn/K2AS0mL1zt8JmCI c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAAB8G7xd/xbLJq1cCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF9g2EgEiqEKIkDiBmTGoYjgWcCBwE?= =?us-ascii?q?BAQkDAQEvAQGEQAKEHzgTAgMBAwIDAQEEAQEBAgEFBG2FQ4VRAQEBAQIBI1Y?= =?us-ascii?q?FCwsYKgICVwYTgyIBglcgsQR1gTKFToR1EIE2gVOKVoF/gREnH4JMPoQSAQg?= =?us-ascii?q?KAQkGgyAygiwElVlhiDSPBIIugjOBE5FvG4I8h1qECocOhDeQAJR9gxcCBAY?= =?us-ascii?q?FAhWBaSJncTMaCBsVZQGCQT4SEBSRTUADMIw8gjABAQ?= X-IronPort-AV: E=Sophos;i="5.68,254,1569283200"; d="asc'?scan'208,217";a="18628372" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 11:54:01 +0000 Received: from [10.61.230.56] ([10.61.230.56]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1Bs0Lk005048 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Nov 2019 11:54:01 GMT From: Eliot Lear Message-Id: <257044BF-5F82-4A08-861B-71F58100981C@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B08BFD61-8099-493E-81BE-43F0145CB87F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 1 Nov 2019 12:53:59 +0100 In-Reply-To: <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> Cc: John Mattsson , Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG To: Alan DeKok References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <575D1FD8-9C81-4DA7-B542-71B6D78E7BAC@deployingradius.com> <35D3B09D-B540-4465-BA4F-8EB3C34A167B@ericsson.com> <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.230.56, [10.61.230.56] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Fri, 01 Nov 2019 11:54:06 -0000 --Apple-Mail=_B08BFD61-8099-493E-81BE-43F0145CB87F Content-Type: multipart/alternative; boundary="Apple-Mail=_D5A609FD-9664-4740-8FAC-E77F56500BB9" --Apple-Mail=_D5A609FD-9664-4740-8FAC-E77F56500BB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Alan. Please see below. > On 1 Nov 2019, at 12:08, Alan DeKok wrote: >=20 > On Nov 1, 2019, at 6:15 AM, John Mattsson = wrote: >> I strongly support working group adoption of = draft-dekok-emu-tls-eap-types. Can we make sure to get this document = going, I agree that this is a very needed draft. I think it should = include updates for everything people wants to use. I do not think = draft-ietf-emu-eap-tls13 strictly have to wait for = draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should = be published shortly after. >=20 > I will do an update to my document shortly. >=20 > I also added an issue with the EAP-TLS document on GitHub. The = suggestion is to add text which explains how (and why) the EAP Identity = is chosen during resumption: >=20 > --- > The EAP Identity used in resumption SHOULD be the same EAP Identity as = was used during the original authentication. This requirement allows EAP = packets to be routable through an AAA infrastructure to the same = destination as the original authentication. Just a question: why SHOULD and not MUST? >=20 > The alternative is to derive the EAP Identity from the identity used = inside of TLS. This derivation is common practice when using = certificates, and works because the "common name" field in the = certificate is typically compatible with EAP, and it contains a routable = identifier such as an email address. This practice cannot be used for = resumption, as the PSK identity may be a binary blob, and it might not = contain a routable realm as suggested by RFC 7542. >=20 > In some cases, the PSK identity is derived by the underlying TLS = implementation, and cannot be controlled by the EAP authenticator. These = limitations make the PSK identity unsuitable for use as the EAP = Identity. Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for = federated realms (we may both have this wrong). My presumption here is = that an anonymous NAI is always used, but that the realm is what people = would key off of, and this would always be present. But that = presumption doesn=E2=80=99t hold true with the current TEAP update that = we=E2=80=99re working on and that may be problematic. In any case, this = means that that at least the externalized identity can be used to route, = and that normal TLS semantics can be used for authenticating. It does = require that tickets be managed on both ends. My presumption is further that federation doesn=E2=80=99t really occur = beyond the TLS endpoint, of it it does that is entirely an internal = matter for the server. We have a working example of callouts based on = the identity of a client for purposes of authorization, but for = authentication, I would think that would be largely a bad idea, due to = secret sharing issues (when I say =E2=80=9Cfederation=E2=80=9D I mean = that there should be no trust TLS secret sharing). Is my understanding correct? Eliot > --- >=20 > Alan DeKok. >=20 --Apple-Mail=_D5A609FD-9664-4740-8FAC-E77F56500BB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Alan.  Please see below.

On 1 Nov = 2019, at 12:08, Alan DeKok <aland@deployingradius.com> wrote:

On = Nov 1, 2019, at 6:15 AM, John Mattsson <john.mattsson@ericsson.com> wrote:
I strongly support = working group adoption of draft-dekok-emu-tls-eap-types. Can we make = sure to get this document going, I agree that this is a very needed = draft. I think it should include updates for everything people wants to = use. I do not think draft-ietf-emu-eap-tls13 strictly have to wait for = draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should = be published shortly after.

=  I will do an update to my document shortly.

 I also added an issue with the EAP-TLS document on = GitHub.  The suggestion is to add text which explains how (and why) = the EAP Identity is chosen during resumption:

---
The EAP Identity used in resumption SHOULD = be the same EAP Identity as was used during the original authentication. = This requirement allows EAP packets to be routable through an AAA = infrastructure to the same destination as the original = authentication.

Just a question: why SHOULD and not MUST?


The alternative is to derive the EAP Identity = from the identity used inside of TLS. This derivation is common practice = when using certificates, and works because the "common name" field in = the certificate is typically compatible with EAP, and it contains a = routable identifier such as an email address. This practice cannot be = used for resumption, as the PSK identity may be a binary blob, and it = might not contain a routable realm as suggested by RFC 7542.

In some cases, = the PSK identity is derived by the underlying TLS implementation, and = cannot be controlled by the EAP authenticator. These limitations make = the PSK identity unsuitable for use as the EAP Identity.

Ok, = so this sort of impacts the other drafts as well (NOOB and TEAP) for = federated realms (we may both have this wrong).  My presumption = here is that an anonymous NAI is always used, but that the realm is what = people would key off of, and this would always be present.  But = that presumption doesn=E2=80=99t hold true with = the current TEAP update that we=E2=80=99re working on and that may be = problematic.  In any case, this means that that at least the = externalized identity can be used to route, and that normal TLS = semantics can be used for authenticating.  It does require that = tickets be managed on both ends.

My = presumption is further that federation doesn=E2=80=99t really occur = beyond the TLS endpoint, of it it does that is entirely an internal = matter for the server.  We have a working example of callouts based = on the identity of a client for purposes of authorization, but for authentication, I would think that = would be largely a bad idea, due to secret sharing issues (when I say = =E2=80=9Cfederation=E2=80=9D I mean that there should be no trust TLS = secret sharing).

Is my understanding = correct?

Eliot


---

 Alan DeKok.


= --Apple-Mail=_D5A609FD-9664-4740-8FAC-E77F56500BB9-- --Apple-Mail=_B08BFD61-8099-493E-81BE-43F0145CB87F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl28HNcACgkQh7ZrRtnS ejOI8wf/UrEOqYYv0u4wADC+SEM9+a4zNeFWbFDzAA2d5wW4C5Pj5I4R/+m0vp1p R2762V3E1AHs/zov6dmo60vsQWfaDbUsQ6ziCO2iN3r2+X4y8+fjZAXSYpPrNS2S O3sgoUDJPKegP4waSiitJEQjCxEOWpW4zCTz/UZyhnQCjKRk3VXq44x982WL/6q4 1lFNTNgTnB9EiIGEYwLg8bkwQgeBfVqu9ZmY70I9Urwh3VuadwJYIS1p/C0GtrUM pDLGg+OkjHl9CvtKNd+BqOVx68h00HxhiStLGHOw/GPjABEvwuGtsY5gq3I/WE4c 2W6FiMMWRLRRLIg1pNvHSpLg4VEDWw== =akxR -----END PGP SIGNATURE----- --Apple-Mail=_B08BFD61-8099-493E-81BE-43F0145CB87F-- From nobody Fri Nov 1 05:06:04 2019 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 03F6A120894; Fri, 1 Nov 2019 05:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdvMzh9IHmHl; Fri, 1 Nov 2019 05:05:57 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D82120855; Fri, 1 Nov 2019 05:05:57 -0700 (PDT) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 0475B49B; Fri, 1 Nov 2019 12:05:54 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <257044BF-5F82-4A08-861B-71F58100981C@cisco.com> Date: Fri, 1 Nov 2019 08:05:53 -0400 Cc: John Mattsson , Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <575D1FD8-9C81-4DA7-B542-71B6D78E7BAC@deployingradius.com> <35D3B09D-B540-4465-BA4F-8EB3C34A167B@ericsson.com> <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> <257044BF-5F82-4A08-861B-71F58100981C@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Fri, 01 Nov 2019 12:06:03 -0000 On Nov 1, 2019, at 7:53 AM, Eliot Lear wrote: >=20 >> The EAP Identity used in resumption SHOULD be the same EAP Identity = as was used during the original authentication. This requirement allows = EAP packets to be routable through an AAA infrastructure to the same = destination as the original authentication. >=20 > Just a question: why SHOULD and not MUST? I'm happy to have it a MUST. I'm prepared for some people to say it can be different, i.e a = different AAA server can be used for resumed sessions. But I don't see = that as important. >> The alternative is to derive the EAP Identity from the identity used = inside of TLS. This derivation is common practice when using = certificates, and works because the "common name" field in the = certificate is typically compatible with EAP, and it contains a routable = identifier such as an email address. This practice cannot be used for = resumption, as the PSK identity may be a binary blob, and it might not = contain a routable realm as suggested by RFC 7542. >>=20 >> In some cases, the PSK identity is derived by the underlying TLS = implementation, and cannot be controlled by the EAP authenticator. These = limitations make the PSK identity unsuitable for use as the EAP = Identity. >=20 > Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) = for federated realms (we may both have this wrong). My presumption here = is that an anonymous NAI is always used, but that the realm is what = people would key off of, and this would always be present. As the EAP Identity, yes. > But that presumption doesn=E2=80=99t hold true with the current TEAP = update that we=E2=80=99re working on and that may be problematic. In = any case, this means that that at least the externalized identity can be = used to route, and that normal TLS semantics can be used for = authenticating. It does require that tickets be managed on both ends. If the authentications are performed within a constrained system, it's = fine to skip using NAIs. I would suggest that for device bootstrapping = you want to ensure that the authentications *aren't* routed outside of = the current network. So they *shouldn't* use a realm. That's why my suggested text said "resumption uses same identity as = the original authentication" .... whatever that is. That initial = identity doesn't need to be an NAI. However, the identities still need to be acceptable to EAP / AAA = systems. Which means that any binary identity should likely be = converted to a "printable" form, via something like base64. > My presumption is further that federation doesn=E2=80=99t really occur = beyond the TLS endpoint, of it it does that is entirely an internal = matter for the server. Yes. Federation works because nothing examines the contents of EAP. = Instead, the packets are routed solely based on the NAI. > We have a working example of callouts based on the identity of a = client for purposes of authorization, but for authentication, I would = think that would be largely a bad idea, due to secret sharing issues = (when I say =E2=80=9Cfederation=E2=80=9D I mean that there should be no = trust TLS secret sharing). >=20 > Is my understanding correct? Yes. There may be federations which share a common CA cert. But each = authentication system is unique, and does not share its secrets / = identity with any other system. Aln DeKok. From nobody Fri Nov 1 06:15:00 2019 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 A9725120125; Fri, 1 Nov 2019 06:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txQyW4GLR9a6; Fri, 1 Nov 2019 06:14:56 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FB41200F1; Fri, 1 Nov 2019 06:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3678; q=dns/txt; s=iport; t=1572614096; x=1573823696; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=jvQnWUZl91fntIKVNpUPR5vMiPUNRHpdosUsvk60JHA=; b=H9lajSMFbdqurjx+Pa5vNainxFabj0/hOxwpcwuauf/QBXfH0YuaOL8n TInqy754eozgp7iZUSsYbSKH4irxDG73m1ifIbv7YbT5rVYiuj33BL7IQ xWSQruzKHFFd4XWEDi3zPMCwi6OakIGVE8G3uddTk3x992N5+A71CLLzz I=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAACdL7xd/xbLJq1cCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYF9g2ABIBIqhCiJA4gYmT6BZwIHAQE?= =?us-ascii?q?BCQMBAS8BAYRAAoQfOBMCAwsBAQQBAQECAQUEbYVDhVEBAQEBAgEjVgULCxg?= =?us-ascii?q?qAgJXBhODIgGCVyCxKnWBMoVOhHYQgTaBU4pWgX+BEScfgkw+hBIBCAoBCQa?= =?us-ascii?q?DIDKCLASVWWGXOIIugjOBE5FvG4I8i2SLRZAAlH2DFwIEBgUCFYFpImdxMxo?= =?us-ascii?q?IGxVlAYJBPhIRFJFLAkADMIw8gjABAQ?= X-IronPort-AV: E=Sophos;i="5.68,255,1569283200"; d="asc'?scan'208";a="18643820" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 13:14:35 +0000 Received: from [10.61.230.56] ([10.61.230.56]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1DEX9a032723 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Nov 2019 13:14:34 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BE0325C9-B529-4B1C-BE5C-B16699E394F1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 1 Nov 2019 14:14:33 +0100 In-Reply-To: Cc: John Mattsson , Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG To: Alan DeKok References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <575D1FD8-9C81-4DA7-B542-71B6D78E7BAC@deployingradius.com> <35D3B09D-B540-4465-BA4F-8EB3C34A167B@ericsson.com> <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> <257044BF-5F82-4A08-861B-71F58100981C@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.230.56, [10.61.230.56] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Fri, 01 Nov 2019 13:14:59 -0000 --Apple-Mail=_BE0325C9-B529-4B1C-BE5C-B16699E394F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! > On 1 Nov 2019, at 13:05, Alan DeKok wrote: >=20 > On Nov 1, 2019, at 7:53 AM, Eliot Lear wrote: >>=20 >>> The EAP Identity used in resumption SHOULD be the same EAP Identity = as was used during the original authentication. This requirement allows = EAP packets to be routable through an AAA infrastructure to the same = destination as the original authentication. >>=20 >> Just a question: why SHOULD and not MUST? >=20 > I'm happy to have it a MUST. >=20 > I'm prepared for some people to say it can be different, i.e a = different AAA server can be used for resumed sessions. But I don't see = that as important. >=20 >>> The alternative is to derive the EAP Identity from the identity used = inside of TLS. This derivation is common practice when using = certificates, and works because the "common name" field in the = certificate is typically compatible with EAP, and it contains a routable = identifier such as an email address. This practice cannot be used for = resumption, as the PSK identity may be a binary blob, and it might not = contain a routable realm as suggested by RFC 7542. >>>=20 >>> In some cases, the PSK identity is derived by the underlying TLS = implementation, and cannot be controlled by the EAP authenticator. These = limitations make the PSK identity unsuitable for use as the EAP = Identity. >>=20 >> Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) = for federated realms (we may both have this wrong). My presumption here = is that an anonymous NAI is always used, but that the realm is what = people would key off of, and this would always be present. >=20 > As the EAP Identity, yes. >=20 >> But that presumption doesn=E2=80=99t hold true with the current TEAP = update that we=E2=80=99re working on and that may be problematic. In = any case, this means that that at least the externalized identity can be = used to route, and that normal TLS semantics can be used for = authenticating. It does require that tickets be managed on both ends. >=20 > If the authentications are performed within a constrained system, = it's fine to skip using NAIs. I would suggest that for device = bootstrapping you want to ensure that the authentications *aren't* = routed outside of the current network. So they *shouldn't* use a realm. Ok. Got it. I think we have to be quite careful about use of the = realm, then, and mechanism selection must be done exclusively with = EAP-Request/Type. I think it=E2=80=99s okay for federations to = bootstrap; although we needn=E2=80=99t define that here. I=E2=80=99ll be updating our draft accordingly. Eliot --Apple-Mail=_BE0325C9-B529-4B1C-BE5C-B16699E394F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl28L7kACgkQh7ZrRtnS ejMSXgf/R19sVTNh+hGBOmJ7iIz2EmNcBK+gRFBiVO/L7P0KamdfL1WeAKRf74aj 3vR85L3YBhryQsJGgXAfaqDYF4frirvhS6eZ4GTgByQkcbCPFyoT5Uf98LA1vjui tn3pfZKKf9UBGB/O9V6qzrBqJURqxkOZBfPWK9VbZO6WezQDXWXk8J0Jv4NQ/WRr 3a4Tc+TtxxOzYOd2Eqm695bVjPN9LxJXTi5rGbbdhnxek1bxXs7vKhUnsYYvD5zh LIj7YOJryI/165VCu2sQaHX+2p57O8XEHt1uUfMEjvYui9hgL19yb9tArTMhzgAO 4Gooe9Mf/QOsrTSjmAScGsL99WXArg== =R1sk -----END PGP SIGNATURE----- --Apple-Mail=_BE0325C9-B529-4B1C-BE5C-B16699E394F1-- From nobody Fri Nov 1 09:22:39 2019 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 390A1120A54; Fri, 1 Nov 2019 09:22:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Cc: emu@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157262534717.31915.16550102966510523902.idtracker@ietfa.amsl.com> Date: Fri, 01 Nov 2019 09:22:27 -0700 Archived-At: Subject: [Emu] WG Review: EAP Method Update (emu) 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, 01 Nov 2019 16:22:32 -0000 The EAP Method Update (emu) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-11-11. EAP Method Update (emu) ----------------------------------------------------------------------- Current status: Active WG Chairs: Joseph Salowey Mohit Sethi Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: emu@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu Group page: https://datatracker.ietf.org/group/emu/ Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/ The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used, for instance, in VPN and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Several EAP methods have been developed at the IETF and support for EAP exists in a broad set of devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol specification and the development of several standards track EAP methods. EAP methods are generally based on existing security technologies such as Transport Layer Security (TLS) and mobile network Authentication and Key Agreement (AKA). Our understanding of security threats is continuously evolving. This has driven the evolution of several of these underlying technologies. As an example, IETF has standardized a new and improved version of TLS (v1.3) in RFC 8446. The group will therefore provide guidance and update EAP method specifications where necessary to enable the use of new versions of these underlying technologies. At the same time, some new use cases for EAP have been identified. EAP is now more broadly used in mobile network authentication. The group will update existing EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. Perfect Forward Secrecy (PFS) is an important security property for modern protocols to thwart pervasive monitoring. The group will work on an extension to EAP-AKA' for providing PFS. Out-of-band (OOB) refers to a separate communication channel independent of the primary in-band channel over which the actual network communication takes place. OOB channels are now used for authentication in a variety of protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users are accustomed to tapping NFC or scanning QR codes. However, EAP currently does not have any standard methods that support authentication based on OOB channels. The group will therefore work on an EAP method where authentication is based on an out-of-band channel between the peer and the server. EAP authentication is based on credentials available on the peer and the server. However, some EAP methods use credentials that are time or domain limited (such as EAP-POTP), and there may be a need for creating long term credentials for re-authenticating the peer in a more general context. The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials. In summary, the working group shall produce the following documents: * An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). This document will update the security considerations relating to EAP-TLS, document the implications of using new vs. old TLS versions. It will add any recently gained new knowledge on vulnerabilities and discuss the possible implications of pervasive surveillance. * Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. Provide guidance or update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on errata found in published specifications (such as EAP-TEAP). * Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently discovered bug in the original RFCs. * Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance. * Develop an extension to EAP-AKA' such that Perfect Forward Secrecy can be provided. There may also be privacy improvements that have become feasible with the introduction of recent identity privacy improvements in 3GPP networks. * Gather experience regarding the use of large certificates and long certificate chains in the context of TLS based EAP methods, as some implementations and access networks may limit the number of EAP packet exchanges that can be handled. Document operational recommendations or other mitigation strategies to avoid issues. * Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself should be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light. * Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials. The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for work on TLS based EAP methods), and the 3GPP security architecture group (for EAP-AKA' work). Milestones: Nov 2019 - WG last call on operational recommendations for large certificate and chain sizes Nov 2019 - WG last call on definition of session identifiers for fast re- authentication in EAP-SIM and EAP-AKA Nov 2019 - WG adopts initial draft addressing the errata found in EAP-TEAP Nov 2019 - WG adopts initial draft on an EAP method for mutual authentication based on an OOB channel Nov 2019 - WG adopts draft providing guidance for use of TLS 1.3 with TLS based EAP methods Jan 2020 - WG adopts initial draft on creation of long-term credentials for EAP peer based on initial limited-use credentials Mar 2020 - WG last call on extension to EAP-AKA to support forward secrecy From nobody Sun Nov 3 10:31:27 2019 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 CB9A51200F1 for ; Sun, 3 Nov 2019 10:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPVFYYZkwROl for ; Sun, 3 Nov 2019 10:31:21 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF201200CC for ; Sun, 3 Nov 2019 10:31:21 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id e2so15426890qkn.5 for ; Sun, 03 Nov 2019 10:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d5j3V8IGKGsW2AjZM91HUi3pmadbk6C3q/X1yJGRbj4=; b=o0c6zacw7hmmAt+NL6F3T11h8O+8Kl5nDeZHA8xPkGRFdYnwM6vO0BszJyvVYuxKRb aysBhvH++Cqob0DiNYKEoPf9B08TOCVbCZ/Q4XP9DV6hn42z6dAwvnI4BkAnsV/Ho221 M6EZUKCjc1C/JJcXYCWlW/zlmX3qU9LSq9/RFHdyrf0GJD8VaZ4oZHAgHvuVMK2mgz8y 5HQrhvTtWXmyiH7NhlNxJHaPBtwnbmxeRrzAU6eO5qnylu83nu/KxRflnauhGgdY0xoc S9HbQFaVbVlbyLNoH8Am2QCnK+rJr7RUN8bqASd9y/23MBjbnTeV/M90KVtLGDcnCyZp sXiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d5j3V8IGKGsW2AjZM91HUi3pmadbk6C3q/X1yJGRbj4=; b=HrPLwFuPF+HUjRBKAov9R2T/wxo4dZUSPI0hC0lzZlxVzCz7QaQr/haMM9uhZu+EqM XnPfLYPAudrRAayFbU4K377W3izDJPP2VNb50NhxzL3KDqzNFt0+zXI9PqOgGg5Lrbyx Y6taDPNt7vvmxFnPxV9mXpp1cWFuxIKQr63CUl2JOdpG8TuzMrvG+alpZ05FrKmpqkqp dFbw+MQVyAbfosRZ0/cZODMTngCjqRPFxXu/SDtnjk69d4QrGCm25ilSPTtfj8Q0TSIZ WCRovapQnzkutgnYMBrO+H8OX0y51Zl6iizEQRrBVSmhqg+SV6QcWeZgRiOh4IJcGnJF g2rA== X-Gm-Message-State: APjAAAXYHS31kY0e53WrvnHt/kgqRhpVXaUvbMAmzzQbo47FIgnyJGki qbJn7+cFoHAh3NoA5gCuqr9O8+rF8J/dk4HJcpyGBw== X-Google-Smtp-Source: APXvYqxZuzBEAZgUPX9YwYgv3+C/BcNlzZ0vOLBtUmpFuncHrCed3KIE6YYlhBPIQx8GvfXr43TggELDHy0/ASPK2Kc= X-Received: by 2002:a37:9145:: with SMTP id t66mr4834539qkd.332.1572805880299; Sun, 03 Nov 2019 10:31:20 -0800 (PST) MIME-Version: 1.0 References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <575D1FD8-9C81-4DA7-B542-71B6D78E7BAC@deployingradius.com> <35D3B09D-B540-4465-BA4F-8EB3C34A167B@ericsson.com> <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> In-Reply-To: <3D27AB0E-508E-479D-81A5-42566F166647@deployingradius.com> From: Joseph Salowey Date: Sun, 3 Nov 2019 10:31:09 -0800 Message-ID: To: Alan DeKok Cc: John Mattsson , Eliot Lear , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG Content-Type: multipart/alternative; boundary="000000000000cbd4a905967567f7" Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Sun, 03 Nov 2019 18:31:25 -0000 --000000000000cbd4a905967567f7 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok wrote: > On Nov 1, 2019, at 6:15 AM, John Mattsson > wrote: > > I strongly support working group adoption of > draft-dekok-emu-tls-eap-types. Can we make sure to get this document going, > I agree that this is a very needed draft. I think it should include updates > for everything people wants to use. I do not think draft-ietf-emu-eap-tls13 > strictly have to wait for draft-dekok-emu-tls-eap-types, but > draft-dekok-emu-tls-eap-types should be published shortly after. > > I will do an update to my document shortly. > > I also added an issue with the EAP-TLS document on GitHub. The > suggestion is to add text which explains how (and why) the EAP Identity is > chosen during resumption: > > --- > The EAP Identity used in resumption SHOULD be the same EAP Identity as was > used during the original authentication. This requirement allows EAP > packets to be routable through an AAA infrastructure to the same > destination as the original authentication. > > The alternative is to derive the EAP Identity from the identity used inside > of TLS. This derivation is common practice when using certificates, and > works because the "common name" field in the certificate is typically > compatible with EAP, and it contains a routable identifier such as an email > address. This practice cannot be used for resumption, as the PSK identity > may be a binary blob, and it might not contain a routable realm as > suggested by RFC 7542. > > [Joe] Do implementations use the whole common name or just the domain portion. Using the whole common name is not advisable with TLS 1.3. > In some cases, the PSK identity is derived by the underlying TLS > implementation, and cannot be controlled by the EAP authenticator. These > limitations make the PSK identity unsuitable for use as the EAP Identity. > [Joe] Is EAP Identity Synonymous with the NAI? > --- > > Alan DeKok. > > --000000000000cbd4a905967567f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 1, 2019, at 6:15 AM, John Matt= sson <jo= hn.mattsson@ericsson.com> wrote:
> I strongly support working group adoption of draft-dekok-emu-tls-eap-t= ypes. Can we make sure to get this document going, I agree that this is a v= ery needed draft. I think it should include updates for everything people w= ants to use. I do not think draft-ietf-emu-eap-tls13 strictly have to wait = for draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should= be published shortly after.

=C2=A0 I will do an update to my document shortly.

=C2=A0 I also added an issue with the EAP-TLS document on GitHub.=C2=A0 The= suggestion is to add text which explains how (and why) the EAP Identity is= chosen during resumption:

---
The EAP Identity used in resumption SHOULD be the same EAP Identity as was = used during the original authentication. This requirement allows EAP packet= s to be routable through an AAA infrastructure to the same destination as t= he original authentication.
=C2=A0
=C2=A0
The alternative is to derive the EAP Identity from the identity used inside= of TLS. This derivation is common practice when using certificates, and wo= rks because the "common name" field in the certificate is typical= ly compatible with EAP, and it contains a routable identifier such as an em= ail address. This practice cannot be used for resumption, as the PSK identi= ty may be a binary blob, and it might not contain a routable realm as sugge= sted by RFC 7542.


[Joe] Do implementations use the whole= common name or just the domain portion.=C2=A0 Using the whole common name = is not advisable with TLS 1.3.=C2=A0=C2=A0
=C2=A0
In some cases, the PSK identity is derived by the underlying TLS implementa= tion, and cannot be controlled by the EAP authenticator. These limitations = make the PSK identity unsuitable for use as the EAP Identity.

[Joe]=C2=A0 Is EAP Identity Synonymous=C2=A0with the= NAI?
=C2=A0
---

=C2=A0 Alan DeKok.

--000000000000cbd4a905967567f7-- From nobody Sun Nov 3 22:59:41 2019 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 DB0A21200A1 for ; Sun, 3 Nov 2019 22:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeTpDj2RROv1 for ; Sun, 3 Nov 2019 22:59:30 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on061d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::61d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3645C12006E for ; Sun, 3 Nov 2019 22:59:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F/pprqiNA20dcWaBPrcy2Ac6iis5uMWSq+wybO8rR9ei+RZPqkCPyUKgjmwwhLtVUu+D7TajBdc56qNij4hLB/z5ZStCUOaQlqcTD5FiYMnz/HSp0MODhDd81AW9IKk5Lq9lJOrjSn1St+1SvJ1rqPncq7qyKz7bWmajc/DxG3zjE8Vm6kj47j8voaNM00miMdgKnG5eD+NpnHJHE/XEvMWbX4ZF0FfNp1r0U4GuNI3hnPGWLopJiuhHw8E9bGSz0vyVX/SZ5hIh2mmBbInl6ovw7EW74LFtd3aXB4Y/DKm2k8Ktgkw6U/9mOULE/1H02YUsv/OFk7LPt11ehtE0bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ucFNPgm9QUsPC4CmsNWrkrZJ/ak7na7NycSE3fMQxaY=; b=nvGAA5Jq5NYNXUu+AxGfDkBMC2U3jJY4qhQq6utWVOdIzl9lzUGGjkMASTkCRec4zGZ6HrkmDezt5NKDDCAB+kzpaVOFZ/+oNlMH7MJN7V34JJ8BhEOX5tcg0gG0QtrM1HhHAASY+v0cDK+ZVAD+9UIIIIvCB6ULk5C2vhy5p+k6FGmbThnt179Q4QD4rt1/UndG6NRGNsVFOwJpkKdv0ggJ8KSiwgp6GQzCm3mtoAh9THNSVV/GHD1JAXuoD7ufMAvY7U+2FpS1ulEgdXmx4qhyLfe7VZHogPBkqLiWwA8x3mM6WumUjn6UdF2nQC/NjM4R2lnBDX3nuBEPJnIpLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ucFNPgm9QUsPC4CmsNWrkrZJ/ak7na7NycSE3fMQxaY=; b=E30SoFIC2zG+tvb95tBAUOXK/MdzEMT7l3azTn3gPdmJN3WW7QdkQm9n9D5q2cJAFesNc57NX8/SmFFBTXZWGRqpgx8dr6ep8ccDy15i/InH13LcWKz2QLPo6C0wxzjlfBz4/M9K6R+IS4YhHJYjQctVvh42XYbIy1B/q3CyDfU= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2428.eurprd07.prod.outlook.com (10.168.123.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 06:59:28 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f%6]) with mapi id 15.20.2408.018; Mon, 4 Nov 2019 06:59:27 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: Agenda Items for IETF 106 Thread-Index: AQHVkt1l56ZSSu0cT02Qfshmg3Rfbg== Date: Mon, 4 Nov 2019 06:59:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [122.180.185.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f3942e7-6e0f-4048-fcae-08d760f488cb x-ms-traffictypediagnostic: HE1PR0701MB2428: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(199004)(189003)(8676002)(31696002)(71190400001)(71200400001)(36756003)(1730700003)(6916009)(2616005)(476003)(58126008)(6512007)(5660300002)(256004)(14444005)(7736002)(8936002)(5640700003)(305945005)(6436002)(486006)(4744005)(102836004)(316002)(6486002)(81166006)(81156014)(2906002)(64756008)(26005)(186003)(31686004)(66476007)(66556008)(66446008)(14454004)(478600001)(66066001)(6116002)(86362001)(65956001)(76116006)(66946007)(99286004)(65806001)(413944005)(2501003)(91956017)(6506007)(3846002)(2351001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2428; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JLt6JI4RXwtZUHsYX2mAGXWC/2L/x2lZIWfdrEo/yMApZBuz5h268OXYvW1+k1n/8qG3mscoWPG1grB+p0mUKLRhaZzwNj1DAg+7HOBfA+MdE0eHPqlMtI9FIy7ctf95wIp4jUTvPGMo2BbgZ+5WspstKFjyAlMQ0ruF4W76O1LP0Xd97r3w+vhaG8cN3p/E56ckkPPUw7SFwZsqUECp2WzVTZmZQ1FNR4Rrnhf3zB2loyCKWuju2bkYUY3TmWV9sZ3J4VWtdcJwkRZYR65noDCU8WX8Mhh8Q3hRVIb65yVetHJWt92eqKmnmNSHRbipX9bXQBkTRpGJhErmQrJmxDM13DTvFWM/bX1FjVBQev/Rh4bsUcrgPTkJFjQc2WKimxipWKHZVPVUjsbQWTDDH29JB70oU46pwwfp7yj/AAW8orLBP+8ZcZVR6mXp21bP x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f3942e7-6e0f-4048-fcae-08d760f488cb X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 06:59:27.8271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xei2kNbHOEcwLtS0L+44FOT6//rpZDFI17hoZJTG8Vg+yn6G2JsIeYOxf52dko+ih6TvGuVrsFZTn48sKsFhoc5k9SQLYxSNaG3Qr9Qfwcc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2428 Archived-At: Subject: [Emu] Agenda Items for IETF 106 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: Mon, 04 Nov 2019 06:59:35 -0000 RGVhciBhbGwsDQoNClNvbWUgb2YgeW91IGhhdmUgYWxyZWFkeSBzZW50IGluIGEgcmVxdWVzdCBm b3IgcHJlc2VudGF0aW9uIHRpbWUgZHVyaW5nIA0KdGhlIEVNVSBzZXNzaW9uIEAgSUVURiAxMDYu IFRoYW5rIHlvdSENCg0KRm9yIHRob3NlIHdobyBoYXZlbid0LCBwbGVhc2Ugc2VuZCBKb2UgYW5k IEkgcmVxdWVzdHMgZm9yIHByZXNlbnRhdGlvbiANCnNsb3RzLiBXZSBoYXZlIGEgMiBob3VyIHNl c3Npb24gb24gTW9uZGF5LCBOb3ZlbWJlciAxOCwgYmV0d2VlbiANCjE1OjUwLTE3OjUwIGluIHJv b20gSHVsbGV0Lg0KDQpEb24ndCBmb3JnZXQgdG8gaW5jbHVkZSB0aGUgdGl0bGUgb2YgeW91ciBw cmVzZW50YXRpb24sIHJlbGF0ZWQgZHJhZnRzLCANCmFuZCB0aGUgYXBwcm94aW1hdGUgYW1vdW50 IG9mIHRpbWUgdGhhdCB5b3UgbmVlZC4NCg0KUGxlYXNlIGFsc28gbGV0IHVzIGtub3cgaWYgeW91 IHBsYW4gdG8gcHJlc2VudCByZW1vdGVseS4NCg0KSm9lIGFuZCBNb2hpdA0KDQo= From nobody Mon Nov 4 07:35:35 2019 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 AE871120124; Mon, 4 Nov 2019 07:35:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <157288173364.16503.10974813017837647353@ietfa.amsl.com> Date: Mon, 04 Nov 2019 07:35:33 -0800 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-eap-session-id-01.txt 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: Mon, 04 Nov 2019 15:35:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP Author : Alan DeKok Filename : draft-ietf-emu-eap-session-id-01.txt Pages : 9 Date : 2019-11-04 Abstract: EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA when using the fast re-authentication exchange instead of full authentication. This document updates RFC 5247 to define those derivations for EAP-SIM and EAP-AKA. Since RFC5448bis defines the Session-ID for EAP-AKA', the definition for EAP-AKA' is not included here. RFC 5247 also does not define Session-Id derivation for PEAP. A definition is given here which follows the definition for other TLS-based EAP methods. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-session-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-session-id-01 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-session-id-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-session-id-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 07:50:06 2019 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 13746120089 for ; Mon, 4 Nov 2019 07:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBGoV0osi9E4 for ; Mon, 4 Nov 2019 07:50:03 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7CC120168 for ; Mon, 4 Nov 2019 07:50:02 -0800 (PST) Received: from [192.168.20.132] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id E7B192B4 for ; Mon, 4 Nov 2019 15:50:00 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 Nov 2019 10:49:59 -0500 References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <575D1FD8-9C81-4DA7-B542-71B6D78E7BAC@deployingradius.com> To: EMU WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Mon, 04 Nov 2019 15:50:05 -0000 After checking the draft again, Section 2.1.4 does have comments about = anonymizing the NAI. But those comments are limited to NAIs derived = from certificates. I think that the text needs to be expanded to make the recommendations = more genetic, and clearer. I hope that my previous message clarified = some of the issues here. I would like to see some discussion of these topics in the draft. I = don't think it's clear enough that the EAP Identity should always be = "@realm", and there is no discussion on EAP Identity and resumption. I would suggest a new section called "Identities". This section could = go after 2.1.1, and incorporate some existing text from the Privacy = section. Suggested text follows. Identities EAP-TLS peer and server implementations supporting TLS 1.3 or higher MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response. It is RECOMMENDED to use anonymous NAIs, but other solutions where the username is encrypted MAY be used. This recommendation applies to all uses of EAP-TLS, no matter the = underlying TLS authentication mechanism. This recommendation also = applies when resumption is used. The anonymous NAI can often be derived automatically. When certificates = are used, the certificate common name is often in the form of an email = address. The anonymous NAI can be derived from that address by using = only the "@realm" portion. This derivation has privacy implications, as = discussed in the Privacy section, below. In some cases, the anonymous NAI cannot be derived from the underlying = TLS authentication mechanism. For example, when PSKs are used, the PSK = identity may be an opaque binary string. Binary data is not compatible = with the EAP Response / Identity field, as Section 5.1 of 3748 requires = that the Identity field be composed solely of UTF-8 encoded ISO 10646 = characters. Instead, the Identity may be statically pre-provisioned. = Or for resumption, the Identity used for resumption SHOULD be the same = as the Identity used for the original authentication.= From nobody Mon Nov 4 15:48:29 2019 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 9712B120090; Mon, 4 Nov 2019 15:48:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <157291130754.13948.7913093997974091692@ietfa.amsl.com> Date: Mon, 04 Nov 2019 15:48:27 -0800 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-aka-pfs-01.txt 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: Mon, 04 Nov 2019 23:48:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS) Authors : Jari Arkko Karl Norrman Vesa Torvinen Filename : draft-ietf-emu-aka-pfs-01.txt Pages : 25 Date : 2019-11-04 Abstract: Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC 5448 (to be superseded by draft-ietf-emu-rfc5448bis). The extension, when negotiated, provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt all past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-01 https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 7 09:30:32 2019 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 609531209A0; Thu, 7 Nov 2019 09:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FVoUYAWW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iJrYzfB7 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 Xf50MfSGGwcs; Thu, 7 Nov 2019 09:30:21 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A191209B7; Thu, 7 Nov 2019 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5174; q=dns/txt; s=iport; t=1573147821; x=1574357421; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=yorFbw+DD3Lu3xPnWH2YAJ3H8Yurv/oeTf6VOz5gHPU=; b=FVoUYAWWa/91z9mRAD7ffKLzWoYUSn/OOUKkeYkUrRn4xJhTibEP5se2 B0udRGQICTcwyqfG2o7Fi/ZPoU37DSaviZZVRIzPUyCSfj7XJjsG6imCd +Sry5MBFRwGfjBP7CuEZS6GP6r/25POhsKqha6f5mUMpa4nDRIpbzLrxD w=; IronPort-PHdr: =?us-ascii?q?9a23=3AD0qT/xHzv8e2JKeOSuuL0p1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAC+U8Rd/4MNJK1bCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBbQIBAQEBCwGBSlAFbFggBAsqhCmDRgOLAoJ?= =?us-ascii?q?ef5Z/gUKBEANUCQEBAQwBASMKAgEBhEACF4N3JDcGDgIDCwEBBAEBAQIBBQR?= =?us-ascii?q?thTcMhVEBAQEBFRERDAEBNwELBgEWAwQBAQECAiMDAgQwFAEICQEEAQ0FCBq?= =?us-ascii?q?DAYJGAy4BAgyncAKBOIhgdYEygn4BAQWFCxiCFwmBDigBjBMYgUA/gRFGghd?= =?us-ascii?q?zgmIBAQIBgSsBCAoBCRiDDjKCLJAHhWOYHgqCJIcXjkWCPHKWRI5GgUCGcZE?= =?us-ascii?q?5AgQCBAUCDgEBBYFoI2dxcBWDJwlHERSQNoNzhRSFP3QBAYEmjVyCMQEB?= X-IronPort-AV: E=Sophos;i="5.68,278,1569283200"; d="scan'208";a="358978626" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2019 17:30:14 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xA7HUAIe031053 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2019 17:30:12 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 11:30:10 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 11:30:09 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Nov 2019 12:30:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oEmkRO5ZMVcXAhkD3QiZ/rYtaxAhPaekJSts5TtwpF9LYfstrmE8qpm9CDNqvqPpmsaUXIB3ef3/oqNQZUTYyYUXGLpxzcmymK3lka4zkhieklS8tI7vkxy0trD7Tn3YX3mloYu/Nf0NmTZj6VwZum1TMIjJSXKxNGmNs3SxQICTrRHBtRvQ2GIVYoBc/d9bA+LpJt9pY9JLuT6E7Rkal8zPOlgWFEIowThHpEQr5YhVpsrEp4VsR+LBjVfxzVWQ/j+jj1lm1717Dz01B3R9V37To9cSi4sTTBgW7OynPDIs1FkDCXk3Dvaga+mOnSbSoddnkIaOzF1rG0ETqoZORQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yorFbw+DD3Lu3xPnWH2YAJ3H8Yurv/oeTf6VOz5gHPU=; b=RqsX24w3kkwPc+Khu+gMM0XMqOVXs3pCXRUv1C6k5zqn0MPkcw8OeZoOxxJAlzrN7BudlhawRo5Te851egVP6UXLn7vbSolBuBJdG+1eMgBIpF9/Yk5cCYBz7aomC3c4LylYSAEUZK8Nn/xID4prqvIS4Uqv5cddHJHvo2BPOAFQJ8r85OcBR0HMuZ+yYR2VPIAqHizganZ1DN4WKY8hqzLETLLIHW+75EwzbBtCGI11mdfWtbxS8/s32gIhmmg6pH2P0hFYewdD5m2BsSMcLglwoaJvWMj4XBP7GTvjHq/ndJgLQdGPvOvm+ULkhI7S7dTWlIjLV49Sit2SW3fZ5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yorFbw+DD3Lu3xPnWH2YAJ3H8Yurv/oeTf6VOz5gHPU=; b=iJrYzfB74oImJFmZDUypzbMcwIXBty1jhkswyh9XHedo2Dnm1oAIx/HZlLV4TmL6Yqx5OPYBiHkTYVTX0UW3hhoWuzjfkNNRTJXzUicI3ieWS4drcSNFOgUp1Ik1JAfb8CZq/dXSAT/IsnR+L5c78VQe+gtptj+QmQvtrDK6bOY= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3648.namprd11.prod.outlook.com (20.178.252.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Thu, 7 Nov 2019 17:30:07 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.023; Thu, 7 Nov 2019 17:30:07 +0000 From: "Owen Friel (ofriel)" To: Joseph Salowey , Alan DeKok CC: "draft-ietf-emu-eap-tls13@ietf.org" , EMU WG , John Mattsson , Michael Richardson Thread-Topic: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13) Thread-Index: AdWVkP6miTdVx/8XQ5+EVyVKdjyrBg== Date: Thu, 7 Nov 2019 17:30:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:4041:1300:6d98:e3fd:9fdd:799e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: caba8765-d35f-45f2-855d-08d763a8223c x-ms-traffictypediagnostic: MN2PR11MB3648: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(13464003)(199004)(189003)(478600001)(99286004)(4326008)(966005)(8676002)(14444005)(256004)(86362001)(81166006)(81156014)(9686003)(55016002)(6306002)(14454004)(76116006)(25786009)(52536014)(66946007)(66556008)(64756008)(66446008)(66476007)(110136005)(486006)(476003)(7696005)(74316002)(305945005)(102836004)(6436002)(7736002)(316002)(53546011)(6506007)(6116002)(5660300002)(46003)(2906002)(54906003)(71190400001)(71200400001)(186003)(33656002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3648; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QAPFbEPEya02Te0Iti/thGEgcY96jllzDcHjt1EPTnKy95ngmgjj9ej+1l4YHrlDCvmK7UbJNLktynFsH55uyKhmb3FKIQzmtf3cRUjV9lKPr5Mav1OUwjv4oCGSFwJkMiOn8oZivOp2jiCG8Q7CIl8Rx9q1cP17KlBEQAyu7c3/czLklRxEU57BGX7LkVvs50L9hAsILEWa016L2L0CkoqC/JKzDng27ZcBPSclxV7KPbAsW1EiclrmeEN9dSLaJWqL+v2cZEG8d1knm8fUk9imNdIkjGwAViRi22uljgzGjLScmiXzGXg87H0E5DL0kNhjUjKmN2mB35yLJZ6njhKX8j+AK0b4bQbBdGRyHGmUIf4hN5pNFf9097jH3R8a4n/8ki0WnL7hn06ULx6dIcVvm/Qz1got0RA2j7ube3TOPCZMjNlP42PPLGWMLYI/u+H5IVxDr2+1JO8R85DQwSIEgoNwggnTUG4RqqzUlXw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: caba8765-d35f-45f2-855d-08d763a8223c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 17:30:07.1554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2A73nGUp8GwTjQ7vyevez+N7MPvI34f66Z/gTN7fSOVnOAAzGcdLaVGZu+2dd/8WtUyGtp1shjx5V/hG3Cff0Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3648 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Thu, 07 Nov 2019 17:30:31 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRW11IDxlbXUtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvc2VwaCBTYWxvd2V5DQo+IFNlbnQ6IDAzIE5vdmVt YmVyIDIwMTkgMTg6MzENCj4gVG86IEFsYW4gRGVLb2sgPGFsYW5kQGRlcGxveWluZ3JhZGl1cy5j b20+DQo+IENjOiBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTNAaWV0Zi5vcmc7IEVNVSBXRyA8ZW11 QGlldGYub3JnPjsgSm9obg0KPiBNYXR0c3NvbiA8am9obi5tYXR0c3Nvbj00MGVyaWNzc29uLmNv bUBkbWFyYy5pZXRmLm9yZz47IE1pY2hhZWwNCj4gUmljaGFyZHNvbiA8bWNyQHNhbmRlbG1hbi5j YT4NCj4gU3ViamVjdDogUmU6IFtFbXVdIFBPU1QgV0dMQyBDb21tZW50cyBkcmFmdC1pZXRmLWVt dS1lYXAtdGxzMTMNCj4gDQo+IA0KPiBPbiBGcmksIE5vdiAxLCAyMDE5IGF0IDQ6MDggQU0gQWxh biBEZUtvaw0KPiA8bWFpbHRvOmFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20+IHdyb3RlOg0KPiBP biBOb3YgMSwgMjAxOSwgYXQgNjoxNSBBTSwgSm9obiBNYXR0c3Nvbg0KPiA8bWFpbHRvOmpvaG4u bWF0dHNzb25AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gPiBJIHN0cm9uZ2x5IHN1cHBvcnQgd29y a2luZyBncm91cCBhZG9wdGlvbiBvZiBkcmFmdC1kZWtvay1lbXUtdGxzLWVhcC10eXBlcy4NCj4g Q2FuIHdlIG1ha2Ugc3VyZSB0byBnZXQgdGhpcyBkb2N1bWVudCBnb2luZywgSSBhZ3JlZSB0aGF0 IHRoaXMgaXMgYSB2ZXJ5IG5lZWRlZA0KPiBkcmFmdC4gSSB0aGluayBpdCBzaG91bGQgaW5jbHVk ZSB1cGRhdGVzIGZvciBldmVyeXRoaW5nIHBlb3BsZSB3YW50cyB0byB1c2UuIEkgZG8NCj4gbm90 IHRoaW5rIGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMyBzdHJpY3RseSBoYXZlIHRvIHdhaXQgZm9y IGRyYWZ0LWRla29rLWVtdS10bHMtDQo+IGVhcC10eXBlcywgYnV0IGRyYWZ0LWRla29rLWVtdS10 bHMtZWFwLXR5cGVzIHNob3VsZCBiZSBwdWJsaXNoZWQgc2hvcnRseSBhZnRlci4NCj4gDQo+IMKg IEkgd2lsbCBkbyBhbiB1cGRhdGUgdG8gbXkgZG9jdW1lbnQgc2hvcnRseS4NCj4gDQo+IMKgIEkg YWxzbyBhZGRlZCBhbiBpc3N1ZSB3aXRoIHRoZSBFQVAtVExTIGRvY3VtZW50IG9uIEdpdEh1Yi7C oCBUaGUgc3VnZ2VzdGlvbiBpcw0KPiB0byBhZGQgdGV4dCB3aGljaCBleHBsYWlucyBob3cgKGFu ZCB3aHkpIHRoZSBFQVAgSWRlbnRpdHkgaXMgY2hvc2VuIGR1cmluZw0KPiByZXN1bXB0aW9uOg0K PiANCj4gLS0tDQo+IFRoZSBFQVAgSWRlbnRpdHkgdXNlZCBpbiByZXN1bXB0aW9uIFNIT1VMRCBi ZSB0aGUgc2FtZSBFQVAgSWRlbnRpdHkgYXMgd2FzDQo+IHVzZWQgZHVyaW5nIHRoZSBvcmlnaW5h bCBhdXRoZW50aWNhdGlvbi4gVGhpcyByZXF1aXJlbWVudCBhbGxvd3MgRUFQIHBhY2tldHMgdG8N Cj4gYmUgcm91dGFibGUgdGhyb3VnaCBhbiBBQUEgaW5mcmFzdHJ1Y3R1cmUgdG8gdGhlIHNhbWUg ZGVzdGluYXRpb24gYXMgdGhlDQo+IG9yaWdpbmFsIGF1dGhlbnRpY2F0aW9uLg0KPiANCj4gDQo+ IFRoZSBhbHRlcm5hdGl2ZSBpcyB0byBkZXJpdmUgdGhlIEVBUCBJZGVudGl0eSBmcm9tIHRoZSBp ZGVudGl0eSB1c2VkIGluc2lkZSBvZiBUTFMuDQo+IFRoaXMgZGVyaXZhdGlvbiBpcyBjb21tb24g cHJhY3RpY2Ugd2hlbiB1c2luZyBjZXJ0aWZpY2F0ZXMsIGFuZCB3b3JrcyBiZWNhdXNlDQo+IHRo ZSAiY29tbW9uIG5hbWUiIGZpZWxkIGluIHRoZSBjZXJ0aWZpY2F0ZSBpcyB0eXBpY2FsbHkgY29t cGF0aWJsZSB3aXRoIEVBUCwgYW5kDQo+IGl0IGNvbnRhaW5zIGEgcm91dGFibGUgaWRlbnRpZmll ciBzdWNoIGFzIGFuIGVtYWlsIGFkZHJlc3MuIFRoaXMgcHJhY3RpY2UgY2Fubm90IGJlDQo+IHVz ZWQgZm9yIHJlc3VtcHRpb24sIGFzIHRoZSBQU0sgaWRlbnRpdHkgbWF5IGJlIGEgYmluYXJ5IGJs b2IsIGFuZCBpdCBtaWdodCBub3QNCj4gY29udGFpbiBhIHJvdXRhYmxlIHJlYWxtIGFzIHN1Z2dl c3RlZCBieSBSRkMgNzU0Mi4NCj4gDQo+IFtKb2VdIERvIGltcGxlbWVudGF0aW9ucyB1c2UgdGhl IHdob2xlIGNvbW1vbiBuYW1lIG9yIGp1c3QgdGhlIGRvbWFpbg0KPiBwb3J0aW9uLsKgIFVzaW5n IHRoZSB3aG9sZSBjb21tb24gbmFtZSBpcyBub3QgYWR2aXNhYmxlIHdpdGggVExTIDEuMy4NCj4g DQo+IEluIHNvbWUgY2FzZXMsIHRoZSBQU0sgaWRlbnRpdHkgaXMgZGVyaXZlZCBieSB0aGUgdW5k ZXJseWluZyBUTFMgaW1wbGVtZW50YXRpb24sDQo+IGFuZCBjYW5ub3QgYmUgY29udHJvbGxlZCBi eSB0aGUgRUFQIGF1dGhlbnRpY2F0b3IuIFRoZXNlIGxpbWl0YXRpb25zIG1ha2UgdGhlDQo+IFBT SyBpZGVudGl0eSB1bnN1aXRhYmxlIGZvciB1c2UgYXMgdGhlIEVBUCBJZGVudGl0eS4NCj4gDQo+ IFtKb2VdwqAgSXMgRUFQIElkZW50aXR5IFN5bm9ueW1vdXPCoHdpdGggdGhlIE5BST8NCg0KW29m cmllbF0gSSdkIGFsc28gbGlrZSB0byBkZWZpbml0aXZlbHkgdW5kZXJzdGFuZCB0aGlzLiBOZWl0 aGVyIFJGQzM3NDggb3IgUkZDNzU0MiBhcmUgY2xlYXIgb24gdGhpcy4gU2hvdWxkIHRoaXMgYmUg YW4gZXJyYXRhIHRvIGNsYXJpZnkuLiBzb21ld2hlcmU/DQoNCg0KVHdvIG90aGVyIHF1ZXN0aW9u cyBvbiBSRkMzNzQ4LiBTZWN0aW9uIDUuMSBzdGF0ZXM6DQoiICAgICAgSXQgaXMgUkVDT01NRU5E RUQgdGhhdCB0aGUgSWRlbnRpdHkgUmVzcG9uc2UgYmUgdXNlZCBwcmltYXJpbHkgZm9yDQogICAg ICByb3V0aW5nIHB1cnBvc2VzIGFuZCBzZWxlY3Rpbmcgd2hpY2ggRUFQIG1ldGhvZCB0byB1c2Uu ICINCg0KSXMgaXQgZGVmaW5lZCBhbnl3aGVyZSBob3cgdGhlIElkZW50aXR5IGlzIHVzZWQgZm9y IEVBUCBtZXRob2Qgc2VsZWN0aW9uPyBPciBpcyB0aGlzIEVBUCBtZXRob2Qgc3BlY2lmaWMgYW5k IHNob3VsZCBiZSBkZWZpbmVkIGluIHRoZSBtZXRob2Qgc3BlY2lmaWMgZHJhZnQ/DQoNCiBFLmcu IHdlIGhhdmUgZG9jdW1lbnRlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGVhci1lYXAtdGVhcC1icnNraS0wNSNzZWN0aW9uLTUgdGhhdDoNCg0KIiAgIEEgZGV2aWNlIHRo YXQgaGFzIG5vdCBiZWVuIGJvb3RzdHJhcHBlZCBhdCBhbGwgU0hPVUxEIHNlbmQgYW4NCiAgIGlk ZW50aXR5IG9mIHRlYXAtYm9vdHN0cmFwQFRCRDEuICINCg0KSWYgd2UgcmVnaXN0ZXIgdGhhdCAi dGVhcC1ib290c3RyYXBAVEJEMSIgd2l0aCBJQU5BLCB0aGVuIGl0IGNvdWxkIGJlIHRoZSBtZWNo YW5pc20gYnkgd2hpY2ggdGhlIHBlZXIgdGVsbHMgdGhlIHNlcnZlciB0aGF0IGl0IHdhbnRzIHRv IHVzZSBURUFQLiBJZiB0aGUgc2VydmVyIGRvZXMgbm90IHN1cHBvcnQgVEVBUCwgaXQgd2lsbCBy ZXR1cm4gYW4gZXJyb3IgcmVzcG9uc2UuDQoNCkZvciByb3V0aW5nLCB0aGUgSWRlbnRpdHkgcHJv dmlkZWQgaW5jbHVkZXMgYSByZWFsbSBhbmQgaXQgY291bGQgYmUgYW5vbnltb3VzOiBlLmcuICJA ZXhhbXBsZS5jb20iLiBJZiB0aGUgc2VydmVyIGNhbm5vdCByb3V0ZSB0byB0aGF0IGRvbWFpbiwg aXQgcmV0dXJucyBhbiBlcnJvci4NCg0KRUFQIHByb3ZpZGVzIG5vIG1lY2hhbmlzbSB0byByZXR1 cm4gYW4gZXJyb3IgY29kZSB0byB0aGUgcGVlci4gSG93IGNvdWxkIHdlIHNpZ25hbCBpbiBFQVAg dGhlIGVycm9yIGRpZmZlcmVuY2UgYmV0d2VlbiByb3V0aW5nIHZzIEVBUCBtZXRob2QgdW5zdXBw b3J0ZWQgZmFpbHVyZXM/IE9yIGNhbiB3ZSBhdCBhbGw/DQoNCg0KDQo+IA0KPiAtLS0NCj4gDQo+ IMKgIEFsYW4gRGVLb2suDQo= From nobody Thu Nov 7 09:30:40 2019 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 B8B641209D4; Thu, 7 Nov 2019 09:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Mn2vEa3x; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rSef2xlM 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 RLGaXZOLaHS4; Thu, 7 Nov 2019 09:30:21 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23701209AE; Thu, 7 Nov 2019 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2746; q=dns/txt; s=iport; t=1573147820; x=1574357420; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=wZlaOd6crxw9Mucu5ST+8VMKnp7IHeviVlFD+f5bVtg=; b=Mn2vEa3xqFqqeDOxWFloSHoIXFe1JuimDTq3raRFpjQZ+VqYwdFjyHTz 4ptV4jq7kvu4i6cPIfoXfFun8kRugXPeBoilRP4iiaCQDXAxBzJ/8LdXf yJdbLxynrBXt7ZG4C6d9M/HQruPhgCP6IsnEdRN7zi+93vwIGCuHeZ3Fp c=; IronPort-PHdr: =?us-ascii?q?9a23=3AmouLrxGDyYBe7if0Twyf4Z1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAB7U8Rd/5FdJa1bCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBbAMBAQEBCwGBSlAFbFggBAsqh28DiwKCXpd?= =?us-ascii?q?+gS4UgRADVAkBAQEMAQEYCwoCAQGEQAKEDiQ2Bw4CAwsBAQQBAQECAQUEbYU?= =?us-ascii?q?3DIVRAQEBAQICARAoBgEBLAsBCwYBGQQBAQEeNwsdCQEEAQ0FCBqDAYJGAw4?= =?us-ascii?q?gAQIMp2oCgTiIYIIngn4BAQWFCxiCFwMGgTYBjBMYgUA/gRFGgwqCYgEBAoE?= =?us-ascii?q?sAQgKASGDQIIslWqYHgqCJJVcgjyXNo5GgUCYKgIEAgQFAg4BAQWBWQMvZ3F?= =?us-ascii?q?wFRohgmxQERSQNoNzhRSFP3QBAYEmjVyCMQEB?= X-IronPort-AV: E=Sophos;i="5.68,278,1569283200"; d="scan'208";a="367596135" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2019 17:30:15 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xA7HUFiJ027160 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2019 17:30:15 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 11:30:15 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 12:30:13 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Nov 2019 11:30:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XnFyo01hQM/Q0TI2Du+Qoz8Bx5Mx5iB6K+pDOE+JyLgEB7ZDRQbtAS4nerglbb0IC5X41X21ZZRsqGUlSeEKKeUtlZ2+iJK4dRFPVC0UduA/C1/Fx9dBfCUmq03RVjGBLdQ3NdGtYOLB4t8HiKi0amQY/uQ4uL3qMgTTdTjHS1tn16+fyIt97hG0EbkSCj1RB/KzSbFpNzHdm6BFdc+iG6zA+K19ruwzCLkiaq9NdZYRRrq9F6c5K3CF7CTZ1XsJlm1/s4FcdB68yK0m3eLLkVebA03mz2AjOVRjrmu3NmK40oRsV6QiSyKCxTL8SAwfqkhm2CNB6sUvU/wSQBkZUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k93n1Di0j3XdGxEWSoo+WpEbnPnQAlEApltFFI7E0aE=; b=l0uBvVpxrVcnWn4Z2B7o4305/MzPF4saT46aZtk7vrx9xyty55A2bpUpzxxWMkTKV9Z2269PGPvt9oUi69fQIKBS0ySTOREIBPqnGaqT7OoUl1WLnnrobZz9D5/V9hVZfUNQtj3bbvkFDqTC1HYEvnQ/pAd6e9X1HHTluMctJ+zHlQ95QDvQ81FXJHo67LOp2Yd2gLhaK5Yjj94c54IBpd2rFx5ncuhNz+OIEn93Cs17XST3Oy4j7sni8jQOkKet40mtYBVH8rWCJHbiTrKQOtJpYbnmGBol+9PuAh51ze7geu/QXpeMFI7s/mT88/WUsNXAuBu++rxH+O8Z67kAGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k93n1Di0j3XdGxEWSoo+WpEbnPnQAlEApltFFI7E0aE=; b=rSef2xlMwC6GD95b6oFvivkbAnvB6I3Q7YDfIB/TV/bi2D6ngpNCdKkUpVA9QQWtngJdl4Z4jcm3nUdoIIOlDUlIARZB76agZUyLCMuuqxDH7+tzEFV+Nb5E+m8a8NyP8xHcokiSKVDR8yDlpMO4xSHITHMWjTDNvFvgpTu7mfQ= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3648.namprd11.prod.outlook.com (20.178.252.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Thu, 7 Nov 2019 17:30:12 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.023; Thu, 7 Nov 2019 17:30:12 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok , John Mattsson CC: "draft-ietf-emu-eap-tls13@ietf.org" , Michael Richardson , John Mattsson , EMU WG Thread-Topic: TLS1.3 and TEAP (RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13) Thread-Index: AdWVkQAOhvHNjkPsSrmtom9842Q5uA== Date: Thu, 7 Nov 2019 17:30:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:4041:1300:6d98:e3fd:9fdd:799e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7076ecd-505b-43a9-41b2-08d763a82538 x-ms-traffictypediagnostic: MN2PR11MB3648: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(13464003)(199004)(189003)(478600001)(99286004)(4326008)(966005)(8676002)(14444005)(256004)(86362001)(81166006)(81156014)(9686003)(55016002)(6306002)(14454004)(76116006)(25786009)(52536014)(66946007)(66556008)(64756008)(66446008)(66476007)(110136005)(486006)(476003)(7696005)(74316002)(305945005)(102836004)(6436002)(7736002)(316002)(53546011)(6506007)(6116002)(5660300002)(46003)(2906002)(54906003)(71190400001)(71200400001)(186003)(33656002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3648; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0kDb3bqmZhI5UvoqLvq0CfZN6pQB6shze3Kfe0gcqzVPrLo37V+HiEw8Epeczoh0Z2rRqAtVZBQHWwumIl93bZoaSevaHc6xQZDrBLDJOAanQOHwZyIp4BnGxzLHScxaUGPcAqev0S0D1a4EZhTn+bpVydpDI8DYDFerOgjJqLCk+d5hkXZzj1rs6f+GAF2Hs/HgG+uZb817tGr83ckEiRvG3Qw8YyMlhtJS211cQrc3BGV43keglViB8+ZnZRNwhC+Y5RnJoiga1kecyjB405Y9+uHUXpH5wJ3G+klmp5c9EJzMxqcOFgp+EW9sXwRFdoIVPz08+oHQ/6tMrEJEFbjUhccTjPQg4AT4J/256yeIxZtltBane11e+QaH7PA2Ko7BGsd58cXyh2yJ9O7T2/Rcyfpwv/tMVCgpFjZqMepnqoebz47ibo8247ucP+Vw00Yn2+H49JZexpZMNvYfG29Tu01iMcGd6cmxicdDcUk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b7076ecd-505b-43a9-41b2-08d763a82538 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 17:30:12.4484 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7eefQ5c6eMfOVIx+QDmMtkaDlVAlRIkyIK/YuMaC2uGAvMvd+WCMTZSccE5VJLP7HBEfC32eolTky1CUQk0GxA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3648 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Thu, 07 Nov 2019 17:30:32 -0000 > -----Original Message----- > From: Emu On Behalf Of Alan DeKok > Sent: 01 November 2019 11:08 > To: John Mattsson > Cc: draft-ietf-emu-eap-tls13@ietf.org; Michael Richardson > ; John Mattsson > ; EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 >=20 > On Nov 1, 2019, at 6:15 AM, John Mattsson > wrote: > > I strongly support working group adoption of draft-dekok-emu-tls-eap-ty= pes. > Can we make sure to get this document going, I agree that this is a very = needed > draft. I think it should include updates for everything people wants to u= se. I do > not think draft-ietf-emu-eap-tls13 strictly have to wait for draft-dekok-= emu-tls- > eap-types, but draft-dekok-emu-tls-eap-types should be published shortly = after. >=20 > I will do an update to my document shortly. [ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included= in draft-dekok-emu-tls-eap-types? Or in draft-lear-eap-teap-brski - and no= te that the title is changed to " TEAP Update and Extensions for Bootstrapp= ing "? Or potentially both? Eliot, Nancy and I had planned on adding TLS1.3= updates to draft-lear-eap-teap-brski, but haven't got it done yet. >=20 > I also added an issue with the EAP-TLS document on GitHub. The suggest= ion is > to add text which explains how (and why) the EAP Identity is chosen durin= g > resumption: >=20 > --- > The EAP Identity used in resumption SHOULD be the same EAP Identity as wa= s > used during the original authentication. This requirement allows EAP pack= ets to > be routable through an AAA infrastructure to the same destination as the > original authentication. >=20 > The alternative is to derive the EAP Identity from the identity used insi= de of TLS. > This derivation is common practice when using certificates, and works bec= ause > the "common name" field in the certificate is typically compatible with E= AP, and > it contains a routable identifier such as an email address. This practice= cannot be > used for resumption, as the PSK identity may be a binary blob, and it mig= ht not > contain a routable realm as suggested by RFC 7542. >=20 > In some cases, the PSK identity is derived by the underlying TLS implemen= tation, > and cannot be controlled by the EAP authenticator. These limitations make= the > PSK identity unsuitable for use as the EAP Identity. > --- >=20 > Alan DeKok. >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Thu Nov 7 09:30:48 2019 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 E763F1209BB; Thu, 7 Nov 2019 09:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WV3iawOJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dhZS+k9q 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 pFabPTJsosda; Thu, 7 Nov 2019 09:30:24 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C3D1209DC; Thu, 7 Nov 2019 09:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4890; q=dns/txt; s=iport; t=1573147822; x=1574357422; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9eF+tRjnHOMa8hePwOOpzLVxAhnnq0qruQtUexuW7DA=; b=WV3iawOJrmVLaqxLGkTNAc7r8kPtA40UJ2pWit2fESTfvGMS0nzdzAq7 Nupkn4AUxr4jTrpYEqwZfI97m+oE+ck+Dk6oBwYzhjsvpO8T8SABh9iTu RvUD6LxIGrf+aDKU0gRX6HF7cEcfmvaPTtNPTRUcuDnt596bsGsh/11rG Y=; IronPort-PHdr: =?us-ascii?q?9a23=3Apf10NxN57BEJ/MhFARAl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj8IuTrYigSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAB7U8Rd/5ldJa1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYFKUAVsWCAECyqEKYNGA4sCgl6?= =?us-ascii?q?XfoJSA1QJAQEBDAEBIwoCAQGEQAIXg3ckNwYOAgMLAQEEAQEBAgEFBG2FNwy?= =?us-ascii?q?FUQEBAQEDEhERDAEBNwELBAIBCA4DBAEBAQICFA8DAgICMBQBCAgCBAENBQg?= =?us-ascii?q?agwGCRgMuAQIMA6dnAoE4iGB1gTKCfgEBBYE0AYNWGIIXAwaBDigBjBMYgUA?= =?us-ascii?q?/gRFGgkw+gmICAoFJGE2CQTKCLJAHngEKgiSHF45FmXKORogxkTkCBAIEBQI?= =?us-ascii?q?OAQEFgWgjgVhwFTuCbFARFJA2g3OFFIU/dAEBgSaNcYIcAQE?= X-IronPort-AV: E=Sophos;i="5.68,278,1569283200"; d="scan'208";a="367596235" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Nov 2019 17:30:20 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xA7HUKTi011165 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2019 17:30:20 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 11:30:19 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 12:30:18 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Nov 2019 11:30:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IBUhrWIb2wN8AUZ6OshrmMa6a2Yzet59/srkHP4UUpJ95s7/eGqxU33te0gNVedh1+0jRIHLNhjUNdtH6qwvBz7i070OD91FkNf+T1k/KvxFwP4JzGlv+rGX6vHoAKMyvnrpyHdccETZKgvCI740KDxz95V62Y786SPIY5/Qm7shFxg4KzZy2ALddvsUJ0N+MhBpSB4drhipJtLvIqp22n8bcyqe/eIyKE77npG1+6ZDXW72YHfGLvmBQKEcHisg6YZ+LKz0t2FIxfSlTklwJiT4vSGahQaZAT2bwlOCmEAPb72AJU8xfbeggGIJUrG3m1SdHlFf8W2BD1nCnqApaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9eF+tRjnHOMa8hePwOOpzLVxAhnnq0qruQtUexuW7DA=; b=AFEhfNdzcAodt8RJWCopFV3chQxQ1lGT9AJM0b+a8Z/nobEypxuP9KjrG3I18mGAyKnUjF4LcZkuO1ytaSql7mzh94Q4gjuIkrpyV7jPYcJF7be8uKOmZlciAoTnKLZn6aXt5Le0p0jHKAMjUJqXDO4u7wFzKK4sHfw+w2XTo8NYsf3BPYgcBMs/J1sj9TBY2NxdKmZOngm5D2sgGJ5RGm7aJA62O9QzmgfCA7mo99ZCJoeTDgY5Ln9SKP+qv4lUxM00oHP1cv8fGF3EWWQaUeXqk6FDTjgikAuqfCIT0pqGTAVlZDwijtnMAO563Zw0XlpKCcViW3fH++42UGeQnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9eF+tRjnHOMa8hePwOOpzLVxAhnnq0qruQtUexuW7DA=; b=dhZS+k9qsjPNeLVw9myNM0yHVbStVnNQjKfNXsRdaXYVtJEj7YJvMkysN1Ur1bVvaoojAYX5FZU174PxYW/czYy3ju0hwGclEM/xYyeEYXyub7+IP1MFV5GBBikccnY+PrCP9MNMGp56gp7+98t9z1Nub1fUluD5OlfKRNh0lVE= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3648.namprd11.prod.outlook.com (20.178.252.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Thu, 7 Nov 2019 17:30:17 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.023; Thu, 7 Nov 2019 17:30:17 +0000 From: "Owen Friel (ofriel)" To: Joseph Salowey , Alan DeKok CC: "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , "Michael Richardson" , EMU WG Thread-Topic: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Thread-Index: AdVKJoKyKr1G5+9hQuKLAEK5rLYqPgfSdnOQAABeFAAABkCJgP//55mA//bAJjCAEoqCAIADGZ8AgBnulgCABSSTAIAB0o2AgAAF5ACAAC3sAIAABveAgB1CFQCAAD1cgIAAJDQAgAEmKQD/9DAisA== Date: Thu, 7 Nov 2019 17:30:16 +0000 Message-ID: References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:4041:1300:6d98:e3fd:9fdd:799e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f2da44a-54d3-413d-5a13-08d763a827f3 x-ms-traffictypediagnostic: MN2PR11MB3648: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(13464003)(199004)(189003)(478600001)(99286004)(4326008)(229853002)(966005)(8676002)(14444005)(256004)(86362001)(81166006)(81156014)(9686003)(55016002)(6306002)(14454004)(76116006)(6246003)(25786009)(52536014)(66946007)(66556008)(64756008)(66446008)(66476007)(110136005)(486006)(476003)(7696005)(74316002)(305945005)(102836004)(6436002)(7736002)(66574012)(446003)(11346002)(316002)(76176011)(53546011)(6506007)(6116002)(5660300002)(46003)(2906002)(54906003)(71190400001)(71200400001)(186003)(33656002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3648; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FgC0JyB0P2VVlVG5T6gENu/N2qqNHZ1UeGckE1wZzKj8Zr66B2SGnhfgtR5eWG22X+ddK8wg8vpQf68FF41U8MnqVlPcCLSxgcfjTXB3RRJe/b/LNU1p+OCIEBmRFw+dPL2o8zxVdNAAzwsqcX4IPpy4chfxsgHVdhhTWDqpJV9sZZc8WQ0nEkghNtbCBC5lqHe3MxHb/x50DPMS5ynDZsMHS3Tm0SG22kerpP81SUZCboOikVcKvfmIoIdZJ/tBjENs9CD0TZrAytpNVlzevcHcj3+CQCPHxi+qA5/5oAL/sk/9FAAr2A37pOQ2YJo6A8o022HykAWpvaIZaTlmdRC/O9u0QR10mWZ9TiWcml8WEJthlLKwAbTbTZudENFki34/zvhUI9ZW7yyyiMd+emhM+WIaVvfio1gP7wmbTH9o5NbFo3GmnDQzDTBIJ6zSAtuO5QSn5osvNEmPHkKFYsg1HRMegjKKwv0QIg/3vo0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f2da44a-54d3-413d-5a13-08d763a827f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2019 17:30:17.0120 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HEY4hL8L5AZ/CmTH9+9vVUebKi2VBp+eFTm8fqn6URd9bMnoDTvC3zY9zp7R0VvfSs8wUc87SPxo7YN8QPnwAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3648 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Thu, 07 Nov 2019 17:30:35 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRW11IDxlbXUtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvc2VwaCBTYWxvd2V5DQo+IFNlbnQ6IDMxIE9jdG9i ZXIgMjAxOSAwNDo0NQ0KPiBUbzogQWxhbiBEZUtvayA8YWxhbmRAZGVwbG95aW5ncmFkaXVzLmNv bT4NCj4gQ2M6IGRyYWZ0LWlldGYtZW11LWVhcC10bHMxM0BpZXRmLm9yZzsgSm9obiBNYXR0c3Nv bg0KPiA8am9obi5tYXR0c3Nvbj00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz47IE1pY2hh ZWwgUmljaGFyZHNvbg0KPiA8bWNyQHNhbmRlbG1hbi5jYT47IEVNVSBXRyA8ZW11QGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogW0VtdV0gUE9TVCBXR0xDIENvbW1lbnRzIGRyYWZ0LWlldGYtZW11 LWVhcC10bHMxMw0KPiANCj4gDQo+IA0KPiBPbiBXZWQsIE9jdCAzMCwgMjAxOSBhdCA0OjEyIEFN IEFsYW4gRGVLb2sNCj4gPG1haWx0bzphbGFuZEBkZXBsb3lpbmdyYWRpdXMuY29tPiB3cm90ZToN Cj4gT24gT2N0IDMwLCAyMDE5LCBhdCA1OjAyIEFNLCBFbGlvdCBMZWFyIDxtYWlsdG86bGVhckBj aXNjby5jb20+IHdyb3RlOg0KPiA+IEEgZmFpciBhcmd1bWVudCwgaWYgaXQgY2FuIGJlIG1hZGUs IGFuZCBJIGFtIG5vdCBjb252aW5jZWQgaXQgaGFzIGJlZW4gZnVsbHkNCj4gZXhwcmVzc2VkLCBp cyB0aGUgaWRlYSB0aGF0IHRoZXJlIGlzIG5vIGNvbnRleHQgYnkgd2hpY2ggb25lIGNhbiBzZXBh cmF0ZSBmYXN0DQo+IHJlc3RhcnQgYW5kIGluaXRpYWwgYXV0aGVudGljYXRpb24uwqAgVGhpcyBp cyBBbGFu4oCZcyBjb25jZXJuLsKgIEnigJltIG5vdCBzYXlpbmcgaXTigJlzDQo+IHdpdGhvdXQg bWVyaXQsIGJ1dCB3aGF0IEkgY2Fubm90IHlldCBzZWUgaXMgd2hldGhlciBpdCBpcyBhbiBpbXBs ZW1lbnRhdGlvbiBvciBhDQo+IHByb3RvY29sIG1hdHRlci4NCj4gDQo+IMKgIEkgYmVsaWV2ZSBp dCdzIGEgcHJvdG9jb2wgbWF0dGVyLsKgIEluIFRMUyAxLjMsIFBTSyBoYW5kc2hha2VzIGFyZSB0 aGUgc2FtZSBhcw0KPiByZXN1bXB0aW9uIGhhbmRzaGFrZXMuDQo+IA0KPiDCoCBJdCdzIG5vdCBj bGVhciB0byBtZSBob3cgdGhpcyBpc3N1ZSB3YXMgYWRkcmVzc2VkIHdoZW4gdXNpbmcgVExTIDEu MyB3aXRoDQo+IEhUVFBTLsKgIEJ1dCBJIGRvIGJlbGlldmUgaXQncyBhbiBpc3N1ZSB0aGVyZSwg dG9vLg0KPiANCj4gW0pvZV0gQ2FuIHlvdSBlbGFib3JhdGUgb24gd2hhdCB0aGUgaXNzdWUgaXM/ wqAgSSB0aGluayBtb3N0IFRMUyBkZXBsb3ltZW50cw0KPiBvcGVyYXRlIGluIGVpdGhlciBhIGNl cnRpZmljYXRlIGJhc2VkIG1vZGUgb3IgYSBQU0sgbW9kZSwgYnV0IG5vdCBib3RoIGF0IHRoZQ0K PiBzYW1lIHRpbWUuDQoNCltvZnJpZWxdIFRMUzEuMyBleHBsaWNpdGx5IGRvZXMgbm90IGFsbG93 IGJvdGggUFNLIGFuZCBjZXJ0cyBzaW11bHRhbmVvdXNseS4gZHJhZnQtaWV0Zi10bHMtdGxzMTMt Y2VydC13aXRoLWV4dGVybi1wc2sgZG9lcywgYnV0IHRoYXTigJlzIEV4cGVyaW1lbnRhbC4gSSBk b24ndCB0aGluayBUTFMgd2l0aCBleHRlcm4gUFNLIGlzIHJlYWxseSBpbnRlbmRlZCBmb3IgV2Vi L0Jyb3dzZXIgSFRUUFMgY29ubmVjdGlvbnMuIEl0cyBtb3JlIGZvciBkZXZpY2VzL3RoaW5ncyB3 aGljaCBhcmUgcHJlcHJvdmlzaW9uZWQgd2l0aCB0aGUgZXh0ZXJuIFBTSy4NCg0KSW4gVExTMS4z LCBieSBkZXNpZ24gdGhlIHByb3RvY29sIGRvZXMgbm90IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBy ZXN1bXB0aW9uIGFuZCBleHRlcm5hbCBQU0tzLCBhbmQgc2F5cyBub3RoaW5nIGFib3V0IFBTSyBJ RCBmb3JtYXQsIGFzIGNvbW1lbnRlZCBoZXJlIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvdGxzL1E1SzhIU1BQZ0xSb2pRd1hiVjRaVEl4QklIMCAsIGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGxzL1hfejhwYzNvUzJBdTdLYWpqTWhsV2hQMVVQYyAN Cg0KQW5kIGl0cyBhcHBsaWNhdGlvbiBzcGVjaWZpYyBob3cgdGhlIHR3byBhcmUgZGlmZmVyZW50 aWF0ZWQsIHRoZSBzcGVjIHNheXMgbm90aGluZyBhYm91dCBpdDogaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy90bHMvYnRMblpFUll2OEdKSjJQRlVrc2pOc0R5djhvDQoNCkkg c3RpbGwgZG9uJ3QgZ2V0IHdoeSBFQVAtVExTMS4zIHNob3VsZCBwbGFjZSByZXN0cmljdGlvbnMg b24gdXNlIG9mIFRMUzEuMy4gU3VyZWx5IGl0IHNob3VsZCBiZSBhbiBFQVAgc2VydmVyIGltcGxl bWVudGF0aW9uIGRlY2lzaW9uIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCB0aGF0IGZlYXR1cmUgb3Ig bm90LCBidXQgd2Ugc2hvdWxkIG5vdCBwcmVjbHVkZSBhIHNwZWNpZmljIEVBUCBzZXJ2ZXIgaW1w bGVtZW50YXRpb24gZnJvbSBzdXBwb3J0aW5nIGV4dGVybiBQU0sgYnkgZGlzYWxsb3dpbmcgaXQg aW4gdGhlIHNwZWMuIElmIGEgcGFydGljdWxhciBFQVAgc2VydmVyIGRvZXMgbm90IHdhbnQgdG8g c3VwcG9ydCBleHRlcm4gUFNLIC0gdGhhdOKAmXMgZmluZS4NCg0KPiANCj4gwqAgQXMgYW4gYWRk aXRpb25hbCBub3RlLCBJIGJlbGlldmUgaXQncyBhbHNvIGltcG9ydGFudCB0aGF0IGRyYWZ0LWRl a29rLWVtdS10bHMtDQo+IGVhcC10eXBlcyBiZSBwdWJsaXNoZWQgYXQgdGhlIHNhbWUgdGltZSBh cyB0aGUgRUFQLVRMUyBkb2N1bWVudC7CoCBUaGUgb25seQ0KPiB1bmtub3duIHRoZXJlIGlzIEZB U1QgYW5kIFRFQVAuwqAgSSdtIGhhcHB5IHRvIHJlbW92ZSB0aGVtIGZyb20gdGhlDQo+IGRvY3Vt ZW50Lg0KPiANCj4gwqAgQnV0IGF0IHRoaXMgcG9pbnQgaXQncyBub3QgZXZlbiBhIFdHIGRvY3Vt ZW50LsKgIFRoZXJlJ3Mgbm90IGV2ZW4gY29uc2Vuc3VzIHRoYXQNCj4gdGhlIGRvY3VtZW50IG5l Y2Vzc2FyeSwgd2hpY2ggc3VycHJpc2VzIG1lIHJhdGhlciBhIGxvdC7CoCBCZWNhdXNlIHBhc3N3 b3JkLQ0KPiBiYXNlZCBFQVAgbWV0aG9kcyBhcmUgKm11Y2gqIG1vcmUgd2lkZS1zcHJlYWQgdGhh biBFQVAtVExTLg0KPiANCj4gwqAgSWYgdGhlIElFVEYgcHVibGlzaGVzIEVBUC1UTFMgd2l0aG91 dCBzaW11bHRhbmVvdXNseSByZXYnaW5nIFRUTFMgYW5kIFBFQVAsIGl0DQo+IHdpbGwgbm90IG9u bHkgbG9vayBiYWQsIGl0IHdpbGwgKmJlKiBiYWQuwqAgQW5kIHRoZSBpbmR1c3RyeSBwcmVzcyB3 aWxsIChyaWdodGZ1bGx5KQ0KPiBsYW1iYXN0IHRoZSBzdGFuZGFyZHMgcHJvY2Vzcy4NCj4gDQo+ IFtKb2VdIFdlIG5lZWQgcGVvcGxlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGRvY3VtZW50LsKgIElm IHdlIGFyZSBnb2luZyB0byBwdWJsaXNoDQo+IGEgZG9jdW1lbnQgdGhyb3VnaCB0aGUgd29ya2lu ZyBncm91cCBpdCBuZWVkcyB0byBhdCBsZWFzdCB0byBpbmNsdWRlIFRFQVAuwqAgwqBJDQo+IGtu b3cgdGhlcmUgYXJlIGZvbGtzIG9uIHRoaXMgbGlzdCB3aG8gYXJlIGltcGxlbWVudGluZy7CoCBU aGV5IG5lZWQgdG8gc3RlcCB1cA0KPiBhbmQgaGVscCB3aXRoIHRoaXMgZG9jdW1lbnQgYW5kIHRo ZSBURUFQwqBlcnJhdGEuDQo+IA0KPiDCoCBBbGFuIERlS29rLg0K From nobody Thu Nov 7 09:43:20 2019 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 D6C27120940; Thu, 7 Nov 2019 09:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XJUg-qKeBxY; Thu, 7 Nov 2019 09:43:14 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECEF120943; Thu, 7 Nov 2019 09:43:14 -0800 (PST) Received: from [192.168.20.137] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id D32F6837; Thu, 7 Nov 2019 17:43:10 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Thu, 7 Nov 2019 12:43:09 -0500 Cc: Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , EMU WG , John Mattsson , Michael Richardson Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Thu, 07 Nov 2019 17:43:19 -0000 On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) = wrote: >> [Joe] Is EAP Identity Synonymous with the NAI? >=20 > [ofriel] I'd also like to definitively understand this. Neither = RFC3748 or RFC7542 are clear on this. Should this be an errata to = clarify.. somewhere? The EAP Identity can largely be anything, so long as it is UTF-8. The *recommendation* in RFC 7542 is to make it an NAI. But that isn't = mandated anywhere. I'm not sure there's any errata required. > Two other questions on RFC3748. Section 5.1 states: > " It is RECOMMENDED that the Identity Response be used primarily = for > routing purposes and selecting which EAP method to use. " >=20 > Is it defined anywhere how the Identity is used for EAP method = selection? It is absolutely not mentioned anywhere. For the simple reason that = EAP provides for method negotiation. We don't need to overload the = Identity field. The issue we're running into here is not about EAP method selection. = It's about *TLS* method selection (PSK vs certs). And that officially = has little to do with EAP. > Or is this EAP method specific and should be defined in the method = specific draft? No EAP document should recommend overloading Identity in order to do = EAP method selection. > E.g. we have documented in = https://tools.ietf.org/html/draft-lear-eap-teap-brski-05#section-5 that: >=20 > " A device that has not been bootstrapped at all SHOULD send an > identity of teap-bootstrap@TBD1. " >=20 > If we register that "teap-bootstrap@TBD1" with IANA, then it could be = the mechanism by which the peer tells the server that it wants to use = TEAP. If the server does not support TEAP, it will return an error = response. The discussion prior to IETF 105 was that we should use the ".arpa" = domain: https://www.iana.org/domains/arpa That domain is explicitly = intended for this kind of negotiation. =20 Note that using ".arpa" still isn't EAP method selection. It's = instead signalling something else. > For routing, the Identity provided includes a realm and it could be = anonymous: e.g. "@example.com". If the server cannot route to that = domain, it returns an error. i.e. an EAP Failure message. > EAP provides no mechanism to return an error code to the peer. How = could we signal in EAP the error difference between routing vs EAP = method unsupported failures? Or can we at all? EAP provides for a NAK for negotiation, and a Notification packet for = signalling errors or messages. Unfortunately, most supplicants don't = support Notification. And the ones that do won't show Notification = messages to the end user. Alan DeKok. From nobody Thu Nov 7 09:48:21 2019 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 E87071209A9; Thu, 7 Nov 2019 09:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXooHsQNlJ6X; Thu, 7 Nov 2019 09:48:18 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1A112098A; Thu, 7 Nov 2019 09:48:18 -0800 (PST) Received: from [192.168.20.137] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id E111A1946; Thu, 7 Nov 2019 17:48:15 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Thu, 7 Nov 2019 12:48:14 -0500 Cc: Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Thu, 07 Nov 2019 17:48:20 -0000 On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) = wrote: > [ofriel] TLS1.3 explicitly does not allow both PSK and certs = simultaneously. draft-ietf-tls-tls13-cert-with-extern-psk does, but = that=E2=80=99s Experimental. I don't think TLS with extern PSK is really = intended for Web/Browser HTTPS connections. Its more for devices/things = which are preprovisioned with the extern PSK. Then the EAP-TLS document should disallow it, too. If TLS 1.3 doesn't = support it, I don't see how something built on top of TLS 1.3 can = support it. > In TLS1.3, by design the protocol does not differentiate between = resumption and external PSKs, and says nothing about PSK ID format, as = commented here = https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , = https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc=20 Which is fine. I'm happy to have PSKs be anything. The caveat is = that we then MUST forbid the PSKs from being copied to the EAP Identity = field. So the EAP-TLS document has to make a recommendation. > And its application specific how the two are differentiated, the spec = says nothing about it: = https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o >=20 > I still don't get why EAP-TLS1.3 should place restrictions on use of = TLS1.3. Surely it should be an EAP server implementation decision on = whether to support that feature or not, but we should not preclude a = specific EAP server implementation from supporting extern PSK by = disallowing it in the spec. If a particular EAP server does not want to = support extern PSK - that=E2=80=99s fine. Then we need to give guidance on what implementors and administrators = should do. Even if it means adding text saying "you can do certs OR = PSK, but NOT BOTH". Alan DeKok. From nobody Thu Nov 7 09:49:37 2019 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 E6F711209AB; Thu, 7 Nov 2019 09:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UVlx3o8nGTN; Thu, 7 Nov 2019 09:49:35 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDAF1209A0; Thu, 7 Nov 2019 09:49:34 -0800 (PST) Received: from [192.168.20.137] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id CF31F1946; Thu, 7 Nov 2019 17:49:32 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Thu, 7 Nov 2019 12:49:31 -0500 Cc: John Mattsson , "draft-ietf-emu-eap-tls13@ietf.org" , Michael Richardson , John Mattsson , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Thu, 07 Nov 2019 17:49:36 -0000 On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) = wrote: >=20 >=20 > [ofriel] Question to the WG: should the TEAP changes for TLS1.3 be = included in draft-dekok-emu-tls-eap-types? If they're minor, it may be OK. > Or in draft-lear-eap-teap-brski - and note that the title is changed = to " TEAP Update and Extensions for Bootstrapping "? Or potentially = both? Eliot, Nancy and I had planned on adding TLS1.3 updates to = draft-lear-eap-teap-brski, but haven't got it done yet. Since it looks like TEAP hasn't actually been implemented much, it's = probably best to move the TLS 1.3 fixes into a general "oops, we need to = fix TEAP" document. Alan DeKok. From nobody Thu Nov 7 11:10:47 2019 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 E0DBD120869 for ; Thu, 7 Nov 2019 11:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5-gQAJzIjK8 for ; Thu, 7 Nov 2019 11:10:25 -0800 (PST) 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 8B745120957 for ; Thu, 7 Nov 2019 11:10:25 -0800 (PST) Received: from [10.10.10.21] (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id CA5533897B for ; Thu, 7 Nov 2019 14:07:26 -0500 (EST) To: emu@ietf.org References: From: Michael Richardson Message-ID: Date: Thu, 7 Nov 2019 14:10:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F3743B38431FE220F0082440" Content-Language: en-US Archived-At: Subject: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...) 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: Thu, 07 Nov 2019 19:10:31 -0000 This is a multi-part message in MIME format. --------------F3743B38431FE220F0082440 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-11-07 12:43 p.m., Alan DeKok wrote: >> E.g. we have documented in https://tools.ietf.org/html/draft-lear-eap-= teap-brski-05#section-5 that: >> >> " A device that has not been bootstrapped at all SHOULD send an >> identity of teap-bootstrap@TBD1. " >> >> If we register that "teap-bootstrap@TBD1" with IANA, then it could be = the mechanism by which the peer tells the server that it wants to use TEA= P. If the server does not support TEAP, it will return an error response.= > The discussion prior to IETF 105 was that we should use the ".arpa" d= omain: https://www.iana.org/domains/arpa That domain is explicitly inte= nded for this kind of negotiation. =20 BTW, related to BRSKI is that the 6tisch CoJP protocol uses 6tisch.arpa in the CoAP header. (Not that we'd use the same one, but registering it wasn't hard) i.e. an EAP Failure message. >> EAP provides no mechanism to return an error code to the peer. How cou= ld we signal in EAP the error difference between routing vs EAP method un= supported failures? Or can we at all? > EAP provides for a NAK for negotiation, and a Notification packet for= signalling errors or messages. Unfortunately, most supplicants don't sup= port Notification. And the ones that do won't show Notification messages= to the end user. Owen, do we have a need to recognize that a device needs to perform onboarding again after a movement? i.e. device A enrolls on network 1, gets an LDevID usable on network 1, uses that with EAP-FOOBAR. device A then is moved to network 2, it tries to use same LDevID, receives an error and then recognizes that it needs to perform another enrollment. What is that error, and is it recognizeable?=C2=A0 Do we need a new error= code to distinguish from "I reject you" from "I reject you but, you could try enrolling with BRSKI-TEAP" (hoping re-installed laptop works) --------------F3743B38431FE220F0082440 Content-Type: application/pgp-keys; name="pEpkey.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pEpkey.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QS dv84oNe1h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2I oHCU6ezhQz2TwJO7l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF 8lIIAYEbQ4YyYyjk5DS30x59kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDD sMmTJWPkszvQoCjCbrvgDAuoRtL5su2VIQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVl L71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj1N/2x7mGk35Zrvz0WHjZLcFJ YJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQgRI4pNs24NoxLXl5 v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh05I5okPcE Nk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsD BQkB4TOABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvU mQjFqXgsg4KhIWQbQBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSG TEH03oJIeYbdwlOCe5blA6h4FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQM xgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU8VTgenm4JpBdJQx7/7syvIaQilhN2fF2 5CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnpmspJTGptxFxH/GM/kW40iB4t UjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullztu37BDVj/SmgbGhvT UXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollEZcw9VIoj PKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kB jQRdxGjvAQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5Khdcxj Tlo6htNjRUuUy1Ld0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOpl KgMSoGpGamLSDzRs3SAJu4GFiHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zX fSmZqZwNp/6xosLCl3TKvFWX6421Vb/LWAOOAz/xSyS0GCUs/grBUfzu95+TTskR k7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOqe7/5y4bQkILGGMIux878DhAE D865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD7r5QL6iU57zI/B5U 03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhDVmrDKLWX Rm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUC XcRo7wIbDAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyyteP FmS9NAwdT8A6mA4s+WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8 WJVn0zH7LVCKMWo/tHE2rWyiQ1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJp rKZAtiDJ897vv1jP09fWLEBhaDsHqLhgckQpIoee0Id4FXGt7wxDsPwa64SUUCTY dt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7UXVMQlEKG7E31G1XQMk6sFAT F1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8SFA6Uc+Bjr0i1jdn xS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot8lIsHGAJ QHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw=3D =3DgM0D -----END PGP PUBLIC KEY BLOCK----- --------------F3743B38431FE220F0082440-- From nobody Fri Nov 8 04:43:33 2019 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 4F97C120120 for ; Fri, 8 Nov 2019 04:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] 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 i_ORUY3Cb3le for ; Fri, 8 Nov 2019 04:43:30 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7028120118 for ; Fri, 8 Nov 2019 04:43:30 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 9AB0B1A40; Fri, 8 Nov 2019 12:43:27 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Fri, 8 Nov 2019 07:43:25 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <2FF842AE-0FA8-40EA-9A82-672E3068EBAB@deployingradius.com> References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> To: Joseph Salowey X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Fri, 08 Nov 2019 12:43:32 -0000 On Nov 7, 2019, at 11:08 PM, Joseph Salowey wrote: > [Joe] How about=20 > "If an implementation supports an external PSK it MUST provide a way = to configure the realm so it can create an Anonymous NAI to send in the = EAP-Identity response. An EAP-TLS 1.3 implementation MUST NOT copy the = PSK-ID into the EAP-Identity response. " That's good. > If someone thinks there is a need to allow the PSK-ID to be copied = then the phrase could be extended with " unless there is prior knowledge = that this will have an acceptable impact to privacy and the use case = supports Identity responses that are not in the form of an NAI. =20 ... and the PSK identity is compatible with the requirements of the = EAP Identity field, i.e. UTF-8. > [Joe] The TLS 1.3 base spec teats certificate auth and external PSK = auth as mutually exclusive for a particular handshake. I do not think = it restricts a particular server from supporting both external PSK and = certificate authentication for separate connections. =20 OK. I'm back to "how do you tell?" If the document suggests that plain PSK is OK, it would be very useful = to describe the impact of that. What does an implementation do? How = should administrators tell PSK identities apart? If the EAP = authenticator can't control the derivation of PSK identities for = resumption, is it even possible to have manually provisioned PSKs? Alan DeKok. From nobody Fri Nov 8 13:03:50 2019 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 971C31208E5; Fri, 8 Nov 2019 13:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAOmVCOTHD8B; Fri, 8 Nov 2019 13:03:46 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750132.outbound.protection.outlook.com [40.107.75.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3929B120D6C; Fri, 8 Nov 2019 13:03:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XHpNRuD5NRUjo/4Bt2EskO9pmxx/GALxVO29T47h0uLuMqRjvpA1RvTIL6S7Rsbj3D2JIZ7twUqyaWEswrtylj31e3X2ooCaQ9/nJcSBwpJcBzswBTG83kw3F7fHBTucwKp+R+qp23Ghl9n7OE9EP+aB+0zIKe6Iz/bzvexI1oof37mnX1O0G9fmzADjd+OwJUDu+otOdEDfGeSZVbQdCeuowOvjc1mib9i1NUpH+eMmR+BeOzjQiVqOu4zW4lQXJYrq3rqpo7SDMew0g7h3LifKTBBjpuFTipacevNX6SPhuGDxXc/z6FhfIoDdkrfNo9jAf1C4afpq7tTEMUHvlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R3DaWlUoXhHbtn4xhN/n+DWtNyYc0dxirQCR00G0/xo=; b=OJOQuuuqowirVf58berD4OB8jlJ96wHOOhSSVIEbWdhBQ9qKoajWnes6tpjQQ4lqr1z0eSqJ3rhcRMajC3fqDZXwre20Zpr+6zPlm5d5GuCo1QknqD6njrDb9sFRL7wD43fE0q5rpIwdAoTK+UE5+Qs6hMjQ2BQfxzZYumS0eiNUwZHKc7OE8SifdSzw5DzDocccqXEeBBnO/pwjKT3e8gmRYTIIwI1ovkIqx+TeSaOqFqLTrsDEWn9U0IIpRLtGwJGeq+T5xRMp56O/ocPGxizIuKMoGS8yrTisp560EPNKlQ8qn9YB76eXZaWSUbMFJQ2Fc19y6xcVWe+hlhxqNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R3DaWlUoXhHbtn4xhN/n+DWtNyYc0dxirQCR00G0/xo=; b=gofvwjdINzc9NfRi7UOWPT9Tu9eeMjeCy9aBf4UD5FmVbaQvgXtJWe0CPLrhkW/r/zuH611lOh63uqXUBeez3Aqw23u7WZ9GG0PPyOCZYlLzpH/nxKaWH+QoEWJsQCEnLOuSeHYY6Mr1dXzsOqcOqg3KHgjD65xEVkCWmCTjRXs= Received: from CY4PR2101MB0868.namprd21.prod.outlook.com (52.132.103.39) by CY4PR2101MB0721.namprd21.prod.outlook.com (52.132.98.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.11; Fri, 8 Nov 2019 21:03:44 +0000 Received: from CY4PR2101MB0868.namprd21.prod.outlook.com ([fe80::90cb:c6c6:91d1:8283]) by CY4PR2101MB0868.namprd21.prod.outlook.com ([fe80::90cb:c6c6:91d1:8283%8]) with mapi id 15.20.2430.020; Fri, 8 Nov 2019 21:03:44 +0000 From: Jorge Vergara To: Alan DeKok , "Owen Friel (ofriel)" CC: "draft-ietf-emu-eap-tls13@ietf.org" , EMU WG , John Mattsson , Michael Richardson Thread-Topic: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) Thread-Index: AdWVkQAOhvHNjkPsSrmtom9842Q5uAAArUmAADjJqcA= Date: Fri, 8 Nov 2019 21:03:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=jovergar@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-08T21:03:41.1915447Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=79aa0fc7-53df-460c-ac00-34c8108cfbc1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=jovergar@microsoft.com; x-originating-ip: [131.107.160.137] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 060b4524-fa00-4ff1-b5a9-08d7648f23f7 x-ms-traffictypediagnostic: CY4PR2101MB0721: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0215D7173F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(376002)(136003)(346002)(396003)(13464003)(189003)(199004)(316002)(476003)(14444005)(256004)(86362001)(229853002)(71200400001)(26005)(76116006)(71190400001)(33656002)(11346002)(446003)(10090500001)(486006)(102836004)(478600001)(55016002)(7696005)(2906002)(6506007)(966005)(6436002)(6306002)(53546011)(9686003)(6246003)(4326008)(76176011)(81156014)(66066001)(8990500004)(8676002)(25786009)(22452003)(81166006)(99286004)(5660300002)(66476007)(52536014)(64756008)(66556008)(186003)(66446008)(66946007)(6116002)(3846002)(54906003)(110136005)(305945005)(10290500003)(7736002)(74316002)(8936002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR2101MB0721; H:CY4PR2101MB0868.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XHdPV/wCXWURjNXgPE7SJJg5Vyhfad7T8NQT/gNdTdAd1Zc4UL5KD0yHPC7nhpXeMv8+zCQhRb3QUhj2we6sc5lDTZu2xKHxXKiXPhvE4boDKRKFx1GGmfb2OoDXlG/2j/3DBCe12rSW0IDDVrIgTJ/xevzvX7iPetw5uz07yoheanjGu9ED5wqUfphNMHdzsvke3FBL6E5fcWQuA8mtNZO+7FcF8w2uEwXcl2M7XeEOJ+3F7SA9m85RZ2YLYf3e3LRogG2IkgyMSUbO6xpAMGUvEy5015D1DEikBISH2rmvCONUtjFR4R/XILpSzAX4a37bZePV8IdPgySc4/Q22YGcUbpoaThn1cLUf/huR50gXiG70TldBuGlj+TfmahHr6lwiKzrERretkALVIjVahyB5RU6DUh23etXLls5XWiHmvv4p3oHWASM8L4MlbG2 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 060b4524-fa00-4ff1-b5a9-08d7648f23f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 21:03:44.1402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3udHM8t1Y1pTvcE/fcY4ZmVbXi3v1sCBRzDtK+l05D8N+XAjaUfeo3j0sJo6jg/2ROKilfvbCRA/h1AnSHR2cQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR2101MB0721 Archived-At: Subject: Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Fri, 08 Nov 2019 21:03:49 -0000 > Since it looks like TEAP hasn't actually been implemented much, it's prob= ably best to move the TLS 1.3 fixes into a general "oops, we need to fix TE= AP" document. I can understand the reasoning here, but it's my opinion that we should def= ault to including TEAP changes for TLS1.3 in draft-dekok-emu-tls-eap-types.= If the changes become lengthy or complex then I would understand moving th= em to a different document. But it's my belief that the currently proposed = updates in draft-dekok-emu-tls-eap-types are sufficient. Are there further = TEAP specific changes that are thought to be needed? The latest Windows insider builds contain a TEAP implementation if you woul= d like to play with another supplicant implementation. -----Original Message----- From: Emu On Behalf Of Alan DeKok Sent: Thursday, November 7, 2019 9:50 AM To: Owen Friel (ofriel) Cc: draft-ietf-emu-eap-tls13@ietf.org; EMU WG ; John Mattsson= ; Michael Richardson Subject: Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-e= ap-tls13) On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) wrote: >=20 >=20 > [ofriel] Question to the WG: should the TEAP changes for TLS1.3 be includ= ed in draft-dekok-emu-tls-eap-types? If they're minor, it may be OK. > Or in draft-lear-eap-teap-brski - and note that the title is changed to "= TEAP Update and Extensions for Bootstrapping "? Or potentially both? Eliot= , Nancy and I had planned on adding TLS1.3 updates to draft-lear-eap-teap-b= rski, but haven't got it done yet. Since it looks like TEAP hasn't actually been implemented much, it's prob= ably best to move the TLS 1.3 fixes into a general "oops, we need to fix TE= AP" document. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Femu&data=3D02%7C01%7Cjovergar%40microsoft.= com%7Cff6d16a2debe42fe552608d763aade1d%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637087458127841459&sdata=3DuNLeQQn%2BPI2BAi1FweVNdKNG9MhBzxIu8= oozlp%2F774s%3D&reserved=3D0 From nobody Sat Nov 9 09:33:27 2019 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 64FD7120178 for ; Sat, 9 Nov 2019 09:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de 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 5vNOaYAPj6rs for ; Sat, 9 Nov 2019 09:33:23 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A7C120143 for ; Sat, 9 Nov 2019 09:33:22 -0800 (PST) Received: from [10.198.96.188] (tmo-111-8.customers.d1-online.com [80.187.111.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 479PPD2YfCzySG for ; Sat, 9 Nov 2019 18:33:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1573320800; bh=OuZYVcyZ8cGEcMGBW3x8M8+bRS3N+2a/lT0qKHr2AE4=; h=From:To:Date; b=ofxlA2QDz32zT7n8aTGwvTwqb2CxcKVAXcj/foTsEK/AyWntnYp98h94KYoCXRMmE D9veYebSavyLc7kbZCFVwBxcZDCe60rzpxbzl2dZoljMHsZ9nMmw3I3VmCYRIzq8Fg 7TrIDu3Hg6LnSJed+6sFvMYN6tP5V89Gn6f1Xrt2NBddwg0eWcVcOXCqmFXyFWnPR0 ZwG6b5kWc9BaOKzf+PZH7oRfHaVI768ExoyHxMCGwH7lUNUtTHcVSAmrgU2s01ZNW/ ae5yAKEvaOX+MVNSddACtvyCoT84IjkKn7hu2myLa8zfS58xnIrn9LkCjwZs30gKB6 2ydht4T9We2IA== From: Jan-Frederik Rieckers Openpgp: preference=signencrypt To: emu@ietf.org Message-ID: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> Date: Sat, 9 Nov 2019 18:33:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="awirpacQ37TSeWeUHdeKgwGFtHI3fiv1V" Archived-At: Subject: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 09 Nov 2019 17:33:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --awirpacQ37TSeWeUHdeKgwGFtHI3fiv1V Content-Type: multipart/mixed; boundary="CrVGpHelab5BJn4MsIK4YdYRyx4mbru18"; protected-headers="v1" From: Jan-Frederik Rieckers To: emu@ietf.org Message-ID: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> Subject: Idea: New X509 Extension for securing EAP-TLS --CrVGpHelab5BJn4MsIK4YdYRyx4mbru18 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi to all, I have submitted a draft for a new X509v3 extension to improve security in EAP environments by including information which is implicitly defined by the communication context in the certificate . This is done e.g. by including the Realm of the username in the certificate, to give clients the opportunity to decide if the certificate can be trusted apart from (user-set) configuration. https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/ This is a very early working state. I would be happy to get feedback if this is useful and the draft goes into the right direction. If people are interested I would prepare a short presentation about deployment experiences in the eduroam at the University Bremen, which have lead to this draft, together with the basic idea how to solve these problems. Probably this draft is not one which can or will be adopted by the EMU working group, but I think this is the right group of people for a first feedback. Kind regards Jan-Frederik Rieckers --CrVGpHelab5BJn4MsIK4YdYRyx4mbru18-- --awirpacQ37TSeWeUHdeKgwGFtHI3fiv1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO9n8U/6Yuq3qYHN1UHR7NOiKGm0FAl3G+F4ACgkQUHR7NOiK Gm2D/xAAkAN4pFT4XTFeYzmcXFobai13ruJoixnzzim1g693L5w/ObLAgoAWuGp+ Yp6L7+cJE0lXadIukqAV+X0ZQP4BcXqOFLzO1YFCjVtU+YY5+Ioi7iy2tONZYx4w EKXgD1vTnh4q9h/MOYZwMJRKQQR5uMEqQhOtxAlJumoo463TqHHTStakze5asWB6 w5oyE1YiD46ebSp3TMdPYH2SNKBp+W9ua+pDxyC+Ls/H9R5tA8sIPG8e9nN2A39W RNi9fKf1TWyZWdtZkqTPlyK7cnJO0Enz4Ex68OU8SwkDe9avkhs6gbeHTwkErDDm tpw4NFmP5pk4/V1hQfHU32eoH80Y3iQRyxZijdjCWx6mzXuqn19IG2TCHnmCirwx BiZJJpwhjCwIPqXI47ayLc42o+lUXiatVlwgZcZB0T14Az0/F4yDSRoS6EoGHjkg +iM6f7W6Gy3X4odIszT19CbUj2OWyXnzMzAniTOtjkY5c9OYkSy9Q9RzOmXCOYr5 IOJ8yvtfc3YQQdFpGnMNc3UUHBGie/xGDJKGZJVBOSV8eIHZCZ8KuRfdrDkCduaD wLqk8C7wYdNWS4dWKNWhMPwNzvD5Mkur03zNaxwLN0DXSeHPm065Fmemz/48YHlu 7iMU/txIQILsCOXU3n6Fc+KRyN6my7ct6/xcAp0kEzpwv/FMq5E= =vxpH -----END PGP SIGNATURE----- --awirpacQ37TSeWeUHdeKgwGFtHI3fiv1V-- From nobody Sat Nov 9 10:00:09 2019 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 78D3A120241 for ; Sat, 9 Nov 2019 10:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAQ_q-8jxGqE for ; Sat, 9 Nov 2019 10:00:06 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF12120143 for ; Sat, 9 Nov 2019 10:00:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3FB89300B1C for ; Sat, 9 Nov 2019 13:00:05 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZfyJheDH2vbb for ; Sat, 9 Nov 2019 13:00:03 -0500 (EST) Received: from [5.5.33.237] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id ACE1C300250; Sat, 9 Nov 2019 13:00:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> Date: Sat, 9 Nov 2019 13:00:03 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> To: Jan-Frederik Rieckers X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 09 Nov 2019 18:00:08 -0000 With a very quick skim, it appears that you are trying to do the same = thing as RFC 7585. Russ > On Nov 9, 2019, at 12:33 PM, Jan-Frederik Rieckers = wrote: >=20 > Signed PGP part > Hi to all, >=20 > I have submitted a draft for a new X509v3 extension to improve = security > in EAP environments by including information which is implicitly = defined > by the communication context in the certificate . > This is done e.g. by including the Realm of the username in the > certificate, to give clients the opportunity to decide if the > certificate can be trusted apart from (user-set) configuration. >=20 > https://datatracker.ietf.org/doc/draft-rieckers-eapparameterextension/ >=20 > This is a very early working state. I would be happy to get feedback = if > this is useful and the draft goes into the right direction. >=20 > If people are interested I would prepare a short presentation about > deployment experiences in the eduroam at the University Bremen, > which have lead to this draft, together with the basic idea how to = solve > these problems. >=20 > Probably this draft is not one which can or will be adopted by the EMU > working group, but I think this is the right group of people for a = first > feedback. >=20 > Kind regards >=20 > Jan-Frederik Rieckers >=20 >=20 >=20 From nobody Sat Nov 9 11:52:41 2019 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 E67B01200CE for ; Sat, 9 Nov 2019 11:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Au2PASUVjXTj for ; Sat, 9 Nov 2019 11:52:35 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B853312001A for ; Sat, 9 Nov 2019 11:52:35 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id A683E613; Sat, 9 Nov 2019 19:52:32 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> Date: Sat, 9 Nov 2019 14:52:29 -0500 Cc: Jan-Frederik Rieckers , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 09 Nov 2019 19:52:39 -0000 On Nov 9, 2019, at 1:00 PM, Russ Housley wrote: >=20 > With a very quick skim, it appears that you are trying to do the same = thing as RFC 7585. I think there's overlap, but it's not quite the same thing. Both proposals add a "known realm" as an X.509 certificate property. = They differ in their usage, and in who is checking the fields. I'll = quickly recap: RFC 7585 allows for RADIUS clients to dynamically discover RADIUS = servers via DNS. As a sanity check, the discovered RADIUS server should = induce the "known realm" in its server certificate. The RADIUS client = verifies that the "known realm" field matches the domain it was looking = for. Note that this verification is done by a RADIUS client, and is = independent of the authentication mechanism carried inside of RADIUS. = (PAP, CHAP, EAP, etc.) In this proposal, the supplicant is the component which is checking = the "known realm" field. The supplicant verifies that the NAI it's = sending matches the "known realm" sent by the server. It is common practice today for server certificates to include a = contact email address in the common name field. However, there's no = requirement that this is done. No one checks the domain of that email = address against the NAI being used by the supplicant. I think that this proposal may be useful. Given that the parties who = check this field do so for different purposes, it may be useful to have = two separate OIDs. On the other hand, RCC 7585 uses the OID for TLS connections which = then carry RADIUS packets. This draft would use an OID for EAP-TLS = authentications, which are carried inside of RADIUS, and then inside of = UDP / TCP / TLS / DTLS. The uses-cases may be different enough to = warrant re-use of the same OID. Alan DeKok. From nobody Sun Nov 10 08:16:21 2019 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 390AD120170 for ; Sun, 10 Nov 2019 08:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bto5U_4x1CnE for ; Sun, 10 Nov 2019 08:16:17 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E878A12004C for ; Sun, 10 Nov 2019 08:16:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F0A07300B0A for ; Sun, 10 Nov 2019 11:16:14 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MHSiHvUF56jq for ; Sun, 10 Nov 2019 11:16:13 -0500 (EST) Received: from [5.5.33.27] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 49349300A30; Sun, 10 Nov 2019 11:16:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Sun, 10 Nov 2019 11:16:13 -0500 Cc: Jan-Frederik Rieckers , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> To: Alan DeKok X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Sun, 10 Nov 2019 16:16:19 -0000 Alan: >=20 > On Nov 9, 2019, at 1:00 PM, Russ Housley wrote: >>=20 >> With a very quick skim, it appears that you are trying to do the same = thing as RFC 7585. >=20 > I think there's overlap, but it's not quite the same thing. >=20 > Both proposals add a "known realm" as an X.509 certificate property. = They differ in their usage, and in who is checking the fields. I'll = quickly recap: >=20 > RFC 7585 allows for RADIUS clients to dynamically discover RADIUS = servers via DNS. As a sanity check, the discovered RADIUS server should = induce the "known realm" in its server certificate. The RADIUS client = verifies that the "known realm" field matches the domain it was looking = for. Note that this verification is done by a RADIUS client, and is = independent of the authentication mechanism carried inside of RADIUS. = (PAP, CHAP, EAP, etc.) >=20 > In this proposal, the supplicant is the component which is checking = the "known realm" field. The supplicant verifies that the NAI it's = sending matches the "known realm" sent by the server. >=20 > It is common practice today for server certificates to include a = contact email address in the common name field. However, there's no = requirement that this is done. No one checks the domain of that email = address against the NAI being used by the supplicant. >=20 > I think that this proposal may be useful. Given that the parties who = check this field do so for different purposes, it may be useful to have = two separate OIDs. >=20 > On the other hand, RCC 7585 uses the OID for TLS connections which = then carry RADIUS packets. This draft would use an OID for EAP-TLS = authentications, which are carried inside of RADIUS, and then inside of = UDP / TCP / TLS / DTLS. The uses-cases may be different enough to = warrant re-use of the same OID. Thanks for the overview. It was very helpful. RFC 7586 define the NAIRealm as an otherName in the SubjectAltName of a = certificate. It seems that the NAIRealm name form works equally well, = regardless of the role that the certificate holder is performing in the = protocol. Russ= From nobody Sun Nov 10 14:57:27 2019 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 247A41200F1 for ; Sun, 10 Nov 2019 14:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdek5miMPX1d for ; Sun, 10 Nov 2019 14:57:24 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACDB1200E0 for ; Sun, 10 Nov 2019 14:57:23 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 99A94564; Sun, 10 Nov 2019 22:57:21 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Sun, 10 Nov 2019 17:57:19 -0500 Cc: Jan-Frederik Rieckers , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Sun, 10 Nov 2019 22:57:26 -0000 On Nov 10, 2019, at 11:16 AM, Russ Housley wrote: > Thanks for the overview. It was very helpful. Glad to help. > RFC 7586 define the NAIRealm as an otherName in the SubjectAltName of = a certificate. It seems that the NAIRealm name form works equally well, = regardless of the role that the certificate holder is performing in the = protocol. I agree. TBH, I like this proposal for securing EAP-TLS. It may take time to = deploy, but adding more clarity to certificates is always useful. I'd = be in favour of WG adoption of a document based on this. FWIW, a configuration file that creates certificates with the NAIRealm = is located here: = https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/certs/se= rver.cnf Alan DeKok. From nobody Mon Nov 11 01:42:16 2019 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 65C7812080B for ; Mon, 11 Nov 2019 01:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de 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 I2tVHDZr6X1A for ; Mon, 11 Nov 2019 01:42:12 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1000112087A for ; Mon, 11 Nov 2019 01:42:11 -0800 (PST) Received: from [134.102.5.27] (dhcp4.noc.uni-bremen.de [134.102.5.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47BQrd5fDFzyNp; Mon, 11 Nov 2019 10:42:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1573465329; bh=v8zczupxBBeZchXp2gY7JcL/QMx6uhHIThAwHbsSD5M=; h=To:Cc:References:From:Date:In-Reply-To; b=FGwsLmh2CatxT23YC706fGI87WaLejTbtx7jWO7iuj69hSoNZjjmBriMZX2S2pEw2 HuzDP5KdIP1qspX9D+5wjOWvQZqzkHcnrNI0O1mVufXNjW/wftMO/w6WT8L5zR8sDL 6aGkByiz5Fj1Xz7tZx6KqcC9i3IYQ++dzF8RYqTjCelPAA/kPQCGEHl7P1M6/uAVqY 7tydadDLekPl1Ir0Gj9epM/7JkTK0MfHviBGhMfKrjocU++8b14k8AawPmWB4jiP+O xF5d+bfs6kHWJ72xM8oB2Y3y8y11J8Fv+ifoAKhT2r7FdpigIr/ZxKH0nOaXOrNekN upFChjh/XRXbw== To: Alan DeKok , Russ Housley Cc: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> From: Jan-Frederik Rieckers Openpgp: preference=signencrypt Message-ID: <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> Date: Mon, 11 Nov 2019 10:42:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0dA6rpZBg73XcgtpfFoQL3wxxuMJC6IxS" Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Mon, 11 Nov 2019 09:42:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0dA6rpZBg73XcgtpfFoQL3wxxuMJC6IxS Content-Type: multipart/mixed; boundary="oIMA13d95gqy4PZcLyhd7tYGMcINj6WsA"; protected-headers="v1" From: Jan-Frederik Rieckers To: Alan DeKok , Russ Housley Cc: emu@ietf.org Message-ID: <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> In-Reply-To: --oIMA13d95gqy4PZcLyhd7tYGMcINj6WsA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, Thank you for your feedback. I was unaware of RFC 7585. I had a brief look on it and it seems that the certificate part could be used for the goal I try to achieve. I'm not quite sure if the naiRealm should be used for validation on supplicants for EAP-TLS. I would assume it would not be a security issue, but I don't have enough experience to be sure about that. The main reason why I submitted this draft is my experience from the deployment of eduroam at University Bremen. With expiry of the used root CA and the needed migration, we have forced all our users to use one specific outer Identity, to be sure the users configure their devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroam.org) instead of a manual configuration, because in our experience manual configured devices almost always lacked configuration for certificate checking. But I just have experience in local deployment, the federation connections are done at higher levels (country research networks), I don't have an insight there. Greetings, Jan-Frederik Rieckers --oIMA13d95gqy4PZcLyhd7tYGMcINj6WsA-- --0dA6rpZBg73XcgtpfFoQL3wxxuMJC6IxS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO9n8U/6Yuq3qYHN1UHR7NOiKGm0FAl3JLPEACgkQUHR7NOiK Gm2qzQ/9FYouRLODfp9gvEms5ERdLTnxMZmR4YinulSAQpAPxepHdfQwOUBNLrqw 0Vt8PGc2ILtNqDOjBHlS+Ao8Q2gW9+0acymuj0TnnfYQhce2zRjw0vnQ9snsyIlE Wg6ROwzKGgyUc2eZpuGmUGLHVhDj7+VC5xwFcsLHQCRCl5ADad+pjxGK0VZcojff fpnT7d6ipmZzWYhoDa3Mj5LAFTvf5RQ3M5THnRXhoqpfvaQFD76MHgZapLA7c/e8 pAs1f7x/szKd9PyE100Q4d2KFkUOREYZRT33coXw/CtXKUwZq2Xe+1ZCxd+a2KD7 OP4fN+F0uGVRQ9xwWUPUUkLQtnXR2RqizrcVHQgjHeXyM/qfyNrH2gVpK0W8PcCf gvXfe7V0EsR9i/NtgyCmvQeTJZD1ALI++rco6lXUMUeiWdWq9Y9/9Z8kZ2aFUG87 b+tWTEC1VWDhnu+emnI8YX8qokuhn8S5tjR8a6AhnVg257xOVwtdH3AVFK/wDn9L odbfszvVm9rmxjfNHBQC2RFuxBrJz2kURklTdT89DhtCkz1OEJed+Tn+QHIGK01x mTbKm65yJyOSpiq06FLA0ZBQeJ5zZRh35ZjbCvHRAWvGZk7K+Q4PMS/EHoDySay6 jiKmaI+cEgRU05NMdBJEiziqmhEoNibGvFWucFx+x7eZV1jrRD0= =buvQ -----END PGP SIGNATURE----- --0dA6rpZBg73XcgtpfFoQL3wxxuMJC6IxS-- From nobody Mon Nov 11 09:27:57 2019 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 CCB20120AC9; Mon, 11 Nov 2019 09:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 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, URIBL_SBL=0.5, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KUk9K6BT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=o9hEm1fE 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 kuP1hwwbGt2j; Mon, 11 Nov 2019 09:27:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5866C120AC2; Mon, 11 Nov 2019 09:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4378; q=dns/txt; s=iport; t=1573493271; x=1574702871; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TDBfLg0tD2RyvG3cyRaHToTzoZ/94yFc0wf9+zRbrVo=; b=KUk9K6BTGsQCw8/OWxjXcaT/3RLCB75+yre48A5LvU8b1MVYw5MjpR4D Ifl1YWbYnssOOBLjK+5QAMJX5IfUgy6R8/WmNJoiaSHFhVq4wL1RPbf4a relVykSopFPzsBU/mOXzVzUCC0fMbWlPHz9iCDTuc/jKGrFG+RQ6H7/5s 4=; IronPort-PHdr: =?us-ascii?q?9a23=3Au7IBkxU9WoiIPuU2ahiwHzvH3sbV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank9Et5DWVtN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAAAmmcld/5RdJa1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYFtAQEBAQEBCwGBSlAFbFggBAsqCod?= =?us-ascii?q?lA4prgl5/lwGCUgNUCQEBAQwBASMKAgEBhEAChBQkNwYOAgMLAQEEAQEBAgE?= =?us-ascii?q?FBG2FNwyFUQEBAQECARIoBgEBNwELBAIBCBEEAQEBHhAyFAkIAQEEDgUIGoM?= =?us-ascii?q?BgkYDDiABAgyiDgKBOIhggieCfgEBBYUNGIIXCYE2AYwTGIFAP4ERRoIXNT6?= =?us-ascii?q?CYgEBAgGBNBQYg0CCLK4UCoIlhxeFJIkkgy+WSpZ9kUACBAIEBQIOAQEFgWg?= =?us-ascii?q?jgVhwFYMnCUcRFJA2g3OFFIU/dAEBgSaMPQGBDgEB?= X-IronPort-AV: E=Sophos;i="5.68,293,1569283200"; d="scan'208";a="438099129" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 17:27:48 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xABHRm6Q028426 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 17:27:49 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 11:27:48 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 12:27:46 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 11 Nov 2019 12:27:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M+CkiqmD4pzomcfioO6sEMv2IXi5XwvlH+Z7KDKjRG455h2N43c+v7E6nqUQm71Tn0bBP1HPjgd2g/Z4UjvY3OaFErPmCuVd+JibD6knMIC8obaQjU3ACgbiSJRboTN5/p3kDR4eeyUGL6O9mGXqHVa44kgJKFHBdfdc+Riy5ad9p6iT8MOnMuYf6KygIcK3NEtYhlf7wmJiDH08aDdm4ajN9WI7ID69shhZ6fmGChmlXUjODoGVP9fB5oVAMQA+jU9xQDYQG0kzNfaDoEiJuGEY7f+o4JUvqixFnFCgdJvKLPFLn+U1kJJqzDjSFxSUdyFdCly33TB3rQiwrW+BYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QNf5hh2WamBVuOx2XZJjAAODr8s1jsTYTtLfAZ5p4m4=; b=M/NxC6UJG/cWLAb0xmGTKhHEs32q7qL50fT1K6PEytkdHdeuTu3TQZKaoF1P9uC8ooRFXoqXq39W/pM/PhRnR27IeLTA7Da3x/mwRE+37nXJ2zbaQsHi7qdBjwLHCgZgJGmo+lYyDmQXorSNJSE3ehnNT7utXxIIMLq+Qoom/W9nKcaN7hr6sEMhkpXrZd+Ym12srUfNT9r/QSUgIBaHcRWQW/k/9iIopUFLFCBivjXk/TBrxR8DgZztP4IzhWLCvj1ZcNQ9lbYbod3i8smBZtrj7eCM6097Vc7UJmwCWr2vLEr5D5u+CQntWyG0h5mv8j5JZblbp5DmnGNamHb2qQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QNf5hh2WamBVuOx2XZJjAAODr8s1jsTYTtLfAZ5p4m4=; b=o9hEm1fE3A1LOUdHCZZ0PTO5rBXzKnX+DNHcmVEUV08EzFg/ryhyDrtZH0HcNDuQbAKp0Po1eHWs5BafAe/GUBtT+Ee950f2s53qD/Z/FavUpsrQomO8Pk63b1w/Ol33yDLWZYCRtrE5FNDbsUkAC6IhzG0qvcrnL0szaabscSU= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4206.namprd11.prod.outlook.com (52.135.36.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Mon, 11 Nov 2019 17:27:45 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 17:27:45 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok CC: Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , EMU WG , John Mattsson , Michael Richardson Thread-Topic: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13) Thread-Index: AdWVkP6miTdVx/8XQ5+EVyVKdjyrBgAAdLaAAMISpoA= Date: Mon, 11 Nov 2019 17:27:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f288c1d-cea2-422e-07bf-08d766cc776c x-ms-traffictypediagnostic: MN2PR11MB4206: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(189003)(13464003)(199004)(186003)(316002)(53546011)(6436002)(54906003)(305945005)(55016002)(66446008)(6116002)(66066001)(66946007)(66476007)(66556008)(102836004)(256004)(14444005)(74316002)(64756008)(6246003)(71190400001)(71200400001)(86362001)(229853002)(76116006)(478600001)(25786009)(6506007)(81156014)(7736002)(6916009)(7696005)(76176011)(81166006)(9686003)(14454004)(26005)(33656002)(99286004)(11346002)(2906002)(4326008)(476003)(966005)(8936002)(6306002)(5660300002)(8676002)(52536014)(446003)(486006)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4206; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: l/DXAV7lx9vtNar0S2TUMPgQ7CWnaS1F5DK2FiOUso0ehiUbIdV4vogXPkzQIiivTHuzyzEy85agm/rXGXAOP85aWLI7Nz8DbVAJBEboycIGeof8SgH5T7LWoQAEAvwDSqU1KG1ww5nYH69xD9qkVOErnB6uWTANnYolZ7HWbO0tOcEo1xjy5d1rca9RXhlQ+toEu22s5g/Gi28PgfC+yo5eVhvKRPUrL1n+wVmLViTXIXe0/OC8zxyt8ZKkfd2n+N5wp87qd/q0H09meSB2aDut38Aul+IiuOXgVBpOEPKJJPy+ClWGC3/Wh+5dzv2SC5JUD9Ch8qsLTbj5c33Oz5xSeDQBoh0sdyrjrF42AunI0OiIvdXpMlFIX01PwN1kL8JEd2UiX324NziodEt7caRw6Td9S/YyyFwAGvfIsk3N6Kfl6D2I6uOemgbeJaIUDIiZZaNQaylpMLJOSBRL/uVxgjctZ9RLbIU3mCqut5o= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f288c1d-cea2-422e-07bf-08d766cc776c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 17:27:45.6745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RpAMzpejFnw45QgqljIYpchM0lyss2WKjebfEmskEdyZ74n0I9zh7uO8OGQBMhLMubaZgkFowjy2moazCbnBhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4206 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Mon, 11 Nov 2019 17:27:56 -0000 > -----Original Message----- > From: Alan DeKok > Sent: 07 November 2019 17:43 > To: Owen Friel (ofriel) > Cc: Joseph Salowey ; draft-ietf-emu-eap-tls13@ietf.org; > EMU WG ; John Mattsson > ; Michael Richardson > > Subject: Re: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu- > eap-tls13) >=20 > On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel) wrote= : > >> [Joe] Is EAP Identity Synonymous with the NAI? > > > > [ofriel] I'd also like to definitively understand this. Neither RFC3748= or > RFC7542 are clear on this. Should this be an errata to clarify.. somewher= e? >=20 > The EAP Identity can largely be anything, so long as it is UTF-8. >=20 > The *recommendation* in RFC 7542 is to make it an NAI. But that isn't > mandated anywhere. >=20 > I'm not sure there's any errata required. [ofriel] On reading RFC 7542 again, I certainly agree with the sentiment th= at the NAI is recommended for EAP identity, but I don't see that actually b= eing explicitly definitively stated anywhere in the document. >=20 > > Two other questions on RFC3748. Section 5.1 states: > > " It is RECOMMENDED that the Identity Response be used primarily f= or > > routing purposes and selecting which EAP method to use. " > > > > Is it defined anywhere how the Identity is used for EAP method selectio= n? >=20 > It is absolutely not mentioned anywhere. For the simple reason that EA= P > provides for method negotiation. We don't need to overload the Identity = field. [ofriel] then why does https://tools.ietf.org/html/rfc3748#section-5.1 expl= icitly state " It is RECOMMENDED that the Identity Response be used primari= ly for routing purposes and selecting which EAP method to use." It explicitly states: "selecting which EAP method to use " Should there be an errata for RFC 3748 to remove the last few words from th= at sentence: "and selecting which EAP method to use"? And the "EAP provides for method negotiation" is via Nak messages, Ok, then= my confusion was on the EAP method selection statement in section 5.1. >=20 > The issue we're running into here is not about EAP method selection. I= t's about > *TLS* method selection (PSK vs certs). And that officially has little to= do with > EAP. [ofriel] Sure, but that's not what I am getting at, I was asking about EAP= method selection and my confusion between the statements in sections 5.1/I= dentity and 5.3/Nak. >=20 > > Or is this EAP method specific and should be defined in the method spec= ific > draft? >=20 > No EAP document should recommend overloading Identity in order to do EA= P > method selection. >=20 > > E.g. we have documented in https://tools.ietf.org/html/draft-lear-eap-t= eap- > brski-05#section-5 that: > > > > " A device that has not been bootstrapped at all SHOULD send an > > identity of teap-bootstrap@TBD1. " > > > > If we register that "teap-bootstrap@TBD1" with IANA, then it could be t= he > mechanism by which the peer tells the server that it wants to use TEAP. I= f the > server does not support TEAP, it will return an error response. >=20 > The discussion prior to IETF 105 was that we should use the ".arpa" dom= ain: > https://www.iana.org/domains/arpa That domain is explicitly intended for= this > kind of negotiation. >=20 > Note that using ".arpa" still isn't EAP method selection. It's instead= signalling > something else. >=20 > > For routing, the Identity provided includes a realm and it could be ano= nymous: > e.g. "@example.com". If the server cannot route to that domain, it return= s an > error. >=20 > i.e. an EAP Failure message. >=20 > > EAP provides no mechanism to return an error code to the peer. How coul= d we > signal in EAP the error difference between routing vs EAP method unsuppor= ted > failures? Or can we at all? >=20 > EAP provides for a NAK for negotiation, and a Notification packet for s= ignalling > errors or messages. Unfortunately, most supplicants don't support Notific= ation. > And the ones that do won't show Notification messages to the end user. [ofriel] Ok, thanks. >=20 > Alan DeKok. From nobody Mon Nov 11 09:28:31 2019 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 6473E120AD6; Mon, 11 Nov 2019 09:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 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, URIBL_SBL=0.5, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=By2r0+G9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vI7hDq4s 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 IxVNVmDMCf1x; Mon, 11 Nov 2019 09:28:27 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DAF120AC9; Mon, 11 Nov 2019 09:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3918; q=dns/txt; s=iport; t=1573493307; x=1574702907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XtkRIPnIMfQ1Ny4HAC/ApqGqmmKyc0T8HeqcGM+2zVM=; b=By2r0+G9i9mRlNeyq20ZXJHX1S93AuYsr6goCC58p11pdn/IwKJ/l6Q8 FkKpQujHB18+rp6MUAgGQmJWJkf5TNxe9Anaq9yQcxsTsUi4gUSe8DAJl 9IS68NLwZXl7lmdIP5JJ3XATPyokqrP+I1EaT47efhq9PBYYXhQvbQ6ek I=; IronPort-PHdr: =?us-ascii?q?9a23=3A/0Muvx2qPUfWb9w+smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQDkPhLfPuRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABimcld/5JdJa1bCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBawQBAQEBCwGBSlAFbFggBAsqCoQfg0YDimu?= =?us-ascii?q?CXpgAgS6BJANUCQEBAQwBASMKAgEBhEACF4N9JDUIDgIDCwEBBAEBAQIBBQR?= =?us-ascii?q?thTcMhVEBAQEBAgESEREMAQE3AQsEAgEIEQQBAQECAiYCAgIwFQgIAgQOBQg?= =?us-ascii?q?agwGCRgMOIAECDAOiBwKBOIhgdYEygn4BAQWBNAGDWBiCFwMGgQ4oAYwTGIF?= =?us-ascii?q?AP4ERRoJMPoJiAgKBNRQYgw4ygiyQDJ4ICoIlhxeOSJl5ln2RQAIEAgQFAg4?= =?us-ascii?q?BAQWBVAE2gVhwFYMnUBEUkDYHg2yFFIU+AXQBAYEmjD0BgQ4BAQ?= X-IronPort-AV: E=Sophos;i="5.68,293,1569283200"; d="scan'208";a="663835132" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 17:28:25 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xABHSPkJ030759 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 17:28:25 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 11:28:24 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 11:28:23 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 11 Nov 2019 12:28:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nXIcr6TOdniQ3IPMEjmMNMmHKzj3s2k/BpjB41JkVYymjVYbuDweTCqpYyjoDq0cv0Syt9/gZYL/jyjf3hT1DFn2JSm/HBwXfkIFKtUoJglYv0KD+RvFE8urnMhOjkBusgOyVgJ3IScqzs3mX7BiYoRz+ynLcAIC27FLCK7Mze4m92dMnFqhb4QAWOQ2iQqgSQOXPLZ+rmFDGd819KImQ52r8jnhKn4p+ykTLlFb9IJVB/G8GrfJhsyWKmRW0xG5hGGV6gkQ1hh4nCamDs46K/JuwMoqy1cA9DYV4i5xvpZ6OtKAjKx8ZA5BErq4556nW7GoIA1K5jRXjDaTF4hFTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XtkRIPnIMfQ1Ny4HAC/ApqGqmmKyc0T8HeqcGM+2zVM=; b=bRQt1OvCu0tlq3IuO5mezGgLEqe9KPtAIFmdFBxYzXCIA1yRXuSIb8Vr7hFjJbFj/9Fr5jjwAF6M/w+zMhC0ZVSELdGg6y6rSEnQOMzqt5maWQr7/j3fUsAKzW03Bb+M4qb1tRU6RN52ooA61tQpRzJ0WB2gGLwbsmMY5EfQy5mCuhm/Y+Qf4JWdHY3QjrLKOq/OkgU+YxpLyBWCQ5/Mfq/wPD82tMJnXX+nu+DTpT+qxKvPgcuah6J1pyZXhtcogQiVZBlbkol+h1Lkps+0KyfQkriP2RrsqC1/ny8lqm9aypG+8nslfbsERfCfsRoUafQ0cNED7ZSRkBl+Mq4UWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XtkRIPnIMfQ1Ny4HAC/ApqGqmmKyc0T8HeqcGM+2zVM=; b=vI7hDq4snNQhsiw+gyI1MFgD9KJV8xqun25DNhR3ScsiPcxRyk0xPihbpVT0eH002JUL1SaBIrFF8iSByeXq3hBfLMzvEzNftYypYEWBP6zL5yF0JZhIThdA7EG7D9zmAPCLB3BPN4ARPf7c1FjNCP5ciNqjwgYtb4vjF4ofV5U= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4206.namprd11.prod.outlook.com (52.135.36.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Mon, 11 Nov 2019 17:28:21 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 17:28:21 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok CC: Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , John Mattsson , Michael Richardson , EMU WG Thread-Topic: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Thread-Index: AdVKJoKyKr1G5+9hQuKLAEK5rLYqPgfSdnOQAABeFAAABkCJgP//55mA//bAJjCAEoqCAIADGZ8AgBnulgCABSSTAIAB0o2AgAAF5ACAAC3sAIAABveAgB1CFQCAAD1cgIAAJDQAgAEmKQD/9DAisIAXqxMA//nquBA= Date: Mon, 11 Nov 2019 17:28:21 +0000 Message-ID: References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> In-Reply-To: <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 083a7dda-7348-4b59-05d5-08d766cc8c9b x-ms-traffictypediagnostic: MN2PR11MB4206: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(189003)(13464003)(199004)(186003)(316002)(53546011)(6436002)(54906003)(305945005)(55016002)(66446008)(6116002)(66066001)(66946007)(66476007)(66556008)(102836004)(256004)(74316002)(64756008)(6246003)(71190400001)(71200400001)(86362001)(229853002)(76116006)(478600001)(25786009)(6506007)(81156014)(7736002)(6916009)(7696005)(76176011)(81166006)(9686003)(14454004)(26005)(66574012)(33656002)(99286004)(11346002)(2906002)(4326008)(476003)(966005)(8936002)(6306002)(5660300002)(8676002)(52536014)(446003)(486006)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4206; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: L46nxhHjnZ4U3Kkxhl+DP7a+k6WrMIEj6wHnH+AtIH0Wxec3LP2jQo8EUFvDQFCXfxCgis57DXdwmPyUhTT0lL6b5Fw/bgpFdLNBgD0Ch3P4GjiWKAHZ7dxluG8RasjvyzQ3WdAf5VblL9mj0ixTVyrnZXd5Lmr7nKFYJ1HstMQT4jydSrRA56McnEBZysxV/aKG67bZ/tlmgkBU2FwZNBuYcxwo+Ei6oSv3pO/oYkXCXbgGSNT/hehWE6qob5he5GxU8JEmWWZ0XBhLTheCVwHCz8N7kB1qif+jYmbtxDsxoGiWlNHFrTdNgkk1SMpC3QQ1/rigpFz08iTUfRVesLZpsHxgI4y9Ib/AL20TjkwkY1gvMdA1pxotkht4r91cnsYTpmVOr3iA7d/HKTw1pfS5jSxVrnrGSr1kg66fUjC+NombBHrJn3SZw6O9Fz9W5S0IFwtFYFHofwqVbs+gCzDMITLkKs6zGwwH/LBcTyY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 083a7dda-7348-4b59-05d5-08d766cc8c9b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 17:28:21.2237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MjUgLDPpfLzTdZn5c3fSKMBK0Zh8Uqnpfn/HyXCMoQo2d+aQl7nEjOA+N9lS4Lfdqc9OKSnOrrUCi80ECSXnbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4206 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Mon, 11 Nov 2019 17:28:29 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxhbiBEZUtvayA8YWxh bmRAZGVwbG95aW5ncmFkaXVzLmNvbT4NCj4gU2VudDogMDcgTm92ZW1iZXIgMjAxOSAxNzo0OA0K PiBUbzogT3dlbiBGcmllbCAob2ZyaWVsKSA8b2ZyaWVsQGNpc2NvLmNvbT4NCj4gQ2M6IEpvc2Vw aCBTYWxvd2V5IDxqb2VAc2Fsb3dleS5uZXQ+OyBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTNAaWV0 Zi5vcmc7DQo+IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb249NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmc+OyBNaWNoYWVsDQo+IFJpY2hhcmRzb24gPG1jckBzYW5kZWxtYW4uY2E+OyBF TVUgV0cgPGVtdUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtFbXVdIFBPU1QgV0dMQyBDb21t ZW50cyBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMNCj4gDQo+IE9uIE5vdiA3LCAyMDE5LCBhdCAx MjozMCBQTSwgT3dlbiBGcmllbCAob2ZyaWVsKSA8b2ZyaWVsQGNpc2NvLmNvbT4gd3JvdGU6DQo+ ID4gW29mcmllbF0gVExTMS4zIGV4cGxpY2l0bHkgZG9lcyBub3QgYWxsb3cgYm90aCBQU0sgYW5k IGNlcnRzIHNpbXVsdGFuZW91c2x5Lg0KPiBkcmFmdC1pZXRmLXRscy10bHMxMy1jZXJ0LXdpdGgt ZXh0ZXJuLXBzayBkb2VzLCBidXQgdGhhdOKAmXMgRXhwZXJpbWVudGFsLiBJIGRvbid0DQo+IHRo aW5rIFRMUyB3aXRoIGV4dGVybiBQU0sgaXMgcmVhbGx5IGludGVuZGVkIGZvciBXZWIvQnJvd3Nl ciBIVFRQUw0KPiBjb25uZWN0aW9ucy4gSXRzIG1vcmUgZm9yIGRldmljZXMvdGhpbmdzIHdoaWNo IGFyZSBwcmVwcm92aXNpb25lZCB3aXRoIHRoZQ0KPiBleHRlcm4gUFNLLg0KPiANCj4gICBUaGVu IHRoZSBFQVAtVExTIGRvY3VtZW50IHNob3VsZCBkaXNhbGxvdyBpdCwgdG9vLiAgSWYgVExTIDEu MyBkb2Vzbid0IHN1cHBvcnQNCj4gaXQsIEkgZG9uJ3Qgc2VlIGhvdyBzb21ldGhpbmcgYnVpbHQg b24gdG9wIG9mIFRMUyAxLjMgY2FuIHN1cHBvcnQgaXQuDQoNCltvZnJpZWxdICBUTFMxLjMgZG9l cyBub3QgYWxsb3cgYm90aCBQU0sgYW5kIGNlcnQgYmFzZWQgYXV0aCBzaW11bHRhbmVvdXNseSBv biB0aGUgc2FtZSBUTFMgc2Vzc2lvbi4gSXQgZG9lcyBhbGxvd3Mgc3VwcG9ydCBvZiBib3RoIFBT SyBhbmQgY2VydCBiYXNlZCBhdXRoIG9uIHRoZSBzYW1lIHNlcnZlciwganVzdCBvbiBkaWZmZXJl bnQgVExTIHNlc3Npb25zLiBXaGF0IGRyYWZ0LWlldGYtdGxzLXRsczEzLWNlcnQtd2l0aC1leHRl cm4tcHNrIGRvZXMgaXMgYWxsb3cgYm90aCBQU0sgYW5kIGNlcnQgYmFzZWQgYXV0aCBzaW11bHRh bmVvdXNseSBvbiB0aGUgc2FtZSBUTFMgc2Vzc2lvbi4gSSBjYW4gc2VlIGhvdyBteSBzdGF0ZW1l bnQgd2FzIGNvbmZ1c2luZywgYXBvbG9naWVzLg0KDQo+IA0KPiA+IEluIFRMUzEuMywgYnkgZGVz aWduIHRoZSBwcm90b2NvbCBkb2VzIG5vdCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gcmVzdW1wdGlv bg0KPiBhbmQgZXh0ZXJuYWwgUFNLcywgYW5kIHNheXMgbm90aGluZyBhYm91dCBQU0sgSUQgZm9y bWF0LCBhcyBjb21tZW50ZWQgaGVyZQ0KPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3Rscy9RNUs4SFNQUGdMUm9qUXdYYlY0WlRJeEJJSDAgLA0KPiBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Rscy9YX3o4cGMzb1MyQXU3S2Fqak1obFdoUDFVUGMN Cj4gDQo+ICAgV2hpY2ggaXMgZmluZS4gIEknbSBoYXBweSB0byBoYXZlIFBTS3MgYmUgYW55dGhp bmcuICBUaGUgY2F2ZWF0IGlzIHRoYXQgd2UgdGhlbg0KPiBNVVNUIGZvcmJpZCB0aGUgUFNLcyBm cm9tIGJlaW5nIGNvcGllZCB0byB0aGUgRUFQIElkZW50aXR5IGZpZWxkLiAgU28gdGhlIEVBUC0N Cj4gVExTIGRvY3VtZW50IGhhcyB0byBtYWtlIGEgcmVjb21tZW5kYXRpb24uDQo+IA0KPiA+IEFu ZCBpdHMgYXBwbGljYXRpb24gc3BlY2lmaWMgaG93IHRoZSB0d28gYXJlIGRpZmZlcmVudGlhdGVk LCB0aGUgc3BlYyBzYXlzDQo+IG5vdGhpbmcgYWJvdXQgaXQ6DQo+IGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGxzL2J0TG5aRVJZdjhHSkoyUEZVa3NqTnNEeXY4bw0KPiA+ DQo+ID4gSSBzdGlsbCBkb24ndCBnZXQgd2h5IEVBUC1UTFMxLjMgc2hvdWxkIHBsYWNlIHJlc3Ry aWN0aW9ucyBvbiB1c2Ugb2YgVExTMS4zLg0KPiBTdXJlbHkgaXQgc2hvdWxkIGJlIGFuIEVBUCBz ZXJ2ZXIgaW1wbGVtZW50YXRpb24gZGVjaXNpb24gb24gd2hldGhlciB0byBzdXBwb3J0DQo+IHRo YXQgZmVhdHVyZSBvciBub3QsIGJ1dCB3ZSBzaG91bGQgbm90IHByZWNsdWRlIGEgc3BlY2lmaWMg RUFQIHNlcnZlcg0KPiBpbXBsZW1lbnRhdGlvbiBmcm9tIHN1cHBvcnRpbmcgZXh0ZXJuIFBTSyBi eSBkaXNhbGxvd2luZyBpdCBpbiB0aGUgc3BlYy4gSWYgYQ0KPiBwYXJ0aWN1bGFyIEVBUCBzZXJ2 ZXIgZG9lcyBub3Qgd2FudCB0byBzdXBwb3J0IGV4dGVybiBQU0sgLSB0aGF04oCZcyBmaW5lLg0K PiANCj4gICBUaGVuIHdlIG5lZWQgdG8gZ2l2ZSBndWlkYW5jZSBvbiB3aGF0IGltcGxlbWVudG9y cyBhbmQgYWRtaW5pc3RyYXRvcnMNCj4gc2hvdWxkIGRvLiAgRXZlbiBpZiBpdCBtZWFucyBhZGRp bmcgdGV4dCBzYXlpbmcgInlvdSBjYW4gZG8gY2VydHMgT1IgUFNLLCBidXQNCj4gTk9UIEJPVEgi Lg0KW29mcmllbF0gWW91IGNhbiBkbyBjZXJ0cyBvciBQU0sgb24gdGhlIHNhbWUgVExTIHNlcnZl ciwganVzdCBub3Qgb24gdGhlIHNhbWUgVExTIHNlc3Npb24uIFVubGVzcyBkcmFmdC1pZXRmLXRs cy10bHMxMy1jZXJ0LXdpdGgtZXh0ZXJuLXBzayBiZWNhbWUgYSB0aGluZy4NCj4gDQo+ICAgQWxh biBEZUtvay4NCg0K From nobody Mon Nov 11 09:39:35 2019 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 D605D1201DC; Mon, 11 Nov 2019 09:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjfQtrVj63UZ; Mon, 11 Nov 2019 09:39:27 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDF412006F; Mon, 11 Nov 2019 09:39:27 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 5BBD619AD; Mon, 11 Nov 2019 17:39:25 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 11 Nov 2019 12:39:23 -0500 Cc: Joseph Salowey , "draft-ietf-emu-eap-tls13@ietf.org" , EMU WG , John Mattsson , Michael Richardson Content-Transfer-Encoding: quoted-printable Message-Id: <359CBF01-BEA1-4FF4-8465-146881972164@deployingradius.com> References: To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13) 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: Mon, 11 Nov 2019 17:39:33 -0000 On Nov 11, 2019, at 12:27 PM, Owen Friel (ofriel) = wrote: > [ofriel] On reading RFC 7542 again, I certainly agree with the = sentiment that the NAI is recommended for EAP identity, but I don't see = that actually being explicitly definitively stated anywhere in the = document. The document recommend using NAI everywhere. Unfortunately it = couldn't update EAP. >> It is absolutely not mentioned anywhere. For the simple reason that = EAP >> provides for method negotiation. We don't need to overload the = Identity field. >=20 > [ofriel] then why does https://tools.ietf.org/html/rfc3748#section-5.1 = explicitly state " It is RECOMMENDED that the Identity Response be used = primarily for routing purposes and selecting which EAP method to use." >=20 > It explicitly states: "selecting which EAP method to use " See the 3G specs, or Section 4 of RFC 7542 For instance, some EAP methods apply method-specific pseudonyms in the username part of the NAI [RFC3748]. > Should there be an errata for RFC 3748 to remove the last few words = from that sentence: "and selecting which EAP method to use"? I don't think so. > And the "EAP provides for method negotiation" is via Nak messages, Ok, = then my confusion was on the EAP method selection statement in section = 5.1. EAP is unfortunately complex. Alan DeKok. From nobody Mon Nov 11 09:52:37 2019 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 BA203120AF8 for ; Mon, 11 Nov 2019 09:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 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, URIBL_SBL=0.5, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=d68sYn/m; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cvQcmGCh 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 s-EzJtOvEykg for ; Mon, 11 Nov 2019 09:52:32 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563CB120A59 for ; Mon, 11 Nov 2019 09:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3653; q=dns/txt; s=iport; t=1573494752; x=1574704352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YZ+f1+7Eg8g6CQeWooMmVltSZmdxVQhnlygQnr0zzmA=; b=d68sYn/mcmlktDrricsaISHH0phHsr107FJPymBzRisiI6S4XrLCxGcw lV/4YJ5QT4BbmNo++OkYfC28wfze9shpjxsPIHqAVMyOw2X9cF9buKrLy zLwHwVJYB8uvD0FJojnGXUuGw8jHnkmvUd6jXlaYwIssp6g5TnjnGyn47 Y=; IronPort-PHdr: =?us-ascii?q?9a23=3ApVQu7h3reRcN5LJFsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQDkPhLfPuRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAAD7nsld/5tdJa1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAREBAQEBAQEBAQEBAYFrAwEBAQEBCwGBSlAFbFggBAsqCod?= =?us-ascii?q?lA4pqgl6YAIEugSQDVAkBAQEMAQEYCwoCAQGEQAKEFCQ1CA4CAwsBAQQBAQE?= =?us-ascii?q?CAQUEbYU3DIVRAQEBAQIBAQEQKAYBASwLAQsEAgEIEQQBAQEeECcLHQgCBAE?= =?us-ascii?q?NBQgagwGCRgMOIAECDKF6AoE4iGCCJ4J+AQEFhQ4YghcDBoE2AYt2HRiBQD+?= =?us-ascii?q?BEUaCTD6CYgEBgTcUGINAgiytJm4KgiWVX5l5jkeZdgIEAgQFAg4BAQWBUwE?= =?us-ascii?q?3gVhwFTuCbFARFJA2BwIag1CFFIU/dIEoiw4rgQQBgQ4BAQ?= X-IronPort-AV: E=Sophos;i="5.68,293,1569283200"; d="scan'208";a="649408519" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 17:52:31 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xABHqVwS002219 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 17:52:31 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 11:52:30 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 12:52:29 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 11 Nov 2019 11:52:29 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c2pY3SJOYDu0/UoT4gXDI7/+qToo7pRhlRyMT1DiGAJ405bbpOlSeiseYB8jZgEAOLnVGygtwDdLsTBnQ77yIXT/MDbuMclqUgLQoyiHS3rpW+4QkplV2VnDctmIlRj8RJj/G59+x6MWMFHd/C+tOG1vKWM1MAhwKDmySNgUKFSbRxfMIE5xxURRpmw/GiX0WTvMm55YQq01ZERjnCfxDKI5WJt0FGx7MTjyGAynD1YAO231QpkflTmQUVZytT0qOumo4ZCvh7NeNrB2SEmIVGmoC009oREqyG1WyygpZ85UStORIq/qrQt+2W3QYRMuwqM/Kv9WHtMmyDQh0gwcgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9sVVvxWsZll/xv0U8q96dj9PPbburLQXeTrnQ01D9oo=; b=Qz4U9MHqqG2aieuZ+K8YEFvKzRPGZsKwPKmHNj6LBRvgmbl6aC71EKreH6ef6s8viJNlDn0XoSPm+iSDrJ3IVYJ8rpsEOGj15hDSxg7GA5I8cNV0p101VLbdkS2mCkCYs3pJz4Ez8jITr+j7xt/hXhA/k7n/wTvfmSzK9RpJAtsHlDnWcA5ZVCTJtv0CUCV+UP0B6Dfjca555GL7KJi2ROuBSpPl9feTP7ipfF59b5lBCKPkzwCCtcBX/rzEPpmb7UIfj3RmgtXqTpn5OzhGxB7fiQcuXVKlcZvm2XtuRgxsqVEz3mHNQjij80UnF7N2BElBsej0Z3oj1h+CilAJtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9sVVvxWsZll/xv0U8q96dj9PPbburLQXeTrnQ01D9oo=; b=cvQcmGChX/rgvppVYTyWM0C/653w3stY+90Ej5D1LvBhhAEFI72h5kLuvmcwFrgnW+yOtaayKQRe4tinABL2DmqfvcL5xWMb37qBza77KXJOXS5EQZ6YIPGIUxYaPxNfcwKEJgx7X/CuFyO5WqGHJdRFWldYYBoFMaeYzpklROo= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3614.namprd11.prod.outlook.com (20.178.250.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Mon, 11 Nov 2019 17:52:28 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 17:52:28 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok , Joseph Salowey CC: EMU WG Thread-Topic: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Thread-Index: AdVKJoKyKr1G5+9hQuKLAEK5rLYqPgfSdnOQAABeFAAABkCJgP//55mA//bAJjCAEoqCAIADGZ8AgBnulgCABSSTAIAB0o2AgAAF5ACAAC3sAIAABveAgB1CFQCAAD1cgIAAJDQAgAEmKQD/9DAisIAXqxMAgAE9TG7/+vl+wA== Date: Mon, 11 Nov 2019 17:52:28 +0000 Message-ID: References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> <2FF842AE-0FA8-40EA-9A82-672E3068EBAB@deployingradius.com> In-Reply-To: <2FF842AE-0FA8-40EA-9A82-672E3068EBAB@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.50] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f601b441-7d9f-4bb8-e3c0-08d766cfeaf1 x-ms-traffictypediagnostic: MN2PR11MB3614: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(13464003)(189003)(199004)(110136005)(256004)(14454004)(316002)(74316002)(86362001)(14444005)(52536014)(478600001)(966005)(33656002)(102836004)(76176011)(11346002)(486006)(26005)(6506007)(446003)(2906002)(7736002)(305945005)(25786009)(186003)(7696005)(53546011)(8936002)(9686003)(5660300002)(6306002)(4326008)(6436002)(55016002)(6246003)(476003)(8676002)(66946007)(99286004)(81166006)(81156014)(229853002)(6116002)(76116006)(3846002)(66066001)(66476007)(66556008)(66446008)(71200400001)(71190400001)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3614; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s8cKKqJ9Rl0Jcxwbjq4qgo2TBGBB33h8iiq0bFRbhBA9rdzIHUZjG/wryYxkEaxnXcsvJplgzWc98WfHT8TasakBBvXWOvegfD/TyCn7xe0U707onofaU2TOzHU+Vt5+Odtl65I/LC5fK+mlrrrI8QIVUjfaw7ImiHnSQeEb5SlrAB1HpeLakd1SYANO9UeAdRkSCbaoWp3EHWw3+7oaIePts/P8ujDfNXjdbE9xzhqa0jdT5smu6JsrxHYOZ82pyRWB2JoiMGirFQAhbWDN4oVT7ow7gWJDkI0usfyzegHnPQUF2fj/xBquocKBCyvY1/j3QNOXg/9/aOGYwvZioPx3ItStysEyhWNZZV/D+fS4PRV8ixc1laEaOrdq7XcjXmcqsiqZpHlMGiEx+AiX+Q209zTYkw5emv/paGpWf350WQfbTt+R7a7C4dWegVDyF+LX3VErewj+hi1nfG+T2fpl4GvsMEzEZ+ES/BQdZx0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f601b441-7d9f-4bb8-e3c0-08d766cfeaf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 17:52:28.0349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UV7oNVOaE2Xi/G5wvO8RDFiQKWtHpA49wBU48KsDvl+wudQO/QVGNSpfcc0yB4RszHTFYEWaVFAxyOX+cXJ2Nw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3614 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Mon, 11 Nov 2019 17:52:36 -0000 > -----Original Message----- > From: Emu On Behalf Of Alan DeKok > Sent: 08 November 2019 12:43 > To: Joseph Salowey > Cc: EMU WG > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 >=20 > On Nov 7, 2019, at 11:08 PM, Joseph Salowey wrote: > > [Joe] How about > > "If an implementation supports an external PSK it MUST provide a way to > configure the realm so it can create an Anonymous NAI to send in the EAP- > Identity response. An EAP-TLS 1.3 implementation MUST NOT copy the PSK-= ID > into the EAP-Identity response. " >=20 > That's good. [ofriel] Is the primary reason they MUST NOT be copied because of encoding= differences? UTF-8 vs. TLS raw bytes? On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypte= d in cleartext in the ClientHello, what information leakage are we preventi= ng by not sending that same data in cleartext in the Identity Response? Note that TLS1.3 PSK IDs are different to TLS1.3 client certs: PSK IDs are = sent in cleartext in the ClientHello, client certs are sent encrypted insid= e the client's second flight. PSK IDs are not protected, client certs are (= assuming of course that the client can validate the server identity when th= e server sends its first flight to the client). >=20 > > If someone thinks there is a need to allow the PSK-ID to be copied then= the > phrase could be extended with " unless there is prior knowledge that this= will > have an acceptable impact to privacy and the use case supports Identity > responses that are not in the form of an NAI. >=20 > ... and the PSK identity is compatible with the requirements of the EAP= Identity > field, i.e. UTF-8. >=20 > > [Joe] The TLS 1.3 base spec teats certificate auth and external PSK aut= h as > mutually exclusive for a particular handshake. I do not think it restri= cts a > particular server from supporting both external PSK and certificate > authentication for separate connections. [ofriel] Right. >=20 > OK. I'm back to "how do you tell?" [ofriel] You can of course trivially tell the difference between an extern= PSK and a cert based auth - the ClientHellos are different. This is a different question to the difference between an extern PSK and a = resumption PSK. That is implementation specific and not defined in TLS1.3 >=20 > If the document suggests that plain PSK is OK, it would be very useful = to > describe the impact of that. What does an implementation do? How should > administrators tell PSK identities apart? If the EAP authenticator can't= control > the derivation of PSK identities for resumption, is it even possible to h= ave > manually provisioned PSKs? [ofriel] I agree some implementation advice would be good here. Should this= be in EAP, or should we push for a TLS1.3 errata? It's the same advice tha= t a standard TLS1.3 server implementor needs. OpenSSL for example defines i= ts own resumption format, and provides a callback hook to check for extern = PSKs, and it looks like OpenSSL lets the application check for an extern PS= K match first before checking its internal resumption cache: https://github= .com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093. But of= course that is TLS stack specific. We would need to document guidance olon= g the lines of checking for TLS stack behaviour. >=20 > Alan DeKok. >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Mon Nov 11 11:41:52 2019 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 8A291120A32 for ; Mon, 11 Nov 2019 11:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi5SJda3WqnA for ; Mon, 11 Nov 2019 11:41:45 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF55120219 for ; Mon, 11 Nov 2019 11:41:40 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id BC30E648; Mon, 11 Nov 2019 19:41:38 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 11 Nov 2019 14:41:37 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> <2FF842AE-0FA8-40EA-9A82-672E3068EBAB@deployingradius.com> To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Mon, 11 Nov 2019 19:41:50 -0000 On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) = wrote: >=20 > [ofriel] Is the primary reason they MUST NOT be copied because of = encoding differences? UTF-8 vs. TLS raw bytes? Yes. EAP Identities are UTF-8 encoded strings. Non-compliant = identities will likely result in the packet being dropped. > On the privacy aspect, as the TLS PSK ID is sent unprotected and = unencrypted in cleartext in the ClientHello, what information leakage = are we preventing by not sending that same data in cleartext in the = Identity Response? Not much. Except that if we send the data in the Identity, it MUST be = encoded in some format which is acceptable to EAP, RADIUS, etc. Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 = octets in length. While EAP can carry large identities, RADIUS cannot. = So we're left with a practical limitation of ~250 octets for the = identity field. At that point, it's best to recommend that the EAP Identity carry only = an anonymous NAI. That avoids the issue of PSK length and encoding = entirely. Further, it means that all uses of EAP-TLS have the same = recommendation: the Identity is an anonymous NAI. > This is a different question to the difference between an extern PSK = and a resumption PSK. That is implementation specific and not defined in = TLS1.3 i.e. "good luck". :( It's difficult for implementors to do the right thing in such a = situation. > [ofriel] I agree some implementation advice would be good here. Should = this be in EAP, or should we push for a TLS1.3 errata? It's the same = advice that a standard TLS1.3 server implementor needs. OpenSSL for = example defines its own resumption format, and provides a callback hook = to check for extern PSKs, and it looks like OpenSSL lets the application = check for an extern PSK match first before checking its internal = resumption cache: = https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.= c#L1093. But of course that is TLS stack specific. We would need to = document guidance olong the lines of checking for TLS stack behaviour. I think it's best to give guidance in this document. Alan DeKok. From nobody Mon Nov 11 14:38:43 2019 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 C8843120020 for ; Mon, 11 Nov 2019 14:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHqNOZlnFn-P for ; Mon, 11 Nov 2019 14:38:36 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A13120122 for ; Mon, 11 Nov 2019 14:38:36 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id z16so12705324qkg.7 for ; Mon, 11 Nov 2019 14:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/vr3B/pryLhh1mtz1WWGaY6IF+ekDqkiI0HopluPq5c=; b=aIX9yZaLE0FHPrBIyj1nu6asBONyjvkfRJXUOD34kgKCeneZ34cTYqgZHpRVcoNVHM iYLskpCPIW2NRHdqORtJxzz5hLzB4NP2v4FUtN6tPWG7oClZLgkta+kXHV1DTJKClV0J s7nnp+s0Iwd572GI1YEtsRwfq2ZTWg44F7TGW0TgDEr+5+72yP1EmibsTL3VHlDAKj7A dG3hxsIsDMAwd/q7iXfWuup3XtAsJT7fAah7aZfydYb+NS6HOqXBoiviHayT1JK9nyXT 18PT16Xp5clgzyfebvHuxz9hiSCe9TITCJGxwtBTqZmcaUawphKDkBa/Mte0EJROhzTO 8rzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/vr3B/pryLhh1mtz1WWGaY6IF+ekDqkiI0HopluPq5c=; b=OQVWeI8KOUaWYyKJuM8GOVbXeciALcmV6ecAUSbLLQHMjomih0YLsE9dDRkl7aj8Yi x1MCwqn2OkKMjrHdygW+KNX8rfYzlApMifsTIpuwThA1r5kpybP/N6Jv5QAkCpeHoA5r q0Bt33/4cQYjcwVg/weJxSvFhwUOc1d9AKJtDA0q1zTSCddrJv3Oe84txGKnx8GiM3kS WqAtfQK/fVLOyduZAxXlHxLGSvWDgPH9vFy6tz+yDbQ3VM+NduxVU9l8HPrcgoBiyqpW pFv1jmOfo/CSBYdR8UiAbO+fvb7Weappf55T817ILPwsxyCtNaCUf+NDJ5KbTNeC5iU+ M1Jw== X-Gm-Message-State: APjAAAVPgoRWgh5ic9DOGiiGujWeOsFxJtrvUcZENcwxfZUq5JjNafNV pku/yqEx1EQBMJ4yQOIZ2tqaUhtaIgII43+nxiRkQDro X-Google-Smtp-Source: APXvYqy8ijmMfaQ1bejDs/AA3oZHwAk9hPH3qR1WHcy8V4Op5WII018HgwvWzo1xoyGZK9qKmFqik7ht5kLX7Tnub+0= X-Received: by 2002:ae9:e201:: with SMTP id c1mr12854889qkc.416.1573511915279; Mon, 11 Nov 2019 14:38:35 -0800 (PST) MIME-Version: 1.0 References: <7828_1564869242_5D46027A_7828_348_1_02e001d54a45$e92ae900$bb80bb00$@augustcellars.com> <20b118932a4843b6b88e605799fafea8@aalto.fi> <211AD83C-D111-4EEB-AAF0-D9B5E521F4CF@deployingradius.com> <8F355C6F-DF1E-4E03-B75E-0F1D2508B9D4@ericsson.com> <246280B8-6E5C-484B-95BD-9C940C98C507@deployingradius.com> <17E08795-4E4E-4507-8384-836020966BCF@deployingradius.com> <634C375D-FBF3-4297-A5C0-E68C903CA34A@ericsson.com> <26738.1570791861@dooku.sandelman.ca> <9501.1570802988@dooku.sandelman.ca> <20826A11-1881-40F9-8C54-82BB90820851@deployingradius.com> <0D21C6F3-DCF7-41FA-BEFB-9408575524A8@deployingradius.com> <2FF842AE-0FA8-40EA-9A82-672E3068EBAB@deployingradius.com> In-Reply-To: From: Joseph Salowey Date: Mon, 11 Nov 2019 14:38:23 -0800 Message-ID: To: Alan DeKok Cc: "Owen Friel (ofriel)" , EMU WG Content-Type: multipart/alternative; boundary="000000000000c2a89d059719cade" Archived-At: Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 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: Mon, 11 Nov 2019 22:38:41 -0000 --000000000000c2a89d059719cade Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok wrote: > On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) > wrote: > > > > [ofriel] Is the primary reason they MUST NOT be copied because of > encoding differences? UTF-8 vs. TLS raw bytes? > > Yes. EAP Identities are UTF-8 encoded strings. Non-compliant > identities will likely result in the packet being dropped. > > > On the privacy aspect, as the TLS PSK ID is sent unprotected and > unencrypted in cleartext in the ClientHello, what information leakage are > we preventing by not sending that same data in cleartext in the Identity > Response? > > Not much. Except that if we send the data in the Identity, it MUST be > encoded in some format which is acceptable to EAP, RADIUS, etc. > > Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets > in length. While EAP can carry large identities, RADIUS cannot. So we're > left with a practical limitation of ~250 octets for the identity field. > > At that point, it's best to recommend that the EAP Identity carry only > an anonymous NAI. That avoids the issue of PSK length and encoding > entirely. Further, it means that all uses of EAP-TLS have the same > recommendation: the Identity is an anonymous NAI. > > [Joe] I agree that its best to only include the anonymous NAI. Including more information may cause a problem if the PSK works changes in the future or if you are copying the original NAI into subsequent transactions. > > This is a different question to the difference between an extern PSK and > a resumption PSK. That is implementation specific and not defined in TLS1.3 > > i.e. "good luck". :( > > It's difficult for implementors to do the right thing in such a > situation. > > > [ofriel] I agree some implementation advice would be good here. Should > this be in EAP, or should we push for a TLS1.3 errata? It's the same advice > that a standard TLS1.3 server implementor needs. OpenSSL for example > defines its own resumption format, and provides a callback hook to check > for extern PSKs, and it looks like OpenSSL lets the application check for > an extern PSK match first before checking its internal resumption cache: > https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093. > But of course that is TLS stack specific. We would need to document > guidance olong the lines of checking for TLS stack behaviour. > > I think it's best to give guidance in this document. > > [Joe] If its needed then I also think we should include it in the EAP-TLS document. It wouldn't be bad to file an errata on TLS 1.3, but I think this is more of a corner case for them. > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --000000000000c2a89d059719cade Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 11, 2019 at 11:41 AM Alan= DeKok <aland@deployingradi= us.com> wrote:
On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) <ofriel@cisco.com> wrote:
>
> [ofriel]=C2=A0 Is the primary reason they MUST NOT be copied because o= f encoding differences? UTF-8 vs. TLS raw bytes?

=C2=A0 Yes.=C2=A0 EAP Identities are UTF-8 encoded strings.=C2=A0 Non-compl= iant identities will likely result in the packet being dropped.

> On the privacy aspect, as the TLS PSK ID is sent unprotected and unenc= rypted in cleartext in the ClientHello, what information leakage are we pre= venting by not sending that same data in cleartext in the Identity Response= ?

=C2=A0 Not much.=C2=A0 Except that if we send the data in the Identity, it = MUST be encoded in some format which is acceptable to EAP, RADIUS, etc.

=C2=A0 Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 oc= tets in length.=C2=A0 While EAP can carry large identities, RADIUS cannot.= =C2=A0 So we're left with a practical limitation of ~250 octets for the= identity field.

=C2=A0 At that point, it's best to recommend that the EAP Identity carr= y only an anonymous NAI.=C2=A0 That avoids the issue of PSK length and enco= ding entirely.=C2=A0 Further, it means that all uses of EAP-TLS have the sa= me recommendation: the Identity is an anonymous NAI.


[Joe] I agree that its best to only in= clude the anonymous NAI.=C2=A0 Including more information may cause a probl= em if the PSK works changes in the future or if you are copying the origina= l NAI into subsequent transactions.=C2=A0=C2=A0
=C2=A0
> This is a different question to the difference between an extern PSK a= nd a resumption PSK. That is implementation specific and not defined in TLS= 1.3

=C2=A0 i.e. "good luck".=C2=A0 :(

=C2=A0 It's difficult for implementors to do the right thing in such a = situation.

> [ofriel] I agree some implementation advice would be good here. Should= this be in EAP, or should we push for a TLS1.3 errata? It's the same a= dvice that a standard TLS1.3 server implementor needs. OpenSSL for example = defines its own resumption format, and provides a callback hook to check fo= r extern PSKs, and it looks like OpenSSL lets the application check for an = extern PSK match first before checking its internal resumption cache: https://github.com/opens= sl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093. But of cours= e that is TLS stack specific. We would need to document guidance olong the = lines of checking for TLS stack behaviour.

=C2=A0 I think it's best to give guidance in this document.


[Joe] If its=C2=A0needed then I also t= hink we should include it in the EAP-TLS document.=C2=A0 It wouldn't be= bad to file an errata on TLS 1.3, but I think this is more of a corner cas= e for them.=C2=A0=C2=A0
=C2=A0
=C2=A0 Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--000000000000c2a89d059719cade-- From nobody Mon Nov 11 15:15:45 2019 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 9102C1200E3 for ; Mon, 11 Nov 2019 15:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WLbSqQ70; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=H/9zFavb 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 2iuvHUNw_Q5r for ; Mon, 11 Nov 2019 15:15:41 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDBA1200D8 for ; Mon, 11 Nov 2019 15:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3190; q=dns/txt; s=iport; t=1573514140; x=1574723740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NaYt9YxhRuZ6hIvnOJ9VyosNHquTkDSlYREl8WtoEMQ=; b=WLbSqQ702B6LrCQ5pQDI6eIKZbUGzNS+ry6m9UBaGv9qnnOtif5LJou6 En23frzQf76PIFm15hqfQXgJapysXPFpuD9xW/2vkzrji3xn1QO7smdle LVbzMyZ0KU69B9liBwSTApxzGVPxbgkjhHbfub1tYdQCmxwteZ21GF0EP I=; IronPort-PHdr: =?us-ascii?q?9a23=3ACjEPTBFXcKl6VTAsvZHP7p1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAAZ68ld/4QNJK1dCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBbAMBAQEBCwGBSlAFgUQgBAsqCoQfg0YDimq?= =?us-ascii?q?CXpgAgS6BJANUCQEBAQwBAS0CAQGEQAIXg30kNgcOAgMLAQEEAQEBAgEFBG2?= =?us-ascii?q?FNwyFUQEBAQEDEhERDAEBNwELBAIBCBEEAQEDAiYCAgIwFQgIAgQBDQUIGoV?= =?us-ascii?q?HAy4BAqJFAoE4iGB1gTKBO4FDAQEFhQ0YgX0aCYEOKAGLdR4YgUA/gRFGgh4?= =?us-ascii?q?uPoQbFBiDDjKCLJAMnggKgiWMO4kkmXmOR5l2AgQCBAUCDgEBBYFZByuBWHA?= =?us-ascii?q?VgydQERSQNoNzilN0gSiLCiuBBAGBDgEB?= X-IronPort-AV: E=Sophos;i="5.68,294,1569283200"; d="scan'208";a="370618108" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 23:15:39 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xABNFdhx022497 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 23:15:39 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 17:15:39 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 17:15:38 -0600 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 11 Nov 2019 18:15:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KM1wbwBJYvazmoke8+CREHgl/Nmjna/mo99X8ajMENEvQyJyLqYbcwxHtmcu3rNB6gA6fqghFkiviS1zXknrHo2IeVqyvyVovgfvxhslCRoLe824rxAKHSARo1rLmVUBf4Dfm+i0mxxV731YN81hBILQzoQ7ZkXq8OJey46by9AHS+0NtJnzzDHeazYGtYOxe84j5gKfElU3JzJctxmIww5OHblxN17gv4w75RyLOapXCYfPJOMemM6SaoM7pPyhn1pPyxAGVfSseFlmKr9gnppPiIHx2lXJQOWfhmED2BKy+ma/0lq2kf2nj/adJ40Dlz84CkR+h/4laUJXx2sWfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NaYt9YxhRuZ6hIvnOJ9VyosNHquTkDSlYREl8WtoEMQ=; b=LvyXPhpMoH3VNBbAU4rIv3rXD7Pc7uGaqtCoUr3gikNPB5MrW5zj5WR9huLcKxvT0zwHkuIp4f2TFiKX7tWNHmXfyGcRjSxFCEjLipIvxDjlXx5S1F5dIAJj8u2kANbuJgJZuBWTK1qyILhilDzzGsWx5nBFHys39z4siZYKilkQctRrR0EQP3xG41A8T9A3ISow1G4JnaUzrRu9lJ0muLE+i4EpjX5OPZe8Inr/gKVXhkas7Gp3bzwF2UhSgjCw8xOYCoibMbBIYdDKaT58wn0J2a9gWZF6gU/0cfSTXUTtozQDBcjI03ACKXJBgaAGnU9G2+wvRgV6pChAsWNZ6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NaYt9YxhRuZ6hIvnOJ9VyosNHquTkDSlYREl8WtoEMQ=; b=H/9zFavbcrtsSXKF+5iMuiiJMP1E7DMQ1Vw5gAIz10Hxk4y+SfXt54wA+ZzB70xsjvlh8kf7fHItK1gVqWngOM2ds4e7R0Q86xPUEI6vPVQyF5Lx6RzYT/GoU+BLd10nMC8Szvbb61VDNknY9rP87ttemgCOWI9dtmEPjANOnFU= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3709.namprd11.prod.outlook.com (20.178.252.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Mon, 11 Nov 2019 23:15:37 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 23:15:37 +0000 From: "Owen Friel (ofriel)" To: Jan-Frederik Rieckers , Alan DeKok , Russ Housley CC: "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPeAysQlGUpTU6o3aUNy73n/aeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAOEToA== Date: Mon, 11 Nov 2019 23:15:36 +0000 Message-ID: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> In-Reply-To: <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8a90c81-df02-401c-1ee0-08d766fd0f90 x-ms-traffictypediagnostic: MN2PR11MB3709: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(376002)(39860400002)(346002)(13464003)(189003)(199004)(99286004)(14444005)(256004)(25786009)(66066001)(8936002)(305945005)(14454004)(74316002)(7736002)(478600001)(71200400001)(71190400001)(3846002)(6116002)(5660300002)(86362001)(33656002)(52536014)(55016002)(6436002)(9686003)(7696005)(26005)(186003)(476003)(229853002)(486006)(76176011)(76116006)(66556008)(66476007)(66946007)(8676002)(81156014)(66446008)(81166006)(64756008)(4326008)(316002)(6506007)(11346002)(446003)(102836004)(53546011)(2906002)(6246003)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3709; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UKq8AYjUHpSpSJ+KZA1R/Rg1RYKoivoAIo4JIq/r/yMLPSowr9iSsnX/xftrPxChtp5ZPxzoakUmxlRZk2fYQ+wNfZL/UszQGjnJ2yo98aJFZWYN08rt7A4hV3sCeIMS9azY6maPqaS4dDE/VrZNHRurn/1F0evjf0XlYZx1wy2AZE9yBpZaqLIPe463RmBf0cD+/hbvgu3yPjBJKhaNbS3B14aQtWKeW/L0UnRG4xrhnvh4vMlGKR5LlRKKFvFGAiwRX93WpDL1IwEthi4z8KeeACDU9Z/HjfkXmPDwPboc4Yw0vCyjcsrQQSRH376iMAht5ukLT+ljoZI1C7dBQT4/VHJ1sa5vLmXVmi+qjL71bnbovA/pEJRFu5Rfb3eUDTJ/7kTl9ddXJn5Jw+YlhwD0b/0sdzQR/p0uWMlV582R3EQ0tJiKODvl+OOhhq0u x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a8a90c81-df02-401c-1ee0-08d766fd0f90 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 23:15:36.9667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1x/QX980GGHR4MYCx3hG30AtQBcPbN6FYMvE0KADjz0g62bki+Zvn+6uZRRj8hZlLA1uHtAuxwn5YymA9p6tcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3709 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Mon, 11 Nov 2019 23:15:43 -0000 VGhpcyBpcyBhbHNvIHJlbGF0ZWQgdG8gb25nb2luZyBhbmltYSBkaXNjdXNzaW9ucyBhYm91dCBS RkMgODM2NiwgYW5kIGhvdyBpdCBjYW4gYm9vdHN0cmFwIHRydXN0IHdoZW4gdGhlIHBpbm5lZCBk b21haW4gY2VydCBpcyBhIHB1YmxpYyBQS0kgQ0EsIGFuZCBub3QgYSBwcml2YXRlIENBLCBhbmQg aGVuY2UgYWRkaXRpb25hbCBkb21haW4gKG9yIHJlYWxtIG9yIEZRRE4pIGluZm8gaXMgYWxzbyBu ZWVkZWQgaW4gb3JkZXIgZm9yIHRoZSBwZWVyIHRvIHZlcmlmeSB0aGUgaWRlbnRpdHkgb2YgdGhl IHNlcnZlci4NCg0KSXRzIGFsc28gcmVsZXZhbnQgZm9yIG9uZ29pbmcgV2ktRmkgQWxsaWFuY2Ug RFBQIGRpc2N1c3Npb25zIGFib3V0IGJvb3RzdHJhcHBpbmcgYSBzdXBwbGljYW50IG9udG8gYW4g ODAyLjFYIG5ldHdvcmsgLSBhZnRlciBhIHN1cHBsaWNhbnQgY29tcGxldGVzIERQUCBhbmQgZ2V0 cyBwcm92aXNpb25lZCB3aXRoIGEgdHJ1c3QgYW5jaG9yIC0gd2hhdCBpZiB0aGF0IHRydXN0IGFu Y2hvciBpcyBhIHB1YmxpYyBQS0k/IEl04oCZcyB0aGUgc2FtZSBwcm9ibGVtLg0KDQpPbmUgZGVw bG95bWVudCBjb25zaWRlcmF0aW9uIGlzIGlmIGFuIG9wZXJhdG9yIHdhbnRzIHRvIHVzZSBhIHB1 YmxpYyBQS0kgKGUuZy4gTGV0cyBFbmNyeXB0KSBmb3IgdGhlaXIgQUFBIGNlcnRzLCB0aGVuIGl0 IGNvdWxkIGJlIHllYXJzLCBpZiBldmVyLCBiZWZvcmUgdGhlc2UgZXh0ZW5zaW9ucyBjb3VsZCBi ZSBzdXBwb3J0ZWQgKGFzIEFsYW4gYWxsdWRlcyB0byksIHNvIGl0IHdvdWxkIGFsc28gYmUgZ29v ZCB0byBkZWZpbmUgaG93IHRoaXMgY291bGQgd29yayB3aXRoIHN0YW5kYXJkIFJGQyA2MTI1IERO Uy1JRHMgLyBSRkMgNTI4MCBkTlNOYW1lcy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBFbXUgPGVtdS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSmFuLUZy ZWRlcmlrIFJpZWNrZXJzDQo+IFNlbnQ6IDExIE5vdmVtYmVyIDIwMTkgMDk6NDINCj4gVG86IEFs YW4gRGVLb2sgPGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20+OyBSdXNzIEhvdXNsZXkNCj4gPGhv dXNsZXlAdmlnaWxzZWMuY29tPg0KPiBDYzogZW11QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb RW11XSBJZGVhOiBOZXcgWDUwOSBFeHRlbnNpb24gZm9yIHNlY3VyaW5nIEVBUC1UTFMNCj4gDQo+ IEhpLA0KPiBUaGFuayB5b3UgZm9yIHlvdXIgZmVlZGJhY2suDQo+IA0KPiBJIHdhcyB1bmF3YXJl IG9mIFJGQyA3NTg1LiBJIGhhZCBhIGJyaWVmIGxvb2sgb24gaXQgYW5kIGl0IHNlZW1zIHRoYXQg dGhlDQo+IGNlcnRpZmljYXRlIHBhcnQgY291bGQgYmUgdXNlZCBmb3IgdGhlIGdvYWwgSSB0cnkg dG8gYWNoaWV2ZS4NCj4gDQo+IEknbSBub3QgcXVpdGUgc3VyZSBpZiB0aGUgbmFpUmVhbG0gc2hv dWxkIGJlIHVzZWQgZm9yIHZhbGlkYXRpb24gb24gc3VwcGxpY2FudHMNCj4gZm9yIEVBUC1UTFMu IEkgd291bGQgYXNzdW1lIGl0IHdvdWxkIG5vdCBiZSBhIHNlY3VyaXR5IGlzc3VlLCBidXQgSSBk b24ndCBoYXZlDQo+IGVub3VnaCBleHBlcmllbmNlIHRvIGJlIHN1cmUgYWJvdXQgdGhhdC4NCj4g DQo+IFRoZSBtYWluIHJlYXNvbiB3aHkgSSBzdWJtaXR0ZWQgdGhpcyBkcmFmdCBpcyBteSBleHBl cmllbmNlIGZyb20gdGhlDQo+IGRlcGxveW1lbnQgb2YgZWR1cm9hbSBhdCBVbml2ZXJzaXR5IEJy ZW1lbi4NCj4gV2l0aCBleHBpcnkgb2YgdGhlIHVzZWQgcm9vdCBDQSBhbmQgdGhlIG5lZWRlZCBt aWdyYXRpb24sIHdlIGhhdmUgZm9yY2VkIGFsbA0KPiBvdXIgdXNlcnMgdG8gdXNlIG9uZSBzcGVj aWZpYyBvdXRlciBJZGVudGl0eSwgdG8gYmUgc3VyZSB0aGUgdXNlcnMgY29uZmlndXJlIHRoZWly DQo+IGRldmljZXMgd2l0aCB0aGUgZWR1cm9hbSBDb25maWd1cmF0aW9uIEFzc2lzdGFudCBUb29s IChDQVQsIGNhdC5lZHVyb2FtLm9yZykNCj4gaW5zdGVhZCBvZiBhIG1hbnVhbCBjb25maWd1cmF0 aW9uLCBiZWNhdXNlIGluIG91ciBleHBlcmllbmNlIG1hbnVhbCBjb25maWd1cmVkDQo+IGRldmlj ZXMgYWxtb3N0IGFsd2F5cyBsYWNrZWQgY29uZmlndXJhdGlvbiBmb3IgY2VydGlmaWNhdGUgY2hl Y2tpbmcuDQo+IEJ1dCBJIGp1c3QgaGF2ZSBleHBlcmllbmNlIGluIGxvY2FsIGRlcGxveW1lbnQs IHRoZSBmZWRlcmF0aW9uIGNvbm5lY3Rpb25zIGFyZQ0KPiBkb25lIGF0IGhpZ2hlciBsZXZlbHMg KGNvdW50cnkgcmVzZWFyY2ggbmV0d29ya3MpLCBJIGRvbid0IGhhdmUgYW4gaW5zaWdodCB0aGVy ZS4NCj4gDQo+IEdyZWV0aW5ncywNCj4gSmFuLUZyZWRlcmlrIFJpZWNrZXJzDQoNCg== From nobody Mon Nov 11 17:07:42 2019 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 7562A120072 for ; Mon, 11 Nov 2019 17:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSGqZdlSXH8v for ; Mon, 11 Nov 2019 17:07:38 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFF11200FE for ; Mon, 11 Nov 2019 17:07:21 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id A91C78F8; Tue, 12 Nov 2019 01:07:18 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 11 Nov 2019 20:07:16 -0500 Cc: Jan-Frederik Rieckers , Russ Housley , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6632D477-CB45-4A41-8B17-74C38D1141FE@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 01:07:40 -0000 On Nov 11, 2019, at 6:15 PM, Owen Friel (ofriel) = wrote: >=20 > This is also related to ongoing anima discussions about RFC 8366, and = how it can bootstrap trust when the pinned domain cert is a public PKI = CA, and not a private CA, and hence additional domain (or realm or FQDN) = info is also needed in order for the peer to verify the identity of the = server. >=20 > Its also relevant for ongoing Wi-Fi Alliance DPP discussions about = bootstrapping a supplicant onto an 802.1X network - after a supplicant = completes DPP and gets provisioned with a trust anchor - what if that = trust anchor is a public PKI? It=E2=80=99s the same problem. >=20 > One deployment consideration is if an operator wants to use a public = PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if = ever, before these extensions could be supported (as Alan alludes to), = so it would also be good to define how this could work with standard RFC = 6125 DNS-IDs / RFC 5280 dNSNames. That sounds reasonable. Certificates for 802.1X authentication already use DNS names. It's = not wide-spread, but it's not rare. There's no *meaning* to these = names, as nothing checks them. It would be useful to suggest how a supplicant can use these fields to = further verify a server certificate. And for servers, what these fields = should contain. Alan DeKok. From nobody Mon Nov 11 23:54:10 2019 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 0E5C512013A for ; Mon, 11 Nov 2019 23:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de 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 otFRFJ0qoYxW for ; Mon, 11 Nov 2019 23:54:05 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC291200A1 for ; Mon, 11 Nov 2019 23:53:55 -0800 (PST) Received: from [192.168.42.20] (luisenthal-079.wohnheim.uni-bremen.de [134.102.9.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47C0PF6lwfzyqB for ; Tue, 12 Nov 2019 08:53:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1573545233; bh=0yHpobYPcSycF6oaf+5RZ/5G3O0eV1lQvX9FOwsSJwg=; h=References:From:To:Date:In-Reply-To; b=Twf3g67B/Inze0BQxa+/vUHgjtxpyAw8w+MVc978gbQ29Lzm/mTzXT2LrZpqGlAj/ sYKKruPdj9KaJnXx6uc78nqNJqXHz0oeFRFRSA83fadpHfpG4PqkUPYjsU9eHhrLUe dvUncW3zzoJD4+29hXSzf9/kPm4kPKEp3MntZPigZj3zgMFp17OOXWlVtx0MBxGaku SPs31SaZSFWqBeJLyiRkJzIn9SDPrHXQoqOC/WcLOJ0itQZd0XZReGG/gq4yRjfZXp uOwLwZRT0m4aCTRoQZnWdmlhtJ3hecVYWHU3+NjYp97hrQUSb72PTwd+ZRRhAov04U 1WT30zJQm2qlA== References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> From: Jan-Frederik Rieckers Openpgp: preference=signencrypt To: "emu@ietf.org" Message-ID: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> Date: Tue, 12 Nov 2019 08:53:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KxAlFblfXQaPdnFOKF2O3uSvnAcfCdomu" Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 07:54:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KxAlFblfXQaPdnFOKF2O3uSvnAcfCdomu Content-Type: multipart/mixed; boundary="YGnwdO8GV7LOoZNwfW85ggYhBB43Kgr56"; protected-headers="v1" From: Jan-Frederik Rieckers To: "emu@ietf.org" Message-ID: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> In-Reply-To: --YGnwdO8GV7LOoZNwfW85ggYhBB43Kgr56 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12.11.19 00:15, Owen Friel (ofriel) wrote: > One deployment consideration is if an operator wants to use a public PK= I (e.g. Lets Encrypt) for their AAA certs, then it could be years, if eve= r, before these extensions could be supported (as Alan alludes to), so it= would also be good to define how this could work with standard RFC 6125 = DNS-IDs / RFC 5280 dNSNames. I had a lot of thoughts about this topic. I am experimenting with certificates in EAP-TLS contexts and experienced the problems with getting a certificate with specific extension properties from our public PKI. (In my case a test certificate with a critical MustStaple extension) The Problem with dNSNames is that they are also used in other contexts (mainly HTTPS). There would be the possibility to define a specific prefix to bind it to a Realm without having the certificate being valid for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm uni-bremen.de) but I don't see the advantage in that. This will probably don't really lead to a change in the supplicants implementations. My deployment experience shows, that the certificate check is the main security problem in WPA2-Enterprise networks. I have seen instructions for installing WPA2-Enterprise networks where they have explicitly suggested switching off the certificate check, probably because it was too complicated for the users and would lead to people complaining at the IT department about the complicated setup. A setup of WPA2-Enterprise can be secure if all devices are part of a centralized Device Management, but especially in eduroam this isn't possible. We have a lot of people who don't really care about security. Jan-Frederik Rieckers --YGnwdO8GV7LOoZNwfW85ggYhBB43Kgr56-- --KxAlFblfXQaPdnFOKF2O3uSvnAcfCdomu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO9n8U/6Yuq3qYHN1UHR7NOiKGm0FAl3KZQoACgkQUHR7NOiK Gm1Qsw//eNlf7I1qOpXayakqX35KEoPV97f0/qEfXBI5c1cCiVFvFfd6wME2y2Cc OEiCikC/eXZ7ahkWYugSspzK4OYmKxKiJQISZVXDV5WTFYij5Ua21ehq9d3HN0UE VsZJ9v+jM3bxRrYevdViC31EsjDt9GRqIOvOHJ7IKcMTlsOYeaogyNPI6pZ36Abe zdqKarCEOP/JRqIG0soV5QYjrv9BSZmwa28n1+2hbFx+7TR75ppfVd8+YWAcmRUf v0AjbUdKM/A31xX0ToWYs87JFKWslSzRY3LObDDBlnD0rUEVM1eUIeDOlzcgEPyD CMWuJcs9myHuqUNlW2sEXm0tU93/xFlImmpd4CvheAD8pZoxMBDU+qcwKLqxnjRI SC6cOuJFN8tTnPK8RlfN8EtXFv7h4NWfsgE/RlqEUGy9BHqrLHol9Pwe7GbpKI8V hN/vGLGeiUy320ULTPIeLfUQG19NO/aOlVoZMTUJQKy8KJ+mlZERKGSlFpCXGcWa werMNlp1v0oehI60aS+O8sEpJalBvXpzsQSTW0jENlVkD8BU3afYdTFRO3z24umF /Mxm2Pkh7xuSvuq1orzd7U1t41TUCuPYYRq8zMV5nuOleyoANdSMwirAE3w5QlMS +GKkoeU491zFGNJc2LnCuAcccZFKA8itc3nNuxT1b09G0fi/HT8= =fJ/7 -----END PGP SIGNATURE----- --KxAlFblfXQaPdnFOKF2O3uSvnAcfCdomu-- From nobody Tue Nov 12 01:22:34 2019 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 6A2041200A3 for ; Tue, 12 Nov 2019 01:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD-zbecnUFrN for ; Tue, 12 Nov 2019 01:22:30 -0800 (PST) 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 81954120046 for ; Tue, 12 Nov 2019 01:22:30 -0800 (PST) Received: from [192.168.44.20] (unknown [209.171.88.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 0C60F3897B for ; Tue, 12 Nov 2019 04:19:13 -0500 (EST) To: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> From: Michael Richardson Openpgp: preference=signencrypt Autocrypt: addr=mcr@sandelman.ca; keydata= mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QSdv84oNe1 h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2IoHCU6ezhQz2TwJO7 l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF8lIIAYEbQ4YyYyjk5DS30x59 kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDDsMmTJWPkszvQoCjCbrvgDAuoRtL5su2V IQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVlL71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj 1N/2x7mGk35Zrvz0WHjZLcFJYJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQ gRI4pNs24NoxLXl5v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh0 5I5okPcENk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvUmQjFqXgsg4KhIWQb QBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSGTEH03oJIeYbdwlOCe5blA6h4 FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQMxgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU 8VTgenm4JpBdJQx7/7syvIaQilhN2fF25CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnp mspJTGptxFxH/GM/kW40iB4tUjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullzt u37BDVj/SmgbGhvTUXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollE Zcw9VIojPKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kBjQRdxGjv AQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5KhdcxjTlo6htNjRUuUy1Ld 0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOplKgMSoGpGamLSDzRs3SAJu4GF iHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zXfSmZqZwNp/6xosLCl3TKvFWX6421Vb/L WAOOAz/xSyS0GCUs/grBUfzu95+TTskRk7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOq e7/5y4bQkILGGMIux878DhAED865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD 7r5QL6iU57zI/B5U03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhD VmrDKLWXRm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUCXcRo7wIb DAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyytePFmS9NAwdT8A6mA4s +WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8WJVn0zH7LVCKMWo/tHE2rWyi Q1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJprKZAtiDJ897vv1jP09fWLEBhaDsHqLhg ckQpIoee0Id4FXGt7wxDsPwa64SUUCTYdt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7 UXVMQlEKG7E31G1XQMk6sFATF1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8 SFA6Uc+Bjr0i1jdnxS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot 8lIsHGAJQHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw= Message-ID: <03a039fc-4f88-13ca-8492-29e6738d550d@sandelman.ca> Date: Tue, 12 Nov 2019 17:19:39 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zuc4BhDanUaquDWuL4nvBFhR1LEROyleA" Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 09:22:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Zuc4BhDanUaquDWuL4nvBFhR1LEROyleA Content-Type: multipart/mixed; boundary="sp30TnA9IeubDl8HjAzv67MXlgIXZHICa"; protected-headers="v1" From: Michael Richardson To: emu@ietf.org Message-ID: <03a039fc-4f88-13ca-8492-29e6738d550d@sandelman.ca> Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> In-Reply-To: --sp30TnA9IeubDl8HjAzv67MXlgIXZHICa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote: > This is also related to ongoing anima discussions about RFC 8366, and h= ow it can bootstrap trust when the pinned domain cert is a public PKI CA,= and not a private CA, and hence additional domain (or realm or FQDN) inf= o is also needed in order for the peer to verify the identity of the serv= er. While I'm familiar with this conversation, which I'm right now inspired to call the the "Maria" problem ("How do solve a problem like Maria.=C2=A0 How do you a cloud certificate= and pin it down?") I don't really understand what it has to do with the problem of an EAP client, **which is not doing initial onboarding**, to validate a certificate that it has received as part of EAP-TLS*. > Its also relevant for ongoing Wi-Fi Alliance DPP discussions about boot= strapping a supplicant onto an 802.1X network - after a supplicant comple= tes DPP and gets provisioned with a trust anchor - what if that trust anc= hor is a public PKI? It=E2=80=99s the same problem. I agree that this is the Maria problem, because the client has to pin *a* CA and a SubjectDN (specifically a dnsName SubjectAltName), and you want to allow the server to change public CAs. >> -----Original Message----- >> From: Emu On Behalf Of Jan-Frederik Rieckers >> >> Thank you for your feedback. >> >> I was unaware of RFC 7585. I had a brief look on it and it seems that = the >> certificate part could be used for the goal I try to achieve. >> >> I'm not quite sure if the naiRealm should be used for validation on su= pplicants >> for EAP-TLS. I would assume it would not be a security issue, but I do= n't have >> enough experience to be sure about that. >> >> The main reason why I submitted this draft is my experience from the >> deployment of eduroam at University Bremen. >> With expiry of the used root CA and the needed migration, we have forc= ed all >> our users to use one specific outer Identity, to be sure the users con= figure their >> devices with the eduroam Configuration Assistant Tool (CAT, cat.eduroa= m.org) >> instead of a manual configuration, because in our experience manual co= nfigured >> devices almost always lacked configuration for certificate checking. >> But I just have experience in local deployment, the federation connect= ions are >> done at higher levels (country research networks), I don't have an ins= ight there. I skimmed your document before and I didn't understand it based upon my quick read. Your text here helps me a bit. In eduroam, the supplicant sees the TLSServerCertificate of the local institution's Authentication Server, correct? Is it not the case that for this to be validated that there needs to be a path to the eduroam's root certificate, which the client would have pinned? You need to set the NAI correctly, because we have essentially an SNI-like issue, in that the Authentication Server needs to answer with it's eduroam certificate for eduroam clients, and it might use a different certificate for other clients? As I understand it, your ran into an issue because the root certificate expired, and clients had pinned it, but they could find a new certificate in DNS? --sp30TnA9IeubDl8HjAzv67MXlgIXZHICa-- --Zuc4BhDanUaquDWuL4nvBFhR1LEROyleA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAl3KeSsACgkQcAKuwszY gEOsHgwAnYiGJxtzVTdm258h3VHdANMZ6WEaaTqAhqjH8IFqoJfN93ppUenj7DRK NKZWo4C+6/6vv961U44SlGrQtRPE3rkEBJqcoM7SXmC65lWwoy6DkOE74fuOKuUy lQvi8B9WmHHnHPrGaYCCBYpq/ugoOq2B1YJz9KVJgsd/onMuftcq03T5Lsey6yCr Lm8UJP29CW6DhQvJXfsB0dKnb4l423LJn6yDczemagt4Ix1HfXul7DT5VLvzRZqC eFu0rG3ljRYviePZztKghvpi1VippQmxlQ+/qcGzkU4EwkwblGn88oyXDZCNaR7p UricLzub/asodMhLxBw7am/Swe/CvlTInDoEgsWNHg6uoXfsvohZJ4m2a/ADZ+OY vrv57uUOkm74iESZzjMpMn6Q447gP6SPg3OsMr8eBp8vKRjdyak7UeQT4BLl7orY xlHlUnCNXcVBwQe81nD0rqKKKR7r4lwdoPwOi4c4R63ERzZXl6Yj+6495uOoLoPn pvCk45fv =0qSz -----END PGP SIGNATURE----- --Zuc4BhDanUaquDWuL4nvBFhR1LEROyleA-- From nobody Tue Nov 12 01:28:57 2019 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 E9A6D12024E for ; Tue, 12 Nov 2019 01:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpgSsENZYCr9 for ; Tue, 12 Nov 2019 01:28:54 -0800 (PST) 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 D76F1120118 for ; Tue, 12 Nov 2019 01:28:53 -0800 (PST) Received: from [192.168.44.20] (unknown [209.171.88.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id D42F33897A for ; Tue, 12 Nov 2019 04:25:47 -0500 (EST) To: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> From: Michael Richardson Openpgp: preference=signencrypt Autocrypt: addr=mcr@sandelman.ca; keydata= mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QSdv84oNe1 h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2IoHCU6ezhQz2TwJO7 l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF8lIIAYEbQ4YyYyjk5DS30x59 kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDDsMmTJWPkszvQoCjCbrvgDAuoRtL5su2V IQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVlL71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj 1N/2x7mGk35Zrvz0WHjZLcFJYJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQ gRI4pNs24NoxLXl5v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh0 5I5okPcENk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvUmQjFqXgsg4KhIWQb QBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSGTEH03oJIeYbdwlOCe5blA6h4 FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQMxgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU 8VTgenm4JpBdJQx7/7syvIaQilhN2fF25CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnp mspJTGptxFxH/GM/kW40iB4tUjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullzt u37BDVj/SmgbGhvTUXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollE Zcw9VIojPKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kBjQRdxGjv AQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5KhdcxjTlo6htNjRUuUy1Ld 0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOplKgMSoGpGamLSDzRs3SAJu4GF iHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zXfSmZqZwNp/6xosLCl3TKvFWX6421Vb/L WAOOAz/xSyS0GCUs/grBUfzu95+TTskRk7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOq e7/5y4bQkILGGMIux878DhAED865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD 7r5QL6iU57zI/B5U03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhD VmrDKLWXRm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUCXcRo7wIb DAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyytePFmS9NAwdT8A6mA4s +WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8WJVn0zH7LVCKMWo/tHE2rWyi Q1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJprKZAtiDJ897vv1jP09fWLEBhaDsHqLhg ckQpIoee0Id4FXGt7wxDsPwa64SUUCTYdt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7 UXVMQlEKG7E31G1XQMk6sFATF1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8 SFA6Uc+Bjr0i1jdnxS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot 8lIsHGAJQHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw= Message-ID: <7d7609a5-ab18-7296-719e-11b2296f3d07@sandelman.ca> Date: Tue, 12 Nov 2019 17:28:46 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tPgnFOLPGET4ARq6JueodsVnsI6cap9QG" Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 09:28:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tPgnFOLPGET4ARq6JueodsVnsI6cap9QG Content-Type: multipart/mixed; boundary="WI9BL2rquVVU4kyIIiFOODv271g53Rwy1"; protected-headers="v1" From: Michael Richardson To: emu@ietf.org Message-ID: <7d7609a5-ab18-7296-719e-11b2296f3d07@sandelman.ca> Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> In-Reply-To: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> --WI9BL2rquVVU4kyIIiFOODv271g53Rwy1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 2019-11-12 3:53 p.m., Jan-Frederik Rieckers wrote: > On 12.11.19 00:15, Owen Friel (ofriel) wrote: >> One deployment consideration is if an operator wants to use a public P= KI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ev= er, before these extensions could be supported (as Alan alludes to), so i= t would also be good to define how this could work with standard RFC 6125= DNS-IDs / RFC 5280 dNSNames. > I had a lot of thoughts about this topic. > I am experimenting with certificates in EAP-TLS contexts and experience= d > the problems with getting a certificate with specific extension > properties from our public PKI. (In my case a test certificate with a > critical MustStaple extension) You were trying to do a CSR with some extra attributes with a CA (using ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn't verify? > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). There would be the possibility to define a specific > prefix to bind it to a Realm without having the certificate being valid= > for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. I think you are saying that the problem with dNSNames is that web servers use them/pay-attention to them, so CAs are careful what they put in.=C2=A0 That's a reason to avoid that SAN in my opinion.=C2=A0 Toerless= , in draft-ietf-anima-autonomic-control-plane went the other direction, and argued that only dNSNames have good interoperability, and so we have to use only them. > My deployment experience shows, that the certificate check is the main > security problem in WPA2-Enterprise networks. I have seen instructions > for installing WPA2-Enterprise networks where they have explicitly > suggested switching off the certificate check, probably because it was > too complicated for the users and would lead to people complaining at > the IT department about the complicated setup. So, as I understand it, the enrollment process for laptops/phones into WPA-Enterprise does not include retrieving a set of anchors for that connection.=C2=A0 Or that it is just too hard to do.=C2=A0=C2=A0 It works= fine if the devices are compelled by their corporate masters, but this fails for BYOD, and it fails for cross-realm (which eduroam is). --WI9BL2rquVVU4kyIIiFOODv271g53Rwy1-- --tPgnFOLPGET4ARq6JueodsVnsI6cap9QG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAl3Ke04ACgkQcAKuwszY gEPb0Qv+PHaTMbSrl/nYJPaBhxVnmlSvbtADt8K2X/1vP4/SnYnFDYcXlKpGMZaP A7E2uzOAMMpmAV1t8E/G7GRBkZ0y/uF3A7F0OZIAPSW+CnoIjf2+qx0DTIMlWThL CmOZf6jBlPUtU02aAf2aHtzi7moqO9x50AuNLNukWz9/x7h34+ZwO38c0LMp2Gn0 8+k/BJhe6oBNMzSmQk6Ul8Kx4Vb52ZnBBYgBqRZl8BzgokJFza638t/WxQAJbH/L 9s+yhwqy/00Ga31L7B1+O1VAfdLcM7s1j8bbRjXiJ/SeJgVrj6/x5fXaaXgDRxqd W0PIrC6LH2a4ZLuYfK3Przg9d0SB62JZBcwUdFcYRPeaMx4Um+pXnNOW7yS260yI 2/QVw7F7BTN3KiwwL8omI1MVMuXvZyJmQfkmAYm9Wj09qg5N0pFVx65HEThID3xY o/j+sjFeK8B3DcFipT59wUc01GAGwMh8PZwGsEmZZiF2lBDyMLuDT/nOdyQ/n2n2 zmZVBwVk =RmTN -----END PGP SIGNATURE----- --tPgnFOLPGET4ARq6JueodsVnsI6cap9QG-- From nobody Tue Nov 12 02:47:11 2019 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 C687112003E for ; Tue, 12 Nov 2019 02:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de 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 S91eTTJOmTzM for ; Tue, 12 Nov 2019 02:47:07 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F7C12001A for ; Tue, 12 Nov 2019 02:46:30 -0800 (PST) Received: from [134.102.218.221] (dynamic-218-v.informatik.uni-bremen.de [134.102.218.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47C4DN3XBfz17gG for ; Tue, 12 Nov 2019 11:46:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1573555588; bh=LRAnN0IKl0KuqsGyRE7ffxT0Hho+upebp3tXEFeA8/A=; h=To:References:From:Date:In-Reply-To; b=RpQ9rrcVvRwXcGF7wOuRYJ5ZTBl4NKENQ3nDaGz++ol3nzkQeOa+Uar8zcOFPGh0Z njSXZZYroG+p68l63kUqrzNFTMD4lnuHwe4IyxXQCgMjko8xZMZAk5NeJes3QAbv6c HYlDH2CmiiYiSuhsgz0SjXmZPileQnUZx22C4tfA3uSJ9kGfadThgPs2l95858ISvK 6Y+m3mKTaO10HCcRLOxdoMuNi1oENnXXHVRv2qovMtUjN6kuUp5mzIwNnNXgEdibAD YTcCjd3DIHgcurEjwfnb3i5QzarxOKxKlThl0Oa8hpg0CmdakEeapfEnv9I4nedO1w Sn2bCoZmOsqwg== To: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <7d7609a5-ab18-7296-719e-11b2296f3d07@sandelman.ca> From: Jan-Frederik Rieckers Openpgp: preference=signencrypt Message-ID: Date: Tue, 12 Nov 2019 11:46:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <7d7609a5-ab18-7296-719e-11b2296f3d07@sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vkd6RS5DtFSiwjQ10UwQUlWuR3Tj0ZkRG" Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 10:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vkd6RS5DtFSiwjQ10UwQUlWuR3Tj0ZkRG Content-Type: multipart/mixed; boundary="DI9oRGQeDXSzk7X8vJoxfFgXWFIoryFpY"; protected-headers="v1" From: Jan-Frederik Rieckers To: emu@ietf.org Message-ID: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <7d7609a5-ab18-7296-719e-11b2296f3d07@sandelman.ca> In-Reply-To: <7d7609a5-ab18-7296-719e-11b2296f3d07@sandelman.ca> --DI9oRGQeDXSzk7X8vJoxfFgXWFIoryFpY Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12.11.19 10:28, Michael Richardson wrote: > You were trying to do a CSR with some extra attributes with a CA (using= > ACME? Using LetsEncrypt?) and the CA ignored the things that it couldn'= t > verify? No, it was a direct request to the CA of our research network. The problem here was, that the CA itself would have had to clarify this with their CA (Telekom Trust Center), because it would mean to set up a new certificate profile. And that wasn't possible for this one usecase. > So, as I understand it, the enrollment process for laptops/phones into > WPA-Enterprise does not include retrieving a set of anchors for that > connection.=C2=A0 Or that it is just too hard to do.=C2=A0=C2=A0 It wor= ks fine if the > devices are compelled by their corporate masters, but this fails for > BYOD, and it fails for cross-realm (which eduroam is). It doesn't. In eduroam this has lead to cat.eduroam.org, where the installers can be downloaded. As Carsten Borman and I already have written in a submission for the IAB DEDR workshop[1], with the need of this tool we also could have used client certificates instead of username/password combinations. For a long time it was easy to connect to eduroam without certificate checking. Especially Android had a very insecure default setting and most of our users just typed in their username and password and connected to eduroam without any certificate check. And if the inner authentication then defaults to PAP an attacker could get many credentials just by setting up a rogue access point in a crowded place. And many universities in Germany use PAP because they don't want a NT-Hashed password in their database. With the expiry of the old Root CA all clients had to change their configuration, because (if set up correctly) the root ca was in fact pinn= ed. We used this rollover to force all our users to use a specific outer identity, to encourage the use of the CAT. Since the expiry we also deny all requests with any other outer identity before the EAP-TLS handshake, to prevent certificate warnings on the user devices. Jan-Frederik --- 1: https://www.iab.org/wp-content/IAB-uploads/2019/05/p16-bormann-wifi.tx= t --DI9oRGQeDXSzk7X8vJoxfFgXWFIoryFpY-- --Vkd6RS5DtFSiwjQ10UwQUlWuR3Tj0ZkRG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO9n8U/6Yuq3qYHN1UHR7NOiKGm0FAl3KjYQACgkQUHR7NOiK Gm1TGQ//RUGb++J/kpYZoDX2B8T9/A81RGeWTFbkPGr65DtkX7auha8sBCrkKFbp s2u13QFuJNHoJOlGKQPy3LIDJkK00yXnxUFXepe8CkhIJ3EueAVWIdd1vd+BAOsn +KU7MXVV0lcVJgF4Wn2VnDeqp68loBex5R3ZDWNMLB6N4Hdhcj9H7Hd64IuH2mHL t4Gz5aU1xXpRVmTiS2yrJnDEKY4TXeh1llAjyyxLSx9zYFyUXxzHEOleYnaVteTA nSVG6XzNc0Fl5hEvCBQp5aIme8mg+ZDi9o/6Fol6isZfcTTXyGcWvgKix6ZIVikD Jx4YakQhMTuwgF9WMzkn6km7J+MSNuI22Ffr9yhvzjDzZGp4Y8dL3ueEQVLf6qyW pdOdhUvyg73JbJheKToVyOmmPNwrrxb+ZboHSkHQ2rxWIUNCCJW5WmjuI2fCfu5k hNkW4soGuuuEQq+5dUvlAPtCcmse5/C64rS7S8yzWzd/FKFBKnFa8r9yUSM8P/17 Xv8Ic1DTsSOVyUBIvO+Tw+maSbPq6MnKptoh0AbF+GrSIHY9F0Eyoz/BvCCdjHRf FpRWQqo5aFQ1ExfJXmANKMsjWFMmP02346TN6zLPUigZwhGj7nupgEY9HcdrZR2C UOhwV92VuZT2M+qWci4nEciBxUMxoy8kNS4XOXKEriiNjs2SZGs= =lygP -----END PGP SIGNATURE----- --Vkd6RS5DtFSiwjQ10UwQUlWuR3Tj0ZkRG-- From nobody Tue Nov 12 08:32:12 2019 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 C5713120108 for ; Tue, 12 Nov 2019 08:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIkeVl4LZRuH for ; Tue, 12 Nov 2019 08:32:07 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAD6120098 for ; Tue, 12 Nov 2019 08:32:07 -0800 (PST) Received: from [192.168.20.141] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id A2993606; Tue, 12 Nov 2019 16:32:04 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> Date: Tue, 12 Nov 2019 11:32:03 -0500 Cc: "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> To: Jan-Frederik Rieckers X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 16:32:10 -0000 On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers = wrote: >=20 > Signed PGP part > On 12.11.19 00:15, Owen Friel (ofriel) wrote: >> One deployment consideration is if an operator wants to use a public = PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if = ever, before these extensions could be supported (as Alan alludes to), = so it would also be good to define how this could work with standard RFC = 6125 DNS-IDs / RFC 5280 dNSNames. >=20 > I had a lot of thoughts about this topic. > I am experimenting with certificates in EAP-TLS contexts and = experienced > the problems with getting a certificate with specific extension > properties from our public PKI. (In my case a test certificate with a > critical MustStaple extension) >=20 > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). They're also domain names, not realms. A particular certificate may = be valid for authenticating uses to the realm "example.org". That same = certificate may not be valid for the main web site for "example.org". This means that domain names are a hint, but not authoritative. Only = the NAIRealm field would be authoritative. i.e. "this certificate = really is for users authenticating to a realm". > There would be the possibility to define a specific > prefix to bind it to a Realm without having the certificate being = valid > for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. A common short-hand is for certificates to use the "radius" subdomain. = e.g. "radius.example.org". While not perfect, it's something. > My deployment experience shows, that the certificate check is the main > security problem in WPA2-Enterprise networks. I have seen instructions > for installing WPA2-Enterprise networks where they have explicitly > suggested switching off the certificate check, probably because it was > too complicated for the users and would lead to people complaining at > the IT department about the complicated setup. Exactly. =20 > A setup of WPA2-Enterprise can be secure if all devices are part of a > centralized Device Management, but especially in eduroam this isn't > possible. We have a lot of people who don't really care about = security. What's worse is that there's no cross-platform way to set up 802.1X. = It would be nice if a user could visit an HTTPS secured web site for = example.com, and then download a supplicant configuration. Stefan = Winter has a draft: https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 But it received little support from vendors. Security should be simple, and it should be the default. Users don't = care about security because it's hard, and because it too often prevents = them from getting things done. If security is useful, they will use it. Alan DeKok. From nobody Tue Nov 12 08:43:09 2019 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 2E7F412006E for ; Tue, 12 Nov 2019 08:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oobq6wpv35pA for ; Tue, 12 Nov 2019 08:43:04 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3C012082E for ; Tue, 12 Nov 2019 08:43:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 190AF300B22 for ; Tue, 12 Nov 2019 11:43:03 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XxLH8o03p2ea for ; Tue, 12 Nov 2019 11:43:01 -0500 (EST) Received: from [5.5.33.39] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 4585A3004AF; Tue, 12 Nov 2019 11:43:01 -0500 (EST) From: Russ Housley Message-Id: <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_91F0B059-1BC0-4AE3-A679-DD936B2D82D3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 12 Nov 2019 11:43:01 -0500 In-Reply-To: <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> Cc: "emu@ietf.org" To: Jan-Frederik Rieckers References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 16:43:07 -0000 --Apple-Mail=_91F0B059-1BC0-4AE3-A679-DD936B2D82D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 12, 2019, at 2:53 AM, Jan-Frederik Rieckers = wrote: >=20 > Signed PGP part > On 12.11.19 00:15, Owen Friel (ofriel) wrote: >> One deployment consideration is if an operator wants to use a public = PKI (e.g. Lets Encrypt) for their AAA certs, then it could be years, if = ever, before these extensions could be supported (as Alan alludes to), = so it would also be good to define how this could work with standard RFC = 6125 DNS-IDs / RFC 5280 dNSNames. >=20 > I had a lot of thoughts about this topic. > I am experimenting with certificates in EAP-TLS contexts and = experienced > the problems with getting a certificate with specific extension > properties from our public PKI. (In my case a test certificate with a > critical MustStaple extension) >=20 > The Problem with dNSNames is that they are also used in other contexts > (mainly HTTPS). There would be the possibility to define a specific > prefix to bind it to a Realm without having the certificate being = valid > for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants > implementations. >=20 > My deployment experience shows, that the certificate check is the main > security problem in WPA2-Enterprise networks. I have seen instructions > for installing WPA2-Enterprise networks where they have explicitly > suggested switching off the certificate check, probably because it was > too complicated for the users and would lead to people complaining at > the IT department about the complicated setup. >=20 > A setup of WPA2-Enterprise can be secure if all devices are part of a > centralized Device Management, but especially in eduroam this isn't > possible. We have a lot of people who don't really care about = security. Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve = this for you? It is defined in RFC 4334. A certificate for Web PKI = should not include this extended key usage. RFC 4334 also offers a certificate extension that lists the SSIDs that = are associated with the server. Russ --Apple-Mail=_91F0B059-1BC0-4AE3-A679-DD936B2D82D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXcrhFQAKCRCK5O7Q9ZwR y70yAJ9h9ZoXDYvIt9biAxOEffL2WWy5jgCgrz2QsSz7fKi63kFABx3P4WjMijk= =pajQ -----END PGP SIGNATURE----- --Apple-Mail=_91F0B059-1BC0-4AE3-A679-DD936B2D82D3-- From nobody Tue Nov 12 12:07:50 2019 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 5106812004C for ; Tue, 12 Nov 2019 12:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBiQFjDZlre9 for ; Tue, 12 Nov 2019 12:07:47 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E223E120024 for ; Tue, 12 Nov 2019 12:07:46 -0800 (PST) Received: from [192.168.20.141] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 7E2095DF; Tue, 12 Nov 2019 20:07:43 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> Date: Tue, 12 Nov 2019 15:07:41 -0500 Cc: Jan-Frederik Rieckers , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 20:07:49 -0000 On Nov 12, 2019, at 11:43 AM, Russ Housley wrote: >=20 > Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) = solve this for you? It is defined in RFC 4334. A certificate for Web = PKI should not include this extended key usage. >=20 > RFC 4334 also offers a certificate extension that lists the SSIDs that = are associated with the server. That does sound relevant. I wasn't even aware of that document. While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of = anyone using it. Even Microsoft supplicants still require the TLS web = server auth OID (1.3.6.1.5.5.7.3.1). So yes, RFC 4334 is absolutely relevant here. Alan DeKok. From nobody Tue Nov 12 12:13:38 2019 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 B60F4120842 for ; Tue, 12 Nov 2019 12:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAlkTKMya9dd for ; Tue, 12 Nov 2019 12:13:35 -0800 (PST) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8474E120839 for ; Tue, 12 Nov 2019 12:13:35 -0800 (PST) Received: from pps.filterd (m0150245.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xACKBixe028844; Tue, 12 Nov 2019 20:13:29 GMT Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com with ESMTP id 2w7u7b40ja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Nov 2019 20:13:29 +0000 Received: from G2W6311.americas.hpqcorp.net (g2w6311.austin.hp.com [16.197.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id 60F2082; Tue, 12 Nov 2019 20:13:27 +0000 (UTC) Received: from G9W8674.americas.hpqcorp.net (16.220.49.0) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Nov 2019 20:13:25 +0000 Received: from G4W10204.americas.hpqcorp.net (2002:10cf:5210::10cf:5210) by G9W8674.americas.hpqcorp.net (2002:10dc:3100::10dc:3100) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Nov 2019 20:13:25 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (15.241.52.11) by G4W10204.americas.hpqcorp.net (16.207.82.16) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 12 Nov 2019 20:13:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVCg1s3dd7sbNyn4P4uxx3fLyuQV0rWR5DGq/p6OTMvG6Mp/0HOrf8vuCrcVX2/yHHa54UTDYbX4E/g4jdkFUYBlczzayYI4yc1aSxk4txlrJLJWETpJwg4IFnlXd4423XYElrnrLtFfom/1wjJ21y/n5u2/XbGkf3FwdXFoY9lAlOfIA23MUFHApbjU4UwqMGuoEHpnTkyDH7Jt/3c8feam33Bgk5/Fd4t7ia3BDq+Lbydq4wsd5x4/emfAUbsuUH/US+XX/wFIde4FeajkVVmc20PaDz5sUhUew5Smk/WOtaVDenbhGdA4lM5qe5YX9bwgtFn+x/GQHM7VlZT6OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5sebgZ1P0bRmKk/9vB3DT1DGohcVhEu0BqT5jlBs/N0=; b=ShkTbjffqrGyJCkzE0b+BHR5ihgMjJ71bg4MOyoCQqOQsxpgEip6mIlrF9ZMr7V6xa8migcdQDeFmujHSZpw/bSK1nBznUnCPtI4sG55ZoNrwrcyUqUn5og4tFGOWXkJ6e8mCLkadzgR7A/17g6cMNkoFSYiEvAOsqGtlMkGvvQUzIRh6+WO/RTnPxJWaqvayBrkFTljy2Kp+yPP7ajArdCSx2fKPdb2QbG7F8ABypITteQtPcLG8T8aSfzYElwMWf4SLYgiDSihKA36LabtekBLLoSveQdTAxS/hqzQvZwo36V5QnXL8S1Ccok7Lm9dyY2bLALWHEBepAzA0inZ5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.9) by AT5PR8401MB1265.NAMPRD84.PROD.OUTLOOK.COM (10.169.7.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Tue, 12 Nov 2019 20:13:24 +0000 Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110]) by AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110%11]) with mapi id 15.20.2451.023; Tue, 12 Nov 2019 20:13:24 +0000 From: "Cappalli, Tim (Aruba)" To: Alan DeKok , Russ Housley CC: "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPZhfnuWeQf7E22nSLDCx/SnqeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAONLAIAAkMYAgACT34CAADkvgIAAAW7i Date: Tue, 12 Nov 2019 20:13:24 +0000 Message-ID: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:88f7:1621:206b:d022:5ea0:bf0] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9dcd4cb5-96ad-4dba-b7bb-08d767acc57e x-ms-traffictypediagnostic: AT5PR8401MB1265: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1227; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(366004)(136003)(199004)(189003)(76116006)(102836004)(64756008)(6246003)(66556008)(99286004)(55016002)(66946007)(6306002)(66476007)(9686003)(4326008)(110136005)(6506007)(316002)(53546011)(66446008)(236005)(186003)(54896002)(52536014)(256004)(5660300002)(6436002)(71200400001)(71190400001)(478600001)(45080400002)(6116002)(8936002)(25786009)(74316002)(7736002)(14454004)(76176011)(46003)(2906002)(229853002)(7696005)(476003)(446003)(33656002)(11346002)(486006)(81166006)(81156014)(8676002)(86362001)(606006)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB1265; H:AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cdAeNdVrnRHjLZDqVIAPjxAcI/1uqwWzFV58kZ58EOPmHJR1JWrmxkrAwvwOqSmYk9FqqvTx7lBk/kS8NfDNM7+fHwisLWMIehRDNdx7jJpwCfhPOnOb6FZ6zn6H7PI7eAHQGGr5m/i36GZ8J6qFcSmu9Q30PGWaSqPly9s+bPEk/CQvecSWtoqt21tl/B7VDnyreCtDwVDc9EzjDqq9Ez05Chgze2Rq2A8Pv1KBcTegu4pV4i83Uc6xPdhsoroIQyP31Vu8Qcb/X27aCYrGs0WS06WJuP5Yf+C+IrVqGZ0rQ8jbvSTqhhjpNaJeRrCcoKvO61NlKsOEAD0dx9SSfSj1N9LB3Y3if4w7hdXTKDHiOjwITBWYwMay9XZ2LkzeL38+jmsPULrCner8NzPdqZOXR9Mtf0mR/j/aqCJgqp/BJHcC6wyB+TCI+I1ygWtoDaHXxvlLcO27n55rrogzJZjL4fhWEjXqhlwYkD8wBLU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AT5PR8401MB05309002D11E8AEF1018D250DB770AT5PR8401MB0530_" X-MS-Exchange-CrossTenant-Network-Message-Id: 9dcd4cb5-96ad-4dba-b7bb-08d767acc57e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 20:13:24.0676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8bex4Qw+fXu29MK4Gq/xvzdrdNX0pUwG4SCpJec/ObyX2j6WhRrQwrHlAqtSMlKx X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB1265 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 4 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-12_07:2019-11-11,2019-11-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 adultscore=0 mlxscore=0 mlxlogscore=958 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911120171 Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 20:13:38 -0000 --_000_AT5PR8401MB05309002D11E8AEF1018D250DB770AT5PR8401MB0530_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How does a public CA prove ownership of an SSID? From: Emu Date: Tuesday, November 12, 2019 at 3:08 PM To: Russ Housley Cc: emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 12, 2019, at 11:43 AM, Russ Housley wrote: > > Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve = this for you? It is defined in RFC 4334. A certificate for Web PKI should= not include this extended key usage. > > RFC 4334 also offers a certificate extension that lists the SSIDs that ar= e associated with the server. That does sound relevant. I wasn't even aware of that document. While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone u= sing it. Even Microsoft supplicants still require the TLS web server auth = OID (1.3.6.1.5.5.7.3.1). So yes, RFC 4334 is absolutely relevant here. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_AT5PR8401MB05309002D11E8AEF1018D250DB770AT5PR8401MB0530_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How does a public CA prove ownership of an SSID?

 

From: Emu <emu-bounces= @ietf.org>
Date: Tuesday, November 12, 2019 at 3:08 PM
To: Russ Housley <housley@vigilsec.com>
Cc: emu@ietf.org <emu@ietf.org>
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

On Nov 12, 2019, at 11:43 AM, Russ Housley <housl= ey@vigilsec.com> wrote:
>
> Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) sol= ve this for you?  It is defined in RFC 4334.  A certificate for W= eb PKI should not include this extended key usage.
>
> RFC 4334 also offers a certificate extension that lists the SSIDs that= are associated with the server.

  That does sound relevant.  I wasn't even aware of that document= .

  While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of any= one using it.  Even Microsoft supplicants still require the TLS web se= rver auth OID (1.3.6.1.5.5.7.3.1).

  So yes, RFC 4334 is absolutely relevant here.

  Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/= mailman/listinfo/emu

--_000_AT5PR8401MB05309002D11E8AEF1018D250DB770AT5PR8401MB0530_-- From nobody Tue Nov 12 15:40:46 2019 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 A706212011D for ; Tue, 12 Nov 2019 15:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gn5foss7Z1M for ; Tue, 12 Nov 2019 15:40:42 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47506120044 for ; Tue, 12 Nov 2019 15:40:42 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id D0E7ADD; Tue, 12 Nov 2019 23:40:39 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Tue, 12 Nov 2019 18:40:38 -0500 Cc: Russ Housley , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> To: "Cappalli, Tim (Aruba)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 23:40:45 -0000 On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: >=20 > How does a public CA prove ownership of an SSID? Do public CAs *always* verify addresses and/or telephone numbers, = which are normally included in certificates? Do public CAs verify that email addresses in the certificate work? Do public CAs verify that the OIDs in the certificate match the = intended use-cases? Is there a global registry of SSIDs which the public CA could use to = verify the SSID? To put it another way, I'm not sure why this question is being posed. Alan DeKok. From nobody Tue Nov 12 15:59:35 2019 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 DA7591200D8 for ; Tue, 12 Nov 2019 15:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oZlcGCgWrdV for ; Tue, 12 Nov 2019 15:59:31 -0800 (PST) Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C44F120044 for ; Tue, 12 Nov 2019 15:59:31 -0800 (PST) Received: from pps.filterd (m0134420.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xACNVoAo027804; Tue, 12 Nov 2019 23:59:20 GMT Received: from g4t3426.houston.hpe.com (g4t3426.houston.hpe.com [15.241.140.75]) by mx0b-002e3701.pphosted.com with ESMTP id 2w7u7tn23e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Nov 2019 23:59:20 +0000 Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3426.houston.hpe.com (Postfix) with ESMTPS id C31605A; Tue, 12 Nov 2019 23:59:19 +0000 (UTC) Received: from G9W8672.americas.hpqcorp.net (16.220.49.31) by G1W8106.americas.hpqcorp.net (16.193.72.61) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Nov 2019 23:59:19 +0000 Received: from G2W6311.americas.hpqcorp.net (16.197.64.53) by G9W8672.americas.hpqcorp.net (16.220.49.31) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 12 Nov 2019 23:59:19 +0000 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (15.241.52.10) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 12 Nov 2019 23:59:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K7yo3IL7+95JqH34GSKoVHkvCxK08DyeJlNbWJYM6xlax/CcQ7Csy9eMg7DvZ4JyXc47PwlhC/0Y6uaHJV0UrbgkY9mAHs2IA4LHl806mB2WrswEs1ElQr5oA61ldvJBRZtPwa9DHTDKHNYsOKpcmSlsNF98YrMPR8m7spknP6Y5BaTuJdXK5S2VsNkPQhto8RrA8Kvs1lR4N8Ta5vsbBOCe2Qvw96OJThpNJimK7XoohnjrZrw8L0ewMXUvTwVpCcCcFfqEVqkjxFmxe+bjG8nDhmFMBYNpQ9yEY0hDdkkkjnM3FxkQ7moLhdFPvvY5wphMzvj+s7ZI8OSlByyDNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TlJqRQ4H8TcsvewtgCNYzfFjD5vqnjJJJSxkgrrLd6E=; b=WSYCUaXM5tNGVKLlVBdW31qY8m4h7vNNtHvmF3MR6HDgkmN1FW6CE/ZKn8oH3V9ZN//yUTap1WeBYMWiq6aylq8OklUenpcKzAVbil2j6ezRSbgZuuqcH0i/yODGeJTIaqZb0+ITUe6+qIw25qMBuTYk5Y6vrOg8LVgIdDsyAMpVQ2nm1PcZor//A7+W0Fpd/Uqki+iD4iY/Yw99jjk6sv68S3DzZDKHVbTMZxJhuNluxOUeaESIg2wm3tFJSoH56RBW09HupW5S4+2vwbxPpswCX4lMLBfCTuOiF6PYVUVfAUs8R844r8keRt7u7UqR/HgGv/MfUO3HBt4TKhJPGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.9) by AT5PR8401MB0818.NAMPRD84.PROD.OUTLOOK.COM (10.169.5.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Tue, 12 Nov 2019 23:59:17 +0000 Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110]) by AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110%11]) with mapi id 15.20.2451.023; Tue, 12 Nov 2019 23:59:17 +0000 From: "Cappalli, Tim (Aruba)" To: Alan DeKok CC: Russ Housley , "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPZhfnuWeQf7E22nSLDCx/SnqeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAONLAIAAkMYAgACT34CAADkvgIAAAW7igAA6EQCAAAU2/A== Date: Tue, 12 Nov 2019 23:59:17 +0000 Message-ID: <98294862-6601-4479-9690-ad04f62f2d8d@hpe.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> , <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> In-Reply-To: <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.121.28.38] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7932f98d-2b0a-4143-49aa-08d767cc53eb x-ms-traffictypediagnostic: AT5PR8401MB0818: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(136003)(39860400002)(189003)(199004)(71190400001)(66946007)(76176011)(26005)(476003)(66446008)(14444005)(25786009)(66556008)(446003)(486006)(11346002)(91956017)(64756008)(54906003)(256004)(66476007)(2616005)(31696002)(71200400001)(86362001)(14454004)(6916009)(7736002)(53546011)(6506007)(36756003)(99286004)(478600001)(3846002)(6116002)(6246003)(66066001)(5660300002)(8676002)(229853002)(6436002)(102836004)(81156014)(8936002)(81166006)(4326008)(2906002)(54896002)(76116006)(6512007)(6486002)(31686004)(316002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0818; H:AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /5FjA3vnoGonbGbDZKO1qjW+0HDM/TQcSbF6PY7th/QzQbEo5JE4r31LQ8e5P+MLRdsH5pQVCZxqK4vrR6YjOedh8HybVh1NTeSyHXVQi6C0ZMLIgt++wozgNyKOYMLg8CSdhm7xucmbnPqrlSgN6zbUErnLcGu6GnI+qqLu4w5UnWKMLjwOPv1egZ+Zn11rqFCI8anLAmoFbjV9IbDgb7rC2KLX3sKMe2bOJqt3A5OQWLj71bWPK6aRkmuWogFvBQvt2BlMMOR64KJTas7bNXC6NV2iPSt+b3f80pCjVnSAdv9BjOtpxnMBsO3qGMp4WMFafaAgkMYd3xYqPBaQplXE4TwdQfPsyrZr3F5sbl+Xh7UlGrzlQguvRXXDMHHwUfl+R7S+OSiPUKabU4FH2P2tal2vjasDXuuhW+IHjHUgJLDHZRfR3o1JT0D9WpSZ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_98294862660144799690ad04f62f2d8dhpecom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7932f98d-2b0a-4143-49aa-08d767cc53eb X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 23:59:17.4722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aHzCkFvAouLlzCjw3bhQg0dBUu5isfekl9rTfcw2w749pgUE6qr8Vx0jQkIT51KJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0818 X-OriginatorOrg: hpe.com X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-12_09:2019-11-11,2019-11-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1015 adultscore=0 lowpriorityscore=0 mlxlogscore=530 spamscore=0 impostorscore=0 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911120201 Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 12 Nov 2019 23:59:33 -0000 --_000_98294862660144799690ad04f62f2d8dhpecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regardless of validation levels, it is not possible to own an ESSID. It is = possible, however, to own a domain, email address, physical address, etc. T= hat's the difference. Putting an ESSID in a certificate is a slippery slope. I doubt any public C= A or OS vendor would ever entertain this. Tim ________________________________ From: Alan DeKok Sent: Tuesday, November 12, 2019 18:40 To: Cappalli, Tim (Aruba) Cc: Russ Housley; emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: > > How does a public CA prove ownership of an SSID? Do public CAs *always* verify addresses and/or telephone numbers, which a= re normally included in certificates? Do public CAs verify that email addresses in the certificate work? Do public CAs verify that the OIDs in the certificate match the intended = use-cases? Is there a global registry of SSIDs which the public CA could use to veri= fy the SSID? To put it another way, I'm not sure why this question is being posed. Alan DeKok. --_000_98294862660144799690ad04f62f2d8dhpecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Regardless of validation levels, it is not possible to own an ESSID. It is = possible, however, to own a domain, email address, physical address, etc. T= hat's the difference.

Putting an ESSID in a certificate is a slippery slope. I doubt any public C= A or OS vendor would ever entertain this.

Tim


From: Alan DeKok <= ;aland@deployingradius.com>
Sent: Tuesday, November 12, 2019 18:40
To: Cappalli, Tim (Aruba)
Cc: Russ Housley; emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba)= <timc@hpe.com> wrote:
>
> How does a public CA prove ownership of an SSID?

  Do public CAs *always* verify addresses and/or telephone numbers, wh= ich are normally included in certificates?

  Do public CAs verify that email addresses in the certificate work?
  Do public CAs verify that the OIDs in the certificate match the inte= nded use-cases?

  Is there a global registry of SSIDs which the public CA could use to= verify the SSID?

  To put it another way, I'm not sure why this question is being posed= .

  Alan DeKok.

 --_000_98294862660144799690ad04f62f2d8dhpecom_-- From nobody Tue Nov 12 16:59:51 2019 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 982EC1200E3 for ; Tue, 12 Nov 2019 16:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pVlGS6q9T6s for ; Tue, 12 Nov 2019 16:59:47 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09BF11200C1 for ; Tue, 12 Nov 2019 16:59:46 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 37B56370; Wed, 13 Nov 2019 00:59:44 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <98294862-6601-4479-9690-ad04f62f2d8d@hpe.com> Date: Tue, 12 Nov 2019 19:59:42 -0500 Cc: Russ Housley , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2B7835F2-C713-464C-AA98-3CE02041EF59@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <98294862-6601-4479-9690-ad04f62f2d8d@hpe.com> To: "Cappalli, Tim (Aruba)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 13 Nov 2019 00:59:50 -0000 On Nov 12, 2019, at 6:59 PM, Cappalli, Tim (Aruba) wrote: >=20 > Regardless of validation levels, it is not possible to own an ESSID. = It is possible, however, to own a domain, email address, physical = address, etc. That's the difference.=20 I think that's largely begging the question. Your comment seems to be that it's OK for a certificate to include = incorrect a physical address, because that address is "owned" by = someone. Even if the owner of that address knows nothing about the = certificate request. I don't see how that's useful. Which is why I asked about validation. If the CA doesn't validate = addresses, why should it validate SSIDs? Even worse, the CAs verify = *control* of domain names. They don't verify *ownership* of the domain = name. They're not quite the same thing. Is the person requesting the certificate the "owner" of the domain = name? If not, is the certificate request authorized by the owner? None = of this is checked by CAs right now. > Putting an ESSID in a certificate is a slippery slope. I doubt any = public CA or OS vendor would ever entertain this. Both are well known to do "surprising" things with certificates. I'm = not sure why they would care about additional fields in a certificate. My point is that we have loose rules around the subjects of = "ownership" and "validation". Simplistic statements are easy to make, = but aren't particularly helpful. In my view, if something is useful, practical and can be shown to be = not harmful, then I think it can be used. Putting SSIDs into a = certificate seems useful, and (at least) the PKIX WG seemed to have = agreed. Further, RFC 4334 in fact contains no text about "ownership" of the = SSID. i.e. inclusion of an SSID in a certificate is *not* a statement = about "ownership" of that SSID. So your comments seem to be against an = issue that doesn't exist. Alan DeKok. From nobody Wed Nov 13 06:32:14 2019 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 187051200D7 for ; Wed, 13 Nov 2019 06:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de 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 0FJe3xV8kJKa for ; Wed, 13 Nov 2019 06:32:11 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5EE12003E for ; Wed, 13 Nov 2019 06:32:10 -0800 (PST) Received: from [10.11.85.85] (vpn-client.noc.uni-bremen.de [134.102.5.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47CnBK0bg9zyP1 for ; Wed, 13 Nov 2019 15:32:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1573655529; bh=OWX9VKS+BB3XQ/We+RbsqdAGqbvw8qWOp61EFvM/49A=; h=To:References:From:Date:In-Reply-To; b=VkKE2sPgmqTiMeKGcFm+pmJsGb0WHuk895qn8CnqFOcGXV/W//IoXrxzzSvUB6QuY QqDGWpz2cAFhpLewxOoYN8IwRZdu6+1+d15XibfE1kfGtPWV1HvXEpXntAuXg3HU0Y Kqbz5ulgbWJj2BVqUT5uYa29ooSZKwQCX9MMZ6iBjn3DaClRHI31lIywiyL/a3LHQu vL13sgDWiysDEW8BkFZpJlXTC4uDqzn8nclq10WFlPW/o2uyLnE/gbP+dOtF3mTvlL DJJ1j/er7CeOD/q3EH0afLk59oZMYwIgUdrlKSwZgokew45vd4HP5MB4STOHCbPyoo VyI2fLHFcSdAQ== To: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> From: Jan-Frederik Rieckers Openpgp: preference=signencrypt Message-ID: <049d789f-08af-dc75-37f9-c977e1e1c5a9@uni-bremen.de> Date: Wed, 13 Nov 2019 15:32:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kOlQV8UANZLPf2dz5PkvToMeJOQrTxjHI" Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 13 Nov 2019 14:32:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kOlQV8UANZLPf2dz5PkvToMeJOQrTxjHI Content-Type: multipart/mixed; boundary="VTu4hqIp0cOBmrAg6CgcOwBnzFQz9M4gm"; protected-headers="v1" From: Jan-Frederik Rieckers To: emu@ietf.org Message-ID: <049d789f-08af-dc75-37f9-c977e1e1c5a9@uni-bremen.de> Subject: Re: Idea: New X509 Extension for securing EAP-TLS References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> In-Reply-To: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> --VTu4hqIp0cOBmrAg6CgcOwBnzFQz9M4gm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable There has been some discussion about this idea. I don't have any experience in IETF work yet, so I don't know how this discussion can go o= n. I would be happy to present my deployment experiences from eduroam and the basic idea in Singapore. (Since I won't attend the meeting in person, I would join from remote) Is there room for that? Jan-Frederik Rieckers --VTu4hqIp0cOBmrAg6CgcOwBnzFQz9M4gm-- --kOlQV8UANZLPf2dz5PkvToMeJOQrTxjHI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO9n8U/6Yuq3qYHN1UHR7NOiKGm0FAl3ME+gACgkQUHR7NOiK Gm0A+hAAq+LQXQE2Ey/zNmNt8CszNZBEkNuSBo1UqQtczFmVYuQrwKAPz1wdYerr SWrqnvk2vFtbURs8wjI2G3CoJyn1QEuOqeHp+jqDZvytobLlLAQCeZduAzRd2uBP h/Jh50F7qL3daMUDIKbQAj8bUqCiqIDu+RKwHnsdxh/5UAoLhd7f4h2DLMpbUFCf L8UtA1CrGDn8/BW1okzzM90+tIpe+PRb6s42BmURLTIpQSWkYPN7jGy9298127FK BAfEMKCpJYa5y6ZM3D8ZNoDwMVx7WOd4x5jiqVbxpYK4lS6RMn/pVomirAi66ULW UA4Hsfq4mzwf93BxEYVN45UCYsqaHor6mddir53QuHRt8Boq+1o75znKGc4Coj72 R0qjkya04GOFcfu6IWB9bBpFIRXk/XhbX83GJm4KWzcmNJiTTbKyYgenn/cu9Jmk NLViqA6cZsPyXZ2GCr64yhudMX1c6RuSqIV8NV6qYJbIyiN5Od/HBpQbCLwZaFvQ 3lJBMRaX3/uLT2OHMjZx/JD3ioCCRtdoaPcNmJOhxT3t1o4YUpdWVJbbOinD8Lj7 l6S7AGZm7n5rChyZ/iTIyNEcMhtpGRD2fXWxAjq8DKZBaKUkbVR24yiz1/L7eENB cBkMWwDlwFxkNQYUzFDiE0CskD4cMWlUtrhge2njvMkPnzH+ekg= =gsfl -----END PGP SIGNATURE----- --kOlQV8UANZLPf2dz5PkvToMeJOQrTxjHI-- From nobody Wed Nov 13 15:24:00 2019 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 BC26D120837 for ; Wed, 13 Nov 2019 15:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H--af_1z3Wka for ; Wed, 13 Nov 2019 15:23:57 -0800 (PST) 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 01663120831 for ; Wed, 13 Nov 2019 15:23:56 -0800 (PST) Received: from [192.168.41.2] (unknown [49.74.64.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id E9B4F3818F for ; Wed, 13 Nov 2019 18:20:48 -0500 (EST) To: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> From: Michael Richardson Message-ID: <240b3611-706c-303f-82aa-3fc3d78b7aa3@sandelman.ca> Date: Thu, 14 Nov 2019 07:23:52 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 13 Nov 2019 23:23:59 -0000 On 2019-11-13 4:07 a.m., Alan DeKok wrote: > On Nov 12, 2019, at 11:43 AM, Russ Housley wrote: >> Can the extended key usage for EAP over a LAN ( id-kp-eapOverLAN ) solve this for you? It is defined in RFC 4334. A certificate for Web PKI should not include this extended key usage. >> >> RFC 4334 also offers a certificate extension that lists the SSIDs that are associated with the server. > That does sound relevant. I wasn't even aware of that document. > > While RFC 4334 offers the id-kp-eapOverLAN OID, I'm not aware of anyone using it. Even Microsoft supplicants still require the TLS web server auth OID (1.3.6.1.5.5.7.3.1). I think that the issue isn't, can we find or define a OID that has the right semantics. I think that the issue whether or not any public CAs are willing to include that into a certificate. From nobody Wed Nov 13 15:27:04 2019 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 CA84A120837 for ; Wed, 13 Nov 2019 15:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR4T-mXUS84t for ; Wed, 13 Nov 2019 15:27:01 -0800 (PST) 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 199D8120831 for ; Wed, 13 Nov 2019 15:27:00 -0800 (PST) Received: from [192.168.41.2] (unknown [49.74.64.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 27E373818F for ; Wed, 13 Nov 2019 18:23:52 -0500 (EST) To: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> From: Michael Richardson Message-ID: Date: Thu, 14 Nov 2019 07:26:55 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 13 Nov 2019 23:27:03 -0000 On 2019-11-13 7:40 a.m., Alan DeKok wrote: > On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: >> How does a public CA prove ownership of an SSID? > Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? They are?  I've rarely seen it. I think that if it's in the certificate, then they have verified them. I can remember in the bad old days providing CAs with notorized articles of incorporation, etc. I haven't done that this decade though, and I haven't seen that kind of info. CAs won't include anything they can't verify. > Do public CAs verify that email addresses in the certificate work? yes, they do by sending a challenge to it. > Do public CAs verify that the OIDs in the certificate match the intended use-cases? Most won't include OIDs. > Is there a global registry of SSIDs which the public CA could use to verify the SSID? No, SSIDs are a local matter. One could (and I do), use FQDNs as the SSID. That's the only way I can see this working. From nobody Thu Nov 14 03:59:56 2019 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 C6D6512011E for ; Thu, 14 Nov 2019 03:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiu7WB3wD6VE for ; Thu, 14 Nov 2019 03:59:52 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153A412011B for ; Thu, 14 Nov 2019 03:59:51 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 8406219AD; Thu, 14 Nov 2019 11:59:49 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <240b3611-706c-303f-82aa-3fc3d78b7aa3@sandelman.ca> Date: Thu, 14 Nov 2019 06:59:48 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9AD503C8-EE44-4EEC-B87E-8BBC11EB031A@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <240b3611-706c-303f-82aa-3fc3d78b7aa3@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Thu, 14 Nov 2019 11:59:55 -0000 On Nov 13, 2019, at 6:23 PM, Michael Richardson = wrote: >=20 > I think that the issue isn't, can we find or define a OID that has the > right semantics. > I think that the issue whether or not any public CAs are willing to > include that into a certificate. That's less relevant than it may be. The common practice for years has been to recommend self-signed or = "internal" CAs. The original reason was that supplicants didn't do = certificate pinning. So if they were configured to trust a root CA, = they would send user credentials to *any* EAP authentication server = which had a certificate signed by that CA. With certificate pinning, = they now warn if the server certificate changes. The other reason is that supplicant configuration is still largely a = manual process. If admins need a complex process to configure the = supplicant, then adding a self-signed CA to the mix has near-zero cost. = And supplicant vendors seem entirely disinterested in a standard way to = configure them. The other benefit of self-signed CAs is that they're free. No = verification is required. Since the admin controls both the CA and the = end user machine, he's free to do whatever he wants, when he wants. As to why self-signed CAs are appealing, here's an example. I've had = "interesting" times trying to renew a simple certificate for HTTPS = usage. The CA was happy to take my money and "verify" ownership of a = domain. But they were entirely uninterested in sending me an actual = certificate. Their support system was similarly unhelpful. In the end, = I went with a simpler approach. And I can't be the only person that = this happened too. The gating issue for me is supplicants. It's easy to update Open = Source supplicants to check new OIDs. The larger vendors might upgrade. = Eventually. Maybe. On a technical front, a major issue is also *how* to upgrade. What do = supplicants do? Allow both OIDs? When do they start rejecting = certificates with the "TLS web server" OIDs? Alan DeKok. From nobody Thu Nov 14 04:39:24 2019 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 88BF6120251 for ; Thu, 14 Nov 2019 04:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvKRsEHGeSwX for ; Thu, 14 Nov 2019 04:39:21 -0800 (PST) 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 67FB0120232 for ; Thu, 14 Nov 2019 04:39:21 -0800 (PST) Received: from [192.168.41.2] (unknown [49.74.66.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 49C8D3818F; Thu, 14 Nov 2019 07:36:07 -0500 (EST) To: Alan DeKok Cc: emu@ietf.org References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <240b3611-706c-303f-82aa-3fc3d78b7aa3@sandelman.ca> <9AD503C8-EE44-4EEC-B87E-8BBC11EB031A@deployingradius.com> From: Michael Richardson Message-ID: Date: Thu, 14 Nov 2019 20:38:59 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <9AD503C8-EE44-4EEC-B87E-8BBC11EB031A@deployingradius.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Thu, 14 Nov 2019 12:39:23 -0000 On 2019-11-14 7:59 p.m., Alan DeKok wrote: > On Nov 13, 2019, at 6:23 PM, Michael Richardson wrote: >> I think that the issue isn't, can we find or define a OID that has the >> right semantics. >> I think that the issue whether or not any public CAs are willing to >> include that into a certificate. > That's less relevant than it may be. > > The common practice for years has been to recommend self-signed or "internal" CAs. The original reason was that supplicants didn't do certificate pinning. So if they were configured to trust a root CA, they would send user credentials to *any* EAP authentication server which had a certificate signed by that CA. With certificate pinning, they now warn if the server certificate changes. > > The other reason is that supplicant configuration is still largely a manual process. If admins need a complex process to configure the supplicant, then adding a self-signed CA to the mix has near-zero cost. And supplicant vendors seem entirely disinterested in a standard way to configure them. I understand. If the authentication server is manually configured, then it matters not in the last what OIDs might be in the certificate. We believe that TEAP-BRSKI (or BRSKI-WIFI) will result in supplicants being configured during an automated process. This would involve getting the organizational root CA, and it could pin the authentication server certificate, or it could pin just a DN, TBD.  The OIDs might be be useful that point, but I would generally find them not interesting. From nobody Thu Nov 14 15:12:35 2019 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 7033B120059 for ; Thu, 14 Nov 2019 15:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVloQyyUngIn for ; Thu, 14 Nov 2019 15:12:29 -0800 (PST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2351120058 for ; Thu, 14 Nov 2019 15:12:29 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id v16so3092890qvq.6 for ; Thu, 14 Nov 2019 15:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ZedAkUONYETmBc1ADkrzpST5F29i2cBMGkcAssWagLo=; b=wBN6yKo1B/shCsnBlkfZPsxQGMGz5SGNyN2IUuOyYDzLZbooSXQglR0PIeJX93X3Cz vf01RoyYuJvAqSnY9nD7EzNgd4HzteNpleR4CIboSLcCUeg4Hv31642us+7R6gzV44+M 1YUHt1gK6ugA+mf/IpV56NnCFxlANQHp5UCr+oJNLZzdLo3eWN9iKhDJMmfAdHsX9PYF cTQYijLnSSNj7lpztOu0AsPe2b+RF2yLvxfQehF26YVhLCaYSVvPCKRKS4jrXTI/zrgB 7OB3XRGH9KlBgFUh2m5WIfo9fjUkdJykbi4Ezd8KhGpWzW9YRF3SIiilUbKMn6h6ryn1 6S6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZedAkUONYETmBc1ADkrzpST5F29i2cBMGkcAssWagLo=; b=ZJ/ezobnMbOGsZ4cXdd8QzgtaT1sn0KVQZutHjL+znQjAgMdTpxvl0dfFAKRrzJJhD ntK2u/5Ye0ln2g643+z+5KCmXszf6eivx9Hj9+/SWk1AeGozeJqOTgb2jOcE1nQTFYm+ ExEXU5yj/fhSZz7idtV0jTWSXSDhyacUb+31XlaSvpfHA9C02GQhEwnkEcBJ2ywtj8YL yWtP6lYz6djQImfvdzYjhfFpg1zWV1yqCB6Td1LWJib7wjr8RpyBOgRaEeyhJDLZOeE0 6kq7tKobEhwi1SFkHytq9hqupRXMHE6d3L41itPTq/ZQuAamq48Bxi18jzuBjJsmBh+p MjUA== X-Gm-Message-State: APjAAAVaXLuc+ydIa8V/O7uEyMBTvr++YbpEbMU0wI7GIw81ly0tGhfX 8Xs2rb7uz3CyyxPaK0Vys6Q2CD1GlVDGk53mnoqchkGtvdA= X-Google-Smtp-Source: APXvYqymC8Q4v3iXqscyCjUm6PWYVdVHItv+o1daVU24FvsZGBvzRA64JbUf8yoUR6sHX8T8ybdRfUAg0j5GSrS4aqU= X-Received: by 2002:a0c:eed3:: with SMTP id h19mr10456339qvs.153.1573773148561; Thu, 14 Nov 2019 15:12:28 -0800 (PST) MIME-Version: 1.0 From: Joseph Salowey Date: Thu, 14 Nov 2019 15:12:18 -0800 Message-ID: To: EMU WG Content-Type: multipart/alternative; boundary="0000000000007a3a040597569d24" Archived-At: Subject: [Emu] Presentations for IETF 106 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: Thu, 14 Nov 2019 23:12:32 -0000 --0000000000007a3a040597569d24 Content-Type: text/plain; charset="UTF-8" If you are on the agenda [1] for IETF 106 in Singapore please send your slides to emu-chairs@ietf.org as soon as possible as the meeting is on Monday. Failure to send your slides before the day of the meeting may result in your presentation being pushed to the end of the agenda. [1] (https://datatracker.ietf.org/meeting/106/materials/agenda-106-emu-00) --0000000000007a3a040597569d24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you are on the agenda [1]=C2=A0for IETF 106 in Singapor= e please send your slides to=C2=A0em= u-chairs@ietf.org as soon as possible as the meeting is on Monday.=C2= =A0 Failure to send your slides before the day of the meeting may result in= your presentation being pushed to the end of the agenda.=C2=A0=C2=A0
<= br>
--0000000000007a3a040597569d24-- From nobody Sat Nov 16 04:59:44 2019 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 4238D120127 for ; Sat, 16 Nov 2019 04:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Gqb7Ykxf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=B8oAqTAF 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 Pyh7JNCqhz1x for ; Sat, 16 Nov 2019 04:59:40 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AE312006D for ; Sat, 16 Nov 2019 04:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1750; q=dns/txt; s=iport; t=1573909180; x=1575118780; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qOTMl9R3dkh/9Vj27QAyNqKrM4ypKDRZNvAOyJWNGWs=; b=Gqb7YkxfdEfE0/3bLOOnYvedz1zTxaBSq0UnAN2abcYpZa+Oc2nxSgV8 WetCEjpTWnPcUf9GbRQPKF5Ka0BKUFn26/glVG1E8/v6Pj+hCtBC9J45s UVpUPUP353OvvOqaFKmDg4XTLLJatkltWkdFUMrPPH1L3XgGcd0O198J4 k=; IronPort-PHdr: =?us-ascii?q?9a23=3AB4ebrh8pCFztT/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcmLE0z2KNbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AAAU8s9d/4sNJK1cCRsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgWwEAQEBCwGBSlAFgUQgBAsqhCmDRgOKcU6CEJgAgS6?= =?us-ascii?q?BJANUCQEBAQwBAS0CAQGEQAIXggwkNgcOAgMLAQEEAQEBAgEFBG2FNwyFUQE?= =?us-ascii?q?BAQEDEhERDAEBOAsEAgEIDgMEAQEBAgImAgICMBUICAIEARIIGoVHAy4BAqQ?= =?us-ascii?q?zAoE4iGB1gTKCfgEBBYUVGIIXCYEOKAGMFBiBQD+BEUaCHi4+hBsUGBWCeTK?= =?us-ascii?q?CLJATnhoKgiqMQIkqmhGOSJoIAgQCBAUCDgEBBYFZAjCBWHAVgydQERSRGoN?= =?us-ascii?q?zilN0gSiNYCuCEwEB?= X-IronPort-AV: E=Sophos;i="5.68,312,1569283200"; d="scan'208";a="381518673" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2019 12:59:39 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xAGCxdTe031607 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Nov 2019 12:59:39 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 06:59:38 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 06:59:38 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 16 Nov 2019 06:59:38 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mz0fl1//SLoTNMGnthWh3K6c+slKz20JjYq76NMxud7bbRNDVvUpn3rksn7lU2NfhI8fWoVvJjzcuL9zlfZe0NBEpkiw4+TI924rbWDwuE0NRaiWtKMqFr7yNmRfTlHP8oDith8uJ8hpR4EZgLtN+BIkdnhWHk9HbsXiYvRe9HYdci4JFzS5J7aaC9Y2u3bRFIs9dM3XtQM1C3348rrF/Ynnm9BPtp9fFbG84daoa9D5FJit9rsTQY7v7UCjp3NlmJOsu4NR7zebxtcyohn/k+XaOY4HTgKfKVyJa11SJjp3iQAcS7V0U9GHBPDRqow1l6ZOzGl4RSIgQAAKwJpcPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qOTMl9R3dkh/9Vj27QAyNqKrM4ypKDRZNvAOyJWNGWs=; b=m4BCJ3oJhitI5eVBXJ2jSsLT6eWukOYnVYqfyIfbCWqq4wYknjL7TSg8Fq0zJbBQ0GGyQgTh5/aYqaVAtbBcS7aFTCZKvuvLByqrSiN6t2o/EBOnvhZ/6682pFQUCm72grPxdY+Ltvda/hmj021ce0KNBGQY5HQ3MhZJOIFjPYK4WKAXbW/NincBiq6KqH+hs+7xAT4VmEO9wubD3pHd3TNFBAeLeizwQXP3wrXCe5Sxteq58SD+Vb+EGN+/PknNtYOswVkqJ7ptxeBuVj42j++MArnclVTqDrpHBpWUev8hUmX8yQDI1HV+zocK63X57K2PYe8PJPG9nbgAyONC5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qOTMl9R3dkh/9Vj27QAyNqKrM4ypKDRZNvAOyJWNGWs=; b=B8oAqTAF3bvxTqIOUD5bMqBxkHtn/gp/x1ffrLUmSHEDx2vJ6RT8SinUvt14LmdTnSabnqnwmGvZLuVEDFfUxvbWpaBDLUSlXUj0ptGqkWYdeuyvRR4KVWhh2UH/12RDl7F4iMATXn63jST9by41OshmZm/bBIZr2blaTcRyhck= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4045.namprd11.prod.outlook.com (20.179.149.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Sat, 16 Nov 2019 12:59:37 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.029; Sat, 16 Nov 2019 12:59:37 +0000 From: "Owen Friel (ofriel)" To: Michael Richardson , "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPeAysQlGUpTU6o3aUNy73n/aeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAOEToIAAqv2AgAZ+ImA= Date: Sat, 16 Nov 2019 12:59:37 +0000 Message-ID: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <03a039fc-4f88-13ca-8492-29e6738d550d@sandelman.ca> In-Reply-To: <03a039fc-4f88-13ca-8492-29e6738d550d@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0c8:1007::a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9720c45a-a225-4013-fdd0-08d76a94d5ed x-ms-traffictypediagnostic: MN2PR11MB4045: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(199004)(189003)(13464003)(52536014)(46003)(5660300002)(8936002)(55016002)(6246003)(81166006)(81156014)(71190400001)(71200400001)(14454004)(7736002)(305945005)(74316002)(4001150100001)(25786009)(6116002)(186003)(478600001)(102836004)(9686003)(14444005)(229853002)(6436002)(2501003)(256004)(76176011)(110136005)(316002)(64756008)(476003)(66446008)(7696005)(66476007)(53546011)(6506007)(8676002)(99286004)(2906002)(86362001)(66556008)(76116006)(486006)(11346002)(66946007)(446003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4045; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kRcDay6jIqhHFfOtAjPoSbW7dEJrXwUj7nPUr3RN/nfc1OC3zo/ZP77qlIg465mqQcphfbtbPU0Nupnyz1VU+7IeFJSO+W4wxlXgIS7SuA9tNb0VH38dZ1HYVUeTEgtJThYmZBcDWcMPrWK4W0lgbSlvIYXWcdxVbI+yqUM6GmjDXEaeGjGMr+PGwxkBd+J+kcUcIFjCj9icr0u7eymvN4KO4zju2l9kkvSJ/c5IDhr3TjLGHpC0B1KhukgEH0bp2WhdXY8WJn9QoZEs/ICnWwIUXxg8Pn5TstuSO4vg7hyd1JhXQYTCBSkVOug6V5E7W3PEHXJC9emxpkxZdOzCWsCwj0EV+ogAjpxZD7ZXmw8PhkYnniSGIOTb2yRQ7hz5t3MxSoBafFBTg3wTeHbTF01GRG0KWCTSysZK42ydxVB0rLFOsipk4kZNifcgI+9x x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9720c45a-a225-4013-fdd0-08d76a94d5ed X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2019 12:59:37.2313 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9deQs4HvqnH837jab3+BgZJAQqOh/nhNnJ36/DHLXhJ8pL1Iu4CuDSofRthHrDajw/sWeLXjdftuvEYhWgHCNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4045 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 16 Nov 2019 12:59:42 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFbXUgPGVtdS1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiAxMiBOb3ZlbWJl ciAyMDE5IDA5OjIwDQpUbzogZW11QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0VtdV0gSWRlYTog TmV3IFg1MDkgRXh0ZW5zaW9uIGZvciBzZWN1cmluZyBFQVAtVExTDQoNCg0KDQpPbiAyMDE5LTEx LTEyIDc6MTUgYS5tLiwgT3dlbiBGcmllbCAob2ZyaWVsKSB3cm90ZToNCj4gVGhpcyBpcyBhbHNv IHJlbGF0ZWQgdG8gb25nb2luZyBhbmltYSBkaXNjdXNzaW9ucyBhYm91dCBSRkMgODM2NiwgYW5k IGhvdyBpdCBjYW4gYm9vdHN0cmFwIHRydXN0IHdoZW4gdGhlIHBpbm5lZCBkb21haW4gY2VydCBp cyBhIHB1YmxpYyBQS0kgQ0EsIGFuZCBub3QgYSBwcml2YXRlIENBLCBhbmQgaGVuY2UgYWRkaXRp b25hbCBkb21haW4gKG9yIHJlYWxtIG9yIEZRRE4pIGluZm8gaXMgYWxzbyBuZWVkZWQgaW4gb3Jk ZXIgZm9yIHRoZSBwZWVyIHRvIHZlcmlmeSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlcnZlci4NCg0K V2hpbGUgSSdtIGZhbWlsaWFyIHdpdGggdGhpcyBjb252ZXJzYXRpb24sIHdoaWNoIEknbSByaWdo dCBub3cgaW5zcGlyZWQgdG8gY2FsbCB0aGUgdGhlICJNYXJpYSIgcHJvYmxlbSAoIkhvdyBkbyBz b2x2ZSBhIHByb2JsZW0gbGlrZSBNYXJpYS7CoCBIb3cgZG8geW91IGEgY2xvdWQgY2VydGlmaWNh dGUgYW5kIHBpbiBpdCBkb3duPyIpDQoNCkkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCBp dCBoYXMgdG8gZG8gd2l0aCB0aGUgcHJvYmxlbSBvZiBhbiBFQVAgY2xpZW50LCAqKndoaWNoIGlz IG5vdCBkb2luZyBpbml0aWFsIG9uYm9hcmRpbmcqKiwgdG8gdmFsaWRhdGUgYSBjZXJ0aWZpY2F0 ZSB0aGF0IGl0IGhhcyByZWNlaXZlZCBhcyBwYXJ0IG9mIEVBUC1UTFMqLg0KDQpbb2ZyaWVsXSB3 aGV0aGVyIGl0cyBmaXJzdCB0aW1lIGJvb3RzdHJhcCBvciBzdWJzZXF1ZW50IEVBUCBhdXRoZW50 aWNhdGlvbiwgdGhlIEVBUCBzZXJ2ZXIgaXMgZ29pbmcgdG8gcHJlc2VudCB0aGUgc2FtZSBpZGVu dGl0eSBjZXJ0IHRvIHRoZSBjbGllbnQsIGFuZCB0aGF0IGNvdWxkIGJlIHNpZ25lZCBieSBhIHB1 YmxpYyBDQSwgYW5kIGluIGJvdGggc2NlbmFyaW9zIChib290c3RyYXAgYW5kIHJlYXV0aGVudGlj YXRlKSB0aGUgY2xpZW50IG5lZWRzIHRvIGtub3cgd2hhdCBpZGVudGl0eSB0byBsb29rIGZvciBp biB0aGUgc2VydmVyIGNlcnQuDQoNCg0K From nobody Sat Nov 16 05:00:14 2019 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 20F1212018B for ; Sat, 16 Nov 2019 05:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eN23+UO2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PaU2KH/D 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 LMIVubjhZ1R0 for ; Sat, 16 Nov 2019 05:00:04 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8143E12013F for ; Sat, 16 Nov 2019 05:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2000; q=dns/txt; s=iport; t=1573909204; x=1575118804; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yPD/UrdyBJaA+QC3t2kWa5kJw7gJ8fGpwDiPKhvvGjk=; b=eN23+UO2dv1wVOrIHxclVbTjvB1bpfcdElcxtHW1+7dhDDvaas6M2Hsn CGcLEcxt/Ote2k5EvqCrdhfPlXkFJy05ofNyeofn2HYNnhHCfPEZMhcHr DuqW7AHpevY+dVrey/qqOqaRgixQ9V58jDTofJWHnPNB+iddznipd0hPf 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AE5BgrxORWGnnfSsfgYYl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj8IuTrYigSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQCH8s9d/5pdJa1cCRsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgX6BS1AFbFggBAsqh28DinOCXpgAglIDVAkBAQEMAQE?= =?us-ascii?q?fDgIBAYRAAoIjJDgTAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQECARIoBgEBNwE?= =?us-ascii?q?EBwQCAQgRBAEBHxAyHQgCBAENBQgagwGCRgMOIAECpDUCgTiIYIIngn4BAQW?= =?us-ascii?q?FFRiCFwmBNowVGIFAP4FXgh4uPoQbFBiDQIIsri0KgiqHGo5QgzGWYI5Imgg?= =?us-ascii?q?CBAIEBQIOAQEFgWkigVhwFYMnCUcRFJEag3MzhGGFP3SBKJAeAQE?= X-IronPort-AV: E=Sophos;i="5.68,312,1569283200"; d="scan'208";a="364715467" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2019 13:00:01 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xAGD01Zh007244 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Nov 2019 13:00:01 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 07:00:00 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 06:59:59 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 16 Nov 2019 06:59:59 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mNiusLVIWR0zNLbzk3GYJQ++GLKv4STQ9LddbD77gbciZhjZruBePOiEjvYkhZDqXHisj9mX7NYSp4oh7io0GG9fOV+HNaVJHNEIBluxTAJLdDzaWHX4Bgoq1A1nfU6lW4X52ejbjN88coJDadf3zywXwzpWYWR4pM6hz7vKM6QuF1H9deOfhiaN2V0Sk/Q9nPDIlsB9d6BAD1656qll2aalMDgwG7tSjKLNMjXqstfHynytriLWZ2eFzthTrq+Rp/79SRZDrU5zHHrOUyuS/vEh1xjWjcpaG869kvUHA6yVOrcmA49aLvT8GoQ4KX2nuj0Tgps+zTsAAuDf6Cp8FA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gQtknX+N/cRrANAkerY/QVfgPnRzkwGieN0itypLPHw=; b=I4Q1gJs6oFnmJhYeMnDU8YgWNfzMKWJV2nSisvPHKF9RbivWcTx+mlE85F0aJj5ax7/h8DRFDFQiimYzn9OwG4bYrzBolcu1aqRomLwem0Q/tH5s1CZRVKucZMluPUMouCSMjRkV1lNzE3HepK2If6kZQ4K02k60XkflbZ59kk8ug9AxWwR9FIQTizfpkwYwujNaJWcPhIk5FG6KHdEjApn/G0bq2h64xEEaUY2KFWeaLcG7IKbtb6T6yBiZZZgHTzz0uh0voWBuepaO0RzYBUY4enl0PAcrD+4IP/qdoQ5ZSQ4P8K2zluWH5PuKSKliFj9u3KlcPrhtJP4DX/0e1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gQtknX+N/cRrANAkerY/QVfgPnRzkwGieN0itypLPHw=; b=PaU2KH/D39gjPhN20R5Dk+5c23ltkqXs02PzPkpn6g7J11gsidBJvt8BnsILYUJ7leSJbnpbrowhm2MZq27QPSEvcDy6Ckyc+JNT89ZBe51EUbLvc2ZCwvlkRSTutb8YKbyuk7kenn0BfSBZ7bc/uCVwaDWGOmYDtzhqWNSdoEQ= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4045.namprd11.prod.outlook.com (20.179.149.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Sat, 16 Nov 2019 12:59:58 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.029; Sat, 16 Nov 2019 12:59:58 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok , Jan-Frederik Rieckers CC: "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPeAysQlGUpTU6o3aUNy73n/aeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAOEToIAAkv4AgACQzoCABgY2YA== Date: Sat, 16 Nov 2019 12:59:58 +0000 Message-ID: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com> In-Reply-To: <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0c8:1007::a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a90af088-7dcb-4179-7196-08d76a94e284 x-ms-traffictypediagnostic: MN2PR11MB4045: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(199004)(189003)(13464003)(52536014)(46003)(5660300002)(8936002)(55016002)(6246003)(81166006)(81156014)(71190400001)(71200400001)(14454004)(7736002)(305945005)(74316002)(25786009)(6116002)(186003)(478600001)(102836004)(9686003)(229853002)(6436002)(4326008)(256004)(66574012)(76176011)(110136005)(316002)(64756008)(476003)(66446008)(7696005)(66476007)(53546011)(6506007)(8676002)(99286004)(2906002)(86362001)(66556008)(76116006)(486006)(11346002)(66946007)(446003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4045; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iGV3Zf740100gzZbERSJlCvSpb3W4USGPDIn5EqhtQHLveaYkqsmr7o7SKbq0KR+LvzHIpz+w22bBscI5mGAMmz8/gEuDbglkmvmnJL3qRIsunirGRbgp3lRf7pUocIE4kMBV1/4gyKZwhfLYwh3ZdqoZEgOwVTaSS6chaQxKGuLT1WtAeZNrFlnhzpNZZzcefvSwWfgIhY6FGuaQHJzCmM6YGXKwUYo//xzW7P2X/wsdTtvblNgVD+fWuJweNrzBMBPUNSfmJxzYZCLF6+AbCkVymzT1Og+SXYd6DQWapTsR3r/a/pUjKrbpIbxkjcS416uqOT1Ia9AdUJnLDXm+dQJHTj6nLn539PPY5dX4s28qLqYx9UMVQ0pfu6N2Xrt0PghDipS3tGFp+JDG9FPZsn13UivngFVKdwZjzNsQ355DWIxr5AaG9OhjvKfih3L x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a90af088-7dcb-4179-7196-08d76a94e284 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2019 12:59:58.3029 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wCb3iRA0xoin1I1QNzU4h7Dnum2SlGOGe7JJLwJTy7RsIH6/49MD1gNn/QPTbvGvFbcsGWQXKp52pQzgybQOxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4045 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 16 Nov 2019 13:00:12 -0000 -----Original Message----- From: Emu On Behalf Of Alan DeKok Sent: 12 November 2019 16:32 To: Jan-Frederik Rieckers Cc: emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS >=20 > The Problem with dNSNames is that they are also used in other contexts=20 > (mainly HTTPS). They're also domain names, not realms. A particular certificate may be v= alid for authenticating uses to the realm "example.org". That same certifi= cate may not be valid for the main web site for "example.org". This means that domain names are a hint, but not authoritative. Only the= NAIRealm field would be authoritative. i.e. "this certificate really is f= or users authenticating to a realm". > There would be the possibility to define a specific prefix to bind it=20 > to a Realm without having the certificate being valid for the HTTPS=20 > host (e.g. eap-tls.uni-bremen.de for the realm > uni-bremen.de) but I don't see the advantage in that. > This will probably don't really lead to a change in the supplicants=20 > implementations. A common short-hand is for certificates to use the "radius" subdomain. e= .g. "radius.example.org". While not perfect, it's something. [ofriel] this seems like something reasonable, but that's more a general de= ployment recommendation: ensure that the identity/realm of EAP servers is d= ifferent from the identity/domain of webservers within an org. Therefore in= the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert, clien= ts can still distinguish between the two. Users point their Browser clients= point to 'example.org' and wi-fi supplications are configured to look for = 'radius.exampe.org'. The supplicant logic for verifying EAP server identity (assuming it already= knows the root CA and a realm/domain string) could be check for NAIRealm f= irst, then check for id-kp-eapOverLAN, then check for a dnsName. From nobody Sat Nov 16 05:01:37 2019 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 0EB2312013F for ; Sat, 16 Nov 2019 05:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SZcwlqB+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DabpgxAX 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 pYkP-JPXtpkL for ; Sat, 16 Nov 2019 05:01:34 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25FF12006D for ; Sat, 16 Nov 2019 05:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5514; q=dns/txt; s=iport; t=1573909293; x=1575118893; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WImCaJzqi6B8d3HcLhPiHdU1a5zJA9BTZaI9ceb5SOQ=; b=SZcwlqB+zxtfuX0D7Li66npveWG4v/AxN+WBADjjY6kdkWf2Na0fKWoJ fFgGfQz2e03TuCvJzmWVHBS5TeCAWnGljPe7AdVhogrGM/WD3x5LAb4gg RjXqbxYIW+miMTfXaLMVAHQ98aEP/j807wkpRAbj01bUhTFLGldtyd4dX A=; IronPort-PHdr: =?us-ascii?q?9a23=3ALq/41BzEYNNCblnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuCB1f6IfrCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAACH8s9d/4ENJK1PDQkaAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQERAQEBAgIBAQEBgWsEAQEBAQsBgUpQBWxYIAQLKoQpg0YDinM?= =?us-ascii?q?aNIIQlRuCZYEuFIEQA1QJAQEBDAEBGAsKAgEBhEACF4IMJDUIDgIDCwEBBAE?= =?us-ascii?q?BAQIBBQRthTcMhVEBAQEBAQEBAQEQEQ4DDAEBLAwEBwQCAQgRBAEBAQICDxc?= =?us-ascii?q?CAgIlCxUICAIEARIIGoMBNIISAw4gAQIMpCkCgTiIYHWBMoE7FIEvAQEFgTV?= =?us-ascii?q?RA4MMGIIXAwaBDigBjBQYgUA/gRFGgh4uPoF5aQEBAYEdBwkBCAoBIRWCeTK?= =?us-ascii?q?CLJAThWuYLwqCKocahSaJKpoRjkiIOJFQAgQCBAUCDgEBBYFUAjVEI3FwFTu?= =?us-ascii?q?CbFARFFeQQwcFF4NQhRSFP3QBARGBFY1tgjEBAQ?= X-IronPort-AV: E=Sophos;i="5.68,312,1569283200"; d="scan'208";a="371852913" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2019 13:01:30 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xAGD1UFN019514 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Nov 2019 13:01:30 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 07:01:30 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 07:01:29 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 16 Nov 2019 07:01:29 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nUp9COsSgl+GUDj2HSadinsJEvcfEynfMNmYoDjNufr+yu9xKALVzFflEXFCBQw4PppZZz5u5+MX0fDvlFdTkJD4nTSUOusP+3EOXdopf2BiCS0sSnvcyGTNBb7CcbWNCniR44FgwKAApDwFZVfB/7IGMKwN3RwXV+UHsncrRFYdifyyZ9xL2V7f+EuH6a04DGE6qGXWMe85XrP44ViOYxe6a1Mzneg/ulC9ZLxcBu4bBVwRm5Gg44TeFLtSK1lvTsnz5XNE+L550GdGK+dAK1dbrkAxMkWi1+/++MIB9ST5v3iCKeGjrfTdZCY0NzHRwU5PnuO1hGJLhfI4Y5uq0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WImCaJzqi6B8d3HcLhPiHdU1a5zJA9BTZaI9ceb5SOQ=; b=e9BQySXK53apTPVNTz/ZN6x6f2QWflROqPVml38POUJI99cfYRrWA75uKhXas/FDUKXoxV74HeecbThnlKFTgjM003ui0er9DqKgK6ZhsD/zbOqP8Jud6GhTFePoTUiSSpyQrsl6Y+YLBpfoKjUiS9bfBp4IuMoDeEfPymb5jfmw5fkNAe9M9MMMHAP0JbNmCSf0Xn/nxeNMy/Sod78BlsS5yDrnYrgSWHLfk1npaWKZB0HFJvo421DIMUXgsqzKQV3M+CKQcnQ042J3ruy5PVGmuAKYKDyugEwpsHKBKM0oM+Fq0nohhXZgUT7CAPez3x8wJo1hcHLTqmFRAwo5kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WImCaJzqi6B8d3HcLhPiHdU1a5zJA9BTZaI9ceb5SOQ=; b=DabpgxAX9uk8q6MlhsRNJtJ+yw2Gf0YZfIdn8kyw6W4+B+sbgkulkD8VM8TUVAI3LUQRJV4BrL/5hWvQd4lPwepynVdGc8gjrTo5hz/TTGjIT+TpMNnnbVXFGD6GFck3WkbaKrdmZ31Vfo+CmX6hdXmtqmei21KA2oQbaU8I3L0= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4045.namprd11.prod.outlook.com (20.179.149.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Sat, 16 Nov 2019 13:01:27 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.029; Sat, 16 Nov 2019 13:01:27 +0000 From: "Owen Friel (ofriel)" To: Michael Richardson , "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPeAysQlGUpTU6o3aUNy73n/aeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAOEToIAAkv4AgACT34CAADkvgIAAAZkAgAA55gCAAY6AgIAEAtkg Date: Sat, 16 Nov 2019 13:01:27 +0000 Message-ID: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0c8:1007::a3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 724578fc-dfc9-48c8-e9d4-08d76a9517c0 x-ms-traffictypediagnostic: MN2PR11MB4045: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(51444003)(199004)(189003)(13464003)(52536014)(46003)(5660300002)(8936002)(55016002)(6246003)(81166006)(81156014)(71190400001)(71200400001)(14454004)(7736002)(305945005)(74316002)(4001150100001)(25786009)(6116002)(186003)(478600001)(102836004)(9686003)(14444005)(229853002)(6436002)(2501003)(256004)(66574012)(76176011)(110136005)(316002)(64756008)(476003)(66446008)(7696005)(66476007)(53546011)(6506007)(8676002)(99286004)(2906002)(86362001)(66556008)(966005)(76116006)(6306002)(486006)(11346002)(66946007)(446003)(33656002)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4045; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qi5KnU09RjRBww+joavNrN5e6OzXyI8BJGs+MQNBe+DYfpyMXTB2cpnT9ssxFdkfnc4FkB3Rn874KT15HMRp0YSqKJcCdHB+4aBo1VAWy9s+AzvooE74+yHIOLDDui9w277V42WBVrjV/gl3IGSeqBWJbYn95mVk2/xEP4HcVtyLY+jj2+g5auSw7zDsfuACv3tRzslIy0EpajipmkniVBudthdgkl9Ojfcs94UihNSd+XzCoIS/XgewwCOY67Qi3t7A9Bs0d2jfTOxNPqTIZvkTScF8Gbd5y0NeGQlgB/qWC9xFsp19CuFAisGsofYBpHh4qZVbvg8GQx/rs9wGJrYU2OxhEwmtjkJYH2oIdIBGFZGklVy/dbeBkNqeE5DesO9j/69FXceJ3Lj4vBLqHqXNfateEp7yVq66HJnYOv9PV64iqCqhiRG4U5FmshpT x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 724578fc-dfc9-48c8-e9d4-08d76a9517c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2019 13:01:27.7004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i2uUM58O6zfMn5pj4JHJhgbwdxFtnIv1GcaMDEjIgOJj4nBil/IrF/HERedTKWCBSdVvnjmpvaxa5TlScP9kqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4045 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 16 Nov 2019 13:01:36 -0000 VGhlIENBL0Jyb3dzZXIgZm9ydW0gaGFzIGNvbmNyZXRlIGd1aWRlbGluZXMgb24gYWRkcmVzcywg ZW1haWwsIGRvbWFpbiB2ZXJpZmljYXRpb24gb3V0bGluZWQgaGVyZS4NCg0KaHR0cHM6Ly9jYWJm b3J1bS5vcmcvd3AtY29udGVudC91cGxvYWRzL0NBLUJyb3dzZXItRm9ydW0tQlItMS42LjYucGRm DQoNCkFsbCBwdWJsaWMgQ0FzIHNob3VsZCBmb2xsb3cgdGhlc2UsIG9yIGZhY2UgYmxhY2tsaXN0 aW5nLiBDQXMgZG9u4oCZdCB3YW50IHRvIHJpc2sgYmVpbmcgdGhlIG5leHQgU3ltYW50ZWMuDQoN CiIgMy4yLjIuMS4gSWRlbnRpdHkNCiBJZiB0aGUgU3ViamVjdCBJZGVudGl0eSBJbmZvcm1hdGlv biBpcyB0byBpbmNsdWRlIHRoZSBuYW1lIG9yIGFkZHJlc3Mgb2YgYW4gb3JnYW5pemF0aW9uLCB0 aGUgQ0EgU0hBTEwgdmVyaWZ5IHRoZSBpZGVudGl0eSBhbmQgYWRkcmVzcyBvZiB0aGUgb3JnYW5p emF0aW9uIGFuZCB0aGF0IHRoZSBhZGRyZXNzIGlzIHRoZSBBcHBsaWNhbnTigJlzIGFkZHJlc3Mg b2YgZXhpc3RlbmNlIG9yIG9wZXJhdGlvbi4gVGhlIENBIFNIQUxMIHZlcmlmeSB0aGUgaWRlbnRp dHkgYW5kIGFkZHJlc3Mgb2YgdGhlIEFwcGxpY2FudCB1c2luZyBkb2N1bWVudGF0aW9uIHByb3Zp ZGVkIGJ5LCBvciB0aHJvdWdoIGNvbW11bmljYXRpb24gd2l0aCwgYXQgbGVhc3Qgb25lIG9mIHRo ZSBmb2xsb3dpbmc6DQoxLiBBIGdvdmVybm1lbnQgYWdlbmN5IGluIHRoZSBqdXJpc2RpY3Rpb24g b2YgdGhlIEFwcGxpY2FudOKAmXMgbGVnYWwgY3JlYXRpb24sIGV4aXN0ZW5jZSwgb3IgcmVjb2du aXRpb247DQoyLiBBIHRoaXJkIHBhcnR5IGRhdGFiYXNlIHRoYXQgaXMgcGVyaW9kaWNhbGx5IHVw ZGF0ZWQgYW5kIGNvbnNpZGVyZWQgYSBSZWxpYWJsZSBEYXRhIFNvdXJjZTsNCjMuIEEgc2l0ZSB2 aXNpdCBieSB0aGUgQ0Egb3IgYSB0aGlyZCBwYXJ0eSB3aG8gaXMgYWN0aW5nIGFzIGFuIGFnZW50 IGZvciB0aGUgQ0E7IG9yDQo0LiBBbiBBdHRlc3RhdGlvbiBMZXR0ZXIuDQpUaGUgQ0EgTUFZIHVz ZSB0aGUgc2FtZSBkb2N1bWVudGF0aW9uIG9yIGNvbW11bmljYXRpb24gZGVzY3JpYmVkIGluIDEg dGhyb3VnaCA0IGFib3ZlIHRvIHZlcmlmeSBib3RoIHRoZSBBcHBsaWNhbnTigJlzIGlkZW50aXR5 IGFuZCBhZGRyZXNzLg0KQWx0ZXJuYXRpdmVseSwgdGhlIENBIE1BWSB2ZXJpZnkgdGhlIGFkZHJl c3Mgb2YgdGhlIEFwcGxpY2FudCAoYnV0IG5vdCB0aGUgaWRlbnRpdHkgb2YgdGhlIEFwcGxpY2Fu dCkgdXNpbmcgYSB1dGlsaXR5IGJpbGwsIGJhbmsgc3RhdGVtZW50LCBjcmVkaXQgY2FyZCBzdGF0 ZW1lbnQsIGdvdmVybm1lbnQtaXNzdWVkIHRheCBkb2N1bWVudCwgb3Igb3RoZXIgZm9ybSBvZiBp ZGVudGlmaWNhdGlvbiB0aGF0IHRoZSBDQSBkZXRlcm1pbmVzIHRvIGJlIHJlbGlhYmxlLiAiDQoN CiIgMy4yLjIuMy4gVmVyaWZpY2F0aW9uIG9mIENvdW50cnkNCklmIHRoZSBzdWJqZWN0OmNvdW50 cnlOYW1lIGZpZWxkIGlzIHByZXNlbnQsIHRoZW4gdGhlIENBIFNIQUxMIHZlcmlmeSB0aGUgY291 bnRyeSBhc3NvY2lhdGVkIHdpdGggdGhlIFN1YmplY3QgdXNpbmcgb25lIG9mIHRoZSBmb2xsb3dp bmc6IChhKSB0aGUgSVAgQWRkcmVzcyByYW5nZSBhc3NpZ25tZW50IGJ5IGNvdW50cnkgZm9yIGVp dGhlciAoaSkgdGhlIHdlYiBzaXRl4oCZcyBJUCBhZGRyZXNzLCBhcyBpbmRpY2F0ZWQgYnkgdGhl IEROUyByZWNvcmQgZm9yIHRoZSB3ZWIgc2l0ZSBvciAoaWkpIHRoZSBBcHBsaWNhbnTigJlzIElQ IGFkZHJlc3M7IChiKSB0aGUgY2NUTEQgb2YgdGhlIHJlcXVlc3RlZCBEb21haW4gTmFtZTsgKGMp IGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBEb21haW4gTmFtZSBSZWdpc3RyYXI7IG9yIChk KSBhIG1ldGhvZCBpZGVudGlmaWVkIGluIFNlY3Rpb24gMy4yLjIuMS4gVGhlIENBIFNIT1VMRCBp bXBsZW1lbnQgYSBwcm9jZXNzIHRvIHNjcmVlbiBwcm94eSBzZXJ2ZXJzIGluIG9yZGVyIHRvIHBy ZXZlbnQgcmVsaWFuY2UgdXBvbiBJUCBhZGRyZXNzZXMgYXNzaWduZWQgaW4gY291bnRyaWVzIG90 aGVyIHRoYW4gd2hlcmUgdGhlIEFwcGxpY2FudCBpcyBhY3R1YWxseSBsb2NhdGVkLiAiDQoNClRo ZXJlIGlzIGFsc28gYSBidW5jaCBvZiBzdHVmZiBpbiB0aGVyZSBhYm91dCBlbWFpbHMgaW5jbHVk aW5nOg0KDQoiIDMuMi4yLjQuNCBDb25zdHJ1Y3RlZCBFbWFpbCB0byBEb21haW4gQ29udGFjdA0K Q29uZmlybSB0aGUgQXBwbGljYW50J3MgY29udHJvbCBvdmVyIHRoZSBGUUROIGJ5IChpKSBzZW5k aW5nIGFuIGVtYWlsIHRvIG9uZSBvciBtb3JlIGFkZHJlc3NlcyBjcmVhdGVkIGJ5IHVzaW5nICdh ZG1pbicsICdhZG1pbmlzdHJhdG9yJywgJ3dlYm1hc3RlcicsICdob3N0bWFzdGVyJywgb3IgJ3Bv c3RtYXN0ZXInIGFzIHRoZSBsb2NhbCBwYXJ0LCBmb2xsb3dlZCBieSB0aGUgYXQtc2lnbiAoIkAi KSwgZm9sbG93ZWQgYnkgYW4gQXV0aG9yaXphdGlvbiBEb21haW4gTmFtZSwgKGlpKSBpbmNsdWRp bmcgYSBSYW5kb20gVmFsdWUgaW4gdGhlIGVtYWlsLCBhbmQgKGlpaSkgcmVjZWl2aW5nIGEgY29u ZmlybWluZyByZXNwb25zZSB1dGlsaXppbmcgdGhlIFJhbmRvbSBWYWx1ZS4gIg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRW11IDxlbXUtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIE1pY2hhZWwgUmljaGFyZHNvbg0KU2VudDogMTMgTm92ZW1iZXIgMjAxOSAyMzoy Nw0KVG86IGVtdUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFbXVdIElkZWE6IE5ldyBYNTA5IEV4 dGVuc2lvbiBmb3Igc2VjdXJpbmcgRUFQLVRMUw0KDQoNCg0KT24gMjAxOS0xMS0xMyA3OjQwIGEu bS4sIEFsYW4gRGVLb2sgd3JvdGU6DQo+IE9uIE5vdiAxMiwgMjAxOSwgYXQgMzoxMyBQTSwgQ2Fw cGFsbGksIFRpbSAoQXJ1YmEpIDx0aW1jQGhwZS5jb20+IHdyb3RlOg0KPj4gSG93IGRvZXMgYSBw dWJsaWMgQ0EgcHJvdmUgb3duZXJzaGlwIG9mIGFuIFNTSUQ/DQo+ICAgRG8gcHVibGljIENBcyAq YWx3YXlzKiB2ZXJpZnkgYWRkcmVzc2VzIGFuZC9vciB0ZWxlcGhvbmUgbnVtYmVycywgd2hpY2gg YXJlIG5vcm1hbGx5IGluY2x1ZGVkIGluIGNlcnRpZmljYXRlcz8NCg0KVGhleSBhcmU/wqAgSSd2 ZSByYXJlbHkgc2VlbiBpdC4NCkkgdGhpbmsgdGhhdCBpZiBpdCdzIGluIHRoZSBjZXJ0aWZpY2F0 ZSwgdGhlbiB0aGV5IGhhdmUgdmVyaWZpZWQgdGhlbS4NCkkgY2FuIHJlbWVtYmVyIGluIHRoZSBi YWQgb2xkIGRheXMgcHJvdmlkaW5nIENBcyB3aXRoIG5vdG9yaXplZCBhcnRpY2xlcyBvZiBpbmNv cnBvcmF0aW9uLCBldGMuDQpJIGhhdmVuJ3QgZG9uZSB0aGF0IHRoaXMgZGVjYWRlIHRob3VnaCwg YW5kIEkgaGF2ZW4ndCBzZWVuIHRoYXQga2luZCBvZiBpbmZvLg0KQ0FzIHdvbid0IGluY2x1ZGUg YW55dGhpbmcgdGhleSBjYW4ndCB2ZXJpZnkuDQoNCj4gICBEbyBwdWJsaWMgQ0FzIHZlcmlmeSB0 aGF0IGVtYWlsIGFkZHJlc3NlcyBpbiB0aGUgY2VydGlmaWNhdGUgd29yaz8NCg0KeWVzLCB0aGV5 IGRvIGJ5IHNlbmRpbmcgYSBjaGFsbGVuZ2UgdG8gaXQuDQo+ICAgRG8gcHVibGljIENBcyB2ZXJp ZnkgdGhhdCB0aGUgT0lEcyBpbiB0aGUgY2VydGlmaWNhdGUgbWF0Y2ggdGhlIGludGVuZGVkIHVz ZS1jYXNlcz8NCg0KTW9zdCB3b24ndCBpbmNsdWRlIE9JRHMuDQo+ICAgSXMgdGhlcmUgYSBnbG9i YWwgcmVnaXN0cnkgb2YgU1NJRHMgd2hpY2ggdGhlIHB1YmxpYyBDQSBjb3VsZCB1c2UgdG8gdmVy aWZ5IHRoZSBTU0lEPw0KDQpObywgU1NJRHMgYXJlIGEgbG9jYWwgbWF0dGVyLg0KT25lIGNvdWxk IChhbmQgSSBkbyksIHVzZSBGUUROcyBhcyB0aGUgU1NJRC4NCg0KVGhhdCdzIHRoZSBvbmx5IHdh eSBJIGNhbiBzZWUgdGhpcyB3b3JraW5nLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRW11IG1haWxpbmcgbGlzdA0KRW11QGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0K From nobody Sat Nov 16 06:36:44 2019 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 3208A120233 for ; Sat, 16 Nov 2019 06:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V72m19bxLu7Q for ; Sat, 16 Nov 2019 06:36:34 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7FF120170 for ; Sat, 16 Nov 2019 06:36:29 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 7BE4F613; Sat, 16 Nov 2019 14:28:37 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Sat, 16 Nov 2019 09:28:35 -0500 Cc: Jan-Frederik Rieckers , "emu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com> To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 16 Nov 2019 14:36:38 -0000 On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) = wrote: > [ofriel] this seems like something reasonable, but that's more a = general deployment recommendation: ensure that the identity/realm of EAP = servers is different from the identity/domain of webservers within an = org. Therefore in the absence of an NAIRealm or id-kp-eapOverLAN = extension in a cert, clients can still distinguish between the two. = Users point their Browser clients point to 'example.org' and wi-fi = supplications are configured to look for 'radius.exampe.org'. >=20 > The supplicant logic for verifying EAP server identity (assuming it = already knows the root CA and a realm/domain string) could be check for = NAIRealm first, then check for id-kp-eapOverLAN, then check for a = dnsName. There is currently no document which offers guidance for implementors. = There's just common practice, and various standards. Which are = unfortunately different. Even worse, it's not clear how these practices = interact, or how we should migrate from existing practice to using the = standards. I think it would be useful for this WG to have a document which gives = these guidelines. Aln DeKok. From nobody Sat Nov 16 06:48:06 2019 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 B12EA120164 for ; Sat, 16 Nov 2019 06:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=nFam95Up; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tEeh8uw0 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 9NajnDV8oW5u for ; Sat, 16 Nov 2019 06:48:01 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C984F12012D for ; Sat, 16 Nov 2019 06:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1628; q=dns/txt; s=iport; t=1573915681; x=1575125281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d52DAYFC++OOkKZku2TfuDuOThO6FJo104K3VE8nEkM=; b=nFam95UpwegGfe2rxtCWHcXT3Se7xcgwdPaZnhweExHFmdne7Jry62Wo 9mm/oRs8GIiFORAwD0+Zi5bYM0ZBIuEfZEYFONt7eRAwBnrCBBSJ8c8pf b7JnpC1FxUxA9xB3IJncUmpHiPF4lK9vEAu/AY/eaaFH2FXd5aiz5qN6A 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AQpSWRBDRmUoL/hMJ+hVfUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAAB7C9Bd/4QNJK1bCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBfoFLUAWBRCAECyoKh2UDinKCXpgAglIDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACgiMkOBMCAwsBAQQBAQECAQUEbYU3DIVRAQEBAQMSKAY?= =?us-ascii?q?BATcBCwQCAQgRBAEBAR4QMh0IAgQOBQgahUcDLgECpCUCgTiIYIIngn4BAQW?= =?us-ascii?q?FHRiCFwmBNowVGIFAP4FXgh4uPoQbFBiDQIIsnyCPDQqCKpVqmhGoUAIEAgQ?= =?us-ascii?q?FAg4BAQWBaSKBWHAVgydQERSRGoNzilN0gSiPDwGBDgEB?= X-IronPort-AV: E=Sophos;i="5.68,312,1569283200"; d="scan'208";a="577996908" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2019 14:47:59 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xAGElxDG007849 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Nov 2019 14:47:59 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 08:47:59 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 08:47:58 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 16 Nov 2019 09:47:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nvjOKBvjcruNiJObFFOrYPbxx8Amdq96dUKf8+CVe6krmGJLIwFWzElNibCk9Vs/AJRL1pNSzem6DGTN/W5f3rrypj5Duuxj730P5awTVv8IcgNnI+hrqzrDRBeksdQGdj12m3XPqOVlKe00DTLdBtXGdfxCiMpyNk721YpM5WJexHEXGbTyUycw5rJ/Z2ahdL7guTHjIVI6XfU0tsQMVZ7dIRcaaOpuFZI25FZSPmJ98hedpiyCRHeRt6sh8PwH/xTCRO4wW9XC/5rRALa75m6G6VVWngmZezSJrd/gfC8P498kdH68WYEhYwUKd0zuDFj5AQxPaSBChSSskHlRtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1vZwOJbmINKiGx2KPNgcrEoVErYOIi+VQHZqbUOsTeQ=; b=VStbzwnWQqUjad/QcsMc+vyY7z3S/VvBNsJPjGSdt2W5e457DWlwjZsvQgrnADBaRe/OOY8ZKKY5ZJtABrXfUv+IsTBsR9srMuTJweRL6t/+8nGELqO7lCuramiemzKrL7XxU1HndbvCvB9A64pvGUkdtGP5QbLK46Egyt1rrtvhjJpi4LFjhkMkeZi3WOo2jYiEQ/gOud9vpJr5TBDRDELZSRHtrQ5r0reoKSMNmXaN/YOjZRfKyRvF6roDF5ORnBOraadwMjD+msE3CdcHzFd12YZa6EFiceRJxK8qIH2BlLP8sdZxDvw6+a7uvHoCnCTnMQLEzQR9mLTGXbwR4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1vZwOJbmINKiGx2KPNgcrEoVErYOIi+VQHZqbUOsTeQ=; b=tEeh8uw045E2vmwiRt8OF1rhlocJ+CXoUdldpX+EEk9xDODBC1M9J2KUnW9dYWldXsLPNfjjRA/wjeEL/82YQ707uwRC9qhDEAuAbi3tAIzOC/1t1aSnzkG+PcflyDik3iEhgbx6kJLBBYf6Rsy6gzQZZUT6rxzB6hPJ44rWcJw= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Sat, 16 Nov 2019 14:47:57 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.029; Sat, 16 Nov 2019 14:47:57 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok CC: Jan-Frederik Rieckers , "emu@ietf.org" Thread-Topic: [Emu] Idea: New X509 Extension for securing EAP-TLS Thread-Index: AQHVlyPeAysQlGUpTU6o3aUNy73n/aeDIL2AgAAfaoCAAVXogIAAcBGAgAC0JoCAAOEToIAAkv4AgACQzoCABgY2YIAAIJ+AgAACwyA= Date: Sat, 16 Nov 2019 14:47:57 +0000 Message-ID: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <58473B30-802F-469A-8967-CE90316974E7@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [38.98.37.142] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac72944a-4029-459a-df36-08d76aa3f84a x-ms-traffictypediagnostic: MN2PR11MB3551: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(396003)(346002)(366004)(13464003)(199004)(189003)(6506007)(74316002)(6436002)(6916009)(26005)(6116002)(11346002)(25786009)(99286004)(446003)(8936002)(9686003)(66066001)(476003)(6246003)(81166006)(81156014)(486006)(55016002)(4326008)(5660300002)(7736002)(86362001)(305945005)(66574012)(14454004)(52536014)(7696005)(76176011)(316002)(2906002)(186003)(8676002)(33656002)(102836004)(71190400001)(71200400001)(256004)(76116006)(229853002)(66556008)(64756008)(66446008)(66476007)(478600001)(66946007)(53546011)(54906003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /aFNdJBs2s9QEOCcITRfyP8NbPst206EpUh2UadZoR+KQCXGxhrfeQpxhMEFkejOFztrs+eReXRQ+Qp4XfmeIm38RLEYfO+yTPBR8UCcSbippb4GNYqBhDGJXwodhkIJkmfvlKmBfTTWNaDRpC/cWjfFZPoyaeJQT/sQF2C8UBIh/Fxbl5JB1KgarQglPGFLQKIuhQHMYbHCL8Dwkd8fXSuCQlEX7BfsO0u9YrwX/GvByZ7S+0D1O6bUiD0+af3Ha0HqFcrxszR011nRnvnucUIfFWVlBwq9W4f+Jd6OvhvAKLwGL0jFLc+MrP9/vu6HD+RU/IEz5vkATKvY/ysiZ1Gm1PcIra1bhDvCzYB3bRrGRoYIxSegf+zW90GN8xnPtbaU7P09mDZUYNus87fZwywY0axqGTZGxpbMMYmFzG6Tt4vcqZ0diTOCPhit8WFK x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac72944a-4029-459a-df36-08d76aa3f84a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2019 14:47:57.2425 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YTJKDCAr4biWljBw7E6AHr8G/OcSGy3izavgPkF04uPT9lx+vOzHCRKEw4KwsnaxtOVdg2wJ31urtJJRRrGrZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3551 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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, 16 Nov 2019 14:48:04 -0000 -----Original Message----- From: Alan DeKok =20 Sent: 16 November 2019 14:29 To: Owen Friel (ofriel) Cc: Jan-Frederik Rieckers ; emu@ietf.org Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel) wrote: > [ofriel] this seems like something reasonable, but that's more a general = deployment recommendation: ensure that the identity/realm of EAP servers is= different from the identity/domain of webservers within an org. Therefore = in the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert, cli= ents can still distinguish between the two. Users point their Browser clien= ts point to 'example.org' and wi-fi supplications are configured to look fo= r 'radius.exampe.org'. >=20 > The supplicant logic for verifying EAP server identity (assuming it alrea= dy knows the root CA and a realm/domain string) could be check for NAIRealm= first, then check for id-kp-eapOverLAN, then check for a dnsName. There is currently no document which offers guidance for implementors. T= here's just common practice, and various standards. Which are unfortunatel= y different. Even worse, it's not clear how these practices interact, or h= ow we should migrate from existing practice to using the standards. I think it would be useful for this WG to have a document which gives the= se guidelines. [ofriel] Happy to help put a strawman for that together, along with some re= commendations for the other PSK ambiguity. Aln DeKok. From nobody Sat Nov 16 14:14:58 2019 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 1E4BE1207FE for ; Sat, 16 Nov 2019 14:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Cbm0vNjI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Yq8i+eaP 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 O-p9Zf-FDi97 for ; Sat, 16 Nov 2019 14:14:55 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E0912011B for ; Sat, 16 Nov 2019 14:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1170; q=dns/txt; s=iport; t=1573942495; x=1575152095; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=twxbIx+yYI83IFnoA8YNmxfwXdITV8iXXcGeoaHXON0=; b=Cbm0vNjInUy2PBr66IB5pig+asnfp7Kg/bduF9WLG+rL9wbEyCIw8ZKh fnLW1zL4y89ba8gx8sYCN52KN5TnGGDkwW2CTf1ncO1TBrpdOaan2Wn8y ARWWV5UijZvwPucXNqW1lX2oqqWud3Xnp2bOKKTw2NXUmx04tlGbuygd8 Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AM5L0rRSGA26ih/RimmVmfczyHNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOis0BsVPUHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdDQCRdNBd/4ENJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BS1AFbFggBAsqhCmDRgOKck6CEJgAglIDVAkBAQEMAQEjCgI?= =?us-ascii?q?BAYRAAheCDCQ4EwIDAQMCAwIBAQQBAQECAQUEbYU3DIVRAQEBAQMSEREMAQE?= =?us-ascii?q?FMwsEAgEIDgMEAQEDAiMDAgICMBQBCAgCBAESCBqDAYJGAy4BAgyjMQKBOIh?= =?us-ascii?q?gdYEygn4BAQUvgQUBAwICg1wYghcDBoEOKIFcijkYgUA/gRFGgkw+gQSBXgI?= =?us-ascii?q?DgWCDDjKCLJATnhoKgiqHGo5Qgj6HaI9rjkiBQYZ3kVACBAIEBQIOAQEFgWk?= =?us-ascii?q?igVhwFRqDDVARFJEag3OFFIU/dIEokBYBAQ?= X-IronPort-AV: E=Sophos;i="5.68,313,1569283200"; d="scan'208";a="381723509" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Nov 2019 22:14:54 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xAGMEsU1032363 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Nov 2019 22:14:54 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 16:14:53 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Nov 2019 17:14:52 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 16 Nov 2019 16:14:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cHfEFiwf15uojNunoaItgHSRcVfht6Ix7Ga7vDiQ5HzybGROXnddGzbZFLdh1w7lT/6raRvsfvlYKR/x55s/bhBwlHls5gBuVZl6OqLDea5IivDM+EFl62qwqWuJg8uJJxIRuSs8e37WnzyyQ+8D9t3IcoPZJBWZQ1L4+LYv8P3+6swnebFmt9vE7TsJDSss7srXa0XaPoJmpIL9W4XXpziWM7Ug29twiYHsjHQ9Crg3/S7IHjdMkRhk3CE9s0LaMjwBjQ+FVPICZQa+/tWx5+sSC8s2GUdQXRO/s81I07qVpzyIlineSTK7n2H0/4b6ThFBUiJmDt562Kzj30Zp9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=twxbIx+yYI83IFnoA8YNmxfwXdITV8iXXcGeoaHXON0=; b=Co2HPxWqf/4/PyOTH/ymMXmcuQ4QwDX76d/uPEcrXCSWKoenzdphHyPKpvCyplf9PLyBwSZP+6PfYIQqiJDTGygN9ztUELrIA71Lq+/qU2fWg8QoY74GKi8l/DWq+RndhFbT8Ms6uo3dvwCj66l/vTw4h/nJkxuKX6+pa1+EG4V0g8D96A9tehiskP4jKZO9JxqH3rvCaRqX4HeLRywm4TMQXdsp11Fa+pB5JZ8Dr8SZI1ZiE9JQnQFWcWhgqx+YseEHbu9L6gfQJ0epkC01Yv1V5vBDuyodaCOe1ruVpy2FklIgxj3W0SBi2LBYgDB5rZuxboV/BDq26OoKbLbIbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=twxbIx+yYI83IFnoA8YNmxfwXdITV8iXXcGeoaHXON0=; b=Yq8i+eaPnzFyOgUSHEr+uaZfOuG+Ptt2zTOEDFZC5lcmeDS6D7PFC/HDQuWgBsf23G4RtQ0Hh1hAJ7l5AQ0NhKNspIbo5+ijBasDgHfK95vW3/i07OPpbrvLwhl1Qs8k26bbn1hWcOqZ5T28vETLXsmBBz5xA6UoBmzD7NALmU0= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4206.namprd11.prod.outlook.com (52.135.36.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.27; Sat, 16 Nov 2019 22:14:52 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.029; Sat, 16 Nov 2019 22:14:52 +0000 From: "Owen Friel (ofriel)" To: Joseph Salowey , EMU WG Thread-Topic: [Emu] Presentations for IETF 106 Thread-Index: AQHVm0ELnnfTxfUNKEKV6/IzN5B7IKeOXw6A Date: Sat, 16 Nov 2019 22:14:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0c8:1004::2be] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9a0cacd-0ecc-4e61-d17c-08d76ae26712 x-ms-traffictypediagnostic: MN2PR11MB4206: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02234DBFF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(396003)(346002)(376002)(39860400002)(13464003)(189003)(199004)(102836004)(6506007)(53546011)(71190400001)(71200400001)(4744005)(6116002)(74316002)(5660300002)(86362001)(186003)(46003)(476003)(2906002)(33656002)(305945005)(486006)(7736002)(316002)(66476007)(66556008)(64756008)(66446008)(52536014)(66946007)(478600001)(110136005)(14454004)(11346002)(446003)(76116006)(99286004)(229853002)(256004)(14444005)(55016002)(9686003)(6306002)(25786009)(81156014)(81166006)(8676002)(7696005)(6246003)(76176011)(6436002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4206; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NttUBp7Lt7PydLfWa17BaBsFsKJOU+KQtPSOxJwdgO9HCscWTfFkpGcus1ldHLNsF35Hs2GDnjQGxV4pkuiP3U/Nl+hGiLSpE2xsDiB78FJDLrcfiFzc/kaJes8rEvzd43BJr6oVuSKuggEJcGZyyG3LJZ3HC0pPxUvESMpMqV0FAuGJ072L+oeVmlIfxiMKzp1ykKjZFv1zEN0CSKwuIHXVBl74Ah0vAVAnGQzUjMipBT69xypGimY7FMbqTigrLK4iCU39joV8AATo3bugjUqx5J8y9EHcV4BWBZsj4VhAEIL8os2H2JLMDU2dExF7TJC+ndOaZsEz8cyQT4hg+Htjo21Tk/OPyQzUOmcWEQWnvqG83f+wPKzONIXdESBqpFHcJSzADGg2BTphlQAPZJ3lAaiIipngZA9UiTsrPdMA30YoC/hzguTrRwmQDMRr x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9a0cacd-0ecc-4e61-d17c-08d76ae26712 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2019 22:14:51.9165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Bb83v3Om8i3RkUELprAuUyL3CSRNSAtPIiq+OSwy0ZtuSNt2xNHY9hfz5sSX1EKXhLiYdEQAq830tyTrb2FD7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4206 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Emu] Presentations for IETF 106 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, 16 Nov 2019 22:14:57 -0000 Sm9lLCBNb2hpdCwNCg0KU29tZXdoYXQgZGlzb3JnYW5pc2VkIGFuZCBsYXRlIHJlcXVlc3Q6IHRo ZXJlIGFwcGVhcnMgdG8gYmUgdGltZSBpbiB0aGUgYWdlbmRhIGF0IHRoZSBlbmQgZm9yIGEgMTAg bWluIHVwZGF0ZSBvbjoNCg0KVGl0bGU6IEFDTUUgSW50ZWdyYXRpb25zDQpEcmFmdHM6IGRyYWZ0 LWZyaWVsLWFjbWUtaW50ZWdyYXRpb25zLCBkcmFmdC1mcmllbC1hY21lLXN1YmRvbWFpbnMNClRp bWU6IDEwIG1pbnV0ZXMNCg0KQ3VycmVudGx5IGRvaW5nIHNsaWRlcyBvbiB0aGUgcGxhbmUuLg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRW11IDxlbXUtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIEpvc2VwaCBTYWxvd2V5DQpTZW50OiAxNCBOb3ZlbWJlciAyMDE5 IDIzOjEyDQpUbzogRU1VIFdHIDxlbXVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRW11XSBQcmVzZW50 YXRpb25zIGZvciBJRVRGIDEwNg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBhZ2VuZGEgWzFdwqBmb3Ig SUVURiAxMDYgaW4gU2luZ2Fwb3JlIHBsZWFzZSBzZW5kIHlvdXIgc2xpZGVzIHRvwqBtYWlsdG86 ZW11LWNoYWlyc0BpZXRmLm9yZyBhcyBzb29uIGFzIHBvc3NpYmxlIGFzIHRoZSBtZWV0aW5nIGlz IG9uIE1vbmRheS7CoCBGYWlsdXJlIHRvIHNlbmQgeW91ciBzbGlkZXMgYmVmb3JlIHRoZSBkYXkg b2YgdGhlIG1lZXRpbmcgbWF5IHJlc3VsdCBpbiB5b3VyIHByZXNlbnRhdGlvbiBiZWluZyBwdXNo ZWQgdG8gdGhlIGVuZCBvZiB0aGUgYWdlbmRhLsKgwqANCg0KWzFdIChodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvMTA2L21hdGVyaWFscy9hZ2VuZGEtMTA2LWVtdS0wMCkNCg== From nobody Sun Nov 17 20:34:37 2019 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 DBC19120848; Sun, 17 Nov 2019 20:34:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <157405166985.24419.8470011931537606841@ietfa.amsl.com> Date: Sun, 17 Nov 2019 20:34:29 -0800 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-06.txt 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: Mon, 18 Nov 2019 04:34:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') Authors : Jari Arkko Vesa Lehtovirta Vesa Torvinen Pasi Eronen Filename : draft-ietf-emu-rfc5448bis-06.txt Pages : 49 Date : 2019-11-17 Abstract: The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the primary authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' is also an algorithm update, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC- SHA-1 as in EAP-AKA. This version of EAP-AKA' specification specifies the protocol behaviour for 5G deployments as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-rfc5448bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc5448bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-rfc5448bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 17 20:35:59 2019 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 8BCB2120096; Sun, 17 Nov 2019 20:35:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: emu@ietf.org Message-ID: <157405175249.24209.13273691303346419754@ietfa.amsl.com> Date: Sun, 17 Nov 2019 20:35:52 -0800 Archived-At: Subject: [Emu] I-D Action: draft-ietf-emu-aka-pfs-02.txt 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: Mon, 18 Nov 2019 04:35:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update WG of the IETF. Title : Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS) Authors : Jari Arkko Karl Norrman Vesa Torvinen Filename : draft-ietf-emu-aka-pfs-02.txt Pages : 26 Date : 2019-11-17 Abstract: Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in [I-D.ietf-emu-rfc5448bis]. The extension, when negotiated, provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'. This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-02 https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 18 06:18:08 2019 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 E4F7912083D for ; Mon, 18 Nov 2019 06:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTx6H-BuW78m for ; Mon, 18 Nov 2019 06:18:04 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C120B1200F5 for ; Mon, 18 Nov 2019 06:18:04 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id BAE10385 for ; Mon, 18 Nov 2019 14:18:02 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> Date: Mon, 18 Nov 2019 09:18:01 -0500 To: EMU WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 14:18:07 -0000 After the meeting earlier today, I made some notes on best practices = for supplicants and authenticators. I think it would be useful to have = an official WG document which gives guidance. Background: a) the current practice in TLS-based EAP methods is to use certificates = with "id-kp-serverAuth" OID set for Extended Key Usage. b) many supplicants check for this OID, and refuse to perform = authentication if it is missing c) supplicants do not check DNS names or any other field in the = certificates d) as a result of this lack of verification, supplicants ship with all = known CAs disabled for TLS-based EAP methods If the supplicants did ship with root CAs enabled, then because of the = lack of validation in (c), the supplicants would hand over user = credentials to any authenticator who has a properly signed certificate. = This is wrong, and is why all of the root CAs are disabled. It would be useful to simplify the user experience when working with = EAP-TLS. It would also be useful to reduce security issues. This is = where a new document is needed. I believe that the standards exist to = support these goals. However, there's a lack of guidance around using = these standard. It would be good to document current practices, and = then give guidance on how to upgrade to better practices. I'll start off describing the end goal, and then discuss how we can = get there. The goal is to have certificates which contain the id-kp-eapOverLAN = OID (RFC 4334), and either the NAIRealm OID (RFC 7585), or a similar one = dedicated to TLS-based EAP authentication. Supplicants can use these = fields to verify that the certificate is both intended to be used for = TLS-based EAP authentication, and that the certificate is for a given = realm. The end user experience *should* be something like: * connect to a system which uses 802.1X authentication (SSID, wired, = etc) * prompt the user for full credentials (user id + realm / password) * validate that the server certificate has the id-kp-eapOverLAN OID set, = AND that the NAIRealm OID matches the user's realm * validate the certificate chain If those validation steps succeed, then the supplicant could send the = users credentials over the EAP method. I think that this extra = validation means that supplicants can trust known root CAs by default. = Which makes the user experience much better. Since the certificates do not currently contain these fields, and = supplicants don't check them, we need an upgrade path. The first step is to suggest that admins generate certificates with = the above fields. This likely means that certificate authorities will = be asked to sign certs with the NAIRealm OID, which they might not do. = This limitation is less of a problem in a roaming federation like = Eduroam, where they are their own CA. The next step is to suggest that supplicant vendors upgrade their = systems to allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in = server certificates. That is a simple change, and shouldn't have any = negative affects. Supplicants can also be upgraded to check the NAIRealm. If the field = does not match the users realm, then the certificate should be rejected. = If the field does match, then the supplicant should validate the = certificate chain. This validation should also include trusting known = root CAs by default. We should also recommend that supplicant vendors check the = id-mod-dns-srv-name-88 and id-mod-dns-srv-name-93 fields of server = certificates. If the domain names there do not match the realm given by = the user, then the user should be warned, and the certificate rejected. If accepted, I think that such practices would tremendously simplify = the use of TLS-based EAP methods for both users and administrators. Alan DeKok. From nobody Mon Nov 18 07:08:09 2019 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 8B93812008B; Mon, 18 Nov 2019 07:08:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, joe@salowey.net, Joseph Salowey , emu-chairs@ietf.org, emu@ietf.org Message-ID: <157408968856.14139.6716727011010048650.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2019 07:08:08 -0800 Archived-At: Subject: [Emu] Publication has been requested for draft-ietf-emu-rfc5448bis-06 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: Mon, 18 Nov 2019 15:08:09 -0000 Joseph Salowey has requested publication of draft-ietf-emu-rfc5448bis-06 as Informational on behalf of the EMU working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ From nobody Mon Nov 18 07:23:15 2019 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 B3958120962 for ; Mon, 18 Nov 2019 07:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCFGDsJRBFi7 for ; Mon, 18 Nov 2019 07:23:11 -0800 (PST) Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86081120961 for ; Mon, 18 Nov 2019 07:23:11 -0800 (PST) Received: from pps.filterd (m0150241.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIFLNta025083; Mon, 18 Nov 2019 15:23:05 GMT Received: from g2t2353.austin.hpe.com (g2t2353.austin.hpe.com [15.233.44.26]) by mx0a-002e3701.pphosted.com with ESMTP id 2wbq38ugcy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 15:23:05 +0000 Received: from G2W6311.americas.hpqcorp.net (g2w6311.austin.hp.com [16.197.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2353.austin.hpe.com (Postfix) with ESMTPS id EB3E996; Mon, 18 Nov 2019 15:23:02 +0000 (UTC) Received: from G9W8670.americas.hpqcorp.net (16.220.49.29) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 15:23:00 +0000 Received: from G9W9210.americas.hpqcorp.net (2002:10dc:429b::10dc:429b) by G9W8670.americas.hpqcorp.net (2002:10dc:311d::10dc:311d) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 15:22:59 +0000 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (15.241.52.10) by G9W9210.americas.hpqcorp.net (16.220.66.155) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 18 Nov 2019 15:23:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b6nh7QjJV2wlTRC9017sjQet4okM6qB1XAX4vKu0j97BnSflEQ6wfd7As8nKM7oYib9Mx4C+EKFTBbznsmfGNMG40TCC+xiqZ6GaPOJ7AK9AEcGzVY39Si2WxLt2/VWQEOswyG/dCWldI5AEgv6EHc//0LOS+v8lO/DHZxaEX5FtAWWJxGwMLLRrOJ2MjXCgvRlADfqKwiDDdB77B9J16cR9kkGp5xfl8nC14V3WEJIvPkKATFowrhkD/C1g+GCCbzxNti7D+2kiTJj5mddJE1n0TFjie705BYgoxardabyJuWqhEokb9t5x8XNalekmzQARAi3vNQS5TqGSsaeRoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JaM9wd5c9JHeACKIoRu8KZK4OraqQ86snQiKPl32Hdw=; b=G33UOz1gC9vIa2OZ0+yGM1EVUORS0CkFOjMz/AkF8WxC8PHdS6hybObLynxbGNuDpv6zv9yK/mzuqzQxygR8/dxfSlmg9JXHFaAUfbpcYzcNyeoiD0zP3/+IUBij7OEDJMUm/tpo1j6he600guai6SV/lDTkkAFyFsDphVo8jrFz8bpRBvrZb7MXa7mPNwl2kSNflgi7vnqcECTxrEI0SP8tMJGXNS/oDAx4NZuLFegO3yb0Y2BCe3ltGoxDCVn4BQaKEtNGqIxPtBxmMUfjkGJ3jYdDl8Kzyb6AcHrOdhy0OwSuTDEj8TerwnCuG7KxVB7O5M9HKgUMVS6BGaP9Ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.9) by AT5PR8401MB0500.NAMPRD84.PROD.OUTLOOK.COM (10.169.2.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 15:22:58 +0000 Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110]) by AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110%11]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 15:22:59 +0000 From: "Cappalli, Tim (Aruba)" To: Alan DeKok , EMU WG Thread-Topic: [Emu] Best practices for supplicants and authenticators Thread-Index: AQHVnhsKV+GRtV0vSkCNpQk4qcIR6KeRC18/ Date: Mon, 18 Nov 2019 15:22:58 +0000 Message-ID: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> In-Reply-To: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:88f7:1621:610c:c87:2f84:f471] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8be77fc3-a9bf-4df7-391b-08d76c3b31c4 x-ms-traffictypediagnostic: AT5PR8401MB0500: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(39860400002)(376002)(136003)(51444003)(199004)(189003)(6116002)(6306002)(81156014)(81166006)(9686003)(256004)(14444005)(5660300002)(33656002)(486006)(7696005)(71190400001)(55016002)(71200400001)(6246003)(476003)(99286004)(76176011)(25786009)(54896002)(76116006)(102836004)(2906002)(6436002)(8936002)(8676002)(66446008)(229853002)(64756008)(6506007)(7736002)(53546011)(66476007)(66556008)(11346002)(236005)(316002)(110136005)(606006)(446003)(14454004)(74316002)(478600001)(52536014)(46003)(86362001)(66946007)(186003)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0500; H:AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IaChIMKdHpF0HZijQtzeVvdFEnF1A4en56zutIvetjYMIQ1KuzbHrGZh1WXNbNWTCAEK4GNQhrN7EIItrCRbpODNbzWPotO8LVkID0fYfhlQsoIh9T2tISB3odsBMnFdS69JdT1CUm9uRjMXZGgUx5UtFfc+RbaRFDsBFsGXO1oD0NusuyGZfz3XSb6C80358pUrzaV2OahdHq97oexX/UoUWMGCUaZ/sOFve1Cz1qy8ouAyf1XF1+Jle0grx7TyKvbVE0p+CseEqQNhCqtymcaBJKIq/uxjRsnTft9ILEtzUMjTIvNGvt8iZiePPNBVDruvv7tHVaYM4tvMMBpVXhQmbYbnn6+a3mnXR+0w6xwCsf/SIa1ZnFU/NJRKdFmLZ5di5MKrheQI7f64ZWXLnqh7Z277h+R4eDwKL5DleMtZzWCS467qYO+4nRhMpFkJ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AT5PR8401MB0530EEE33628E2DB3098C1E6DB4D0AT5PR8401MB0530_" X-MS-Exchange-CrossTenant-Network-Message-Id: 8be77fc3-a9bf-4df7-391b-08d76c3b31c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 15:22:58.8828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H2mbluEbOeKAqhIO343YswUc0pLbZ/hyo2xB2tyWy+K52IGYjLU0Y1vyNC7YjKuQ X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0500 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 4 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_03:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 spamscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 mlxlogscore=813 adultscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180140 Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:23:14 -0000 --_000_AT5PR8401MB0530EEE33628E2DB3098C1E6DB4D0AT5PR8401MB0530_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So again, if NAIRealm is not bound to an organization=92s public domain nam= e, how does a public CA prove ownership of an NAIRealm? How is this differe= nt than ESSID? I don=92t see how this improves assurance of a server identity. tim From: Emu Date: Monday, November 18, 2019 at 9:18 AM To: EMU WG Subject: [Emu] Best practices for supplicants and authenticators After the meeting earlier today, I made some notes on best practices for = supplicants and authenticators. I think it would be useful to have an offi= cial WG document which gives guidance. Background: a) the current practice in TLS-based EAP methods is to use certificates wit= h "id-kp-serverAuth" OID set for Extended Key Usage. b) many supplicants check for this OID, and refuse to perform authenticatio= n if it is missing c) supplicants do not check DNS names or any other field in the certificates d) as a result of this lack of verification, supplicants ship with all know= n CAs disabled for TLS-based EAP methods If the supplicants did ship with root CAs enabled, then because of the la= ck of validation in (c), the supplicants would hand over user credentials t= o any authenticator who has a properly signed certificate. This is wrong, = and is why all of the root CAs are disabled. It would be useful to simplify the user experience when working with EAP-= TLS. It would also be useful to reduce security issues. This is where a n= ew document is needed. I believe that the standards exist to support these= goals. However, there's a lack of guidance around using these standard. = It would be good to document current practices, and then give guidance on h= ow to upgrade to better practices. I'll start off describing the end goal, and then discuss how we can get t= here. The goal is to have certificates which contain the id-kp-eapOverLAN OID (= RFC 4334), and either the NAIRealm OID (RFC 7585), or a similar one dedicat= ed to TLS-based EAP authentication. Supplicants can use these fields to ve= rify that the certificate is both intended to be used for TLS-based EAP aut= hentication, and that the certificate is for a given realm. The end user experience *should* be something like: * connect to a system which uses 802.1X authentication (SSID, wired, etc) * prompt the user for full credentials (user id + realm / password) * validate that the server certificate has the id-kp-eapOverLAN OID set, AN= D that the NAIRealm OID matches the user's realm * validate the certificate chain If those validation steps succeed, then the supplicant could send the use= rs credentials over the EAP method. I think that this extra validation mea= ns that supplicants can trust known root CAs by default. Which makes the u= ser experience much better. Since the certificates do not currently contain these fields, and supplic= ants don't check them, we need an upgrade path. The first step is to suggest that admins generate certificates with the a= bove fields. This likely means that certificate authorities will be asked = to sign certs with the NAIRealm OID, which they might not do. This limitat= ion is less of a problem in a roaming federation like Eduroam, where they a= re their own CA. The next step is to suggest that supplicant vendors upgrade their systems= to allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in server cer= tificates. That is a simple change, and shouldn't have any negative affect= s. Supplicants can also be upgraded to check the NAIRealm. If the field doe= s not match the users realm, then the certificate should be rejected. If t= he field does match, then the supplicant should validate the certificate ch= ain. This validation should also include trusting known root CAs by defaul= t. We should also recommend that supplicant vendors check the id-mod-dns-srv= -name-88 and id-mod-dns-srv-name-93 fields of server certificates. If the = domain names there do not match the realm given by the user, then the user = should be warned, and the certificate rejected. If accepted, I think that such practices would tremendously simplify the = use of TLS-based EAP methods for both users and administrators. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_AT5PR8401MB0530EEE33628E2DB3098C1E6DB4D0AT5PR8401MB0530_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

So again, if NAIRealm is not bound to an organization=92s public domai= n name, how does a public CA prove ownership of an NAIRealm? How is this di= fferent than ESSID?

 

I don=92t see how this improves assurance of a server identity.

 

tim

 

From: Emu <emu-bounces= @ietf.org>
Date: Monday, November 18, 2019 at 9:18 AM
To: EMU WG <emu@ietf.org>
Subject: [Emu] Best practices for supplicants and authenticators

  After the meeting earlier today, I made some = notes on best practices for supplicants and authenticators.  I think i= t would be useful to have an official WG document which gives guidance.

Background:

a) the current practice in TLS-based EAP methods is to use certificates wit= h "id-kp-serverAuth" OID set for Extended Key Usage.
b) many supplicants check for this OID, and refuse to perform authenticatio= n if it is missing
c) supplicants do not check DNS names or any other field in the certificate= s
d) as a result of this lack of verification, supplicants ship with all know= n CAs disabled for TLS-based EAP methods

  If the supplicants did ship with root CAs enabled, then because of t= he lack of validation in (c), the supplicants would hand over user credenti= als to any authenticator who has a properly signed certificate.  This = is wrong, and is why all of the root CAs are disabled.

  It would be useful to simplify the user experience when working with= EAP-TLS.  It would also be useful to reduce security issues.  Th= is is where a new document is needed.  I believe that the standards ex= ist to support these goals.  However, there's a lack of guidance around using these standard.  It would be good to documen= t current practices, and then give guidance on how to upgrade to better pra= ctices.

  I'll start off describing the end goal, and then discuss how we can = get there.

  The goal is to have certificates which contain the id-kp-eapOverLAN = OID (RFC 4334), and either the NAIRealm OID (RFC 7585), or a similar one de= dicated to TLS-based EAP authentication.  Supplicants can use these fi= elds to verify that the certificate is both intended to be used for TLS-based EAP authentication, and that the certifi= cate is for a given realm.

  The end user experience *should* be something like:

* connect to a system which uses 802.1X authentication (SSID, wired, etc) * prompt the user for full credentials (user id + realm / password)
* validate that the server certificate has the id-kp-eapOverLAN OID set, AN= D that the NAIRealm OID matches the user's realm
* validate the certificate chain

  If those validation steps succeed, then the supplicant could send th= e users credentials over the EAP method.  I think that this extra vali= dation means that supplicants can trust known root CAs by default.  Wh= ich makes the user experience much better.

  Since the certificates do not currently contain these fields, and su= pplicants don't check them, we need an upgrade path.

  The first step is to suggest that admins generate certificates with = the above fields.  This likely means that certificate authorities will= be asked to sign certs with the NAIRealm OID, which they might not do.&nbs= p; This limitation is less of a problem in a roaming federation like Eduroam, where they are their own CA.

  The next step is to suggest that supplicant vendors upgrade their sy= stems to allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in serve= r certificates.  That is a simple change, and shouldn't have any negat= ive affects.

  Supplicants can also be upgraded to check the NAIRealm.  If the= field does not match the users realm, then the certificate should be rejec= ted.  If the field does match, then the supplicant should validate the= certificate chain.  This validation should also include trusting known root CAs by default.

  We should also recommend that supplicant vendors check the id-mod-dn= s-srv-name-88 and id-mod-dns-srv-name-93 fields of server certificates.&nbs= p; If the domain names there do not match the realm given by the user, then= the user should be warned, and the certificate rejected.

  If accepted, I think that such practices would tremendously simplify= the use of TLS-based EAP methods for both users and administrators.

  Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/= mailman/listinfo/emu

--_000_AT5PR8401MB0530EEE33628E2DB3098C1E6DB4D0AT5PR8401MB0530_-- From nobody Mon Nov 18 07:30:03 2019 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 5F37F12010D for ; Mon, 18 Nov 2019 07:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-bremen.de 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 ZMCc4IFF2MGP for ; Mon, 18 Nov 2019 07:29:59 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC951200FA for ; Mon, 18 Nov 2019 07:29:59 -0800 (PST) Received: from [134.102.25.84] (eduroam-pool6-0340.wlan.uni-bremen.de [134.102.25.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47GtDj634WzySS for ; Mon, 18 Nov 2019 16:29:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1574090997; bh=zV1tHDRWnHbfTbjGUi5QXN79TGsjHD85Gak4a5e86ss=; h=To:References:From:Date:In-Reply-To; b=HNxhs/Kgm53TCgZV+T6KLoXwfhMRvTrmdKgNsLItsyKpx+2N58deOAsgqQI8QAlx8 1pSAEzRJHClbcrL56o0d8587DGjcjZMgiuO9EoHPUHyFROcvehsq3vTb54nm+kJnSy QheSuS73Ng2UOFwV9g4N9eSh2owEdlez6/92zDlOWk4qU1/+oPb+Oj6MsTA/nw3yic n2v/AjEGIoMeMu3HuCdBisnl3C73t+2yAeDbax1X8F9rPHPQsBcNRtiS1Pjid/h4cp 39XCg6Bx6vzSPlvZEAn6Edj7pDGD9zGs83BpTpGNiC3IOkJul+IRMv9F7kLiL/m04v +wImukpicT6wQ== To: emu@ietf.org References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> From: Jan-Frederik Rieckers Openpgp: preference=signencrypt Message-ID: <82f03924-5099-4818-2d9e-15212b469b95@uni-bremen.de> Date: Mon, 18 Nov 2019 16:29:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K48Yoy9EqkniKiTDRNnMAzICS5lkwokVG" Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:30:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K48Yoy9EqkniKiTDRNnMAzICS5lkwokVG Content-Type: multipart/mixed; boundary="I8EHjDm8sSu6oFr88ek6pxMw3i8jLNXHx"; protected-headers="v1" From: Jan-Frederik Rieckers To: emu@ietf.org Message-ID: <82f03924-5099-4818-2d9e-15212b469b95@uni-bremen.de> Subject: Re: [Emu] Best practices for supplicants and authenticators References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> In-Reply-To: --I8EHjDm8sSu6oFr88ek6pxMw3i8jLNXHx Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 18.11.19 16:22, Cappalli, Tim (Aruba) wrote: > So again, if NAIRealm is not bound to an organization=92s public domain= > name, how does a public CA prove ownership of an NAIRealm? How is this > different than ESSID? It must not be a public domain name, but it can be. Speaking of eduroam this is usually the case, and is also used for roaming. (See RFC7585, the NAPTR DNS record) And if it is, it can be validated by a CA. Janfred --I8EHjDm8sSu6oFr88ek6pxMw3i8jLNXHx-- --K48Yoy9EqkniKiTDRNnMAzICS5lkwokVG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO9n8U/6Yuq3qYHN1UHR7NOiKGm0FAl3SuPUACgkQUHR7NOiK Gm2jOhAAvnE1lRr7Ytdy8wHFMxzaijQWtdOnvVXhoFgj5zarccCXwPXEz09DCtff DdUMTmc9Kgx/PFRS/xiP8DQfBVFi3uRdB2dyfz9QkEwlMS/lDBq41ATOq6IriqOX GJocFg+ha8LSkCEyh/LblelCmVvCpnvGa2pZg22nx4BG/GA67cZ1E2PW8GaSqCxh KqS0seruq9TV25UOP4IM3+eCqqvBlPQYGk/IN3PPZgs1BtKpvOu6V6KfI5WNCMA/ /9mGHK3JTZXaUZAbhoGqI3xVMSJb5zwJBpN1kaIdyYMqWcf/Iz9eyRB5fs/AVPu+ wyl5tJ4RWKwblJ5ap1HaVY+0mDCeTa1Xb2B/Ig/OMxO9+HaY7bWsm7QfVuBEENBg ezFQ2lpzVsHzOnpbarW2djU+J48nyWnxBSdI/idPnh67B3RmtVaoWz+cKP+00Ums wGqNN/TQVYy2uB1KCV16K1fJcBBpprfH4Fvm5hA2YKorQivuZCIRzjvEKKozyYdL AQ/D4bz2DK+MWnfNCB/I1Zacwnuzvzfds0O7HNf0HNGkc0CnhuoucRybdujlERJj gshTEdaT4ItKZ5jmcCxYEeWUh3iC9S17QzLkRjCmtox5n0l+8QmLE1KKLWP9SnVu 1Q3aIwZmQVLGqyBS4CUBObbXRe18RYuV42SL0bE4/ZfcRah58Fk= =LSfU -----END PGP SIGNATURE----- --K48Yoy9EqkniKiTDRNnMAzICS5lkwokVG-- From nobody Mon Nov 18 07:34:50 2019 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 985271209A6 for ; Mon, 18 Nov 2019 07:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaNakniQLOqd for ; Mon, 18 Nov 2019 07:34:43 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360E312098F for ; Mon, 18 Nov 2019 07:34:33 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id E087C1301; Mon, 18 Nov 2019 15:34:30 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 18 Nov 2019 10:34:29 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> To: "Cappalli, Tim (Aruba)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:34:48 -0000 > On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) = wrote: >=20 > So again, if NAIRealm is not bound to an organization=E2=80=99s public = domain name, I never suggested that or implied it. I'm not sure why it's relevant. > how does a public CA prove ownership of an NAIRealm? How is this = different than ESSID? I had hoped that my point was clear. The requirement would be for the NAIReam to be in the same domain as = rest of the certificate. Anything else makes zero sense. i.e. if the certificate is from "example.org", then the NAIRealm = should be "example.org", or any other name within that domain. Such as = "radius.example.org" > I don=E2=80=99t see how this improves assurance of a server identity. No one proposed the position you're opposing, so the conclusion above = is irrelevant. On the other hand, if the requirement is that the NAIRealm be the = domain name, then it makes perfect sense, and it's useful. We can't use existing fields to derive the NAIRealm. The common name = is typically an email address and *not* a domain name. The various DNS = fields are DNS host names (FQDNs), and not domain names. We can = *suggest* that supplicants can check these fields. But it involves = parsing them, and deriving *implicit* meaning from them. In contrast, an NAIRealm field is *explicit* meaning, that doesn't = require additional derivation. I think that explicit statements of intent are useful. I don't see = why there's any controversy about this. Alan DeKok. From nobody Mon Nov 18 07:37:28 2019 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 454D41209EB for ; Mon, 18 Nov 2019 07:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk34HOc5O9Fh for ; Mon, 18 Nov 2019 07:37:22 -0800 (PST) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3275C1209F9 for ; Mon, 18 Nov 2019 07:37:15 -0800 (PST) Received: from pps.filterd (m0150244.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIFSN5t014681; Mon, 18 Nov 2019 15:37:07 GMT Received: from g4t3427.houston.hpe.com (g4t3427.houston.hpe.com [15.241.140.73]) by mx0b-002e3701.pphosted.com with ESMTP id 2wbrs7ttq6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 15:37:07 +0000 Received: from G9W9209.americas.hpqcorp.net (g9w9209.houston.hpecorp.net [16.220.66.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3427.houston.hpe.com (Postfix) with ESMTPS id F29C06F; Mon, 18 Nov 2019 15:37:06 +0000 (UTC) Received: from G9W9210.americas.hpqcorp.net (2002:10dc:429b::10dc:429b) by G9W9209.americas.hpqcorp.net (2002:10dc:429c::10dc:429c) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 15:37:06 +0000 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (15.241.52.11) by G9W9210.americas.hpqcorp.net (16.220.66.155) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 18 Nov 2019 15:37:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b8CRc/EQga6iBUcakGUa8V1s1haTMk+nSntk//ASdanW2fq/uFroQQGPAifzP6/etQlPuI5evB4H4f2I1IPS4QxP3FHFkpwPvwokcvbWm3xHTQC5IVIoQLBnVmXW1GfP3z06O87XwSI3sJ5NOnjdEVnr867GHjLyyC4vSn69ch3hjfXg/LjQfJet2HxovuW9YY7O4CuzBVce89ELpT6P7q/PycVaNlNtxnWC2HeSJZ1iAzWCmheF1SBjvOvFmclsa5lS++f6NJTSDFdyK4S44KpsR8Hja8wD1p2RISQgApPoINKcSjiwyhwx/bdidbsD3Eu6Qhn4U/IWS53cLPMhaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6FYubJ4ax+hryKnodmeSmETsjhnXlc5v/pYX3GNlqzc=; b=b1ofpSNwHWwtSO9hsngyknU2aaSBwL8P45i2lhknL6kQIZQCcuOOUSKbEJ8qBja0l5RHkaEhAEKEhu4UR2Um0kMtTTbTCgv7jn6xknUVgulZq0x6Io0uHA9YYYxNwWLm5bYpppn2V3HgWuc7FABiv34l+ZnDmssdyTwMCKdyBYmVrZ83t2jfNH9SUEtaTJaQCuvgeKDXICh30sEF7t+2op++D0rQ0nDeZdNU3im78fGlbRkwETBsrmDJQy5rQiNuNSJdpXoNQsyOuO5kgncswWVkzcNu5NoJtyLkbIYDL3mscVskBBF579+WhchUr5D6jujwNUzitraDN5PrmSuG0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.9) by AT5PR8401MB0564.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.28; Mon, 18 Nov 2019 15:37:05 +0000 Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110]) by AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110%11]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 15:37:05 +0000 From: "Cappalli, Tim (Aruba)" To: Alan DeKok CC: EMU WG Thread-Topic: [Emu] Best practices for supplicants and authenticators Thread-Index: AQHVnhsKV+GRtV0vSkCNpQk4qcIR6KeRC18/gAADwICAAABZaw== Date: Mon, 18 Nov 2019 15:37:05 +0000 Message-ID: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:88f7:1621:610c:c87:2f84:f471] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 303e0526-6989-4165-d102-08d76c3d2a6c x-ms-traffictypediagnostic: AT5PR8401MB0564: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(376002)(366004)(396003)(189003)(199004)(51444003)(102836004)(64756008)(66476007)(46003)(476003)(316002)(11346002)(4326008)(486006)(446003)(7736002)(33656002)(74316002)(229853002)(81156014)(7696005)(81166006)(5660300002)(76176011)(8676002)(478600001)(86362001)(256004)(8936002)(186003)(6246003)(6436002)(14454004)(25786009)(6116002)(52536014)(99286004)(66946007)(55016002)(53546011)(66556008)(66446008)(6506007)(71200400001)(54896002)(6306002)(76116006)(71190400001)(2906002)(91956017)(6916009)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0564; H:AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oXN9o0tHKy93s0edmpoD/LnLG/TXftFtJAr4Fdz+k1NXtv61EetwbpwEcuD4VIUvauXMNV0CPopDvQzz/GYXEq6qD3TzGXlZ/nwzgyfvseI8TExcUSsvKdphpsjKsfgnZEwV1L7NZyuLbu3VFhtGEsAqLdmC2N8EBS4VFrtLBIjuhy7NxwNSNQI0YSZNlL3SO8SxX4o5kl5gtsJazUFUIiXd5c1gE4bkbJWGZk3orxU1TuuWw339udXILHbCqpTamSQu75TqDY1O4dPoO2sZAW/NAa3e4f2TbeL+EQZtBdPn3hODlKDQoziB4AYUb9jckhQQKQ/LQ9ypmFGN/EBirzePg+ylr3k7VEohiQaQS4aWiVkj5DNzNS4ZkffXAGIIKr6lxiblJvXczw1exuNyV5g4aKd0xBJKNdOe3Nuv6it+5D4ebR9hScl9gNo5nA+D x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AT5PR8401MB05309AD8F339DF5B6BD2E993DB4D0AT5PR8401MB0530_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 303e0526-6989-4165-d102-08d76c3d2a6c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 15:37:05.6194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XE5spkItVe8uyItZct6KS9tFQ1qVURAeJsF0JnTJZbYGYVjUB4sASNVef1tjNmJe X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0564 X-OriginatorOrg: hpe.com X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_04:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 mlxscore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 suspectscore=0 adultscore=0 impostorscore=0 mlxlogscore=316 malwarescore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180141 Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:37:26 -0000 --_000_AT5PR8401MB05309AD8F339DF5B6BD2E993DB4D0AT5PR8401MB0530_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the goal is not to improve identity assurance of an EAP server then what= is this best practice change actually for? From: Alan DeKok Date: Monday, November 18, 2019 at 10:34 AM To: Cappalli, Tim (Aruba) Cc: EMU WG Subject: Re: [Emu] Best practices for supplicants and authenticators > On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) wrote: > > So again, if NAIRealm is not bound to an organization=92s public domain n= ame, I never suggested that or implied it. I'm not sure why it's relevant. > how does a public CA prove ownership of an NAIRealm? How is this differen= t than ESSID? I had hoped that my point was clear. The requirement would be for the NAIReam to be in the same domain as rest= of the certificate. Anything else makes zero sense. i.e. if the certificate is from "example.org", then the NAIRealm should b= e "example.org", or any other name within that domain. Such as "radius.exa= mple.org" > I don=92t see how this improves assurance of a server identity. No one proposed the position you're opposing, so the conclusion above is = irrelevant. On the other hand, if the requirement is that the NAIRealm be the domain = name, then it makes perfect sense, and it's useful. We can't use existing fields to derive the NAIRealm. The common name is = typically an email address and *not* a domain name. The various DNS field= s are DNS host names (FQDNs), and not domain names. We can *suggest* that = supplicants can check these fields. But it involves parsing them, and deri= ving *implicit* meaning from them. In contrast, an NAIRealm field is *explicit* meaning, that doesn't requir= e additional derivation. I think that explicit statements of intent are useful. I don't see why t= here's any controversy about this. Alan DeKok. --_000_AT5PR8401MB05309AD8F339DF5B6BD2E993DB4D0AT5PR8401MB0530_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

If the goal is not to improve identity assurance of an EAP server then= what is this best practice change actually for?

 

 

 

From: Alan DeKok <alan= d@deployingradius.com>
Date: Monday, November 18, 2019 at 10:34 AM
To: Cappalli, Tim (Aruba) <timc@hpe.com>
Cc: EMU WG <emu@ietf.org>
Subject: Re: [Emu] Best practices for supplicants and authenticators=



> On Nov 18, 2019, at 10:22 AM, Cappalli, Tim (Aruba) <timc@hpe.com&g= t; wrote:
>
> So again, if NAIRealm is not bound to an organization=92s public domai= n name,

  I never suggested that or implied it.  I'm not sure why it's re= levant.

> how does a public CA prove ownership of an NAIRealm? How is this diffe= rent than ESSID?

  I had hoped that my point was clear.

  The requirement would be for the NAIReam to be in the same domain as= rest of the certificate.  Anything else makes zero sense.

  i.e. if the certificate is from "example.org", then the NA= IRealm should be "example.org", or any other name within that dom= ain.  Such as "radius.example.org"

> I don=92t see how this improves assurance of a server identity.

  No one proposed the position you're opposing, so the conclusion abov= e is irrelevant.

  On the other hand, if the requirement is that the NAIRealm be the do= main name, then it makes perfect sense, and it's useful.

  We can't use existing fields to derive the NAIRealm.  The commo= n name is typically an email address and *not* a domain name.   T= he various DNS fields are DNS host names (FQDNs), and not domain names.&nbs= p; We can *suggest* that supplicants can check these fields.  But it involves parsing them, and deriving *implicit* meaning from them.
  In contrast, an NAIRealm field is *explicit* meaning, that doesn't r= equire additional derivation.

  I think that explicit statements of intent are useful.  I don't= see why there's any controversy about this.

  Alan DeKok.

--_000_AT5PR8401MB05309AD8F339DF5B6BD2E993DB4D0AT5PR8401MB0530_-- From nobody Mon Nov 18 07:43:37 2019 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 44418120A35 for ; Mon, 18 Nov 2019 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrs1t3vKpYiO for ; Mon, 18 Nov 2019 07:43:34 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B7C120A4F for ; Mon, 18 Nov 2019 07:43:32 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id ABFE0B3F; Mon, 18 Nov 2019 15:43:30 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 18 Nov 2019 10:43:29 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <4D4ACE1D-B565-4AB2-87B8-FD8362A0E76F@deployingradius.com> References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> To: "Cappalli, Tim (Aruba)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:43:36 -0000 On Nov 18, 2019, at 10:37 AM, Cappalli, Tim (Aruba) = wrote: >=20 > If the goal is not to improve identity assurance of an EAP server then = what is this best practice change actually for? I have been *explicit* in my statements that my goal *is* to improve = validation of the EAP server identity. I have no idea how anyone could = interpret those statements as meaning the opposite of their clear = intent. So I have no idea what you're getting at. Please explain yourself = using something *other* than a leading question which gets everything = wrong. i.e. state a position and defend it. Attacking a straw man version of = someone else's position is unhelpful. Alan DeKok. From nobody Mon Nov 18 07:47:19 2019 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 4B93712098F for ; Mon, 18 Nov 2019 07:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elJwtDWTqUJO for ; Mon, 18 Nov 2019 07:47:16 -0800 (PST) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A70120987 for ; Mon, 18 Nov 2019 07:47:16 -0800 (PST) Received: from pps.filterd (m0134424.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIFk1Fq000607; Mon, 18 Nov 2019 15:47:10 GMT Received: from g4t3426.houston.hpe.com (g4t3426.houston.hpe.com [15.241.140.75]) by mx0b-002e3701.pphosted.com with ESMTP id 2wbsj92bws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 15:47:10 +0000 Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3426.houston.hpe.com (Postfix) with ESMTPS id D72F269; Mon, 18 Nov 2019 15:47:09 +0000 (UTC) Received: from G4W9333.americas.hpqcorp.net (16.208.32.119) by G1W8106.americas.hpqcorp.net (16.193.72.61) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 15:47:06 +0000 Received: from G4W10205.americas.hpqcorp.net (2002:10cf:520f::10cf:520f) by G4W9333.americas.hpqcorp.net (2002:10d0:2077::10d0:2077) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 15:47:06 +0000 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (15.241.52.12) by G4W10205.americas.hpqcorp.net (16.207.82.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 18 Nov 2019 15:47:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlBgiHOfArk8Gcx4wGDkPqV1/Ug89N2N0z1gNuP9BCiXoIM4eZQZS/hkCR7gXgyczd0VUL00PX2qxNXcAddw4UCTRTFf6sRZG3pyhUeU3fzk6TACUG4f+/kYAdQkynfuL0DiRlw4l1lfo0PNmq42YfXs3H/vzMNCBEEWBXB17iEirzXs+IjP5s25tLUEEwvYRgV/m7ecleVt5JLwRdfaRf0PUzrCuZSvrj7Xqtn3hqwbbvCvE229iS1ang+cC32qFLrajLukOFkiSXcoZR7eprQ7jO9SD2c/uAPVSadHPBRQOjZma/8ZU4uYvdQrcVwyu3B4lVxuoecKmaTm6wdfnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QES/9H1VfDqJPIBAfAELI5luveL4uI2WrqQ6LVtJuOE=; b=Zf/yqZy8zx/yPyAEMCXTuOkP/6JhJYiosxySH0tDnJ64nUEmbvkSbG1Y1rFOkQSaDX1zBnNVnpqdHUuBPkT/1KS0l4NHtTdRseEfY46uE6lytMlglfvBjzIfmJdBvciPp5TMTPk9PC0D3Cv5I7tSQCh1zWoQ7ddUp2qCCpF03VrcbJleu5sOqjPjBO08gT1RIzmO3a1063qB87swmhZFtp0A+ZDxe/MKrZcPEnUTKCpWrjRL+ctAyLyCszqDZ4LH8owI1cw1fHjDcIRkT2UGtOwh1+UrL/ONOiZxLZkIz+gMFh4XQ3T7m63PIj9wsDN6MAtvNBEwbZK0G7JIqaIM3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.9) by AT5PR8401MB0834.NAMPRD84.PROD.OUTLOOK.COM (10.169.6.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.28; Mon, 18 Nov 2019 15:47:05 +0000 Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110]) by AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110%11]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 15:47:05 +0000 From: "Cappalli, Tim (Aruba)" To: Alan DeKok CC: EMU WG Thread-Topic: [Emu] Best practices for supplicants and authenticators Thread-Index: AQHVnhsKV+GRtV0vSkCNpQk4qcIR6KeRC18/gAADwICAAABZa4AAAiqAgAAALDA= Date: Mon, 18 Nov 2019 15:47:05 +0000 Message-ID: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> , <4D4ACE1D-B565-4AB2-87B8-FD8362A0E76F@deployingradius.com> In-Reply-To: <4D4ACE1D-B565-4AB2-87B8-FD8362A0E76F@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:88f7:1621:610c:c87:2f84:f471] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0458a54c-4ba4-4d4d-0a11-08d76c3e8ff9 x-ms-traffictypediagnostic: AT5PR8401MB0834: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(39860400002)(376002)(366004)(346002)(199004)(189003)(102836004)(316002)(486006)(5660300002)(229853002)(186003)(76116006)(8936002)(6436002)(52536014)(71200400001)(2906002)(33656002)(476003)(55016002)(6306002)(71190400001)(6116002)(54896002)(25786009)(9686003)(74316002)(6246003)(7696005)(7736002)(53546011)(91956017)(256004)(6916009)(14444005)(6506007)(4326008)(99286004)(478600001)(66476007)(46003)(86362001)(81156014)(81166006)(8676002)(11346002)(446003)(14454004)(66556008)(64756008)(66446008)(76176011)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0834; H:AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mn1uVNj77kdCuLYHrn0jNqiFHH2Mp3mlo1rqRHLnc2AU3zAgGr60/MuwL+2d6bGt8zbgAwf6hypCbE0qLDopy0DzNqAgCIygTbcGwDhFpcxKVrFiJZf8XUlUjVMFcUuZZs2cAzS+KohxShb7rcpuRrQYCkAAjCTsLAlQPvhhm43P/aeJQTnGNsTuX0S7KqwvB9cK4u4BBpJmZW/xbGZc8bzYXMlT9HIm/HM9IDYJautma557+3DsW3WRWqkMKbrNnyqqaq4bvuNM+K6VK77CeEFwtLj9QNopHWJ1v9J24pXn5aozAZUQyQEcC/TMiNeTY24Bowe+3qaHte1ob9NhiXkoZfAMQxMcTiud0T+SR3187XtDk5dC9KMox6uG+swKs1lCzoQz/lCR3y1hc4SMSSnOxyq6QG29gFP0S+hDEyHHANASqzQi4ZLyT4fOkMLE x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AT5PR8401MB053007BCE574F9DD75DBF5CDDB4D0AT5PR8401MB0530_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0458a54c-4ba4-4d4d-0a11-08d76c3e8ff9 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 15:47:05.5059 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: anKLjVdZWj4nLXcreswYX8Gr5LpLNsAAW+G7KbcDg9TG1hsgwX/VnEHoD3e9I4UL X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0834 X-OriginatorOrg: hpe.com X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_04:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 lowpriorityscore=0 spamscore=0 adultscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180144 Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:47:18 -0000 --_000_AT5PR8401MB053007BCE574F9DD75DBF5CDDB4D0AT5PR8401MB0530_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alan =96 Adding yet another OID and/or EKU to a certificate does not change= the fact that no authority can attest to that information. A public CA can= not validate a ownership of an NAIRealm. So while a supplicant could be con= figured to validate that the server=92s NAIRealm matches the local configur= ation, that doesn=92t change the requirement to manually configure the supp= licant. So what are we actually trying to improve here? From: Alan DeKok Date: Monday, November 18, 2019 at 10:43 AM To: Cappalli, Tim (Aruba) Cc: EMU WG Subject: Re: [Emu] Best practices for supplicants and authenticators On Nov 18, 2019, at 10:37 AM, Cappalli, Tim (Aruba) wrote: > > If the goal is not to improve identity assurance of an EAP server then wh= at is this best practice change actually for? I have been *explicit* in my statements that my goal *is* to improve vali= dation of the EAP server identity. I have no idea how anyone could interpr= et those statements as meaning the opposite of their clear intent. So I have no idea what you're getting at. Please explain yourself using = something *other* than a leading question which gets everything wrong. i.e. state a position and defend it. Attacking a straw man version of so= meone else's position is unhelpful. Alan DeKok. --_000_AT5PR8401MB053007BCE574F9DD75DBF5CDDB4D0AT5PR8401MB0530_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Alan =96 Adding yet another OID and/or EKU to a certificate does not c= hange the fact that no authority can attest to that information. A public C= A cannot validate a ownership of an NAIRealm. So while a supplicant could be configured to validate that the server=92s NAI= Realm matches the local configuration, that doesn=92t change the requiremen= t to manually configure the supplicant. So what are we actually trying to i= mprove here?

 

From: Alan DeKok <alan= d@deployingradius.com>
Date: Monday, November 18, 2019 at 10:43 AM
To: Cappalli, Tim (Aruba) <timc@hpe.com>
Cc: EMU WG <emu@ietf.org>
Subject: Re: [Emu] Best practices for supplicants and authenticators=

On Nov 18, 2019, at 1= 0:37 AM, Cappalli, Tim (Aruba) <timc@hpe.com> wrote:
>
> If the goal is not to improve identity assurance of an EAP server then= what is this best practice change actually for?

  I have been *explicit* in my statements that my goal *is* to improve= validation of the EAP server identity.  I have no idea how anyone cou= ld interpret those statements as meaning the opposite of their clear intent= .

  So I have no idea what you're getting at.  Please explain yours= elf using something *other* than a leading question which gets everything w= rong.

  i.e. state a position and defend it.  Attacking a straw man ver= sion of someone else's position is unhelpful.

  Alan DeKok.

--_000_AT5PR8401MB053007BCE574F9DD75DBF5CDDB4D0AT5PR8401MB0530_-- From nobody Mon Nov 18 07:57:25 2019 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 0057112099C for ; Mon, 18 Nov 2019 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9cYJOBZMSdZ for ; Mon, 18 Nov 2019 07:57:22 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C4C120994 for ; Mon, 18 Nov 2019 07:57:22 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 043965F1; Mon, 18 Nov 2019 15:57:20 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 18 Nov 2019 10:57:19 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <1DCB7146-EAE5-4450-A690-0783F687DF72@deployingradius.com> References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> <4D4ACE1D-B565-4AB2-87B8-FD8362A0E76F@deployingradius.com> To: "Cappalli, Tim (Aruba)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 15:57:24 -0000 > On Nov 18, 2019, at 10:47 AM, Cappalli, Tim (Aruba) = wrote: >=20 > Alan =E2=80=93 Adding yet another OID and/or EKU to a certificate does = not change the fact that no authority can attest to that information. A = public CA cannot validate a ownership of an NAIRealm.=20 That's not true. Public CAs validate ownership of domain names. The NAIRealm is a = domain name. And, the NAIRealm is the *same* as the domain name in the = certificate. Which the CA validated. Unless you have a counter-argument, that discussion should be closed. > So while a supplicant could be configured to validate that the = server=E2=80=99s NAIRealm matches the local configuration, that = doesn=E2=80=99t change the requirement to manually configure the = supplicant. I explained how it could simplify the supplicants configuration. > So what are we actually trying to improve here? See my previous messages for explanations. Alan DeKok. From nobody Mon Nov 18 08:01:48 2019 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 69C90120A75 for ; Mon, 18 Nov 2019 08:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpEYYQi4Blqc for ; Mon, 18 Nov 2019 08:01:40 -0800 (PST) Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C88120A4E for ; Mon, 18 Nov 2019 08:01:40 -0800 (PST) Received: from pps.filterd (m0134422.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIFwWgR032508; Mon, 18 Nov 2019 16:01:37 GMT Received: from g9t5009.houston.hpe.com (g9t5009.houston.hpe.com [15.241.48.73]) by mx0b-002e3701.pphosted.com with ESMTP id 2wbt54a553-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 16:01:36 +0000 Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5009.houston.hpe.com (Postfix) with ESMTPS id 02DF758; Mon, 18 Nov 2019 16:01:36 +0000 (UTC) Received: from G9W8675.americas.hpqcorp.net (16.220.49.22) by G1W8106.americas.hpqcorp.net (16.193.72.61) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 16:01:35 +0000 Received: from G4W10204.americas.hpqcorp.net (2002:10cf:5210::10cf:5210) by G9W8675.americas.hpqcorp.net (2002:10dc:3116::10dc:3116) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 18 Nov 2019 16:01:35 +0000 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (15.241.52.11) by G4W10204.americas.hpqcorp.net (16.207.82.16) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 18 Nov 2019 16:01:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G8q7p7DvGNqbMEdqHjYgMMqBHN8kBwNKBZrDa5o/z9sQjHJR8dm7FCqWGwvthdB3RVqsr6F6ZOlnTUpCFK+xDVYeAggPczK1JNQ2MdPsc5K7L3Bkc3Pgb1hkEBU08cilGgBCr1L/q632HlOpmjtDoSnhwnIBUGcPM5Wps2ipqNR5rLq2g8KDhKUWJTAqQ/3uwoGeDerYUp7dhCHS3CdjdMWkCwydDAgGmbDnO9DQJp1g9pejebBBZ5SNTO+9WXvoEMt4sz35wsQ/pRnqdk+Yi0ecrx8EEwUmz5c/a4tScTRhqgCZWeI9qDMKIBGOws+OVKibTF5MVltB7AB+8KzuYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VgstlfcoSm/6nUlArfYRVGAsPre8Rw3IkajnwzT7Xrc=; b=HrlwQTVwDAdmgCzTXpHXBBPsKlu+/+U5eaEFB/5xuaic9eGB0KqIKe1QX2yuAPYiTBrdyChndUqO7FF8Tm4/RV0Hjo8kEBz8Vb8MUEzPfIx02Y6ORWjCLNiN9ha7KGtSsNqxJ4qrCpfxZ6lNVRQKE4qqMiNfI/5LFrXZi7Tie444rpJTxmkYy7lICHfdZiNic9MiauD6tzjdOc6oTNXXsZL5JauvFZ9o4Cwn44qSveaLi+SxukXv0QbmaN3oHlVhCbMT640SHcpfCsRw0B9m059n+lHtBEZXK7LMGnbyj+iBNfy9FS2fBlFb7sC6/s4+vOL1A16/7X3Yd8NPXQA50Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM (10.169.4.9) by AT5PR8401MB0817.NAMPRD84.PROD.OUTLOOK.COM (10.169.8.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 16:01:34 +0000 Received: from AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110]) by AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM ([fe80::81ab:37ac:b862:a110%11]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 16:01:34 +0000 From: "Cappalli, Tim (Aruba)" To: Alan DeKok CC: EMU WG Thread-Topic: [Emu] Best practices for supplicants and authenticators Thread-Index: AQHVnhsKV+GRtV0vSkCNpQk4qcIR6KeRC18/gAADwICAAABZa4AAAiqAgAAALDCAAAOygIAAAQVG Date: Mon, 18 Nov 2019 16:01:34 +0000 Message-ID: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> <4D4ACE1D-B565-4AB2-87B8-FD8362A0E76F@deployingradius.com> , <1DCB7146-EAE5-4450-A690-0783F687DF72@deployingradius.com> In-Reply-To: <1DCB7146-EAE5-4450-A690-0783F687DF72@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:88f7:1621:610c:c87:2f84:f471] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 44227aaf-f4f0-4642-ce1d-08d76c4095ca x-ms-traffictypediagnostic: AT5PR8401MB0817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(136003)(346002)(366004)(199004)(189003)(6246003)(86362001)(8676002)(6916009)(478600001)(6306002)(54896002)(9686003)(2906002)(81166006)(81156014)(7696005)(8936002)(33656002)(64756008)(256004)(486006)(25786009)(11346002)(476003)(66946007)(66556008)(66476007)(66446008)(91956017)(446003)(52536014)(76116006)(229853002)(6116002)(53546011)(76176011)(102836004)(14444005)(46003)(6506007)(55016002)(6436002)(7736002)(186003)(74316002)(99286004)(316002)(5660300002)(4326008)(14454004)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0817; H:AT5PR8401MB0530.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HcEnT928ARqZ8SETRdwWmbhTneojMRKD4bbBfImndgEn3eMsUMvkKr0tdrvd4vS2zmpDNE+faWL+3hls+7y0zMNd+H9RQXsY4cNWA7UxNIRuMb8TPPKCsi9cvdb++AIQwO7W027foTL8IPnWFg6YbIujdinImD1EoLOym3+4cM3bpUiBuawH61CHQhzdluV8iyUvUL42PL9muj4rBcwKAjfn/SZ+SzdTwSp6AEfPLwvcbfHjRFGDZ6apcmD4qBDSI4u6o1CiWyumS8ErU2W6A6/MVlaACk1ojXTmjS6YXl6R7Hqjhw/AXIwUSv1fq3ZwXt/Y17bbEvM7D7VFf2Jh/WR1ZphyrW+QmqZ6b78sPS+y50QwB6H7FsgumKPAsIyoj4OC97Z8LDbpJLxHLXTfRl0o6mzOQCZ7vcQHu+mF1zxGebOVw7tO8Jsx6FgSFqL6 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AT5PR8401MB0530AF675322838D27DFDF7FDB4D0AT5PR8401MB0530_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 44227aaf-f4f0-4642-ce1d-08d76c4095ca X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 16:01:34.2297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UevkjdBjCd4thoKiHuRNiLHvgCw9TX3Li8v4B1lpGg8J86jBGu/ebgGwXVD1zCw3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0817 X-OriginatorOrg: hpe.com X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_04:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 priorityscore=1501 phishscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 mlxscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180146 Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 16:01:46 -0000 --_000_AT5PR8401MB0530AF675322838D27DFDF7FDB4D0AT5PR8401MB0530_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So you=92re saying an NAIRealm must be a publicly registered domain name? I= agree, but just want to be crystal clear. tim From: Alan DeKok Date: Monday, November 18, 2019 at 10:57 AM To: Cappalli, Tim (Aruba) Cc: EMU WG Subject: Re: [Emu] Best practices for supplicants and authenticators > On Nov 18, 2019, at 10:47 AM, Cappalli, Tim (Aruba) wrote: > > Alan =96 Adding yet another OID and/or EKU to a certificate does not chan= ge the fact that no authority can attest to that information. A public CA c= annot validate a ownership of an NAIRealm. That's not true. Public CAs validate ownership of domain names. The NAIRealm is a domain n= ame. And, the NAIRealm is the *same* as the domain name in the certificate= . Which the CA validated. Unless you have a counter-argument, that discussion should be closed. > So while a supplicant could be configured to validate that the server=92s= NAIRealm matches the local configuration, that doesn=92t change the requir= ement to manually configure the supplicant. I explained how it could simplify the supplicants configuration. > So what are we actually trying to improve here? See my previous messages for explanations. Alan DeKok. --_000_AT5PR8401MB0530AF675322838D27DFDF7FDB4D0AT5PR8401MB0530_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

So you=92re saying an NAIRealm must be a publicly registered domain na= me? I agree, but just want to be crystal clear.

 

tim

 

From: Alan DeKok <alan= d@deployingradius.com>
Date: Monday, November 18, 2019 at 10:57 AM
To: Cappalli, Tim (Aruba) <timc@hpe.com>
Cc: EMU WG <emu@ietf.org>
Subject: Re: [Emu] Best practices for supplicants and authenticators=



> On Nov 18, 2019, at 10:47 AM, Cappalli, Tim (Aruba) <timc@hpe.com&g= t; wrote:
>
> Alan =96 Adding yet another OID and/or EKU to a certificate does not c= hange the fact that no authority can attest to that information. A public C= A cannot validate a ownership of an NAIRealm.

  That's not true.

  Public CAs validate ownership of domain names. The NAIRealm is a dom= ain name.  And, the NAIRealm is the *same* as the domain name in the c= ertificate.  Which the CA validated.

  Unless you have a counter-argument, that discussion should be closed= .

> So while a supplicant could be configured to validate that the server= =92s NAIRealm matches the local configuration, that doesn=92t change the re= quirement to manually configure the supplicant.

  I explained how it could simplify the supplicants configuration.

> So what are we actually trying to improve here?

  See my previous messages for explanations.

  Alan DeKok.

--_000_AT5PR8401MB0530AF675322838D27DFDF7FDB4D0AT5PR8401MB0530_-- From nobody Mon Nov 18 08:04:42 2019 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 93EB912097A for ; Mon, 18 Nov 2019 08:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvJtTr3_IFR3 for ; Mon, 18 Nov 2019 08:04:40 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CBE112010E for ; Mon, 18 Nov 2019 08:04:40 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 7F7ED77; Mon, 18 Nov 2019 16:04:38 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 18 Nov 2019 11:04:36 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <886A3962-56BB-4589-8F0E-5884EB3D62A3@deployingradius.com> References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> <4D4ACE1D-B565-4AB2-87B8-FD8362A0E76F@deployingradius.com> <1DCB7146-EAE5-4450-A690-0783F687DF72@deployingradius.com> To: "Cappalli, Tim (Aruba)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Mon, 18 Nov 2019 16:04:42 -0000 On Nov 18, 2019, at 11:01 AM, Cappalli, Tim (Aruba) = wrote: >=20 > So you=E2=80=99re saying an NAIRealm must be a publicly registered = domain name? I agree, but just want to be crystal clear. Yes. See RFC 7542. It defines the NAI in some detail. Alan DeKok. From nobody Mon Nov 18 15:22:31 2019 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 EA020120A3D for ; Mon, 18 Nov 2019 15:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYhhNDNZgLcC for ; Mon, 18 Nov 2019 15:22:25 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689F1120919 for ; Mon, 18 Nov 2019 15:22:25 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q1600DAUU9CKN@wwwlocal.goatley.com> for emu@ietf.org; Mon, 18 Nov 2019 17:22:24 -0600 (CST) Received: from Dans-MacBook-Pro.local ([101.100.166.3]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q1600ODTU4WOZ@trixy.bergandi.net> for emu@ietf.org; Mon, 18 Nov 2019 15:19:45 -0800 (PST) Received: from 3-166-100-101.myrepublic.com.sg ([101.100.166.3] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 18 Nov 2019 15:19:45 -0800 Date: Mon, 18 Nov 2019 15:22:21 -0800 From: Dan Harkins In-reply-to: <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> To: emu@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=101.100.166.3) X-PMAS-External-Auth: 3-166-100-101.myrepublic.com.sg [101.100.166.3] (EHLO Dans-MacBook-Pro.local) References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> X-PMAS-Software: PreciseMail V3.3 [191118] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Mon, 18 Nov 2019 23:22:30 -0000   Hi Alan, On 11/12/19 3:40 PM, Alan DeKok wrote: > On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: >> How does a public CA prove ownership of an SSID? > Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? > > Do public CAs verify that email addresses in the certificate work? > > Do public CAs verify that the OIDs in the certificate match the intended use-cases? > > Is there a global registry of SSIDs which the public CA could use to verify the SSID?   I'm taking these as rhetorical questions with an implied "no". If that is not the correct way of taking them then please let me know.   So the issue is, if the CA does not check any of these things then you cannot trust them in the certificate. The reason you trust the contents of a certificate is because you trust the CA has done the appropriate due diligence to validate the stuff it is certifying. If a CA doesn't do the due diligence on any of the above stuff and still issues a certificate containing that stuff then I would question the integrity of the CA and probably not trust other things it is certifying. In other words, I'd probably remove that CA's cert from my TADB. > To put it another way, I'm not sure why this question is being posed.   Here's one: Why would you trust an attribute that was not validated?   Dan. > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Mon Nov 18 15:42:48 2019 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 6D83C120B6D for ; Mon, 18 Nov 2019 15:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1ExZUoWpKXg for ; Mon, 18 Nov 2019 15:42:42 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9976A120B6C for ; Mon, 18 Nov 2019 15:42:42 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 2F05AB79; Mon, 18 Nov 2019 23:42:40 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Mon, 18 Nov 2019 18:42:38 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> To: Dan Harkins X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Mon, 18 Nov 2019 23:42:47 -0000 On Nov 18, 2019, at 6:22 PM, Dan Harkins wrote: >=20 > On 11/12/19 3:40 PM, Alan DeKok wrote: >> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) = wrote: >>> How does a public CA prove ownership of an SSID? >> Do public CAs *always* verify addresses and/or telephone numbers, = which are normally included in certificates? >>=20 >> Do public CAs verify that email addresses in the certificate work? >>=20 >> Do public CAs verify that the OIDs in the certificate match the = intended use-cases? >>=20 >> Is there a global registry of SSIDs which the public CA could use = to verify the SSID? >=20 > I'm taking these as rhetorical questions with an implied "no". If = that is > not the correct way of taking them then please let me know. The implication is that many of them are "no". Some are "yes". Some = *should* be "yes", and are in practice often "no". > So the issue is, if the CA does not check any of these things then = you cannot > trust them in the certificate. What happens if the CA checks some things, and not others? > The reason you trust the contents of a certificate > is because you trust the CA has done the appropriate due diligence to = validate > the stuff it is certifying. If a CA doesn't do the due diligence on = any of the > above stuff and still issues a certificate containing that stuff then = I would > question the integrity of the CA and probably not trust other things = it is > certifying. In other words, I'd probably remove that CA's cert from my = TADB. That's up to you. =20 >> To put it another way, I'm not sure why this question is being = posed. >=20 > Here's one: Why would you trust an attribute that was not validated? Define "validation" :) If the certificate contains an NAIRealm OID, then I know how the CA = should validate it: check that the realm matches the domain. For SSIDs, since there's no registry, it's not possible to "validate" = it against a registry. So "validation" here means... what, exactly? My point for SSIDs is that validation means whatever we define it to = mean. So long as everyone agrees that the SSID field is a hint and is = not validated by the CA, it's OK to use it. In addition, CAs currently validate *control* of a domain. But they = don't (and can't) really validate *ownership* as such. i.e. if I own a = company, I can tell an employee to ask a CA for certificates for that = domain. He may be making that request, even if he doesn't "own" the = domain. He can convince the CA that he controls the domain. I'm not = sure how the CA would check that the owner of the domain has properly = delegated the certificate request to the employee. The same applies for telephone numbers. Do CAs call the numbers? Do = they check that the person answering is the same person who made the = request? Maybe. These issues can't be answered with simple black & white statements. = If the data in a certificate is imperfect, it might still be useful. Alan DeKok. From nobody Mon Nov 18 16:39:18 2019 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 E6D17120125 for ; Mon, 18 Nov 2019 16:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X_9KYtFBCXY for ; Mon, 18 Nov 2019 16:39:12 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C92612006F for ; Mon, 18 Nov 2019 16:39:11 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q1600DE8XTBKN@wwwlocal.goatley.com> for emu@ietf.org; Mon, 18 Nov 2019 18:39:11 -0600 (CST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q16000GFXOTDK@trixy.bergandi.net> for emu@ietf.org; Mon, 18 Nov 2019 16:36:31 -0800 (PST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165] EXTERNAL) (EHLO dhcp-9ca5.meeting.ietf.org) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 18 Nov 2019 16:36:31 -0800 Date: Mon, 18 Nov 2019 16:39:07 -0800 From: Dan Harkins In-reply-to: To: Alan DeKok Cc: emu@ietf.org Message-id: <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=31.133.156.165) X-PMAS-External-Auth: dhcp-9ca5.meeting.ietf.org [31.133.156.165] (EHLO dhcp-9ca5.meeting.ietf.org) References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> X-PMAS-Software: PreciseMail V3.3 [191118] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 19 Nov 2019 00:39:17 -0000 On 11/18/19 3:42 PM, Alan DeKok wrote: > On Nov 18, 2019, at 6:22 PM, Dan Harkins wrote: >> On 11/12/19 3:40 PM, Alan DeKok wrote: >>> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba) wrote: >>>> How does a public CA prove ownership of an SSID? >>> Do public CAs *always* verify addresses and/or telephone numbers, which are normally included in certificates? >>> >>> Do public CAs verify that email addresses in the certificate work? >>> >>> Do public CAs verify that the OIDs in the certificate match the intended use-cases? >>> >>> Is there a global registry of SSIDs which the public CA could use to verify the SSID? >> I'm taking these as rhetorical questions with an implied "no". If that is >> not the correct way of taking them then please let me know. > The implication is that many of them are "no". Some are "yes". Some *should* be "yes", and are in practice often "no". > >> So the issue is, if the CA does not check any of these things then you cannot >> trust them in the certificate. > What happens if the CA checks some things, and not others?   Then it means the CA is certifying things it shouldn't. >> The reason you trust the contents of a certificate >> is because you trust the CA has done the appropriate due diligence to validate >> the stuff it is certifying. If a CA doesn't do the due diligence on any of the >> above stuff and still issues a certificate containing that stuff then I would >> question the integrity of the CA and probably not trust other things it is >> certifying. In other words, I'd probably remove that CA's cert from my TADB. > That's up to you.   Let me put it another way. There is no reason to trust a CA that does not perform due diligence on the things it certifies. Convince me otherwise. >>> To put it another way, I'm not sure why this question is being posed. >> Here's one: Why would you trust an attribute that was not validated? > Define "validation" :)   I'll pass on playing that game. > If the certificate contains an NAIRealm OID, then I know how the CA should validate it: check that the realm matches the domain. > > For SSIDs, since there's no registry, it's not possible to "validate" it against a registry. So "validation" here means... what, exactly? > > My point for SSIDs is that validation means whatever we define it to mean. So long as everyone agrees that the SSID field is a hint and is not validated by the CA, it's OK to use it.   Use it how? What value do you put in an attribute that hasn't been validated (and don't ask me what that word means since you used it)? > In addition, CAs currently validate *control* of a domain. But they don't (and can't) really validate *ownership* as such. i.e. if I own a company, I can tell an employee to ask a CA for certificates for that domain. He may be making that request, even if he doesn't "own" the domain. He can convince the CA that he controls the domain. I'm not sure how the CA would check that the owner of the domain has properly delegated the certificate request to the employee.   Then what you can infer from a domain name in a certificate issued by such a CA is that the holder of the corresponding private key controls that domain. Nothing more, nothing less. But you can't infer anything from other attributes that have not been validated (again, using a word you used yourself) > The same applies for telephone numbers. Do CAs call the numbers? Do they check that the person answering is the same person who made the request? Maybe.   You tell me if a CA "calls the numbers". If it doesn't then what can you infer from a telephone number in a certificate it signs? > These issues can't be answered with simple black & white statements. If the data in a certificate is imperfect, it might still be useful.   OK, convince me of its utility.   Dan. From nobody Tue Nov 19 04:18:07 2019 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 62DEB120917 for ; Tue, 19 Nov 2019 04:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPLsP8zl56Pj for ; Tue, 19 Nov 2019 04:18:03 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8162D120874 for ; Tue, 19 Nov 2019 04:18:03 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 5DC8EA8B; Tue, 19 Nov 2019 12:18:01 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> Date: Tue, 19 Nov 2019 07:17:59 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> To: Dan Harkins X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Tue, 19 Nov 2019 12:18:05 -0000 On Nov 18, 2019, at 7:39 PM, Dan Harkins wrote: >> What happens if the CA checks some things, and not others? >=20 > Then it means the CA is certifying things it shouldn't. Well, that's what happens with most CA's. >> Define "validation" :) >=20 > I'll pass on playing that game. We have a good "feel" for what validation means in casual = conversation. We're less clear what it means as a *process*. How does a CA validate a field? The answer is too often "it validates = the field", which seems a bit circular. My point is that validation isn't black and white. There are various = kinds of validation, each of which give you different kinds of = information. My goal is to understand what those are, and to find out = how we can use that information. Your position seems to be "it's either = perfectly validated or perfectly useless". >> My point for SSIDs is that validation means whatever we define it = to mean. So long as everyone agrees that the SSID field is a hint and = is not validated by the CA, it's OK to use it. >=20 > Use it how? What value do you put in an attribute that hasn't been = validated (and > don't ask me what that word means since you used it)? RFC 4334 describes this in some detail. See section 3 for discussion = on SSIDs. >> In addition, CAs currently validate *control* of a domain. But = they don't (and can't) really validate *ownership* as such. i.e. if I = own a company, I can tell an employee to ask a CA for certificates for = that domain. He may be making that request, even if he doesn't "own" = the domain. He can convince the CA that he controls the domain. I'm = not sure how the CA would check that the owner of the domain has = properly delegated the certificate request to the employee. >=20 > Then what you can infer from a domain name in a certificate issued = by such a CA > is that the holder of the corresponding private key controls that = domain. Nothing > more, nothing less. But you can't infer anything from other attributes = that have not > been validated (again, using a word you used yourself) Certificates contain serial numbers. They haven't been validated by a = CA. The lack of validation therefore means that you can't infer = anything from that field? I would argue that you *can* make inferences from that field. >> The same applies for telephone numbers. Do CAs call the numbers? = Do they check that the person answering is the same person who made the = request? Maybe. >=20 > You tell me if a CA "calls the numbers". If it doesn't then what can = you infer > from a telephone number in a certificate it signs? This isn't difficult. It means that the certificate owner has claimed = he can be reached at that number. And the CA has signed the statement, = agreeing that it's a statement made by the certificate owner. >> These issues can't be answered with simple black & white = statements. If the data in a certificate is imperfect, it might still = be useful. >=20 > OK, convince me of its utility. See RFC 4334 and its discussion of SSIDs. Alan DeKok. From nobody Tue Nov 19 19:40:34 2019 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 388CA12004E for ; Tue, 19 Nov 2019 19:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mKwlENtC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=X6nyxGpc 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 UXB84jJ15FKb for ; Tue, 19 Nov 2019 19:40:30 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FBE12002E for ; Tue, 19 Nov 2019 19:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5974; q=dns/txt; s=iport; t=1574221230; x=1575430830; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=idHEu/cv9zmOg00jlEI42firlMj+6SRFeZsFKxz1Bio=; b=mKwlENtCD4EWl/s0DTW229JZctTQx35jopodHcQU4CcCYjb17utYbUCz GgaZVkuUTE0hb3u+OWrtpVeE/cR4Ezz94qy4fZhzoinIOAPw4q2qyBj0l jT/Lf9+f3olBnkfdc23falFzfPVW5eyIEOguw7nZV1hUOTORQICAvLpLJ 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A/HiSiByZSTF6KNXXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuCB1f6IfrCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCrtNRd/49dJa1cCRoBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBfoFLUAVsWCAECyqHcAOKdE6CEJgAglIDVAk?= =?us-ascii?q?BAQEMAQEYDQgCAQGEQAKCJSQ4EwIDDQEBBAEBAQIBBQRthTcMhVEBAQEBAwE?= =?us-ascii?q?BECgGAQEsDAsEAgEIEQQBARcCBQEQJwsdCAIEARIIGoMBgkYDLgECDKVyAoE?= =?us-ascii?q?4iGCCJ4J+AQEFhQYYghcDBoE2i3ceGIFAP4ERRoFOUC4+gmIBAQKBNRQJD0Y?= =?us-ascii?q?HBoJtgiyNFjgJAYgmghuHB48NCoIrhxqOUIFUlAGEPI5Ihz56kVACBAIEBQI?= =?us-ascii?q?OAQEFgWkigUIOCHAVO4JsUBEUkRoHBReDUIUUhT90B4Ehi1MNFQIHghMBAQ?= X-IronPort-AV: E=Sophos;i="5.69,220,1571702400"; d="scan'208";a="374208307" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2019 03:40:28 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xAK3eSxF001557 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Nov 2019 03:40:28 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 21:40:28 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 21:40:27 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Nov 2019 21:40:27 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NJNJ+A2GjrxM3wiJ/qMlzkcRRGEBOzpxOca9sEx9wyvKhkS5dsVc8K4o2i3/DHvrb4Ex50tmJP72R6KKdQWAYt9/vv4ZFIoszB22Eey379XcyCVRP9aiKPAigpbRHpGcfFySrJnCEQYxq8KapUUIhQd4StQgK29rnmM0A8Z7PuTKIyGDB2aXuFWz92nbZGAs69ki+L9ueDCEdzFdtjNp4A5J/VPoSGd5LIakqlIJZLy4zomHK6XfKki0/8qyyye8vUvHbTVpivxCFkNNNPYQV7smFIC0YOMCbaQiyP7nNF8YKpnyZLM2s5Zz01Ngor9tBHjeFaOagkvviOIyhSbFVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CZZsyp4vEFE11eXZogNr6A9ghCX+Vafd3JUE8zv91TE=; b=RamAn36pDeijKRxVOffCFZIwP2THFa3BtpnVkh9LuGyHsSPZkKXHyHktRtlgkPorH2vDruPXh3VfxWXpOMSsZRFfMHuQkmybAzW2ZNQaDMHD/qvoou37hYW90z/l/2Cb9pWl9IQ4IGytLAaN/emYaVqDKeLLXlB51TYHEFsYXq0QZydrgOcY8fy+FAhLI7hZHPywFP8SngwvRvpQpWPRORP49tsaSOZ4+90gn/P8TEsrOiRR7euS9qM4VCAFaXBvNbC/UKMaZiTrzXR5UMXhS+LokUWsFOkH5uODLCjzw/Tts8fmSdhagl+ajQ0ol8q3QZ3lTBBvMXdaurf0i6NGrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CZZsyp4vEFE11eXZogNr6A9ghCX+Vafd3JUE8zv91TE=; b=X6nyxGpcUUjdixH1lAlLpSSBxnXUYvZGNKH50Vo6sADa5rsiOptKGbGjMKc/Fk2hvntBAQ65/7B2lyhPcUtnzlB+Bdg6SC2i1wnLMtDmpn01gp5dMteNzjO1S8ZiWtzzv8DKwcRVURy9DSAM0gEEYdPSG4kxVcLrWmyzMLrjy2Y= Received: from MN2PR11MB3901.namprd11.prod.outlook.com (20.179.150.76) by MN2PR11MB4013.namprd11.prod.outlook.com (10.255.181.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.16; Wed, 20 Nov 2019 03:40:25 +0000 Received: from MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153]) by MN2PR11MB3901.namprd11.prod.outlook.com ([fe80::7127:bf0:d3be:3153%7]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 03:40:25 +0000 From: "Owen Friel (ofriel)" To: Alan DeKok , EMU WG Thread-Topic: [Emu] Best practices for supplicants and authenticators Thread-Index: AQHVnhsMTqA+nAW920SAMstMn7GUyaeSBYfg Date: Wed, 20 Nov 2019 03:40:25 +0000 Message-ID: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> In-Reply-To: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [2001:420:c0c8:1001::f0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e8e67c0-afae-4c6f-0f14-08d76d6b60fd x-ms-traffictypediagnostic: MN2PR11MB4013: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39860400002)(346002)(366004)(136003)(51444003)(13464003)(199004)(189003)(76116006)(8676002)(476003)(81166006)(74316002)(2906002)(81156014)(6116002)(305945005)(110136005)(316002)(446003)(8936002)(66556008)(46003)(71190400001)(71200400001)(6246003)(66946007)(99286004)(64756008)(66476007)(102836004)(66446008)(7696005)(53546011)(11346002)(76176011)(6506007)(7736002)(229853002)(86362001)(486006)(966005)(33656002)(14444005)(256004)(55016002)(25786009)(186003)(52536014)(14454004)(6306002)(5660300002)(9686003)(6436002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4013; H:MN2PR11MB3901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DNqf7nXXGuZY2VPNAf0nQJVKhw529Pp2N6oKhlzt3rQqgVD8Q0IPJLwByGLUvzQqmEvA1ZHxsQTtMmXRdvmXOOKdC0j9dVeiBnYHuewXsMI0ybsed+dLBwk7oTq4B9KdfRBwmq+gxwnxZkyBCm5G4NsWFUpJyl2Rmh7hIuXZ1kvPkhDrNjv3GN0FxUKOjIrzaIc1Dsx/HSmMyXpnrFETfdF+iUfCpiGd3PtHuvRPvf6lR4QWH3ZEhGPFq/5yIml2M27WBE0pFF64PXZFEiVYtoSDR7jK7e3fg1oRCZM9ZkALlB2MFxWWV65cYfPg+nhPlYgkSfPz5yry0F9iDtBzri70cpUwyS7cF0QP8PasRgPBYADKqjF5zAO3zurvorJ0mcfnEsRiMYYkGshQoMWx7/iKrpTzXXBTHD0LKzstH1IpLBiZRQgfb1mRxEBBzjZ3ioXoxoeUj/Gndz5egHe4ayc3lYdKwYtq4azEUuWZsWk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5e8e67c0-afae-4c6f-0f14-08d76d6b60fd X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 03:40:25.1140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Gyixou7bGN/Sr8BFB5Py6d4+SvTJwWM2zW0MREJcSOskeC5jweyYZiE30j5dTbAf4Fj31l59N8u4jZBrJeyQhg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4013 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Wed, 20 Nov 2019 03:40:32 -0000 Assuming that NAIRealm is a registered domain as per RFC 7542, and thus pub= lic CAs can verify ownership, the goal / where we want to get to is: - CA may be a public CA and thus public CAs can be enabled by default in su= pplicant config - supplicant checks NAI Realm in the EAP identity cert matches that of the = user's realm - supplicant verifies id-kp-eapOverLAN is set And also assuming that public CAs will not issue certs with an NAIRealm or = id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below = for details.) And it could be years before public CAs do. Does that mean there is an intermediate rollout phase where the supplicant = checks that the realm the user enters matches a dNSName in the EAP cert? The rollout / upgrade issue with this is of course if we give guidance that= supplicants (i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is set If that fails then (ii) check that dNSName matches entered realm at what point in time would supplicant behaviour ever change to remove the = fallback to option (ii) and checking dNSName only? As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs= ): Public CAs generally don't issue these either, so the same issue with su= pplicants checking for NAIRealm or id-kp-eapOverLAN exists with id-mod-dns-= srv-name-93 w.r.t. Public CAs. Owen P.S.: Let's Encrypt implementation is at: https://github.com/letsencrypt/bo= ulder You can see the only allowed KeyUsage and ExtKeyUsage bits here: https://github.com/letsencrypt/boulder/blob/master/cmd/gen-ca/main.go#L318 https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go= #L303 -----Original Message----- From: Emu On Behalf Of Alan DeKok Sent: 18 November 2019 14:18 To: EMU WG Subject: [Emu] Best practices for supplicants and authenticators After the meeting earlier today, I made some notes on best practices for = supplicants and authenticators. I think it would be useful to have an offi= cial WG document which gives guidance. Background: a) the current practice in TLS-based EAP methods is to use certificates wit= h "id-kp-serverAuth" OID set for Extended Key Usage. b) many supplicants check for this OID, and refuse to perform authenticatio= n if it is missing c) supplicants do not check DNS names or any other field in the certificate= s d) as a result of this lack of verification, supplicants ship with all know= n CAs disabled for TLS-based EAP methods If the supplicants did ship with root CAs enabled, then because of the la= ck of validation in (c), the supplicants would hand over user credentials t= o any authenticator who has a properly signed certificate. This is wrong, = and is why all of the root CAs are disabled. It would be useful to simplify the user experience when working with EAP-= TLS. It would also be useful to reduce security issues. This is where a n= ew document is needed. I believe that the standards exist to support these= goals. However, there's a lack of guidance around using these standard. = It would be good to document current practices, and then give guidance on h= ow to upgrade to better practices. I'll start off describing the end goal, and then discuss how we can get t= here. The goal is to have certificates which contain the id-kp-eapOverLAN OID (= RFC 4334), and either the NAIRealm OID (RFC 7585), or a similar one dedicat= ed to TLS-based EAP authentication. Supplicants can use these fields to ve= rify that the certificate is both intended to be used for TLS-based EAP aut= hentication, and that the certificate is for a given realm. The end user experience *should* be something like: * connect to a system which uses 802.1X authentication (SSID, wired, etc) * prompt the user for full credentials (user id + realm / password) * validate that the server certificate has the id-kp-eapOverLAN OID set, AN= D that the NAIRealm OID matches the user's realm * validate the certificate chain If those validation steps succeed, then the supplicant could send the use= rs credentials over the EAP method. I think that this extra validation mea= ns that supplicants can trust known root CAs by default. Which makes the u= ser experience much better. Since the certificates do not currently contain these fields, and supplic= ants don't check them, we need an upgrade path. The first step is to suggest that admins generate certificates with the a= bove fields. This likely means that certificate authorities will be asked = to sign certs with the NAIRealm OID, which they might not do. This limitat= ion is less of a problem in a roaming federation like Eduroam, where they a= re their own CA. The next step is to suggest that supplicant vendors upgrade their systems= to allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in server cer= tificates. That is a simple change, and shouldn't have any negative affect= s. Supplicants can also be upgraded to check the NAIRealm. If the field doe= s not match the users realm, then the certificate should be rejected. If t= he field does match, then the supplicant should validate the certificate ch= ain. This validation should also include trusting known root CAs by defaul= t. We should also recommend that supplicant vendors check the id-mod-dns-srv= -name-88 and id-mod-dns-srv-name-93 fields of server certificates. If the = domain names there do not match the realm given by the user, then the user = should be warned, and the certificate rejected. If accepted, I think that such practices would tremendously simplify the = use of TLS-based EAP methods for both users and administrators. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From nobody Wed Nov 20 02:23:49 2019 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 CED981208E0 for ; Wed, 20 Nov 2019 02:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tnFUjJruPQ1 for ; Wed, 20 Nov 2019 02:23:46 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36919120844 for ; Wed, 20 Nov 2019 02:23:46 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q1900DYVJJLKN@wwwlocal.goatley.com> for emu@ietf.org; Wed, 20 Nov 2019 04:23:45 -0600 (CST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q1900E13JEXEG@trixy.bergandi.net> for emu@ietf.org; Wed, 20 Nov 2019 02:20:59 -0800 (PST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165] EXTERNAL) (EHLO dhcp-9ca5.meeting.ietf.org) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 20 Nov 2019 02:20:59 -0800 Date: Wed, 20 Nov 2019 02:23:42 -0800 From: Dan Harkins In-reply-to: <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> To: Alan DeKok Cc: emu@ietf.org Message-id: <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=31.133.156.165) X-PMAS-External-Auth: dhcp-9ca5.meeting.ietf.org [31.133.156.165] (EHLO dhcp-9ca5.meeting.ietf.org) References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> X-PMAS-Software: PreciseMail V3.3 [191118] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 20 Nov 2019 10:23:48 -0000 On 11/19/19 4:17 AM, Alan DeKok wrote: > On Nov 18, 2019, at 7:39 PM, Dan Harkins wrote: [snip] >> Then what you can infer from a domain name in a certificate issued by such a CA >> is that the holder of the corresponding private key controls that domain. Nothing >> more, nothing less. But you can't infer anything from other attributes that have not >> been validated (again, using a word you used yourself) > Certificates contain serial numbers. They haven't been validated by a CA. The lack of validation therefore means that you can't infer anything from that field? > > I would argue that you *can* make inferences from that field.   What do you mean that certificate serial numbers haven't been validated by the CA? They originate from the CA. They are, by definition, a valid statement from the CA. >>> The same applies for telephone numbers. Do CAs call the numbers? Do they check that the person answering is the same person who made the request? Maybe. >> You tell me if a CA "calls the numbers". If it doesn't then what can you infer >> from a telephone number in a certificate it signs? > This isn't difficult. It means that the certificate owner has claimed he can be reached at that number. And the CA has signed the statement, agreeing that it's a statement made by the certificate owner. > >>> These issues can't be answered with simple black & white statements. If the data in a certificate is imperfect, it might still be useful. >> OK, convince me of its utility. > See RFC 4334 and its discussion of SSIDs.   Is this _my_ certificate that has this attribute in it or is it in a certificate I receive? If it's my certificate then what is the point of putting it in my certificate? I am asking for ambiguous data to be certified and placed in my certificate for my own use? If this attribute is in a certificate I receive then what does it mean to "select the correct certificate for authentication in a particular WLAN"?Fit this check into the network connection process:   1. service discovery   2. 802.11 authentication   3. 802.11 association   4. EAP-ID req/resp   5. EAP authentication Which numbered step is this attribute used in and how?   This attribute seems useless to me and its ambiguity and therefore unverifiability is a large reason why.   Dan. From nobody Wed Nov 20 04:11:24 2019 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 82ACA1200B9 for ; Wed, 20 Nov 2019 04:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tCeAgOBVKTA for ; Wed, 20 Nov 2019 04:11:20 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A593C1207FE for ; Wed, 20 Nov 2019 04:11:20 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 9BC8042E; Wed, 20 Nov 2019 12:11:17 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> Date: Wed, 20 Nov 2019 07:11:15 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <04E2AEF5-F1EE-4B74-B5BB-DFE099543C92@vigilsec.com> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> To: Dan Harkins X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 20 Nov 2019 12:11:23 -0000 On Nov 20, 2019, at 5:23 AM, Dan Harkins wrote: >> See RFC 4334 and its discussion of SSIDs. >=20 > Is this _my_ certificate that has this attribute in it or is it in a = certificate I receive? The Introduction of RFC 4334 says: Automated selection of client certificates for use with PPP and IEEE 802.1X is highly desirable. Which seems clear. > If it's my certificate then what is the point of putting it in my = certificate? See the text in the document, which explains this in detail. > I am asking for > ambiguous data to be certified and placed in my certificate for my own = use? If this attribute > is in a certificate I receive then what does it mean to "select the = correct certificate for > authentication in a particular WLAN"? The text explains this in detail. I'll summarize. The use-case of the document is that an individual is issued a client = certificate. That certificate contains an OID about the expected = use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a = client system is confronted with a set of SSIDs, it can cross-correlate = the SSIDs it sees with SSIDs in it's certificate store. The client = system can then select an appropriate authentication method (EAP versus = WPA-PSK), and also a client certificate to use. Since it's selected a = client cert, it can also verify the certificate chain back to the root. I would *also* argue that this information can be placed in a server = certificate, for situations when client certificates are not being used. = As discussed extensively previously on this list, a client can connect = to an SSID, obtain the server cert, and then verify: a) the server cert is intended for EAPoL (and is not just a cert taken = from a web server) b) the SSIDs in the cert match the SSID used to authenticate c) the NAIRealm in the cert matches a user identifier stored in the = client system In which case the client has *more* information than what is available = to it today, and can thus make better decisions about whether or not to = accept the cert. > This attribute seems useless to me and its ambiguity and therefore = unverifiability is a > large reason why. I would suggest not using it for your own purposes then. I would also = suggest allowing *others* to use it, if they find it useful. Alan DeKok. From nobody Wed Nov 20 06:16:32 2019 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 0D1081208DA for ; Wed, 20 Nov 2019 06:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5v8VCZoM9Tl for ; Wed, 20 Nov 2019 06:16:28 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239F91200EB for ; Wed, 20 Nov 2019 06:16:27 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id D2BF9333; Wed, 20 Nov 2019 14:16:25 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Wed, 20 Nov 2019 09:16:24 -0500 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <526166D8-80B9-4356-84D9-52ACD49E004B@deployingradius.com> To: "Owen Friel (ofriel)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Best practices for supplicants and authenticators 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: Wed, 20 Nov 2019 14:16:30 -0000 On Nov 19, 2019, at 10:40 PM, Owen Friel (ofriel) = wrote: >=20 > Assuming that NAIRealm is a registered domain as per RFC 7542, and = thus public CAs can verify ownership, the goal / where we want to get to = is: >=20 > - CA may be a public CA and thus public CAs can be enabled by default = in supplicant config I would add: only if the new checks pass. > - supplicant checks NAI Realm in the EAP identity cert matches that of = the user's realm > - supplicant verifies id-kp-eapOverLAN is set In addition to id-kp-serverAuth. We still need a way to distinguish = server certificates from client certificates. > And also assuming that public CAs will not issue certs with an = NAIRealm or id-kp-eapOverLAN bit. (This is certainly true for Let's = Encrypt. See below for details.) And it could be years before public CAs = do. I agree. > Does that mean there is an intermediate rollout phase where the = supplicant checks that the realm the user enters matches a dNSName in = the EAP cert? It's worth checking that anyways. It can be done quickly by = supplicants, and doesn't require changes to any CAs. > The rollout / upgrade issue with this is of course if we give guidance = that supplicants > (i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is = set > If that fails then (ii) check that dNSName matches entered realm Yes. > at what point in time would supplicant behaviour ever change to remove = the fallback to option (ii) and checking dNSName only? I'm not sure. > As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 = SRV-IDs): Public CAs generally don't issue these either, so the same = issue with supplicants checking for NAIRealm or id-kp-eapOverLAN exists = with id-mod-dns-srv-name-93 w.r.t. Public CAs. I agree. TBH, even if these practices are only implemented in a roaming = consortium, they will still be useful. A roaming consortium can create = their own CA with their own rules. i.e. even if just Eduroam adopts this practice, then it can be used by = millions, if not tens of millions of people. And making EAP easier to = use is always of enormous utility. Alan DeKok. From nobody Wed Nov 20 06:58:34 2019 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 1C5671200F8 for ; Wed, 20 Nov 2019 06:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFUrBPnByKSG for ; Wed, 20 Nov 2019 06:58:28 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69185120868 for ; Wed, 20 Nov 2019 06:58:28 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q1900NK4W9FNB@wwwlocal.goatley.com> for emu@ietf.org; Wed, 20 Nov 2019 08:58:27 -0600 (CST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q1900CF6W4PIU@trixy.bergandi.net> for emu@ietf.org; Wed, 20 Nov 2019 06:55:39 -0800 (PST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165] EXTERNAL) (EHLO dhcp-9ca5.meeting.ietf.org) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 20 Nov 2019 06:55:39 -0800 Date: Wed, 20 Nov 2019 06:58:23 -0800 From: Dan Harkins In-reply-to: To: Alan DeKok Cc: emu@ietf.org Message-id: <20c3dea6-d0e9-3b0c-c6dc-e3ae54e8a067@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=31.133.156.165) X-PMAS-External-Auth: dhcp-9ca5.meeting.ietf.org [31.133.156.165] (EHLO dhcp-9ca5.meeting.ietf.org) References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> X-PMAS-Software: PreciseMail V3.3 [191118] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 20 Nov 2019 14:58:33 -0000 On 11/20/19 4:11 AM, Alan DeKok wrote: > On Nov 20, 2019, at 5:23 AM, Dan Harkins wrote: >> I am asking for >> ambiguous data to be certified and placed in my certificate for my own use? If this attribute >> is in a certificate I receive then what does it mean to "select the correct certificate for >> authentication in a particular WLAN"? > The text explains this in detail. I'll summarize. > > The use-case of the document is that an individual is issued a client certificate. That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store. The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use. Since it's selected a client cert, it can also verify the certificate chain back to the root.   So you asked for imprecise, ambiguous, and unverified information to be put in your own certificate for you to use later. Just because something is in an RFC doesn't make it right. And appeal to RFC is another form of appeal to authority fallacy.   Oh, and what's the point of verifying the chain of your own certificate prior to connecting to a network? Do you do OCSP responses to see if your certificate has been revoked? > I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used. As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify:   Yea, and that's why I gave you the list of actions a client takes and asked you to point out where in the list this happens. You deleted the list. > a) the server cert is intended for EAPoL (and is not just a cert taken from a web server) > b) the SSIDs in the cert match the SSID used to authenticate > c) the NAIRealm in the cert matches a user identifier stored in the client system > > In which case the client has *more* information than what is available to it today, and can thus make better decisions about whether or not to accept the cert.   If the information is ambiguous and unverified why would you use it in a decision to accept a certificate or not? >> This attribute seems useless to me and its ambiguity and therefore unverifiability is a >> large reason why. > I would suggest not using it for your own purposes then. I would also suggest allowing *others* to use it, if they find it useful.   I'm not proposing to prevent you from doing anything. I'm asking what's the point and why. You didn't really provide one. And good luck getting a public CA to put ambiguous and unverifiable information in a certificate for you.   Dan. From nobody Wed Nov 20 08:07:28 2019 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 29AB2120100 for ; Wed, 20 Nov 2019 08:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeBwSyFuIGk9 for ; Wed, 20 Nov 2019 08:07:24 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA45C1200C4 for ; Wed, 20 Nov 2019 08:07:23 -0800 (PST) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 1FA8919AD; Wed, 20 Nov 2019 16:07:20 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <20c3dea6-d0e9-3b0c-c6dc-e3ae54e8a067@lounge.org> Date: Wed, 20 Nov 2019 11:07:19 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <550761BD-37C9-4EE4-9503-02DF4E4675D6@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> <20c3dea6-d0e9-3b0c-c6dc-e3ae54e8a067@lounge.org> To: Dan Harkins X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Wed, 20 Nov 2019 16:07:26 -0000 On Nov 20, 2019, at 9:58 AM, Dan Harkins wrote: >> The use-case of the document is that an individual is issued a = client certificate. That certificate contains an OID about the expected = use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a = client system is confronted with a set of SSIDs, it can cross-correlate = the SSIDs it sees with SSIDs in it's certificate store. The client = system can then select an appropriate authentication method (EAP versus = WPA-PSK), and also a client certificate to use. Since it's selected a = client cert, it can also verify the certificate chain back to the root. >=20 > So you asked for imprecise, ambiguous, and unverified information to = be put > in your own certificate for you to use later. Just because something = is in an > RFC doesn't make it right. And appeal to RFC is another form of appeal = to > authority fallacy. You asked how it worked. I pointed you to the RFC. You now claim I = *can't* refer to the RFC, because it's an appeal to authority. To recap: appeals to authority are logical fallacies where someone = says "I'm right because of this authority". I'm not saying that. I'm = saying that some people find it *useful*. I'm pointing to the RFC as = evidence that people find it useful. I'm pointing to the RFC as an = explanation of how it works. I think some of this back and forth could have been avoided with a = careful reading of the RFC. > Oh, and what's the point of verifying the chain of your own = certificate prior > to connecting to a network? Do you do OCSP responses to see if your = certificate > has been revoked? I had hoped my explanation was unclear. I guess not. The point was that when a client connects, it can check the *server* = certificate chain back to the *same* CA which was used to issue the = client cert. I've never seen a client check it's own certificate chain during = authentication. Such a use-case would be ludicrous, which makes me = wonder why you think that's what I was proposing. >> I would *also* argue that this information can be placed in a = server certificate, for situations when client certificates are not = being used. As discussed extensively previously on this list, a client = can connect to an SSID, obtain the server cert, and then verify: >=20 > Yea, and that's why I gave you the list of actions a client takes = and asked > you to point out where in the list this happens. You deleted the list. Yes. Because I gave an explanation of how it works. I want to be = sure that the explanation is understood before going into further = details. If my explanation makes no sense, then there's no point in me = discussing technical details. >> a) the server cert is intended for EAPoL (and is not just a cert = taken from a web server) >> b) the SSIDs in the cert match the SSID used to authenticate >> c) the NAIRealm in the cert matches a user identifier stored in the = client system >>=20 >> In which case the client has *more* information than what is = available to it today, and can thus make better decisions about whether = or not to accept the cert. >=20 > If the information is ambiguous and unverified why would you use it = in a decision > to accept a certificate or not? Well we're going in circles. I've given explanations. You reject = them whole-sale, and keep asking me for more explanations. > I'm not proposing to prevent you from doing anything. I'm asking = what's the point > and why. You didn't really provide one. And good luck getting a public = CA to put > ambiguous and unverifiable information in a certificate for you. I've already addressed these points. Please see my previous messages. I think this horse has been beaten to death. I don't see any point in = continuing it, unless there is progress. Alan DeKok. From nobody Thu Nov 21 16:40:02 2019 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 870121200B7 for ; Thu, 21 Nov 2019 16:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7pQR6aUcabJ for ; Thu, 21 Nov 2019 16:39:58 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1061200B6 for ; Thu, 21 Nov 2019 16:39:58 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0Q1C00LBUHUMRR@wwwlocal.goatley.com> for emu@ietf.org; Thu, 21 Nov 2019 18:39:58 -0600 (CST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0Q1C00BAKHPLYZ@trixy.bergandi.net> for emu@ietf.org; Thu, 21 Nov 2019 16:37:04 -0800 (PST) Received: from dhcp-9ca5.meeting.ietf.org ([31.133.156.165] EXTERNAL) (EHLO dhcp-9ca5.meeting.ietf.org) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 21 Nov 2019 16:37:04 -0800 Date: Thu, 21 Nov 2019 16:39:49 -0800 From: Dan Harkins In-reply-to: <550761BD-37C9-4EE4-9503-02DF4E4675D6@deployingradius.com> To: Alan DeKok Cc: emu@ietf.org Message-id: <87f583a4-cb0a-5d83-b8db-9e6d48b29ba9@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=31.133.156.165) X-PMAS-External-Auth: dhcp-9ca5.meeting.ietf.org [31.133.156.165] (EHLO dhcp-9ca5.meeting.ietf.org) References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> <20c3dea6-d0e9-3b0c-c6dc-e3ae54e8a067@lounge.org> <550761BD-37C9-4EE4-9503-02DF4E4675D6@deployingradius.com> X-PMAS-Software: PreciseMail V3.3 [191121] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Fri, 22 Nov 2019 00:40:02 -0000 On 11/20/19 8:07 AM, Alan DeKok wrote: > On Nov 20, 2019, at 9:58 AM, Dan Harkins wrote: >>> The use-case of the document is that an individual is issued a client certificate. That certificate contains an OID about the expected use-case (EAPoL), and also a list of SSIDs used to perform EAP. When a client system is confronted with a set of SSIDs, it can cross-correlate the SSIDs it sees with SSIDs in it's certificate store. The client system can then select an appropriate authentication method (EAP versus WPA-PSK), and also a client certificate to use. Since it's selected a client cert, it can also verify the certificate chain back to the root. [snip] > I've never seen a client check it's own certificate chain during authentication. Such a use-case would be ludicrous, which makes me wonder why you think that's what I was proposing.   Above you refer to a client checking its own certificate in order to find an appropriate one to use for an SSID. And now this is the use case you claim is ludicrous. EXACTLY!   Asking a CA to certify something that is ambiguous and unverifiable in order to use it yourself is ludicrous. >>> I would *also* argue that this information can be placed in a server certificate, for situations when client certificates are not being used. As discussed extensively previously on this list, a client can connect to an SSID, obtain the server cert, and then verify: >> Yea, and that's why I gave you the list of actions a client takes and asked >> you to point out where in the list this happens. You deleted the list. > Yes. Because I gave an explanation of how it works. I want to be sure that the explanation is understood before going into further details. > > If my explanation makes no sense, then there's no point in me discussing technical details.   It doesn't make sense because it's too late. You can't use unverifiable information in a certificate you have not yet obtained in order to make a network connection decision. So this unverifiable and ambiguous nonsense you want to put in a certificate is for a client certificate and that use case is, as you note, ludicrous. >> I'm not proposing to prevent you from doing anything. I'm asking what's the point >> and why. You didn't really provide one. And good luck getting a public CA to put >> ambiguous and unverifiable information in a certificate for you. > I've already addressed these points. Please see my previous messages. > > I think this horse has been beaten to death. I don't see any point in continuing it, unless there is progress.   I think we have made progress and closure. The use case for unverifiable and ambiguous nonsense in a certificate is ludicrous.   Dan. From nobody Fri Nov 22 01:33:02 2019 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 B0B1B12091D for ; Fri, 22 Nov 2019 01:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3yFcenU11b2 for ; Fri, 22 Nov 2019 01:32:56 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241531208F8 for ; Fri, 22 Nov 2019 01:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2671; q=dns/txt; s=iport; t=1574415175; x=1575624775; h=from:mime-version:subject:message-id:date:to; bh=83xUy0JDNYut1KB0z5u7HtF8agSuLAut8mU6DZ+BOdA=; b=MkgCAeXm2riddAG+DaP6npR+ZKE99Q2hgMkZDG8UCjsPqZsRjHM6nJRl hN7y6SBOSmKa7ulm1fZpEyuOMcW1pM3yFB8Y72wMf+wynakwgjt1YqORj VJgGjQtV9jqSANgMnsUv072y9wwp6o8btil6xojZVb0Z80AQg0h1rtmj1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAABDRNdd/xjFo0hkGgEBAQEBAQEBA?= =?us-ascii?q?QMBAQEBEQEBAQICAQEBAYF+g2EgEiqEKokDh22TRIgLCQEBAQwBAS8BAYcOOBM?= =?us-ascii?q?CEAEBBAEBAQIBBQRthUOFUwQkWxoBPQJfE4MiglggnxOODHWBMoVOhHuBNowwg?= =?us-ascii?q?X+BEScME4pfMoIsBJcklwyCNQOCNJMZG44+i1qlOIMcAgQGBQIVgWkigVgzGgg?= =?us-ascii?q?bFWUBgkE+EhEUhlMYjjA0AzCRRQEB?= X-IronPort-AV: E=Sophos;i="5.69,229,1571702400"; d="scan'208,217";a="132052913" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Nov 2019 09:32:51 +0000 Received: from [10.68.215.213] ([10.68.215.213]) by bgl-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xAM9LBpZ032466 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 22 Nov 2019 09:21:12 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_4AEB63CF-BFDB-43E8-B09C-DEB583057ED8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: <7E638208-B23C-4740-B51D-96CDF959BC71@cisco.com> Date: Fri, 22 Nov 2019 17:21:10 +0800 To: EMU WG X-Mailer: Apple Mail (2.3601.0.10) X-Outbound-SMTP-Client: 10.68.215.213, [10.68.215.213] X-Outbound-Node: bgl-core-1.cisco.com Archived-At: Subject: [Emu] Processing of TEWAP erratum 5127 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: Fri, 22 Nov 2019 09:33:01 -0000 --Apple-Mail=_4AEB63CF-BFDB-43E8-B09C-DEB583057ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have been reviewing this erratum, and I think it is correct, but I = have a question: > Section 5.2. says: >=20 > IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | > "\0" | 64) > It should say: >=20 > IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | > "\0", 64) Is that last parameter =E2=80=9Cseed=E2=80=9D or =E2=80=9Cseed size=E2=80=9D= ? Confusedly yours. Eliot > Notes: >=20 > According to >=20 > RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 >=20 > 5. HMAC and the Pseudorandom Function >=20 > "TLS's PRF is created by applying P_hash to the secret as: >=20 > PRF(secret, label, seed) =3D P_(secret, label + seed)"=20 --Apple-Mail=_4AEB63CF-BFDB-43E8-B09C-DEB583057ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I have been reviewing this erratum, and I think it is = correct, but I have a question:

Section = 5.2. says: 

IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" =
|
     "\0" | 64)

It should say:

IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" =
|
     "\0", 64)

Is that last = parameter =E2=80=9Cseed=E2=80=9D or =E2=80=9Cseed size=E2=80=9D? =  Confusedly yours.

Eliot

Notes:

According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) =3D P_<hash>(secret, label + = seed)" 

= --Apple-Mail=_4AEB63CF-BFDB-43E8-B09C-DEB583057ED8-- From nobody Fri Nov 22 05:23:45 2019 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 8635D120047 for ; Fri, 22 Nov 2019 05:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LusR-dzjTUt for ; Fri, 22 Nov 2019 05:23:42 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C853D1200B1 for ; Fri, 22 Nov 2019 05:23:42 -0800 (PST) Received: from [192.168.20.151] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id BED764BD; Fri, 22 Nov 2019 13:23:39 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <87f583a4-cb0a-5d83-b8db-9e6d48b29ba9@lounge.org> Date: Fri, 22 Nov 2019 08:23:38 -0500 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D9B3458-9EAC-4080-8F0C-37748947EF56@deployingradius.com> References: <102dd850-b1ae-3426-8189-45876b7b419d@uni-bremen.de> <8147b718-23d6-07de-a565-08bcc8148095@uni-bremen.de> <08da27e5-518e-b6a4-a97a-b4ae9c32ed00@uni-bremen.de> <46C8D8C4-7317-47F3-8F9B-6C56F7B7FEE9@vigilsec.com> <9907D136-C262-48BC-8630-0EABC0EB97F5@deployingradius.com> <339ba466-d24c-6950-3271-68dc71cfcba8@lounge.org> <822C82FA-4AF5-4BAF-8A19-40CE0E57B391@deployingradius.com> <13edb98a-36d8-d616-77dd-75d16ab6ff58@lounge.org> <20c3dea6-d0e9-3b0c-c6dc-e3ae54e8a067@lounge.org> <550761BD-37C9-4EE4-9503-02DF4E4675D6@deployingradius.com> <87f583a4-cb0a-5d83-b8db-9e6d48b29ba9@lounge.org> To: Dan Harkins X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS 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: Fri, 22 Nov 2019 13:23:44 -0000 On Nov 21, 2019, at 7:39 PM, Dan Harkins wrote: > I think we have made progress and closure. No. The word "unverifiable" is not a magic wan that you can use to win any = argument. Your description of what I'm proposing does not match what I'm = actually proposing. Alan DeKok. From nobody Sun Nov 24 03:31:53 2019 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 B36A012011A for ; Sun, 24 Nov 2019 03:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC580hXwkDsW for ; Sun, 24 Nov 2019 03:31:51 -0800 (PST) Received: from li674-96.members.linode.com (mail.w1.fi [212.71.239.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9069120115 for ; Sun, 24 Nov 2019 03:31:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by li674-96.members.linode.com (Postfix) with ESMTP id C224511E14; Sun, 24 Nov 2019 11:31:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at w1.fi Received: from li674-96.members.linode.com ([127.0.0.1]) by localhost (mail.w1.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiswwycelLmC; Sun, 24 Nov 2019 11:31:44 +0000 (UTC) Received: by jm (sSMTP sendmail emulation); Sun, 24 Nov 2019 13:31:42 +0200 Date: Sun, 24 Nov 2019 13:31:42 +0200 From: Jouni Malinen To: Eliot Lear Cc: EMU WG Message-ID: <20191124113142.GA4381@w1.fi> References: <7E638208-B23C-4740-B51D-96CDF959BC71@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7E638208-B23C-4740-B51D-96CDF959BC71@cisco.com> Archived-At: Subject: Re: [Emu] Processing of TEWAP erratum 5127 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: Sun, 24 Nov 2019 11:31:53 -0000 On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot Lear wrote: > I have been reviewing this erratum, and I think it is correct, but I have a question: > > > Section 5.2. says: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | > > "\0" | 64) > > It should say: > > > > IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | > > "\0", 64) > > Is that last parameter “seed” or “seed size”? Confusedly yours. It's neither.. The main problem here is in RFC 7170 not defining TLS-PRF() properly. All it says is "TLS-PRF is the PRF negotiated as part of TLS handshake" while RFC 5246 does not define PRF as a function with arguments that would be compatible with even a single instance of TLS-PRF() use in RFC 7170.. And the RFC 7170 uses are inconsistent with themselves like this erratum show, but this instance is not the only issue: TLS-PRF() is used with two, three, and even four arguments. This leaves the implementer guessing what exactly these maps to.. > > RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 > > 5. HMAC and the Pseudorandom Function > > "TLS's PRF is created by applying P_hash to the secret as: > > PRF(secret, label, seed) = P_(secret, label + seed)" So this PRF(secret, label, seed) is what is available and RFC 5246 does not define that 64 part in the example above as an argument. That 64 is the number of octets of output that is fetched from the PRF. In other words, RFC 7170 should have defined TLS-PRF(secret, label, seed, output-len-in-octets) as taking output-len-in-octets of octets from the output of RFC 5246 PRF(secret, label, seed). With this, following fixes would be needed for the users for TLS-PRF() in RFC 7170: IMSK: This could be one of following (last two having identical outcome): TLS-PRF(EMSK, "TEAPbindkey@ietf.org", "", 64) TLS-PRF(EMSK, "TEAPbindkey@ietf.org", "\0", 64) TLS-PRF(EMSK, "TEAPbindkey@ietf.org", "\0" | 0x00 | 0x40, 64) TLS-PRF(EMSK, "TEAPbindkey@ietf.org", 0x00 | 0x00 | 0x40, 64) However, this TLS-PRF() instance is more strange.. The "Optional data parameter is not used in the derivation" part does not make any sense since I think "optional data parameter" is a reference to the seed value going into PRF. The following description is then clearly indicating that "\0" is 0x00 and length (that | 64) is "2-octet unsigned integer in network byte order". That seems to be talking about some binary data and the seed is the only place where such byte order and field size discussion would apply. I'm actually implementing that last one because of that discussion in the RFC. It should also be noted that the "First 32 octets of TLS-PRF(..., 64)" does not make much sense since "TLS-PRF(..., 32)" would cover same. This would seem to imply that "First 32 octets of TLS-PRF" could actually be trying to address that PRF argument mismatch. Anyway, maybe this should simply say: IMSK = TLS-PRF(EMSK, "TEAPbindkey@ietf.org", 0x00 | 0x00 | 0x40, 32) (or with empty seed "" instead of that 3 octet seed) The "and the length is 64 octets" part just above this is a bit confusing with this, though. IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) (this is actually unchanged) MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", "", 64) (i.e., add the missing empty seed) EMSK = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function", "", 64) (i.e., add the missing empty seed) -- Jouni Malinen PGP id EFC895FA From nobody Mon Nov 25 05:43:45 2019 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 9633A120885 for ; Mon, 25 Nov 2019 05:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA3Eu4Y2cZsh for ; Mon, 25 Nov 2019 05:41:14 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A0F12018D for ; Mon, 25 Nov 2019 05:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71086; q=dns/txt; s=iport; t=1574689273; x=1575898873; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=MdpWwQG9Wi6Kj6yj8DdcTjLtoGntSGP4M7iTMlW4tuA=; b=iz4e2xLOAZzsDGLXeGynUbgGloca0XfJllgYoxBOTkTmfOUMnxbiOazj 5Xku98u4K0ZIHHGAM4euUge1Zr21BZF1WZ97uYXsdKhtSDfL6A1U3X0ZB FyKOwn6V84QScZbhG0UyXBZnKa2R+okshBAe256rGCn1rB67JfFnCgCr+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BJAABO2dtd/xbLJq1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgX6BHIJEASASKoQriQOIEpstCQEBAQw?= =?us-ascii?q?BAS8BAYRAAoJSOBMCAw0BAQQBAQECAQUEbYULCDCFUgEBAQECASNWBQsLDgo?= =?us-ascii?q?gAQYDAgJGEQYTgyKCWCCvfHWBMoVPhQOBNowwgX+BEScggh4uPoR/gloygiw?= =?us-ascii?q?EnySPDoI1gjiKC4kRG4I/h2qEF4tcpTuDHQIEBgUCFYFpIoFYMxoIGxVlAYJ?= =?us-ascii?q?BPhIRFIR0gV8YjiRAAzCOTQEB?= X-IronPort-AV: E=Sophos; i="5.69,241,1571702400"; d="scan'208,217"; a="19546802" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2019 13:41:11 +0000 Received: from [10.61.214.19] ([10.61.214.19]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xAPDfAdq006720 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Nov 2019 13:41:11 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_725514E0-485E-4E9E-91EB-2ACB010C21A6" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 25 Nov 2019 14:41:10 +0100 In-Reply-To: <20191124113142.GA4381@w1.fi> Cc: EMU WG To: Jouni Malinen References: <7E638208-B23C-4740-B51D-96CDF959BC71@cisco.com> <20191124113142.GA4381@w1.fi> X-Mailer: Apple Mail (2.3601.0.10) X-Outbound-SMTP-Client: 10.61.214.19, [10.61.214.19] X-Outbound-Node: aer-core-1.cisco.com Archived-At: X-Mailman-Approved-At: Mon, 25 Nov 2019 05:43:44 -0800 Subject: Re: [Emu] Processing of TEWAP erratum 5127 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: Mon, 25 Nov 2019 13:41:17 -0000 --Apple-Mail=_725514E0-485E-4E9E-91EB-2ACB010C21A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juoni, Thanks for taking the time. I suspect this will take a few iterations = to get the actual text right, as I am drinking water from a fire hose = here. Please bear with me. > On 24 Nov 2019, at 12:31, Jouni Malinen wrote: >=20 > On Fri, Nov 22, 2019 at 05:21:10PM +0800, Eliot Lear wrote: >> I have been reviewing this erratum, and I think it is correct, but I = have a question: >>=20 >>> Section 5.2. says: >>>=20 >>> IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | >>> "\0" | 64) >>> It should say: >>>=20 >>> IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | >>> "\0", 64) >>=20 >> Is that last parameter =E2=80=9Cseed=E2=80=9D or =E2=80=9Cseed = size=E2=80=9D? Confusedly yours. >=20 > It's neither.. The main problem here is in RFC 7170 not defining > TLS-PRF() properly. All it says is "TLS-PRF is the PRF negotiated as > part of TLS handshake" while RFC 5246 does not define PRF as a = function > with arguments that would be compatible with even a single instance of > TLS-PRF() use in RFC 7170.. > And the RFC 7170 uses are inconsistent with > themselves like this erratum show, but this instance is not the only > issue: TLS-PRF() is used with two, three, and even four arguments. Indeed. So that we=E2=80=99re clear, here they are: Section 5.2: IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | "\0" | 64) 2 args. Later, same section: IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) 4 args. And then further down: MSK =3D TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) EMSK =3D TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function", 64) 3 args. And 5246 says: PRF(secret, label, seed) =3D P_(secret, label + seed) And so I agree with you that nowhere is there a length field for the = return value in RFC 5246. > This > leaves the implementer guessing what exactly these maps to.. >=20 >>> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 >>> 5. HMAC and the Pseudorandom Function >>> "TLS's PRF is created by applying P_hash to the secret as: >>> PRF(secret, label, seed) =3D P_(secret, label + seed)"=20 >=20 > So this PRF(secret, label, seed) is what is available and RFC 5246 = does > not define that 64 part in the example above as an argument. That 64 = is > the number of octets of output that is fetched from the PRF. >=20 > In other words, RFC 7170 should have defined TLS-PRF(secret, label, > seed, output-len-in-octets) as taking output-len-in-octets of octets > from the output of RFC 5246 PRF(secret, label, seed). With this, > following fixes would be needed for the users for TLS-PRF() in RFC = 7170: >=20 > IMSK: > This could be one of following (last two having identical outcome): > TLS-PRF(EMSK, "TEAPbindkey@ietf.org ", = "", 64) > TLS-PRF(EMSK, "TEAPbindkey@ietf.org ", = "\0", 64) > TLS-PRF(EMSK, "TEAPbindkey@ietf.org ", = "\0" | 0x00 | 0x40, 64) > TLS-PRF(EMSK, "TEAPbindkey@ietf.org ", = 0x00 | 0x00 | 0x40, 64) >=20 > However, this TLS-PRF() instance is more strange.. The "Optional data > parameter is not used in the derivation" part does not make any sense > since I think "optional data parameter" is a reference to the seed = value > going into PRF. Could it be that this text refers to RFC 5295: > If an inner method supports export of an Extended Master Session Key > (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in > [RFC5295]. The usage label used is "TEAPbindkey@ietf.org", and the > length is 64 octets. Optional data parameter is not used in the > derivation. USRK =3D KDF(EMSK, key label | "\0" | optional data | length) Which perhaps is meant to translate to: IMSK =3D KDF(EMSK, =E2=80=9CTEAPbindkey@ietf.org = =E2=80=9D, 64) But again, only when the inner method supports export of the EMSK. Note = the text below, by the way: > USRKs MUST be at least 64 octets in length. However we interpret the text, it seems that either the argument count = is wrong or the function is wrong. > The following description is then clearly indicating > that "\0" is 0x00 and length (that | 64) is "2-octet unsigned integer = in > network byte order". That seems to be talking about some binary data > and the seed is the only place where such byte order and field size > discussion would apply. I'm actually implementing that last one = because > of that discussion in the RFC. >=20 > It should also be noted that the "First 32 octets of TLS-PRF(..., 64)" > does not make much sense since "TLS-PRF(..., 32)" would cover same. = This > would seem to imply that "First 32 octets of TLS-PRF" could actually = be > trying to address that PRF argument mismatch. Anyway, maybe this = should > simply say: >=20 > IMSK =3D TLS-PRF(EMSK, "TEAPbindkey@ietf.org = ", 0x00 | 0x00 | 0x40, 32) > (or with empty seed "" instead of that 3 octet seed) I=E2=80=99m really not sure what adding a known seed gets us at this = point. >=20 > The "and the length is 64 octets" part just above this is a bit > confusing with this, though. >=20 >=20 >=20 >=20 > IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", = IMSK[j], 60) > (this is actually unchanged) >=20 > MSK =3D TLS-PRF(S-IMCK[j], "Session Key Generating Function", "", 64) > (i.e., add the missing empty seed) >=20 > EMSK =3D TLS-PRF(S-IMCK[j], > "Extended Session Key Generating Function", "", 64) > (i.e., add the missing empty seed) On the last two, entropy is thus borrowed from S-IMCK[j]. Correct? I = don=E2=80=99t have the full flow in my head, but are these indepedently = generated on both sides, right? If so, I don=E2=80=99t see any other = alternative to what you are suggesting. Eliot= --Apple-Mail=_725514E0-485E-4E9E-91EB-2ACB010C21A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Juoni,

Thanks for = taking the time.  I suspect this will take a few iterations to get = the actual text right, as I am drinking water from a fire hose here. =  Please bear with me.

On 24 Nov 2019, at 12:31, Jouni = Malinen <j@w1.fi> = wrote:

On Fri, Nov 22, 2019 at = 05:21:10PM +0800, Eliot Lear wrote:
I have been reviewing this erratum, = and I think it is correct, but I have a question:

Section 5.2. says:

IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" = |
    "\0" | 64)
It = should say:

IMSK =3D First 32 octets of = TLS-PRF(EMSK, "TEAPbindkey@ietf.org" |
    "\0", 64)

Is that last parameter =E2=80=9Csee= d=E2=80=9D or =E2=80=9Cseed size=E2=80=9D?  Confusedly yours.

It's neither.. The main problem here is in RFC 7170 not = defining
TLS-PRF() = properly. All it says is "TLS-PRF is the PRF negotiated as
part of TLS handshake" while RFC = 5246 does not define PRF as a function
with arguments that would be compatible with even a single = instance of
TLS-PRF() use = in RFC 7170..


And the RFC 7170 uses are = inconsistent with
themselves like this erratum show, but this instance is not = the only
issue: = TLS-PRF() is used with two, three, and even four arguments. =


Indeed.  So that we=E2=80=99re clear, here they = are:

Section 5.2:
 IMSK =3D First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" = |
     "\0" | 64)


2 args.

Later, = same section:

IMCK[j] = =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
                = IMSK[j], 60)

4 args.

And then further down:

 MSK  =3D TLS-PRF(S-IMCK[j], "Session Key = Generating Function", 64)
 EMSK =3D TLS-PRF(S-IMCK[j],
           "Extended Session = Key Generating Function", 64)


3 = args.


And 5246 says:

PRF(secret, label, seed) =3D = P_<hash>(secret, label + seed)

And so I agree with you that nowhere is = there a length field for the return value in RFC 5246.


This
leaves the implementer guessing what exactly these maps = to..

RFC5246 The Transport = Layer Security (TLS) Protocol Version 1.2
5. HMAC and the = Pseudorandom Function
"TLS's PRF is created by applying = P_hash to the secret as:
PRF(secret, label, seed) =3D = P_<hash>(secret, label + seed)" 

So this PRF(secret, label, seed) is what is available and RFC = 5246 does
not define = that 64 part in the example above as an argument. That 64 is
the number of octets of output = that is fetched from the PRF.

In other words, RFC 7170 should have defined TLS-PRF(secret, = label,
seed, = output-len-in-octets) as taking output-len-in-octets of octets
from the output of RFC 5246 = PRF(secret, label, seed). With this,
following fixes would be needed for the users for TLS-PRF() = in RFC 7170:

IMSK:This could be one of following = (last two having identical outcome):
TLS-PRF(EMSK, "TEAPbindkey@ietf.org", "", 64)
TLS-PRF(EMSK, "TEAPbindkey@ietf.org", "\0", 64)
TLS-PRF(EMSK, "TEAPbindkey@ietf.org", "\0" | 0x00 | 0x40, 64)
TLS-PRF(EMSK, "TEAPbindkey@ietf.org", 0x00 | 0x00 | 0x40, 64)

However, this TLS-PRF() instance is more strange.. The = "Optional data
parameter is not used in the derivation" part does not make = any sense
since I think = "optional data parameter" is a reference to the seed value
going into PRF. =


Could it be that this text refers to RFC = 5295:

 If = an inner method supports export of an Extended Master Session = Key
 (EMSK), then the IMSK SHOULD be derived from the EMSK = as defined in
 [RFC5295].  The usage label used = is "TEAPbindkey@ietf.org", and the
 length is 64 octets.  Optional data = parameter is not used in the
 derivation.

USRK =3D KDF(EMSK, key label | "\0" | = optional data | length)

Which = perhaps is meant to translate to:

IMSK =3D = KDF(EMSK, =E2=80=9CTEAPbindkey@ietf.org=E2=80=9D, 64)

But again, only when the inner method supports export of the = EMSK.  Note the text below, by the way:

USRKs = MUST be at least 64 octets in length.


However we interpret the text, it seems that either the = argument count is wrong or the function is wrong.

The following = description is then clearly indicating
that "\0" is 0x00 and length (that | 64) is "2-octet unsigned = integer in
network byte = order".  That seems to be talking about some binary data
and the seed is the only place = where such byte order and field size
discussion would apply. I'm actually implementing that last = one because
of that = discussion in the RFC.

It should also be noted that the "First 32 octets of = TLS-PRF(..., 64)"
does not make much sense since "TLS-PRF(..., 32)" would cover = same. This
would seem to = imply that "First 32 octets of TLS-PRF" could actually be
trying to address that PRF = argument mismatch. Anyway, maybe this should
simply say:

IMSK =3D TLS-PRF(EMSK, = "TEAPbindkey@ietf.org", 0x00 | 0x00 | 0x40, = 32)
(or with = empty seed "" instead of that 3 octet = seed)

I=E2=80=99m = really not sure what adding a known seed gets us at this = point.


The "and the = length is 64 octets" part just above this is a bit
confusing with this, = though.




IMCK[j] =3D = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], = 60)
  (this is actually unchanged)

MSK =3D TLS-PRF(S-IMCK[j], = "Session Key Generating Function", "", 64)
  (i.e., add the missing empty seed)

EMSK =3D = TLS-PRF(S-IMCK[j],
          "Ex= tended Session Key Generating Function", "", 64)
  (i.e., add the = missing empty seed)


On the last two, entropy is = thus borrowed from S-IMCK[j].  Correct?  I don=E2=80=99t have = the full flow in my head, but are these indepedently generated on both = sides, right?  If so, I don=E2=80=99t see any other alternative to = what you are suggesting.

Eliot
= --Apple-Mail=_725514E0-485E-4E9E-91EB-2ACB010C21A6-- From nobody Tue Nov 26 05:08:15 2019 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 656991208C2 for ; Tue, 26 Nov 2019 05:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-P0V1xbx42h for ; Tue, 26 Nov 2019 05:08:11 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370341208C1 for ; Tue, 26 Nov 2019 05:08:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CWfNlmV1Md4xnlG8FhORsvmtTORWaLeoqXhZbjZDLePAfwiZJ/eXqVhWK8E4IKo7XzwySTeIlss5qXBmb/WzTV3o4lLJkGMxQgzvOgL0Z2+w48v/QaMdnrg0ig3qrXLc8N1fOznYlHY434qIXsO1xATt9jCZ/aXg4Rily5E+iMlL22IZNl6/8v6OH4TRwvz99IaPX5DrSzH8BaaooURoU2XeXKV/q6KyceM1UlTnpIlp5CSozHnEJaeEs9Y5YCqqHVdE7n7bwBztUTniH5a/SFfo9tNxpg81mAxvBs8EsLmR7jgMbf8dTs++8uiz6781XrOZE3kGsb6dkChVWcPxjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RL6vo1fQk7Pbc1vLcbxHYRReevwd89tLh1uzPTGT34A=; b=noK1aa2eHpDg165wR5odeLa1ULCu2mDFFLo2QDc4Uopavon3waEnJmvM2QECIpTfCxAznHDT/7JdeO8Q9HRLTFlRv0NwBecI4rbFgFEEwKD4HW3+V7wrXxge1V5xba0exsQt5zOoZb1j/ST5v8osL33G4y+J7+yh3cbCvCKHvT67Za1TmzPIKXtMaVtVv4k+KA5k10A4bV/+nNpYojjPRx6s43wza5K/W6SUJO8q0Naw2bRfE1aBnZrQOarbtYh8ngoBaGJUH9C0ufKO3yMe3Xe47x0V15aHrnP+hM9gpWcRUyg75S89biw9lc3HNONwAn/kiw3I10snMesj4xf6mQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RL6vo1fQk7Pbc1vLcbxHYRReevwd89tLh1uzPTGT34A=; b=mIAYDq7aGq1hG9J93Tk7PEZ6VzMTqKcu6hn8t6KE16jPD1dq+XmH3+gAAsTgXl0m1yS89kiShsXiPnqoGgU3gFTvwkYrzz1CKVpynBw5EzovC4gtK4VAIn3eOimkFl6FA/kZCUE5rmETB19nXVdoPccZmW/xFo54SjXEX56ZWvs= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2570.eurprd07.prod.outlook.com (10.168.187.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.16; Tue, 26 Nov 2019 13:08:08 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e%6]) with mapi id 15.20.2495.014; Tue, 26 Nov 2019 13:08:08 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: WGLC for draft-ietf-emu-eap-session-id-01 Thread-Index: AQHVpFqMI1yTZMmdm068bwW6HgCCZQ== Date: Tue, 26 Nov 2019 13:08:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [85.131.107.249] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5dec8d91-b015-4e1a-0c4a-08d77271aee5 x-ms-traffictypediagnostic: HE1PR0701MB2570: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(189003)(199004)(6436002)(102836004)(6506007)(26005)(81166006)(65806001)(8936002)(66066001)(65956001)(2351001)(5660300002)(81156014)(1730700003)(7736002)(8676002)(71200400001)(186003)(71190400001)(99286004)(305945005)(58126008)(31686004)(36756003)(14454004)(2616005)(413944005)(316002)(478600001)(86362001)(6486002)(2906002)(3846002)(6116002)(6512007)(2501003)(66946007)(6916009)(4744005)(66446008)(66476007)(66556008)(31696002)(64756008)(25786009)(6306002)(5640700003)(256004)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2570; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yZu+iXF+Db/IbhEga4xWvwLbYUxjUgLabhBZTphARdg+mBt3n2no6zN0Hjow4UlEAf8TfAGQ/LhI5JoeO8YS3VXgWicRQEduL/QufQ/Ypi/J5vn6sZwp9INFrqS+W9IC/YVQ71rlhdSv7r/6iuytQ+lOHfs61wO9K4Cw1hIkCsPkogRkQLTBmAfM3W/cOJ96hVYfPft/YOnAxhT++DS7S1/AqkGZKwtR1bZ1Yy79SZgMERnWMd2je0Ai0Qb3SYmSCLk8DnOredLjneHJY0IKLsfbOVizpLIKaD5kDZ0wQ1eUJOTtSsj1Me6845mmCAlD8SBj01rce+Yyei4EmbAG9bJsveKc7fxSWgDEnjP1zXBxyLhW/Qez3OvvfacPaH2/+In19DPXhNMkgk3daoogeT+1i5TJjhFD5grIxVBCDWECo9sdkOiBy9xmP7R72TtU4g8/+gZA6agN4C2alnHo+CXkfELgCZcgR9kPJgyIGKw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5dec8d91-b015-4e1a-0c4a-08d77271aee5 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 13:08:08.5782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rbC2K5E3xlkv0HzUVXWATk7Ito2Fh/2ITrmNbxATWpS50rRVDSPsuDuuyzX//FYRtZTrK6J1bsPb/0DKnxljO8alOekw0oA7JEF5EEFLDa8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2570 Archived-At: Subject: [Emu] WGLC for draft-ietf-emu-eap-session-id-01 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: Tue, 26 Nov 2019 13:08:13 -0000 RGVhciBhbGwsDQoNClRoaXMgZW1haWwgaW5pdGlhdGVzIHRoZSB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCAoV0dMQykgZm9yIA0KZHJhZnQtaWV0Zi1lbXUtZWFwLXNlc3Npb24taWQgDQooaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZW11LWVhcC1zZXNzaW9uLWlkLTAxKS4w DQoNCklmIHlvdSBoYXZlIGFueSByZW1haW5pbmcgY29uY2VybnMgb3IgaXNzdWVzLCBwbGVhc2Ug Y29tbWVudCBvbiB0aGUgDQptYWlsaW5nIGxpc3QgYmVmb3JlIHRoZSBXR0xDIGV4cGlyZXMgb24g RGVjZW1iZXIgMTAsIDIwMTkuDQoNClRoYW5rcywNCkpvZSBhbmQgTW9oaXQNCg0K From nobody Tue Nov 26 05:22:34 2019 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 2BF0312012D for ; Tue, 26 Nov 2019 05:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BzparoKtcEl for ; Tue, 26 Nov 2019 05:22:31 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on062b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E5412012C for ; Tue, 26 Nov 2019 05:22:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LHauaZYcYr+UA00Cxbh6KP4s0YjAZxNkDSbwqaEvAmFKXFFDdLIEVo7colRdk8/SlyUZH2Xfvi/eETaTPsJ8id+vn+3rogt+Cdz1Kbc08lm5E7EpVTMmWn8HnKwlxF/hHopzoWtlgyo8AajgOTfT5Uw++shtMu2vZfNitEb0Nxus7+GnfrgQR+NKV6Rupo1xSIIw+RbWnrkGU9dp/zfz4K5bUK/dA/brImkb667cUF3EiC56LG0lQs4yL4iu8v9oVsR1WgVKuu7Y6hhKkxUsdoD0CGtl3roT7wyY4nXgP0oGgHFuS/y9TlUoQkw+/t4rQOu14/f5RxJe6R4hkfdeJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/mc9CHFCbdUM+N/hwxA/VRxOGoOONWHRfe2NBrFl52k=; b=jiAPGAvq/2hzznSk5HOhfVHcI6c4FIFSFwPEFAz4TvFwHl+p9op+8R0k5l9Kvohmlhc12GpKGLs/1D1JXSYabiD36+miTB9Lif/1hMNzOv5wNDhAzSAZQgk3LIQyvbmSrCR72A11OCZo7ZE38CDktHkBsf6POnniyUWS7DZmTvITpwMqXBeWqdJ7m1AKOHQ1aftYohg26ZdkpjZ3HmYuz2/9TBad+dgYIqOVadxgNnxsDnP2rvBppD834HLHEcNkgX9LmlIJ2HkpwBgBUidJqhuZZlol7r4ZnorgEWltCVfs6Y8HRvnAu8jWgl9RccGdBEWp6OO2JDxPZp6FZXzP6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/mc9CHFCbdUM+N/hwxA/VRxOGoOONWHRfe2NBrFl52k=; b=EMpRENXJ8kSoppOWkYgF4YB8SuJv5sAATq+/vrOvtirTphM217ObGd4OZ+fh6cx7apFcVf/GovQQb7cbtE7BiSKUU8g2GJTSpcLf5E3sw1kTJDafEsAmtF6hphpME4MPKCzdQqeCNpV+U/8ZYWHEE9IfF5jJgA7LFdose3Qqe6g= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2492.eurprd07.prod.outlook.com (10.168.128.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Tue, 26 Nov 2019 13:22:28 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e%6]) with mapi id 15.20.2495.014; Tue, 26 Nov 2019 13:22:28 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: Minutes from EMU @ IETF106 Thread-Index: AQHVpFyMaBavQLBzHkmVCuIkyGlO8Q== Date: Tue, 26 Nov 2019 13:22:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [85.131.107.249] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: facb838c-f6fd-44a2-d846-08d77273af50 x-ms-traffictypediagnostic: HE1PR0701MB2492: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(136003)(396003)(189003)(199004)(53754006)(6116002)(65806001)(86362001)(65956001)(3846002)(14454004)(66066001)(6512007)(6306002)(31696002)(2501003)(305945005)(6486002)(5660300002)(2616005)(7736002)(256004)(5640700003)(25786009)(966005)(478600001)(6916009)(71200400001)(71190400001)(6436002)(4744005)(2906002)(31686004)(102836004)(8936002)(1730700003)(186003)(81156014)(2351001)(26005)(36756003)(8676002)(81166006)(99286004)(76116006)(316002)(58126008)(66476007)(66556008)(66446008)(6506007)(66946007)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2492; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K/A1g3pQGPsKViZFW0yBJBugHRcprgz9HJ62nx/tSN+mleax5pzBaBVFktbQKwCSFvfajS7WfPa20Zd3gFq1sTA8lKVkFJLOCIAYpJtaNeYlrBUHkKAfqg09pb7hj6H6vC4ksY6T6p1+RRle9f3l1DYHu+dnEUQDUhlGYj7u55JJC0NdZiucF/iBDtJOmgtZZyvVopGQC6Dll56bp1kugUp13GvFcNJIk9ZRJLO7scwevz9KN4eu/UZN4HLulanrLY0mTTjc8/2k/jgtZKAmVvexGubpv9Ir60bdHUhZrBqU7ZZpTXxDtDd1AoIanatSmFfM+q/ZCSlZKFxNnUjYwDXTI/0co0I66rbh4oUjyPCNFdvR9Ms8u8gJhe4lrnSlKUfKM3ByFjPhDmZltrUeLHg+38HfgSoQWHvbMMicp6MB4Uxp9GCJeRVVY1vpMJG22Zr/MoB+963d6wwMwyEvLIp2hFjTWqsO0UXOkuxa088= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: facb838c-f6fd-44a2-d846-08d77273af50 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 13:22:28.3311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: L4xxkX7L9zkDLd4yM1JU1B5dDY/P+qd/bk37JqQB6bYJjLkFiG8HZI3hX9xto0hfju80joEIRcrHR+j2QK6ZbiYG3KIlbAjLjxAwG1lC1Qo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2492 Archived-At: Subject: [Emu] Minutes from EMU @ IETF106 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: Tue, 26 Nov 2019 13:22:33 -0000 SGkgYWxsLA0KDQpUaGFuayB5b3UgZm9yIHBhcnRpY2lwYXRpbmcgaW4gdGhlIEVNVSBzZXNzaW9u IGF0IElFVEYgMTA2LiBBIHNwZWNpYWwgDQp0aGFuayB5b3UgdG8gRWxpb3QgZm9yIHZvbHVudGVl cmluZyBhcyB0aGUgbWludXRlIHRha2VyLg0KDQpNZWV0aW5nIG1pbnV0ZXMgZnJvbSB0aGUgRU1V IHNlc3Npb24gYXQgSUVURiAxMDYgaGF2ZSBub3cgYmVlbiB1cGxvYWRlZDoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDYvbWF0ZXJpYWxzL21pbnV0ZXMtMTA2LWVtdS0w MA0KDQpQbGVhc2UgcmVwb3J0IGFueSBpc3N1ZXMgYnkgRGVjZW1iZXIgMywgMjAxOS4NCg0KSm9l IGFuZCBNb2hpdA0KDQo=