Re: [Emu] Re-charter text

Mohit Sethi M <mohit.m.sethi@ericsson.com> Mon, 02 September 2019 10:35 UTC

Return-Path: <mohit.m.sethi@ericsson.com>
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 675D2120073 for <emu@ietfa.amsl.com>; Mon, 2 Sep 2019 03:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwQMF0kwszUk for <emu@ietfa.amsl.com>; Mon, 2 Sep 2019 03:35:25 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::612]) (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 802EC12006B for <emu@ietf.org>; Mon, 2 Sep 2019 03:35:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dIxiRDXHEARpa6QRqq19GoU8VP/X/TzAgqfSIj4BOhNnPOtu5K+oXVUA5oxmUWHtyYbXvmjIVQqOx8117KG2KfNSjc/xlBIzz4AppflgejD/Hm8CCtavJXjIt7aDjERots9ahBHmuxvqAhgirbwPXZZhsA5UB2fJamRyGBvtXefnL01hQPo1AAwqP/HdAZvB8rnNwqknCIxRjwulwDJxg5f7oYX1vEm00mGtDKN+HGGAeT6IqTUqXybIjDIVHPPO50Zy/Ag8Fhe/AaZB6WruTMfifhJSn/Qo04C4Y3ODc437hKs8Za2dX6wZJChoQD0PmNSQGwQsuDUc3NRM51QZ/A==
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=ddBSoXoOTKHz/kaghciBVg7cHcEawRNX6BFc+C6Ku4I=; b=fmbvWZVAY6I2eJAVD+xPFeeY3ByTqfhHeNmeJfmwHl6ydya+DryeVgukgQmzrUFKecvHq4ZQeCbqkkwTNtPSINUU9FL0mi6xUBfbUodfwCRwLjIbLF5uEdXzZiqGMZJk+eMz94xypqoJzscmj3mGD13cjg21uM/Eyn8LmucYziuqkXMmKJXVBx64MyP9blmg8tIjcXxMoN8b+cp88pF6MN1eYPL1+IPO3TWaX1BlTb5f8GSw903ur+pOZR2pBqud2WmsKrhDgNvQwpLwh+yxOdXGsqdSlekyKxN74JQfJcRPmwnyuSmwVvHS4DuCDr9x3Si0oLbxrgXPVUdEO4jvyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ddBSoXoOTKHz/kaghciBVg7cHcEawRNX6BFc+C6Ku4I=; b=ZTRfDWDB6q6LikMgDUB9a+zYnlq8T+ukDn6vpTa3J02l6pLalc+0AwA9Jwjx66IznsvH/ul4wAqOrqfwZridN/nQMeXi3nroEQCpzB7drPeIA1l8ADrG5SK8HpQGozFZT5h5NtyZBgN/6GAUynOpt2aqsT0SDtmqd33x0d0E4mU=
Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB3034.eurprd07.prod.outlook.com (10.168.93.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.12; Mon, 2 Sep 2019 10:35:21 +0000
Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9%10]) with mapi id 15.20.2241.012; Mon, 2 Sep 2019 10:35:21 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Rene Struik <rstruik.ext@gmail.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>
CC: "emu@ietf.org" <emu@ietf.org>
Thread-Topic: [Emu] Re-charter text
Thread-Index: AQHVV/hd5AP1y7w6BUWxMRLUThUF06cNlQIAgAqvS4A=
Date: Mon, 02 Sep 2019 10:35:21 +0000
Message-ID: <e58bc3b0-2ab1-40ed-8237-1b5249172d94@ericsson.com>
References: <ae492726-6268-5e73-338b-c80369023e1c@ericsson.com> <e91549aa-7af9-cde5-51b4-1685542a7259@gmail.com>
In-Reply-To: <e91549aa-7af9-cde5-51b4-1685542a7259@gmail.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:60.0) Gecko/20100101 Thunderbird/60.8.0
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com;
x-originating-ip: [2001:14bb:180:4df:de17:5607:1db3:ef62]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 958d81f7-14a8-4657-bc09-08d72f9141e1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0701MB3034;
x-ms-traffictypediagnostic: HE1PR0701MB3034:|HE1PR0701MB3034:
x-ms-exchange-purlcount: 2
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB3034B37FCFB782AC851B822FD0BE0@HE1PR0701MB3034.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(396003)(39860400002)(346002)(199004)(189003)(6116002)(5660300002)(14454004)(46003)(606006)(2616005)(476003)(486006)(36756003)(6506007)(53546011)(446003)(11346002)(186003)(102836004)(76176011)(86362001)(6246003)(31686004)(478600001)(31696002)(4326008)(25786009)(966005)(65806001)(65956001)(7736002)(229853002)(71190400001)(110136005)(58126008)(2906002)(6512007)(54896002)(6306002)(6436002)(8936002)(316002)(81166006)(81156014)(8676002)(53936002)(236005)(64756008)(66476007)(66446008)(66946007)(76116006)(66556008)(256004)(14444005)(99286004)(6486002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3034; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Li54kYoRUdJz1+uEc+OvpTx+w5Ef34aeMMiZsbdtVdNAkCOqq3EgixF14vQl2e18DWt/muM367WMGbp4yVGjT6Z0XQ2QH87mIapppFtVAgKsB6RmZ4f5fqE8syUrsTxv62q07+alQeJ6lbxtUsa5db2DEd6nBjW5w41ntumKYE+8DhzGK/FOD8uq42cbjm0gTMxvvRnqIOtlZZk2vPkIgxNjazLQcMaXtkbwoi0FG3h200gewrRH0NXFufCHkyVf0lPDWS1qv4+Myu76mDHL03NJS3RxiV8eJs2AHJIJsMtWAW/klVne9qtyYJ1GpSpw/NQqXjqC1sx2gulr2+CHCXuemWTqnu+qoh2l08grCTFqIZnsDeF/b+J540VyVDUXPcJzfRi/bklkms8kNvrDpLr/fomk+GrenVPGJVneAyw=
Content-Type: multipart/alternative; boundary="_000_e58bc3b02ab140ed82371b5249172d94ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 958d81f7-14a8-4657-bc09-08d72f9141e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2019 10:35:21.6491 (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: JdpnpbO2Pt9Pj2Dso61xE2omi3CPaiOWQrf8eNUuMQDFvzSzlfRN9EDDmDjKM/aElq9HZ1/51dTEW6IC236Z/rHMS6IJf8aeBUDMPGBwEJA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3034
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/YGDim0VU1PPOeMdFTw2Wr_LXEZ8>
Subject: Re: [Emu] Re-charter text
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 10:35:28 -0000

Hi Rene,

Thank you for the suggestion. It makes sense. I will update the text accordingly.

--Mohit

On 8/26/19 6:25 PM, Rene Struik wrote:

Hi Mohit:

I read the proposed recharter text and suggest a tiny change in the dashed work item below: change "shall" to "should". With "shall" language, the out-of-band characteristics of the most stringent such channel imposes the design constraints, which is not the case with "should" language. Here, one should note that certain OOB channels for sensor devices may not have sufficient bandwidth for conveying, e.g., a representation of a public key (if that is one of the intended methods one wishes to use), whereas this would be easy for devices with camera on-board. If the intention is to have a method that is truly independent of the OOB channel and wants the charter text to nail this, that is fine, but one has to be ware that this may limit applicability in some use cases; otherwise, simply making this a "should" leaves some wiggle room. There may be other cases, where characteristics of OOB channel may impact design space and where some wiggle room in the charter may not hurt.

Suggested modification (change underlined):

- Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself should be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light.

Best regards, Rene

-------- Forwarded Message --------
Subject:        [Emu] Re-charter text
Date:   Wed, 21 Aug 2019 08:13:51 +0000
From:   Mohit Sethi M <mohit.m.sethi@ericsson.com><mailto:mohit.m.sethi@ericsson.com>
To:     emu@ietf.org<mailto:emu@ietf.org> <emu@ietf.org><mailto:emu@ietf.org>



Dear all,

Thank you for a productive meeting @ IETF 105. We had discussed the new charter text during the working group session in Montreal. Please find the same text below. This text builds upon our current charter. Feel free to suggest changes. RFC 2418 section 2.2 https://tools.ietf.org/html/rfc2418#section-2.2 says the following about a working group charter:

   2. Specifies the direction or objectives of the working group and
      describes the approach that will be taken to achieve the goals;

Please keep this in mind when suggesting changes. Once the text is ready, we will send it to the IESG for review.

Joe and Mohit

------------------------

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used, for instance, in VPN and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Several EAP methods have been developed at the IETF and support for EAP exists in a broad set of devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol specification and the development of several standards track EAP methods.

EAP methods are generally based on existing security technologies such as TLS and SIM cards. Our understanding of security threats is continuously evolving. This has driven the evolution of several of these underlying technologies. As an example, IETF has standardized a new and improved version of TLS in RFC 8446. The group will therefore provide guidance and update EAP method specifications where necessary to enable the use of new versions of these underlying technologies.

At the same time, some new use cases for EAP have been identified. EAP is now more broadly in mobile network authentication. The group will update existing EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. Perfect Forward Secrecy (PFS) is an important security property for modern protocols to thwart pervasive monitoring. The group will therefore work on an extension to EAP-AKA' for providing Perfect Forward Secrecy (PFS).

Out-of-band (OOB) refers to a separate communication channel independent of the primary in-band channel over which the actual network communication takes place. OOB channels are now used for authentication in a variety of protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users are accustomed to tapping NFC or scanning QR codes. However, EAP currently does not have any standard methods that support authentication based on OOB channels. The group will therefore work on an EAP method where authentication is based on an out-of-band channel between the peer and the server.

EAP authentication is based on credentials available on the peer and the server. However, some EAP methods use credentials that are time or domain limited (such as EAP-POTP), and there may be a need for creating long term credentials for re-authenticating the peer in a more general context. The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials.

In summary, the working group shall produce the following documents:

 - An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). This document will pdate the security considerations relating to EAP-TLS, document the implications of using new vs. old TLS versions, add any recently gained new knowledge on vulnerabilities, and discuss the possible implications of pervasive surveillance.

 - Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. Provide guidance or update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on erratas found in published specifications (such as EAP-TEAP).

- Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, and EAP-AKA’. The lack of this definition is a recently discovered bug in the original RFCs.

- Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance.

- Develop an extension to EAP-AKA' such that Perfect Forward Secrecy can be provided. There may also be privacy improvements that have become feasible with the  introduction of recent identity privacy improvements in 3GPP networks.

- Gather experience regarding the use of large certificates and long certificate chains in the context of EAP-TLS (all versions), as some implementations and access networks may limit the number of EAP packet exchanges that can be handled. Document operational recommendations or other mitigation strategies to avoid issues.

- Define a standard EAP method for mutual authentication between a peer and a server that is based on an out-of-band channel. The method itself shall be independent of the underlying OOB channel and shall support a variety of OOB channels such as NFC, dynamically generated QR codes, audio, and visible light.

- Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials.

The working group is expected to stay in close collaboration with the EAP deployment community, the TLS working group (for EAP-TLS work), and the 3GPP security architecture group (for EAP-AKA' work)

------------------------



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