From nobody Fri Aug 3 02:15:34 2018 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 1A0DB1294D7 for ; Fri, 3 Aug 2018 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 zFaPPBOuLQnV for ; Fri, 3 Aug 2018 02:15:30 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D35D01277D2 for ; Fri, 3 Aug 2018 02:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533287728; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TrwRKWHVkGjXeKIF29bRl4QqC90iZXQXKPIOd2/aKR0=; b=Zr97Zig+0UH7XlcCwBE67v3OQGS83VGTgF7rUdTr34ICSW1wcFiBKyOtB9Tu8OPQ +QLtuiJcCLulTVMG7z6js5BxBBOaHn6VGUFRyDBvQ31lgJtg8ryWcmy0rB1bVJjG Fe1f1J0KHdlD7+U6O4ifpBZ0R5lQrxlwr/AheOrxI9M=; X-AuditID: c1b4fb30-5cb039c0000059c2-43-5b641d305e72 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.6F.22978.03D146B5; Fri, 3 Aug 2018 11:15:28 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 3 Aug 2018 11:15:27 +0200 Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.184) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 3 Aug 2018 11:15:27 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id AE26A480AB6 for ; Fri, 3 Aug 2018 12:15:27 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 655BD480A1D for ; Fri, 3 Aug 2018 12:15:27 +0300 (EEST) From: Mohit Sethi To: Message-ID: <3f5dac0a-609f-8bb2-8321-2c0018edd87c@ericsson.com> Date: Fri, 3 Aug 2018 12:15:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM2J7ua6BbEq0wbpz3BbH1q9lcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpWNT5kLGjUr9jT8ZGpgnK3YxcjJISFgInFr5lXWLkYuDiGB o4wSbxddZARJCAl8ZZTo+KsNkbjAKDGjYS47hHOMUWLN3Y1sEM4WRonZW78zg7SwCehJdJ47 DmYLC2hLvG39xgZiiwgISVxb/xJsLK+AvUTD9S1Akzg4WARUJBpf5YCERQUiJFYvf8EKUSIo cXLmExYQm1nAQmLm/POMELa2xLKFr5khbHGJW0/mM0G8oCyxoGUR1NXqEls7DjBOYBSahWTU LCSjZiEZNQvJqAWMLKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAsP54JbfBjsYXz53PMQo wMGoxMN7RSglWog1say4MvcQowQHs5II79vO5Ggh3pTEyqrUovz4otKc1OJDjNIcLErivBZ+ m6OEBNITS1KzU1MLUotgskwcnFINjOU2RRzNN7YI/QjPjr/5wHdb4MP5GhcWvxPwX2f4XVno 07fN7kpyd70Mnnt8ePPDa22wkYzV5CyZGQFrp4jEMX+NX90jpXiRc0nKnkMae8503n7yx/2c iMLjtHtfFB5Uurw1YiiactSx+Vehrs6tZjvV6V8rL7Y2+C2VOF80edmu3QKFz9guqCmxFGck GmoxFxUnAgAHOX8dYwIAAA== Archived-At: Subject: [Emu] Early chair review of EAP-AKA' PFS X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 09:15:32 -0000 Hi Jari and co-authors, Here is a review of the EAP-AKA' PFS draft version 02. Note, none of=20 these comments preclude its working group adoption and these can be=20 addressed before or after adoption as a working group item. - Use of DH vs. DHE vs. ECDH vs. ECDHE The draft almost uniformly refers to Diffie-Hellman (DH) key exchange.=20 However, we can't achieve perfect forward secrecy (PFS) if static=20 Diffie-Hellman keys are used. Therefore it might make sense to refer to=20 Ephemeral Diffie-Hellman (DHE) and Ephemeral Elliptic Curve=20 Diffie-Hellman (ECDHE) instead of DH. The use of DH throughout the draft = is also surprising when only one elliptic curve is currently specified=20 for the key exchange in the draft. If only elliptic curves will be=20 supported (currently and in the future), then you can use ECDHE=20 throughout. Otherwise, you can use the notation (EC)DHE. - Use of g^x and g^y in message exchanges The traditional notation of public keys g^x and g^y and derivation of=20 the secret g^xy is useful and easy for understanding. The strength of=20 the secret here is based on the discrete logarithm problem. For Elliptic = Curve Diffie-Hellman, the notation would be a different (both parties=20 have public keys as points on the agreed curve and after the key=20 exchange, both parties compute another point on curve which is the=20 shared secret). The strength of the secret here would be based on the=20 elliptic curve discrete logarithm problem. The use of g^x and g^y while=20 only supporting a single elliptic curve might confuse readers. It might=20 be useful to at least add that g^x and g^y are used for notation and=20 corresponding public keys of ephemeral elliptic curve diffie-hellman can = be used in the messages (if both DHE and ECDHE are to be supported). If=20 only ECDHE is supported, then it might make sense to explicitly clarify=20 that g^x and g^y are used are for notation only. As another option, you=20 can simply refer to them as PKs and PKp for public keys of server and pee= r. - Negotiation of the ECDHE curve I think this needs some more clarification. The AT_KDF_DH is used for=20 deciding which ECDHE curve is used for the public key in AT_PUB_DH. So=20 as the draft currently says, it is possible for the the server to send=20 several AT_KDF_DH attributes in the order of preference. Does this also=20 mean that it sends several AT_PUB_DH in the same order? I am afraid the=20 message size may explode and without any fragmentation support, this is=20 bound to fail. I guess you might initially send only one AT_PUB_DH with=20 the most preferred AT_KDF_DH. If the client/peer does not support that=20 and chooses a different AT_KDF_DH from the list, then a new EAP-Request=20 is sent with a different AT_PUB_DH. Also, currently the peer will need=20 to do AT_KDF and AT_KDF_DH negotiation separately, because=20 EAP-Response/AKA'-Challenge message can contain only one attribute=20 AT_KDF or AT_KDF_DH depending on what are you negotiating. Shouldn't=20 they be done at the same time? - Encoding the (EC)DHE public keys sent to Peer and Server Currently the draft says at that the AT_PUB_DH contains the public value = of the Diffie-Hellman key, and for curve25519 it is 32 bytes long.=C2=A0 = As=20 the test vectors in RFC 7748 say, that is 32 binary bytes. You would=20 need to encode the public key when sending on the wire which would=20 increase the size. Section 5.2 of RFC7748 shows the public key with=20 Curve25519 key as hex encoded. I would strongly recommend encoding the=20 public keys when sending on the wire with something like JSON Web Key=20 (JWK). Also, Curve25519 is special. Most other curves have a public key=20 as a point x and y. Without proper encoding it would be hard to=20 interpret which bytes are x and which bytes are y and therefore=20 inter-operable implementations would be challenging. - No KDF on Z derived from EC(DHE) The shared secret resulting from a EC(DHE) exchange is typically denoted = as Z (perhaps you can use that instead of g^xy). This comment is related = to the use of g^xy in the derivation of MSK, EMSK and other parameters=20 shown in Section 6.3. I am not an expert with PRF vs KDF and others with = more expertise maybe able to help more. My understanding is that a PRF=20 places more stringent requirements on the uniform distribution of the=20 secret key that is used. It might be better to pass Z though a KDF like=20 those in the NIST=C2=A0 800-56A Revision 2 before using it in a PRF. - The abstract and introduction refers to the RFC5448. Perhaps it should = be updated to reference the draft-ietf-emu-rfc5448bis-01? - In Section 1: " we as protocol designs can ask " should be " we as=20 protocol designers can ask " - In Section 1: " within that context will be EAP-AKA. " should be "=20 within that context will be EAP-AKA'. " - In Section 2: " This specification is an initial proposal for ensuring = SIM-based authentication in EAP makes attacks difficult. Comments and=20 suggestions are much appreciated, including design improvements.=C2=A0"=20 perhaps can be removed now? --Mohit From nobody Fri Aug 3 03:08:33 2018 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 595DA130E3E for ; Fri, 3 Aug 2018 03:08:32 -0700 (PDT) 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, HTML_MESSAGE=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 82lPLCFgu01Y for ; Fri, 3 Aug 2018 03:08:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB74130ECD for ; Fri, 3 Aug 2018 03:08:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C2CCA660261; Fri, 3 Aug 2018 13:08:27 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbgYUJfbsKue; Fri, 3 Aug 2018 13:08:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 52B3766020F; Fri, 3 Aug 2018 13:08:26 +0300 (EEST) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_7719E93E-E45E-44DB-AEDC-6B017ADB8220" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 3 Aug 2018 13:08:25 +0300 Cc: =?utf-8?Q?Kalle_J=C3=A4rvinen?= To: emu@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Emu] Some observations on RFC 4187 attribute table X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 10:08:32 -0000 --Apple-Mail=_7719E93E-E45E-44DB-AEDC-6B017ADB8220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As part of ongoing (new) implementation effort, my colleague realised = that there are couple of oddities in the RFC 4187 attribute table = (Section 10.1). First, for AT_CHECKCODE, the table indicates =E2=80=9C0=E2=80=9D for = EAP-Response/AKA-Identity, yet Section 10.13 says =E2=80=9C The = AT_CHECKCODE attribute MAY be used to protect the EAP/AKA-Identity = messages.=E2=80=9D This seems like an oversight in the table. The entry = should be =E2=80=9C0-1=E2=80=9D instead. Second, again for EAP-Response/AKA-Identity, AT_IDENTITY is marked as = =E2=80=9C0-1=E2=80=9D but the corresponding text in Section 4.1.5 says = "the peer MUST respond with EAP-Response/AKA-Identity and include the = permanent identity in AT_IDENTITY.=E2=80=9D Again, we think the text is = correct and the table should read =E2=80=9C1=E2=80=9D in this case. Note = that the peer can send a client error message if for instance it does = not have a suitable identity. Are we reading these correctly, or are we missing something? (I=E2=80=99d fix these in RFC 5448bis but they aren=E2=80=99t included = in 5448 to begin with=E2=80=A6 so maybe an errata should be filed. The = current errata do not seem to include these issues, see = https://www.rfc-editor.org/errata_search.php?rfc=3D4187 = ) Jari --Apple-Mail=_7719E93E-E45E-44DB-AEDC-6B017ADB8220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As part of ongoing (new) implementation effort, my colleague = realised that there are couple of oddities in the RFC 4187 attribute = table (Section 10.1).

First, for AT_CHECKCODE, the table indicates =E2=80=9C0=E2=80=9D= for EAP-Response/AKA-Identity, yet Section 10.13  says =E2=80=9C = The AT_CHECKCODE attribute MAY be used to protect the EAP/AKA-Identity = messages.=E2=80=9D This seems like an oversight in the table. The =  entry should be =E2=80=9C0-1=E2=80=9D instead.

Second, again for = EAP-Response/AKA-Identity, AT_IDENTITY is marked as =E2=80=9C0-1=E2=80=9D = but the corresponding text in Section 4.1.5 says "the peer MUST respond = with EAP-Response/AKA-Identity and include the permanent identity in = AT_IDENTITY.=E2=80=9D Again, we think the text is correct and the table = should read =E2=80=9C1=E2=80=9D in this case. Note that the peer can = send a client error message if for instance it does not have a suitable = identity.

Are = we reading these correctly, or are we missing something?

(I=E2=80=99d fix these = in RFC 5448bis but they aren=E2=80=99t included in 5448 to begin with=E2=80= =A6 so maybe an errata should be filed. The current errata do not seem = to include these issues, see https://www.rfc-editor.org/errata_search.php?rfc=3D4187)

Jari

= --Apple-Mail=_7719E93E-E45E-44DB-AEDC-6B017ADB8220-- From nobody Fri Aug 3 11:51:43 2018 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 5AF64130F02 for ; Fri, 3 Aug 2018 11:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 nMgqr72oBQ06 for ; Fri, 3 Aug 2018 11:51:40 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 25FBA131093 for ; Fri, 3 Aug 2018 11:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533322292; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6IHym8LoKE7Wpoc22Do9lcVG61vgp15z/dGRPP1IRSU=; b=LQs34yyRK1QPqUfK1RRKrk9qmfOsrc52r+o0rVbv6/O+04gtE9Czz89ItcMlFQcX n4chkm7rxuW0ghFsI02Me9v5lXJubFSMVRMhy+xezY1KXokGMbWeYl5meDscl13j YFi8/IMNFyB43cqZmGD8ilOeoK675BQcgfmGVccbiUQ=; X-AuditID: c1b4fb3a-481ff7000000145f-76-5b64a4344913 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.52.05215.434A46B5; Fri, 3 Aug 2018 20:51:32 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 3 Aug 2018 20:51:31 +0200 Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 3 Aug 2018 20:51:31 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id F358B4812CB for ; Fri, 3 Aug 2018 21:51:31 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id B86EF480090 for ; Fri, 3 Aug 2018 21:51:31 +0300 (EEST) From: Mohit Sethi To: Message-ID: Date: Fri, 3 Aug 2018 21:51:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM2J7ta7JkpRog3OnRC2OrV/L4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPMNaxkL5jJXHDt+j62B8TJTFyMnh4SAicSxS1dZQGwhgaOM Ev/3V3YxcgHZXxklvqy5zAjhXGCUWPh5PwuEc4xRYvG+5cwQzhZGiR8/nrOC9LMJ6El0njvO DGILCyhLLFq9ix3EFhEQkri2/iUjiM0rYC9x4+kpNhCbRUBF4sPlz2A1ogIREquXv2CFqBGU ODnzCdhNzAIWEjPnn2eEsLUlli18zQxhi0vcejIf6gdliQUtixghflCX2NpxgHECo9AsJKNm IRk1C8moWUhGLWBkWcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGNAHt/y22sF48LnjIUYB DkYlHt6gaSnRQqyJZcWVuYcYJTiYlUR433YmRwvxpiRWVqUW5ccXleakFh9ilOZgURLndUqz iBISSE8sSc1OTS1ILYLJMnFwSjUwrl/1ek+7hW3ZDt/Iaw7/gqZdu2O44MWnR/dPrZFzMP23 XPP6B/dXO2V3dHdymRiteMaYn/+wi7ntuu/5HTuqX65dF7hkxuKZqVerfghxrZWbwHfroek9 dZHgpV7nRO9mLfqyNCpgygP2g7feqZ/rfjZz/4yNFjUmTLdv7mFbHJbizX3t0he/zhYlluKM REMt5qLiRACqOSnUZAIAAA== Archived-At: Subject: [Emu] Minutes from EMU @ IETF102 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 18:51:42 -0000 Hi all, Thank you for participating in the EMU session at IETF 102. A special=20 thank you to Rahul for serving=C2=A0as=C2=A0the=C2=A0jabber=C2=A0scribe a= nd Zhen for taking=20 the minutes. Edited minutes from the EMU session at IETF 102 have now been uploaded: https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00 Please report any issues by August 10, 2018. Joe and Mohit From nobody Mon Aug 6 02:27:03 2018 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 69577130EAF for ; Mon, 6 Aug 2018 02:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 V-5ot6KmqUNC for ; Mon, 6 Aug 2018 02:26:59 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 99FFB130E77 for ; Mon, 6 Aug 2018 02:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533547617; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Clrl68KKB3TmfUxmv8BKgIs3XP8k22aL5/sgOXqhhqM=; b=F/4bpWlZlCIzeUfqemoTPTJkGS9iB6eLdb6xCBMunfNbrGjFYdFAsl9S83wivTbG DSUZ0VztTs1oSr4+EAYqcAfAYpa0WgMmchFvIl8O/un4xWAVKc2ArKCkxsgCLTo0 5Tq5JbGKHA6N0e5wxCA9micorrPXk00wDKQgL7Hklvk=; X-AuditID: c1b4fb25-b1dff70000006cb9-b0-5b68146153bf Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.78.27833.164186B5; Mon, 6 Aug 2018 11:26:57 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 6 Aug 2018 11:26:57 +0200 Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Mon, 6 Aug 2018 11:26:56 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id D90B2480F9B for ; Mon, 6 Aug 2018 12:26:56 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 9BD66480A6C for ; Mon, 6 Aug 2018 12:26:56 +0300 (EEST) From: Mohit Sethi To: Message-ID: <54df2eb3-b8b6-5cbd-75b7-c8b495d8cc24@ericsson.com> Date: Mon, 6 Aug 2018 12:26:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM2J7mW6iSEa0wa9eHYtj69eyODB6LFny kymAMYrLJiU1J7MstUjfLoEr48OFdcwFx9gqNt3bzN7AuIa1i5GDQ0LARGLCjPouRi4OIYGj jBIbHn1igXC+Mkrc/dsA5VxglPhybBuUc4xR4sD+fVDOFkaJ3//msXUxcnKwCehJdJ47zgxi CwvIS/zq284OYosICElcW/+SEcTmFbCX+HxjFguIzSKgIrF/6XywGlGBCInVy1+wQtQISpyc +QSshlnAQmLm/POMELa2xLKFr5khbHGJW0/mM4HYEgLKEgtaFoHVCAmoS2ztOMA4gVFoFpJR s5CMmoVk1CwkoxYwsqxiFC1OLU7KTTcy1kstykwuLs7P08tLLdnECAzog1t+q+5gvPzG8RCj AAejEg+vHm9GtBBrYllxZe4hRgkOZiUR3hWz06OFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8z40 3xwlJJCeWJKanZpakFoEk2Xi4JRqYBSyv6TImfTI1v5rfnPxs1V1YtEnKvZtF+JebLZ6TSef 66/Nn8T0cv4b79Opvb3nX+G6eysvzYxfdNLNz5aL6yF/yBJfR4fq3M/ry/3POp1acvfKjYNx gvX/7jEvPs4X/vzvaj81G/8d9557yxx68C2w0PMO493SKMv9cxgZmwzbHl0QWqF56a4SS3FG oqEWc1FxIgBdf/FRZAIAAA== Archived-At: Subject: [Emu] Experiment with github X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 09:27:01 -0000 Hi all, Joe and I decided to experiment with editing EMU drafts on github. We=20 have setup a github organization for the working group: https://github.com/emu-wg Currently, we have the following drafts (repositories): 1.=C2=A0 Using EAP-TLS with TLS 1.3:=20 https://github.com/emu-wg/draft-ietf-emu-eap-tls13 2.=C2=A0 Handling Large Certificates and Long Certificate Chains in EAP-T= LS:=20 https://github.com/emu-wg/eaptls-longcert This would hopefully make the collaborative editing of drafts easier and = more transparent. For example, Sean Turner had promised during the=20 meeting to help with some text on how not to shoot yourself in the foot=20 with PKI (pick shorter OIDs if possible etc.). This is an experiment so we look forward to your feedback (and pull=20 requests). Joe and Mohit From nobody Mon Aug 6 03:14:10 2018 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 24F14130E7E for ; Mon, 6 Aug 2018 03:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 eyogSRXEMGy5 for ; Mon, 6 Aug 2018 03:14:06 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 050AC128CF3 for ; Mon, 6 Aug 2018 03:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533550444; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4jwi1Tdu7NgH7yGq8EKEPHO0DPAX50QDQq0BvvsR+uE=; b=EWGsVx61kGwL7wqD+hQH0Ls66zQArYSIc4J0ixdeDuozxq0zWYNsylepm4rPPHzG GZ26mRaTWBPgxNvwxHb5CHIrU7DzMXXLzLxKwuqzZhtXOroF8D8lscuyZ4N/6jMF H1Up5DJi5LX9xfAfYlCVHDy6apRZlKH1ymWqx8JsEVg=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-5f-5b681f6c5c22 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D8.46.22015.C6F186B5; Mon, 6 Aug 2018 12:14:04 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 6 Aug 2018 12:13:35 +0200 Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.189) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Mon, 6 Aug 2018 12:13:36 +0200 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 27657480F9B; Mon, 6 Aug 2018 13:13:36 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id CE538480A6C; Mon, 6 Aug 2018 13:13:35 +0300 (EEST) From: Mohit Sethi To: CC: John Mattsson Message-ID: <0ea1dd35-d47a-8974-317f-72081d90487e@ericsson.com> Date: Mon, 6 Aug 2018 13:13:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------41AFE3DF1A05F5C7B769FF9B" Content-Language: en-US X-AV-Checked: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2J7hW6OfEa0wcl1nBbH1q9lcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxouPpxkLfgpXTNj1mbmB8SZ/FyMnh4SAicS9RdPYuhi5OIQE jjJKTLqxmwnC+cooMXP7DCjnAqPEx9kfoJzNjBIP33QzQzgLGSXu79jKDjKMTUBPovPccWYQ W1jASmL1+ilMILaIgJDEtfUvGUFsZqCax8/ugNm8AvYSj/d+BOtlEVCR2P56GVhcVCBCYvXy F6wQNYISJ2c+YYHoDZPoW3CaGcIWl7j1ZD4TxBPKEgtaFoH1CgmoS2ztOMA4gVFoFpL2WUja ZyFph7AtJGbOP88IYWtLLFv4GqpGQ6J1zlx2CFteonnrbOYFjOyrGEWLU4uLc9ONjPVSizKT i4vz8/TyUks2MQJj4+CW37o7GFe/djzEKMDBqMTDe0guI1qINbGsuDL3EKMEB7OSCO+K2enR QrwpiZVVqUX58UWlOanFhxilOViUxHn1Vu2JEhJITyxJzU5NLUgtgskycXBKNTD6bb/63Y+1 u/ubdcwPfQmGDlu9a9+T050Ufgs3y114qv/q/gprY23Zx5Y19TZhuTfMfpmcXrX5vUW+xJ7c v7bvMlb2/Ba77bMpa/u6RY1qonlCkr2p16X+1Tb1ieyR0FGX1uFbHXTlwJbrV0OrvVxiEpWC TE0tvUwTdqfr77v3Ony3qtHmuUosxRmJhlrMRcWJAMaCBF+JAgAA Archived-At: Subject: [Emu] Method-Id and Session-Id for EAP-TLS with TLS 1.3 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 10:14:08 -0000 --------------41AFE3DF1A05F5C7B769FF9B Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, At IETF 102, there was consensus in the room to use exporters going=20 forward. Bernard rightly pointed out that the Session-Id was missing the = Type Code prefix. As stated in RFC 5247: > EAP Session-Id is the > concatenation of the single octet EAP Type Code and a temporally= > unique identifier obtained from the method (known as the > Method-Id): Therefore, we have updated the current version of the draft in github=20 (https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls= 13.html)=20 to use the following construction: > Method-Id =3D TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64) > Session-Id =3D 0x0D || Method-Id > where 0x0D is the type code. IANA had allocated type code 13 for EAP-TLS.= Please let us know if we still missed something. --Mohit --------------41AFE3DF1A05F5C7B769FF9B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi all,

At IETF 102, there was consensus in the room to use exporters going forward. Bernard rightly pointed out that the Session-Id was missing the Type Code prefix. As stated in RFC 5247:

EAP Session-Id is the
      concatenation of the single octet EAP Type Code and a temporally
      unique identifier obtained from the method (known as the
      Method-Id):
Therefore, we have updated the current version of the draft in github (https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.html) to use the following construction:

Method-Id    = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64)
Session-Id   = 0x0D || Method-Id
where 0x0D is the type code. IANA had allocated type code 13 for EAP-TLS.

Please let us know if we still missed something.

--Mohit

--------------41AFE3DF1A05F5C7B769FF9B-- From nobody Fri Aug 10 02:20:58 2018 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 37AFF130DCF; Fri, 10 Aug 2018 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_MED=-2.3, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=gr8rlNNd; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=S9yCqbCE 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 1Ht45q0Qs82u; Fri, 10 Aug 2018 02:20:51 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 4C1011271FF; Fri, 10 Aug 2018 02:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1533892850; x=1565428850; h=from:to:cc:subject:date:message-id:mime-version; bh=aQ+AzcuJsHPPuVtsiijKq5xlfHZ5BvFAdrbgle+7eyY=; b=gr8rlNNdqvUJnY7l9+ivawnbqTmubDLNh9v3+CI3dBoJK4zspi6dCx0A YnGNEM0WjxpDPzbWwWipwKs8fV2ianVadTk3nhYm+4LJtQgIMwL3Hwknf FuNBq6T5HSNC9BdgmWUCkP5WoQL/nmB0N7AzjVbd00ITF6za2Y43P/m+g fnsExR4rr9WM6RaNZNtio7/gf+0u8XFUr8Vrer59C7HG1jOWRfuCAasH+ 6niwzS2jFZBxIz4DgacQWJipdV2bAHnMWwtJnl6ArZamZeM8XpuhINVs2 RI3AqKe+DFe+DHjnO3pwRa6x/B15aOOwXOZX4fq6ivvEMlP5OYhUAQ95q w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Aug 2018 11:20:41 +0200 X-IronPort-AV: E=Sophos;i="5.53,218,1531778400"; d="scan'208,217";a="230461931" Received: from he105871.emea1.cds.t-internal.com ([10.169.118.68]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 10 Aug 2018 11:20:41 +0200 Received: from HE105709.EMEA1.cds.t-internal.com (10.169.118.41) by HE105871.emea1.cds.t-internal.com (10.169.118.68) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 10 Aug 2018 11:20:40 +0200 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105709.EMEA1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 10 Aug 2018 11:20:40 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.24) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 10 Aug 2018 11:21:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aQ+AzcuJsHPPuVtsiijKq5xlfHZ5BvFAdrbgle+7eyY=; b=S9yCqbCEwQODdOjElwRTbmyI+qi3yvRgprWufMFZO66TCIRiO9P7buarXgHZ7rzS1pneMwmow0if7WFDzyCIrnXJgvi89zkh5xZOWep15B2VG0Szkpwa4T3TkUyZkc1S8XAVaB7aJGkOqHG7V7rSc+nuwIzae5dj+4QiZEYbXNk= Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.18) by FRAPR01MB0802.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.14; Fri, 10 Aug 2018 09:20:40 +0000 Received: from FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::fcbe:870:6cd7:64a9]) by FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE ([fe80::fcbe:870:6cd7:64a9%6]) with mapi id 15.20.1017.021; Fri, 10 Aug 2018 09:20:40 +0000 From: To: , Thread-Topic: FW: New Non-WG Mailing List: PidLoc Thread-Index: AdQwi2cW7Xe3OomrT22yyEkR268I5A== Date: Fri, 10 Aug 2018 09:20:40 +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=Dirk.von-Hugo@telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; FRAPR01MB0802; 6:NVwnWgICIoAA++WtT6iNtnN26DRPhQTYrrDoPQ9ufqbXEUuxrRiqQV0VfkPrkJCyW84klu81HPAYAgyDvv3O3k3FMyajCvISof2t12LK5xd6eKwy0Rdor6sz9sGqVQ9MQglJDOwXvQgVpTu5OU9j6mPGmY8nDPoI5K1cxvdds92wlRMhVNDxEGASAYxwonW8PocZEWvBz/gh55GWzm3n/p6sTe79Uu7OhiTkGiu8AcOGGAbWPGCjodZuGaPahR7ygqJK6KPkspzZHPBHpxe9pxxdXpSHmpqN1YPTnVap4AW/VJCkyrSfKKM8eUPn00GNiVh1v5We2O1Qi4LEm+Ad2xsyxZOMh2Cgv8iodakDcTpA8MMZ7OYlv/1zeans1Oiz4bmquvZkehL2f+epCMOaKoLFh270tD8r2rMQVC6jVIYdBPkNAn7p5kx9gvO3VDfbvuzd+DDo+Mqk6T2MEZlTfw==; 5:wGgLxUwDoab0qNPtX9Rm7nB5xb+iyQSkUYo/pqS5g9UPFSnHlnNCo2mq3ZZQX6Iw5AJEpNVaAnydZJc94NtYdzXFXEgs7qcHez3VL05z7ap6w+PUkLcHB6uOS+TLkSa0zxChFC+CZpn9l8sPDl8vrxpTRPCLmyIvIEMtu2MMosk=; 7:PkXD9i4eq9UV6kQPTS/mH/+DWUJ7jnZtlC2khLKsFVfdCiOe3bVpXvbFAaFvWLZYpmcbE100HbIyzy+ukj9MTRjs39VVLKb52POpuDcu/Als2VgVk8GfaXijfFr24TCooj+oHH8wkHm77TZZPfsa8WKTrWmwev4BOzPS3R+Iy1FdyS/0GkE/5nIFlwBWjh8ogHBy8qfbTZqc7LqSWoKE8TO5mjzqPokYdiWyIeDlj0N6A82jtCslpKp2HThhXLDx x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bef7e6d1-fc7b-4d29-0558-08d5fea28a48 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0802; x-ms-traffictypediagnostic: FRAPR01MB0802: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(85827821059158)(260130700054247)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:FRAPR01MB0802; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0802; x-forefront-prvs: 07607ED19A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(396003)(376002)(366004)(22974007)(199004)(189003)(106356001)(74482002)(6306002)(236005)(2473003)(229853002)(52396003)(105586002)(7696005)(2900100001)(4326008)(97736004)(55016002)(86362001)(5660300001)(66066001)(54896002)(9686003)(790700001)(3846002)(6116002)(33656002)(2906002)(316002)(110136005)(75402003)(68736007)(186003)(8936002)(14454004)(476003)(14444005)(256004)(606006)(5250100002)(53936002)(486006)(8676002)(102836004)(478600001)(81166006)(81156014)(966005)(26005)(2501003)(72206003)(7736002)(53546011)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0802; H:FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: TGj2LZ7RU0W/kTRdJCAWwaSNvH4l+F1QS09SBsHptCPOuDgDIDWgeLNVbxB8D+NUHdXeWmboRbFJMkBqrAvQxWMFIM8W5rmc6SBx8YRlJQUMjLvs4ylmxrijV+00yPfoqza24px+FT7zox7FxtMq8ePOtub2CKvm370QMLQQgY1h6zKBXZR3JHRfa9lzPiSG2UzeDMubaO9B/3ZF5vo9P8ruRcQ6OWz+URJVa5b4vPyAI5/tpdllqd860lsEWxtzskkIDPT34MkxBJnnK1ZP+uFi8x2KJiQIZvFuD9BLpSEO4uygk4d6LGvnbg69G59le3Ni+V1BWq4bcpse+bfmdiqIBZ+AIOC9zGmdwc1vmPE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FRAPR01MB080154DB00B103F78DCE95CED1240FRAPR01MB0801DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bef7e6d1-fc7b-4d29-0558-08d5fea28a48 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2018 09:20:40.0301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0802 X-OriginatorOrg: telekom.de Archived-At: Subject: [Emu] FW: New Non-WG Mailing List: PidLoc X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 09:20:56 -0000 --_000_FRAPR01MB080154DB00B103F78DCE95CED1240FRAPR01MB0801DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear EMU chairs: please approve this non-member post, thanks. Since in your WG you deal with Identity privacy improvements we think this = new discussion list may be of interest to you! Thanks! Best regards - also on behalf of Behcet Dirk ---------- Forwarded message ---------- From: IETF Secretariat > Date: Fri, Jul 27, 2018 at 3:32 PM Subject: New Non-WG Mailing List: PidLoc To: IETF Announcement List > Cc: PIdLoc@ietf.org, Dirk.von-Hugo@telekom.de, sarikaya2012@gmail.com A new IETF non-working group email list has been created. List address: PIdLoc@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/pidloc/ To subscribe: https://www.ietf.org/mailman/listinfo/pidloc Purpose: In IdLoc protocols like LISP, ILA, etc. separation between (fixed) Identi= fier and (dynamic) Location is proposed to find optimum path for data packe= ts to/from moving devices The threats against privacy in IdLoc protocols include location privacy where if a third party can at any time determine the IP lo= cation of some identifier, then the device can at one point be IP geolocate= d and movement privacy where if a third party can determine that an identifier ha= s changed locator(s) at time T, then even without knowing the particular lo= cators before and after, it can correlate this movement event with other in= formation to create a binding between the identifier and a person. Privacy and security work is needed both in control and data plane There is an existing draft https://www.ietf.org/id/draft-nordmark-id-loc-pr= ivacy-00.txt that is expected to serve as a starting point. The work is expected to clear the way for a wider acceptance/deployment of = IdLoc protocol. This may open new application areas such as in future mobil= e networks. In future mobile networks more efficient differentiation of packet handling= according to specific service demands (QoS) are expected. Traditional tunn= eling and encapsulation between IP addresses (=3D Id and/or Loc) have disad= vantages --_000_FRAPR01MB080154DB00B103F78DCE95CED1240FRAPR01MB0801DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear EMU chairs: plea= se approve this non-member post, thanks.

Since in your WG you = deal with Identity privacy improvements we think this new discussion list m= ay be of interest to you!

Thanks!

Best regards - also o= n behalf of Behcet

Dirk

---------- Forwarded message ----------
From: IETF Secretariat <ietf-secretariat@ietf.org= >
Date: Fri, Jul 27, 2018 at 3:32 PM
Subject: New Non-WG Mailing List: PidLoc
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: PIdLoc@ietf.org, Dirk.von-Hugo@telekom.de, sarikaya2012@gmail.com


A new IETF non-working group email list has been created.

List address: <= span lang=3D"EN-US">PIdLoc@ietf.org
Archive: https://mailarchive.ietf.org/arch/= browse/pidloc/
To subscribe: https://www.ietf.org/mailman/list= info/pidloc

Purpose:
 In IdLoc protocols like LISP, ILA, etc.  separation between (fix= ed) Identifier and (dynamic) Location is proposed to find optimum path f= or data packets to/from moving devices

The threats against privacy in IdLoc protocols include

location privacy where if a third party can at any time determine the IP location of some identifier, then the device can at one point be IP<= span style=3D"color:#1F497D"> geolocated and

movement privacy where if a third party can determine that an identifier has changed locator(s) at time T, then even without knowing the particular locators before and = after, it can correlate this movement event with other information to create a binding between the identifier and a person.=

Privacy and security work is needed both in control and data plane

There is an existing draft https://www.ietf.org/i= d/draft-nordmark-id-loc-privacy-00.txt that is expected to serve as a starting point.

The work is expected to clear the way for a wider acceptance/deployment of IdLoc protocol. This may open new application areas such as in fu= ture mobile networks.

In future mobile networks more efficient differentiation of packet handling according to specific service demands (QoS) are expected. T= raditional tunneling and encapsulation between IP addresses (=3D Id and/or Loc)= have disadvantages=

 

--_000_FRAPR01MB080154DB00B103F78DCE95CED1240FRAPR01MB0801DEUP_-- From nobody Thu Aug 23 15:52:57 2018 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 B2DC8130DDB for ; Thu, 23 Aug 2018 15:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=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 RwcPXYW5wQUK for ; Thu, 23 Aug 2018 15:52:50 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id F1F23128CF2 for ; Thu, 23 Aug 2018 15:52:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id A02B7374128E; Thu, 23 Aug 2018 22:52:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iUGbvvkIpjzD; Thu, 23 Aug 2018 18:52:42 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 9290B3740C38; Thu, 23 Aug 2018 18:52:42 -0400 (EDT) To: Mohit Sethi , Eliot Lear Cc: "Nancy Cam-Winget (ncamwing)" , EMU WG References: <4060a28f-3417-4693-06f9-6ddbe71d65d4@openca.org> From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <9ed1cf74-615e-d3e0-b090-e857dd8127e8@openca.org> Date: Thu, 23 Aug 2018 16:52:42 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030707090802000503080208" Archived-At: Subject: Re: [Emu] Re-Charter Considerations X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 22:52:54 -0000 This is a cryptographically signed message in MIME format. --------------ms030707090802000503080208 Content-Type: multipart/alternative; boundary="------------C215CC0B20C8B6F707B7AAA5" Content-Language: en-US This is a multi-part message in MIME format. --------------C215CC0B20C8B6F707B7AAA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mohit, all, So, if I may summarize the mail exchange, we agree that: * We can continue to discuss the issue within the EMU umbrella as long as it will not be overwhelming (it seems there is not much discussion within the ML now, so it might be a good time to work on these items) * It would be useful to have a conversation with IEEE around the idea of using EAP as a provisioning channel. My question here is - does anybody have plans to attend the IEEE meeting and/or report on what's the sentiment there around this idea? Given the above, I would like to understand what would be the possible options for provisioning protocols. In particular, I would like to have the input from the WG about EAP-TEAP extension vs. new EAP mechanisms. The use of EAP-TEAP extension seems to be a good approach - it already supports EST and can be extended to support other provisioning protocols. However, for protocols that might not require the use of a protected channel (e.g., because messages are signed and no secrets are exposed), it might be useful to have the option of not requiring EAP-TEAM as the "outer shell". On the other hand, the definition of extensions for EAP-TEAP might provide the needed push for seeing the deployment of the mechanisms (which today is still, as far as I know, very limited). What do you think? Cheers, Max On 8/7/18 1:57 PM, Mohit Sethi wrote: > Hi all, > > Please see our responses inline. > > Joe and Mohit > > On 08/03/2018 06:02 PM, Eliot Lear wrote: >> >> Hi Max and group, >> >> I want to direct my response to you in the context of >> draft-lear-eap-teap-brski.=C2=A0 While I wasn't in Montreal, I was in >> London, and it seems like there is a generally favorable view of the >> draft with two caveats: >> >> 1. The charter issue that you discuss below; and >> 2. a concern that perhaps extensions to TEAP won't get deployed >> because TEAP isn't well deployed. >> > There were also some other comments during the meeting. Please have a > look at the detailed minutes: > https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00 >> >> I want to address the 2nd point first.=C2=A0 My view is that TEAP hasn= 't >> seen wide deployment because the use case it thus far addresses is >> primarily focused on is well handled by EAP-FAST, and that is quite >> heavily deployed.=C2=A0 What we are talking about is an expanded use c= ase >> that would provide some additional reason to deploy TEAP.=C2=A0 I thin= k >> everyone understands the wireless chicken-and-egg problem, tho some >> see different ways of solving it. >> >> Michael has pointed out that the IEEE is having a meeting opposite >> the IETF in Bangkok.=C2=A0 As this directly relates to them, it might = make >> sense for some of us to gather together, either formally or >> informally or however between the two meetings and talk through what >> we think "Good" looks like.=C2=A0 As to how to progress discussion, we= 'd >> like to keep things open.=C2=A0 We know we have a problem.=C2=A0 In th= e >> enterprise space it's particularly interesting interesting.=C2=A0 When= in >> noisy environments like cities, the problem is even more interesting. >> > An informal discussion with the folks at IEEE to understand the > problems, requirements and various proposals would be a good approach. >> >> In the interim, should we continue to discuss this on EMU?=C2=A0 If no= t, >> can we get a non-wg mailing list for this purpose, and maybe even >> advertise it over to the IEEE 802.11 folk so that we could have good >> industry input?=C2=A0 I could see such a list covering eap-provisionin= g >> which seems to handle a much of what you mention below (sorry for >> taking so long to get back to your message).=C2=A0 Does that sound lik= e a >> reasonable approach?=C2=A0 That way the ADs can occasionally see how t= he >> work is progressing and then make decisions. >> > The discussion can continue on the EMU list as long as it doesn't > become a significant distraction.=C2=A0=C2=A0 >> >> Thanks, >> >> Eliot >> >> >> On 21.07.18 00:20, Dr. Pala wrote: >>> >>> Hi Emu-ers, >>> >>> I wanted to follow up the discussion from today's meeting. In >>> particular, there is some work that has been proposed that might >>> require re-chartering as indicated by Ekr and supported by the Chair(= s). >>> >>> I would like to push forward the request for re-chartering, in >>> particular, I would like to add the definition of one (or more) >>> EAP-based credentials provisioning mechanisms that would fit many >>> use cases that we are currently working on in different organizations= =2E >>> >>> In particular, the use cases that I am referring to are the following= : >>> >>> * *Cellular Networks.* The provisioning of Certificates (or other >>> credentials) to enable the use of EAP methods in different >>> environments (e.g., CBRS Alliance, MutleFire, etc.) has been a >>> problem that the current ecosystem have not addressed >>> efficiently. The use of OSU servers and the complexity (and >>> associated risks) of allowing (partial) IP access to >>> non-authenticated devices has limited the possibility for >>> in-line provisioning of devices. The use of an EAP-based >>> mechanism that can be used for credentials provisioning (and >>> renewal) would greatly improve the feasibility of in-band >>> credentials deployment. This authentication mechanism would >>> improve the possibility to use 4G\LTE (and future 5G) networks >>> for IoT credentials management which, today, seems to be ignored >>> because of the complexity required on the device. >>> >>> * *Cable Networks.* With the deployment of the new DOCSIS 3.1 FDX >>> specifications and its newly defined support for EAP >>> authentication via X.509 certificate throughout the whole >>> ecosystem, the ability to provide an EAP-based mechanism that >>> can be used for credentials provisioning and renewal, would >>> greately improve the feasibility of in-band credentials >>> deployment also in this case and the possibility to further >>> secure the infrastructure by allowing for better certificates >>> management (i.e., renewal, deployment, etc.) >>> >>> * =C2=A0*802.1x / WBA / HS2.0.* Also in these ecosystems, the >>> possibility to provision (and re-provision) dynamically >>> credentials opens up the possibility for more secure management >>> of identities. As in the previous use-cases, the management >>> directly at layer 2 allows for a simple (and extensible :D) >>> approach to credentials provisioning for devices. >>> >>> Therefore, counting the fact that all these ecosystems are looking >>> at a standardized / common solution to solve the same issue, I think >>> it is the right time to evaluate the possibility to work on this >>> important aspect. >>> >>> In my opinion, the WG should open up to evaluate the possibility to >>> work on the standardization of EAP-based provisioning mechanisms >>> that would allow for easier management options safer life-cycles of >>> device and subscribers credentials. >>> >>> On the need to re-charter, I would like to point out that this type >>> of work has been done in the past, therefore is not a completely new >>> territory (i.e., TEAP / EST). What we need now is the possibility to >>> address (a) the bootstrapping problem, and (b) the need for >>> supporting additional provisioning protocols that address different >>> ecosystems (i.e., simpler approaches that can be implemented in >>> sub-systems like micro-controllers - this would facilitate the >>> integration of credentials management independent from the >>> application layer / wifi module / etc.), and (c) the possibility of >>> defining provisioning protocols that might be used with or without >>> additional layers (e.g., EAP-tunneling). >>> >>> I hope we will have the possibility to work on this important topic >>> that, IMO, have the possibility to impact many millions of people >>> around the world and the security of our networks (Cellular, WiFi, >>> Corporate, and Home). >>> >>> Looking forward to a productive discussion! >>> >>> Cheers, >>> Max >>> >>> --=20 >>> Best Regards, >>> Massimiliano Pala, Ph.D. >>> OpenCA Labs Director >>> OpenCA Logo >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >> > --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------C215CC0B20C8B6F707B7AAA5 Content-Type: multipart/related; boundary="------------F239A79E85F3042E39658C79" --------------F239A79E85F3042E39658C79 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Mohit, all,

So, if I may summarize the mail exchange, we agree that:

  • We can continue to discuss the issue within the EMU umbrella as long as it will not be overwhelming (it seems there is not much discussion within the ML now, so it might be a good time to work on these items)

  • It would be useful to have a conversation with IEEE around the idea of using EAP as a provisioning channel. My question here is - does anybody have plans to attend the IEEE meeting and/or report on what's the sentiment there around this idea?

Given the above, I would like to understand what would be the possible options for provisioning protocols. In particular, I would like to have the input from the WG about EAP-TEAP extension vs. new EAP mechanisms.

The use of EAP-TEAP extension seems to be a good approach - it already supports EST and can be extended to support other provisioning protocols. However, for protocols that might not require the use of a protected channel (e.g., because messages are signed and no secrets are exposed), it might be useful to have the option of not requiring EAP-TEAM as the "outer shell".

On the other hand, the definition of extensions for EAP-TEAP might provide the needed push for seeing the deployment of the mechanisms (which today is still, as far as I know, very limited).<= /p>

What do you think?

Cheers,
Max


On 8/7/18 1:57 PM, Mohit Sethi wrote:<= br>
Hi all,

Please see our responses inline.

Joe and Mohit

On 08/03/2018 06:02 PM, Eliot Lear wrote:

Hi Max and group,

I want to direct my response to you in the context of draft-lear-eap-teap-brski.=C2=A0 While I wasn't in Montreal, I = was in London, and it seems like there is a generally favorable view of the draft with two caveats:

  1. The charter issue that you discuss below; and
  2. a concern that perhaps extensions to TEAP won't get deployed because TEAP isn't well deployed.
There were also some other comments during the meeting. Please have a look at the detailed minutes: https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-= 00

I want to address the 2nd point first.=C2=A0 My view is that T= EAP hasn't seen wide deployment because the use case it thus far addresses is primarily focused on is well handled by EAP-FAST, and that is quite heavily deployed.=C2=A0 What we are talking a= bout is an expanded use case that would provide some additional reason to deploy TEAP.=C2=A0 I think everyone understands the wireless chicken-and-egg problem, tho some see different ways of solving it.

Michael has pointed out that the IEEE is having a meeting opposite the IETF in Bangkok.=C2=A0 As this directly relates to= them, it might make sense for some of us to gather together, either formally or informally or however between the two meetings and talk through what we think "Good" looks like.=C2=A0= As to how to progress discussion, we'd like to keep things open.=C2= =A0 We know we have a problem.=C2=A0 In the enterprise space it's particularly interesting interesting.=C2=A0 When in noisy environments like cities, the problem is even more interesting.

An informal discussion with the folks at IEEE to understand the problems, requirements and various proposals would be a good approach.

In the interim, should we continue to discuss this on EMU?=C2=A0= If not, can we get a non-wg mailing list for this purpose, and maybe even advertise it over to the IEEE 802.11 folk so that we could have good industry input?=C2=A0 I could see such a lis= t covering eap-provisioning which seems to handle a much of what you mention below (sorry for taking so long to get back to your message).=C2=A0 Does that sound like a reasonable approach= ?=C2=A0 That way the ADs can occasionally see how the work is progressing and then make decisions.

The discussion can continue on the EMU list= as long as it doesn't become a significant distraction.=C2=A0=C2=A0=

Thanks,

Eliot


On 21.07.18 00:20, Dr. Pala wrote:=

Hi Emu-ers,

I wanted to follow up the discussion from today's meeting. In particular, there is some work that has been proposed that might require re-chartering as indicated by Ekr and supported by the Chair(s).

I would like to push forward the request for re-chartering, in particular, I would like to add the definition of one (or more) EAP-based credentials provisioning mechanisms that would fit many use cases that we are currently working on in different organizations.

In particular, the use cases that I am referring to are the following:

  • Cellular Networks. The provisioning of Certificates (or other credentials) to enable the use of EAP methods in different environments (e.g., CBRS Alliance, MutleFire, etc.) has been a problem that the current ecosystem have not addressed efficiently. The use of OSU servers and the complexity (and associated risks) of allowing (partial) IP access to non-authenticated devices has limited the possibility for in-line provisioning of devices. The use of an EAP-based mechanism that can be used for credentials provisioning (and renewal) would greatly improve the feasibility of in-band credentials deployment. This authentication mechanism would improve the possibility to use 4G\LTE (and future 5G) networks for IoT credentials management which, today, seems to be ignored because of the complexity required on the device.
  • Cable Networks. With the deployment of the new DOCSIS 3.1 FDX specifications and its newly defined support for EAP authentication via X.509 certificate throughout the whole ecosystem, the ability to provide an EAP-based mechanism that can be used for credentials provisioning and renewal, would greately improve the feasibility of in-band credentials deployment also in this case and the possibility to further secure the infrastructure by allowing for better certificates management (i.e., renewal, deployment, etc.)
  • =C2=A0802.1x / WBA / HS2.0. Also in these ecosyste= ms, the possibility to provision (and re-provision) dynamically credentials opens up the possibility for more secure management of identities. As in the previous use-cases, the management directly at layer 2 allows for a simple (and extensible :D) approach to credentials provisioning for devices.

Therefore, counting the fact that all these ecosystems are looking at a standardized / common solution to solve the same issue, I think it is the right time to evaluate the possibility to work on this important aspect.

In my opinion, the WG should open up to evaluate the possibility to work on the standardization of EAP-based provisioning mechanisms that would allow for easier management options safer life-cycles of device and subscribers credentials.

On the need to re-charter, I would like to point out that this type of work has been done in the past, therefore is not a completely new territory (i.e., TEAP / EST). What we need now is the possibility to address (a) the bootstrapping problem, and (b) the need for supporting additional provisioning protocols that address different ecosystems (i.e., simpler approaches that can be implemented in sub-systems like micro-controllers - this would facilitate the integration of credentials management independent from the application layer / wifi module / etc.), and (c) the possibility of defining provisioning protocols that might be used with or without additional layers (e.g., EAP-tunneling).

I hope we will have the possibility to work on this important topic that, IMO, have the possibility to impact many millions of people around the world and the security of our networks (Cellular, WiFi, Corporate, and Home).

Looking forward to a productive discussion!

Cheers,
Max

--
Best Regards,=
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA


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



--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------F239A79E85F3042E39658C79 Content-Type: image/png; name="komjmhmlmfcgckmf.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="komjmhmlmfcgckmf.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------F239A79E85F3042E39658C79 Content-Type: image/png; name="mdegkokjdoinfmkh.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="mdegkokjdoinfmkh.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------F239A79E85F3042E39658C79-- --------------C215CC0B20C8B6F707B7AAA5-- --------------ms030707090802000503080208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODIzMjI1MjQyWjAvBgkqhkiG9w0BCQQxIgQg7dt7 EELcoRFlkID4sIFvC8KdUpQ8Gr5SbQKH2q5dRfcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEANyUj58mLyLflSJFye6kNH8TiTN5l06jddPyxvVSzCo9Hne4+eNbOkSZXxYW3o3b9 rOXhtxIqn/OldmGIiVVYaMP6WSyPKgJBtsd/cRSJRqrpIPUH20/ulT7xyod53yNM5o6b87vR 2Df2mPn1XHQyQUr1tN+X2rUCuABQV4jijoEdaanssRUqei2IVHX8OUkQ8nLEpvmtECGvUoNu viH9TAAPd1XM+n3a9P2H48C+pGF16zWTpt1/FaWzJZsLynTna78g2nUKB3wAlSVdhfQfMyDC aeEn+ON1Ig+wKtdWy9pUpLSH1Cs+eX+GB+7cPJxJPjJa5kHAC0y5jnOisAyzAwAAAAAAAA== --------------ms030707090802000503080208--