Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling
Jim Schaad <ietf@augustcellars.com> Mon, 13 July 2020 18:31 UTC
Return-Path: <ietf@augustcellars.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 BD01E3A1692 for <emu@ietfa.amsl.com>; Mon, 13 Jul 2020 11:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 fDvJPWHSsBJC for <emu@ietfa.amsl.com>; Mon, 13 Jul 2020 11:31:03 -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 6AC7A3A1686 for <emu@ietf.org>; Mon, 13 Jul 2020 11:31:02 -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; Mon, 13 Jul 2020 11:30:52 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mohit Sethi M' <mohit.m.sethi@ericsson.com>, emu@ietf.org
CC: 'Alan DeKok' <aland@deployingradius.com>, j@w1.fi, 'Roman Danyliw' <rdd@cert.org>, 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>
References: <1dbd00fc-0031-7198-5a0b-1f107dba942b@ericsson.com>
In-Reply-To: <1dbd00fc-0031-7198-5a0b-1f107dba942b@ericsson.com>
Date: Mon, 13 Jul 2020 11:30:49 -0700
Message-ID: <000001d65943$bdba9190$392fb4b0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D65909.115C55D0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH4M7yOapq8H5rAk9X9j99TstXjpajCH8bA
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/MkS-pes6cLiZzFnGHqPMXCkCCuc>
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling
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, 13 Jul 2020 18:31:05 -0000
My expectation would be that the third option from Hannes is what should be done. The commit message should be encrypted and not a plain text message. Jim From: Mohit Sethi M <mohit.m.sethi@ericsson.com> Sent: Monday, July 13, 2020 10:44 AM To: emu@ietf.org Cc: Jim Schaad <ietf@augustcellars.com>; Alan DeKok <aland@deployingradius.com>; j@w1.fi; Roman Danyliw <rdd@cert.org>; Hannes Tschofenig <Hannes.Tschofenig@arm.com> Subject: Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling Dear all, draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD Followup". Our AD (Roman) had done an excellent review (https://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), which I addressed in version 10 (https://mailarchive.ietf.org/arch/msg/emu/IopJTjefyVVKpObzyFc0CAJ-Pig/). The only outstanding issue is the handling of the commitment message. The current text in the draft says the following: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handshake messages. The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 implementation. He made 3 alternative suggestions for achieving the functionality of the commitment message (https://mailarchive.ietf.org/arch/msg/emu/eM-14QdDQjg7DvhAVJMzpvPz5wg/). I would like to close this issue and would like to receive feedback from others who have commented before or are working on implementations: Jim, Alan, Jouni; please let us know what do you think about the change? --Mohit
- [Emu] Finishing draft-ietf-emu-eap-tls13 - Commit… Mohit Sethi M
- Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Co… Alan DeKok
- Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Co… Jorge Vergara
- Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Co… Jim Schaad
- Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Co… Mohit Sethi M
- Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Co… Jim Schaad