From nobody Thu Apr 2 05:03:24 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682FD3A0DE1; Thu, 2 Apr 2020 05:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=kcjAQKNw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vvW40BLe 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 033xuWedFKMR; Thu, 2 Apr 2020 05:03:19 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928613A10C1; Thu, 2 Apr 2020 05:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7658; q=dns/txt; s=iport; t=1585828964; x=1587038564; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hM0TkdXBSPKlfgW3cKZNCzD2KBzk1iGLk4i+Q54ajnI=; b=kcjAQKNwr5RVSXe+qoSFCtaVZaFFSBBzKk4zGe1gQhiLvLrZ3FMIrA7n NwMVkaJ2/cvfXeVC7UMJ4lXqfoYsGG49xzYUJlRqMsHfOeB0ESGW1fRKc rRxA2JY6M8zk/RCAxfRjsL9gUQ6cDRnnVD6eGKPgV1KOpCNywFHWHxLeo E=; IronPort-PHdr: =?us-ascii?q?9a23=3A3MdmqR2C/7nL9S5zsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBFPqKvXpYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBQDz0oVe/5RdJa1dCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gVQkLAVsWCAECyqEG4NFA4psgl+YHoFCgRADVAoBAQEMAQE?= =?us-ascii?q?YCwoCBAEBhEQCF4IpJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQMBARA?= =?us-ascii?q?REQwBASwLAQsEAgEIEQMBAgMCERUCAgIlCxQBCAgCBAENBRsHgwQBgksDLgE?= =?us-ascii?q?OpBQCgTmIYnWBMoJ/AQEFhTIYggwDBoEOKowTHhqBQT+BEScggU9+PoJnAQG?= =?us-ascii?q?BHhsUGD+CUzKCLI1ogxqfDHgKgj2JUIkXhDQdgkyINQWQbI8pnBYCBAIEBQI?= =?us-ascii?q?OAQEFgWkigVdwFTsqAYI+UBgNjh0LAReDUIUUhUF0gSmOHgEB?= X-IronPort-AV: E=Sophos;i="5.72,335,1580774400"; d="scan'208";a="457161361" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2020 12:02:43 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 032C2hLK028159 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Apr 2020 12:02:43 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 07:02:43 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 08:02:42 -0400 Received: from NAM11-DM6-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.1497.2 via Frontend Transport; Thu, 2 Apr 2020 07:02:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EPaY33RQYTZLf4iJDZTxD4+qmw80/0D5yeiCqJfynrU1iT72rgNVs+Xw7wQwJQjl+dl3TZUhsMasXRaz0s9+zK5JpGZRQGsevvoFeA02BuOacw/xn/oT14/jGqoY3dJS7tCQjKgr8FSJ43c9N1Qp+OsieciXr2FdFPalQ02wQQIAATkCxL9koEIOuSKR/ZefW5g41t6Ke9lqAMdGNM7n5X9S7l88SwdszP3dTl+FBu/CKUBjCnm1tfRHugH1Wsx1JmBKqXOa4rmscgSIu8fV38xMSe2uCzQEdYBWKwafFOmXDutfG3/3CgTpovvqbraK6Z8Tqrl2IUm0Uqk2A+TM1w== 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=hM0TkdXBSPKlfgW3cKZNCzD2KBzk1iGLk4i+Q54ajnI=; b=deE2Rc6ovY1Ysy4bnB8Ok45PNBWnEH20XPTlqkQHFdQNMVG/zD8ZmipfDQjgHT5gCrOIDsX1oYtyUL6bfGMKPMyaZYBHVfUGYU4xSCQYo0WsTaX1inlTr9WENNR8Dk+x3TMJFeJXJP6oDBZuQYoZUOHYhk6Qo0fvV5MNsq5yxXUrxc530lulRokCTAK70sU+HueF6N+Td2YJt7eCQBaRwanRoZk/LrQiBdJUJJacvGIRJqJB0qmgKNEDNAGsXd+bkIDWofkxqH1n3nOC+TK8UjsEtb+HixJVbqVAC+gf0J/V2Ku5nKyPwi8+4M/NotXExM2c02EDHH8xQQiLgxdEdA== 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=hM0TkdXBSPKlfgW3cKZNCzD2KBzk1iGLk4i+Q54ajnI=; b=vvW40BLeMNmO070mWdJLYoErLgc5Plb6pKtrhNhrCzW0ED8it8lVlmjJAF4EGR73BHieXg+lnK0nvxN9k10qbnfx7vgMn01G6/ETOGmVJ5/K/KvXjK8+tqoYz89NvHB52c2Kw23OP2BphYHx8ZHu+JCmzVCaVm5abccVwhkGeTc= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB0076.namprd11.prod.outlook.com (2603:10b6:4:6b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 12:02:41 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 12:02:41 +0000 From: "Eric Vyncke (evyncke)" To: Russ Housley , "iot-directorate@ietf.org" CC: "draft-ietf-emu-rfc5448bis.all@ietf.org" , "emu@ietf.org" Thread-Topic: [Iot-directorate] Iotdir telechat review of draft-ietf-emu-rfc5448bis-07 Thread-Index: AQHWAhuFkCDJ/bW/eES5n3dAFMeviahl6oiA Date: Thu, 2 Apr 2020 12:02:41 +0000 Message-ID: References: <158508197187.19714.2310393273939699203@ietfa.amsl.com> In-Reply-To: <158508197187.19714.2310393273939699203@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:ad33:1e6:78ba:617b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a9ab5eff-4e75-476e-7c51-08d7d6fdbf1e x-ms-traffictypediagnostic: DM5PR11MB0076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(6486002)(110136005)(4326008)(33656002)(54906003)(5660300002)(2906002)(966005)(71200400001)(316002)(478600001)(36756003)(6506007)(6512007)(66946007)(81166006)(66574012)(76116006)(186003)(53546011)(91956017)(2616005)(86362001)(66556008)(66446008)(8936002)(64756008)(8676002)(66476007)(81156014); DIR:OUT; SFP:1101; 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: ohLMEgNPcMbixiEWEwrgOsiYdNf/hgiyhGEZ5q9wRogsNq95z1p5ImL/5JEKbJ0mxn8HNLiADmwpg3bDjm9mjcJgT4r/SWeWak5kGXwU1P7vDj1oh6uN24EJd+hcr38ZrLAQXIsY+HDixfMneNKJmkJK+OOP5qYyU93pL3zQV4L3BJDJaUXYiBzkEDt3cWPJS2rJ/4lVRPVGmScBi7YlTvZbq71o9cv1f7LQZ5J9mw98BWamww8Cx7WOmu5HGrK/PyP0t9kQ66FATf6fd0NwN+U9sYkyTYAMjjAjLjnUYlaSL0NgF74wgFzE8gKF6rp7X8roZ1RSJRHTK258J9OSlB4PUmpyalg714sQ2mMHl88mwqgM1JIU+CE+5dRkx+vzvmkCeLCLO5v1qYLKVhMycfSKvVxfDfrdsYntZ3xdO/ePmG3mbujkyrAwbx98zJLKvoTStuoYLo0bMeJacVYAz7foA/avMUnlzIS7cyIGmvUpvjKVCl/sMrT1+6tMnpzwU8srX0Oe4jay19CAy6YNqw== x-ms-exchange-antispam-messagedata: EpHTURz9tEp8n6AkBwVZjvEaisQ/OuituiG6OTWAQ7rSRvuR28F22kF3jfecdc0cvUSkG41wZW0rVTUmK5hBVHzAEMOTZ3fIrNniqJbXZMO8B4mOsJeBLzhzAafkZ4J4AsZcWqFxYvdZB/tKZG8hiOL0uCbVq8jatdeJWYI0hp2Ug8ieM8CR/0IP6EM19yOGv1hoqkXtQR98paGdU60sZQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <471C2B7C1A45CF4384D672CB51BC6127@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a9ab5eff-4e75-476e-7c51-08d7d6fdbf1e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 12:02:41.6761 (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: DHYieGVnvHXWj39k5b6u3KKQNdg+fG5OAlolrul5Ed+WX3HqL40bK8lCdEVWxgBkww1SONnalafhglu0vdAEzw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0076 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Emu] [Iot-directorate] Iotdir telechat review of draft-ietf-emu-rfc5448bis-07 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, 02 Apr 2020 12:03:22 -0000 QmVsYXRlZCB0aGFuayB5b3UgUnVzcyBmb3IgdGhlIHJldmlldywgbXkgYmFsbG90IHdpbGwgdGFr ZSB0aGlzIGludG8gYWNjb3VudC4NCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBJb3QtZGlyZWN0b3JhdGUgPGlvdC1kaXJlY3RvcmF0ZS1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgUnVzcyBIb3VzbGV5IHZpYSBEYXRhdHJhY2tlciA8bm9yZXBs eUBpZXRmLm9yZz4NClJlcGx5LVRvOiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29t Pg0KRGF0ZTogVHVlc2RheSwgMjQgTWFyY2ggMjAyMCBhdCAyMTozMw0KVG86ICJpb3QtZGlyZWN0 b3JhdGVAaWV0Zi5vcmciIDxpb3QtZGlyZWN0b3JhdGVAaWV0Zi5vcmc+DQpDYzogImxhc3QtY2Fs bEBpZXRmLm9yZyIgPGxhc3QtY2FsbEBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLWVtdS1yZmM1NDQ4 YmlzLmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtZW11LXJmYzU0NDhiaXMuYWxsQGlldGYub3Jn PiwgImVtdUBpZXRmLm9yZyIgPGVtdUBpZXRmLm9yZz4NClN1YmplY3Q6IFtJb3QtZGlyZWN0b3Jh dGVdIElvdGRpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1lbXUtcmZjNTQ0OGJpcy0w Nw0KDQogICAgUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KICAgIFJldmlldyByZXN1bHQ6IFJlYWR5 IHdpdGggSXNzdWVzDQogICAgDQogICAgSSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQg b2YgdGhlIElvVCBEaXJlY3RvcmF0ZSdzIGVmZm9ydCB0bw0KICAgIElvVC1yZWxhdGVkIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzDQog ICAgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0 IEFyZWEgRGlyZWN0b3JzLg0KICAgIERvY3VtZW50IGF1dGhvcnMsIGRvY3VtZW50IGVkaXRvcnMs IGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlDQogICAgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cy4NCiAgICANCiAgICBEb2N1bWVudDog ZHJhZnQtaWV0Zi1lbXUtcmZjNTQ0OGJpcy0wNw0KICAgIFJldmlld2VyOiBSdXNzIEhvdXNsZXkN CiAgICBSZXZpZXcgRGF0ZTogMjAyMC0wMy0yNA0KICAgIElFVEYgTEMgRW5kIERhdGU6IDIwMjAt MDEtMjkNCiAgICBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMjAtMDQtMDkNCiAgICANCiAgICANCiAg ICBBIHJldmlldyBmcm9tIHRoZSBJb1QgRGlyZWN0b3JhdGUgd2FzIHJlcXVlc3RlZCBvbiAyMDIw LTAzLTIzLCB3aGljaCBpcw0KICAgIGFmdGVyIHRoZSBJRVRGIExhc3QgQ2FsbCBlbmRlZC4gIEkg YXNzdW1lIHRoYXQgdGhlIEludGVybmV0IEFEcyB3YW50DQogICAgdGhpcyByZXZpZXcgdG8gaGVs cCBpbmZvcm0gdGhlbSBkdXJpbmcgSUVTRyBFdmFsdWF0aW9uLg0KICAgIA0KICAgIE5vdGU6IEkg ZGlkIG5vdCByZXZpZXcgdGhlIEFwcGVuZGljZXMuDQogICAgDQogICAgDQogICAgU3VtbWFyeTog UmVhZHkgd2l0aCBJc3N1ZXMNCiAgICANCiAgICANCiAgICBNYWpvciBDb25jZXJuczoNCiAgICAN CiAgICBTZWN0aW9uIDUuMiBzYXlzOg0KICAgIA0KICAgICAgIFRoZSBwc2V1ZG9ueW0gdXNlcm5h bWVzIGFuZCBmYXN0IHJlLWF1dGhlbnRpY2F0aW9uIGlkZW50aXRpZXMgTVVTVCBiZQ0KICAgICAg IGdlbmVyYXRlZCBpbiBhIGNyeXB0b2dyYXBoaWNhbGx5IHNlY3VyZSB3YXkgc28gdGhhdCB0aGF0 IGl0IGlzDQogICAgICAgY29tcHV0YXRpb25hbGx5IGluZmVhc2libGUgZm9yIGFuIGF0dGFja2Vy IHRvIGRpZmZlcmVudGlhdGUgdHdvDQogICAgICAgaWRlbnRpdGllcyBiZWxvbmdpbmcgdG8gdGhl IHNhbWUgdXNlciBmcm9tIHR3byBpZGVudGl0aWVzIGJlbG9uZ2luZw0KICAgICAgIHRvIGRpZmZl cmVudCB1c2Vycy4gIFRoaXMgY2FuIGJlIGFjaGlldmVkLCBmb3IgaW5zdGFuY2UsIGJ5IHVzaW5n DQogICAgICAgcmFuZG9tIG9yIHBzZXVkby1yYW5kb20gaWRlbnRpZmllcnMgc3VjaCBhcyByYW5k b20gYnl0ZSBzdHJpbmdzIG9yDQogICAgICAgY2lwaGVydGV4dHMuICBTZWUgYWxzbyBbUkZDNDA4 Nl0gZm9yIGd1aWRhbmNlIG9uIHJhbmRvbSBudW1iZXINCiAgICAgICBnZW5lcmF0aW9uLg0KICAg IA0KICAgIEl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGEgcmFuZG9tIG51bWJlciBnZW5lcmF0 b3IgaXMgbmVlZGVkIHRvIGhpZGUNCiAgICB0aGUgaWRlbnRpdGllcy4gIEZvciBleGFtcGxlLCBh IGhhc2ggb2YgYSBjb25maWd1cmVkIHNlY3JldCB2YWx1ZSBhbmQgYQ0KICAgIGNvdW50ZXIgYXJl IHByb2JhYmx5IGdvb2QgZW5vdWdoLiAgVGhlcmUgYXJlIGNsZWFybHkgb3RoZXIgd2F5cyB0byBk byBpdA0KICAgIHRvbywgYW5kIHNvbWUgb2YgdGhlbSBuZWVkIGEgcmFuZG9tIG51bWJlciBnZW5l cmF0b3IuICBCZWNhdXNlIG9mIHRoZQ0KICAgIHdheSB0aGlzIGlzIHdvcmRlZCwgaXQgaXMgbm90 IGNsZWFyIG5vdCBtZSB0aGF0IG15IHByb3Bvc2VkIHNvbHV0aW9uDQogICAgd291bGQgbWVldCB0 aGUgTVVTVCBzdGF0ZW1lbnQuICBJIGRvIG5vdCB0aGluayB3ZSB3YW50IHRvIG1ha2UgdGhpcw0K ICAgIGhhcmRlciB0aGFuIG5lY2Vzc2FyeS4NCiAgICANCiAgICBTZWN0aW9uIDcgc2F5czoNCiAg ICANCiAgICAgICAgICBJbiBnZW5lcmFsLCBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBjdXJyZW50 IG5lZ290aWF0aW9uDQogICAgICAgICAgY2FwYWJpbGl0aWVzIGluIEVBUC1BS0EnIGFyZSBzdWZm aWNpZW50IGZvciBzb21lIHR5cGVzIG9mDQogICAgICAgICAgZXh0ZW5zaW9ucyBhbmQgY3J5cHRv Z3JhcGhpYyBhZ2lsaXR5LCBpbmNsdWRpbmcgYWRkaW5nIFBlcmZlY3QNCiAgICAgICAgICBGb3J3 YXJkIFNlY3JlY3kgKFtJLUQuaWV0Zi1lbXUtYWthLXBmc10pIGFuZCBwZXJoYXBzIG90aGVycy4g IEJ1dA0KICAgICAgICAgIGFzIHdpdGggaG93IEVBUC1BS0EnIGl0c2VsZiBjYW1lIGFib3V0LCBz b21lIGxhcmdlciBjaGFuZ2VzIG1heQ0KICAgICAgICAgIHJlcXVpcmUgYSBuZXcgRUFQIG1ldGhv ZCB0eXBlLg0KICAgIA0KICAgIEkgZG8gbm90IHRoaW5rIGl0IGl0IGFwcHJvcHJpYXRlIHRvIGNs YWltIGNyeXB0b2dyYXBoaWMgYWdpbGl0eSB3aGVuDQogICAgU0hBLTI1NiBhbmQgSE1BQy1TSEEt MjU2IGFyZSBoYXJkd2lyZWQuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gc2F5IHRoYXQNCiAgICBh IG5ldyBFQVAgbWV0aG9kIHdpbGwgYmUgZGVmaW5lZCB0byBjaGFuZ2UgdGhlIGFsZ29yaXRobXMg KGFzIHdhcyBkb25lDQogICAgdG8gbWFrZSBFQVAtQUtBJyBpbiB0aGUgZmlyc3QgcGxhY2UpLg0K ICAgIA0KICAgIA0KICAgIE1pbm9yIENvbmNlcm5zOg0KICAgIA0KICAgIFNlY3Rpb24gMSBpbmNs dWRlcyB0aGUgc3VtbWFyeSBvZiBjaGFuZ2VzIGZyb20gUkZDIDU0NDguICBIb3dldmVyLCBpdA0K ICAgIGRvZXMgbm90IG1lbnRpb24gdGhlIGFkZGl0aW9uIG9mIFNlY3Rpb25zIDMuNSBhbmQgNC4x LiAgUGxlYXNlIGFkZCB0aGVtLg0KICAgIA0KICAgIFNlY3Rpb24gMy4xIHNheXM6DQogICAgDQog ICAgICAgT25seSB0aGUgc2VydmVyIHNlbmRzIHRoZSBBVF9LREZfSU5QVVQgYXR0cmlidXRlLiAg VGhlIHZhbHVlIGlzIHNlbnQNCiAgICAgICBhcyBzcGVjaWZpZWQgaW4gW1RTLTNHUFAuMjQuMzAy XSBmb3IgYm90aCBub24tM0dQUCBhY2Nlc3MgbmV0d29ya3MNCiAgICAgICBmb3IgNUcgYWNjZXNz IG5ldHdvcmtzLiAgDQogICAgDQogICAgVGhlcmUgYXJlIHNvbWUgbWlzc2luZyB3b3JkcyBoZXJl LiAgSSBhbSBub3QgcmVhbGx5IHN1cmUgd2hhdCBpcw0KICAgIGludGVuZGVkLCBzbyBJIGNhbm5v dCBvZmZlciBhIGZpeC4NCiAgICANCiAgICBTZWN0aW9uIDUuMy4xIHNheXM6DQogICAgDQogICAg ICAgICAgQWdhaW4sIHRoZSBpZGVudGl0eSBNVVNUIGJlIHVzZWQgZXhhY3RseSBhcyBzZW50Lg0K ICAgIA0KICAgIFBsZWFzZSBkZWxldGUhICBTYXlpbmcgaXQgdHdpY2UgZG9lcyBub3QgbWFrZSBp dCBhIHN0cm9uZ2VyIE1VU1QuDQogICAgDQogICAgU2VjdGlvbiA3LjI6IHMvZW5jcnlwdCBhbGwg cGF5bG9hZCB0cmFmZmljIGFmdGVyIGVuY3J5cHRpb24vDQogICAgICAgICAgICAgICAgICAvZW5j cnlwdCBhbGwgcGF5bG9hZCB0cmFmZmljIGFmdGVyIGF1dGhlbnRpY2F0aW9uLw0KICAgIA0KICAg IA0KICAgIE5pdHM6DQogICAgDQogICAgU2VjdGlvbiAxOiBzLyBub24tZ29hbCBvZiB0aGlzIGRy YWZ0LyBub24tZ29hbCBvZiB0aGlzIG1lbW8vDQogICAgDQogICAgVGhlcmUgaXMgYSBtaXNhbGln bm1lbnQgaW4gdGhlIGJvdHRvbSBib3ggaW4gRmlndXJlIDEuICBUaGlzIGlzDQogICAgc3VycHJp c2luZyBiZWNhdXNlIHRoZSBmaWd1cmUgaXMgb3RoZXJ3aXNlIGlkZW50aWNhbCB0byB0aGUgb25l IGluDQogICAgUkZDIDU0NDguDQogICAgDQogICAgSW4gU2VjdGlvbiAzLjU6IFRoZSBpbnRyb2R1 Y3Rpb24gdG8gdGhlIG51bWJlcmVkIGNvbHVtbnMgaXMgc2ltcGx5DQogICAgIkluIGFkZGl0aW9u OiIuICBGb3IgY2xhcml0eSwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gc2F5DQogICAg c29tZXRoaW5nIGxpa2U6DQogICAgDQogICAgICAgVGhlIG51bWJlcmVkIGNvbHVtbnMgaW5kaWNh dGUgdGhlIHF1YW50aXR5IG9mIHRoZSBhdHRyaWJ1dGUNCiAgICAgICB3aXRoaW4gdGhlIG1lc3Nh Z2UgYXMgZm9sbG93czoNCiAgICANCiAgICBTZWN0aW9uIDUuMTogcy8oc2VlIFNlY3Rpb24gNS4z LjIgYW5kIFNlY3Rpb24gNS4zLjIuMS4vDQogICAgICAgICAgICAgICAgICAvKHNlZSBTZWN0aW9u IDUuMy4yIGFuZCBTZWN0aW9uIDUuMy4yLjEpLi8NCiAgICANCiAgICBTZWN0aW9uIDUuMzogcy9h cyBkZWZpbmVkIGluIHRoaXMgUkZDL2FzIGRlZmluZWQgaW4gU2VjdGlvbiA1LjEvDQogICAgDQog ICAgSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgc3RydWN0dXJlIGZvciBTZWN0aW9uIDUuMy4xOg0K ICAgIA0KICAgICAgIDUuMy4xLiAgIEtleSBEZXJpdmF0aW9uDQogICAgICAgNS4zLjEuMSAgRm9y bWF0IG9mIHRoZSBTVVBJDQogICAgICAgNS4zLjEuMiAgRm9ybWF0IG9mIHRoZSBvdGhlciBpZGVu dGl0aWVzDQogICAgDQogICAgU2VjdGlvbiA2OiBzL1BlZXItSWQgaXMgbnVsbCBzdHJpbmcvUGVl ci1JZCBpcyB0aGUgbnVsbCBzdHJpbmcvDQogICAgDQogICAgU2VjdGlvbiA3LjI6IHMvcmVjb21t ZW5kYXRpb25zIGZyb20gU2VjdGlvbiA1LjIgbmVlZCB0byBiZQ0KICAgICAgICAgICAgICAgICAg IGZvbGxvd2VkIHRvIGF2b2lkIHRoaXMuDQogICAgU2VjdGlvbiA3LjI6IHMvZm9sbG93aW5nIHRo ZSByZWNvbW1lbmRhdGlvbnMgaW4gU2VjdGlvbiA1LjINCiAgICAgICAgICAgICAgICAgICBtaXRp Z2F0ZSB0aGlzIGNvbmNlcm4uLw0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tIA0KICAgIElvdC1k aXJlY3RvcmF0ZSBtYWlsaW5nIGxpc3QNCiAgICBJb3QtZGlyZWN0b3JhdGVAaWV0Zi5vcmcNCiAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvdC1kaXJlY3RvcmF0ZQ0K ICAgIA0KDQo= From nobody Fri Apr 3 01:29:15 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896783A145A; Fri, 3 Apr 2020 01:29:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: last-call@ietf.org, draft-ietf-emu-rfc5448bis.all@ietf.org, emu@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158590254947.16827.334655048985710327@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Fri, 03 Apr 2020 01:29:09 -0700 Archived-At: Subject: [Emu] Genart telechat review of draft-ietf-emu-rfc5448bis-07 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, 03 Apr 2020 08:29:10 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-emu-rfc5448bis-07 Reviewer: Dan Romascanu Review Date: 2020-04-03 IETF LC End Date: 2020-01-29 IESG Telechat date: 2020-04-09 Summary: Ready. This is a very detailed and well-written document that describes a new specification of the specification of EAP-AKA' to support 5G deployments. My comments and concerns in the Last Call review were addressed in a satisfactory manner. Major issues: Minor issues: Nits/editorial comments: From nobody Fri Apr 3 13:48:33 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2C3A0A98 for ; Fri, 3 Apr 2020 13:48:30 -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 OOs-nBKkhO5W for ; Fri, 3 Apr 2020 13:48:29 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422E33A0A96 for ; Fri, 3 Apr 2020 13:48:24 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 2A3FE10B for ; Fri, 3 Apr 2020 20:48:22 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=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 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Fri, 3 Apr 2020 16:48:20 -0400 To: EMU WG X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 03 Apr 2020 20:48:31 -0000 https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-01 I haven't seen much discussion on the document. There are still some = open questions: * should it be published simultaneously with draft-ietf-emu-eap-tls13? If so, we need some consensus on this document, and quick. If not, when do we publish this draft? Microsoft has already said = that they won't rev their EAP-TLS implementation until they can also rev = PEAP. * Should the document simply drop references to FAST? It looks like the effort has moved to TEAP. Perhaps we should note that FAST cannot be used with TLS 1.3, and that = TEAP should be used instead * should the document drop references to TEAP? Given Jouni Malinen's comments on implementing TEAP, it may be worth = simply noting that we're waiting for a TEAP update document * Without FAST / TEAP, the document is about 4 pages of text. Is there = anything controversial, missing, etc? * What are the barriers to adoption and publication? Alan DeKok. From nobody Sat Apr 4 22:48:13 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 449813A0F3A; Sat, 4 Apr 2020 22:48:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <158606568324.27151.8343729471473251946@ietfa.amsl.com> Date: Sat, 04 Apr 2020 22:48:03 -0700 Archived-At: Subject: [Emu] Murray Kucherawy's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT) 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: Sun, 05 Apr 2020 05:48:04 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-emu-rfc5448bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The apostrophe in "EAP-AKA'" makes me think there’s a typo present every time I see it. I primarily reviewed the diff between this document and RFC 5448. Nothing stood out to me as needing particular discussion. The thorough treatment on security, privacy, and vulnerability is appreciated. Abstract: * "memo" should really be "document". (This was beaten into me by a previous AD, but I kind of agree with it.) Section 5.1: Nit: * List item (1)(b) is missing a closing parenthesis. Section 7.2: Nit: * "There has also been attacks …" -- s/has/have/ Section 7.3: Nit: * "Perfect Forwards Secrecy …" -- s/Forwards/Forward/ From nobody Sun Apr 5 09:36:34 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8773A0E32; Sun, 5 Apr 2020 09:36:31 -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 yJhBSyttfxKd; Sun, 5 Apr 2020 09:36:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D87113A0E2F; Sun, 5 Apr 2020 09:36:28 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 035GaMe9013441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 5 Apr 2020 12:36:24 -0400 Date: Sun, 5 Apr 2020 09:36:21 -0700 From: Benjamin Kaduk To: Murray Kucherawy Cc: The IESG , Joseph Salowey , emu@ietf.org, draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org Message-ID: <20200405163621.GR88064@kduck.mit.edu> References: <158606568324.27151.8343729471473251946@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <158606568324.27151.8343729471473251946@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Emu] Murray Kucherawy's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT) 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, 05 Apr 2020 16:36:32 -0000 On Sat, Apr 04, 2020 at 10:48:03PM -0700, Murray Kucherawy via Datatracker wrote: > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > [...] > > Section 7.3: > Nit: > * "Perfect Forwards Secrecy …" -- s/Forwards/Forward/ > FWIW, we had a recent thread on saag@ that seems to have converged on preferring "Forward Secrecy" to "Perfect Forward Secrecy". -Ben From nobody Tue Apr 7 14:09:37 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B943A12E8 for ; Tue, 7 Apr 2020 14:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 MCzucNnHg9-n for ; Tue, 7 Apr 2020 14:09:33 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2070b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8a::70b]) (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 B734B3A12E7 for ; Tue, 7 Apr 2020 14:09:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KgMM3oQBQ9q7aqWyOnSLihRQCcwCBFw+ZciYX2nz0cuC8cOt03/fT13ZEg7sl5E4FtsBQ1UzougdaDG5zmkPWjOtBGh0xswKZppmmDFPoWYAbiaFM+81JAE1+sImAqt2ZUwuv1eKPyhhc2FWm4hZYRsRBoiFeOblHLUrFDdX52PXrZGED9m7rh/3d7zS+ScbYBgluf1g3MDakyaBMPOxdEokzLGR9zuFzBJcXcw9RUSCgPtbniATOvHnHXaDnW6+C1gHl9a03CyIbgh6oHjxanAN4uYIMxJ252FhpkrJJZoj/87HBZEs/0xktmELbhfbyrpE+5aD9WrVYF4u/qEWsw== 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=RnGJnloaqg44c0z9oELk7rggHhWyMkaIEnvem6jEZTw=; b=Q5SWIKgfWXN4CzUwvgMLOc3Jw9bCTBAoUXMq+GJJDYjUc+iRxWMu+8UBmh0Vvypva0EZKfdLpH9FzDR1KVnKkPBj4AaDBy4ob3R1dOewMH9QxwJMhe9azB7uDw6oeFTunvAr2IpaD7jQCURGSo5EpD51cAZMHou3CYdJHyvVzloJgpsrB5mZobCc809w6P++3oh4pdomEZwfDlzFRWKKOc/w8K2cC54unZxSmUyvh5+K2APW7UGgrPvwYGXzBLU93BqHmfQqaIBvLnM+bVIZdGVGRDDs5jN/BtbnHcYjRITqfV03WguJbdlV8UZApPD2RtBcCOX1gPiSH/+HKaIJGA== 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=RnGJnloaqg44c0z9oELk7rggHhWyMkaIEnvem6jEZTw=; b=KLw9THp2Z8TUfEgWXEOTAnXBkn4qff/xPv8kdXTKKhWGcpszyCRlbdZZLEcquN6V1PUOj6xqNuv8nlEel1GEtgClKHf3dlP1TN6dxIYPKB2wJhIBD40xLz3Ilm+khxqFsieksE0PgSe6TbCbT02XJwOz009TusK9D7MLdno53/g= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1399.namprd21.prod.outlook.com (2603:10b6:610:8e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.10; Tue, 7 Apr 2020 21:09:32 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703%5]) with mapi id 15.20.2921.000; Tue, 7 Apr 2020 21:09:31 +0000 From: Jorge Vergara To: Alan DeKok , EMU WG Thread-Topic: [Emu] draft-dekok-emu-tls-eap-types discussion Thread-Index: AQHWCflAito/q8SdbkqYuDgLHK2lQ6huIjRA Date: Tue, 7 Apr 2020 21:09:31 +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=jovergar@microsoft.com; x-originating-ip: [2001:4898:80e8:0:d202:dec:e24c:4f2a] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b8911fc4-edc5-4d50-aa49-08d7db37f796 x-ms-traffictypediagnostic: CH2PR21MB1399: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(366004)(5660300002)(6506007)(53546011)(86362001)(33656002)(110136005)(966005)(8990500004)(498600001)(10290500003)(76116006)(2906002)(66946007)(64756008)(186003)(66556008)(66476007)(66446008)(81156014)(7696005)(8936002)(8676002)(81166006)(71200400001)(9686003)(55016002)(82960400001)(52536014)(82950400001); DIR:OUT; SFP:1102; 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: DXO5ZU6TJ/vQ7QKL4MTk3brx7RXOSlBoU2/E8L6X42oBJN8V+V42/QSI9Q+jPG5zgs579F83XaeJgkbHyTpqO+QkQgv8Sq9zqEl9oFagkYFvURZBdMEGm0BHZMRqkoSJ31i+H1NHrAkfMkYeONMUz4qm9m/OgmfzNHVJHtXD+c62ZgCAZliU1C58gz5TX5j8I5UUA7KRDDqdpo9rkBcmV6gny6kEp2ZOloM59d62bMoYMAbV6B4Vi8pxJ6HrzpS464ZGHOPmks9J7TEKcK9EC3LSJTMlisEXPzjc8DKjTMdCeJ9SHOXVff1a/CNBNNmOLvfWzrGwaQb5qhPC1Kjw9SchwBv6livuU1ctGouUKeDFaNO6W/RHAMub8i6tJshQWH8Nnib+poUqoelUTVhxid2Lzn3oy6b/zf2UfEeszc/qYNZzW591vOuDLJK000rwVfzx8FSX3/EzB2fVm9UqBc5qTK/bs/+PEpgjoKPGp8BD004FE2iAYstVGxjvzERbqxCskyu7LDbKNPI2xCpwuQ== x-ms-exchange-antispam-messagedata: whNHCA3YGtzRVrbdkXbdU+IJ2Bawp1DFqtbtzDujuMz1m1y8+DL2RBueW3iFd8lS5cmowo0OAntxa3Pr4urCHMcOc38ai0JjstpUo2RuwcjobC434k2C0lyGyIj7MoDj4+/yIqMImuGNmfhtFJIlauu7LkbT8eeyioH9bfhTlFvYokuhp0ojrXrxhiQPIHqtvVQ03AtzogVtl/63ED7sWw== 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: b8911fc4-edc5-4d50-aa49-08d7db37f796 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 21:09:31.7972 (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: QmjYiol9FbShfrF+YxWJ13sREzaRNv2bkssCkkUis+9NMHksOJ8cOEoG4uLjVeLxqXcpwRP/SklCuqw7iPIbYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1399 Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 07 Apr 2020 21:09:36 -0000 >Microsoft has already said that they won't rev their EAP-TLS implementatio= n until they can also rev PEAP. PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same= time and will postpone TLS 1.3 support until such a time as we are able to= make the updates together. >* should the document drop references to TEAP? > Given Jouni Malinen's comments on implementing TEAP, it may be worth simp= ly noting that we're waiting for a TEAP update document I've reviewed the current errata, and acknowledge their validity, but am no= t sure that any of them would impact this document. The most relevant errata to this document seems to be https://www.rfc-edito= r.org/errata/eid5770. As noted in the errata, the calculation of keys becom= es confusing when methods export both MSK and EMSK because it is not clearl= y specified which value IMCK[j] should take on during the calculation of S-= IMCK[j]. The addition of clarifying information is welcome, but I don't bel= ieve this ambiguity currently prevents a compliant implementation - for exa= mple, an implementation could avoid this ambiguity by choosing to use eithe= r the MSK/EMSK exclusively, and communicating that to the server via the Co= mpound MAC TLV. The server can then make a policy decision on whether it is= accepting of this decision by the client and follow suit, or reject the cl= ient. The specifics of resolving this particular errata is a digression from my m= ain point - I believe a clarification can be added to the main TEAP documen= t at a future time without impacting the contents of this document. Ambigui= ty about which IMCK to use in S-IMCK calculation should not impact the defi= nition of the cryptographic calculations. On the document contents themselves, I have this review: The key derivation= proposed for TEAP/FAST uses the definition from FAST, which is not identic= al to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but = TEAP uses IMSK[j], which may be equivalent in some cases, but may not in ot= hers where the inner method exports an EMSK. Specifically, I believe this line of section 2.2 should change from IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound Keys",= S-IMCK[j-1] | MSK[j], 60) To IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound Keys",= S-IMCK[j-1] | IMSK[j], 60) For TEAP. Jorge -----Original Message----- From: Emu On Behalf Of Alan DeKok Sent: Friday, April 3, 2020 1:48 PM To: EMU WG Subject: [Emu] draft-dekok-emu-tls-eap-types discussion https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01&data=3D02%7C01%7Cjove= rgar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af9= 1ab2d7cd011db47%7C1%7C0%7C637215437188744711&sdata=3DndLp%2FSzsDlX%2FKY= x0UR0uf77rHgCjGej4kdZPpywuD9Q%3D&reserved=3D0 I haven't seen much discussion on the document. There are still some ope= n questions: * should it be published simultaneously with draft-ietf-emu-eap-tls13? If so, we need some consensus on this document, and quick. If not, when do we publish this draft? Microsoft has already said that = they won't rev their EAP-TLS implementation until they can also rev PEAP. * Should the document simply drop references to FAST? It looks like the effort has moved to TEAP. Perhaps we should note that FAST cannot be used with TLS 1.3, and that TE= AP should be used instead * should the document drop references to TEAP? Given Jouni Malinen's comments on implementing TEAP, it may be worth simpl= y noting that we're waiting for a TEAP update document * Without FAST / TEAP, the document is about 4 pages of text. Is there any= thing controversial, missing, etc? * What are the barriers to adoption and publication? 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%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637215437188744711&sdata=3DlkoHzd0fgN4z1oalqV2jW9pewUGSnlRLeKp= iFew4Yw8%3D&reserved=3D0 From nobody Tue Apr 7 16:47:58 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BB83A0363; Tue, 7 Apr 2020 16:47:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158630327324.15086.8983570743901449637@ietfa.amsl.com> Date: Tue, 07 Apr 2020 16:47:53 -0700 Archived-At: Subject: [Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT) 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: Tue, 07 Apr 2020 23:47:53 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-emu-rfc5448bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I mostly only read the diff and skimmed the rest. Section 1 The rest of this specification is structured as follows. Section 3 defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to prevent bidding down attacks from EAP-AKA'. Section 5 specifies requirements regarding the use of peer identities, including how EAP- AKA' identifiers are used in 5G context. Section 6 specifies what I'm not sure if it's "EAP-AKA' identifiers being used in 5G context" or "5G identifiers being used in an EAP-AKA' context" -- which way does the causality go? Section 4 Note that we assume (Section 7) that EAP-AKA' is always stronger than EAP-AKA. As a result, there is no need to prevent bidding "down" attacks in the other direction, i.e., attackers forcing the endpoints to use EAP-AKA'. I'd prefer to say something like "we do not provide" rather than "there is no need". Section 5.2 I agree with the IoTdir reviewer's concerns about over-stating the need for a secure PRNG in pseudonym generation. Section 5.3.1 In all other cases, the following applies: The identity used in the key derivation formula MUST be exactly the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent, regardless of the kind of identity that it may have been. If no AT_IDENTITY was sent, the identity MUST be the exactly the one sent in the generic EAP Identity exchange, if one was made. Again, the identity MUST be used exactly as sent. If no identity was communicated inside EAP, then the identity is the one communicated outside EAP in link layer messaging. In this case, the used identity MUST be the identity most recently communicated by the peer to the network, again regardless of what type of identity it may have been. Just to check: there's a strong message sequencing, so that there cannot be ambiguity between peers about the "most recently communicated" identity? Section 5.3.1.1 234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org Should this be using an example domain name instead of 3gppnetwork.org? (I think "no", but have to check.) Section 5.3.2.1 For the null-scheme: type0.rid678.schid0.userid0999999999@nai.5gc.mnc015. mcc234.3gppnetwork.org For the Profile protection scheme: type0.rid678.schid1.hnkey27.ecckey. cip.mac@nai.5gc. mnc015.mcc234.3gppnetwork.org [ditto] Section 6 The EAP-AKA' Session-Id is the concatenation of the EAP Type Code (0x32, one byte) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 0x32 || RAND || AUTN When using fast re-authentication, the EAP-AKA' Session-Id is the concatenation of the EAP Type Code (0x32) with the contents of the [...] nit: the second paragraph contradicts the first, since the first one does not disclaim that it's only for "regular authentication" (non-fast-reauthentication). Section 7 In general, it is expected that the current negotiation capabilities in EAP-AKA' are sufficient for some types of extensions and cryptographic agility, including adding Perfect Forward Secrecy ([I-D.ietf-emu-aka-pfs]) and perhaps others. But as with how EAP-AKA' itself came about, some larger changes may require a new EAP method type. Could we mention that we are not agile with respect to the use of SHA256/HMAC-SHA256? Section 7.2 Basin et al [Basin2018] have performed formal analysis and concluded that the AKA protocol would have benefited from additional security requirements, such as key confirmation. This feels a bit like a teaser -- what would be gained/prevented by using key confirmation? Is there a path towards performing key confirmation in the future? Section 7.3 As described Section 7.2, after the publication of RFC 5448, new nit: "As described in" In particular, it is crucial that manufacturers limit access to the secret information and the cards only to necessary systems and personnel. It is also crucial that secure mechanisms be used to communicate the secrets between the manufacturer and the operator that adopts those cards for their customers. No recommendation for encryption at rest? Beyond these operational considerations, there are also technical means to improve resistance to these attacks. One approach is to provide Perfect Forwards Secrecy (PFS). This would prevent any passive attacks merely based on the long-term secrets and observation of traffic. Such a mechanism can be defined as a backwards- compatible extension of EAP-AKA', and is pursued separately from this specification [I-D.ietf-emu-aka-pfs]. Alternatively, EAP-AKA' authentication can be run inside a PFS-capable tunneled authentication method. In any case, the use of some PFS-capable mechanism is recommended. My preference would be to drop the "Perfect" and also discuss forward secrecy with respect to specific event(s). See also the discussion at https://mailarchive.ietf.org/arch/msg/saag/81XWrBZiLNoPg7kfnAdaxIB8da8/ Section 7.4 The server receives the EAP transaction from a given access network, and verifies that the claim from the access network corresponds to the name that this access network should be using. It becomes impossible for an access network to claim over AAA that it is another access network. In addition, if the peer checks that the information it has received locally over the network-access link layer matches with the information the server has given it via EAP-AKA', it becomes impossible for the access network to tell one story to the AAA network and another one to the peer. These checks prevent some Why is this an "if" the peer checks -- shouldn't it be mandatory? Appendix 9.2 It looks like the only place we reference [FIPS.180-1] and [FIPS.180-2] is in the note saying that we updated the references to them :) From nobody Wed Apr 8 19:20:08 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 469F13A03EA; Wed, 8 Apr 2020 19:20:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158639880326.20965.3881608815018267069@ietfa.amsl.com> Date: Wed, 08 Apr 2020 19:20:03 -0700 Archived-At: Subject: [Emu] Alissa Cooper's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT) 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: Thu, 09 Apr 2020 02:20:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-emu-rfc5448bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why isn't this document on the standards track? I understand that it updates and obsoletes informational documents and I'm assuming there are historical 3GPP-related reasons why those documents were informational, but couldn't that be fixed in this update? This certainly seems like it is specifying normative behavior. == Section 5.3.2 == "Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is configured to use." It may be that I'm missing context, but 5.3.1.1 says "A SUPI is either an IMSI or a Network Access Identifier," which makes me wonder what it means to employ a SUPI that is neither an IMSI nor an NAI. == Section 7.1 == "The use of the null scheme is NOT RECOMMENDED where identity privacy is important." I think it might be better to say "The use of the null scheme is NOT RECOMMENDED where the SUCI can be linked to a human user." "The pseudonym usernames and fast re-authentication identities MUST also not be used for other purposes (e.g. in other protocols)." The normative language is not right. I think what you want is: The pseudonym usernames and fast re-authentication identities MUST NOT be used for other purposes (e.g. in other protocols). s/will available/will be available/ It would be good to provide citation(s) for "tunneled EAP methods" since their security properties are not discussed here. From nobody Wed Apr 8 19:21:55 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A770C3A03FC; Wed, 8 Apr 2020 19:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=cooperw.in header.b=YBV7h9Ho; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ApkH6Na9 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 18uproMC4HzX; Wed, 8 Apr 2020 19:21:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20473A03FA; Wed, 8 Apr 2020 19:21:32 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0AA1B5C0300; Wed, 8 Apr 2020 22:21:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 08 Apr 2020 22:21:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Z GEI9s0d4uYD2ItjvAWnNgN80VKutUvdT002tyBQ8NI=; b=YBV7h9HoHTev/tRMb PRf/DdnciX8hH03EtrlncRA3IshS8HF3udeXX09W6+QmmrIhqlb8b4D47H+5WLd5 03ec0BD4BwWsd7nni0YSWKLh/aDMG2KVDnY0seJyTdkhYkUOBYQNsIV56EDcgCyb 8tCMYYc93MuupbYCVftXb5vjWjKlFZRGLhPMnQ3uxzRg76UpMhTmQNzTDiCE0un3 YMgjr23AH6YOI9NN9fkhc2zKjgKMb451mILk7gpHMSzYKfpfYSqRYIVLLM3K5Tis ECNx3sMfA6Tt6dkBBg6YP5DI6MqXWgi2osyiSVaWEwZG/n2rZuV4AdfPnf6qjJ3F C7LfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ZGEI9s0d4uYD2ItjvAWnNgN80VKutUvdT002tyBQ8 NI=; b=ApkH6Na98GZpuLryIjYVhU86slf2NwoU5PqV1qgt7jlx2VbN1sCKy3EHF CIFxA3V6L5SqnO+t9r0t0gus2XdsBOTGNIL/WgeYcDHJtadE0EtNYn6MrqVsikbf rDyU7o8ZcOb0urmPIOq+OJ7PDXC6j4I48pgQRK+ZH14Z3Z6RKaruNzZ+Q2xk8EmY 82GegjZ5IjAZuDolehDHF5eCpfFIE0WeIxsrgzvbw4pQZT2P5CMNl0zt3GB7Jpi5 el9OkX2eBqQ8vQ37r4QCnpoLec3xvUNpfJZG4QV++y9wk0IzDgkoGOplHPGTIKjV VU0/PyldspxJgF1Zyshv3L5UYmQ2w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdeijeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghooh hpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id 72716306005B; Wed, 8 Apr 2020 22:21:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: <158590254947.16827.334655048985710327@ietfa.amsl.com> Date: Wed, 8 Apr 2020 22:21:29 -0400 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-emu-rfc5448bis.all@ietf.org, emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C56D61D-7AC9-4480-A842-2D1E1F9D22AB@cooperw.in> References: <158590254947.16827.334655048985710327@ietfa.amsl.com> To: Dan Romascanu X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [Emu] [Gen-art] Genart telechat review of draft-ietf-emu-rfc5448bis-07 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, 09 Apr 2020 02:21:54 -0000 Dan, thanks for your reviews. Jari, thanks for your responses. I entered = a No Objection ballot. Alissa > On Apr 3, 2020, at 4:29 AM, Dan Romascanu via Datatracker = wrote: >=20 > Reviewer: Dan Romascanu > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-emu-rfc5448bis-07 > Reviewer: Dan Romascanu > Review Date: 2020-04-03 > IETF LC End Date: 2020-01-29 > IESG Telechat date: 2020-04-09 >=20 > Summary: >=20 > Ready. This is a very detailed and well-written document that = describes a new > specification of the specification of EAP-AKA' to support 5G = deployments. My > comments and concerns in the Last Call review were addressed in a = satisfactory > manner. >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Apr 9 03:06:37 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 669B13A108A; Thu, 9 Apr 2020 03:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net, housley@vigilsec.com, iot-directorate@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158642679239.9446.17677836997978406608@ietfa.amsl.com> Date: Thu, 09 Apr 2020 03:06:32 -0700 Archived-At: Subject: [Emu] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?emu-rfc5448bis-07=3A_=28with_COMMENT=29?= 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: Thu, 09 Apr 2020 10:06:33 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-emu-rfc5448bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. Please respond to Russ' IOTDIR review: https://mailarchive.ietf.org/arch/msg/iot-directorate/vpbPLLBpdDnbL0A-bBLSEDyRA_M From nobody Thu Apr 9 04:41:22 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8953A00C1; Thu, 9 Apr 2020 04:40:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-emu-rfc5448bis@ietf.org, emu-chairs@ietf.org, emu@ietf.org, Joseph Salowey , joe@salowey.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <158643245920.18055.3620309316397492007@ietfa.amsl.com> Date: Thu, 09 Apr 2020 04:40:59 -0700 Archived-At: Subject: [Emu] Robert Wilton's No Objection on draft-ietf-emu-rfc5448bis-07: (with COMMENT) 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: Thu, 09 Apr 2020 11:41:01 -0000 Robert Wilton has entered the following ballot position for draft-ietf-emu-rfc5448bis-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One minor comment: I wasn't convinced that this paragraph was needed in the abstract, and thought that it might be better if this was contained in the introduction instead: 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' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC- SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA. From max@maxcrone.org Thu Apr 9 06:13:28 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB083A0B09 for ; Thu, 9 Apr 2020 06:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=maxcrone.org 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 1zWCkjHuko-R for ; Thu, 9 Apr 2020 06:13:26 -0700 (PDT) Received: from relay0181.mxlogin.com (relay0181.mxlogin.com [199.181.239.181]) (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 A966C3A0AE9 for ; Thu, 9 Apr 2020 06:13:25 -0700 (PDT) Received: from filter003.mxroute.com ([168.235.111.26] 168-235-111-26.cloud.ramnode.com) (Authenticated sender: mN4UYu2MZsgR) by relay0181.mxlogin.com (ZoneMTA) with ESMTPSA id 1715f12d86c0000766.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 09 Apr 2020 13:13:22 +0000 X-Zone-Loop: 409ec5a3b4c5e1f649bb935c15bdb78e9dc7e680c168 X-Originating-IP: [168.235.111.26] Received: from ghost.mxroute.com (ghost.mxroute.com [138.201.205.224]) by filter003.mxroute.com (Postfix) with ESMTPS id A8D2460007 for ; Thu, 9 Apr 2020 13:13:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=maxcrone.org; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc: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=PA1wEcaaglZHUCp9fGEj+mZC6e0Oge75OYf2rCzug0k=; b=T2j/33FMN3DVMBIYllf64jvL54 u14z6RiYEUaz+zQJpNKRUIPrf0WO7sA74Ed/uLVg4pQaAYngAj8PIco4LClmb2ANbloMJFliSVm+a UzZPLDYLEAchc6EZt1b2GZjFPNV499zBWM8Y1joBxtBa+Zbb/VUp9yi76fLG3fnPVuvmYdhl8j6bm NwqVPrN+af607v9yLnGg4TPHQshAZsB702/iViKbq1uuXQb88Qg0XvFhnMGNjoLRqo3zvGU8k09gP F84dCd90tig3NG9RfNQj/Z7CdaVzHsA6rnGpqtJ5Lxug+8rKqdXizkuIrF/e/+6nQW3hbbq1MMdAx U5Z+q4gQ==; To: emu@ietf.org From: Max Crone Message-ID: Date: Thu, 9 Apr 2020 16:13:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: max@maxcrone.org Archived-At: Subject: [Emu] Review of draft-aura-eap-noob-08 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, 09 Apr 2020 13:15:01 -0000 Hi all, While reading through the entire EAP-NOOB draft version 8, I compiled a list of mostly editorial corrections and suggestions. Feel free to use whatever you deem fit. If anything remains unclear, I would be happy to discuss further. With kind regards, ~Max Crone 1. Introduction Many proprietary OOB configuration methods exits [...] Typographical error: exits -> exist The device authentication relies on user having physical access to the device, and the of the key exchange security is based on [...] on user -> on a user and the of the key exchange security -> and the key exchange security We follow he common approach taken in pairing protocols: performing a Diffie-Hellman key exchange over the insecure network and authenticating the established key with the help of the OOB channel [...] In order to stay consistent with the first part of this phrase, I would suggest to change "with the help of" to "over". 3.1. Protocol overview In that case, the only way to recover is that the user resets also the peer. the user resets also the peer -> the user also resets the peer 3.2. Protocol messages and sequences Each exchange comprises multiple EAP requests-response pairs [...] requests-response pairs -> request-response pairs 3.2.1. Common handshake in all EAP-NOOB exchanges If one of the peer and server is in the Unregistered (0) state [...] one of the peer and server -> either the peer or server 3.2.2. Initial Exchange The server also sends in the request a list of [...] As part of the request, the server also sends a list of [...] [...] and cryptosuites (Cryptosuites) it supports, [...] The name of the data field for server supported cryptosuites felt confusing to me, because at first I read it as the plural form of cryptosuite, without realizing the last "s" stands for server. When seen in isolation, this is therefore slightly confusing. It is a relatively small issue though, when one continues to read on and sees the Cryptosuitep data field name. 3.2.3. OOB Step However, the receiver MAY buffer redundant OOB messages in case OOB message expiry or similar error detected in the Completion Exchange causes it to return to the Waiting for OOB (1) state. in case OOB message expiry -> in case an OOB message expiry 3.3.2. Message data fields Both kinds of missing input values are are represented by [...] are are -> are 3.4. Fast reconnect and rekeying The failure would typically be detected by the peer or authenticator when session keys no longer are accepted by the other endpoint. no longer are accepted -> are no longer accepted Change in the supported cryptosuites in the EAP server or peer may also cause the need for a new key exchange. Change in -> Changes in 3.4.3. User reset The server could detect that the peer is in the Registered or Reconnecting state but the server itself is in one of the ephemeral states 0..2 [...] state but the server itself -> state, while the server itself In those cases, the user could choose to merge new peer identity with the old one in the server. to merge new peer identity -> to merge the new peer identity 6.2. Identifying correct endpoints OOB implementation with a dedicated app on a mobile device, which communicates with a server API at a pre-configured URL, can protect against such attacks. Doesn't this go against the original motivation of the protocol, where you set out to create an open and interoperable way for OOB configuration of IoT devices? If every manufacturer still has to create a separate app for their devices, the user experience will not improve much compared to the current situation where there already exist many such apps by different manufacturers. Of course, if they would all use the EAP-NOOB protocol, it still is a general improvement in security. As a point of discussion related to this; the required existence of corporate specific EAP servers for authentication of IoT devices has as a consequence that the interoperability of these devices does not improve. Imagine a company decides to shut down a product line and all its respective EAP authentication servers. All future authentication requests will still fail, as there is no entity that can fill in the vacuum left by the removal of authentication servers. IoT devices will only have company specific addresses built in. Or am I missing a piece in this scenario? It could of course also be outside the scope of this protocol. In that case, my apologies for discussing this here. 6.3. Trusted path issues and misbinding attacks The wrong but uncompomised device's PeerInfo [...] uncompomised -> uncompromised 6.6. Downgrading threats As an additional precaution, the EAP server and peer MUST check for downgrading attacks in the Reconnect Exchange af follows. af -> as 7.1. Normative references [NIST-DH] has been withdrawn; it is replaced by the third revision. Appendix C. ServerInfo and PeerInfo contents The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnect Exchange enable the server and peer, respectively, send information about themselves to the other endpoint. send -> to send Appendix D. EAP-NOOB roaming The list is formated as explained in Table 11. formated -> formatted From nobody Wed Apr 15 09:25:24 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE92D3A0C9F for ; Wed, 15 Apr 2020 09:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 dmF-4Obe_toP for ; Wed, 15 Apr 2020 09:25:20 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 8E4DC3A0C9B for ; Wed, 15 Apr 2020 09:25:20 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id m18so465821otq.9 for ; Wed, 15 Apr 2020 09:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ULXlGgB4a2LHjMw6eS9lFGi9znC2eWo1um0Gk5Lqxqg=; b=RLyvUNM8Hin3JDvKoAdTHlBc0SxR1hrlm260ly0/f3uO9bXN2eaKjLlb4ZRjKc8L58 +2PgMEO3ZBPdV2DAaBYpPkaM0FbX7zBFw8s7GxjP1pkLkRbvItu7lRyGlZLMC3W2ngYF OTmXDXxXYuc/XGPZ9gSIxVJSUK2FaPAZPEsNxYMfhp3fVYzyId9TQbxHNNp26E3H7or+ J7EaOIXNem/ea8UEDjXugiPUZmgH49jBZx/Uk5AaZKS6bSQuYgK7w3E/51FWHUuQIhEQ 1ivA4t4LeCnEHTQAAKD7zi4MpPsIR4+FNfH3n0+QDu1eDMhjDvr3Rf1vle7AiMOLR9wL XQrg== 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=ULXlGgB4a2LHjMw6eS9lFGi9znC2eWo1um0Gk5Lqxqg=; b=YJ6ccBLAqD4Fs3E9KredKkQzPyMy4Aw8U79L3hfwBuuZDZ4cgQdYc4S36A9g8+IavQ 9CFenbtNJztcYBdsMx0150oVQ7oMR6F1Ia8D54+Px0UEJ3qqOwDanua4n17KhxuITzoy wbdyTT6jCrA7CRbrBeBUSzgDKfwa4TEdH/YCmhG3kWGa0RT0S06OftZ2Uk6v2P8RwmJN IV+qa1A0+a8r158Op9DlIBkXoNxaEk7p7VSWtpzAn10gcjBsD2Vd1mVO9NgJpAFz4A0y IsC+SV0kaDc9YRgNnkNHRoaGeqDQaY2GlaGbD4mu72HQeZNmdzVIZfxrZtSnhk5i+jDo Dd+w== X-Gm-Message-State: AGi0PubjoOYMOvC7sRq91gKCYf74EjvkV0RARVD/HMsEGbfGZ6inCTkU iS46bLCloNnsAVRaUh5VOOm37w4t0VIbw1Vj0SY= X-Google-Smtp-Source: APiQypL/EewmhD26m/j3xs6GBY2e8Zq9NzZZ/gcmHycBNi3tRzpP+AC8Hs1+BSKXzprjGMZf4+OPi2NNTUZccFDnS+8= X-Received: by 2002:a05:6830:199:: with SMTP id q25mr24413045ota.341.1586967919626; Wed, 15 Apr 2020 09:25:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Oleg Pekar Date: Wed, 15 Apr 2020 19:25:08 +0300 Message-ID: To: Jorge Vergara Cc: Alan DeKok , EMU WG Content-Type: multipart/alternative; boundary="0000000000001e8e9905a356c347" Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 15 Apr 2020 16:25:23 -0000 --0000000000001e8e9905a356c347 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jorge, For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to find the common method of TLS 1.3 support for all three or you just want to release TLS 1.3 support at the same time for all three? For TEAP errata 5770: Technically TEAP RFC suggests the implicit method of taking the correct IMSK[j] and all the subsequent keys after each inner method via negotiation taking place in Crypto-Binding TLV exchange. Let's say we are on the inner method number j that supports both MSK and EMSK and we are server which implementation generates both MSK and EMSK for this inner method. We generated keys according to the rules below - two sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to inner method MSK. Because we don't know whether client implementation supports both MSK and EMSK. S-IMCK[0] =3D session_key_seed For j =3D 1 to n-1 do IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) S-IMCK[j] =3D first 40 octets of IMCK[j] CMK[j] =3D last 20 octets of IMCK[j] So we have two CMK[j] and we create Crypto-Binding TLV with both Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and we can understand from it whether it supports EMSK for this inner method or not. And here we can decide which version of IMCK[j] to take for this inner method - derived from EMSK or MSK. This is just not explicitly specified in the RFC. Could this method work? Should we make it more clearly specified? Or should we change the protocol to arrive explicitly to the understanding which type (MSK/EMSK) of IMSK[j] to use? Thanks Oleg On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara wrote: > >Microsoft has already said that they won't rev their EAP-TLS > implementation until they can also rev PEAP. > > PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the > same time and will postpone TLS 1.3 support until such a time as we are > able to make the updates together. > > >* should the document drop references to TEAP? > > Given Jouni Malinen's comments on implementing TEAP, it may be worth > simply noting that we're waiting for a TEAP update document > > I've reviewed the current errata, and acknowledge their validity, but am > not sure that any of them would impact this document. > > The most relevant errata to this document seems to be > https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the > calculation of keys becomes confusing when methods export both MSK and EM= SK > because it is not clearly specified which value IMCK[j] should take on > during the calculation of S-IMCK[j]. The addition of clarifying informati= on > is welcome, but I don't believe this ambiguity currently prevents a > compliant implementation - for example, an implementation could avoid thi= s > ambiguity by choosing to use either the MSK/EMSK exclusively, and > communicating that to the server via the Compound MAC TLV. The server can > then make a policy decision on whether it is accepting of this decision b= y > the client and follow suit, or reject the client. > > The specifics of resolving this particular errata is a digression from my > main point - I believe a clarification can be added to the main TEAP > document at a future time without impacting the contents of this document= . > Ambiguity about which IMCK to use in S-IMCK calculation should not impact > the definition of the cryptographic calculations. > > On the document contents themselves, I have this review: The key > derivation proposed for TEAP/FAST uses the definition from FAST, which is > not identical to the TEAP derivation. Namely, FAST used MSK[j] in the > derivation, but TEAP uses IMSK[j], which may be equivalent in some cases, > but may not in others where the inner method exports an EMSK. > > Specifically, I believe this line of section 2.2 should change from > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound Keys= ", > S-IMCK[j-1] | MSK[j], 60) > To > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound Keys= ", > S-IMCK[j-1] | IMSK[j], 60) > For TEAP. > > Jorge > > -----Original Message----- > From: Emu On Behalf Of Alan DeKok > Sent: Friday, April 3, 2020 1:48 PM > To: EMU WG > Subject: [Emu] draft-dekok-emu-tls-eap-types discussion > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01&data=3D02%7C01%7Cjo= vergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141a= f91ab2d7cd011db47%7C1%7C0%7C637215437188744711&sdata=3DndLp%2FSzsDlX%2F= KYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3D&reserved=3D0 > > I haven't seen much discussion on the document. There are still some > open questions: > > * should it be published simultaneously with draft-ietf-emu-eap-tls13? > If so, we need some consensus on this document, and quick. > > If not, when do we publish this draft? Microsoft has already said tha= t > they won't rev their EAP-TLS implementation until they can also rev PEAP. > > * Should the document simply drop references to FAST? > It looks like the effort has moved to TEAP. > Perhaps we should note that FAST cannot be used with TLS 1.3, and that > TEAP should be used instead > > * should the document drop references to TEAP? > Given Jouni Malinen's comments on implementing TEAP, it may be worth > simply noting that we're waiting for a TEAP update document > > * Without FAST / TEAP, the document is about 4 pages of text. Is there > anything controversial, missing, etc? > > * What are the barriers to adoption and publication? > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Femu&data=3D02%7C01%7Cjovergar%40microsof= t.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C637215437188744711&sdata=3DlkoHzd0fgN4z1oalqV2jW9pewUGSnlRLe= KpiFew4Yw8%3D&reserved=3D0 > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --0000000000001e8e9905a356c347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jorge,
For Microsoft supported protocol = suite=C2=A0PEAP/TTLS/TEAP - are you planning to find the common method of T= LS 1.3 support for all three or you just want to release TLS 1.3 support at= the same time for all three?

For TEAP errata 5770= :=C2=A0
Technically TEAP RFC suggests the implicit method of taki= ng the correct IMSK[j] and all the subsequent keys after each inner method = via negotiation taking place in Crypto-Binding=C2=A0TLV exchange.=C2=A0

Let's say we are on the inner method number j tha= t supports both MSK and EMSK and we are server=C2=A0which implementation ge= nerates both MSK and EMSK for this inner method. We generated keys accordin= g to the rules below - two sets, for IMSK[j] derived from inner method EMSK= and for IMSK[j] equal to inner method MSK. Because we don't know wheth= er client implementation supports both MSK and EMSK.=C2=A0

S-IMCK[0] =3D =
session_key_seed
      For j =3D 1 to n-1 do
           IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Ke=
ys",
                IMSK[j], 60)
           S-IMCK[j] =3D first 40 octets of IMCK[j]
           CMK[j] =3D last 20 octets of IMCK[j]

<= div>So we have two CMK[j] and we create Crypto-Binding TLV with both Compou= nd MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response an= d we can understand from it whether it supports EMSK for this inner method = or not. And here we can decide which version of IMCK[j] to take for this in= ner method - derived from EMSK or MSK. This is just not explicitly specifie= d in the RFC.=C2=A0

Could this method=C2=A0work? S= hould we make it more clearly specified? Or should we change the protocol t= o arrive explicitly to the understanding which type (MSK/EMSK) of IMSK[j] t= o use?

Thanks
Oleg


On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara <jovergar=3D40microsoft.com@dmarc.ietf.org<= /a>> wrote:
&= gt;Microsoft has already said that they won't rev their EAP-TLS impleme= ntation until they can also rev PEAP.

PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same= time and will postpone TLS 1.3 support until such a time as we are able to= make the updates together.

>* should the document drop references to TEAP?
> Given Jouni Malinen's comments on implementing TEAP, it may be wor= th simply noting that we're waiting for a TEAP update document

I've reviewed the current errata, and acknowledge their validity, but a= m not sure that any of them would impact this document.

The most relevant errata to this document seems to be https= ://www.rfc-editor.org/errata/eid5770. As noted in the errata, the calcu= lation of keys becomes confusing when methods export both MSK and EMSK beca= use it is not clearly specified which value IMCK[j] should take on during t= he calculation of S-IMCK[j]. The addition of clarifying information is welc= ome, but I don't believe this ambiguity currently prevents a compliant = implementation - for example, an implementation could avoid this ambiguity = by choosing to use either the MSK/EMSK exclusively, and communicating that = to the server via the Compound MAC TLV. The server can then make a policy d= ecision on whether it is accepting of this decision by the client and follo= w suit, or reject the client.

The specifics of resolving this particular errata is a digression from my m= ain point - I believe a clarification can be added to the main TEAP documen= t at a future time without impacting the contents of this document. Ambigui= ty about which IMCK to use in S-IMCK calculation should not impact the defi= nition of the cryptographic calculations.

On the document contents themselves, I have this review: The key derivation= proposed for TEAP/FAST uses the definition from FAST, which is not identic= al to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but = TEAP uses IMSK[j], which may be equivalent in some cases, but may not in ot= hers where the inner method exports an EMSK.

Specifically, I believe this line of section 2.2 should change from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-Exporter("EXPORTER:= Inner Methods Compound Keys", S-IMCK[j-1] | MSK[j], 60)
To
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-Exporter("EXPORTER:= Inner Methods Compound Keys", S-IMCK[j-1] | IMSK[j], 60)
For TEAP.

Jorge

-----Original Message-----
From: Emu <emu= -bounces@ietf.org> On Behalf Of Alan DeKok
Sent: Friday, April 3, 2020 1:48 PM
To: EMU WG <emu@ietf.o= rg>
Subject: [Emu] draft-dekok-emu-tls-eap-types discussion

https://nam06.safelinks.protection.ou= tlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-= eap-types-01&amp;data=3D02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc= 4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372154= 37188744711&amp;sdata=3DndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q= %3D&amp;reserved=3D0

=C2=A0 I haven't seen much discussion on the document.=C2=A0 There are = still some open questions:

* should it be published simultaneously with draft-ietf-emu-eap-tls13?
=C2=A0 =C2=A0If so, we need some consensus on this document, and quick.

=C2=A0 =C2=A0If not, when do we publish this draft?=C2=A0 Microsoft has alr= eady said that they won't rev their EAP-TLS implementation until they c= an also rev PEAP.

* Should the document simply drop references to FAST?
=C2=A0 It looks like the effort has moved to TEAP.
=C2=A0 Perhaps we should note that FAST cannot be used with TLS 1.3, and th= at TEAP should be used instead

* should the document drop references to TEAP?
=C2=A0Given Jouni Malinen's comments on implementing TEAP, it may be wo= rth simply noting that we're waiting for a TEAP update document

* Without FAST / TEAP, the document is about 4 pages of text.=C2=A0 Is ther= e anything controversial, missing, etc?

* What are the barriers to adoption and publication?

=C2=A0 Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=3D02%7C01%7Cjo= vergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141a= f91ab2d7cd011db47%7C1%7C0%7C637215437188744711&amp;sdata=3DlkoHzd0fgN4z= 1oalqV2jW9pewUGSnlRLeKpiFew4Yw8%3D&amp;reserved=3D0

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--0000000000001e8e9905a356c347-- From nobody Wed Apr 15 11:32:02 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E393A0F24 for ; Wed, 15 Apr 2020 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=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 u9oGHSIPbsFc for ; Wed, 15 Apr 2020 11:31:49 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2104.outbound.protection.outlook.com [40.107.94.104]) (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 EAEA03A0863 for ; Wed, 15 Apr 2020 11:31:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H8jsBT87r6wbVbWiMi6AwWwxAESjBo+4dTa+pQSoq0TI+GhQByc5VH2Hl9I0smfNrE42JsjjDenn05V2fwT3xuSEv0Exzf7R9oxy7guiUepc46f9L7BHFHufhWZ4jNQevkYS5FljWBVgCLjfgG7tX/Rrkg0O+vhiEMMIfLnL+RxGunC03WxbFs0SfEfoMSycG+5ac9QOLfbIzMG9T7iAjRQj60Dq81NXjXcbUZzmecKsoLcgJz1sFbdeZ2MNh3+0fXU6pVTroqbAz7RbEJ3+UAgr2foE7QRjhBnkQvg2veT+a91IdeadhGMzrMaqb0uuh7iIYNw00R9yIfSVuAvNpw== 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=auctlyu5QKOtzfKaq/E0VqJnJHbqfjq7OFouAQIJH+0=; b=HOXZt/qN6yxK+p3ugPdOefZDdUKMcjcdqwlQ9QIMsa5ouW4MUE4vLS13ATdKWUS8ql1nDKGhivQnEEM/ICkgW8IYbxDLnp1WcroMSU0lfh03y1WLFgVYu5VJ4+QQX5Mfn9aoeuyoCUk+coa3gvFPZJCcdnNOgD4wsVKmyeOgMV6ZnaVWMYvfqtZzJA6M/mdjECXUd7yJn/x+rtzeFdGOOCLmmEHYvsSBkoeg998MGxyIRWbJQD9tuoz5BL6uqSfqJLBQCH6jpzZQsazOWx10WxjA2KQ7WuMor7MTdK0SIiYVmrnlQQP+Nv7inJnq8o5yS9cwf4M6CctZ3ksAYKg9Yg== 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=auctlyu5QKOtzfKaq/E0VqJnJHbqfjq7OFouAQIJH+0=; b=HeppOhBkwv+mdrpi52NSowHKRquq7KK6QX17nlB2cxPUDAliKVw1sv8BUO+RWgIoyFG/KLtK7bpwu37ohd2zkSAMzEOWPfUTf/dwha49h4WmvjcBXi9LkztY9UnxiCCQZn5bekbMqUfUl3raaYVHmaZAjbo5M08Ejr2Jv7chIMI= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1494.namprd21.prod.outlook.com (2603:10b6:610:88::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.4; Wed, 15 Apr 2020 18:31:47 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703%6]) with mapi id 15.20.2937.000; Wed, 15 Apr 2020 18:31:47 +0000 From: Jorge Vergara To: Oleg Pekar , Jorge Vergara CC: EMU WG Thread-Topic: [Emu] draft-dekok-emu-tls-eap-types discussion Thread-Index: AQHWCflAito/q8SdbkqYuDgLHK2lQ6huIjRAgAxOtACAACFLQA== Date: Wed, 15 Apr 2020 18:31:47 +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=jovergar@microsoft.com; x-originating-ip: [2001:4898:80e8:8:6521:501e:a10c:f455] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5d570a7b-2824-433c-6d70-08d7e16b41c8 x-ms-traffictypediagnostic: CH2PR21MB1494: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(5660300002)(8936002)(966005)(8676002)(81156014)(186003)(10290500003)(2906002)(110136005)(478600001)(53546011)(316002)(4326008)(82960400001)(82950400001)(33656002)(8990500004)(71200400001)(52536014)(76116006)(64756008)(7696005)(6506007)(66476007)(66556008)(66946007)(55016002)(86362001)(9686003)(66446008); DIR:OUT; SFP:1102; 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: BO5oh97OAgvN+8leDIGX6EOeBNIcsElWbFEwuMISw62WG85TXnzHK4iQox7oghclPwWFliO/ELriY4IeLOUaT4DqBcAf8foPP454mgQfpdIu5EOpmIJuJCoZtrdBIvmi19ndZiApvtxg9TRA3A1oO42WH2wLZ4B04C0ZWYRzq0PgoBUPkDdSD+Wc+N8WZywMCveVVA1FbvzhJU64MzmzACC/oYhsuUzKg5CXm7cD02SX+VWa8E08zEHg3OrnQQu7S3FmIGihC0JuCG6FuUliUk6lPIXSvzFBR9dx9MX0DzFdCgKiUz2zR3L8s9CjZqXXDUhJy0J2stfA3FWV9OdngcJmThCwx42fSoAeFEezE5HzV1gqZ1zXBf6rqoF5Dr/C23CbFDljtUI36OdUFyfqFiYG0p66PIN5U7LR7/0pmkWABisKu5kroswIRrq7pIg/pRZl0ONTCLnYS1ACHYQDh2hdKegeLOy0XnIQyLl3Gnhahckg9rUCZgMD/kFxZHIM7RE21cBzKQ+tRsBjdxRTSg== x-ms-exchange-antispam-messagedata: Am5Zd838D5Ax4D9URbdj2DrofGQXNtfCBe0IibyvzllSNujr9fFUdKqgGIirfnZawTZ4JKY6pCDQb4b9uym3rAgi0WXhF5H5YQgbS+bFYSfpjLtSDr3e/SsMQcMnFoHbNvf5+9ggZA0C6oUC62UBZ16vjIpCVv32eRQa8HKN3NSxRXk9KMcXynQH+eDpUH9YgPXh1a/FkHynDQGB55Ff0w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR21MB138182A1A04935CD39C1C07CD1DB0CH2PR21MB1381namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d570a7b-2824-433c-6d70-08d7e16b41c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 18:31:47.6752 (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: ZvF61Y3msSfj8Mt88NP3b3rjefbMTXJm/2kKNz9i7iPG18e0GNOALw70oGWMfZDKIn5do1PvGlKm1i61EaswPA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1494 Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 15 Apr 2020 18:31:52 -0000 --_000_CH2PR21MB138182A1A04935CD39C1C07CD1DB0CH2PR21MB1381namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGb3IgTWljcm9zb2Z0IHN1cHBvcnRlZCBwcm90b2NvbCBzdWl0ZSBQRUFQL1RUTFMvVEVBUCAt IGFyZSB5b3UgcGxhbm5pbmcgdG8gZmluZCB0aGUgY29tbW9uIG1ldGhvZCBvZiBUTFMgMS4zIHN1 cHBvcnQgZm9yIGFsbCB0aHJlZSBvciB5b3UganVzdCB3YW50IHRvIHJlbGVhc2UgVExTIDEuMyBz dXBwb3J0IGF0IHRoZSBzYW1lIHRpbWUgZm9yIGFsbCB0aHJlZT8NCg0KSXTigJlzIG5vdCBvdXIg aW50ZW50aW9uIHRvIHRyeSB0byBmb3JjZSB0aGUgc2FtZSBzb2x1dGlvbiBmb3IgZXZlcnkgbWV0 aG9kLiBXZSBwbGFuIHRvIHVwZGF0ZSBvdXIgaW1wbGVtZW50YXRpb25zIGF0IHRoZSBzYW1lIHRp bWUsIHNpbmNlIHdlIGFudGljaXBhdGUgdGhlIHVwZGF0ZXMgd2lsbCBiZSBzaW1pbGFyICh0aG91 Z2ggbm90IG5lY2Vzc2FyaWx5IGlkZW50aWNhbCkuDQoNCj5Db3VsZCB0aGlzIG1ldGhvZCB3b3Jr PyBTaG91bGQgd2UgbWFrZSBpdCBtb3JlIGNsZWFybHkgc3BlY2lmaWVkPyBPciBzaG91bGQgd2Ug Y2hhbmdlIHRoZSBwcm90b2NvbCB0byBhcnJpdmUgZXhwbGljaXRseSB0byB0aGUgdW5kZXJzdGFu ZGluZyB3aGljaCB0eXBlIChNU0svRU1TSykgb2YgSU1TS1tqXSB0byB1c2U/DQoNCllvdSBjbGFy aWZpY2F0aW9uIGlzIHdoYXQgSSB1bmRlcnN0b29kIHRoZSBpbnRlbnRpb24gb2YgdGhlIFJGQyB0 byBiZSBhcyB3ZWxsLCBhbmQgbWFrZXMgc2Vuc2UgdG8gbWUuIEkgZG9u4oCZdCB0aGluayB0aGVy ZSBuZWVkcyB0byBiZSBhIHByb3RvY29sIHVwZGF0ZSBpZiB0aGlzIGNsYXJpZmljYXRpb24gc291 bmRzIGdvb2QgdG8gYWxsIHBhcnRpZXMuIEkgd291bGQgd2VsY29tZSBKb3VuaeKAmXMgdGhvdWdo dHMgYXMgdGhlIGZpbGVyIG9mIHRoZSBlcnJhdGEuDQoNCkpvcmdlDQoNCkZyb206IEVtdSA8ZW11 LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBPbGVnIFBla2FyDQpTZW50OiBXZWRuZXNk YXksIEFwcmlsIDE1LCAyMDIwIDk6MjUgQU0NClRvOiBKb3JnZSBWZXJnYXJhIDxqb3Zlcmdhcj00 MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogRU1VIFdHIDxlbXVAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0VtdV0gZHJhZnQtZGVrb2stZW11LXRscy1lYXAtdHlwZXMgZGlzY3Vz c2lvbg0KDQpIaSBKb3JnZSwNCkZvciBNaWNyb3NvZnQgc3VwcG9ydGVkIHByb3RvY29sIHN1aXRl IFBFQVAvVFRMUy9URUFQIC0gYXJlIHlvdSBwbGFubmluZyB0byBmaW5kIHRoZSBjb21tb24gbWV0 aG9kIG9mIFRMUyAxLjMgc3VwcG9ydCBmb3IgYWxsIHRocmVlIG9yIHlvdSBqdXN0IHdhbnQgdG8g cmVsZWFzZSBUTFMgMS4zIHN1cHBvcnQgYXQgdGhlIHNhbWUgdGltZSBmb3IgYWxsIHRocmVlPw0K DQpGb3IgVEVBUCBlcnJhdGEgNTc3MDoNClRlY2huaWNhbGx5IFRFQVAgUkZDIHN1Z2dlc3RzIHRo ZSBpbXBsaWNpdCBtZXRob2Qgb2YgdGFraW5nIHRoZSBjb3JyZWN0IElNU0tbal0gYW5kIGFsbCB0 aGUgc3Vic2VxdWVudCBrZXlzIGFmdGVyIGVhY2ggaW5uZXIgbWV0aG9kIHZpYSBuZWdvdGlhdGlv biB0YWtpbmcgcGxhY2UgaW4gQ3J5cHRvLUJpbmRpbmcgVExWIGV4Y2hhbmdlLg0KDQpMZXQncyBz YXkgd2UgYXJlIG9uIHRoZSBpbm5lciBtZXRob2QgbnVtYmVyIGogdGhhdCBzdXBwb3J0cyBib3Ro IE1TSyBhbmQgRU1TSyBhbmQgd2UgYXJlIHNlcnZlciB3aGljaCBpbXBsZW1lbnRhdGlvbiBnZW5l cmF0ZXMgYm90aCBNU0sgYW5kIEVNU0sgZm9yIHRoaXMgaW5uZXIgbWV0aG9kLiBXZSBnZW5lcmF0 ZWQga2V5cyBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGJlbG93IC0gdHdvIHNldHMsIGZvciBJTVNL W2pdIGRlcml2ZWQgZnJvbSBpbm5lciBtZXRob2QgRU1TSyBhbmQgZm9yIElNU0tbal0gZXF1YWwg dG8gaW5uZXIgbWV0aG9kIE1TSy4gQmVjYXVzZSB3ZSBkb24ndCBrbm93IHdoZXRoZXIgY2xpZW50 IGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGJvdGggTVNLIGFuZCBFTVNLLg0KDQoNClMtSU1DS1sw XSA9IHNlc3Npb25fa2V5X3NlZWQNCg0KICAgICAgRm9yIGogPSAxIHRvIG4tMSBkbw0KDQogICAg ICAgICAgIElNQ0tbal0gPSBUTFMtUFJGKFMtSU1DS1tqLTFdLCAiSW5uZXIgTWV0aG9kcyBDb21w b3VuZCBLZXlzIiwNCg0KICAgICAgICAgICAgICAgIElNU0tbal0sIDYwKQ0KDQogICAgICAgICAg IFMtSU1DS1tqXSA9IGZpcnN0IDQwIG9jdGV0cyBvZiBJTUNLW2pdDQoNCiAgICAgICAgICAgQ01L W2pdID0gbGFzdCAyMCBvY3RldHMgb2YgSU1DS1tqXQ0KDQpTbyB3ZSBoYXZlIHR3byBDTUtbal0g YW5kIHdlIGNyZWF0ZSBDcnlwdG8tQmluZGluZyBUTFYgd2l0aCBib3RoIENvbXBvdW5kIE1BQyBm b3IgTVNLIGFuZCBFTVNLLiBUaGUgY2xpZW50IHNlbmRzIENyeXB0by1CaW5kaW5nIFRMViBpbiBy ZXNwb25zZSBhbmQgd2UgY2FuIHVuZGVyc3RhbmQgZnJvbSBpdCB3aGV0aGVyIGl0IHN1cHBvcnRz IEVNU0sgZm9yIHRoaXMgaW5uZXIgbWV0aG9kIG9yIG5vdC4gQW5kIGhlcmUgd2UgY2FuIGRlY2lk ZSB3aGljaCB2ZXJzaW9uIG9mIElNQ0tbal0gdG8gdGFrZSBmb3IgdGhpcyBpbm5lciBtZXRob2Qg LSBkZXJpdmVkIGZyb20gRU1TSyBvciBNU0suIFRoaXMgaXMganVzdCBub3QgZXhwbGljaXRseSBz cGVjaWZpZWQgaW4gdGhlIFJGQy4NCg0KQ291bGQgdGhpcyBtZXRob2Qgd29yaz8gU2hvdWxkIHdl IG1ha2UgaXQgbW9yZSBjbGVhcmx5IHNwZWNpZmllZD8gT3Igc2hvdWxkIHdlIGNoYW5nZSB0aGUg cHJvdG9jb2wgdG8gYXJyaXZlIGV4cGxpY2l0bHkgdG8gdGhlIHVuZGVyc3RhbmRpbmcgd2hpY2gg dHlwZSAoTVNLL0VNU0spIG9mIElNU0tbal0gdG8gdXNlPw0KDQpUaGFua3MNCk9sZWcNCg0KDQpP biBXZWQsIEFwciA4LCAyMDIwIGF0IDEyOjA5IEFNIEpvcmdlIFZlcmdhcmEgPGpvdmVyZ2FyPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJj LmlldGYub3JnPj4gd3JvdGU6DQo+TWljcm9zb2Z0IGhhcyBhbHJlYWR5IHNhaWQgdGhhdCB0aGV5 IHdvbid0IHJldiB0aGVpciBFQVAtVExTIGltcGxlbWVudGF0aW9uIHVudGlsIHRoZXkgY2FuIGFs c28gcmV2IFBFQVAuDQoNClBFQVAvVFRMUy9URUFQIC0gd2UgKE1pY3Jvc29mdCkgYmVsaWV2ZSBh bGwgc2hvdWxkIGJlIGFkZHJlc3NlZCBhdCB0aGUgc2FtZSB0aW1lIGFuZCB3aWxsIHBvc3Rwb25l IFRMUyAxLjMgc3VwcG9ydCB1bnRpbCBzdWNoIGEgdGltZSBhcyB3ZSBhcmUgYWJsZSB0byBtYWtl IHRoZSB1cGRhdGVzIHRvZ2V0aGVyLg0KDQo+KiBzaG91bGQgdGhlIGRvY3VtZW50IGRyb3AgcmVm ZXJlbmNlcyB0byBURUFQPw0KPiBHaXZlbiBKb3VuaSBNYWxpbmVuJ3MgY29tbWVudHMgb24gaW1w bGVtZW50aW5nIFRFQVAsIGl0IG1heSBiZSB3b3J0aCBzaW1wbHkgbm90aW5nIHRoYXQgd2UncmUg d2FpdGluZyBmb3IgYSBURUFQIHVwZGF0ZSBkb2N1bWVudA0KDQpJJ3ZlIHJldmlld2VkIHRoZSBj dXJyZW50IGVycmF0YSwgYW5kIGFja25vd2xlZGdlIHRoZWlyIHZhbGlkaXR5LCBidXQgYW0gbm90 IHN1cmUgdGhhdCBhbnkgb2YgdGhlbSB3b3VsZCBpbXBhY3QgdGhpcyBkb2N1bWVudC4NCg0KVGhl IG1vc3QgcmVsZXZhbnQgZXJyYXRhIHRvIHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gYmUgaHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU3NzA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LnJmYy1lZGl0 b3Iub3JnJTJGZXJyYXRhJTJGZWlkNTc3MCZkYXRhPTAyJTdDMDElN0Nqb3ZlcmdhciU0MG1pY3Jv c29mdC5jb20lN0M1ZDg0OTNlOWE2NjU0OTM1NWM2NTA4ZDdlMTU5OWM1ZiU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyMjU2NDczNDE0NTUyOTcmc2RhdGE9 VldJSlRWcllMUFdtZzZKT1ByV2Jpd3RVSkdIa3RhRm94R3VzcWxkTEhyZyUzRCZyZXNlcnZlZD0w Pi4gQXMgbm90ZWQgaW4gdGhlIGVycmF0YSwgdGhlIGNhbGN1bGF0aW9uIG9mIGtleXMgYmVjb21l cyBjb25mdXNpbmcgd2hlbiBtZXRob2RzIGV4cG9ydCBib3RoIE1TSyBhbmQgRU1TSyBiZWNhdXNl IGl0IGlzIG5vdCBjbGVhcmx5IHNwZWNpZmllZCB3aGljaCB2YWx1ZSBJTUNLW2pdIHNob3VsZCB0 YWtlIG9uIGR1cmluZyB0aGUgY2FsY3VsYXRpb24gb2YgUy1JTUNLW2pdLiBUaGUgYWRkaXRpb24g b2YgY2xhcmlmeWluZyBpbmZvcm1hdGlvbiBpcyB3ZWxjb21lLCBidXQgSSBkb24ndCBiZWxpZXZl IHRoaXMgYW1iaWd1aXR5IGN1cnJlbnRseSBwcmV2ZW50cyBhIGNvbXBsaWFudCBpbXBsZW1lbnRh dGlvbiAtIGZvciBleGFtcGxlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBhdm9pZCB0aGlzIGFt YmlndWl0eSBieSBjaG9vc2luZyB0byB1c2UgZWl0aGVyIHRoZSBNU0svRU1TSyBleGNsdXNpdmVs eSwgYW5kIGNvbW11bmljYXRpbmcgdGhhdCB0byB0aGUgc2VydmVyIHZpYSB0aGUgQ29tcG91bmQg TUFDIFRMVi4gVGhlIHNlcnZlciBjYW4gdGhlbiBtYWtlIGEgcG9saWN5IGRlY2lzaW9uIG9uIHdo ZXRoZXIgaXQgaXMgYWNjZXB0aW5nIG9mIHRoaXMgZGVjaXNpb24gYnkgdGhlIGNsaWVudCBhbmQg Zm9sbG93IHN1aXQsIG9yIHJlamVjdCB0aGUgY2xpZW50Lg0KDQpUaGUgc3BlY2lmaWNzIG9mIHJl c29sdmluZyB0aGlzIHBhcnRpY3VsYXIgZXJyYXRhIGlzIGEgZGlncmVzc2lvbiBmcm9tIG15IG1h aW4gcG9pbnQgLSBJIGJlbGlldmUgYSBjbGFyaWZpY2F0aW9uIGNhbiBiZSBhZGRlZCB0byB0aGUg bWFpbiBURUFQIGRvY3VtZW50IGF0IGEgZnV0dXJlIHRpbWUgd2l0aG91dCBpbXBhY3RpbmcgdGhl IGNvbnRlbnRzIG9mIHRoaXMgZG9jdW1lbnQuIEFtYmlndWl0eSBhYm91dCB3aGljaCBJTUNLIHRv IHVzZSBpbiBTLUlNQ0sgY2FsY3VsYXRpb24gc2hvdWxkIG5vdCBpbXBhY3QgdGhlIGRlZmluaXRp b24gb2YgdGhlIGNyeXB0b2dyYXBoaWMgY2FsY3VsYXRpb25zLg0KDQpPbiB0aGUgZG9jdW1lbnQg Y29udGVudHMgdGhlbXNlbHZlcywgSSBoYXZlIHRoaXMgcmV2aWV3OiBUaGUga2V5IGRlcml2YXRp b24gcHJvcG9zZWQgZm9yIFRFQVAvRkFTVCB1c2VzIHRoZSBkZWZpbml0aW9uIGZyb20gRkFTVCwg d2hpY2ggaXMgbm90IGlkZW50aWNhbCB0byB0aGUgVEVBUCBkZXJpdmF0aW9uLiBOYW1lbHksIEZB U1QgdXNlZCBNU0tbal0gaW4gdGhlIGRlcml2YXRpb24sIGJ1dCBURUFQIHVzZXMgSU1TS1tqXSwg d2hpY2ggbWF5IGJlIGVxdWl2YWxlbnQgaW4gc29tZSBjYXNlcywgYnV0IG1heSBub3QgaW4gb3Ro ZXJzIHdoZXJlIHRoZSBpbm5lciBtZXRob2QgZXhwb3J0cyBhbiBFTVNLLg0KDQpTcGVjaWZpY2Fs bHksIEkgYmVsaWV2ZSB0aGlzIGxpbmUgb2Ygc2VjdGlvbiAyLjIgc2hvdWxkIGNoYW5nZSBmcm9t DQogICAgICAgICAgSU1DS1tqXSA9IFRMUy1FeHBvcnRlcigiRVhQT1JURVI6IElubmVyIE1ldGhv ZHMgQ29tcG91bmQgS2V5cyIsIFMtSU1DS1tqLTFdIHwgTVNLW2pdLCA2MCkNClRvDQogICAgICAg ICAgSU1DS1tqXSA9IFRMUy1FeHBvcnRlcigiRVhQT1JURVI6IElubmVyIE1ldGhvZHMgQ29tcG91 bmQgS2V5cyIsIFMtSU1DS1tqLTFdIHwgSU1TS1tqXSwgNjApDQpGb3IgVEVBUC4NCg0KSm9yZ2UN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVtdSA8ZW11LWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmVtdS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEFsYW4gRGVL b2sNClNlbnQ6IEZyaWRheSwgQXByaWwgMywgMjAyMCAxOjQ4IFBNDQpUbzogRU1VIFdHIDxlbXVA aWV0Zi5vcmc8bWFpbHRvOmVtdUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbRW11XSBkcmFmdC1kZWtv ay1lbXUtdGxzLWVhcC10eXBlcyBkaXNjdXNzaW9uDQoNCmh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRmRyYWZ0LWRla29rLWVtdS10bHMtZWFwLXR5cGVzLTAxJmFtcDtkYXRhPTAyJTdD MDElN0Nqb3ZlcmdhciU0MG1pY3Jvc29mdC5jb20lN0MyYzQyMDk1ZWRjNGU0Y2Q2MWNlNDA4ZDdk ODEwNjIwMCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2Mzcy MTU0MzcxODg3NDQ3MTEmYW1wO3NkYXRhPW5kTHAlMkZTenNEbFglMkZLWXgwVVIwdWY3N3JIZ0Nq R2VqNGtkWlBweXd1RDlRJTNEJmFtcDtyZXNlcnZlZD0wPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3Jn JTJGaHRtbCUyRmRyYWZ0LWRla29rLWVtdS10bHMtZWFwLXR5cGVzLTAxJmRhdGE9MDIlN0MwMSU3 Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3QzVkODQ5M2U5YTY2NTQ5MzU1YzY1MDhkN2UxNTk5 YzVmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIyNTY0 NzM0MTQ1NTI5NyZzZGF0YT1oJTJGOFo2d2NtR1FCWXlBYnU2VHRZTThURGw2VnVoenpOM1Y5dzRy eGNBVG8lM0QmcmVzZXJ2ZWQ9MD4NCg0KICBJIGhhdmVuJ3Qgc2VlbiBtdWNoIGRpc2N1c3Npb24g b24gdGhlIGRvY3VtZW50LiAgVGhlcmUgYXJlIHN0aWxsIHNvbWUgb3BlbiBxdWVzdGlvbnM6DQoN Ciogc2hvdWxkIGl0IGJlIHB1Ymxpc2hlZCBzaW11bHRhbmVvdXNseSB3aXRoIGRyYWZ0LWlldGYt ZW11LWVhcC10bHMxMz8NCiAgIElmIHNvLCB3ZSBuZWVkIHNvbWUgY29uc2Vuc3VzIG9uIHRoaXMg ZG9jdW1lbnQsIGFuZCBxdWljay4NCg0KICAgSWYgbm90LCB3aGVuIGRvIHdlIHB1Ymxpc2ggdGhp cyBkcmFmdD8gIE1pY3Jvc29mdCBoYXMgYWxyZWFkeSBzYWlkIHRoYXQgdGhleSB3b24ndCByZXYg dGhlaXIgRUFQLVRMUyBpbXBsZW1lbnRhdGlvbiB1bnRpbCB0aGV5IGNhbiBhbHNvIHJldiBQRUFQ Lg0KDQoqIFNob3VsZCB0aGUgZG9jdW1lbnQgc2ltcGx5IGRyb3AgcmVmZXJlbmNlcyB0byBGQVNU Pw0KICBJdCBsb29rcyBsaWtlIHRoZSBlZmZvcnQgaGFzIG1vdmVkIHRvIFRFQVAuDQogIFBlcmhh cHMgd2Ugc2hvdWxkIG5vdGUgdGhhdCBGQVNUIGNhbm5vdCBiZSB1c2VkIHdpdGggVExTIDEuMywg YW5kIHRoYXQgVEVBUCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkDQoNCiogc2hvdWxkIHRoZSBkb2N1 bWVudCBkcm9wIHJlZmVyZW5jZXMgdG8gVEVBUD8NCiBHaXZlbiBKb3VuaSBNYWxpbmVuJ3MgY29t bWVudHMgb24gaW1wbGVtZW50aW5nIFRFQVAsIGl0IG1heSBiZSB3b3J0aCBzaW1wbHkgbm90aW5n IHRoYXQgd2UncmUgd2FpdGluZyBmb3IgYSBURUFQIHVwZGF0ZSBkb2N1bWVudA0KDQoqIFdpdGhv dXQgRkFTVCAvIFRFQVAsIHRoZSBkb2N1bWVudCBpcyBhYm91dCA0IHBhZ2VzIG9mIHRleHQuICBJ cyB0aGVyZSBhbnl0aGluZyBjb250cm92ZXJzaWFsLCBtaXNzaW5nLCBldGM/DQoNCiogV2hhdCBh cmUgdGhlIGJhcnJpZXJzIHRvIGFkb3B0aW9uIGFuZCBwdWJsaWNhdGlvbj8NCg0KICBBbGFuIERl S29rLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RW11IG1haWxpbmcgbGlzdA0KRW11QGlldGYub3JnPG1haWx0bzpFbXVAaWV0Zi5vcmc+DQpodHRw czovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZlbXUmYW1wO2RhdGE9MDIl N0MwMSU3Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3QzJjNDIwOTVlZGM0ZTRjZDYxY2U0MDhk N2Q4MTA2MjAwJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz NzIxNTQzNzE4ODc0NDcxMSZhbXA7c2RhdGE9bGtvSHpkMGZnTjR6MW9hbHFWMmpXOXBld1VHU25s UkxlS3BpRmV3NFl3OCUzRCZhbXA7cmVzZXJ2ZWQ9MDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZlbXUmZGF0YT0wMiU3QzAxJTdDam92ZXJnYXIlNDBtaWNyb3Nv ZnQuY29tJTdDNWQ4NDkzZTlhNjY1NDkzNTVjNjUwOGQ3ZTE1OTljNWYlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjI1NjQ3MzQxNDY1MjkyJnNkYXRhPVRN TVpJWk9UOFQ4ZHRObjhudzFoOXpQRWpPbFJRdVdGcld0VGtQeHRWTzQlM0QmcmVzZXJ2ZWQ9MD4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVtdSBt YWlsaW5nIGxpc3QNCkVtdUBpZXRmLm9yZzxtYWlsdG86RW11QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXU8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGZW11JmRhdGE9MDIlN0MwMSU3Q2pvdmVyZ2FyJTQwbWljcm9z b2Z0LmNvbSU3QzVkODQ5M2U5YTY2NTQ5MzU1YzY1MDhkN2UxNTk5YzVmJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIyNTY0NzM0MTQ3NTI4NiZzZGF0YT1r OUhGWDJGZEZ3OVIyeFVWSEhIVmhsV2o5dXhtWWRXb3lxRXclMkJYQVpjbGMlM0QmcmVzZXJ2ZWQ9 MD4NCg== --_000_CH2PR21MB138182A1A04935CD39C1C07CD1DB0CH2PR21MB1381namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IEZvciBNaWNyb3NvZnQgc3VwcG9ydGVkIHByb3RvY29sIHN1aXRlJm5ic3A7UEVBUC9U VExTL1RFQVAgLSBhcmUgeW91IHBsYW5uaW5nIHRvIGZpbmQgdGhlIGNvbW1vbiBtZXRob2Qgb2Yg VExTIDEuMyBzdXBwb3J0IGZvciBhbGwgdGhyZWUgb3IgeW91IGp1c3Qgd2FudCB0byByZWxlYXNl IFRMUyAxLjMgc3VwcG9ydCBhdCB0aGUgc2FtZSB0aW1lIGZvciBhbGwgdGhyZWU/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl04oCZcyBub3Qgb3VyIGludGVudGlvbiB0byB0cnkgdG8gZm9yY2Ug dGhlIHNhbWUgc29sdXRpb24gZm9yIGV2ZXJ5IG1ldGhvZC4gV2UgcGxhbiB0byB1cGRhdGUgb3Vy IGltcGxlbWVudGF0aW9ucyBhdCB0aGUgc2FtZSB0aW1lLCBzaW5jZSB3ZSBhbnRpY2lwYXRlIHRo ZSB1cGRhdGVzIHdpbGwgYmUgc2ltaWxhciAodGhvdWdoIG5vdCBuZWNlc3NhcmlseSBpZGVudGlj YWwpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Q291bGQgdGhpcyBtZXRob2QmbmJzcDt3 b3JrPyBTaG91bGQgd2UgbWFrZSBpdCBtb3JlIGNsZWFybHkgc3BlY2lmaWVkPyBPciBzaG91bGQg d2UgY2hhbmdlIHRoZSBwcm90b2NvbCB0byBhcnJpdmUgZXhwbGljaXRseSB0byB0aGUgdW5kZXJz dGFuZGluZyB3aGljaCB0eXBlIChNU0svRU1TSykgb2YgSU1TS1tqXSB0byB1c2U/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPllvdSBjbGFyaWZpY2F0aW9uIGlzIHdoYXQgSSB1bmRlcnN0b29kIHRo ZSBpbnRlbnRpb24gb2YgdGhlIFJGQyB0byBiZSBhcyB3ZWxsLCBhbmQgbWFrZXMgc2Vuc2UgdG8g bWUuIEkgZG9u4oCZdCB0aGluayB0aGVyZSBuZWVkcyB0byBiZSBhIHByb3RvY29sIHVwZGF0ZSBp ZiB0aGlzIGNsYXJpZmljYXRpb24gc291bmRzIGdvb2QgdG8gYWxsIHBhcnRpZXMuIEkgd291bGQg d2VsY29tZSBKb3VuaeKAmXMgdGhvdWdodHMgYXMNCiB0aGUgZmlsZXIgb2YgdGhlIGVycmF0YS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9yZ2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVtdSAmbHQ7ZW11LWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpPbGVnIFBla2FyPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTUsIDIwMjAgOToyNSBBTTxicj4NCjxiPlRvOjwvYj4g Sm9yZ2UgVmVyZ2FyYSAmbHQ7am92ZXJnYXI9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRU1VIFdHICZsdDtlbXVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbRW11XSBkcmFmdC1kZWtvay1lbXUtdGxzLWVhcC10eXBlcyBkaXNj dXNzaW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBK b3JnZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkZvciBNaWNyb3NvZnQgc3VwcG9ydGVkIHByb3RvY29sIHN1aXRlJm5ic3A7UEVBUC9UVExTL1RF QVAgLSBhcmUgeW91IHBsYW5uaW5nIHRvIGZpbmQgdGhlIGNvbW1vbiBtZXRob2Qgb2YgVExTIDEu MyBzdXBwb3J0IGZvciBhbGwgdGhyZWUgb3IgeW91IGp1c3Qgd2FudCB0byByZWxlYXNlIFRMUyAx LjMgc3VwcG9ydCBhdCB0aGUgc2FtZSB0aW1lIGZvciBhbGwgdGhyZWU/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBURUFQIGVycmF0YSA1 NzcwOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGVjaG5pY2FsbHkgVEVBUCBSRkMgc3VnZ2VzdHMgdGhlIGltcGxpY2l0IG1ldGhvZCBv ZiB0YWtpbmcgdGhlIGNvcnJlY3QgSU1TS1tqXSBhbmQgYWxsIHRoZSBzdWJzZXF1ZW50IGtleXMg YWZ0ZXIgZWFjaCBpbm5lciBtZXRob2QgdmlhIG5lZ290aWF0aW9uIHRha2luZyBwbGFjZSBpbiBD cnlwdG8tQmluZGluZyZuYnNwO1RMViBleGNoYW5nZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0J3Mgc2F5IHdlIGFyZSBvbiB0 aGUgaW5uZXIgbWV0aG9kIG51bWJlciBqIHRoYXQgc3VwcG9ydHMgYm90aCBNU0sgYW5kIEVNU0sg YW5kIHdlIGFyZSBzZXJ2ZXImbmJzcDt3aGljaCBpbXBsZW1lbnRhdGlvbiBnZW5lcmF0ZXMgYm90 aCBNU0sgYW5kIEVNU0sgZm9yIHRoaXMgaW5uZXIgbWV0aG9kLiBXZSBnZW5lcmF0ZWQga2V5cyBh Y2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGJlbG93IC0gdHdvIHNldHMsIGZvciBJTVNLW2pdDQogZGVy aXZlZCBmcm9tIGlubmVyIG1ldGhvZCBFTVNLIGFuZCBmb3IgSU1TS1tqXSBlcXVhbCB0byBpbm5l ciBtZXRob2QgTVNLLiBCZWNhdXNlIHdlIGRvbid0IGtub3cgd2hldGhlciBjbGllbnQgaW1wbGVt ZW50YXRpb24gc3VwcG9ydHMgYm90aCBNU0sgYW5kIEVNU0suJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlMtSU1DS1swXSA9IHNlc3Npb25fa2V5X3NlZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRm9yIGogPSAxIHRvIG4tMSBkbzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJTUNLW2pdID0gVExT LVBSRihTLUlNQ0tbai0xXSwgJnF1b3Q7SW5uZXIgTWV0aG9kcyBDb21wb3VuZCBLZXlzJnF1b3Q7 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJTVNLW2pdLCA2MCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUy1JTUNL W2pdID0gZmlyc3QgNDAgb2N0ZXRzIG9mIElNQ0tbal08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ01LW2pdID0gbGFzdCAyMCBvY3Rl dHMgb2YgSU1DS1tqXTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3ZSBoYXZlIHR3byBDTUtbal0gYW5kIHdlIGNyZWF0ZSBD cnlwdG8tQmluZGluZyBUTFYgd2l0aCBib3RoIENvbXBvdW5kIE1BQyBmb3IgTVNLIGFuZCBFTVNL LiBUaGUgY2xpZW50IHNlbmRzIENyeXB0by1CaW5kaW5nIFRMViBpbiByZXNwb25zZSBhbmQgd2Ug Y2FuIHVuZGVyc3RhbmQgZnJvbSBpdCB3aGV0aGVyIGl0IHN1cHBvcnRzIEVNU0sgZm9yIHRoaXMg aW5uZXIgbWV0aG9kIG9yIG5vdC4gQW5kIGhlcmUNCiB3ZSBjYW4gZGVjaWRlIHdoaWNoIHZlcnNp b24gb2YgSU1DS1tqXSB0byB0YWtlIGZvciB0aGlzIGlubmVyIG1ldGhvZCAtIGRlcml2ZWQgZnJv bSBFTVNLIG9yIE1TSy4gVGhpcyBpcyBqdXN0IG5vdCBleHBsaWNpdGx5IHNwZWNpZmllZCBpbiB0 aGUgUkZDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Db3VsZCB0aGlzIG1ldGhvZCZuYnNwO3dvcms/IFNob3VsZCB3ZSBtYWtlIGl0 IG1vcmUgY2xlYXJseSBzcGVjaWZpZWQ/IE9yIHNob3VsZCB3ZSBjaGFuZ2UgdGhlIHByb3RvY29s IHRvIGFycml2ZSBleHBsaWNpdGx5IHRvIHRoZSB1bmRlcnN0YW5kaW5nIHdoaWNoIHR5cGUgKE1T Sy9FTVNLKSBvZiBJTVNLW2pdIHRvIHVzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbGVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDgsIDIwMjAg YXQgMTI6MDkgQU0gSm9yZ2UgVmVyZ2FyYSAmbHQ7am92ZXJnYXI9PGEgaHJlZj0ibWFpbHRvOjQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7TWljcm9zb2Z0IGhhcyBhbHJlYWR5IHNhaWQgdGhhdCB0 aGV5IHdvbid0IHJldiB0aGVpciBFQVAtVExTIGltcGxlbWVudGF0aW9uIHVudGlsIHRoZXkgY2Fu IGFsc28gcmV2IFBFQVAuPGJyPg0KPGJyPg0KUEVBUC9UVExTL1RFQVAgLSB3ZSAoTWljcm9zb2Z0 KSBiZWxpZXZlIGFsbCBzaG91bGQgYmUgYWRkcmVzc2VkIGF0IHRoZSBzYW1lIHRpbWUgYW5kIHdp bGwgcG9zdHBvbmUgVExTIDEuMyBzdXBwb3J0IHVudGlsIHN1Y2ggYSB0aW1lIGFzIHdlIGFyZSBh YmxlIHRvIG1ha2UgdGhlIHVwZGF0ZXMgdG9nZXRoZXIuPGJyPg0KPGJyPg0KJmd0Oyogc2hvdWxk IHRoZSBkb2N1bWVudCBkcm9wIHJlZmVyZW5jZXMgdG8gVEVBUD88YnI+DQomZ3Q7IEdpdmVuIEpv dW5pIE1hbGluZW4ncyBjb21tZW50cyBvbiBpbXBsZW1lbnRpbmcgVEVBUCwgaXQgbWF5IGJlIHdv cnRoIHNpbXBseSBub3RpbmcgdGhhdCB3ZSdyZSB3YWl0aW5nIGZvciBhIFRFQVAgdXBkYXRlIGRv Y3VtZW50PGJyPg0KPGJyPg0KSSd2ZSByZXZpZXdlZCB0aGUgY3VycmVudCBlcnJhdGEsIGFuZCBh Y2tub3dsZWRnZSB0aGVpciB2YWxpZGl0eSwgYnV0IGFtIG5vdCBzdXJlIHRoYXQgYW55IG9mIHRo ZW0gd291bGQgaW1wYWN0IHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhlIG1vc3QgcmVsZXZh bnQgZXJyYXRhIHRvIHRoaXMgZG9jdW1lbnQgc2VlbXMgdG8gYmUgPGEgaHJlZj0iaHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LnJmYy1lZGl0b3Iub3JnJTJGZXJyYXRhJTJGZWlkNTc3MCZhbXA7ZGF0YT0wMiU3QzAxJTdD am92ZXJnYXIlNDBtaWNyb3NvZnQuY29tJTdDNWQ4NDkzZTlhNjY1NDkzNTVjNjUwOGQ3ZTE1OTlj NWYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjI1NjQ3 MzQxNDU1Mjk3JmFtcDtzZGF0YT1WV0lKVFZyWUxQV21nNkpPUHJXYml3dFVKR0hrdGFGb3hHdXNx bGRMSHJnJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5y ZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTc3MDwvYT4uIEFzIG5vdGVkIGluIHRoZSBlcnJhdGEs IHRoZSBjYWxjdWxhdGlvbiBvZiBrZXlzIGJlY29tZXMgY29uZnVzaW5nIHdoZW4gbWV0aG9kcyBl eHBvcnQgYm90aCBNU0sgYW5kIEVNU0sgYmVjYXVzZSBpdCBpcyBub3QgY2xlYXJseSBzcGVjaWZp ZWQgd2hpY2ggdmFsdWUgSU1DS1tqXSBzaG91bGQgdGFrZSBvbiBkdXJpbmcgdGhlIGNhbGN1bGF0 aW9uIG9mIFMtSU1DS1tqXS4NCiBUaGUgYWRkaXRpb24gb2YgY2xhcmlmeWluZyBpbmZvcm1hdGlv biBpcyB3ZWxjb21lLCBidXQgSSBkb24ndCBiZWxpZXZlIHRoaXMgYW1iaWd1aXR5IGN1cnJlbnRs eSBwcmV2ZW50cyBhIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiAtIGZvciBleGFtcGxlLCBhbiBp bXBsZW1lbnRhdGlvbiBjb3VsZCBhdm9pZCB0aGlzIGFtYmlndWl0eSBieSBjaG9vc2luZyB0byB1 c2UgZWl0aGVyIHRoZSBNU0svRU1TSyBleGNsdXNpdmVseSwgYW5kIGNvbW11bmljYXRpbmcNCiB0 aGF0IHRvIHRoZSBzZXJ2ZXIgdmlhIHRoZSBDb21wb3VuZCBNQUMgVExWLiBUaGUgc2VydmVyIGNh biB0aGVuIG1ha2UgYSBwb2xpY3kgZGVjaXNpb24gb24gd2hldGhlciBpdCBpcyBhY2NlcHRpbmcg b2YgdGhpcyBkZWNpc2lvbiBieSB0aGUgY2xpZW50IGFuZCBmb2xsb3cgc3VpdCwgb3IgcmVqZWN0 IHRoZSBjbGllbnQuPGJyPg0KPGJyPg0KVGhlIHNwZWNpZmljcyBvZiByZXNvbHZpbmcgdGhpcyBw YXJ0aWN1bGFyIGVycmF0YSBpcyBhIGRpZ3Jlc3Npb24gZnJvbSBteSBtYWluIHBvaW50IC0gSSBi ZWxpZXZlIGEgY2xhcmlmaWNhdGlvbiBjYW4gYmUgYWRkZWQgdG8gdGhlIG1haW4gVEVBUCBkb2N1 bWVudCBhdCBhIGZ1dHVyZSB0aW1lIHdpdGhvdXQgaW1wYWN0aW5nIHRoZSBjb250ZW50cyBvZiB0 aGlzIGRvY3VtZW50LiBBbWJpZ3VpdHkgYWJvdXQgd2hpY2ggSU1DSyB0byB1c2UgaW4gUy1JTUNL DQogY2FsY3VsYXRpb24gc2hvdWxkIG5vdCBpbXBhY3QgdGhlIGRlZmluaXRpb24gb2YgdGhlIGNy eXB0b2dyYXBoaWMgY2FsY3VsYXRpb25zLjxicj4NCjxicj4NCk9uIHRoZSBkb2N1bWVudCBjb250 ZW50cyB0aGVtc2VsdmVzLCBJIGhhdmUgdGhpcyByZXZpZXc6IFRoZSBrZXkgZGVyaXZhdGlvbiBw cm9wb3NlZCBmb3IgVEVBUC9GQVNUIHVzZXMgdGhlIGRlZmluaXRpb24gZnJvbSBGQVNULCB3aGlj aCBpcyBub3QgaWRlbnRpY2FsIHRvIHRoZSBURUFQIGRlcml2YXRpb24uIE5hbWVseSwgRkFTVCB1 c2VkIE1TS1tqXSBpbiB0aGUgZGVyaXZhdGlvbiwgYnV0IFRFQVAgdXNlcyBJTVNLW2pdLCB3aGlj aCBtYXkgYmUNCiBlcXVpdmFsZW50IGluIHNvbWUgY2FzZXMsIGJ1dCBtYXkgbm90IGluIG90aGVy cyB3aGVyZSB0aGUgaW5uZXIgbWV0aG9kIGV4cG9ydHMgYW4gRU1TSy48YnI+DQo8YnI+DQpTcGVj aWZpY2FsbHksIEkgYmVsaWV2ZSB0aGlzIGxpbmUgb2Ygc2VjdGlvbiAyLjIgc2hvdWxkIGNoYW5n ZSBmcm9tPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJTUNLW2pdID0g VExTLUV4cG9ydGVyKCZxdW90O0VYUE9SVEVSOiBJbm5lciBNZXRob2RzIENvbXBvdW5kIEtleXMm cXVvdDssIFMtSU1DS1tqLTFdIHwgTVNLW2pdLCA2MCk8YnI+DQpUbzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSU1DS1tqXSA9IFRMUy1FeHBvcnRlcigmcXVvdDtFWFBP UlRFUjogSW5uZXIgTWV0aG9kcyBDb21wb3VuZCBLZXlzJnF1b3Q7LCBTLUlNQ0tbai0xXSB8IElN U0tbal0sIDYwKTxicj4NCkZvciBURUFQLjxicj4NCjxicj4NCkpvcmdlPGJyPg0KPGJyPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBFbXUgJmx0OzxhIGhyZWY9Im1haWx0 bzplbXUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmVtdS1ib3VuY2VzQGlldGYu b3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIEFsYW4gRGVLb2s8YnI+DQpTZW50OiBGcmlkYXksIEFw cmlsIDMsIDIwMjAgMTo0OCBQTTxicj4NClRvOiBFTVUgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpl bXVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5lbXVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1 YmplY3Q6IFtFbXVdIGRyYWZ0LWRla29rLWVtdS10bHMtZWFwLXR5cGVzIGRpc2N1c3Npb248YnI+ DQo8YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1k ZWtvay1lbXUtdGxzLWVhcC10eXBlcy0wMSZhbXA7ZGF0YT0wMiU3QzAxJTdDam92ZXJnYXIlNDBt aWNyb3NvZnQuY29tJTdDNWQ4NDkzZTlhNjY1NDkzNTVjNjUwOGQ3ZTE1OTljNWYlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjI1NjQ3MzQxNDU1Mjk3JmFt cDtzZGF0YT1oJTJGOFo2d2NtR1FCWXlBYnU2VHRZTThURGw2VnVoenpOM1Y5dzRyeGNBVG8lM0Qm YW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZkcmFmdC1kZWtvay1lbXUtdGxzLWVhcC10eXBlcy0wMSZhbXA7YW1wO2RhdGE9MDIl N0MwMSU3Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3QzJjNDIwOTVlZGM0ZTRjZDYxY2U0MDhk N2Q4MTA2MjAwJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz NzIxNTQzNzE4ODc0NDcxMSZhbXA7YW1wO3NkYXRhPW5kTHAlMkZTenNEbFglMkZLWXgwVVIwdWY3 N3JIZ0NqR2VqNGtkWlBweXd1RDlRJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+DQo8YnI+ DQombmJzcDsgSSBoYXZlbid0IHNlZW4gbXVjaCBkaXNjdXNzaW9uIG9uIHRoZSBkb2N1bWVudC4m bmJzcDsgVGhlcmUgYXJlIHN0aWxsIHNvbWUgb3BlbiBxdWVzdGlvbnM6PGJyPg0KPGJyPg0KKiBz aG91bGQgaXQgYmUgcHVibGlzaGVkIHNpbXVsdGFuZW91c2x5IHdpdGggZHJhZnQtaWV0Zi1lbXUt ZWFwLXRsczEzPzxicj4NCiZuYnNwOyAmbmJzcDtJZiBzbywgd2UgbmVlZCBzb21lIGNvbnNlbnN1 cyBvbiB0aGlzIGRvY3VtZW50LCBhbmQgcXVpY2suPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0lm IG5vdCwgd2hlbiBkbyB3ZSBwdWJsaXNoIHRoaXMgZHJhZnQ/Jm5ic3A7IE1pY3Jvc29mdCBoYXMg YWxyZWFkeSBzYWlkIHRoYXQgdGhleSB3b24ndCByZXYgdGhlaXIgRUFQLVRMUyBpbXBsZW1lbnRh dGlvbiB1bnRpbCB0aGV5IGNhbiBhbHNvIHJldiBQRUFQLjxicj4NCjxicj4NCiogU2hvdWxkIHRo ZSBkb2N1bWVudCBzaW1wbHkgZHJvcCByZWZlcmVuY2VzIHRvIEZBU1Q/PGJyPg0KJm5ic3A7IEl0 IGxvb2tzIGxpa2UgdGhlIGVmZm9ydCBoYXMgbW92ZWQgdG8gVEVBUC48YnI+DQombmJzcDsgUGVy aGFwcyB3ZSBzaG91bGQgbm90ZSB0aGF0IEZBU1QgY2Fubm90IGJlIHVzZWQgd2l0aCBUTFMgMS4z LCBhbmQgdGhhdCBURUFQIHNob3VsZCBiZSB1c2VkIGluc3RlYWQ8YnI+DQo8YnI+DQoqIHNob3Vs ZCB0aGUgZG9jdW1lbnQgZHJvcCByZWZlcmVuY2VzIHRvIFRFQVA/PGJyPg0KJm5ic3A7R2l2ZW4g Sm91bmkgTWFsaW5lbidzIGNvbW1lbnRzIG9uIGltcGxlbWVudGluZyBURUFQLCBpdCBtYXkgYmUg d29ydGggc2ltcGx5IG5vdGluZyB0aGF0IHdlJ3JlIHdhaXRpbmcgZm9yIGEgVEVBUCB1cGRhdGUg ZG9jdW1lbnQ8YnI+DQo8YnI+DQoqIFdpdGhvdXQgRkFTVCAvIFRFQVAsIHRoZSBkb2N1bWVudCBp cyBhYm91dCA0IHBhZ2VzIG9mIHRleHQuJm5ic3A7IElzIHRoZXJlIGFueXRoaW5nIGNvbnRyb3Zl cnNpYWwsIG1pc3NpbmcsIGV0Yz88YnI+DQo8YnI+DQoqIFdoYXQgYXJlIHRoZSBiYXJyaWVycyB0 byBhZG9wdGlvbiBhbmQgcHVibGljYXRpb24/PGJyPg0KPGJyPg0KJm5ic3A7IEFsYW4gRGVLb2su PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpFbXUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkVtdUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPkVtdUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZlbXUmYW1wO2RhdGE9MDIlN0Mw MSU3Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3QzVkODQ5M2U5YTY2NTQ5MzU1YzY1MDhkN2Ux NTk5YzVmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIy NTY0NzM0MTQ2NTI5MiZhbXA7c2RhdGE9VE1NWklaT1Q4VDhkdE5uOG53MWg5elBFak9sUlF1V0Zy V3RUa1B4dFZPNCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmVtdSZhbXA7YW1wO2RhdGE9MDIlN0Mw MSU3Q2pvdmVyZ2FyJTQwbWljcm9zb2Z0LmNvbSU3QzJjNDIwOTVlZGM0ZTRjZDYxY2U0MDhkN2Q4 MTA2MjAwJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIx NTQzNzE4ODc0NDcxMSZhbXA7YW1wO3NkYXRhPWxrb0h6ZDBmZ040ejFvYWxxVjJqVzlwZXdVR1Nu bFJMZUtwaUZldzRZdzglM0QmYW1wO2FtcDtyZXNlcnZlZD0wPC9hPjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRW11IG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpFbXVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5FbXVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGZW11JmFtcDtkYXRhPTAyJTdDMDElN0Nqb3ZlcmdhciU0MG1p Y3Jvc29mdC5jb20lN0M1ZDg0OTNlOWE2NjU0OTM1NWM2NTA4ZDdlMTU5OWM1ZiU3QzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyMjU2NDczNDE0NzUyODYmYW1w O3NkYXRhPWs5SEZYMkZkRnc5UjJ4VVZISEhWaGxXajl1eG1ZZFdveXFFdyUyQlhBWmNsYyUzRCZh bXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZW11PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CH2PR21MB138182A1A04935CD39C1C07CD1DB0CH2PR21MB1381namp_-- From nobody Wed Apr 15 12:33:21 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B613A0867 for ; Wed, 15 Apr 2020 12:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AOSns6cZ-Kpw for ; Wed, 15 Apr 2020 12:33:17 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 BF1DE3A0863 for ; Wed, 15 Apr 2020 12:32:54 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id j26so1082319ots.0 for ; Wed, 15 Apr 2020 12:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G2UfuFVCVwCDQqSHmxjHICfHEt+XfggyZHSH5JVUttE=; b=jXuJEGiHid1TPpYQP6heBLzZZrwlboBoQp4K/Escxx254pJ0y8pl6uOA/fCIRIThss Z2opp05GDsolpteVZRmHSZGrSMDQOucCkMjUUQudcyWIOTO2CESwk4H0ryIuENfhNmFm DOQhMczt7cA4a5Wd/6fbyP+wf+xenaEkJ4nEUsXCxzPpDWhoJsioUJYwrrGQQlrq8Uew pd3aBlIWFCJK5I7cG6Y/rT+yxoedBLnHY70N23fdrVIuScCvFIU/Y2NSB2mqsGKfVAhb iO5LvCbTSFY9kN5xNOLiJSO6oQXreeTtfUgX5Hxq1aje+kLDNH4QNXxwMDS0GHm3QfBH blJw== 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=G2UfuFVCVwCDQqSHmxjHICfHEt+XfggyZHSH5JVUttE=; b=EhQlmSbJPau31U4B5caqpPfd/cHg5OA/MtJLseBZ93tSfGA1HvBo0+AKO+2tHhzaAK sPAhddEcNVuRr+2i4qRbXPQTsEdJizvEZjczb6JzDsz1T7sGYR/Wa/pZDifHgBb20Eh0 oHISb8I/CqDsz7gqPaA2ZziaO1ZcBKw7BmyhGoe2gIHA4qRLI2q+CDzmIAcqtG/Zjn0m AS79vlgaaTc2zdFAk4cc58k1M2AsALy7plqqwrqp4kKNmjOD3zsNJMem1/LjcYSazFhu Lj3yiqmxLdHvCQ42n/Cn11GiYRucX2o7dWnuuk3MG14KAf3akA0+AQyq2jS+bY5KyNVu usvw== X-Gm-Message-State: AGi0PuZ3QKDsX2A9HV2kFtftYZCXZgRV+XBYD7/tyRCHBl7XGrx9GZwt fCUPh7mx89nKnFnVi7mof+aX8JH2h1Pykdfyyyg= X-Google-Smtp-Source: APiQypIPU9QzRiR2YNU9JRpyF3Qezftk3WZztfI+xfJ/Ayt6NyaOt6/I2sGfbqoz73f8hTa78Lkrr2R3ZA0UquMrxA8= X-Received: by 2002:a05:6830:15a:: with SMTP id j26mr24419141otp.248.1586979173920; Wed, 15 Apr 2020 12:32:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Oleg Pekar Date: Wed, 15 Apr 2020 22:32:42 +0300 Message-ID: To: Jorge Vergara Cc: Jorge Vergara , EMU WG Content-Type: multipart/alternative; boundary="000000000000ed73bf05a359619e" Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 15 Apr 2020 19:33:20 -0000 --000000000000ed73bf05a359619e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >>Could this method work? Should we make it more clearly specified? Or should we change the protocol to arrive explicitly to the understanding which type (MSK/EMSK) of IMSK[j] to use? >You clarification is what I understood the intention of the RFC to be as well, and makes sense to me. I don=E2=80=99t think there needs to be a prot= ocol update if this clarification sounds good to all parties. I would welcome Jouni=E2=80=99s thoughts as the filer of the errata. Good! Then we can leave the protocol unchanged but re-write the relevant sections 5.2, 5.3 and maybe 5.4 to define clearly the algorithm. Right, it would be great to hear from Jouni whether this will satisfy the Errata 5770. Oleg On Wed, Apr 15, 2020 at 9:31 PM Jorge Vergara wrote: > > For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you plannin= g > to find the common method of TLS 1.3 support for all three or you just wa= nt > to release TLS 1.3 support at the same time for all three? > > > > It=E2=80=99s not our intention to try to force the same solution for ever= y method. > We plan to update our implementations at the same time, since we anticipa= te > the updates will be similar (though not necessarily identical). > > > > >Could this method work? Should we make it more clearly specified? Or > should we change the protocol to arrive explicitly to the understanding > which type (MSK/EMSK) of IMSK[j] to use? > > > > You clarification is what I understood the intention of the RFC to be as > well, and makes sense to me. I don=E2=80=99t think there needs to be a pr= otocol > update if this clarification sounds good to all parties. I would welcome > Jouni=E2=80=99s thoughts as the filer of the errata. > > > > Jorge > > > > *From:* Emu *On Behalf Of * Oleg Pekar > *Sent:* Wednesday, April 15, 2020 9:25 AM > *To:* Jorge Vergara > *Cc:* EMU WG > *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > > > Hi Jorge, > > For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning > to find the common method of TLS 1.3 support for all three or you just wa= nt > to release TLS 1.3 support at the same time for all three? > > > > For TEAP errata 5770: > > Technically TEAP RFC suggests the implicit method of taking the correct > IMSK[j] and all the subsequent keys after each inner method via negotiati= on > taking place in Crypto-Binding TLV exchange. > > > > Let's say we are on the inner method number j that supports both MSK and > EMSK and we are server which implementation generates both MSK and EMSK f= or > this inner method. We generated keys according to the rules below - two > sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to > inner method MSK. Because we don't know whether client implementation > supports both MSK and EMSK. > > > > S-IMCK[0] =3D session_key_seed > > For j =3D 1 to n-1 do > > IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys"= , > > IMSK[j], 60) > > S-IMCK[j] =3D first 40 octets of IMCK[j] > > CMK[j] =3D last 20 octets of IMCK[j] > > > > So we have two CMK[j] and we create Crypto-Binding TLV with both Compound > MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and > we can understand from it whether it supports EMSK for this inner method = or > not. And here we can decide which version of IMCK[j] to take for this inn= er > method - derived from EMSK or MSK. This is just not explicitly specified = in > the RFC. > > > > Could this method work? Should we make it more clearly specified? Or > should we change the protocol to arrive explicitly to the understanding > which type (MSK/EMSK) of IMSK[j] to use? > > > > Thanks > > Oleg > > > > > > On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara 40microsoft.com@dmarc.ietf.org> wrote: > > >Microsoft has already said that they won't rev their EAP-TLS > implementation until they can also rev PEAP. > > PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the > same time and will postpone TLS 1.3 support until such a time as we are > able to make the updates together. > > >* should the document drop references to TEAP? > > Given Jouni Malinen's comments on implementing TEAP, it may be worth > simply noting that we're waiting for a TEAP update document > > I've reviewed the current errata, and acknowledge their validity, but am > not sure that any of them would impact this document. > > The most relevant errata to this document seems to be > https://www.rfc-editor.org/errata/eid5770 > . > As noted in the errata, the calculation of keys becomes confusing when > methods export both MSK and EMSK because it is not clearly specified whic= h > value IMCK[j] should take on during the calculation of S-IMCK[j]. The > addition of clarifying information is welcome, but I don't believe this > ambiguity currently prevents a compliant implementation - for example, an > implementation could avoid this ambiguity by choosing to use either the > MSK/EMSK exclusively, and communicating that to the server via the Compou= nd > MAC TLV. The server can then make a policy decision on whether it is > accepting of this decision by the client and follow suit, or reject the > client. > > The specifics of resolving this particular errata is a digression from my > main point - I believe a clarification can be added to the main TEAP > document at a future time without impacting the contents of this document= . > Ambiguity about which IMCK to use in S-IMCK calculation should not impact > the definition of the cryptographic calculations. > > On the document contents themselves, I have this review: The key > derivation proposed for TEAP/FAST uses the definition from FAST, which is > not identical to the TEAP derivation. Namely, FAST used MSK[j] in the > derivation, but TEAP uses IMSK[j], which may be equivalent in some cases, > but may not in others where the inner method exports an EMSK. > > Specifically, I believe this line of section 2.2 should change from > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound Keys= ", > S-IMCK[j-1] | MSK[j], 60) > To > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound Keys= ", > S-IMCK[j-1] | IMSK[j], 60) > For TEAP. > > Jorge > > -----Original Message----- > From: Emu On Behalf Of Alan DeKok > Sent: Friday, April 3, 2020 1:48 PM > To: EMU WG > Subject: [Emu] draft-dekok-emu-tls-eap-types discussion > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01&data=3D02%7C01%7Cjo= vergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141a= f91ab2d7cd011db47%7C1%7C0%7C637215437188744711&sdata=3DndLp%2FSzsDlX%2F= KYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3D&reserved=3D0 > > > I haven't seen much discussion on the document. There are still some > open questions: > > * should it be published simultaneously with draft-ietf-emu-eap-tls13? > If so, we need some consensus on this document, and quick. > > If not, when do we publish this draft? Microsoft has already said tha= t > they won't rev their EAP-TLS implementation until they can also rev PEAP. > > * Should the document simply drop references to FAST? > It looks like the effort has moved to TEAP. > Perhaps we should note that FAST cannot be used with TLS 1.3, and that > TEAP should be used instead > > * should the document drop references to TEAP? > Given Jouni Malinen's comments on implementing TEAP, it may be worth > simply noting that we're waiting for a TEAP update document > > * Without FAST / TEAP, the document is about 4 pages of text. Is there > anything controversial, missing, etc? > > * What are the barriers to adoption and publication? > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Femu&data=3D02%7C01%7Cjovergar%40microsof= t.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C637215437188744711&sdata=3DlkoHzd0fgN4z1oalqV2jW9pewUGSnlRLe= KpiFew4Yw8%3D&reserved=3D0 > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > > > --000000000000ed73bf05a359619e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>= >Could this method=C2=A0work? Should we make it more clearly specified? = Or should we change the protocol to arrive explicitly to the understanding = which type (MSK/EMSK) of IMSK[j] to use?

<= p class=3D"MsoNormal">=C2=A0

>You clarification is what I understood the intention of the RFC to be = as well, and makes sense to me. I don=E2=80=99t think there needs to be a p= rotocol update if this clarification sounds good to all parties. I would we= lcome Jouni=E2=80=99s thoughts as the filer of the errata.


Good! Then we can leave the protoc= ol unchanged but re-write the relevant=C2=A0sections 5.2, 5.3 and maybe 5.4= to define=C2=A0clearly the algorithm. Right, it would be great to hear fr= om Jouni whether this will satisfy the Errata 5770.


Oleg


On Wed, Apr 15, 2020 at 9:31 PM J= orge Vergara <jovergar@microso= ft.com> wrote:

> For Microsoft supported protocol suite=C2=A0PEA= P/TTLS/TEAP - are you planning to find the common method of TLS 1.3 support= for all three or you just want to release TLS 1.3 support at the same time= for all three?

=C2=A0

It=E2=80=99s not our intention to try to force the s= ame solution for every method. We plan to update our implementations at the= same time, since we anticipate the updates will be similar (though not nec= essarily identical).

=C2=A0

>Could this method=C2=A0work? Should we make it m= ore clearly specified? Or should we change the protocol to arrive explicitl= y to the understanding which type (MSK/EMSK) of IMSK[j] to use?

=C2=A0

You clarification is what I understood the intention= of the RFC to be as well, and makes sense to me. I don=E2=80=99t think the= re needs to be a protocol update if this clarification sounds good to all p= arties. I would welcome Jouni=E2=80=99s thoughts as the filer of the errata.

=C2=A0

Jorge

=C2=A0

From: Emu <emu-bounces@ietf.org> On Behalf Of Oleg Pekar
Sent: Wednesday, April 15, 2020 9:25 AM
To: Jorge Vergara <jovergar=3D40microsoft.com@dmarc.ietf.org>
Cc: EMU WG <emu= @ietf.org>
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

=C2=A0

Hi Jorge,

For Microsoft supported protocol suite=C2=A0PEAP/TTL= S/TEAP - are you planning to find the common method of TLS 1.3 support for = all three or you just want to release TLS 1.3 support at the same time for = all three?

=C2=A0

For TEAP errata 5770:=C2=A0

Technically TEAP RFC suggests the implicit method of= taking the correct IMSK[j] and all the subsequent keys after each inner me= thod via negotiation taking place in Crypto-Binding=C2=A0TLV exchange.=C2= =A0

=C2=A0

Let's say we are on the inner method number j th= at supports both MSK and EMSK and we are server=C2=A0which implementation g= enerates both MSK and EMSK for this inner method. We generated keys accordi= ng to the rules below - two sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to inner method MSK. = Because we don't know whether client implementation supports both MSK a= nd EMSK.=C2=A0

=C2=A0

S-IMCK[0] =3D =
session_key_seed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For j =3D 1=
 to n-1 do
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Com=
pound Keys",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IMSK[j], 60)=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 S-IMCK[j] =3D first 40 octets of IMCK[j]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 CMK[j] =3D last 20 octets of IMCK[j]

=C2=A0

So we have two CMK[j] and we create Crypto-Binding T= LV with both Compound MAC for MSK and EMSK. The client sends Crypto-Binding= TLV in response and we can understand from it whether it supports EMSK for= this inner method or not. And here we can decide which version of IMCK[j] to take for this inner method - der= ived from EMSK or MSK. This is just not explicitly specified in the RFC.=C2= =A0

=C2=A0

Could this method=C2=A0work? Should we make it more = clearly specified? Or should we change the protocol to arrive explicitly to= the understanding which type (MSK/EMSK) of IMSK[j] to use?

=C2=A0

Thanks

Oleg

=C2=A0

=C2=A0

On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara <jo= vergar=3D40microsoft.com@dmarc.ietf.org> wrote:

>Microsoft has already said that they won't r= ev their EAP-TLS implementation until they can also rev PEAP.

PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same= time and will postpone TLS 1.3 support until such a time as we are able to= make the updates together.

>* should the document drop references to TEAP?
> Given Jouni Malinen's comments on implementing TEAP, it may be wor= th simply noting that we're waiting for a TEAP update document

I've reviewed the current errata, and acknowledge their validity, but a= m not sure that any of them would impact this document.

The most relevant errata to this document seems to be https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the = calculation of keys becomes confusing when methods export both MSK and EMSK= because it is not clearly specified which value IMCK[j] should take on dur= ing the calculation of S-IMCK[j]. The addition of clarifying information is welcome, but I don't believe= this ambiguity currently prevents a compliant implementation - for example= , an implementation could avoid this ambiguity by choosing to use either th= e MSK/EMSK exclusively, and communicating that to the server via the Compound MAC TLV. The server can then make a po= licy decision on whether it is accepting of this decision by the client and= follow suit, or reject the client.

The specifics of resolving this particular errata is a digression from my m= ain point - I believe a clarification can be added to the main TEAP documen= t at a future time without impacting the contents of this document. Ambigui= ty about which IMCK to use in S-IMCK calculation should not impact the definition of the cryptographic calculat= ions.

On the document contents themselves, I have this review: The key derivation= proposed for TEAP/FAST uses the definition from FAST, which is not identic= al to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but = TEAP uses IMSK[j], which may be equivalent in some cases, but may not in others where the inner method exp= orts an EMSK.

Specifically, I believe this line of section 2.2 should change from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-Exporter("EXPORTER:= Inner Methods Compound Keys", S-IMCK[j-1] | MSK[j], 60)
To
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-Exporter("EXPORTER:= Inner Methods Compound Keys", S-IMCK[j-1] | IMSK[j], 60)
For TEAP.

Jorge

-----Original Message-----
From: Emu <emu= -bounces@ietf.org> On Behalf Of Alan DeKok
Sent: Friday, April 3, 2020 1:48 PM
To: EMU WG <emu@ietf.o= rg>
Subject: [Emu] draft-dekok-emu-tls-eap-types discussion

https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftool= s.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01&amp;data=3D02%7C01= %7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86= f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711&amp;sdata=3DndLp%2F= SzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3D&amp;reserved=3D0

=C2=A0 I haven't seen much discussion on the document.=C2=A0 There are = still some open questions:

* should it be published simultaneously with draft-ietf-emu-eap-tls13?
=C2=A0 =C2=A0If so, we need some consensus on this document, and quick.

=C2=A0 =C2=A0If not, when do we publish this draft?=C2=A0 Microsoft has alr= eady said that they won't rev their EAP-TLS implementation until they c= an also rev PEAP.

* Should the document simply drop references to FAST?
=C2=A0 It looks like the effort has moved to TEAP.
=C2=A0 Perhaps we should note that FAST cannot be used with TLS 1.3, and th= at TEAP should be used instead

* should the document drop references to TEAP?
=C2=A0Given Jouni Malinen's comments on implementing TEAP, it may be wo= rth simply noting that we're waiting for a TEAP update document

* Without FAST / TEAP, the document is about 4 pages of text.=C2=A0 Is ther= e anything controversial, missing, etc?

* What are the barriers to adoption and publication?

=C2=A0 Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://nam06.sa= felinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%= 2Flistinfo%2Femu&amp;data=3D02%7C01%7Cjovergar%40microsoft.com%7C2c4209= 5edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637= 215437188744711&amp;sdata=3DlkoHzd0fgN4z1oalqV2jW9pewUGSnlRLeKpiFew4Yw8= %3D&amp;reserved=3D0

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

--000000000000ed73bf05a359619e-- From nobody Thu Apr 16 03:25:57 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786973A0915 for ; Thu, 16 Apr 2020 03:25:55 -0700 (PDT) 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 bGIW0OmhqXJz for ; Thu, 16 Apr 2020 03:25:53 -0700 (PDT) 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 601FF3A08A5 for ; Thu, 16 Apr 2020 03:25:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by li674-96.members.linode.com (Postfix) with ESMTP id 08F6B11D68; Thu, 16 Apr 2020 10:25:51 +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 xfvo4EvmUTnP; Thu, 16 Apr 2020 10:25:49 +0000 (UTC) Received: by jm (sSMTP sendmail emulation); Thu, 16 Apr 2020 13:24:45 +0300 Date: Thu, 16 Apr 2020 13:24:45 +0300 From: Jouni Malinen To: Oleg Pekar Cc: Jorge Vergara , EMU WG Message-ID: <20200416102445.GA8757@w1.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 16 Apr 2020 10:25:56 -0000 On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: > For TEAP errata 5770: > Technically TEAP RFC suggests the implicit method of taking the correct > IMSK[j] and all the subsequent keys after each inner method via negotiation > taking place in Crypto-Binding TLV exchange. What is "the correct IMSK[j]" and where is this defined? > Let's say we are on the inner method number j that supports both MSK and > EMSK and we are server which implementation generates both MSK and EMSK for > this inner method. We generated keys according to the rules below - two > sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to > inner method MSK. Because we don't know whether client implementation > supports both MSK and EMSK. > > S-IMCK[0] = session_key_seed > For j = 1 to n-1 do > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", > IMSK[j], 60) > S-IMCK[j] = first 40 octets of IMCK[j] > CMK[j] = last 20 octets of IMCK[j] > > > So we have two CMK[j] and we create Crypto-Binding TLV with both Compound > MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and > we can understand from it whether it supports EMSK for this inner method or > not. And here we can decide which version of IMCK[j] to take for this inner > method - derived from EMSK or MSK. This is just not explicitly specified in > the RFC. Is this the proposed definition of "the correct IMSK[J]"? In other words, is this to be understood to have two (or three since we have the no MSK/EMSK case as well) variants of IMSK[j] during an execution of an internal AP authentication method and a single one of those variants is selected as _the correct_ IMSK[j] at the successful conclusion of this inner authentication method? Would this single "correct IMSK[j]" then be used for deriving the different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having all following inner authentication rounds and MSK/EMSK derivation to behave as if the other variants of IMSK[j] never really existed? > Could this method work? Should we make it more clearly specified? Or should > we change the protocol to arrive explicitly to the understanding which type > (MSK/EMSK) of IMSK[j] to use? Regardless of what is done for the design, it will absolutely need to be specified more clearly. If I understood the proposed design correctly, this should be defined with something like following: For each successful inner EAP authentication method, derive IMCK-MSK[j] (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was derived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if available). Generate Crypto-Binding TLV with all available Compound MAC values. Also verify Crypto-Binding TLV with all available Compound MAC values. After both ends have transmitted and received Crypto-Binding TLV, set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but either end did not include EMSK Compound MAC, or . Set S-IMCK[j] based on this IMSK[j]. This results in there being only a single S-IMCK[j] and MSK/EMSK derivation being well defined. And focusing on that "what to do here.." part and the unused IMCK-zero[j] in the previous paragraph.. How is this supposed to work when an inner EAP authentication method does not derive either MSK or EMSK? Intermediate result indication of success needs to be done and that implies there needs to be Crypto-Binding TLV. But that TLV does not have option of indicating that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 defined to do so). So what are those fields (or one of them) supposed to be set to? And how is that selected for an inner EAP authentication method j? Does this depends on what happened with method j-1 (if one was present)? How would the correct IMCK[j] be determined by the peer and the server if one of them derived MSK/EMSK but the other one did not derive either for inner EAP method j? -- Jouni Malinen PGP id EFC895FA From nobody Thu Apr 16 10:38:51 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B453A0898 for ; Thu, 16 Apr 2020 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=openfortress.nl 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 pzG2-4mhi7I9 for ; Thu, 16 Apr 2020 10:38:44 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 90D9C3A0891 for ; Thu, 16 Apr 2020 10:38:44 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id P8THj2dwxlKa1P8TIjV6Lj; Thu, 16 Apr 2020 19:38:42 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587058719; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=Pn/QXscMBwshxN2WnGSTDAXreNcG1Ul99EEM61Ma990=; b=G8HgJuUhbKUnADuxekobRn9B2U/DRnpjM96fMEgaTAwMdd6Mx/b1dZer iK32gDYbLkILFBIZOc9r57V0pdeQ0xCSyvNJx6Hp06kH4iwNL3k052L719 2CF+ciEKmn7W8RMi5+Z7rJsz/AGn9RHnB4sCMvYa/a2gfGKT0Cl+YY8fs= Received: by fame.vanrein.org (Postfix, from userid 1006) id A892B37B05; Thu, 16 Apr 2020 17:38:39 +0000 (UTC) X-Original-To: emu@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 6990A143; Thu, 16 Apr 2020 17:38:36 +0000 (UTC) Message-ID: <5E98981B.7020606@openfortress.nl> Date: Thu, 16 Apr 2020 19:38:35 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: emu@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfGGqy9jfPrLCbqZbnwN5EP7ciqaOekVgZyemW4viYz+3Xe9UQueExbuDiDxggw872DCbTwSUvGP7yYo//6BHSu31gIaOqTkdKpqOxVBEOYg9bn1MsUur tgoszLLPSZ/QPaHf0uTx+d3TmDChJAwteebKz2n1kXSMac+yzCorTJckRudQPNyv3h/7dBkfvtw6NQ== Archived-At: Subject: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:38:50 -0000 Hello, I think SASL over EAP would be useful. Would it be in scope for EMU? SASL is normally used for applications, while EAP authenticates networks. However, with VPNs these uses get mixed. We're making a few other changes to SASL that line up with this: - Diameter embedding of SASL tokens - A SASL mech "SXOVER" to support authentication of foreign realms An interesting usecase for EAP-SASL with all this would be WiFi and LAN authentication (EAPOL or 802.1x) passed over Diameter to *any* domain on the Internet, and receiving back tunnel information. Clients would be tunneled to their own network/IP/routing and it would be easier for public access providers to offer full networking without worry about the behaviour it outputs over their IP range. This may in fact be a path for your purpose of out-of-band based authentication; SASL mechanisms could use such extensions too and SXOVER might help to protect the general mechanism. Before this group existed I wrote a spec for EAP-SASL, is it worthwhile to continue, and how/what do you advise? https://www.ietf.org/archive/id/draft-vanrein-eap-sasl-00.txt The other work is progressing in https://tools.ietf.org/html/draft-vanrein-diameter-sasl-03 Looking forward to the EMU opinions, Kind regards, Rick van Rein InternetWide.org From nobody Fri Apr 17 15:46:51 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1123A08FD for ; Fri, 17 Apr 2020 15:46:48 -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 5UvDoE-Rm97D for ; Fri, 17 Apr 2020 15:46:45 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE913A08F0 for ; Fri, 17 Apr 2020 15:46:44 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 260DF3AC; Fri, 17 Apr 2020 22:46:41 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Alan DeKok In-Reply-To: <5E98981B.7020606@openfortress.nl> Date: Fri, 17 Apr 2020 18:46:40 -0400 Cc: emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> References: <5E98981B.7020606@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 22:46:49 -0000 On Apr 16, 2020, at 1:38 PM, Rick van Rein wrote: > I think SASL over EAP would be useful. Would it be in scope for EMU? I can't say if it's in scope. But I don't think there's any other = place this would would get done. So it's a "maybe". > SASL is normally used for applications, while EAP authenticates > networks. However, with VPNs these uses get mixed. Agreed. > We're making a few other changes to SASL that line up with this: > - Diameter embedding of SASL tokens > - A SASL mech "SXOVER" to support authentication of foreign realms Interesting! > An interesting usecase for EAP-SASL with all this would be WiFi and = LAN > authentication (EAPOL or 802.1x) passed over Diameter to *any* domain = on > the Internet, and receiving back tunnel information. Or RADIUS.... TBH, I can't recall seeing many WiFi deployments which use Diameter. = None of the access points support it. Similarly, EAP over LAN is = implemented in most switches, but they definitely don't do Diameter. Is there a specific reason why Diameter was chosen? > Clients would be > tunneled to their own network/IP/routing and it would be easier for > public access providers to offer full networking without worry about = the > behaviour it outputs over their IP range. I think that's a separate step from EAP, or SASL over EAP. It may be = difficult to in practice to define that tunneling. > This may in fact be a path for your purpose of out-of-band based > authentication; SASL mechanisms could use such extensions too and = SXOVER > might help to protect the general mechanism. >=20 >=20 > Before this group existed I wrote a spec for EAP-SASL, is it = worthwhile > to continue, and how/what do you advise? > https://www.ietf.org/archive/id/draft-vanrein-eap-sasl-00.txt That draft looks reasonably clear. > The other work is progressing in > https://tools.ietf.org/html/draft-vanrein-diameter-sasl-03 I have no opinions on that draft. Alan DeKok. From nobody Sat Apr 18 11:05:47 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543B23A0F0E for ; Sat, 18 Apr 2020 11:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (1024-bit key) header.d=openfortress.nl 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 pZgTGw-kIyfD for ; Sat, 18 Apr 2020 11:05:41 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 13C9F3A0F0D for ; Sat, 18 Apr 2020 11:05:38 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id PrqPjKy0nlKa1PrqQji4Or; Sat, 18 Apr 2020 20:05:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587233133; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=VaMNZd5CNhZnAu3YcpkCUYHA4J2uAyBERt6ZpGPRiTI=; b=oakVkWM9jtuitHfna065KG8phLjkIMExeYxvjsfo9n4c0+ksOWjDJ/c9 8YDSe/B7/0aw4FCcAJt+H23dub15cL6k0xViBJARWdXCHLe5qcDsXgER1M mDKPb5f/NvJroIW5eTvBrWea53rFuX9Zivxw3VDOZbpq4vOkrXStVsFuY= Received: by fame.vanrein.org (Postfix, from userid 1006) id 724E539ED7; Sat, 18 Apr 2020 18:05:32 +0000 (UTC) X-Original-To: emu@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 2F0DB39ED4; Sat, 18 Apr 2020 18:05:27 +0000 (UTC) Message-ID: <5E9B4165.1050703@openfortress.nl> Date: Sat, 18 Apr 2020 20:05:25 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Alan DeKok CC: emu@ietf.org References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> In-Reply-To: <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfMUn/BgoFM2LvQF+X6EjmaqtiwKamz2Z6EgjdJe+nMXwfRHU4rOl20qPPqoYcu9yHmUqPJFj/tih7f+hGKH/QKtPc74KmmMRkLWXd+oPrcpwW9DnV6es lxyN6ESKtwpHszW2PQRcjFEWNlpIZHcECU3Yp8rLEPywrUdgJmhtwXutTLWlwaw1FpagsFqKM0AkvQ== Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 18:05:46 -0000 Hi Alan, >> An interesting usecase for EAP-SASL with all this would be WiFi and LAN >> authentication (EAPOL or 802.1x) passed over Diameter to *any* domain on >> the Internet, and receiving back tunnel information. > > Or RADIUS.... That's what everyone is thinking ;-) The reason for Diameter is that it scales up to the Internet (in terms of connection pooling / efficiency and in terms of security). RADIUS is really useful for internal networks, but becomes rather clumsy when crossing the Internet -- it is not suited for worldwide public service. > TBH, I can't recall seeing many WiFi deployments which use Diameter. None of the access points support it. Similarly, EAP over LAN is implemented in most switches, but they definitely don't do Diameter. Catch-22 -- no use case, no software. That's why I'm describing the use case here. We'll probably package our kit for OpenWRT, so everyone can benefit / derive from it. A patchy solution is possible for closed routers; RADIUS and Diameter can crossover, so a local node doing that is possible. > Is there a specific reason why Diameter was chosen? Certainly, - It enforces mutually authenticated TLS for peer-validation - It does not silently assume a profile but negotiates at startup - It can pool validated TLS connections for reuse - It runs over SCTP for realiability without head-of-line blocing These are hardly a concern for internal networking, and very much concerns for dynamic realm crossover. >> Clients would be >> tunneled to their own network/IP/routing and it would be easier for >> public access providers to offer full networking without worry about the >> behaviour it outputs over their IP range. > > I think that's a separate step from EAP, or SASL over EAP. It may be difficult to in practice to define that tunneling. Yes it is separate, and just here to give you some context. There are several AVP sets for tunneling in RADIUS / Diameter, and making a choice would probably help the crossover to work in general. >> Before this group existed I wrote a spec for EAP-SASL, is it worthwhile >> to continue, and how/what do you advise? >> https://www.ietf.org/archive/id/draft-vanrein-eap-sasl-00.txt > > That draft looks reasonably clear. Thanks for taking the time to judge that. I'll wait a little more to hear others respond on what to do here. I agree with your take that it's not an exact fit here but that it has no other place either. >> The other work is progressing in >> https://tools.ietf.org/html/draft-vanrein-diameter-sasl-03 > > I have no opinions on that draft. ...as it merely provides context, yes of course. Thanks, -Rick From nobody Sat Apr 18 11:47:39 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4833A10BA for ; Sat, 18 Apr 2020 11:47:37 -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 NQy4jwTdLgYP for ; Sat, 18 Apr 2020 11:47:35 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EBD3A10B9 for ; Sat, 18 Apr 2020 11:47:34 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C323D143; Sat, 18 Apr 2020 18:47:32 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Alan DeKok In-Reply-To: <5E9B4165.1050703@openfortress.nl> Date: Sat, 18 Apr 2020 14:47:30 -0400 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> <5E9B4165.1050703@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 18:47:37 -0000 On Apr 18, 2020, at 2:05 PM, Rick van Rein wrote: > The reason for Diameter is that it scales up to the Internet (in terms > of connection pooling / efficiency and in terms of security). RADIUS = is > really useful for internal networks, but becomes rather clumsy when > crossing the Internet -- it is not suited for worldwide public = service. Uh.... what? RADIUS is used in Eduroam, which is a worldwide public service. There = are many other roaming groups using RADIUS. It seems to be fine. I'm not sure why you think otherwise. >> TBH, I can't recall seeing many WiFi deployments which use Diameter. = None of the access points support it. Similarly, EAP over LAN is = implemented in most switches, but they definitely don't do Diameter. >=20 > Catch-22 -- no use case, no software. That's why I'm describing the = use > case here. That is definitely *not* the reason people avoided Diameter. The reason is simple: RADIUS does everything that the enterprises and = ISPS need. Even Telcos use RADIUS for many things. Diameter won in the Telco space because (at a high level) it was = mandated in the 3G standards. And even it seems to be dropped in 5G, in = favour of JSON over QUIC. So your starting assumptions are wrong, which makes it easier for your = conclusions to end up in the wrong place. > A patchy solution is possible for closed routers; RADIUS and Diameter > can crossover, so a local node doing that is possible. The Diameter protocol is about 100x more complex than RADIUS. It will = take *years* before router vendors release inter-operable Diameter = clients. Their best bet is to just do RADIUS, and rely on a Diameter = server in order to do RADIUS to Diameter translation. There is just too little benefit for vendors to implement this in = their client products. >> Is there a specific reason why Diameter was chosen? >=20 > Certainly, >=20 > - It enforces mutually authenticated TLS for peer-validation There is a RADIUS over TLS transport, which is widely implemented and = deployed. There's also dynamic peer discovery. Less widely = implemented, but definitely used. > - It does not silently assume a profile but negotiates at startup A profile for... what? > - It can pool validated TLS connections for reuse RADIUS implementations already do this. Source code is available. > - It runs over SCTP for realiability without head-of-line blocing It *theoretically* runs over SCTP. In practice, SCTP is not widely = used. > Yes it is separate, and just here to give you some context. There are > several AVP sets for tunneling in RADIUS / Diameter, and making a = choice > would probably help the crossover to work in general. In RADIUS, those attributes provide for VLAN assignment. They don't = provide for secure tunnels to "home" networks. Diameter may be different, as I haven't looked at in detail. The short summary is that if you want this to be widely used in the = short term, you should define a RADIUS transport.=20 While freeDiameter exists, it doesn't seem to have an active mailing = list. It's policy capability appears small. It seems to be mainly a = proxy. Which means that you are limiting the market for this idea to = people who are willing to pay $100K+ for a commercial Diameter product. Such a strong limitation means that this idea is likely to be dead in = the water even before it starts. I would therefore suggest expanding = the use-case for this proposal. Alan DeKok. From nobody Sat Apr 18 12:55:37 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EC13A0B66 for ; Sat, 18 Apr 2020 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=openfortress.nl 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 eLYmn11kHyDt for ; Sat, 18 Apr 2020 12:55:31 -0700 (PDT) Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (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 2A1FC3A0B65 for ; Sat, 18 Apr 2020 12:55:30 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id PtYjjLatClKa1PtYkjiOUN; Sat, 18 Apr 2020 21:55:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587239725; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=P3qwZ1S8bQQCJT56KafEDECJoS8VgyOJczv0GOP0SUY=; b=mVtq9S6Uzi656qHJWtbOiLy5/Z6BRCbrD/hhzkp9B6j15tuPO4pBSphR t0Clbp//7IvKjSCYaInfZLfTPN6VXS3JfAxcDUIqjMXzVVEJgOu2tJw5Uw 4uH2tniTpORChDjR6Wi2SDdkLCorJ+hM55YLrgcvt2cCgT+q4JnEESpcw= Received: by fame.vanrein.org (Postfix, from userid 1006) id 0322539EE2; Sat, 18 Apr 2020 19:55:24 +0000 (UTC) X-Original-To: emu@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id BA74C39EEB; Sat, 18 Apr 2020 19:55:21 +0000 (UTC) Message-ID: <5E9B5B28.3000007@openfortress.nl> Date: Sat, 18 Apr 2020 21:55:20 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Alan DeKok CC: EMU WG References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> <5E9B4165.1050703@openfortress.nl> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfCku56Kp9CSbonJJBbtKXMHnWVztbSWHUfdA5m0OcsNVLKeDOQ9WjJulF19E2s3iEA+kkXCBDn0q9AJBzs75s8HbxBu4t2bYwKroXzoWKJQRwV4m9JSD 4Psea8TgnetgwdIwycjIfwLV6fymR2t6DJXsETUF3l9I1FbY175+yuH8K+QdaBbND8IhySzvCByEGw== Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 19:55:35 -0000 Hi, This is turning into a discussion about RADIUS versus Diameter. Please note that this is not implied by my proposal of SASL over EAP; that I merely want to be somewhat clear about how the use case could look. I do thank you for evaluating these details, and am aware that the anticipated advantages of Diameter have balancing arguments. Thanks, -Rick From nobody Sat Apr 18 13:04:42 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DDE3A0BAD; Sat, 18 Apr 2020 13:04:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158724028189.3696.12970079545165243349@ietfa.amsl.com> Date: Sat, 18 Apr 2020 13:04:41 -0700 Archived-At: Subject: [Emu] The EMU WG has placed draft-aura-eap-noob in state "Candidate for WG Adoption" 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: Sat, 18 Apr 2020 20:04:42 -0000 The EMU WG has placed draft-aura-eap-noob in state Candidate for WG Adoption (entered by Joseph Salowey) The document is available at https://datatracker.ietf.org/doc/draft-aura-eap-noob/ From nobody Sat Apr 18 13:13:37 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22373A0BEE for ; Sat, 18 Apr 2020 13:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 2LKgBG0RAcPz for ; Sat, 18 Apr 2020 13:13:34 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 A41CA3A0BED for ; Sat, 18 Apr 2020 13:13:34 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id y3so6376841qky.8 for ; Sat, 18 Apr 2020 13:13:34 -0700 (PDT) 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=7+t6zlX6b+fHlVUFVQslghs2Pq6HWtUXTcr4GOJ0zFU=; b=ALSTSLTctUpdQMo1X1xRkALKS42akauxt5xyd/oTL3cMY+M+sqiwq5PIEwmP4brAF3 SdXHnHaSF4DIZoDJdpAUjajg6miR/IzHBnXD6NbLd6ZBvGyBSHR1y/lx54tCw6XWkTgG YdF3GIE14y4nJ95nDj//niNz7uQvonTYNc5qo81hPLa7hRNvpJVarU3x0h72KprAFbYX 92Jgc93qP7z3Os2ZaPewVh7FKschSwDFS5nvCYp1hTSfcapPlHDFWgFcGDoiTVje36Bi slkRFAHbZeYFSRwa0ZIQlAIWtQ2+JX6ufIsuXFaCCzW33C9wfLj+DaSUvY/HuJfkZmF4 0xXg== 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=7+t6zlX6b+fHlVUFVQslghs2Pq6HWtUXTcr4GOJ0zFU=; b=Kineff/AJ0AOZzZLsH3bACju+1b1qVaIU/LpoHzaNWggkzWK5Z1MnEWLzXJVF1Iob6 lv69BlWLcz1BAZP120PgDaqx6jAJgzrLkKUztfImNsEnk2MTzZx5+lRxECGvAKFgHnFZ qbY3TqzEKsYxa3wgI+zyZqw/Vx560azY8Io6l1EKPRUI/5vs96pXXYoCXNvDxT81kgek tCAAwXbOtOKdnI0AqxqeHr5NAFxFFLbTU3/9fbd7jrMu55FuLFXSNepCpjQa2Wi0vkSB CdlG2dNDAV67mDaUc6Foi/cm7q0opCDP5fm1ELXhZOYwIRJNSipFCbQpSyoFKy7Otdz7 zcJQ== X-Gm-Message-State: AGi0PuZY5XqCPmZADK3nGKtRUKxwbhoJCxfAmpbE5G9go0dA9COKvxpF q5x7QaWVFnRezm+lSshHuqOAppjticJOQMb9Q7404J5hiNg= X-Google-Smtp-Source: APiQypIXbH+jUcGt8lywn5Pf3tLYPtcqy5a2lrhFL/P/Cph63YaAuaL8OxIOqWIzDboP501pOLAmD9l/RwOQVyralFo= X-Received: by 2002:a37:9ad0:: with SMTP id c199mr8840435qke.472.1587240813271; Sat, 18 Apr 2020 13:13:33 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Sat, 18 Apr 2020 13:13:22 -0700 Message-ID: To: EMU WG Content-Type: multipart/alternative; boundary="000000000000d9398605a3964cd2" Archived-At: Subject: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 18 Apr 2020 20:13:36 -0000 --000000000000d9398605a3964cd2 Content-Type: text/plain; charset="UTF-8" This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working group item. This draft has been discussed in several IETF meetings and would be the starting point for the working group deliverable for an EAP method based on "mutual authentication between a peer and a server that is based on an out-of-band channel." Please review the draft and indicate whether you support adoption or not by May 4, 2020. Thanks, Joe [1] https://datatracker.ietf.org/doc/draft-aura-eap-noob/ --000000000000d9398605a3964cd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a call for adoption of draft-aura-eap-noob-08.txt = [1] as a working group item.=C2=A0 This draft has been discussed in several= IETF meetings and would be the starting point for the working group delive= rable for an=C2=A0EAP method based on "mutual authentication between a= peer and a server that is based on an out-of-band channel."=C2=A0 Ple= ase review the draft and indicate whether you support adoption or not by Ma= y 4, 2020. =C2=A0
Thanks,

Joe

--000000000000d9398605a3964cd2-- From nobody Sat Apr 18 15:27:20 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18653A1313 for ; Sat, 18 Apr 2020 15:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 MHfXb7EilQXa for ; Sat, 18 Apr 2020 15:27:17 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D522B3A1312 for ; Sat, 18 Apr 2020 15:27:16 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 4127F36C; Sat, 18 Apr 2020 22:27:14 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Alan DeKok In-Reply-To: <5E9B5B28.3000007@openfortress.nl> Date: Sat, 18 Apr 2020 18:27:12 -0400 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <53BB9E1C-58D4-454E-B77B-3FA4AFA89E15@deployingradius.com> References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> <5E9B4165.1050703@openfortress.nl> <5E9B5B28.3000007@openfortress.nl> To: Rick van Rein X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 22:27:19 -0000 On Apr 18, 2020, at 3:55 PM, Rick van Rein wrote: > This is turning into a discussion about RADIUS versus Diameter. I'm suggesting that since EAP runs over AAA protocols, it helps to = understand where each AAA protocol is used, and why. The alternative is to have a solution which isn't applicable to = existing problems. If your proposal is intended to run mainly in the 3G space, then my = previous message explains which protocol you use, and why. If your = proposal is intended to run mainly in the enterprise / ISP space, then = my previous message also explains which protocol you use, and why.=20 I believe that the document is clear enough so that someone can = implement it. Which is appreciated, as many protocol drafts are = maddeningly obtuse. The concern is that the document does not explain *who* would use this = solution, or *why* they would use it. Or, why it would be used instead = of existing EAP methods. On another technical note, page 3 says: What SASL stands to gain is the ability to be carried over widely used AAA backend protocols such as RADIUS and Diameter. When a site is standardising its authentication on SASL, it is possible for both network access and end-user applications to isolate authentication sequences and relay them to a shared AAA backend. This facilitates centralised management of identities and credentials. The ABFAB working group standardized precisely this many years ago. = One implementation is Moonshot: https://www.jisc.ac.uk/rd/projects/moonshot They demonstrated roaming users authenticating to home networks using = EAP over AAA. Not just for network access, but for SSH, Web login, etc. = It would be good to explain why ABFAB is not applicable to this = problem. I'll speak further from personal experience in this area. I've worked = with roaming groups and companies for a long time. Typical commercial = roaming integrations take many months. The technical side (e.g. dynamic = roaming lookups && certificate exchanges) is the most trivial part of = it. Also, these integrations are largely for ISPs and Telcos. But not = for enterprises. My experience has been that most enterprises are been unwilling to = discuss roaming. They see no benefit in setting up or using AAA servers = so that employees can roam. So... what is the motivation for this proposal? Who will use it? = Why? Alan DeKok. From nobody Sun Apr 19 09:17:30 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE13A0D36 for ; Sun, 19 Apr 2020 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 0YP_ZIPXxXiv for ; Sun, 19 Apr 2020 09:17:24 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5AF3A0D27 for ; Sun, 19 Apr 2020 09:17:18 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 637EC3D6; Sun, 19 Apr 2020 16:17:16 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Alan DeKok In-Reply-To: Date: Sun, 19 Apr 2020 12:17:14 -0400 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jorge Vergara X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 19 Apr 2020 16:17:29 -0000 On Apr 7, 2020, at 5:09 PM, Jorge Vergara = wrote: > On the document contents themselves, I have this review: The key = derivation proposed for TEAP/FAST uses the definition from FAST, which = is not identical to the TEAP derivation. Namely, FAST used MSK[j] in the = derivation, but TEAP uses IMSK[j], which may be equivalent in some = cases, but may not in others where the inner method exports an EMSK. >=20 > Specifically, I believe this line of section 2.2 should change from > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound = Keys", S-IMCK[j-1] | MSK[j], 60) > To > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound = Keys", S-IMCK[j-1] | IMSK[j], 60) > For TEAP. I've made the change, thanks. Alan DeKok. From nobody Sun Apr 19 09:18:14 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18FC3A0CB7 for ; Sun, 19 Apr 2020 09:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 hbf-Iqc6Q9c1 for ; Sun, 19 Apr 2020 09:18:12 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536D43A0CC8 for ; Sun, 19 Apr 2020 09:18:07 -0700 (PDT) Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 06EA73B8; Sun, 19 Apr 2020 16:18:05 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Alan DeKok In-Reply-To: Date: Sun, 19 Apr 2020 12:18:05 -0400 Cc: EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: <782E05D8-EAC0-4117-9692-B8F39C8BF4FE@deployingradius.com> References: To: Joseph Salowey X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 19 Apr 2020 16:18:13 -0000 > On Apr 18, 2020, at 4:13 PM, Joseph Salowey wrote: >=20 > This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a = working group item. This draft has been discussed in several IETF = meetings and would be the starting point for the working group = deliverable for an EAP method based on "mutual authentication between a = peer and a server that is based on an out-of-band channel." Please = review the draft and indicate whether you support adoption or not by May = 4, 2020. =20 I think it's OK. I do have to question why the WG is engaging in new work, when the = updates to TTLS and PEAP are languishing. That document is small. = There's been positive feedback. There have been only minor issues which = have been addressed in the most recent version. I think that we should be able to accept, last call, and publish the = document in short order. Alan DeKok. From nobody Sun Apr 19 15:37:17 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03DA3A0799 for ; Sun, 19 Apr 2020 15:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 eQDeoMesEaA9 for ; Sun, 19 Apr 2020 15:37:15 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 EB4B73A0798 for ; Sun, 19 Apr 2020 15:37:14 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id n20so782853qtp.9 for ; Sun, 19 Apr 2020 15:37:14 -0700 (PDT) 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=HEEeEu+PP98Lss8WtNvf2PFv8bGg2sxkFWvcGZMnElE=; b=mDxCg60Bjp6D81yzBt/lexViXu/DWJprZaGSVVRZwlodZINRpcag2u4tIFS4BB0ai5 FZL2Jvo+/DTQKoVHyAVAkx2b5XKjWwOfaU7kTElxsXVSuH9hpEmHd39azG+4CGcoiWYz 1BXs4ftXxGDPlcsg61r0bF86GiJQuipYuqeAhLd4ejppT3Otj7IkX2Q4zPUr0tFj/vCI FDVK9cIlqWM0uIhKBeSCVsOQYVmDaQ+yEdqFATRi9nTECM1pFFTVn9eGIl0FBYBVMgBY bb2pLQCSWwLupsCL+9EEta0rOXJ4+PNOmVLuNqaVG9MLSuCvJvVZ8PS5p4bFARGNnLDC cFTA== 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=HEEeEu+PP98Lss8WtNvf2PFv8bGg2sxkFWvcGZMnElE=; b=k83WXTT0yTJEk7TchGThFxvANMzzhOAkwhcDX8kQaVFqlNP15I3C2ZV0QUSS665ufJ r8aborgnxLp5KMDqL3Fj28fkHjo6fyeVmpCScHO8PPrc7PAeJwzV7uZvIPhuXOGttoj0 Gc6wrLjkYYwYvbzlcpBLGyuv8TSyyKYUoaeYaDCyLvUB6vt1iWMxu2KzbCm6TZrniNxq p8/72dg8/Tjf53V8O3nsJAfEGgspFI8BBuA+Gjbx4ezmoiikxpGPDHOHaa3X01JxctaW ZoQX4qfCL7iia5m+7UYOW0QgcQAUBT+A7jaOe+XM6DUwgEGCptIAbRmRm3kcKbT9sN9Z DS8Q== X-Gm-Message-State: AGi0PuYXPIfas+xiZ8ePfT4WGuAhBjPoNR4DR7BQn9PqCuuznB8GHU3C f/I+abfgOlsXyg4sDuoSE+HYITK6JVgoq9znWYcN0FuIm+0= X-Google-Smtp-Source: APiQypKTRkvaGI90TzdqwnTbrRQXZKPJpSczD/mhiK+DKfNqmhi2Ne/ILJFBTK6BYcFIWdsnnd59qAwfuaHOw9nVHjI= X-Received: by 2002:ac8:4c9d:: with SMTP id j29mr12177620qtv.297.1587335833614; Sun, 19 Apr 2020 15:37:13 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Sun, 19 Apr 2020 15:37:02 -0700 Message-ID: To: EMU WG Content-Type: multipart/alternative; boundary="00000000000080928b05a3ac6cbf" Archived-At: Subject: [Emu] WGLC for draft-ietf-emu-eap-tls13-09 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, 19 Apr 2020 22:37:17 -0000 --00000000000080928b05a3ac6cbf Content-Type: text/plain; charset="UTF-8" This is the second working group last call for EAP-TLS (draft-ietf-emu-eap-tls13-09)[1]. The authors submitted a draft to address the issues raised during the last working group last call. Please focus on the changes [2] in the latest draft and send any comments to the list by May 4, 2020. Thanks, Joe [1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ [2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-09.txt --00000000000080928b05a3ac6cbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is the second working group last call for EAP-TLS (dr= aft-ietf-emu-eap-tls13-09)[1].=C2=A0 The authors submitted a draft to addre= ss the issues raised during the last working group last call.=C2=A0 Please = focus on the changes [2] in the latest draft and send any comments to the l= ist by May 4, 2020.=C2=A0=C2=A0

Thanks,
Joe


<= /div>

--00000000000080928b05a3ac6cbf-- From nobody Sun Apr 19 15:48:40 2020 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3533A080E; Sun, 19 Apr 2020 15:48:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158733651926.17014.15433835583977758741@ietfa.amsl.com> Date: Sun, 19 Apr 2020 15:48:39 -0700 Archived-At: Subject: [Emu] The EMU WG has placed draft-dekok-emu-tls-eap-types in state "Candidate for WG Adoption" 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: Sun, 19 Apr 2020 22:48:39 -0000 The EMU WG has placed draft-dekok-emu-tls-eap-types in state Candidate for WG Adoption (entered by Mohit Sethi) The document is available at https://datatracker.ietf.org/doc/draft-dekok-emu-tls-eap-types/ From nobody Sun Apr 19 15:49:50 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA13A0814 for ; Sun, 19 Apr 2020 15:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Mbu7lqkoeuBP for ; Sun, 19 Apr 2020 15:49:47 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60050.outbound.protection.outlook.com [40.107.6.50]) (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 642E53A080E for ; Sun, 19 Apr 2020 15:49:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PshXk519Uify0ySqKcIXtv/V4GQO4LkBuy3WSUjczHmOmkwqJ/a94/06RGjE9X69rqLJ4g2l1GfSOqIW6sGmIqf8lPLjtfVzE1910tl4c+5tsccOvBfQXx+mN2GwgxbUgxKboPKNbsjjEh2uwI7Y6U1I3gmCCQwn/EHAgTMZCK7bht7eLS/gBn9EBYqTtSk42flJFeff038MHT7mmeRu8SFaDgii0YKMvPSRgD57KCeUsiYHANvr/LwY9pIb7aiDDcnVF9vgPPrdFu/hD06HFRKKNPcJWOV0tSE6pdjm9X81jEOLW+lcB/REhzw3sLsQKw85FXvJLNrje3LcdiJX9A== 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=Znt+S9awS8/24LdDZioWMPIANpvaVYgKqFcPprTzC3w=; b=NK3NMMtOzDQMSWNpMAVrw94jWVDStt8ucBZ6y+amrlYHUbVQVZh5RLdu2hva9CVKCU/IkCiu+D0hQ3YoUCWCZXpzWk9DoK5fWm5ctU/Fs4hn5aCUf27ASizIbFgCWciFyp4sgsVPFJw5aQ2l324qD5cCq+pIBhg/Ls1Hiy0NhMUfeY7WCKa7u9FDbkEzWPHTk8yFhh4sxIeeCOznZ6W4mnspPirmvNUrQHd5frlRbmftshscBbZcVCxRnTQERNfkC+UHp4nCjj8YytPhiGJZLAXyVSq9HB2EIUBoo1hsj/ximMkhstcWGjtwxtpYS6ubbaLAaJlZ7VYQMiqxx52hZQ== 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=Znt+S9awS8/24LdDZioWMPIANpvaVYgKqFcPprTzC3w=; b=rd/5Bxd1ZSQ3YZGDObol44LlWowxKvqS51J43uIgk4JiEAtZ9zlXuGKxYDdzsf+iz94MM6ZGpXdBNEdLH+StCrRDqecm87P77Q+bFUasechmTfRnFZ85cK8PRLwUQgTVRefGQ12kMLsfQuzDTocdF1gqFAmJw/Kn+KrBrjkii10= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2204.eurprd07.prod.outlook.com (10.168.36.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Sun, 19 Apr 2020 22:49:42 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.011; Sun, 19 Apr 2020 22:49:42 +0000 From: Mohit Sethi M To: Alan DeKok , EMU WG Thread-Topic: [Emu] draft-dekok-emu-tls-eap-types discussion Thread-Index: AQHWFpzQImW9/2SDcUmeBf3An88Nhw== Date: Sun, 19 Apr 2020 22:49:42 +0000 Message-ID: <63518e5f-7d44-dda3-6c12-635e754cf9ab@ericsson.com> References: In-Reply-To: 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:170:1fc7:3791:e56a:e85a:b86c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5fbe683-2c8b-4794-6016-08d7e4b3f312 x-ms-traffictypediagnostic: HE1PR0701MB2204: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(376002)(346002)(366004)(31686004)(8676002)(81156014)(76116006)(186003)(64756008)(66476007)(66946007)(66556008)(66446008)(8936002)(2616005)(45080400002)(71200400001)(478600001)(966005)(53546011)(6512007)(2906002)(36756003)(110136005)(316002)(6506007)(5660300002)(6486002)(31696002)(86362001); DIR:OUT; SFP:1101; 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: jv7VWpgSHzRkWBjlHPjz+bcmF+UKY9uDQh6Goq5wZPEbyqHwRuHWBCPAKC0HS2KXkexiFj9ia7NCIaVds++e11qv7j7fBauRqjdhPRl3IlA3SqUeJOELOdERD3SVMqLAYxOenc/BAfQr6wKotAxI/QPmrVqJVWE3vQNw2D7swV6xD+l13VsiWAsiq/pcTPofAp8o+96pRCRcCKT2jf9vH2LfIC6FZVmwfvPs06dgZZEK7I8Q5XnJLX0APXgbfRSk+E/JVOsY0FVQE4mkpcUi1UQFzigya3WLAhHovelDD8hQvkumn+2AJEqpGFDQaPoFMW2th29d8nBhVIVQF0a6xLIAw++PQ/IU0bNIreW66PzARdjRRr4h/mIxu37lusS7lTbUeKM0nfTyajzYpEnQnhV80utNiorizNMxK7w7ieReiWEF0Kd52/J5xyrxET+15DwanfhqZLMdiqhfEW8lFwZZHhpjS5JoGs4LBzVikdU5nkxeadvOVFyXbcrC5rRRMXfAbwSTi4P2njenGuhy+A== x-ms-exchange-antispam-messagedata: 8nEGsmtg1P2552gLP+m4DPGWa3xzo61MjmcPe2/5siBbF7/m9x67VxBwDc2SyyXKgv+MDWRlcESTQTBcC0R+W6Cxf7/vSuKNzopQnOM6YLJEC2cgTuMkWpnH3N52re4UpRBv1LqK8Fa030v2hwads37q7xkqfbZpQhLvYh9QT1RvLK3aaOhN6IRNa0MPKe5qwu/xs9652QbbsBUzXbc+BhKQcNGjtQTQCQZ3eif9uD6hIfE3kUd2eV6WzgGbzMKQsSjc8drvG5goAECFA+sqDnFV2AVXzIncqoe6+99PS5LBPKWn153Y3LrIcLjTPtFbm/CBKJXZOQldfLJLFrfSNdlpf1hZjzDCdd1GXE7UGkKGKOEXqoRfH/KfhWOpWFh1/+VmHHxGj5PDa+NB+UEzF+bI47a7dlO6VwT/0Tz6mbcJVOTDGdAhYVvOFfVeKQCGPMo1yofmFcMnEaeolBPI0GibNz8sRnMRXQejx2wpOEdOTB+gxPVyM22USFbCjHQ0vwGmoo/5VIdDn8QIf8hk6hQddhdlSbKbylBle5IVJlT9DdEQ4bJoXbeELsstR4ASVYUW9XrDS7CeYmGSwbTpsvxO7ejTeCO0s6ZTLpZH30C6Du1CD56iU/bAWydKksRnvPvrzCe8ojS8vFKU0Z6QGcP5fENGf70A1wDvCtmJU1FasbnrmAoXIDwsZhJeoRqFhINSb3VHyzLJCJ+DWcKga7F886GjDvsujN7/ytmcjfGaWh3a+VsBmVnZdi7B0iiaBKwHkJNEsBuH/1yNbS/sFPqKSqLrzhkiE075r7zgU/MZyvWyQ1s53kwjOV4g9Mh0UVdN4PfWy3BBdq17Jp0y6UMlDDZDI4l3deet5UCodWQ= 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: d5fbe683-2c8b-4794-6016-08d7e4b3f312 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 22:49:42.3151 (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: w2v6BFrtzIKhckvfN+cAy2V0AaQWb15llJ9oTjXT6VbxERhT06ilnc+kDekQPHPwifmUCzvL7cOPeysaHTyUcG34FaW2iKwmi9WAQJZzUdM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2204 Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 19 Apr 2020 22:49:49 -0000 Tm8gaGF0IQ0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQhDQoNCi0t TW9oaXQNCg0KT24gNC8zLzIwIDExOjQ4IFBNLCBBbGFuIERlS29rIHdyb3RlOg0KPiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZGVrb2stZW11LXRscy1lYXAtdHlwZXMtMDENCj4N Cj4gICAgSSBoYXZlbid0IHNlZW4gbXVjaCBkaXNjdXNzaW9uIG9uIHRoZSBkb2N1bWVudC4gIFRo ZXJlIGFyZSBzdGlsbCBzb21lIG9wZW4gcXVlc3Rpb25zOg0KPg0KPiAqIHNob3VsZCBpdCBiZSBw dWJsaXNoZWQgc2ltdWx0YW5lb3VzbHkgd2l0aCBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTM/DQo+ ICAgICBJZiBzbywgd2UgbmVlZCBzb21lIGNvbnNlbnN1cyBvbiB0aGlzIGRvY3VtZW50LCBhbmQg cXVpY2suDQo+DQo+ICAgICBJZiBub3QsIHdoZW4gZG8gd2UgcHVibGlzaCB0aGlzIGRyYWZ0PyAg TWljcm9zb2Z0IGhhcyBhbHJlYWR5IHNhaWQgdGhhdCB0aGV5IHdvbid0IHJldiB0aGVpciBFQVAt VExTIGltcGxlbWVudGF0aW9uIHVudGlsIHRoZXkgY2FuIGFsc28gcmV2IFBFQVAuDQo+DQo+ICog U2hvdWxkIHRoZSBkb2N1bWVudCBzaW1wbHkgZHJvcCByZWZlcmVuY2VzIHRvIEZBU1Q/DQo+ICAg IEl0IGxvb2tzIGxpa2UgdGhlIGVmZm9ydCBoYXMgbW92ZWQgdG8gVEVBUC4NCj4gICAgUGVyaGFw cyB3ZSBzaG91bGQgbm90ZSB0aGF0IEZBU1QgY2Fubm90IGJlIHVzZWQgd2l0aCBUTFMgMS4zLCBh bmQgdGhhdCBURUFQIHNob3VsZCBiZSB1c2VkIGluc3RlYWQNCj4NCj4gKiBzaG91bGQgdGhlIGRv Y3VtZW50IGRyb3AgcmVmZXJlbmNlcyB0byBURUFQPw0KPiAgIEdpdmVuIEpvdW5pIE1hbGluZW4n cyBjb21tZW50cyBvbiBpbXBsZW1lbnRpbmcgVEVBUCwgaXQgbWF5IGJlIHdvcnRoIHNpbXBseSBu b3RpbmcgdGhhdCB3ZSdyZSB3YWl0aW5nIGZvciBhIFRFQVAgdXBkYXRlIGRvY3VtZW50DQo+DQo+ ICogV2l0aG91dCBGQVNUIC8gVEVBUCwgdGhlIGRvY3VtZW50IGlzIGFib3V0IDQgcGFnZXMgb2Yg dGV4dC4gIElzIHRoZXJlIGFueXRoaW5nIGNvbnRyb3ZlcnNpYWwsIG1pc3NpbmcsIGV0Yz8NCj4N Cj4gKiBXaGF0IGFyZSB0aGUgYmFycmllcnMgdG8gYWRvcHRpb24gYW5kIHB1YmxpY2F0aW9uPw0K Pg0KPiAgICBBbGFuIERlS29rLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0K From nobody Sun Apr 19 15:53:06 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF943A081E for ; Sun, 19 Apr 2020 15:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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 AEKzWF9iaInU for ; Sun, 19 Apr 2020 15:53:03 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) (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 611753A081C for ; Sun, 19 Apr 2020 15:53:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YOkH8Pnlt0lTbS8LYRY/6lYfAsGRRGvZUE+N2KZqvKAuQjc1Hi/+1TjXHXcd//78cKttFt7D5D5HBeH71SGomrth4NxgOA8lmerEQmAcuk5cbW+NHitkm98/BNQuXk+ooo2wl36qjZCBwSzzS8g+UJQNcyZzsgBU6DgvzTinl3SsDaP2oKvSk72JC5kXOgCfLsWeDA+plouF78DWM6ojtvw6lc87z7KhEGEFd6IeMZuTRrkLhvJGIQWmUaDK+f+klLs41w7s2siLBjgpivB1ZR8QsuFXqrgao6h1Wvp+Jg9pliIrMbTap5t0XZ8PXfl9V6Abk1iHCwwRKMuLuvVpTg== 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=Gh0NuLTMJ2Zi+1x891J8ff44+WXzOVP5isjE6uvlaR8=; b=RP5ZA1YooAit43NUTwPNKg7btX3pNBAbSduW2dvWOwlI0b6T0/q26mxkcI1r5f60KGacHoh0dMaZvzQ39YQfsRgquVG3yMh64m4nWIiOW61UrzOgAFfzoRV19OFDT/KMzNRWoFEhoAEq0EJo60xDVJ0nydX0pu0+8CJU5Tno9QbdGdvNw67d5zByVkx7of2EPK+0A3dV1llM6PZAS2WzvfqDVhhJqKMMuOqhLibXzdzwAugUzF5vJClmFu4lVdmJtgWOYax/VmqpP5vJ+uNjRBHjO2YGW+Hl+Fy2b/2X2KUpujLGDmsDnMU3P1W5sbUP4pfDZ0K4KN+BVvKuaeaRCQ== 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=Gh0NuLTMJ2Zi+1x891J8ff44+WXzOVP5isjE6uvlaR8=; b=a0tVIYbdRnCCCOpDfn05ExiaTFV648x3C2J9motolmto1BkOb00QxSzAT8djf5gm9WSR5VdM1H1/IFyhrccuOhTjg2Xer9KzaWoF/jlVqf4qaTdzf+p5biMK1uXqQPNmXdRtx852vxuXduvbCeTi8rPwomMywuvQ3ybmqQqvGhg= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2204.eurprd07.prod.outlook.com (10.168.36.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Sun, 19 Apr 2020 22:53:00 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.011; Sun, 19 Apr 2020 22:53:00 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: Working Group Call For adoption of draft-dekok-emu-tls-eap-types Thread-Index: AQHWFp1GMAGifJM7G0ShEhYIO5Pbiw== Date: Sun, 19 Apr 2020 22:53:00 +0000 Message-ID: <57b8d094-1759-3d15-b846-c00f045d7372@ericsson.com> 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:170:1fc7:3791:e56a:e85a:b86c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 638d8cdd-6be6-4287-151f-08d7e4b46904 x-ms-traffictypediagnostic: HE1PR0701MB2204: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3631; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(376002)(346002)(366004)(31686004)(8676002)(81156014)(76116006)(186003)(64756008)(66476007)(66946007)(66556008)(66446008)(8936002)(2616005)(71200400001)(478600001)(558084003)(6512007)(2906002)(36756003)(316002)(6506007)(5660300002)(6486002)(6916009)(31696002)(86362001); DIR:OUT; SFP:1101; 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: gvXEfkyMRaOwzPliEb0Br95EhP/aZtGCQwSuNS02DSoM9ZzMetCU5s4mxo8lgwQmu//O8b89Qhy0NxVZhMXgMaFxPdp5vpZjGFx15s35mH74OX9BCuH1bcg9d5PTk/c7/8SiqbLbwYhfTvv+gXF6eHHhY5nYQpZzwkyfFLblPHjts9evwpGu5EvGQl08rV0Y62yq5F9ycFtSO5/3gTQSPIk7V/GGSFmQr/Wlxcijv0mj0zvvoOQBIMDQqbDiErIx7O00SJBAS33ydl8E9eCWCUOAtckDWHEyKkiCODoW1edxKSEyDYNf7xpY8jk7NJ5uqqwgeBeyoA1xnu04xpvEgNL+gIcQKJ/ylNhDpL9RaXBJEWABQ0qnx8hrUpLcJV2Hj0M4LGu5MAQ58MI2oi894oiUikcBFS3JP499MdHvFFHitaCT18VW2n4pnhpTUnG8VPrjiFO6uYkFBoHdZnoUvvBoj3VDus6lC1JNvJkNN7IVIVbrKIaVUrPmg/e7bf2SLAYPZkBy32jkzak1kzc0cA== x-ms-exchange-antispam-messagedata: OE35yKOcgbnfPV0zEwZmxUg0UkvZ5j70tEfKZGGAOUvbotf7Vjdqchb2+1qhzJWdXKi5CEti01JBTy9jBcBc/GnQgQAk+1XDQ9ZBiXJWVpnItEL1QaLAphpAJONXF6r3fbJdCk3rlgrPEhTvIhFqvpkavTDb4H0EExQYw6n2kDPgc6vm1u9pimqAAfC+5JdpSIStgmxHvaMelcv9vEXhPJv1wk4vaY5xo72NIffyrj64/IHKN76YALc58j7Wud8lDlmmhENs0heGYfj39Gk5LhmSs6twenfYpFEWFO0fOeHODrngLuw6hR/qdt9SQa9ppDqdWrFxwg11+g76/2FTr+I9vTbdd6R2CmuAhFkN6AWBmazvWXBeSmZDMOMqIAYYD3vkBmlPjsUrjVQvA/iXqsnb7qEnJHtz3/N1zW4bn/4M/aA5LCoKybLCUB4SdrT+92dxHyIValxLZn5fA4Yz4vZh16TMpS3EqEb/6X4JRUk5X9pHLeHq9K/POMd1akSbhGPhBlmhRA958olmCPY7Lu7p+85QdypyGblguvOBinyOMraGAkFyO20CLJSLAsbh2vdJhZ9JKxW7qWsWnPtM5lYGdq2Rbztcd6sxvIR7PQozMmm/iOstMC9vC9KUjC8+mTAf//NEYQRzQ+kYh+7v8p0XUXQoCknddzd+1jRtovN9HESFrMEiigtFOGaXVBfVYG9CvcAAqE33GCStcY2rVNAZOYXmM5RjEzD+q37WESK+xOWLEfXxZoLJ7BFh5o9f2Gl5waYSlDtFFta0sDUDnMU0Dvx3VFhC/yuB2pLekn9YUvWbfLPNLbHKap9pU+G/keLoNR5kg9RLhvzQMM4JOH+RejcMdpVRIe2Iweyh1Aw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <872ACE498962204AB8009AF55A6BEEE6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 638d8cdd-6be6-4287-151f-08d7e4b46904 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 22:53:00.2406 (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: xas/XT6ke09hPCL5xgsRPdl8zYMrIbaZEerHLDMoVlwmlffDfaNJaAhxGPj1EwPxcuTpxQmttTSr7oAI/hk+IBiH+7afdCiWaQFwEJCKd0U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2204 Archived-At: Subject: [Emu] Working Group Call For adoption of draft-dekok-emu-tls-eap-types 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, 19 Apr 2020 22:53:05 -0000 VGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWRla29rLWVtdS10bHMtZWFwLXR5 cGVzIA0KKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRla29rLWVtdS10 bHMtZWFwLXR5cGVzLykgYXMgYSANCndvcmtpbmcgZ3JvdXAgaXRlbS4NCg0KUGxlYXNlIGluZGlj YXRlIGlmIHlvdSBoYXZlIGFueSBvYmplY3Rpb25zIGJ5IE1heSA0dGgsIDIwMjAuDQoNCkpvZSBh bmQgTW9oaXQNCg0K From nobody Sun Apr 19 15:58:20 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773B73A0841 for ; Sun, 19 Apr 2020 15:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 wwrU7SbB-lAp for ; Sun, 19 Apr 2020 15:58:17 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2080.outbound.protection.outlook.com [40.107.20.80]) (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 C877C3A083F for ; Sun, 19 Apr 2020 15:58:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NxBsa94WZXkj8MFB6FyKztCImZQ4ERvzDY2kjfvhqd+pTrG3e8hUZC3a4Et5nnUqT9XQY2PxkKCQ1DU2vNeEySDIS3xqhf9VsWPPmfysU1T6b6BEp5xM7tkgqg4B+6JTzd/UkybmtdkIySprLf6c/4aM6O7hYWtvY9YQW7pGp5f/2g8Tg0XCFAxKNs6aLzzUhtoDhgecXkrbHF9vhdskBpf9awO4DvGSEBdPPkXyHcvLh0NW0SzX2Iqa8FCPjTmJNxpTE4o37wj6w6iSTyGUz6u6M7IXTtde2lgzEK+5nfFgZUjZYlFENDrpntmmvwe+sLoeJJD9k2QKcGfdsw2J2g== 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=M5VSxmFTLS4Qs7OmVUV4USlR+dXf06J9bcRmtv3gi0g=; b=GQtJxJv9czbXORDxna/ZJ8wr+YzD7i5rJShPxEJ0CSYUOoJlKEw6UUuTL21XtyqHfb2arw11FiCjGBrPeMrHh/b7+LrdSt72n3/m5jOEcEneKEObYph9CRulDO+8wVwCuvIcZike2fMmDS2gM6hVN0vUz38Hp2PZy0L9PyaQ425VWzVUU2Cn3jUS1pIQW7ktfjcJmi6VLHsENLxpAzUCWziWaP9J93cST7aOoXxJVOmQ3Ud87WY70G/F6oodsuWQh4o7aASDgudqunpPGIepN1MUogREUHdxarhbS/ccMpPkR2Q592xfUxKaCqCbHzvaW4QiNuhi57XRZ5Uk0RaBXA== 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=M5VSxmFTLS4Qs7OmVUV4USlR+dXf06J9bcRmtv3gi0g=; b=DbY87AnR5uT6NZ7SHhMQURUV1zs/aTtOPHriDfZe07CCmT5CDt6xfGHUqHTZ8Icay27rH2b5pU9EjCnhDgjeRekn2Y8JphfipIV9oCuG4BOfOuMZWTm0ULLemZWB7DoP3OTf1xJf+J/fIgKXM3T36b1v3ml8Ftts3biXbRSwOiM= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (2603:10a6:3:57::18) by HE1PR0701MB2364.eurprd07.prod.outlook.com (2603:10a6:3:70::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Sun, 19 Apr 2020 22:58:14 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.011; Sun, 19 Apr 2020 22:58:14 +0000 From: Mohit Sethi M To: Alan DeKok , Joseph Salowey CC: EMU WG Thread-Topic: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt Thread-Index: AQHWFp4BXRH8nFT7Qk+sXiq50zFCKw== Date: Sun, 19 Apr 2020 22:58:13 +0000 Message-ID: <298666d8-1992-4baf-953e-aed998449ca6@ericsson.com> References: <782E05D8-EAC0-4117-9692-B8F39C8BF4FE@deployingradius.com> In-Reply-To: <782E05D8-EAC0-4117-9692-B8F39C8BF4FE@deployingradius.com> 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:170:1fc7:3791:e56a:e85a:b86c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 516f55a0-e6e2-4bca-c1b5-08d7e4b52403 x-ms-traffictypediagnostic: HE1PR0701MB2364: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(396003)(39860400002)(346002)(76116006)(2906002)(8936002)(81156014)(8676002)(71200400001)(6486002)(4326008)(6512007)(31686004)(36756003)(66946007)(66476007)(86362001)(966005)(31696002)(6506007)(53546011)(2616005)(186003)(316002)(66556008)(66446008)(478600001)(110136005)(5660300002)(64756008); DIR:OUT; SFP:1101; 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: 1JrXe1W0m4q5/jif2mChJfAZUvFP+i9ESlx8iIBzuB2uGL9+vSY+vmVh7XTp6C+p+U1G8ev6NkmcfY7M7LqOfqDWxdyJ3pntR5lejVvwZfQD1apopNmKNJdVr7nIC5CVvQE5rQnEtDbzsa9/VWjDW9W8KjDT8JQEIUQjg+lCHE8Rf1LnM2tk44axwMn6/a9lg5ZOmb9jsuCbwlUjCWnzkznkmABI2WE+2FgK1g9TuFq+acf34rBG+OxHbw9KFBq9Nhwd3cTRLe7LBSG3ZGXeP5MEwEPKEEISOfdNyx2ef9/Yc12BAMr2MO+gX7mWvm6NQZc7g2ZGbxyyX5jWDkH+e8mBo/QRN8aSVI6p67SsF88d4abmgFkI7eZRb4LfhLrMnnkp5wtXRjPpMd52/uK/458iGLDOYdv6pXdshMQRsXuKEdjHxW9xYAW+AhGrdjsgrspr/YQE1Nw9CzTyHxcrcU3W2J+dUJEeBnevH5dmfWbt+ZKfSWVs45qo/CeFeWJ9Nejsl3SSIdGrcHKpOrxYzA== x-ms-exchange-antispam-messagedata: 7L//DI8k6jZTID5/rXT9efnB0IAvEmWZpLH1StFyZ6AsPeAvmdQLM9M6WBq394uKnOtrWNTJ1KUOqjfrwNbtKlSogAb26UdmcfCdxcPzKgNoWpD6Q72zU8VgL9Rtz5hAQPE5ST8ga7Vr68Q2T3T2+t2ymemd7nkpdZrKsRAm3z1uq8FqkqXe2LvM8M5kw/Vlui81oLS6mbEbc1hz75Er6N5ntnad+01tVNjDvHSYhhGU1wvZi3WM7e4W7ATtN/2Ms9raMSmfHH+9v/YQMW+Sp+kvojdNupr3eM7c152+E3QQktNBgSSdBZlpkXDNEgom164XdOawv/fu7RD90wpgH9bbMW/eIRlqSSeS9kaHjLVjjZkZ+yRd9MjO0034u/wM5LwzNcJZCd0aqNNl44Coi9SmCYGDk+3nPr6qsRN0ygc+XQjsc5UKz2EOBPEvF8W1khUKwObp4XBiyrrbOtoyb3JnSTGUpAgnACSZc3F/9yt+EIMxay2t+hpkmHh7mNkWbIuY7zpRSHDPhO0uImRaNMtU3DoY0gBvD5t60yefnIDs3/gBpM2LlDtRRUeyBo32YzwyfAKuB9emvkV9DJlzhyajLPwdNMinhOb5qo/EdPffwQYt2WOJdMjpcPdOisHnc2rMYhA4hku6/faTvc0lukfWBOHf+oqa0IdxYl2qKIwQ9r+Tq48ECbITbSqFxU8hHvr5Vy6XkD8AcPcZFuFHKbJYG27hF84dh1YOftIz315AjmN76ax6ofbfmileVOdDC/a7RTc7F7kbLXJAvXQlSRMqhcepOC3ySuMfaSyPOY/EQnRLgtswDCzJUZRvRW8aEqXzmiqHoIH7xEclkwQLpLgqqOxY1d4adW0pNfD1rdA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <15A38251F70DE54B864373A38C026A5A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 516f55a0-e6e2-4bca-c1b5-08d7e4b52403 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 22:58:13.9004 (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: YEkDbYrczitPLEqy5dtevmykxBvijQOtl6ANp8f3vckqopIMVKhrK1Ph6vOZnA3L2DgqJK5z8fD1soV6w3AI0q40Wtb306rp+w2tlUmoyhI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2364 Archived-At: Subject: Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 19 Apr 2020 22:58:19 -0000 SGkgQWxhbiwNCg0KT24gNC8xOS8yMCA3OjE4IFBNLCBBbGFuIERlS29rIHdyb3RlOg0KPg0KPj4g T24gQXByIDE4LCAyMDIwLCBhdCA0OjEzIFBNLCBKb3NlcGggU2Fsb3dleSA8am9lQHNhbG93ZXku bmV0PiB3cm90ZToNCj4+DQo+PiBUaGlzIGlzIGEgY2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQt YXVyYS1lYXAtbm9vYi0wOC50eHQgWzFdIGFzIGEgd29ya2luZyBncm91cCBpdGVtLiAgVGhpcyBk cmFmdCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gc2V2ZXJhbCBJRVRGIG1lZXRpbmdzIGFuZCB3b3Vs ZCBiZSB0aGUgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSB3b3JraW5nIGdyb3VwIGRlbGl2ZXJhYmxl IGZvciBhbiBFQVAgbWV0aG9kIGJhc2VkIG9uICJtdXR1YWwgYXV0aGVudGljYXRpb24gYmV0d2Vl biBhIHBlZXIgYW5kIGEgc2VydmVyIHRoYXQgaXMgYmFzZWQgb24gYW4gb3V0LW9mLWJhbmQgY2hh bm5lbC4iICBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgaW5kaWNhdGUgd2hldGhlciB5b3Ug c3VwcG9ydCBhZG9wdGlvbiBvciBub3QgYnkgTWF5IDQsIDIwMjAuDQo+ICAgIEkgdGhpbmsgaXQn cyBPSy4NClRoYW5rIHlvdSBmb3IgcHJvdmlkaW5nIHlvdXIgaW5wdXQuDQo+DQo+ICAgIEkgZG8g aGF2ZSB0byBxdWVzdGlvbiB3aHkgdGhlIFdHIGlzIGVuZ2FnaW5nIGluIG5ldyB3b3JrLCB3aGVu IHRoZSB1cGRhdGVzIHRvIFRUTFMgYW5kIFBFQVAgYXJlIGxhbmd1aXNoaW5nLiAgVGhhdCBkb2N1 bWVudCBpcyBzbWFsbC4gIFRoZXJlJ3MgYmVlbiBwb3NpdGl2ZSBmZWVkYmFjay4gIFRoZXJlIGhh dmUgYmVlbiBvbmx5IG1pbm9yIGlzc3VlcyB3aGljaCBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRo ZSBtb3N0IHJlY2VudCB2ZXJzaW9uLg0KPg0KPiAgICBJIHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGJl IGFibGUgdG8gYWNjZXB0LCBsYXN0IGNhbGwsIGFuZCBwdWJsaXNoIHRoZSBkb2N1bWVudCBpbiBz aG9ydCBvcmRlci4NCg0KVGhlIGNoYWlycyBoYWQgYW4gZW1haWwgZGlzY3Vzc2lvbiB3aGljaCBo YWRuJ3QgY29uY2x1ZGVkLiBUaGUgbWFpbiANCnN0aWNraW5nIHBvaW50IHdhcyB0aGF0IGJvdGgg Sm9lIGFuZCBJIHByZWZlciBURUFQIGJlaW5nIGFkZHJlc3NlZCBpbiBhIA0Kc2VwYXJhdGUgdXBk YXRlIGRvY3VtZW50IHRoYXQgZml4ZXMgYWxsIG90aGVyIFRFQVAgZXJyYXRhIGFzIHdlbGwuIA0K SG93ZXZlciwgdGhpcyBjYW4gYmUgZGlzY3Vzc2VkIGFmdGVyIGFkb3B0aW9uLg0KDQpBIHdvcmtp bmcgZ3JvdXAgYWRvcHRpb24gY2FsbCBpcyBub3cgaXNzdWVkIGFuZCB3ZSBpbnRlbmQgdG8gbW92 ZSB0aGlzIA0KZG9jdW1lbnQgZm9yd2FyZCByYXBpZGx5Lg0KDQotLU1vaGl0DQoNCj4NCj4gICBB bGFuIERlS29rLg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBFbXUgbWFpbGluZyBsaXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0K From nobody Sun Apr 19 16:11:30 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A540E3A0891 for ; Sun, 19 Apr 2020 16:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 rx6xz-HeYWFW for ; Sun, 19 Apr 2020 16:11:27 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60064.outbound.protection.outlook.com [40.107.6.64]) (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 CA57C3A088F for ; Sun, 19 Apr 2020 16:11:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TsuawOdDU6XyS4nuyfQcF/YtSmtl8XHCnuqovUt8yu75okJeQ0tt5JRuw9Co31P/7SYwAylNzoxYgsPewwqR7YES2NJLOcBIbQZzOk37Gopnp7RnDW8GDPME3nK+OPbb1nkPD40cCad5TMQRI8/qZppbz1kOSTLUQR6LR4RHXtzF3OPETftMQRQ1c19guyfHkn2Jw8nvRs4nUYnFvNeZJ7VgHyC4aAiFakuGZZAe9a7F8PpmFhNUgsFABCdFcpmz64RGo+C4eSf9ZDpnSOBXtBKwZ8YrcVui15YpMGew7XqZUh0XfEUKJdhTMKb6zVpwzCW/fPX0BC3zwIa9xpuoRg== 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=NQnfWNlL7K+0xoTYQYzXcwlFw6WczsA3ejYXoi3O4a8=; b=BJ7VIGvQkqZqxWigx0+x982xB/+rKeA6/zI2ODR9Lq+zheIzf3IiKhojQFx2CGUUurgdQIfVQI337FP9RbRNkDedclaER9RpSEW2Eghfc9UJvdAM/NEXLyhBv7IdxXtAIR9PQ5ceff3VW2payJ8+WLLxhGponmgXNmAt40uJM3vN4uE0/3XeJaalHqNh5XfwWlcSTwPTMHFMkPt2SJsmdsaX1GBHJD6aZCalrHfGfpbItwlvinRZ03KU5Nu86NP5LmPUT1Xnjwq6LrqanDhSK97EjmmXbld5tKPbHyKCmgNL2TVIUw1SH8VtL3L9LSBdfnOOf6HHbUjZbLmn2GVInw== 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=NQnfWNlL7K+0xoTYQYzXcwlFw6WczsA3ejYXoi3O4a8=; b=RP/Te9yQhzaCn1Ua9c2LQUXsaLWKa3SXFKbxqDb8zgX8TSstQEx1VXQ131wz4KnsN0CXJh05306j6tvbbU5yjjezeEcsy5aMCRAv6+6v5qHKiVPK577Pf6W3YylVAglSiReNX+H1jWzGcRwGdwgPjrHfJdvxiWdqQPBmU/TwUEo= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2955.eurprd07.prod.outlook.com (10.168.92.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Sun, 19 Apr 2020 23:11:24 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.011; Sun, 19 Apr 2020 23:11:24 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: Poll for virtual interim Thread-Index: AQHWFp/Y4kHtRMPGXkK69hqFNrQSAA== Date: Sun, 19 Apr 2020 23:11:24 +0000 Message-ID: <008d10ab-8f20-429c-6319-692ddb2b9228@ericsson.com> 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:170:1fc7:3791:e56a:e85a:b86c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0142138c-ec76-4f76-4368-08d7e4b6fb26 x-ms-traffictypediagnostic: HE1PR0701MB2955: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1850; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(66556008)(8676002)(66946007)(71200400001)(66446008)(6506007)(8936002)(31686004)(3480700007)(81156014)(66476007)(186003)(6512007)(64756008)(76116006)(6486002)(2906002)(36756003)(2616005)(4744005)(86362001)(966005)(478600001)(5660300002)(316002)(6916009)(31696002); DIR:OUT; SFP:1101; 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: fySoMWXkl4O6YbTOk3qGBcRngdndCXw/cey+ZS79Ml8gSiXPYxgX6EDqibVROZ1eshQje/UivOo/hye+Z/kRdnVgkKBwIe/30Qxzyd2hhpFFKDXeuDzaI4EWpEkWfsOivKyHBZ6fF+TAvObNohFWKeaKlJUQ+kbQJTBECE5h0NySdbSL7V/rVUN99oiKXQzroX/D5dAN/j0hQpfCkPOKE9FCZDSNm30RTc5tEhvX8MVS9wVRBN7ZR+UiOW6NV/04Y7iRa9ZIvPi4FFG8fVRVDUfJ+L2WRRr9kMJr3Oeoo97nKzXPXjwnkqi5BHsmsv2AzEwXxA8muWPme62xjcDkoUtm4WJ7IlYvN8wBJvKKLZlVp+cO5Zjjb90tyekgbLcCkJKSm1JPEb0GrGY++v/QrNAUzBPfHouIdrbx5IFGKTt9Yx3jcmHpxfU+2YDuDXtx1YfjpIsclVC+A82oyHRSzBNUkG/RWTPtlmehAzvDCHwuiGL3yfjFOPbEFWHhDMEORIBqKJumJaxF7GIL18mGRg== x-ms-exchange-antispam-messagedata: fzYVhsC/e641qiDGHQa5MTVHiTcKoinZNZeGLqCVV8KQEnwKNmT+FEygrLI7MWuZuC4hRIBk+KD9BZoSSg/jgRt6OLho+yUYptWImvGqXblfZLpXM9sPCN4P00UHrukhWV11NxkQWomny/zP47VoEQyXrnmPWDNJi4VslbfP1eg9xOfMdN+f+0N7yC5FSAdlzVFTIOaf8YXQpqvN9L3MaKmrC3zpOOnYn0QQ9aBjB3HSGI+ibzC1qYUMav9OqLH8uQTrQCmjWpA8+L/RCOdxgc1QWKPrYfzcQcUIz9G4+/NyVT7ahlFSBxyvANFaV8jtpMy1TII61oXCIeenOUMd7wbIILIsDrlhPH8GfGl01yti22OdYkcg7pdU0NidrZQK08vgcDyr7QP3yVFrLnOqDT9U7pBhzPDr4vD7yHJP+RsVRfaaGAmGuqPw7y1N/iyyigeZfU1j5LwHj4ygwc5cqNnyA34vRlfGXjkyCrug1EjB32z3gL51KwsN413sEjTbWSdkxfOcnzOYlwzIivcTbkIKjvF/Dj3urkU6Yw8vqecUlpq+uFC10+bsAVRwYBTXqGfAWnwtVumStRv1aLhPxonNiijffS/n/WilinmKV3jxT6icqkqS+05k/xyn86L71OPmW1Y2avcVSxkI4vPk3MVCEvaM6vvhnQtDa4MRk4dCjUB2NRSSzbrtkoxLSkQtTDiGsIehGxsydIx1vFj0pibQV/eUCElDn6UK9+g+3qVy8MwQRh39Q9DLDQBQBKULAziVL728lU7o/L+P+psex2xux43DoqIhqC62z8Ko1HhKI9NJG8o2AaxnOf53daxbAD8rTjVDF7PHXvm0YvBsWlNjWsggc291e3GxvD8Vk0Q= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <72E14B4726AF7C40A0C5C4BEDE47A3E0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0142138c-ec76-4f76-4368-08d7e4b6fb26 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 23:11:24.3484 (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: HWqasP05hfQec4oglqltWeJQQ+E/Qi+QxIR63JLtpzl1HvIs/1gtD0v2h+uv2GGpjoDQLB9Tk0HCKTEjmqMIbOFeGlAI5+ccjyBK1KqDHqk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2955 Archived-At: Subject: [Emu] Poll for virtual interim 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, 19 Apr 2020 23:11:29 -0000 RGVhciBhbGwsDQoNCldlIGRpZCBub3QgaGF2ZSBhIGZhY2UtdG8tZmFjZSBtZWV0aW5nIGluIFZh bmNvdXZlciBmb3IgSUVURiAxMDcuIEF0IA0KdGhpcyBwb2ludCwgdGhlIElFVEYgMTA4IG1lZXRp bmcgaW4gTWFkcmlkIGlzIGFsc28gdW5jZXJ0YWluLg0KDQpXZSBhcmUgdGhlcmVmb3JlIGNvbnNp ZGVyaW5nIGEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgZm9yIEVNVSBkdXJpbmcgDQptaWRkbGUv ZW5kIG9mIE1heSAyMDIwLiBIZXJlIGFyZSBzb21lIHByb3Bvc2VkIGRhdGVzIGFuZCB0aW1lIHNs b3RzOg0KaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvdnh5NXZjNGczY25lZ3Bkcg0KDQpQbGVhc2Ug aW5kaWNhdGUgeW91ciBhdmFpbGFiaWxpdHkhDQoNCkpvZSBhbmQgTW9oaXQNCg0K From nobody Sun Apr 19 17:33:15 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768B23A0A8D for ; Sun, 19 Apr 2020 17:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 a3iKGum8yiWH for ; Sun, 19 Apr 2020 17:33:10 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eaa::71c]) (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 EB1883A0A8C for ; Sun, 19 Apr 2020 17:33:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dkS3joIk8iV99vu2j/DjWUiUOOaaAG9y3sWnsdBELjaWKSV82wkdx/a9zj5GretBl3ChdK6ezWtKmvY4fm1GHajwu2u7QXCiM+LWPJRCT3UXcJBe2aqLkmsiaWNg+tlByrHpiQwSB4Fa2kiMl+OO8yQKriLhABCZ8vyccgD8Kx7dhwnB8mq59iaznN03WozMP2hNOSzHj7lxZqHG7/flQvvC5FwiO+8XfsaAyRM43i3eJF4rAixLxsIoJCtsCsdhahLdvOOpCos4SInim93b0myzMMl/bGCFNsmCCqWAca0KtWWUapW/vTtfpAAsRv4kKepHO1X8LYi+Xpr1YZMyew== 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=OVx4Ff/FALcCWWntrAi/Q2NmlvCWDHSOwe5ehPS4ZLE=; b=iDCPa7rf5u5MgZyWEmFD+XoPAZOm3AC+LKVgPQrmN42RGahH37nKpoob0rDB3S/U0//IWFKQbunHBmGEIiXM+hchi9paCDPpTJQBnyjUPoF7iA5rgIaO+O1g1AZ7Gf2gZokZskPZDmMVZdrSckW9+YWQrzgFfse/Z9BzN+ZRVxtG/B21CvqLDdgkY+eSQvGcjUWuHBRCbcwKvABqrxhf2R8xnUA8aIcSHI8+DpKFDTbD94jgu72H6IjKeeVS51mdbxOkp1NghkToE+xBR2ImQ/DrasYzaLYH1B8PBiGxvPF6rjZchy7Fvt9562EmDhylpYnLmEHuAvNeG302APoO8w== 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=OVx4Ff/FALcCWWntrAi/Q2NmlvCWDHSOwe5ehPS4ZLE=; b=eV9yNmtQgY2ljzfHKnA8NEtxCQ9//6zH8XKVjqKebsnzlKfHC4bBe8/gdoV2OlLb11cs7qmNksHTSjHPeX+yzKk+M8y2M2zBe99ZkLbMOcrJC8RqxyS1Rftd/n1OAGgQ1msttw8ms4rTOKR7MMqiuIyQNpU24js6t+CCzGjLVMU= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1510.namprd21.prod.outlook.com (2603:10b6:610:8e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.3; Mon, 20 Apr 2020 00:33:08 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703%5]) with mapi id 15.20.2958.001; Mon, 20 Apr 2020 00:33:08 +0000 From: Jorge Vergara To: Alan DeKok CC: EMU WG Thread-Topic: [Emu] draft-dekok-emu-tls-eap-types discussion Thread-Index: AQHWCflAito/q8SdbkqYuDgLHK2lQ6huIjRAgBKV0gCAAIhtcA== Date: Mon, 20 Apr 2020 00:33:08 +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=2020-04-20T00:33:07.3393159Z; 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=e803c9aa-1844-4713-a7f3-f803a7d11019; 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: [2001:4898:80e8:0:a4a2:311e:3dd8:d3e1] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ae621537-08a5-43e2-d117-08d7e4c2661e x-ms-traffictypediagnostic: CH2PR21MB1510: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03793408BA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(366004)(376002)(39860400002)(396003)(5660300002)(7696005)(6916009)(86362001)(186003)(71200400001)(2906002)(316002)(6506007)(53546011)(10290500003)(82950400001)(82960400001)(8990500004)(478600001)(66946007)(66446008)(66476007)(66556008)(64756008)(76116006)(966005)(52536014)(81156014)(8936002)(8676002)(4326008)(33656002)(55016002)(9686003); DIR:OUT; SFP:1102; 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: GQpeu8Oa00l3YPGB119tObvDiAbmvAenqxSHnWZJsyw1V5kVMcI+gS7Wy9KvK52kkDxNHMJ+EEpSF6xHF2RfTGDHQNiD5JF0Xu/Qz0+oCHF7HS9un4T8I/ocPZByGeTP3eNwGw2T7I9FRJkrpU5Tgomj8PrwZbEklQgeOGCZJo+3W2aNJRXwyFynoi4PitfAncLAqmLPwoEpT1fKBvKb7p7d3tjISBCJBjFdzLh2FImpbd0yoa2MCUm1wE8emjuLYA5HC5Uss5Kor+puuEjHbKPo6BEwQFm3ldj+4k2BQocOWRdrxXwSURgZkKMaR3a2mFPQ/KrQqmLMxh0cSYzcM0u0CitKEt4ZscgLBIK8XDpfPW8F4ASzXSCFYu/w6mRcdAfWV0mmCZ6ySWWQpUdb/hgqg0SorU2ElXNqzlcPok6IJ9WSXAP2WvB/N48dVinj/5l15A/y8EyXnDS2WHQ5TqlRD5WYqatgkNF7WTO5x9nuLmAZxpH3QtaSpv8pryH7iw4te+CDjxS9wGoE57y3OQ== x-ms-exchange-antispam-messagedata: V8+UGgRpq+puUtEB0X+rxYObG2KwWYlw1y6miEKhYut2bjZ5kqAudJkm26AhECsPq3BqftyErS3z6GIuD+ANgPz5rL6zY2UNmq3n6jFVWOv7VdJqW+pkEwjXCTE0QPEVXkCqI3M62e6vkDxhR5JQndWCs7Rh0rB6/TTTL3j9f0mUoYmJ9ni0NL43HtveinNzD0EenzearoloqtRV93XqosyoUPCA6SiJO1qCv1j/xIs0qg9GH1HIfWIv2KwrHbillnQCjEImr1bP9lF1N0r2N44JJ3dXD2PrWgZS/MoOB6L/xHz7SDYlTObl6n0a/xDov1FS6iPNl/WPvob74T95CfTSfEYb2bgvNcNuWx/NNBEgD/rzX9WgwHUJHwl0i/pJqOO9huypNSbs5MLVOxnqsbIKA19j2iiIYGxrtjlZ6e0C6diA4/aoFE11u14LMKlhexL1rijPkfYoJWg03dBntV41V0HyQxHSHzJimHG9rQaWuQO2bfDhcJQ2uNIxJxvfy68VjZXUmUHkMuZ4K+bdCZJFu5BNUrz79C3xnI73c9bvRqOuf54IvqUpvd234VQj6DhEiVvCJ5LRtw5naVQk0GWCWs8ttQMy+z1ACm3oe+whUzXYuqnLEbY4WUEaXJRLK3/HRINKxBB6VE7p319IffHbw+IFx1lNw51vl1RJ6rkzc/0PzF94chANxk5Uq1wzvYahq+QMbxBMVxPq2FZjioz2aDuyHx42kl46A7ripq8d8ztcQN0ONsG8ZCiggmS60uJ07tM3vkmWZA+MhSz2b+ERhQ8hgoWH0+SvPiq6RhQI2Xy4BfgfcJJIdjMelk81Wk5KXedQ6NGCIq2xFlm486uVQbrBO13J4+qKqxqchVM= 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: ae621537-08a5-43e2-d117-08d7e4c2661e X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 00:33:08.2725 (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: 8PZ3mV5c+Swv1ZXu3Kj9m1QOtGioYmhxh8rLKv5VOqr5fJ+U1B9mabEmxB3JTxLPggEpSGxxYZY5Xkbh7qULYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1510 Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 20 Apr 2020 00:33:12 -0000 Apologies for a second round of feedback after some more time reviewing the= document contents. Section 3 of the document describes how tunneled methods should the possibi= lity of Post-Handshake messages in TLS 1.3. As discussed on this mail threa= d: https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo/ it is possible for the methods in this discussion to skip the phase 2 "tunn= el" completely. Thus it seems that a similar approach as is being taken for= EAP-TLS would be needed here, since there may be no application data excha= nged after the TLS handshake completes. Jorge Vergara -----Original Message----- From: Alan DeKok =20 Sent: Sunday, April 19, 2020 9:17 AM To: Jorge Vergara Cc: EMU WG Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion On Apr 7, 2020, at 5:09 PM, Jorge Vergara wrote: > On the document contents themselves, I have this review: The key derivati= on proposed for TEAP/FAST uses the definition from FAST, which is not ident= ical to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, bu= t TEAP uses IMSK[j], which may be equivalent in some cases, but may not in = others where the inner method exports an EMSK. >=20 > Specifically, I believe this line of section 2.2 should change from > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound=20 > Keys", S-IMCK[j-1] | MSK[j], 60) To > IMCK[j] =3D TLS-Exporter("EXPORTER: Inner Methods Compound=20 > Keys", S-IMCK[j-1] | IMSK[j], 60) For TEAP. I've made the change, thanks. Alan DeKok. From nobody Sun Apr 19 17:58:00 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE76B3A0B10 for ; Sun, 19 Apr 2020 17:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 Lhdl7GLmguCo for ; Sun, 19 Apr 2020 17:57:57 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2090.outbound.protection.outlook.com [40.107.94.90]) (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 278B03A0B0F for ; Sun, 19 Apr 2020 17:57:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eWLYMPUSPyyPjZtZ3xQLRAi1LfNyCUKLgY6NTay3cdIm2ZT4TzafrexatkoO4oAqcCG/O5y6CzTLgi4vZ3wZ7udRNknJJaIMbBjiYaE3UrBu16nOOMqmSrBQT8oftpSD9ACkM10Ab3hnEAMEmO6fC49WodzWPfmcB11DIzqLNTQrx3CpkWCESRxAkvHU5RKI67V5bhg5PKe9kul+xtVR3yKK9nN5ql2NdaH2Kcnp5h2MyTbHHe1W1ytlyHalRFbzw1FaAhcpwuf49rjrNDSNSboYm5HTBokYRrmlMxgpzKjHRpiMy5ADrXn/4j24y7ca1WUBPl8osIWYS0V4p3ub0A== 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=CdeW48wfu/71tgQ60lC2MjdTMligT3yUC8tkTblJigo=; b=JYGhfpz46njonfdHvpfYnVp3m9i3+jTTxurC4NhuWt+orL327qG5OYFrCdIGYubHNuoIJBDrylZWTokeR/sC2wCeBdEGJdta4UnV24DSTJ7moF9XsPUESQOOUlfP7u3bouIXbHXeINSh0EIJYAZIlwb31hx+yZN9Qz/xduCCWHXXjFphLVNWVdU06fzsnYAF3rJnMpuJTz9VAgwxpRb14vwOXVcv6m+4ZWF9EK7D29XlqL3NcmIOu3/ITEC8ef3vTOIBaerEEigpUNShqrLRxkGiz+bo2ZIGB1J/URWTA+t8tV1qlGfyQMOSoeNcKpvr5RkCjjKFJdjglVCX2hOr6g== 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=CdeW48wfu/71tgQ60lC2MjdTMligT3yUC8tkTblJigo=; b=CvDzeqnyCIehj6/QLW/8mmj3KR6fB1QmVY1OlIgH3Pj3GIX/g2wsFst6Cng2PAM3Wf5+jt0RQlQEJ0WyvQzFwl73ylv7LUMuVqZE6oELSA0rtphPDMlWMC9P0L7iZzfwoCzUXL6Zf4NLmNJsosd+M8rYdRRttVNklVsZHOXaels= Received: from CH2PR21MB1381.namprd21.prod.outlook.com (2603:10b6:610:8e::12) by CH2PR21MB1494.namprd21.prod.outlook.com (2603:10b6:610:88::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.4; Mon, 20 Apr 2020 00:57:55 +0000 Received: from CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703]) by CH2PR21MB1381.namprd21.prod.outlook.com ([fe80::f103:7a83:b489:b703%5]) with mapi id 15.20.2958.001; Mon, 20 Apr 2020 00:57:55 +0000 From: Jorge Vergara To: Jouni Malinen , Oleg Pekar CC: EMU WG Thread-Topic: [Emu] draft-dekok-emu-tls-eap-types discussion Thread-Index: AQHWCflAito/q8SdbkqYuDgLHK2lQ6huIjRAgAxOtACAAS2kgIAFpVSw Date: Mon, 20 Apr 2020 00:57:54 +0000 Message-ID: References: <20200416102445.GA8757@w1.fi> In-Reply-To: <20200416102445.GA8757@w1.fi> 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=2020-04-20T00:57:53.6935851Z; 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=4317364b-5b1f-4d50-98e6-e63a6d464302; 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: [2001:4898:80e8:0:a4a2:311e:3dd8:d3e1] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1cbdb016-3282-443e-c738-08d7e4c5dc46 x-ms-traffictypediagnostic: CH2PR21MB1494: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03793408BA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR21MB1381.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(396003)(366004)(346002)(136003)(33656002)(82950400001)(71200400001)(76116006)(8990500004)(82960400001)(53546011)(4326008)(52536014)(9686003)(66946007)(66446008)(316002)(66556008)(55016002)(64756008)(7696005)(6506007)(86362001)(66476007)(2906002)(8676002)(8936002)(5660300002)(10290500003)(186003)(478600001)(110136005)(81156014)(781001); DIR:OUT; SFP:1102; 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: F3V1kFvNjGA7YOUBwvx0Aai4D+skN7tCr277KpGTpA90aoRTr+sKdtGufWsXiMX7RwjI2Pufmb7m0bwkPFDmgFiEevxaekb6bY9RWWRE7LvjtGnT+FW1LlllLyYa9sqiRWjmtTjZaHhd89aqzzxA6sSKAci7I8/f+0QNEnyGFsjDxwjEI+fdaqm2VER9Cxxd8uvC/T5jHbF741mNFSYc2ZKkwW7xjpM+wBi5F5LVGEW39kPqjOfjsgs+aNGvecdj1BJeh6Dp8NNRyMIdAkO/lfGeq9FA1pDAJsih8Uz3/nH/NFcpzdCXrWltChVOD0paoV0gWbgM+EaIe8/vAIwMqTOelbvWx26Q/OGVyAMO8iQiuS3zDBA6Kv6UZVMo67Gw27LDFaCuwHcssTMczYyr6i23YEYnUxDOQ4JbqYCgmAJh4BZKV6oO55LMmtWS4kO/HgCABraRaDjt8VCrhzXTsf7XqMxj46wOpJSseLoCdK8= x-ms-exchange-antispam-messagedata: f6ydkju7vG6/KKW3mld0LSQwUFwJkY3hMrv+WeRFMt7icTXG+/V9JNk3+JD0MyPJ6CPcW+AUUhRCOCDQECFzA+5P2hQjKe1oMOhtxAZ+octXcv5jHf/rDdDwlLzSCliJpZpiW5vd02rM5BsTXyMbBAqC48O6W/v6Ah5/IUemfKFc8mRp0DY33ZtrUe/VJU39NamW97+jgSxKvPffOSJGZcMHdNn7dXJEKoXF8sz2aQAV4zkqAR5/7Bcf3bxslAxAHAAy7U4qJrQ++EwCIDBGlxlpQfqyljOjGiCh6e44xI4rVAA0NLmXm8/Lw63t+N0wWSWoWuhA9bjbOLYxHmmC13AS7yG2i8Ku4axnOHTpaH6q+qxtBKfnXru9Y/ncK/JaoQZdMTgL1r/787x6Qsnkv5uCdYlYjbQiztfNUUYjgFgHDADJCOrIPLCRif10JaJ51VAhtfkLCd4ABdTnnKQmQpHyVgOM1p5Zf7b2AB3ptL1yvlaDlOsrI92J6Q+AfXaqj8EonXpSESJ3+mqJ7xJ2ublS6v8N0qGRPBgN8dGEXitB37ZrkG4L4CBx9SyiOCnMbzw3HHqYCoMD+BkMXuC6WizoPMcRFX48EOrzlMnGW8gEELUVnXcO3t3RrgMiHkUMKcg/p1/Y/h84wPiJWohR4awHz9VKHiMBn8UZOFfvfGtMOB+qxRRytfjRUavdu71j26OCRlvLZDRTq0uQgOEe2u9zm4F0qcz3VUzXzhg7FoMJOH+zmJaFbqhbwOMVstU0u8fjFvg+vzIkPxh4y16OPmsAgEZxrmzAFRdNg6GltyWaExqFDYI6cED97eB+EL0uuem+tlUchVCT1Kh/5nkzPatBCRWK/TNsbSJvuqU+vjc= 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: 1cbdb016-3282-443e-c738-08d7e4c5dc46 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 00:57:54.9898 (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: 11NRRb3WUc/KUIhLr08OjcbON3WWPodIEJrWEdRAXHwYzJ+mKDfq3Yc0amdrpp2Kllv+lOq8uEhHwsFeiQOHSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR21MB1494 Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 20 Apr 2020 00:57:59 -0000 >And focusing on that "what to do here.." part and the unused IMCK-zero[j] = in the previous paragraph.. >How is this supposed to work when an inner EAP authentication method does = not derive either MSK or EMSK? >Intermediate result indication of success needs to be done and that implie= s there needs to be Crypto-Binding TLV. >But that TLV does not have option of indicating that neither EMSK Compound= MAC nor MSK Compound MAC are present (Flags field has no value 0 defined t= o do so). I agree the 0 value should be explicitly listed for this purpose. Given the= design of the flags I think it is clear this was the intended usage and it= s omission was likely an oversight. >So what are those fields (or one of them) supposed to be set to? >And how is that selected for an inner EAP authentication method j? >Does this depends on what happened with method j-1 (if one was present)? >How would the correct IMCK[j] be determined by the peer and the server if = one of them derived MSK/EMSK but the other one did not derive either for in= ner EAP method j? Assuming we use the value 0 to indicate the state where one of the peers di= d not derive either MSK or EMSK, then I believe the RFC addresses this as M= SKi =3D 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,= and both sides decided to continue the conversion, then both sides would u= se the zero-MSK for that IMSK[j],=20 Jorge Vergara -----Original Message----- From: Jouni Malinen =20 Sent: Thursday, April 16, 2020 3:25 AM To: Oleg Pekar Cc: Jorge Vergara ; EMU WG Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: > For TEAP errata 5770: > Technically TEAP RFC suggests the implicit method of taking the=20 > correct IMSK[j] and all the subsequent keys after each inner method=20 > via negotiation taking place in Crypto-Binding TLV exchange. What is "the correct IMSK[j]" and where is this defined? > Let's say we are on the inner method number j that supports both MSK=20 > and EMSK and we are server which implementation generates both MSK and=20 > EMSK for this inner method. We generated keys according to the rules=20 > below - two sets, for IMSK[j] derived from inner method EMSK and for=20 > IMSK[j] equal to inner method MSK. Because we don't know whether=20 > client implementation supports both MSK and EMSK. >=20 > S-IMCK[0] =3D session_key_seed > For j =3D 1 to n-1 do > IMCK[j] =3D TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys"= , > IMSK[j], 60) > S-IMCK[j] =3D first 40 octets of IMCK[j] > CMK[j] =3D last 20 octets of IMCK[j] >=20 >=20 > So we have two CMK[j] and we create Crypto-Binding TLV with both=20 > Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in=20 > response and we can understand from it whether it supports EMSK for=20 > this inner method or not. And here we can decide which version of=20 > IMCK[j] to take for this inner method - derived from EMSK or MSK. This=20 > is just not explicitly specified in the RFC. Is this the proposed definition of "the correct IMSK[J]"? In other words, i= s this to be understood to have two (or three since we have the no MSK/EMSK= case as well) variants of IMSK[j] during an execution of an internal AP au= thentication method and a single one of those variants is selected as _the = correct_ IMSK[j] at the successful conclusion of this inner authentication = method? Would this single "correct IMSK[j]" then be used for deriving the different= variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when deriving EM= SK-based-IMSK[j+1]? In other words, is this to work by having all following= inner authentication rounds and MSK/EMSK derivation to behave as if the ot= her variants of IMSK[j] never really existed? > Could this method work? Should we make it more clearly specified? Or=20 > should we change the protocol to arrive explicitly to the=20 > understanding which type > (MSK/EMSK) of IMSK[j] to use? Regardless of what is done for the design, it will absolutely need to be sp= ecified more clearly. If I understood the proposed design correctly, this should be defined with = something like following: For each successful inner EAP authentication method, derive IMCK-MSK[j] (if= MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was der= ived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-= MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if availab= le). Generate Crypto-Binding TLV with all available Compound MAC values. Al= so verify Crypto-Binding TLV with all available Compound MAC values. After = both ends have transmitted and received Crypto-Binding TLV, set IMSK[j] to = be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j] to = be IMCK-MSK[j] if both ends included MSK Compound MAC but either end did no= t include EMSK Compound MAC, or .= Set S-IMCK[j] based on this IMSK[j]. This results in there being only a si= ngle S-IMCK[j] and MSK/EMSK derivation being well defined. And focusing on that "what to do here.." part and the unused IMCK-zero[j] i= n the previous paragraph.. How is this supposed to work when an inner EAP a= uthentication method does not derive either MSK or EMSK? Intermediate resul= t indication of success needs to be done and that implies there needs to be= Crypto-Binding TLV. But that TLV does not have option of indicating that n= either EMSK Compound MAC nor MSK Compound MAC are present (Flags field has = no value 0 defined to do so). So what are those fields (or one of them) supposed to be set to? And how is= that selected for an inner EAP authentication method j? Does this depends = on what happened with method j-1 (if one was present)? How would the correc= t IMCK[j] be determined by the peer and the server if one of them derived M= SK/EMSK but the other one did not derive either for inner EAP method j? --=20 Jouni Malinen PGP id EFC895FA From nobody Mon Apr 20 05:20:33 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E034A3A0C12 for ; Mon, 20 Apr 2020 05:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=maxcrone.org 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 0sTBkhb2aD-l for ; Mon, 20 Apr 2020 05:20:26 -0700 (PDT) Received: from qrelay216.mxroute.com (qrelay216.mxroute.com [172.82.139.216]) (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 2F4F33A0860 for ; Mon, 20 Apr 2020 05:10:30 -0700 (PDT) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay216.mxroute.com (ZoneMTA) with ESMTPA id 171977f2bd80000d83.001 for ; Mon, 20 Apr 2020 12:10:26 +0000 X-Zone-Loop: d9b8639cd36be62125bd50ce5e569a27a205883a6bb7 X-Originating-IP: [149.28.56.236] Received: from ghost.mxroute.com (ghost.mxroute.com [138.201.205.224]) by filter004.mxroute.com (Postfix) with ESMTPS id 5245C3E993; Mon, 20 Apr 2020 12:10:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=maxcrone.org; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iVQEXrAY21Wz20XOVDs12Nzx3snOQbmncNNdXg4kfbI=; b=zOMlvxWzYKLRhW3evjfRa83Zum VlOEA+9VSBUEcj2yhu1QBEhA5ceY8kEiBSAFx1fKFAgXijRzZslO286OtI4R9rB6q4Je7MgwLZMJP QC7gF+XwP9sPnyBxdeLIVu+sPGcCfAMnv0DZDZwplOXIPeaEhdVCNGBg/K9oGh1EeYupL3GbkA8+6 Q4Vg3pCa+llqW9Ma02B48yi1LiBkgPuPaYMivQ65WPCL1Qg7dnBGY1DPgxW9tH6euBiO1/bxSSrSZ vmEohrCMdIwWDGt0QdkvJQzkh4+1/HIyypIpqVG883d09p8QpWxt8gh2fcSKJNGsVr513YZNnOTM4 z0BvSbyQ==; To: joe@salowey.net, emu@ietf.org References: From: Max Crone Message-ID: Date: Mon, 20 Apr 2020 15:10:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AuthUser: max@maxcrone.org Archived-At: Subject: Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 20 Apr 2020 12:20:32 -0000 WG adoption has my support. I recently reviewed the document [1] and besides a few editorial suggestions I did not identify significant shortcomings. Currently, I am working on a minimal implementation of EAP-NOOB. ~Max Crone [1] https://mailarchive.ietf.org/arch/msg/emu/v21Os2-oLpSPqmwpqlaAgHa0Cnk/ On 18-04-2020 23:13, Joseph Salowey wrote: > This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a > working group item.  This draft has been discussed in several IETF > meetings and would be the starting point for the working group > deliverable for an EAP method based on "mutual authentication between a > peer and a server that is based on an out-of-band channel."  Please > review the draft and indicate whether you support adoption or not by May > 4, 2020. > Thanks, > > Joe > > [1] https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From nobody Tue Apr 21 11:01:54 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625E73A08EA for ; Tue, 21 Apr 2020 11:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=gmail.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 vrclo3n2wKbX for ; Tue, 21 Apr 2020 11:01:37 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 0FCCA3A08E9 for ; Tue, 21 Apr 2020 11:01:21 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id c3so11897131otp.8 for ; Tue, 21 Apr 2020 11:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2diGEwJU+Z8+YtGPJYd+ZwfWZJNgbLiQGgXwrz9dF7o=; b=K8moNCwvuWAu5a2NcHg553D8F4c1V+zikOhWlzRTY7K7geUFLnN1IJt/NELLyuM+F0 YpHovUxNJ9smNZHb12yc33uJ7ONT4Hivy3IcZlvuIwk6z6f19Ygcj8vUHTkzaThP1sK6 LwveJGZg5GjDuARfA02ubl0OhQVS4iZB4sCkuTo25x7IN6CSeIRikSIdUmFGv+5UX4Kh T7HOOP3z1Bh4Yk4W1T1KelLhKmtl9DeTXDpaek725r7xf72ddAXpWnR8LHXBWFRUpYSq DBlxnhRmDT+dt8TPPSGJcOEBfbrqt9Acr4ka2X4pd5u+pmTZmfSdJnXtRlttQKTkotVB SPag== 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=2diGEwJU+Z8+YtGPJYd+ZwfWZJNgbLiQGgXwrz9dF7o=; b=aVo3Alcv9WnJqfjtU0usOGGkYdELx7BK4UM/4sAZdB+ACxVmTuodRSXYKe+WgRtUoX Uwai++oCtMBSdfRULkqTANWVrnH/LtIDUj7udavGK9bJPAQNpdfPyhGUAXh5QaHubdNZ 4ZAYDBylHlSurw6qqWLgBYt0UfIjXk6MKW3oHcCyZgpVp0rLhkxRacG1ex4344q1fDRI r612I+oArOPG4VRHjr60wJ0N/ahS3YZc+I8IKJl4hIbxYNownqRbaDt3oSEZc2WaRTeN nd1VJfSQd1Yu1M2fliVAH68ruin0R1mZUU3dkklAeJqiE8ugQly2eXlCJsNS1+xbhQ5+ AYbw== X-Gm-Message-State: AGi0PuZYbDFYs3eAxQrwArOQnVF5BOGejd1gcWv9lpzJtAoKxDQK0HWG IUx4InBGVDjSZsKWQnTfupPLxwRY4VANtNhgxwIaL6DY X-Google-Smtp-Source: APiQypJV2chy44pGbkatWhhKy5lga4GnWFw5PEOajx2Vv8iGE1GRt5harFA6h8WDOh5lpGhNmHwghk0mHnwk37txuwE= X-Received: by 2002:a05:6830:1e43:: with SMTP id e3mr9369483otj.248.1587492080454; Tue, 21 Apr 2020 11:01:20 -0700 (PDT) MIME-Version: 1.0 References: <20200416102445.GA8757@w1.fi> In-Reply-To: From: Oleg Pekar Date: Tue, 21 Apr 2020 21:01:08 +0300 Message-ID: To: Jorge Vergara , Jouni Malinen Cc: EMU WG Content-Type: multipart/alternative; boundary="0000000000008a155d05a3d0cdac" Archived-At: Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion 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, 21 Apr 2020 18:01:40 -0000 --0000000000008a155d05a3d0cdac Content-Type: text/plain; charset="UTF-8" > > >And focusing on that "what to do here.." part and the unused IMCK-zero[j] > in the previous paragraph.. > >How is this supposed to work when an inner EAP authentication method does > not derive either MSK or EMSK? > >Intermediate result indication of success needs to be done and that > implies there needs to be Crypto-Binding TLV. > >But that TLV does not have option of indicating that neither EMSK > Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 > defined to do so). > I agree the 0 value should be explicitly listed for this purpose. Given > the design of the flags I think it is clear this was the intended usage and > its omission was likely an oversight. > >So what are those fields (or one of them) supposed to be set to? > >And how is that selected for an inner EAP authentication method j? > >Does this depends on what happened with method j-1 (if one was present)? > >How would the correct IMCK[j] be determined by the peer and the server if > one of them derived MSK/EMSK but the other one did not derive either for > inner EAP method j? > Assuming we use the value 0 to indicate the state where one of the peers > did not derive either MSK or EMSK, then I believe the RFC addresses this as > MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, > and both sides decided to continue the conversion, then both sides would > use the zero-MSK for that IMSK[j], > Jorge, Jouni, agree with the approach. Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV as specified in its documentation - when one side has an inner method that provided MSK and another side has this inner method that didn't provide MSK. There is also a case where no inner method is executed. For example, when client certificate was received during TEAP outer tunnel establishment. In this case we also need to use zero-MSK. For such case both values of the flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary ambiguity and thus would be better to request using flag's value "0" for zero MSK in such case (today we use value "2" and it doesn't create ambiguity). However there's a question here: in case of TEAP certificate based authentication that is typically done by running inner method EAP-TLS, should we allow in sending client certificate during TEAP tunnel establishment or inside the tunnel and this way skipping EAP-TLS inner method? On one hand it makes authentication shorter. On the other hand it causes switching from MSK/EMSK exported by the inner method EAP-TLS to zero-MSK. If we do allow skipping any inner method then we need explicitly say that zero-MSK should be used in such case. I've started rebuilding section "5.2 . Intermediate Compound Key Derivations" of the RFC according to the proposal on this thread and will post it here shortly. ~ Oleg On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara wrote: > >And focusing on that "what to do here.." part and the unused IMCK-zero[j] > in the previous paragraph.. > >How is this supposed to work when an inner EAP authentication method does > not derive either MSK or EMSK? > >Intermediate result indication of success needs to be done and that > implies there needs to be Crypto-Binding TLV. > >But that TLV does not have option of indicating that neither EMSK > Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 > defined to do so). > > I agree the 0 value should be explicitly listed for this purpose. Given > the design of the flags I think it is clear this was the intended usage and > its omission was likely an oversight. > > >So what are those fields (or one of them) supposed to be set to? > >And how is that selected for an inner EAP authentication method j? > >Does this depends on what happened with method j-1 (if one was present)? > >How would the correct IMCK[j] be determined by the peer and the server if > one of them derived MSK/EMSK but the other one did not derive either for > inner EAP method j? > > Assuming we use the value 0 to indicate the state where one of the peers > did not derive either MSK or EMSK, then I believe the RFC addresses this as > MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, > and both sides decided to continue the conversion, then both sides would > use the zero-MSK for that IMSK[j], > > Jorge Vergara > > -----Original Message----- > From: Jouni Malinen > Sent: Thursday, April 16, 2020 3:25 AM > To: Oleg Pekar > Cc: Jorge Vergara ; EMU WG > Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: > > For TEAP errata 5770: > > Technically TEAP RFC suggests the implicit method of taking the > > correct IMSK[j] and all the subsequent keys after each inner method > > via negotiation taking place in Crypto-Binding TLV exchange. > > What is "the correct IMSK[j]" and where is this defined? > > > Let's say we are on the inner method number j that supports both MSK > > and EMSK and we are server which implementation generates both MSK and > > EMSK for this inner method. We generated keys according to the rules > > below - two sets, for IMSK[j] derived from inner method EMSK and for > > IMSK[j] equal to inner method MSK. Because we don't know whether > > client implementation supports both MSK and EMSK. > > > > S-IMCK[0] = session_key_seed > > For j = 1 to n-1 do > > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", > > IMSK[j], 60) > > S-IMCK[j] = first 40 octets of IMCK[j] > > CMK[j] = last 20 octets of IMCK[j] > > > > > > So we have two CMK[j] and we create Crypto-Binding TLV with both > > Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in > > response and we can understand from it whether it supports EMSK for > > this inner method or not. And here we can decide which version of > > IMCK[j] to take for this inner method - derived from EMSK or MSK. This > > is just not explicitly specified in the RFC. > > Is this the proposed definition of "the correct IMSK[J]"? In other words, > is this to be understood to have two (or three since we have the no > MSK/EMSK case as well) variants of IMSK[j] during an execution of an > internal AP authentication method and a single one of those variants is > selected as _the correct_ IMSK[j] at the successful conclusion of this > inner authentication method? > > Would this single "correct IMSK[j]" then be used for deriving the > different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when > deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having > all following inner authentication rounds and MSK/EMSK derivation to behave > as if the other variants of IMSK[j] never really existed? > > > Could this method work? Should we make it more clearly specified? Or > > should we change the protocol to arrive explicitly to the > > understanding which type > > (MSK/EMSK) of IMSK[j] to use? > > Regardless of what is done for the design, it will absolutely need to be > specified more clearly. > > If I understood the proposed design correctly, this should be defined with > something like following: > > For each successful inner EAP authentication method, derive IMCK-MSK[j] > (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was > derived by the inner method), derive IMSK-zero[j] (for all cases). Derive > CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if > available). Generate Crypto-Binding TLV with all available Compound MAC > values. Also verify Crypto-Binding TLV with all available Compound MAC > values. After both ends have transmitted and received Crypto-Binding TLV, > set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or > set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but > either end did not include EMSK Compound MAC, or this even happen?>. Set S-IMCK[j] based on this IMSK[j]. This results in > there being only a single S-IMCK[j] and MSK/EMSK derivation being well > defined. > > And focusing on that "what to do here.." part and the unused IMCK-zero[j] > in the previous paragraph.. How is this supposed to work when an inner EAP > authentication method does not derive either MSK or EMSK? Intermediate > result indication of success needs to be done and that implies there needs > to be Crypto-Binding TLV. But that TLV does not have option of indicating > that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags > field has no value 0 defined to do so). > So what are those fields (or one of them) supposed to be set to? And how > is that selected for an inner EAP authentication method j? Does this > depends on what happened with method j-1 (if one was present)? How would > the correct IMCK[j] be determined by the peer and the server if one of them > derived MSK/EMSK but the other one did not derive either for inner EAP > method j? > > -- > Jouni Malinen PGP id EFC895FA > --0000000000008a155d05a3d0cdac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>And focusing o= n that "what to do here.." part and the unused IMCK-zero[j] in th= e previous paragraph..
>How is this supposed to work when an inner EAP authenticati= on method does not derive either MSK or EMSK?
>Intermediate result indication of su= ccess needs to be done and that implies there needs to be Crypto-Binding TL= V.
>But = that TLV does not have option of indicating that neither EMSK Compound MAC = nor MSK Compound MAC are present (Flags field has no value 0 defined to do = so).
I agree the 0 value should be explicitly listed for this purpose. Given th= e design of the flags I think it is clear this was the intended usage and i= ts omission was likely an oversight.
>So what are those fields (or one of them) supposed to be set to?>And how = is that selected for an inner EAP authentication method j?
>Does this depends on wh= at happened with method j-1 (if one was present)?
>How would the correct IMCK[j] be= determined by the peer and the server if one of them derived MSK/EMSK but = the other one did not derive either for inner EAP method j?
Assuming we use the= value 0 to indicate the state where one of the peers did not derive either= MSK or EMSK, then I believe the RFC addresses this as MSKi =3D 32 octets o= f 0x00s. So if one side calculated neither MSK nor EMSK, and both sides dec= ided to continue the conversion, then both sides would use the zero-MSK for= that IMSK[j],
Jorge, Jouni, agree with the a= pproach.=C2=A0

Jorge, please note that the same problem = exists in PEAP Crypto-Binding TLV as specified in its documentation - when one side has an inner method= that provided MSK and another=C2=A0side has this inner method that didn= 9;t provide MSK.=C2=A0

There is also a case where = no inner method is executed. For example, when client certificate was recei= ved during TEAP outer tunnel establishment. In this case we also need to us= e zero-MSK. For such case both values of the flag work - "0 for zero-M= SK" and "2 for MSK". This creates unnecessary ambiguity and = thus would be better to request using flag's value "0" for ze= ro MSK in such case=C2=A0(today we use value "2" and it doesn'= ;t create ambiguity). However there's a question here: in case of TEAP = certificate based authentication that is typically done by running inner me= thod EAP-TLS, should we allow in=C2=A0sending client certificate during TEA= P tunnel establishment or inside the tunnel and this way skipping EAP-TLS i= nner method? On one hand it makes authentication shorter. On the other hand= it causes switching from MSK/EMSK exported by the inner method EAP-TLS to = zero-MSK.

If we do allow skipping any inner method= then we need explicitly say that zero-MSK should be used in such case.

I've started=C2=A0rebuilding section "5.2. Intermediate Compound Key Derivations" of the RFC according to = the proposal on this thread=C2=A0and will post it here shortly.=C2= =A0

~ Oleg




On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara <jovergar@microsof= t.com> wrote:
>And focusing on that "what to do here.." part and the un= used IMCK-zero[j] in the previous paragraph..
>How is this supposed to work when an inner EAP authentication method do= es not derive either MSK or EMSK?
>Intermediate result indication of success needs to be done and that imp= lies there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating that neither EMSK Compo= und MAC nor MSK Compound MAC are present (Flags field has no value 0 define= d to do so).

I agree the 0 value should be explicitly listed for this purpose. Given the= design of the flags I think it is clear this was the intended usage and it= s omission was likely an oversight.

>So what are those fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentication method j?
>Does this depends on what happened with method j-1 (if one was present)= ?
>How would the correct IMCK[j] be determined by the peer and the server = if one of them derived MSK/EMSK but the other one did not derive either for= inner EAP method j?

Assuming we use the value 0 to indicate the state where one of the peers di= d not derive either MSK or EMSK, then I believe the RFC addresses this as M= SKi =3D 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK,= and both sides decided to continue the conversion, then both sides would u= se the zero-MSK for that IMSK[j],

Jorge Vergara

-----Original Message-----
From: Jouni Malinen <j@w1.f= i>
Sent: Thursday, April 16, 2020 3:25 AM
To: Oleg Pekar <oleg.pekar.2017@gmail.com>
Cc: Jorge Vergara <jovergar@microsoft.com>; EMU WG <emu@ietf.org>
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote:
> For TEAP errata 5770:
> Technically TEAP RFC suggests the implicit method of taking the
> correct IMSK[j] and all the subsequent keys after each inner method > via negotiation taking place in Crypto-Binding TLV exchange.

What is "the correct IMSK[j]" and where is this defined?

> Let's say we are on the inner method number j that supports both M= SK
> and EMSK and we are server which implementation generates both MSK and=
> EMSK for this inner method. We generated keys according to the rules <= br> > below - two sets, for IMSK[j] derived from inner method EMSK and for <= br> > IMSK[j] equal to inner method MSK. Because we don't know whether <= br> > client implementation supports both MSK and EMSK.
>
> S-IMCK[0] =3D session_key_seed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For j =3D 1 to n-1 do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IMCK[j] =3D TLS-PRF(S-IMCK[j-= 1], "Inner Methods Compound Keys",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IMSK[j], = 60)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S-IMCK[j] =3D first 40 octets= of IMCK[j]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CMK[j] =3D last 20 octets of = IMCK[j]
>
>
> So we have two CMK[j] and we create Crypto-Binding TLV with both
> Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in =
> response and we can understand from it whether it supports EMSK for > this inner method or not. And here we can decide which version of
> IMCK[j] to take for this inner method - derived from EMSK or MSK. This=
> is just not explicitly specified in the RFC.

Is this the proposed definition of "the correct IMSK[J]"? In othe= r words, is this to be understood to have two (or three since we have the n= o MSK/EMSK case as well) variants of IMSK[j] during an execution of an inte= rnal AP authentication method and a single one of those variants is selecte= d as _the correct_ IMSK[j] at the successful conclusion of this inner authe= ntication method?

Would this single "correct IMSK[j]" then be used for deriving the= different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when d= eriving EMSK-based-IMSK[j+1]? In other words, is this to work by having all= following inner authentication rounds and MSK/EMSK derivation to behave as= if the other variants of IMSK[j] never really existed?

> Could this method work? Should we make it more clearly specified? Or <= br> > should we change the protocol to arrive explicitly to the
> understanding which type
> (MSK/EMSK) of IMSK[j] to use?

Regardless of what is done for the design, it will absolutely need to be sp= ecified more clearly.

If I understood the proposed design correctly, this should be defined with = something like following:

For each successful inner EAP authentication method, derive IMCK-MSK[j] (if= MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was der= ived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-= MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if availab= le). Generate Crypto-Binding TLV with all available Compound MAC values. Al= so verify Crypto-Binding TLV with all available Compound MAC values. After = both ends have transmitted and received Crypto-Binding TLV, set IMSK[j] to = be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j] to = be IMCK-MSK[j] if both ends included MSK Compound MAC but either end did no= t include EMSK Compound MAC, or <what to do here or can this even happen= ?>. Set S-IMCK[j] based on this IMSK[j]. This results in there being onl= y a single S-IMCK[j] and MSK/EMSK derivation being well defined.

And focusing on that "what to do here.." part and the unused IMCK= -zero[j] in the previous paragraph.. How is this supposed to work when an i= nner EAP authentication method does not derive either MSK or EMSK? Intermed= iate result indication of success needs to be done and that implies there n= eeds to be Crypto-Binding TLV. But that TLV does not have option of indicat= ing that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags = field has no value 0 defined to do so).
So what are those fields (or one of them) supposed to be set to? And how is= that selected for an inner EAP authentication method j? Does this depends = on what happened with method j-1 (if one was present)? How would the correc= t IMCK[j] be determined by the peer and the server if one of them derived M= SK/EMSK but the other one did not derive either for inner EAP method j?

--
Jouni Malinen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 PGP id EFC895FA
--0000000000008a155d05a3d0cdac-- From nobody Wed Apr 22 00:51:52 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2D3A0A7E for ; Wed, 22 Apr 2020 00:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=openfortress.nl 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 YSkBjcxIMeoC for ; Wed, 22 Apr 2020 00:51:46 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 39E363A0A74 for ; Wed, 22 Apr 2020 00:51:45 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id RAAXjsHfAlKa1RAAYj5oaS; Wed, 22 Apr 2020 09:51:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587541901; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=BXkGs4yynABpMz3M7vJ2ZF9xFmbzecR+ymQcGmYfI7A=; b=p5DfMwo0QdNRkkTbros+g01F/Nvr6GVD2pcdAwjr7v/pRMIk0Br7IeKd IFqT5+lDp2E8HtmvRBatT/GBjwwx90ThmiJONRRJyW6tiAf2VLDi8eTECU 19QOvqlHIMJzvE/gYuF+wHHoVU5nDSVm17+eZPMRCGrbBWOvXtxbGcPKQ= Received: by fame.vanrein.org (Postfix, from userid 1006) id 34D373A44D; Wed, 22 Apr 2020 07:51:41 +0000 (UTC) X-Original-To: emu@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id A142F3A12B; Wed, 22 Apr 2020 07:51:39 +0000 (UTC) Message-ID: <5E9FF78A.7070605@openfortress.nl> Date: Wed, 22 Apr 2020 09:51:38 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Alan DeKok CC: EMU WG References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> <5E9B4165.1050703@openfortress.nl> <5E9B5B28.3000007@openfortress.nl> <53BB9E1C-58D4-454E-B77B-3FA4AFA89E15@deployingradius.com> In-Reply-To: <53BB9E1C-58D4-454E-B77B-3FA4AFA89E15@deployingradius.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfG9eAiWFvXiiw+Cz40KXDOAGlTrvITkbGMPPvtbG/h8XGnHv77Dt35l0Q92dB8zagMw8+3x6H1HbGoWjD5aJXoCgbfL4BLqOrs0OEIX4o6W50glj2qbe vh7pnDma/h/cbM52IokDfMeaIDYFg8amhNC8OKMW2oZpvB2UWZKX1X7O65B5X1aWxOIHGtJ8HzSq7A== Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 07:51:50 -0000 Hi Alan / EMU, I'll try to talk to Paul @ SURF about Diameter <--> RADIUS; he runs Eduroam and I think he has mentioned Diameter before. Our use case is completely new anyway, so we have a free choice. Good to hear that EAP-SASL sounds implementable. We haven't built it, but I usually "mentally program" the stuff while spec'ing. > The concern is that the document does not explain *who* would use this solution, or *why* they would use it. Or, why it would be used instead of existing EAP methods. I can add that, thanks for asking. There are WG's where I've been requested to remove such contextual aspects. > The ABFAB working group standardized precisely this many years ago. One implementation is Moonshot: > > https://www.jisc.ac.uk/rd/projects/moonshot I know about Moonshot, and that the project was abandoned. What it does iss the reverse; Moonshot runs EAP on top of GSS-API / SASL, whereas I am proposing SASL on top of EAP. > They demonstrated roaming users authenticating to home networks using EAP over AAA. Not just for network access, but for SSH, Web login, etc. It would be good to explain why ABFAB is not applicable to this problem. That is fair crisicism, and I will think it over for a new version. Thanks for the input, they are good input to a new version. I'll think about a few for a while, as that usually helps to better balance things. -Rick From nobody Wed Apr 22 02:29:10 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D193A0C66 for ; Wed, 22 Apr 2020 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=maxcrone.org 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 sTwu5ovFycE8 for ; Wed, 22 Apr 2020 02:29:08 -0700 (PDT) Received: from qrelay89.mxroute.com (qrelay89.mxroute.com [172.82.139.89]) (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 164F73A0C63 for ; Wed, 22 Apr 2020 02:29:07 -0700 (PDT) Received: from filter004.mxroute.com ([149.28.56.236] 149.28.56.236.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by qrelay89.mxroute.com (ZoneMTA) with ESMTPA id 171a138206d0000d83.001 for ; Wed, 22 Apr 2020 09:29:02 +0000 X-Zone-Loop: 937d0737640de70ed5fe4b88a2813beff41d87db59b0 X-Originating-IP: [149.28.56.236] Received: from ghost.mxroute.com (ghost.mxroute.com [138.201.205.224]) by filter004.mxroute.com (Postfix) with ESMTPS id 78D653EACE for ; Wed, 22 Apr 2020 09:29:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=maxcrone.org; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc: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=CmMfVkmymQDJmxUj4+TvAajBNBgEkxJDnI8hDBl1hhg=; b=c7NQrRmrZsju4XwKEvZGHtGgze h/yKWK5SStOBtOOWgc90YR8h0Mi8Uh2NFQ6X2Zun/CJQC8JayZ/191WnkeFi/QS81B4sFiKEr7aRa WJTn5m16pwVlDvnf+IeMhOJomdCuQIth4ShupTy4OWEba6+6LphhqcEppaGhzrqJ16ZcLa2qqhk2W vSGXCBfPTtEczkySB37OfcAaWe2DhWRg3YLb516BI3F61kZzHqpZuOF21/14MCTUAT/oyK+VejSvi vterEisbbBCBanjSDnMFJxcqb0l4bIHQQL6lLRDRfKPAp+Ls/fNmDoLk8CrlE7gTjGGbWk3QWLsj4 6EHTKu1w==; To: EMU WG From: Max Crone Message-ID: <3c0676c8-0810-4f70-4eb5-5d92abc35422@maxcrone.org> Date: Wed, 22 Apr 2020 12:29:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: max@maxcrone.org Archived-At: Subject: [Emu] draft-aura-eap-noob-08 NAI 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, 22 Apr 2020 09:29:10 -0000 While implementing EAP-NOOB, I found the explanation on the Invalid NAI (error code 1001) in the draft to be unclear. The document formulates it as follows: > If the NAI structure is invalid, the server SHOULD send the error > code 1001 to the peer. However, does this mean that the EAP-NOOB server should verify that the NAI follows the formal syntax as specified in RFC 7542, or should it verify that the NAI follows the specification of EAP-NOOB, i.e., it is of the form "noob@{eap-noob.net||RESERVED_DOMAIN}". I think this section could be formulated more clearly to address these concerns. On that note, Figure 2 seems to be incomplete. The EAP-Response/Identity specifies the NAI parameter to be "noob@eap-noob.net", while the specification also has the option of configuring this to a reserved domain. In that case, the NAI should not use the default realm anymore. Currently, this is not reflected in the figure. If anything remains unclear, I am open for discussion. ~Max Crone From nobody Wed Apr 22 11:56:50 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BD63A0B11 for ; Wed, 22 Apr 2020 11:56:48 -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 nlmPHACVSjWK for ; Wed, 22 Apr 2020 11:56:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0057A3A0B10 for ; Wed, 22 Apr 2020 11:56:46 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 22 Apr 2020 11:56:39 -0700 From: Jim Schaad To: 'Rick van Rein' , 'Alan DeKok' CC: 'EMU WG' References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> <5E9B4165.1050703@openfortress.nl> <5E9B5B28.3000007@openfortress.nl> <53BB9E1C-58D4-454E-B77B-3FA4AFA89E15@deployingradius.com> <5E9FF78A.7070605@openfortress.nl> In-Reply-To: <5E9FF78A.7070605@openfortress.nl> Date: Wed, 22 Apr 2020 11:56:38 -0700 Message-ID: <00c301d618d7$c257af50$47070df0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGvHEnmyLwykUcfc02VsFo4oR+4OgJ+3rb/AlaQIAQCJZOPTgH/uPJNAYprougBs4eGnqhxsUig Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 18:56:49 -0000 -----Original Message----- From: Emu On Behalf Of Rick van Rein Sent: Wednesday, April 22, 2020 12:52 AM To: Alan DeKok Cc: EMU WG Subject: Re: [Emu] Proposal: SASL over EAP Hi Alan / EMU, I'll try to talk to Paul @ SURF about Diameter <--> RADIUS; he runs Eduroam and I think he has mentioned Diameter before. Our use case is completely new anyway, so we have a free choice. Good to hear that EAP-SASL sounds implementable. We haven't built it, but I usually "mentally program" the stuff while spec'ing. > The concern is that the document does not explain *who* would use this solution, or *why* they would use it. Or, why it would be used instead of existing EAP methods. I can add that, thanks for asking. There are WG's where I've been requested to remove such contextual aspects. > The ABFAB working group standardized precisely this many years ago. One implementation is Moonshot: > > https://www.jisc.ac.uk/rd/projects/moonshot I know about Moonshot, and that the project was abandoned. What it does iss the reverse; Moonshot runs EAP on top of GSS-API / SASL, whereas I am proposing SASL on top of EAP. [JLS] I am a bit surprised at hearing this is abandoned given that they released an update of the software on the 20th of April > They demonstrated roaming users authenticating to home networks using EAP over AAA. Not just for network access, but for SSH, Web login, etc. It would be good to explain why ABFAB is not applicable to this problem. That is fair crisicism, and I will think it over for a new version. Thanks for the input, they are good input to a new version. I'll think about a few for a while, as that usually helps to better balance things. -Rick _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From nobody Wed Apr 22 12:37:44 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7653A0437 for ; Wed, 22 Apr 2020 12:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=openfortress.nl 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 B2yZ8STnSHwG for ; Wed, 22 Apr 2020 12:37:41 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 68B673A041D for ; Wed, 22 Apr 2020 12:37:40 -0700 (PDT) Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id RLBgjylYilKa1RLBhjBMLY; Wed, 22 Apr 2020 21:37:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587584256; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding : date : from : subject; bh=1y/jdLMNLZVepXDj9q8vrZmeyGrLBMBHgCVPAbdFduI=; b=k9ghVKcH532Zshwdw17jw+HwOuTExzbNXv/pJuTfiBeRn5ykrk4jNZC4 BZ0UHVo74IEIpMnLbBZtzKeODTW8HdlqvM1O+Y7dO3T+r30Gv6Wx9ipIyE wfXgUrDycjFEsjyMG8MVfH31wMouPH3Nc6XqWg1xeliNS0MdlvHdD/JwQ= Received: by fame.vanrein.org (Postfix, from userid 1006) id B2F2D3A4D3; Wed, 22 Apr 2020 19:37:36 +0000 (UTC) X-Original-To: emu@ietf.org Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 4EB593A4D1; Wed, 22 Apr 2020 19:37:33 +0000 (UTC) Message-ID: <5EA09CFC.2070804@openfortress.nl> Date: Wed, 22 Apr 2020 21:37:32 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Jim Schaad CC: 'EMU WG' References: <5E98981B.7020606@openfortress.nl> <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com> <5E9B4165.1050703@openfortress.nl> <5E9B5B28.3000007@openfortress.nl> <53BB9E1C-58D4-454E-B77B-3FA4AFA89E15@deployingradius.com> <5E9FF78A.7070605@openfortress.nl> <00c301d618d7$c257af50$47070df0$@augustcellars.com> In-Reply-To: <00c301d618d7$c257af50$47070df0$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4 X-CMAE-Envelope: MS4wfExGg4+5J5NkVnCuCumgCnpEQ0JYNPWj1CcflFdWPntbuL/mA+hiId5MlkwNIGHjkKRhDd5bfR3CQ2gcKM8OJVu76D5IVqBTl0YA3rJLmWl0dSrLnmH5 PyFYqg7AqME7ZKSMjNDxXI4GDCfX0HT8EdnFeiXeryGBsoNvnMo3KJA/3u9RV4cC8TX0o+Z4TwViHA== Archived-At: Subject: Re: [Emu] Proposal: SASL over EAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 19:37:44 -0000 Jim, > [JLS] I am a bit surprised at hearing this is abandoned given that they > released an update of the software on the 20th of April I heard about stopping Moonshot years ago; this is newer info. -Rick From nobody Fri Apr 24 01:04:55 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0653A0F58 for ; Fri, 24 Apr 2020 01:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=aalto.fi 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 TsV0KnLDQAWK for ; Fri, 24 Apr 2020 01:04:51 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 E79E63A0F57 for ; Fri, 24 Apr 2020 01:04:47 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D114411583C_EA29D9BB; Fri, 24 Apr 2020 08:04:43 +0000 (GMT) Received: from exng4.org.aalto.fi (exng4.org.aalto.fi [130.233.223.23]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng4.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id A0DFB11582A_EA29D9BF; Fri, 24 Apr 2020 08:04:43 +0000 (GMT) Received: from [192.168.8.113] (130.233.0.5) by exng4.org.aalto.fi (130.233.223.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Fri, 24 Apr 2020 11:04:43 +0300 To: Joseph Salowey References: <16130_1587240822_5E9B5F76_16130_332_1_CAOgPGoDUttvqQw5DXofxnxzW8O-8i5-9YS26JWKfiR2UX0yS2Q@mail.gmail.com> CC: From: Aleksi Peltonen Message-ID: Date: Fri, 24 Apr 2020 11:04:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <16130_1587240822_5E9B5F76_16130_332_1_CAOgPGoDUttvqQw5DXofxnxzW8O-8i5-9YS26JWKfiR2UX0yS2Q@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------6DE2DF392B5696743952A116" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng8.org.aalto.fi (130.233.223.27) To exng4.org.aalto.fi (130.233.223.23) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:references:cc:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=cAHI4r4MBDqajMrxcPAmgUC78Q3vn9a+74WNXobaHmI=; b=zLj+kqljFNC+KNAb0tYEtxgxiJu6luesEgwlaRCoR5gzcQxzROP7AnD00BGICmHZM0sbVihSPBYGtynBXgnbK6JSJP4h3OaN44VLda9mFM3yoI1IsI3/zjUxuUyix1pcqlGXiO5LB/nWwilwtjWEh9xWHXPutpRJQjPtqxYJOxYgrB1QtzFAPMOkxxxw71kk1WanWQimpvuTDiccjVb5nhTdyopT/6jefHwehy/Fk4kHYQg8OG55mMtyrPjpgpi3AyimbBCqdbrZkB1gy6em/cKMT9sKMGW9DnUDcZ6jSkSOCpi6aUYCGPMpLcPfFWY57MyvKM9OTjjhBpHPzwV8YQ== Archived-At: Subject: Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 24 Apr 2020 08:04:54 -0000 --------------6DE2DF392B5696743952A116 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit I support adoption of this draft. I have verified previous versions of the protocol with both mCRL2 (safety and liveness properties) and ProVerif (security properties). I am planning on updating the models as the specification evolves after adoption. - Aleksi On 18/04/2020 23:13, Joseph Salowey wrote: > This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a > working group item.  This draft has been discussed in several IETF > meetings and would be the starting point for the working group > deliverable for an EAP method based on "mutual authentication between > a peer and a server that is based on an out-of-band channel."  Please > review the draft and indicate whether you support adoption or not by > May 4, 2020. > Thanks, > > Joe > > [1] https://datatracker.ietf.org/doc/draft-aura-eap-noob/ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------6DE2DF392B5696743952A116 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

I support adoption of this draft. I have verified previous versions of the protocol with both mCRL2 (safety and liveness properties) and ProVerif (security properties). I am planning on updating the models as the specification evolves after adoption.

- Aleksi

On 18/04/2020 23:13, Joseph Salowey wrote:
This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working group item.  This draft has been discussed in several IETF meetings and would be the starting point for the working group deliverable for an EAP method based on "mutual authentication between a peer and a server that is based on an out-of-band channel."  Please review the draft and indicate whether you support adoption or not by May 4, 2020.  
Thanks,

Joe


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--------------6DE2DF392B5696743952A116-- From nobody Fri Apr 24 05:46:25 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785B53A0C51 for ; Fri, 24 Apr 2020 05:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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 HaOAd3ZRjepZ for ; Fri, 24 Apr 2020 05:46:22 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50070.outbound.protection.outlook.com [40.107.5.70]) (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 3AC263A0C4F for ; Fri, 24 Apr 2020 05:45:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XrhYp9vA3sLmG+sqFxpksFlki6s6OrA7sZCQEYxeWyZxZ8QJ1Yjb8LCApZtKOCgnf5kf/zLkVHGH2lBki18luvFA7FanoNT/L+ywLKMDLA0MHWiW5chxVS95JhIdCIu+NQ68kQKYWpoDh9fcwUgcArQWQis08uRjc6vGnWan8I3Ud8JgblR7zauON7w8corP8vxs/CRhN+NxNKjTFBm15h3N+ike5RcqzjI2Yb9cKLYdYYeT8DzZrx41Nz9oLh9ns8J5fYuPk2i/ezQah7iT7nd/EzCoP15Uf7dh+3IgXSL++a9/wCtzVbWBuj105/XGuYJdct8+NAfJjTvm6Jc/FA== 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=OT2zJpbdrpxRrbK/JCu5MJsi6nqA6jtexKOHsB7I1DQ=; b=dc9Hln8un4sdsb1ivBnMSl3K9df40vXr+wX7+U8whdmdk4qcIqKOv/o95xnwL6/7xBS2FEPGf5sGi+vMzR5lQnSuE/I0v8W+kYpbBa2hjfD7WRPfqPv1781Bbx0gZ6ajrB9JoqtHveWff2M3H+wK+QTBRpPFHQBLXV3sNovxRQNNZzoa2Ev0ddSvGKgmvddWAhbh5uFD1Jd64J4eoX3PgMNFWbgMsD6lB2vzEe0UZpBXd5PN0C3V9rTQFLy6pbpmej/TExZVrWVv8hpq+6fGEfYSlBEXbbkeRPIOb5TuoVwViaycTpWav1on41ilPjQyISRMpvTRW7MygX+DCUGpWA== 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=OT2zJpbdrpxRrbK/JCu5MJsi6nqA6jtexKOHsB7I1DQ=; b=pmn8a/FtjfMDNv43LXHkNsFc8usi7ytIifrvZP2U30kYdWN0bHUpHWtAAIkxbc/+eRe0vZULmYPhdDYFFcGBxqimGNe8iYD3nE30fK8xmoeY8xZqCIU/zniv7RxDd8LaK/cshckmwj4wcfarOEVI7rwnc4MijXLc7CzP5qijH4g= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (2603:10a6:3:57::18) by HE1PR0701MB2091.eurprd07.prod.outlook.com (2603:10a6:3:21::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.9; Fri, 24 Apr 2020 12:45:32 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 12:45:32 +0000 From: Mohit Sethi M To: "emu@ietf.org" Thread-Topic: [Emu] Poll for virtual interim Thread-Index: AQHWFp/Y4kHtRMPGXkK69hqFNrQSAKiIPzkA Date: Fri, 24 Apr 2020 12:45:32 +0000 Message-ID: <08230192-bed7-632a-3082-a3f8bde30156@ericsson.com> References: <008d10ab-8f20-429c-6319-692ddb2b9228@ericsson.com> In-Reply-To: <008d10ab-8f20-429c-6319-692ddb2b9228@ericsson.com> 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:190:9ee:c321:5f85:8127:40d0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d482e50b-a237-48ad-2cbb-08d7e84d6056 x-ms-traffictypediagnostic: HE1PR0701MB2091:|HE1PR0701MB2091: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1824; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(5660300002)(6512007)(966005)(478600001)(81156014)(4744005)(6916009)(316002)(186003)(76116006)(36756003)(6486002)(6506007)(53546011)(2906002)(66946007)(64756008)(31686004)(66556008)(66476007)(66446008)(8936002)(71200400001)(2616005)(8676002)(31696002)(86362001); DIR:OUT; SFP:1101; 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: k9T/yOw5J4m9z3ET0AYi1eyfcMJOSdtmYqR7h8mWklIlB2pYWfmJwR7wEonrg2ACwtGNUiSUq8gz/yNBmLUnS/3lr0EwYxpASPR4+m/+hchG5hA+JQbriR0Sfs/D51jnB7EA6+TOsR2FUwKgomlo0dEyPDc/kAnOEavZdz0lw2oFU6iUYoMOX6kaPSIffhX15FKkunnI/tRJb8qI918Bp978ael7jxUb6XA0WFyzVGGVTlx2kj5Dzw4mkXm4d7gUaHZ08oTfb5B46lfdrSHVzPwz70YtF97i2vAF0xIuMxoThAVUldqm/G/eD1u5J/Yn/E+fJAhVukpnqluRTnmdRgKM7qguI5xVTaDVz9N4T8WewR3k6wpcjLtrkm2Fdj1Uh63zIiSJaQVr5Qo4g0xtxUD84HhYV4JNoSsG+Qy1Ecr+vXmA3dJIelPYy5it4sYM7GtBha78Ka57i/mBooznC26PBf1cg+626uVN3k1LVqPag/phc/wl85Tcr98Gnd927CCNiiM9WUCCp3d4nSVHQA== x-ms-exchange-antispam-messagedata: 7AhFtY9sN9vJ6IFssAB+/A58zq/nKiYz7BGjcv5lEy4vJQQUJ6PFKeDUJnBiDA6qsxqoqlE7rcOng6Dki9GQpExP7/7nIxxyTOOQsdUPnB0ixbPEMO4Ce1oMMJFDVAX+VjkYZRNB2NRGvQfyH4k05qQ5NrRIlLQwOQsBeHj7NoaAKqoTe8N+EfzeEx5ua3Rfez+MWkIRWaIRpWKKwzrZ6tDQwirFjsyjfLPE69WBgyWTe8VHgG6/GPA6TqmcCVd8TrmJtyTduWBv+AYAvlguluSO+QT3V1Q7RXXWPf9i1SgTmS7jkloSCk49X+Cis5vDwAJzt2wjvjMFas3nHAzKaEH/wcOu+2GW27czkld+pJer4UH9wkHuDsCEY/7BPQ36GNmYGyINA1OIT9DjGwkJqInYq0KUHPsQOvO0x+mmcmpSjm90YuFETQwiXBBOqguQB2uALSVgzxIwxkCkVs9Oi+KF1IFegaf/D68Gzl9dJ4couDefylgrF86YjselNbk+wFFSEDXJwQYCtCAz1L73giuXae6wCdchHxlz4PEJvYfJjMKqpI9I/3DQTjM2shygU+5EQUGlV5qTBV034QKMeytSjhpVgWk2PG4hHmiLE9dTk1nmMmgneQFXQr6/J5kQkgW2JJExEYJMMoL2/Rx78jPE1n5JI16GAIawuhQXRkrD2VF5lcZPCUsdw80tK08YUaWgmtos2g2MZAIu+oO4OOGkicEaJK07nbAebuIPu784bdQQZFSWVtoZPLAs6qz/CkxTjNlUmVOlr/Xm6huyLLKsfG9g4k2Dv6fBTHqD8FDHpt67wO2Ke7ZdBaYiXTCvk4J9s2bEsPHt6NRxsnK9G1ycXiaWgr8hEcKBgiMtnBI= Content-Type: text/plain; charset="utf-8" Content-ID: <1A9E44C648B15742B37ABBA60B47831F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d482e50b-a237-48ad-2cbb-08d7e84d6056 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 12:45:32.0401 (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: 4TDpk3OE49ixiA084EMV39D9QPe4t01JneTajdwktSUeOFEIx1PD2wOioJHq6uybm5ElXdfwcWCN9GVx4CB6BxI38wwlbP9XUXEfRk8/4E4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2091 Archived-At: Subject: Re: [Emu] Poll for virtual interim 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, 24 Apr 2020 12:46:25 -0000 RGVhciBhbGwsDQoNClJlbWluZGVyOiBwbGVhc2UgcmVzcG9uZCB0byB0aGUgcG9sbCBmb3IgYSBw b3RlbnRpYWwgdmlydHVhbCBpbnRlcmltIGluIA0KTWF5OiBodHRwczovL2Rvb2RsZS5jb20vcG9s bC92eHk1dmM0ZzNjbmVncGRyDQoNCkpvZSBhbmQgTW9oaXQNCg0KT24gNC8yMC8yMCAyOjExIEFN LCBNb2hpdCBTZXRoaSBNIHdyb3RlOg0KPiBEZWFyIGFsbCwNCj4NCj4gV2UgZGlkIG5vdCBoYXZl IGEgZmFjZS10by1mYWNlIG1lZXRpbmcgaW4gVmFuY291dmVyIGZvciBJRVRGIDEwNy4gQXQNCj4g dGhpcyBwb2ludCwgdGhlIElFVEYgMTA4IG1lZXRpbmcgaW4gTWFkcmlkIGlzIGFsc28gdW5jZXJ0 YWluLg0KPg0KPiBXZSBhcmUgdGhlcmVmb3JlIGNvbnNpZGVyaW5nIGEgdmlydHVhbCBpbnRlcmlt IG1lZXRpbmcgZm9yIEVNVSBkdXJpbmcNCj4gbWlkZGxlL2VuZCBvZiBNYXkgMjAyMC4gSGVyZSBh cmUgc29tZSBwcm9wb3NlZCBkYXRlcyBhbmQgdGltZSBzbG90czoNCj4gaHR0cHM6Ly9kb29kbGUu Y29tL3BvbGwvdnh5NXZjNGczY25lZ3Bkcg0KPg0KPiBQbGVhc2UgaW5kaWNhdGUgeW91ciBhdmFp bGFiaWxpdHkhDQo+DQo+IEpvZSBhbmQgTW9oaXQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRW11IG1haWxpbmcgbGlzdA0KPiBFbXVAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUNCg== From nobody Fri Apr 24 06:02:15 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4E23A0CA1 for ; Fri, 24 Apr 2020 06:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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 qwdXFYgrMp_m for ; Fri, 24 Apr 2020 06:02:11 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80041.outbound.protection.outlook.com [40.107.8.41]) (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 23F153A0CA3 for ; Fri, 24 Apr 2020 06:02:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LZxjWwZg+0LKXA9tuoc4iGZ50KHpQwBw0zbgwNoSD1rMful7S6kDq1OoUtHmN5GxL6tol9SbF28qOsB6TKD8OXEDBsd734Q7POWZx2p7ZiD/egbZTC1o4BbrB1cXWF67+nYcJaoG+vr1kZ4MqGGoeXRowtJLw6kLGDaPTjDqiR/99Mj/WvD9CzXMSvdnM2Wzy5Rpydf1hhtgYD8DlXBXRSrJUcy7a7m6YEZiZ/T7MxCeyf5seeJ4yHHDNa1Pe2cG7tKlUeT7kdXzxFMWkkICWgwPCYZh9E+cli+0MzcJa8+0S7aMKLYrPGaPDS6eTmqMmBNAoegAcCCErJGMaA8xkw== 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=PKSa2xkIIsusLrykRydg3rNLE1D+yQ6E2hggobYqcY8=; b=V6SBErrp7DAJM7owLRJhxXyhIqLmCPbDaamjlf1DtucNbRx7V2I+YMobaguH4+nYu+O7Izh2Md2E817jLPtbSc8wBK67ovlqEDjU+4lGNtpBqGBFQhgZpeiOAPruMuoSBz2ZwwvIESFkMgDOj5RvEU5xSeruovdm10C3NMM+GrGLysZP0j7JNSligyLMFduI924XMQdbU+4Hng+uLj7Xx3uR+fHH6RctNfuyrjpMCl4Rj9cQ6glb7WGdIKVhVCygBFu+jsZOWLEa1HOe5/BlJL3aYPTvtudLlxwxM1Q7Vxb1XoiIG7rfwJvs5+nCX77vLygDXmsC7wWfLxgO8fm2oA== 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=PKSa2xkIIsusLrykRydg3rNLE1D+yQ6E2hggobYqcY8=; b=mPANSURQ2VxYO+obuty7vQESdrWvBaJEBO7hmWoSamjRvvkWeyDI4gNgIonXLMkEljWNBP5X78yYASqaefHAm+S7sBldwQ0vMFhrS1RY/6hHRpzl95VUL4rwRhZpHwqnB/Gqs8ZsARrHiNRFIC7Ef47DHuSorltcoFALq43+2jc= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (2603:10a6:3:57::18) by HE1PR0701MB3020.eurprd07.prod.outlook.com (2603:10a6:3:4d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.9; Fri, 24 Apr 2020 13:02:06 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 13:02:06 +0000 From: Mohit Sethi M To: Max Crone , EMU WG Thread-Topic: [Emu] draft-aura-eap-noob-08 NAI Thread-Index: AQHWGjiOwyY5pRQC70mTehtcYchCfw== Date: Fri, 24 Apr 2020 13:02:06 +0000 Message-ID: <2ed6d505-3e43-5524-7979-54bf2e6f70a0@ericsson.com> References: <3c0676c8-0810-4f70-4eb5-5d92abc35422@maxcrone.org> In-Reply-To: <3c0676c8-0810-4f70-4eb5-5d92abc35422@maxcrone.org> 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:190:9ee:c321:5f85:8127:40d0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07926740-5b4c-4b39-6bf2-08d7e84fb116 x-ms-traffictypediagnostic: HE1PR0701MB3020: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(5660300002)(2616005)(966005)(31686004)(316002)(31696002)(71200400001)(2906002)(36756003)(6512007)(478600001)(110136005)(76116006)(66556008)(66446008)(66946007)(81156014)(86362001)(66476007)(64756008)(8676002)(186003)(8936002)(6486002)(6506007)(53546011); DIR:OUT; SFP:1101; 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: JFwZhNJRSv4W1ac9FXx6jjSmF8/ITPUc+oAN4uOEcNqlBn9xoUL3VMgz0AD5XfdsZN+8Eem/ftu3sSKeYgQpr8ANuYEuSM3hNh+vcG/tMrhyQQS1II3LqPNAoe1WJxEbdyQvSfyb/Gu8fbCgN6NbSjfsHIN7gIJOywcJUA5QrCE5NPDSDaUeUNztlz+wAQRNM0Tn/ny7Hi/fnfSyqw2OI2CD6g5+suNU9Kiea3hRAnS8sTIK2B5gVeOEj8CW8HS0aFP9UUvpQJZZiN+H8UPhnZVkOFogeMV4CrIMAKV3UaKxpcTE3ugHBiWHm9FFsMp1uZ6128DdHh00+ALFbxP/izr//GfewK+sGGulZkGphRNXDmGRK4+oWdSrOimcHYZZG+sE6vn7JpNfRMbjcE8dS5/uJ1UCNouXA//GAM+9mBZdV0tckC5cDvIlbu5zfJtY/F7JeiTQzHOa+cPPHidaNSOK0h3dc3yXzh8RRSPzgVv20n7nATdR1a1zdhgZUmuM9DFgzFWP4Lfo1Yw7rJSwlg== x-ms-exchange-antispam-messagedata: HPYBuxYQi7/apLPLLlWyAx0D9avNMAVRWsmecuZfET0tMT0Sp5iJ4XssdRqbvDqEQCj3f5t0/9ruLUD1VpGVPs3cQws1vc1hgI2xu0Tn8AQsae3cGvI3hqTBNUUaH7e+S0kSfUeGh+RE0x2kuR1cGCB8VUrMBp/2PtdRHF9HvtsuqrPcNnNUAHSGIE1Kug2h0VqovfwPDbgAVYON6ui4+Eluc1F8/vQib4hDhzMUKQoCHjQwV9aylORLpYo3WvLDAwOkPu0q/sZYKF9/qdoCevd1JkQMm8ahnx3TDEbur9wHd9ky1Ge0TQrBeFDkjNbn06giAVLB4lpCzPyTZGLArArkIUhrKR1RIX1TpEk3GIrAfByBnc9BYo3DCIBXchquvrMq2qmARRfo/XilJA3OkP8asm56aBpR2WStvYGnyhjDpaH/1ca/O7nMkpDwbS97y2CvPPeXUXeCiOESYBxeh1eUFVTxPwtQnNtC3dwgPVbz2SpNOm6Y8M4Xi5IkNQg0P3cIllSA0jSi/+IkJbHcMIihM6Q/iR3zsCGjco3iRHkKF3UnPFi8//fCgfI20dPL0n4HEPxNZrHNFGAvipKcf2GxCQxIBi6CK7jIXPeK+Bng0srveaTUIKEmVgi/UIJIAzPvfX9QilKIC2B5qQUvJPu11i9hlu1Fv5OVgzGSNqSiY89m6MrlXWHuhMNC4RKnQGsY9ALWzFU9D6SPHlixwHunVzl2noSI8UtrFYRTf6jRLFNVsIzAZsJ67SeBo1dxw//UrQgscrTfC85u8Q8H9fWLwGKksCMngxxl2rcdMEA6bQmIa7syqJsgblWuK8HPzrO6vZswuT4iC8tXKx/IY6MuiQypTlPixRjInwM35Vc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <06644301F303A8449ADB810B655338FD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07926740-5b4c-4b39-6bf2-08d7e84fb116 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 13:02:06.5832 (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: 9+IAzmQlNElkr11Pfmc0WleP9pykjlvqf6nd3LKCiUD3Xeq4J0ENYY+KxlxOgO4McANxGgl2j+M6Vb1T9BWNdnLzy5fG52HKpobc7BiXn0o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3020 Archived-At: Subject: Re: [Emu] draft-aura-eap-noob-08 NAI 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, 24 Apr 2020 13:02:13 -0000 SGkgTWF4LA0KDQpUdW9tYXMgY2FuIGdpdmUgeW91IGEgZGVmaW5pdGUgYW5zd2VyLiBNeSB1bmRl cnN0YW5kaW5nIGlzIHRoYXQgZXJyb3IgDQoxMDAxIHNob3VsZCBiZSBzZW50IGJ5IHRoZSBzZXJ2 ZXIgaWYgdGhlIHJlY2VpdmVkIGlkZW50aXR5IGRvZXMgbm90IA0KZm9sbG93IHRoZSByZXF1aXJl bWVudHMgb2YgZHJhZnQtYXVyYS1lYXAtbm9vYi4gQmVzaWRlcywgaW1wbGVtZW50aW5nIA0KdGhl IHN0cmljdGVyIGNoZWNrcyBvZiB0aGlzIGRyYWZ0IGlzIGVhc2llciB0aGFuIHZhbGlkYXRpbmcg dGhlIEFCTkYgb2YgDQpSRkM3NTQyIChhZnRlciB3aGljaCB5b3Ugd291bGQgYW55d2F5cyBuZWVk IHRvIHZlcmlmeSBjb21wbGlhbmNlIHdpdGggDQp0aGlzIGRyYWZ0KS4NCg0KQW5kIHlvdSBhcmUg cmlnaHQuIFRoZSBhYnNlbmNlIG9mIHNlcnZlci1hc3NpZ25lZCByZWFsbSBpbiBGaWd1cmUgMiBp cyANCnByb2JhYmx5IGFuIGVkaXRvcmlhbCBvdmVyc2lnaHQuIEhvd2V2ZXIsIEkgd291bGRuJ3Qg Y2FsbCB0aGUgb3B0aW9uYWwgDQpzZXJ2ZXIgYXNzaWduZWQgcmVhbG0gYXMgUkVTRVJWRURfRE9N QUlOLiBJZiBhbnl0aGluZywgSSB3b3VsZCBjYWxsIA0KZWFwLW5vb2IubmV0IGFzIGEgcmVzZXJ2 ZWQvc3BlY2lhbCB1c2UgZG9tYWluLg0KDQotLU1vaGl0DQoNCk9uIDQvMjIvMjAgMTI6MjkgUE0s IE1heCBDcm9uZSB3cm90ZToNCj4gV2hpbGUgaW1wbGVtZW50aW5nIEVBUC1OT09CLCBJIGZvdW5k IHRoZSBleHBsYW5hdGlvbiBvbiB0aGUgSW52YWxpZCANCj4gTkFJIChlcnJvciBjb2RlIDEwMDEp IGluIHRoZSBkcmFmdCB0byBiZSB1bmNsZWFyLg0KPg0KPiBUaGUgZG9jdW1lbnQgZm9ybXVsYXRl cyBpdCBhcyBmb2xsb3dzOg0KPiA+wqDCoCBJZiB0aGUgTkFJIHN0cnVjdHVyZSBpcyBpbnZhbGlk LCB0aGUgc2VydmVyIFNIT1VMRCBzZW5kIHRoZSBlcnJvcg0KPiA+wqDCoCBjb2RlIDEwMDEgdG8g dGhlIHBlZXIuDQo+DQo+IEhvd2V2ZXIsIGRvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIEVBUC1OT09C IHNlcnZlciBzaG91bGQgdmVyaWZ5IHRoYXQgDQo+IHRoZSBOQUkgZm9sbG93cyB0aGUgZm9ybWFs IHN5bnRheCBhcyBzcGVjaWZpZWQgaW4gUkZDIDc1NDIsIG9yIHNob3VsZCANCj4gaXQgdmVyaWZ5 IHRoYXQgdGhlIE5BSSBmb2xsb3dzIHRoZSBzcGVjaWZpY2F0aW9uIG9mIEVBUC1OT09CLCBpLmUu LCBpdCANCj4gaXMgb2YgdGhlIGZvcm0gIm5vb2JAe2VhcC1ub29iLm5ldHx8UkVTRVJWRURfRE9N QUlOfSIuIEkgdGhpbmsgdGhpcyANCj4gc2VjdGlvbiBjb3VsZCBiZSBmb3JtdWxhdGVkIG1vcmUg Y2xlYXJseSB0byBhZGRyZXNzIHRoZXNlIGNvbmNlcm5zLg0KPg0KPiBPbiB0aGF0IG5vdGUsIEZp Z3VyZSAyIHNlZW1zIHRvIGJlIGluY29tcGxldGUuIFRoZSANCj4gRUFQLVJlc3BvbnNlL0lkZW50 aXR5IHNwZWNpZmllcyB0aGUgTkFJIHBhcmFtZXRlciB0byBiZSANCj4gIm5vb2JAZWFwLW5vb2Iu bmV0Iiwgd2hpbGUgdGhlIHNwZWNpZmljYXRpb24gYWxzbyBoYXMgdGhlIG9wdGlvbiBvZiANCj4g Y29uZmlndXJpbmcgdGhpcyB0byBhIHJlc2VydmVkIGRvbWFpbi4gSW4gdGhhdCBjYXNlLCB0aGUg TkFJIHNob3VsZCANCj4gbm90IHVzZSB0aGUgZGVmYXVsdCByZWFsbSBhbnltb3JlLiBDdXJyZW50 bHksIHRoaXMgaXMgbm90IHJlZmxlY3RlZCBpbiANCj4gdGhlIGZpZ3VyZS4NCj4NCj4gSWYgYW55 dGhpbmcgcmVtYWlucyB1bmNsZWFyLCBJIGFtIG9wZW4gZm9yIGRpc2N1c3Npb24uDQo+DQo+IH5N YXggQ3JvbmUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRW11IG1haWxpbmcgbGlzdA0KPiBFbXVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXUNCg== From nobody Fri Apr 24 06:23:00 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D53A012A for ; Fri, 24 Apr 2020 06:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, DKIM_VALID_EF=-0.1, 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 R9BU80eFebO9 for ; Fri, 24 Apr 2020 06:22:56 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCDD3A0CDD for ; Fri, 24 Apr 2020 06:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1133; q=dns/txt; s=iport; t=1587734573; x=1588944173; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=bUyIRVp1RhMLPr9VRfdaP2iXVBeT8mbSwzVNBF152Z4=; b=A/44gy6sRp82KJ0gGe/JJ703Yak1zNU0YRmVCRgbdFukp3X5n2hy8oZ6 C5LtV4nnvkedP90h3oiBb6qfq8xp3YtbZAF0g3TS6BU242zSVIECHfst0 yn14i/ghSMAShZO7k8ZHOgfNf4WpnL3gHdg0mjzJU+ZmxRaJ2ExzE3vGz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzDAC956Je/xbLJq1dCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBATyBRwIBgxNUASASKoQfiQKIFZlfE4FnCwEBAQwBARsUBAEBhEQ?= =?us-ascii?q?Cgko6BA0CAwEBCwEBBQEBAQIBBQRthVYMQgEQAYUdAQEBAQIBI1YFCwsYAgI?= =?us-ascii?q?mAgJXBhODJgGCXCCxIHaBMoVPhRCBDioBjFKCAIERJxyCTT6CZwSBLgEICgE?= =?us-ascii?q?JGIMSMoItBLIbgk+CaoUij28WB5xxqTSDQgIEBgUCFYFsDBNmcDMaCBsVZQG?= =?us-ascii?q?CPgk1EhgNmX+Ffz8DMAIBATECBgEHAQEDCYVOhxctghYBAQ?= X-IronPort-AV: E=Sophos;i="5.73,311,1583193600"; d="scan'208";a="25618506" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2020 13:22:50 +0000 Received: from ams3-vpn-dhcp5713.cisco.com (ams3-vpn-dhcp5713.cisco.com [10.61.86.80]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03ODMnVS022135 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Apr 2020 13:22:49 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <2ed6d505-3e43-5524-7979-54bf2e6f70a0@ericsson.com> Date: Fri, 24 Apr 2020 15:22:48 +0200 Cc: Max Crone , EMU WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <3c0676c8-0810-4f70-4eb5-5d92abc35422@maxcrone.org> <2ed6d505-3e43-5524-7979-54bf2e6f70a0@ericsson.com> To: Mohit Sethi M X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.86.80, ams3-vpn-dhcp5713.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Emu] draft-aura-eap-noob-08 NAI 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, 24 Apr 2020 13:22:58 -0000 Hi Mohit > On 24 Apr 2020, at 15:02, Mohit Sethi M = wrote: >=20 > Hi Max, >=20 > Tuomas can give you a definite answer. My understanding is that error=20= > 1001 should be sent by the server if the received identity does not=20 > follow the requirements of draft-aura-eap-noob. Besides, implementing=20= > the stricter checks of this draft is easier than validating the ABNF = of=20 > RFC7542 (after which you would anyways need to verify compliance with=20= > this draft). >=20 > And you are right. The absence of server-assigned realm in Figure 2 is=20= > probably an editorial oversight. However, I wouldn't call the optional=20= > server assigned realm as RESERVED_DOMAIN. If anything, I would call=20 > eap-noob.net as a reserved/special use domain. There are all manner of reasons not to use eap-noob.net. I think we = talked to the IAB about this at some point and they were comfortable = with something in .ARPA, but we=E2=80=99d need to reconfirm. This is a = small matter that should be cleared up with a few email exchanges. Eliot= From nobody Fri Apr 24 06:30:00 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584B03A0D21 for ; Fri, 24 Apr 2020 06:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 W4plzlycioQ8 for ; Fri, 24 Apr 2020 06:29:56 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2070.outbound.protection.outlook.com [40.107.21.70]) (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 39D603A0AB0 for ; Fri, 24 Apr 2020 06:29:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W6KuQD1p40f/5CgkzQOTgxjPQWo1JXdWqjMh3HhxvbSV2KIBBUZ1wvbpWJ2FFWMen7kB4zRDB1qebX9nM4/VddUGoVAcO+h4XZft+q2dTu/HCvwnB64+YxN4YzRxucrVBxuDMH+5B4y56ycnVGg/OCKYGcmSkYh+Eur2Q1Wso6t/GDisV4RqDGFVjXjHPCw5NmamX4s3VzeKMFH2qRlWBfS5rGX6m8Plnh1cybu9R+DptVEC/6fQBFPsm4pQ5kzoycVjqis8vIT3KEcVVlAAJ3RdyN8npmCdoZB5MUnH8D7gTrMWt2R+DIoVV+hSy4ZCmSNGcN8TBe17p0zmuIbHRw== 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=v8mut72nYLifCYqPcfhJ32zD19qCIjyLYtExagA7zZ4=; b=WiiB3diTsC6vo8SI/CmMOEIpOk5939lZDc6D0gvDW0vv7fPH88Zm5e7DPeF50/H71QSYVCx7/IvJwQlQ8mJvNuDH64ePLOHZdEc/zPppnvrZUBfrMpdx6OM6BBaAzOqLuFUXBv7cVMXl2PMrzclCrePDSsy/H3HHglEYJgEDNQPNIZgkI5HqfSgoI63O4+SsLqCXSYTz4VQhW70+VygADGDhLHvvyIO9tgeVEPPuX7/QmQkEffy+R7LMtoWDIC7dK7d2jw417XYKKfH3B8vVjRxZeu9cCL5lechiwz/PqrLLyaC9sEErQ7RKB+dZXZLC3MN089KAVEPatqCLYNVPqw== 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=v8mut72nYLifCYqPcfhJ32zD19qCIjyLYtExagA7zZ4=; b=nL3Z8qjQ5Xuv90js+t+xfSp6Wq1ZyMpmv0NA/hrv6alNOCJsh4nhXbKo2QLgMVBCUjw2XLazB3nwSdJzGfOhrPvx1EPzIXxKwp3GO6iXVqLWovEndLvGgFFlSOzMttKc0zS765QWOcVMPOylx8DsB+KyN0zc6nesYCmbip8ElLc= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (2603:10a6:3:57::18) by HE1PR0701MB2492.eurprd07.prod.outlook.com (2603:10a6:3:71::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Fri, 24 Apr 2020 13:29:53 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::b909:1134:d9c1:e941%5]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 13:29:53 +0000 From: Mohit Sethi M To: Eliot Lear , Mohit Sethi M CC: EMU WG Thread-Topic: [Emu] draft-aura-eap-noob-08 NAI Thread-Index: AQHWGjiOwyY5pRQC70mTehtcYchCf6iIQnMAgAAB+gA= Date: Fri, 24 Apr 2020 13:29:53 +0000 Message-ID: <0cd58037-6867-6d4b-de01-62424725628e@ericsson.com> References: <3c0676c8-0810-4f70-4eb5-5d92abc35422@maxcrone.org> <2ed6d505-3e43-5524-7979-54bf2e6f70a0@ericsson.com> In-Reply-To: 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:68.0) Gecko/20100101 Thunderbird/68.7.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:190:9ee:c321:5f85:8127:40d0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9998f9e5-df01-4487-ec92-08d7e85392a7 x-ms-traffictypediagnostic: HE1PR0701MB2492: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(376002)(396003)(366004)(4326008)(316002)(110136005)(76116006)(66556008)(64756008)(53546011)(6506007)(36756003)(966005)(66946007)(86362001)(66446008)(71200400001)(66476007)(31696002)(5660300002)(186003)(2906002)(478600001)(6512007)(8676002)(6486002)(8936002)(31686004)(81156014)(2616005); DIR:OUT; SFP:1101; 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: qzx77IHnJG8qwdaL/rerx7W5qhSt1K+DmckVQFY4D6KKxP/04SrJwnXHnDFTmdDm9rZQzhX/p21u6VzLwOmGuY760rHUvEQ2ZytCRjuE9k2hIQnuFMr+JJQeJJuAGuR7QbTYEXWprJstbxcgnee8NUW2BNa1xqLLkGolXxWLVWx72iGuwsh49hk1nFC3joyPkj7lk6+66tthh/3OYKiHEo4qt3FvDGQPNAjoK/rPnQB8ByR25cctupwad8fk2oed0jwEhWMYctKQDzEOpBxDBSUg2idxVjYCq9XUEjie1f2DXcRDgGVpkGVOdNvw+pE+Ok4wrB49GEHIbisAFnmq9ij//ItRianHnldqOU1kSlasP9dyu1uwPunZ+bu0ClRNFDqNZ/eR0ylQcQhYxl4l0455P8ZB2SzpXJkh9WP+rNUacKYYlz7yLtYKaOu64GixYvyY7dmOXRpO1c/uM3adH/O0t/Ea3RoN0T7deuCdB8P30Fu5iuabWnEJTDHdd7miAbfKZ6rMTt6yKrVyshTSzA== x-ms-exchange-antispam-messagedata: HTqoM5MCKAE/hE44CJ8mCVAZFrb3h3edz+lstLLkbLWwtls9fh1AdWCP7a0V/aJ36Qe2zCW0pmoDO+Hu4fiquotgWhRDgFVtdFYPpaxo4YnSrYENPnxzK46OIKi9tbVVhy2pMuvisQQ8up0BtS2+lAwqydUmItN3B3qI5ZPIGzw/Mu+aV3FUH570bBhfJfUQpaee1obOIUdb6SvV26Zh2ihKK4nA18O6vBXtUMQPf7xKJwLgizLnRch1PlCsfIaYBvbOztdBMg6DlFcydZ+BcYUlKOj8XXAtafQTIt7BWdkydA6sIPnM3rK0KCV0QFQsV+LktFYQnotCgNuzpPDOMiZpNTdstjqgcfTDLqXvhQ+M9CtVXCJ1kEE10RNJndE0XENQi3bnAjfSlp4AxvDp7b8Sgjn3wkctL3zbp/q0ECKjFfj+HmI4vLTas0GzW22zfH3ZLjYwAiL2otaRbiDRhurJ0u69fX6Zmuyd9GXSeoZYbBfp3BUpuHcGEtjHY5204V4zDa22dyFVsjpIPq6bitV34khY9SN1eo/g+HfAEdNKc0j6JbXNcR723/UhBqtFwt4rVFrcqzcSa0vy5gEVTq/6+e6q7IZrz9Jwlu+3Kcq2VbM19dwsyn7KgXbnLdKxzaZVGm+scE55nibG46ene6ZGw20WKvNO4n6GRM5Tb9o2acP6C/w42H8+MmGHxNWAv3mdfqv9n1dMyz1bMKpSnPbBTtFN+n7R16ov75eHXdkGzeEs54cVK6ZhyJDvzxNLJVTHCumG9SdzYAf53S5qLmmAl7KPnnRphsYldEHa2kVRSaEZ1Il6IzZFKJD77296WQt8fBv+C0O2dKpJLgNq1Lp2fmghq9eUVzkXpbFQYBg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0cd5803768676d4bde0162424725628eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9998f9e5-df01-4487-ec92-08d7e85392a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 13:29:53.5843 (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: n4OaDm6IYELwv9XoXs3RE1c5kh+QP8ZF1Wo93+7KFOED8WacDg2RfA4Npm24DSAPHsWtyqmgEIvD8jd5kfLAUjP0tjGY2h2aLFTrsODgjEo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2492 Archived-At: Subject: Re: [Emu] draft-aura-eap-noob-08 NAI 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, 24 Apr 2020 13:29:58 -0000 --_000_0cd5803768676d4bde0162424725628eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWxpb3QsDQoNCk9uIDQvMjQvMjAgNDoyMiBQTSwgRWxpb3QgTGVhciB3cm90ZToNCg0KSGkg TW9oaXQNCg0KDQoNCk9uIDI0IEFwciAyMDIwLCBhdCAxNTowMiwgTW9oaXQgU2V0aGkgTSA8bW9o aXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz48bWFpbHRvOm1vaGl0Lm0u c2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQpIaSBNYXgsDQoN ClR1b21hcyBjYW4gZ2l2ZSB5b3UgYSBkZWZpbml0ZSBhbnN3ZXIuIE15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCBlcnJvcg0KMTAwMSBzaG91bGQgYmUgc2VudCBieSB0aGUgc2VydmVyIGlmIHRoZSBy ZWNlaXZlZCBpZGVudGl0eSBkb2VzIG5vdA0KZm9sbG93IHRoZSByZXF1aXJlbWVudHMgb2YgZHJh ZnQtYXVyYS1lYXAtbm9vYi4gQmVzaWRlcywgaW1wbGVtZW50aW5nDQp0aGUgc3RyaWN0ZXIgY2hl Y2tzIG9mIHRoaXMgZHJhZnQgaXMgZWFzaWVyIHRoYW4gdmFsaWRhdGluZyB0aGUgQUJORiBvZg0K UkZDNzU0MiAoYWZ0ZXIgd2hpY2ggeW91IHdvdWxkIGFueXdheXMgbmVlZCB0byB2ZXJpZnkgY29t cGxpYW5jZSB3aXRoDQp0aGlzIGRyYWZ0KS4NCg0KQW5kIHlvdSBhcmUgcmlnaHQuIFRoZSBhYnNl bmNlIG9mIHNlcnZlci1hc3NpZ25lZCByZWFsbSBpbiBGaWd1cmUgMiBpcw0KcHJvYmFibHkgYW4g ZWRpdG9yaWFsIG92ZXJzaWdodC4gSG93ZXZlciwgSSB3b3VsZG4ndCBjYWxsIHRoZSBvcHRpb25h bA0Kc2VydmVyIGFzc2lnbmVkIHJlYWxtIGFzIFJFU0VSVkVEX0RPTUFJTi4gSWYgYW55dGhpbmcs IEkgd291bGQgY2FsbA0KZWFwLW5vb2IubmV0IGFzIGEgcmVzZXJ2ZWQvc3BlY2lhbCB1c2UgZG9t YWluLg0KDQoNCg0KVGhlcmUgYXJlIGFsbCBtYW5uZXIgb2YgcmVhc29ucyBub3QgdG8gdXNlIGVh cC1ub29iLm5ldC4gIEkgdGhpbmsgd2UgdGFsa2VkIHRvIHRoZSBJQUIgYWJvdXQgdGhpcyBhdCBz b21lIHBvaW50IGFuZCB0aGV5IHdlcmUgY29tZm9ydGFibGUgd2l0aCBzb21ldGhpbmcgaW4gLkFS UEEsIGJ1dCB3ZeKAmWQgbmVlZCB0byByZWNvbmZpcm0uICBUaGlzIGlzIGEgc21hbGwgbWF0dGVy IHRoYXQgc2hvdWxkIGJlIGNsZWFyZWQgdXAgd2l0aCBhIGZldyBlbWFpbCBleGNoYW5nZXMuDQoN CkFic29sdXRlbHkuIFVzaW5nIHNvbWV0aGluZyBpbiAuYXJwYSBtYWtlcyBwZXJmZWN0IHNlbnNl LiBCdXQgdW50aWwgdGhhdCBpcyBhbGxvY2F0ZWQsIGltcGxlbWVudGF0aW9ucyBuZWVkIGEgdGVt cG9yYXJ5IHBsYWNlaG9sZGVyLiBUaGUgY3VycmVudCB0ZXh0IGluIHNlY3Rpb24gMy4zLjEgb2Yg dGhlIGRyYWZ0IGV2ZW4gc2F5cyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1 cmEtZWFwLW5vb2ItMDgjc2VjdGlvbi0zLjMuMSk6DQoNClRoZSBkZWZhdWx0IHJlYWxtIGZvciB0 aGUgcGVlciBpcyAiZWFwLW5vb2IubmV0IiAoLmFycGEgZG9tYWluIFRCQSkuDQoNCi0tTW9oaXQN Cg0KDQoNCkVsaW90DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRW11IG1haWxpbmcgbGlzdA0KRW11QGlldGYub3JnPG1haWx0bzpFbXVAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0KDQo= --_000_0cd5803768676d4bde0162424725628eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <61525EFD20585C44BB1C2E68B575007E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgRWxpb3Qs PC9wPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA0LzI0LzIwIDQ6MjIgUE0sIEVs aW90IExlYXIgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRl PSJtaWQ6RTVGNDQ0NkUtREI4Qy00QzBCLUJENDQtMzNGN0NFNzdCM0FBQGNpc2NvLmNvbSI+DQo8 cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPkhpIE1vaGl0DQoNCjwvcHJlPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIi Pk9uIDI0IEFwciAyMDIwLCBhdCAxNTowMiwgTW9oaXQgU2V0aGkgTSA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNv bUBkbWFyYy5pZXRmLm9yZyI+Jmx0O21vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMu aWV0Zi5vcmcmZ3Q7PC9hPiB3cm90ZToNCg0KSGkgTWF4LA0KDQpUdW9tYXMgY2FuIGdpdmUgeW91 IGEgZGVmaW5pdGUgYW5zd2VyLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZXJyb3IgDQoxMDAx IHNob3VsZCBiZSBzZW50IGJ5IHRoZSBzZXJ2ZXIgaWYgdGhlIHJlY2VpdmVkIGlkZW50aXR5IGRv ZXMgbm90IA0KZm9sbG93IHRoZSByZXF1aXJlbWVudHMgb2YgZHJhZnQtYXVyYS1lYXAtbm9vYi4g QmVzaWRlcywgaW1wbGVtZW50aW5nIA0KdGhlIHN0cmljdGVyIGNoZWNrcyBvZiB0aGlzIGRyYWZ0 IGlzIGVhc2llciB0aGFuIHZhbGlkYXRpbmcgdGhlIEFCTkYgb2YgDQpSRkM3NTQyIChhZnRlciB3 aGljaCB5b3Ugd291bGQgYW55d2F5cyBuZWVkIHRvIHZlcmlmeSBjb21wbGlhbmNlIHdpdGggDQp0 aGlzIGRyYWZ0KS4NCg0KQW5kIHlvdSBhcmUgcmlnaHQuIFRoZSBhYnNlbmNlIG9mIHNlcnZlci1h c3NpZ25lZCByZWFsbSBpbiBGaWd1cmUgMiBpcyANCnByb2JhYmx5IGFuIGVkaXRvcmlhbCBvdmVy c2lnaHQuIEhvd2V2ZXIsIEkgd291bGRuJ3QgY2FsbCB0aGUgb3B0aW9uYWwgDQpzZXJ2ZXIgYXNz aWduZWQgcmVhbG0gYXMgUkVTRVJWRURfRE9NQUlOLiBJZiBhbnl0aGluZywgSSB3b3VsZCBjYWxs IA0KZWFwLW5vb2IubmV0IGFzIGEgcmVzZXJ2ZWQvc3BlY2lhbCB1c2UgZG9tYWluLg0KPC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KVGhl cmUgYXJlIGFsbCBtYW5uZXIgb2YgcmVhc29ucyBub3QgdG8gdXNlIGVhcC1ub29iLm5ldC4gIEkg dGhpbmsgd2UgdGFsa2VkIHRvIHRoZSBJQUIgYWJvdXQgdGhpcyBhdCBzb21lIHBvaW50IGFuZCB0 aGV5IHdlcmUgY29tZm9ydGFibGUgd2l0aCBzb21ldGhpbmcgaW4gLkFSUEEsIGJ1dCB3ZeKAmWQg bmVlZCB0byByZWNvbmZpcm0uICBUaGlzIGlzIGEgc21hbGwgbWF0dGVyIHRoYXQgc2hvdWxkIGJl IGNsZWFyZWQgdXAgd2l0aCBhIGZldyBlbWFpbCBleGNoYW5nZXMuPC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8cD5BYnNvbHV0ZWx5LiBVc2luZyBzb21ldGhpbmcgaW4gLmFycGEgbWFrZXMgcGVyZmVj dCBzZW5zZS4gQnV0IHVudGlsIHRoYXQgaXMgYWxsb2NhdGVkLCBpbXBsZW1lbnRhdGlvbnMgbmVl ZCBhIHRlbXBvcmFyeSBwbGFjZWhvbGRlci4gVGhlIGN1cnJlbnQgdGV4dCBpbiBzZWN0aW9uIDMu My4xIG9mIHRoZSBkcmFmdCBldmVuIHNheXMgKDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDgjc2Vj dGlvbi0zLjMuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5v b2ItMDgjc2VjdGlvbi0zLjMuMTwvYT4pOjxicj4NCjwvcD4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPg0KPHByZSBjbGFzcz0ibmV3cGFnZSI+VGhlIGRlZmF1bHQgcmVhbG0gZm9yIHRoZSBwZWVy IGlzICZxdW90O2VhcC1ub29iLm5ldCZxdW90OyAoLmFycGEgZG9tYWluIFRCQSkuPC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQotLU1vaGl0PGJyPg0KPHA+PC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2l0ZT0ibWlkOkU1RjQ0NDZFLURCOEMtNEMwQi1CRDQ0LTMzRjdDRTc3QjNBQUBjaXNjby5j b20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4NCg0KRWxpb3QNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFbXUgbWFpbGluZyBs aXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86RW11 QGlldGYub3JnIj5FbXVAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0 ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbXU8L2E+DQo8L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0cd5803768676d4bde0162424725628eericssoncom_-- From nobody Tue Apr 28 01:25:52 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E073A0F53 for ; Tue, 28 Apr 2020 01:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=um.es 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 RwGAdkc0WYUg for ; Tue, 28 Apr 2020 01:25:49 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound5sev.lav.puc.rediris.es [130.206.19.180]) (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 6B6913A0F4E for ; Tue, 28 Apr 2020 01:25:49 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx02.puc.rediris.es with ESMTP id 03S8PkdI011499-03S8PkdJ011499 for ; Tue, 28 Apr 2020 10:25:47 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id E156320B92; Tue, 28 Apr 2020 10:25:46 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QcPSYbNZ-UCT; Tue, 28 Apr 2020 10:25:46 +0200 (CEST) Received: from MacBook-Pro-de-Dan.local (vpn_alu-197-176.inf.um.es [155.54.197.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 0C837201A5; Tue, 28 Apr 2020 10:25:45 +0200 (CEST) To: emu@ietf.org References: <16130_1587240822_5E9B5F76_16130_332_1_CAOgPGoDUttvqQw5DXofxnxzW8O-8i5-9YS26JWKfiR2UX0yS2Q@mail.gmail.com> From: Dan Garcia Message-ID: <7920abe6-2356-256a-0d3b-6a9b1860efec@um.es> Date: Tue, 28 Apr 2020 10:25:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------144DDE2ED70760B191F33F1D" Content-Language: en-US X-FEAS-CONTENT-MODIFICATION: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=cc:subject:to:references:from:message-id:date:mime-version:content-type; bh=pJd+aNYdkebByY1qsayoBsiv8auofuzhnr8JkUO8JuY=; b=FYmxn8R7kYKEnPv2q9bPjJJtdFHLqQgO+yn+1KV6OvcBGOUOwNGJuTbfE+S6g2BRUGdnAH2ykdrV gKuBWt9qOGvqvLCou80alD/3d8uDMt+NEsfdlTbRGyu0gItB4C7EYyLvHol25/fs1IE2NmJ2u6fr 9e96gh4FYYNh85SoLAbj65LP3adTkshlxu5sqHKVSeiSXpDk9HGKeSIJVuJQ1rmRSMJF7HlSuqfu JGZbk3Rd9IFmBOXViLt05yrsY+EKV+/mWyhRpCdHtTcAz22HVLa+PVZOtLj7qjNCCiJfnmjcHYsn G0fdl/EokGrhIPE22zIhRwaq0UkMs7wwsNkGag== Archived-At: Subject: Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 28 Apr 2020 08:25:51 -0000 This is a multi-part message in MIME format. --------------144DDE2ED70760B191F33F1D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, I support the adoption of this document. This is interesting work because it takes the process of deployment a step further and makes it easier by allowing bootstrapping of devices that don't have any credentials programmed into them. Furthermore, there are current efforts to widen the scope of the use cases to constrained IoT, with very limited I/O, which opens this protocol to many other IoT deployments. Best Regards, Dan. On 24/04/2020 10:04, Aleksi Peltonen wrote: > > I support adoption of this draft. I have verified previous versions of > the protocol with both mCRL2 (safety and liveness properties) and > ProVerif (security properties). I am planning on updating the models > as the specification evolves after adoption. > > - Aleksi > > On 18/04/2020 23:13, Joseph Salowey wrote: >> This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a >> working group item.  This draft has been discussed in several IETF >> meetings and would be the starting point for the working group >> deliverable for an EAP method based on "mutual authentication between >> a peer and a server that is based on an out-of-band channel."  Please >> review the draft and indicate whether you support adoption or not by >> May 4, 2020. >> Thanks, >> >> Joe >> >> [1] https://datatracker.ietf.org/doc/draft-aura-eap-noob/ >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu --------------144DDE2ED70760B191F33F1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear all,

I support the adoption of this document.

This is interesting work because it takes the process of deployment a step further and makes it easier by allowing bootstrapping of devices that don't have any credentials programmed into them.

Furthermore, there are current efforts to widen the scope of the use cases to constrained IoT, with very limited I/O, which opens this protocol to many other IoT deployments.

Best Regards,
Dan. 

On 24/04/2020 10:04, Aleksi Peltonen wrote:

I support adoption of this draft. I have verified previous versions of the protocol with both mCRL2 (safety and liveness properties) and ProVerif (security properties). I am planning on updating the models as the specification evolves after adoption.

- Aleksi

On 18/04/2020 23:13, Joseph Salowey wrote:
This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working group item.  This draft has been discussed in several IETF meetings and would be the starting point for the working group deliverable for an EAP method based on "mutual authentication between a peer and a server that is based on an out-of-band channel."  Please review the draft and indicate whether you support adoption or not by May 4, 2020.  
Thanks,

Joe


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


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--------------144DDE2ED70760B191F33F1D-- From nobody Tue Apr 28 06:07:24 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4163A15A0 for ; Tue, 28 Apr 2020 06:07:14 -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, HTML_MESSAGE=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 ooSoft3EEAgA for ; Tue, 28 Apr 2020 06:07:12 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 600AE3A14F5 for ; Tue, 28 Apr 2020 06:07:03 -0700 (PDT) Received: from lhreml730-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E64549F5C877FD00544E for ; Tue, 28 Apr 2020 14:06:58 +0100 (IST) Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Apr 2020 14:06:58 +0100 Received: from lhreml730-chm.china.huawei.com ([10.201.108.81]) by lhreml730-chm.china.huawei.com ([10.201.108.81]) with mapi id 15.01.1913.007; Tue, 28 Apr 2020 14:06:58 +0100 From: Sandeep Tamrakar To: EMU WG Thread-Topic: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt Thread-Index: AQHWFb4IpyjwNKnKSkOtCuON/tbUMaiOh6vg Date: Tue, 28 Apr 2020 13:06:58 +0000 Message-ID: <143283b0452c43fa820f3d9afdfad727@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.210.137] Content-Type: multipart/alternative; boundary="_000_143283b0452c43fa820f3d9afdfad727huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Emu] Working Group Call For adoption of draft-aura-eap-noob-08.txt 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, 28 Apr 2020 13:07:22 -0000 --_000_143283b0452c43fa820f3d9afdfad727huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0K V2UgYXJlIGN1cnJlbnRseSB3b3JraW5nIG9uIElvVCBib290c3RyYXBwaW5nIHNlY3VyaXR5IGFu ZCBhcmUgbG9va2luZyBhdCB2YXJpb3VzIHNvbHV0aW9ucywgb25lIG9mIHRoZW0gaXMgRUFQLU5P T0IuDQoNCndpdGggcmVnYXJkcywNClNhbmRlZXANCg0KRnJvbTogRW11IFttYWlsdG86ZW11LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb3NlcGggU2Fsb3dleQ0KU2VudDogMTggQXBy aWwsIDIwMjAgMjM6MTMNClRvOiBFTVUgV0cgPGVtdUBpZXRmLm9yZz4NClN1YmplY3Q6IFtFbXVd IFdvcmtpbmcgR3JvdXAgQ2FsbCBGb3IgYWRvcHRpb24gb2YgZHJhZnQtYXVyYS1lYXAtbm9vYi0w OC50eHQNCg0KVGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWF1cmEtZWFwLW5v b2ItMDgudHh0IFsxXSBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4gIFRoaXMgZHJhZnQgaGFzIGJl ZW4gZGlzY3Vzc2VkIGluIHNldmVyYWwgSUVURiBtZWV0aW5ncyBhbmQgd291bGQgYmUgdGhlIHN0 YXJ0aW5nIHBvaW50IGZvciB0aGUgd29ya2luZyBncm91cCBkZWxpdmVyYWJsZSBmb3IgYW4gRUFQ IG1ldGhvZCBiYXNlZCBvbiAibXV0dWFsIGF1dGhlbnRpY2F0aW9uIGJldHdlZW4gYSBwZWVyIGFu ZCBhIHNlcnZlciB0aGF0IGlzIGJhc2VkIG9uIGFuIG91dC1vZi1iYW5kIGNoYW5uZWwuIiAgUGxl YXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBvcnQgYWRv cHRpb24gb3Igbm90IGJ5IE1heSA0LCAyMDIwLg0KVGhhbmtzLA0KDQpKb2UNCg0KWzFdIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWF1cmEtZWFwLW5vb2IvDQo= --_000_143283b0452c43fa820f3d9afdfad727huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBzdXBwb3J0IHRoZSBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5XZSBhcmUgY3VycmVudGx5IHdvcmtpbmcgb24gSW9UIGJvb3RzdHJhcHBpbmcg c2VjdXJpdHkgYW5kIGFyZSBsb29raW5nIGF0IHZhcmlvdXMgc29sdXRpb25zLCBvbmUgb2YgdGhl bSBpcyBFQVAtTk9PQi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PndpdGggcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2FuZGVlcDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFbXUgW21h aWx0bzplbXUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9zZXBoIFNh bG93ZXk8YnI+DQo8Yj5TZW50OjwvYj4gMTggQXByaWwsIDIwMjAgMjM6MTM8YnI+DQo8Yj5Ubzo8 L2I+IEVNVSBXRyAmbHQ7ZW11QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRW11 XSBXb3JraW5nIEdyb3VwIENhbGwgRm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWF1cmEtZWFwLW5vb2It MDgudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhIGNh bGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LWF1cmEtZWFwLW5vb2ItMDgudHh0IFsxXSBhcyBhIHdv cmtpbmcgZ3JvdXAgaXRlbS4mbmJzcDsgVGhpcyBkcmFmdCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4g c2V2ZXJhbCBJRVRGIG1lZXRpbmdzIGFuZCB3b3VsZCBiZSB0aGUgc3RhcnRpbmcgcG9pbnQgZm9y IHRoZSB3b3JraW5nIGdyb3VwIGRlbGl2ZXJhYmxlIGZvciBhbiZuYnNwO0VBUCBtZXRob2QgYmFz ZWQgb24NCiAmcXVvdDttdXR1YWwgYXV0aGVudGljYXRpb24gYmV0d2VlbiBhIHBlZXIgYW5kIGEg c2VydmVyIHRoYXQgaXMgYmFzZWQgb24gYW4gb3V0LW9mLWJhbmQgY2hhbm5lbC4mcXVvdDsmbmJz cDsgUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGluZGljYXRlIHdoZXRoZXIgeW91IHN1cHBv cnQgYWRvcHRpb24gb3Igbm90IGJ5IE1heSA0LCAyMDIwLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJzcDs8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hdXJhLWVhcC1ub29iLyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYXVyYS1lYXAtbm9vYi88L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_143283b0452c43fa820f3d9afdfad727huaweicom_-- From nobody Thu Apr 30 06:19:36 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622233A098A for ; Thu, 30 Apr 2020 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 S1H1lAL8nzIq for ; Thu, 30 Apr 2020 06:19:32 -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 ACCD93A0985 for ; Thu, 30 Apr 2020 06:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4130; q=dns/txt; s=iport; t=1588252771; x=1589462371; h=from:mime-version:subject:message-id:date:to; bh=LSJ3q40M+G/KO1Bmuonz58Dz/uVdpypUdnLBbkg28tc=; b=kZzCef/RnV3cM7P7Ui/unJWckhRX7e2uMVLhIjkY1VzCkhl1084MaglM zLcSTZCeNRDfXmWg4GByhdmO/QRJtsOavUNINXPvVdd3lc8tN/cgp5sTw qHbI75Cn72UHfMwqtY1dRV0N+jRLb25LyZFmRhDqth6Fvb9CffiMsttN3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBQAfz6pe/xbLJq1mHgEBCxIMgXw?= =?us-ascii?q?LAoNqASASgUSDB4kBh2aFQI40hhCBewsBAQEMAQEvBAEBDocMNAkOAgMBAQs?= =?us-ascii?q?BAQUBAQECAQUEbYViQgEQAYVHdT4CX4M5gn2kGo4QdoEyhVCFLoE4AYpsgW6?= =?us-ascii?q?CAIERJwwQg3YZAYZbM4ItBLI1gk+CbpUZHZAHjQBEqQuDQwIEBgUCFYFSOYF?= =?us-ascii?q?WMxoIGxU7KgGCPz0SGA2LF4c8jjI/A2YCBgEHAQEDCYcvizsBAQ?= X-IronPort-AV: E=Sophos; i="5.73,334,1583193600"; d="scan'208,217"; a="25739481" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2020 13:19:27 +0000 Received: from [10.61.249.109] ([10.61.249.109]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 03UDJRex008640 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Apr 2020 13:19:27 GMT From: Eliot Lear Content-Type: multipart/alternative; boundary="Apple-Mail=_3DA7A9CD-FB58-4CEA-A617-3FB282604EC7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <7DF5C6C1-5176-417A-837F-4849262DFA35@cisco.com> Date: Thu, 30 Apr 2020 15:19:27 +0200 To: EMU WG X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.249.109, [10.61.249.109] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Emu] TEAP Request-Action TLV 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, 30 Apr 2020 13:19:35 -0000 --Apple-Mail=_3DA7A9CD-FB58-4CEA-A617-3FB282604EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All: Here is a circumstance one could easily imagine, and in fact we = attempted to address in draft-lear-eap-teap-brski: Client requires a new certificate for some reason or another. Perhaps = its is about to expire, or perhaps the signer has been compromised, or = what have you. We were thinking that we could use the Request-Action Frame for this = purpose with a type of PKCS#10. But that now seems wrong, as the = language in the draft states that one appends a Request-Action frame = with a full TLV, and not just a type, and further that the other end = process the TLV. In looking at Jouni=E2=80=99s code, he is doing = precisely that with the PAC TLV. And so it seems we have three choices: Create a new TLV that has a length of two that can be used in a = REQUEST_ACTION frame. Create a new TLV that is what we thought we meant: here is a list of = two(ish)-byte types whose TLVs I want you to send to me. Hard code the ordering of requests so everyone knows what to expect. Each of these has its own problems.=20 The first requires that we create a new EAP TYPE for TLV one end needs = the other to send, but it=E2=80=99s pretty easy to process. The second = requires extra processing but requires less standardization. The last = seems to go against the EAP model and reduces deployment flexibility. Thoughts? Eliot= --Apple-Mail=_3DA7A9CD-FB58-4CEA-A617-3FB282604EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All:

Here = is a circumstance one could easily imagine, and in fact we attempted to = address in draft-lear-eap-teap-brski:

Client requires a new = certificate for some reason or another.  Perhaps its is about to = expire, or perhaps the signer has been compromised, or what have = you.

We were thinking that we could use the Request-Action Frame = for this purpose with a type of PKCS#10.  But that now seems wrong, = as the language in the draft states that one appends a Request-Action = frame with a full TLV, and not just a type,  and = further that the other end process the TLV.  In looking at = Jouni=E2=80=99s code, he is doing precisely that with the PAC = TLV.

And so it = seems we have three choices:

  • Create a new TLV that has a length of two that can be used in a REQUEST_ACTION = frame.
  • Create a new TLV that is what we thought we = meant: here is a list of two(ish)-byte types whose TLVs I want = you to send to me.
  • Hard code the ordering of requests = so everyone knows what to expect.

Each of these has its own = problems. 

The first requires that we create a new EAP TYPE for TLV one = end needs the other to send, but it=E2=80=99s pretty easy to process. = The second requires extra processing but requires less standardization. =  The last seems to go against the EAP model and reduces deployment = flexibility.

Thoughts?

Eliot
= --Apple-Mail=_3DA7A9CD-FB58-4CEA-A617-3FB282604EC7-- From nobody Thu Apr 30 11:54:06 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BFB3A0EEF for ; Thu, 30 Apr 2020 11:54:03 -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=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 HXm5Z-82Cppb for ; Thu, 30 Apr 2020 11:54:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06AD43A0EF3 for ; Thu, 30 Apr 2020 11:53:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CDAF38983; Thu, 30 Apr 2020 14:51:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 52D1637D; Thu, 30 Apr 2020 14:53:39 -0400 (EDT) From: Michael Richardson To: Eliot Lear cc: EMU WG In-Reply-To: <7DF5C6C1-5176-417A-837F-4849262DFA35@cisco.com> References: <7DF5C6C1-5176-417A-837F-4849262DFA35@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Emu] TEAP Request-Action TLV 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, 30 Apr 2020 18:54:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > Here is a circumstance one could easily imagine, and in fact we > attempted to address in draft-lear-eap-teap-brski: > Client requires a new certificate for some reason or another. Perhaps > its is about to expire, or perhaps the signer has been compromised, or > what have you. I think that's a really bad example. I can talk about the reasons, but I think it would detract from your query. Maybe you can give me a different use case? > We were thinking that we could use the Request-Action Frame for this > purpose with a type of PKCS#10. But that now seems wrong, as the > language in the draft states that one appends a Request-Action frame > with a full TLV, and not just a type, and further that the other end > process the TLV. In looking at Jouni=E2=80=99s code, he is doing pre= cisely > that with the PAC TLV. > And so it seems we have three choices: > Create a new TLV that has a length of two that can be used in a REQUE= ST_ACTION frame. > Create a new TLV that is what we thought we meant: here is a list of > two(ish)-byte types whose TLVs I want you to send to me. > Hard code the ordering of requests so everyone knows what to expect. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6rHrMACgkQgItw+93Q 3WXE5Af/UkPtwudfcxbLEyz9hUUmCQ7QvhLAUoqQ7ewgPNqmkwsKvEMz01ANXg3s hEnTMlf7jgS32p6S7WNtiMFxYlK2md22qAShbGa8IdneUZsIEJ+GP5/N7wNv7GXN EXoU5ohXsNKKxxGfgElASUVlb50RGkEGZuxa304ReTXY8D63nh6zixzN1pkMqkG3 A2KSv40BOoQ08Nl/wJJuQoLRTB76H8K7O31EQ0oV9w8uPTGaAGmO+xEpSRhmnaO6 u3shdXrDr5FQ3wstSgHiJJikLTLKgdRAiBJ92s6yBwAFTG4eKDf5NnXwFtEl3/gr uNlp6uVYtayk+MIijB/Atx9kgijYMQ== =XBUo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 30 12:03:36 2020 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD92A3A0F44 for ; Thu, 30 Apr 2020 12:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, DKIM_VALID_EF=-0.1, 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 DS3jKZj57_Yj for ; Thu, 30 Apr 2020 12:03:29 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17553A0F5B for ; Thu, 30 Apr 2020 12:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2201; q=dns/txt; s=iport; t=1588273384; x=1589482984; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=XCu7vzEFYNL9J8ghsDSH4M8Ys61SneVgKR4Mhl3+pnw=; b=S3PkuumTJT0T7PLZPO+vsoQfT645Kquk1UuWZOyVWP3pAZXEuDXMllFk Fc6KGLPBtBVh7C8BOi1q/9liuu1DS/hNgbrt7iXir5XufTrvimrQo/eZx Tif70FaKTAI1LM2/H3toJHSXQ1xfijoNBwZeDrhf71l/HKu+B19NEeXHK c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAABEIKte/xbLJq1mGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYF0BQEBAQsBg2wgEiqEIokBiAuZYIF7BAcBAQEJAwE?= =?us-ascii?q?BLwQBAYREAoJUNQgOAgMBAQsBAQUBAQECAQUEbYVihXEBAQEBAgEjVgULCxg?= =?us-ascii?q?qAgJXBhODJgGCXCCzE3aBMoVQhRgQgTgBgVKJGoFuggCBESccgk0+axkBgWI?= =?us-ascii?q?EgUuDKjOCLQSOOIpKmUKCUIJugSSTeB2CW4hekVtEqR6DQwIEBgUCFYFUATa?= =?us-ascii?q?BVjMaCBsVZQGCPj4SGA2QWo4yPwMwAjQCBgEHAQEDCY87AQE?= X-IronPort-AV: E=Sophos;i="5.73,336,1583193600"; d="asc'?scan'208";a="25807430" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2020 19:03:02 +0000 Received: from ams3-vpn-dhcp747.cisco.com (ams3-vpn-dhcp747.cisco.com [10.61.66.235]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 03UJ31mL023650 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Apr 2020 19:03:02 GMT From: Eliot Lear Message-Id: <66DAEF8B-A59F-45B1-AEAB-B0434CA1D513@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_919C55BD-A9DF-4E53-938B-45C7E25E51A4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 30 Apr 2020 21:03:01 +0200 In-Reply-To: <19729.1588272819@localhost> Cc: Eliot Lear , EMU WG To: Michael Richardson References: <7DF5C6C1-5176-417A-837F-4849262DFA35@cisco.com> <19729.1588272819@localhost> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.66.235, ams3-vpn-dhcp747.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Emu] TEAP Request-Action TLV 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, 30 Apr 2020 19:03:32 -0000 --Apple-Mail=_919C55BD-A9DF-4E53-938B-45C7E25E51A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Apr 2020, at 20:53, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Eliot Lear wrote: >> Here is a circumstance one could easily imagine, and in fact we >> attempted to address in draft-lear-eap-teap-brski: >=20 >> Client requires a new certificate for some reason or another. = Perhaps >> its is about to expire, or perhaps the signer has been compromised, = or >> what have you. >=20 > I think that's a really bad example. I can talk about the reasons, = but I > think it would detract from your query. Certificate do need to roll, and we should handle that case. One could = use the ACME/LE model of just periodically sending a PKCS#10 request = after 2/3rds of the expiry is past, but that doesn=E2=80=99t help us in = the case where the signing cert needs to roll. > Maybe you can give me a different use case? A different use case might be (later on), =E2=80=9Cplease send me a RATS = attestation=E2=80=9D. The key point is that the EAP server is a good = control channel to gate clients in a lock step fashion, but the = Request-Action TLV doesn=E2=80=99t quite get us there, as written, as I = see it. Eliot --Apple-Mail=_919C55BD-A9DF-4E53-938B-45C7E25E51A4 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl6rIOUACgkQh7ZrRtnS ejMKNgf9GUf8Jhg4EKC8XIHBNvfxEB2pHyVg7GfU7HQWfRaiB15u79o/0MniQXA1 CbS/Wbd/XtB9o0Fb66o+ldpUJc4o3mGQghNxCaimycZwsDT4kUdGcVkkCVSFpOtX KX1himVqc5K3U/Gy4+0BT39UAqQsxbb00GIOK2hfEriTlZ0XgNcVLgTximKAxNaj txqyj+dVpgxVuXjV/Fail2yS+NWuDpYqOTf0vRnczomTtwXn/uzABWJUjn0OBPE8 6Q9jeRp6ZkL59L6faEBFHYX5KuDR9RRAAGUfn5Bnba2um30M2SW2jG0aWApLuHN0 Fc6l9BxnCeKphM/skivUXOV3rE+wTw== =b6Tj -----END PGP SIGNATURE----- --Apple-Mail=_919C55BD-A9DF-4E53-938B-45C7E25E51A4--