Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02

Alan DeKok <aland@deployingradius.com> Tue, 02 June 2020 13:09 UTC

Return-Path: <aland@deployingradius.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 8EECA3A08E3 for <emu@ietfa.amsl.com>; Tue, 2 Jun 2020 06:09:35 -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 dclKeIHenAA2 for <emu@ietfa.amsl.com>; Tue, 2 Jun 2020 06:09:33 -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 ED40D3A08E9 for <emu@ietf.org>; Tue, 2 Jun 2020 06:09:32 -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 2D0EAC4; Tue, 2 Jun 2020 13:09:29 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CH2PR21MB13812FAA89097AE25F72186DD18B0@CH2PR21MB1381.namprd21.prod.outlook.com>
Date: Tue, 02 Jun 2020 09:09:28 -0400
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <28E366D3-AEB0-49FF-A155-F4B08B47030E@deployingradius.com>
References: <CH2PR21MB13812FAA89097AE25F72186DD18B0@CH2PR21MB1381.namprd21.prod.outlook.com>
To: Jorge Vergara <jovergar=40microsoft.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/h0vUAp1IgYHi-ilXnHy0jd4hvcs>
Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02
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: Tue, 02 Jun 2020 13:09:36 -0000

On Jun 2, 2020, at 3:29 AM, Jorge Vergara <jovergar=40microsoft.com@dmarc.ietf.org> wrote:
>  
> I’ve attempted/completed a prototype implementation of EAP-TLS, PEAP, EAP-TTLS, and TEAP clients using TLS 1.3. EAP-TLS went smoothly so this boils down to a review of the subject line document which addresses the rest of the EAP types. I am not necessarily an expert on all of TLS 1.3 so some of my issues may just be a lack of understanding – please point this out if so.

  Thanks.  Is the source available somewhere?  It would be good to have multiple implementations for interoperability testing.

> I had the following questions/issues that may need to be addressed in this document:
>  
> 	• PEAP Key Material when crypto binding is used. When PEAP uses crypto binding, it uses a different key material calculation that consumes inner method key material. This is not addressed in this document. If we fallback to what is currently defined, we end up with PEAP’s definition of PRF+, which despite the name is hardcoded to SHA1. Since it’s hard-coded to SHA1 and doesn’t technically depend on the TLS-PRF, it technically could continue to be used. But, is there a desire to update this key material calculation as well to use the TLS-Exporter as with the rest of the calculations?  If not, I believe it’s still worth a mention, since I see it being a point of confusion.

  I'm happy to leave the PRF+ calculation alone.  It uses HMAC-SHA1, which seems fine.
>  
> 	• TTLS Implicit Challenge. The TLS-PRF is currently used to calculate the implicit challenge for CHAP, MS-CHAP, and MS-CHAP-V2 (non-EAP). This isn’t currently covered in the document. In TTLS, differing amounts of challenge material are needed based on whether CHAP, MS-CHAP, or MS-CHAP-V2 is being used. It’s probably sufficient to define one exporter of a suitable length for all three and truncate to the amount needed.

  I don't see that this needs to change, but it is worth a mention in the document.

  i.e. TTLS uses the TLS-PRF with a label of "ttls challenge".  The length of the challenge material can simply be taken from the requirements.  So we don't need to define multiple exporters.

> 	• TEAP Compound MAC. The TEAP Compound MAC is currently defined in terms of the “MAC function negotiated in TLS 1.2.” If TEAP is to remain in this document, I believe this should be clarified. Here my familiarity with TLS 1.3 becomes an issue as I am not sure whether this is a simple wording update or if the calculation needs to be re-defined. (as an aside, I am in favor of TEAP in this document but understand if the consensus is to separate it)

  I'm not sure here.

> 	• TEAP Inner Method Session Key. When an inner authentication method supports exporting an EMSK, the definition of the IMSK relies on the TLS-PRF and so needs to be adjusted. 

  OK.  I'm less sure of what should be done here.  I'll take a look.

> 	• Section 5 of this document is out of date with the EAP-TLS document. It mentions that an empty application record is used to indicate negotiation has finished – this is now a size 1 0x00 application record.

  Good point.  I'll update the doc.

> 	• Section 5 further mentions that methods which use inner tunnel methods should instead begin their inner tunnel negotiation by sending type specific application data. The inner tunnel is optional for PEAP, EAP-TTLS, and TEAP, especially if resumption is used.. So it’s not clear to me how to indicate negotiation has finished in these methods. I believe the 0x00 octet from EAP-TLS is needed here as well.

   I think so, yes.

> I appreciate the effort gone into this thus far. I believe the adjustments needed are fairly simple and after the above issues are solved I could complete my prototypes.

  I'll take a look this week.  I also hope to have FreeRADIUS updated for TLS 1.3, too.

  Alan DeKok.