Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Martin Thomson <> Tue, 05 January 2021 03:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 665B83A0E37; Mon, 4 Jan 2021 19:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
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: (amavisd-new); dkim=pass (2048-bit key) header.b=HepU8w07; dkim=pass (2048-bit key) header.b=QRUZDpZb
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fPdW4mpPAJ8I; Mon, 4 Jan 2021 19:50:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F0713A0E34; Mon, 4 Jan 2021 19:50:39 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 12BFD5C017E; Mon, 4 Jan 2021 22:50:38 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Mon, 04 Jan 2021 22:50:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=I0ji9+v3+Cf+ja/ZtTs+CpKPRmPo BU0o6zhAi+zUsnA=; b=HepU8w07hvufy/8wwu5SEgpeRdDD+EroclLc12SWHgP4 tRVR46LX/gRkMaQIK81vrelpVEaqWdJ2eaqYopvTPhiX6URGzocOK6U0IrXiZSlA LCByR4Y/u122eo7aLxjAL5w+nuwPQI4A9JE+mUNGllZPhdCLkUYeXrOM8oyqWImn Y+pe/mWOh32nYr4/c1byvP/ccMjEoztqq24/jzUlFCCqgSapZasXDf3tG1vHKmzv 81IVetINmYfNiQw/mDOHQ3gu05VJiychqeu5VC9onXE1IC0ilgYwXSJSu4J+tfZI 5ZrzdD9VpxQBXXqtaWg4EvRJixs+UgejlCMABMJWlw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc: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=fm1; bh=I0ji9+ v3+Cf+ja/ZtTs+CpKPRmPoBU0o6zhAi+zUsnA=; b=QRUZDpZb5+dj+vQgQ39DyK dJgcxkkLwgR469aBRJvqzjzqGz5p7lPshG8B4Z323BFgSlUcB6iiR2GYn6W4A9M6 fGOBeuw4qrLmjqL5pAZy125kngWWFQWkN3n15EZ9jy2DH25r/93fEcYCoAHo/UOL CSj9y5TsbfALnYxmsWNuzShO9t1sJ/qu80rCR8f5lNn9APhDnl/yU6EGkWINcrMY h2p/x/1+S1lVsuxVhPXcbsvBA6asX83ArnFM57VcMhHNKkEuzxJw+31+rhZ+70UN kmvjI2CCorkw+yVYvqtJLa0U4/g4ErSo2+alcwKtfgvBXvKF/cXGVFrw4jZQn8pQ ==
X-ME-Sender: <xms:DOLzX_bFAfGNxi0xD6MR-8w6uIoZ1FSgZtYpYz6gjgcg28ffJlTv4w> <xme:DOLzX-ZpWlC1g2h-405KdxTWRAKfRLezzsKIEEeRiyJ1aT2L0Z6pxN6qIjjp2cOs7 bh8xb0kfkTfU5q0kvg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefgedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepgfetveeihfdvgfdtieeugfeufeffieevtdeivddutdfhtedtvdej uddtleehieegnecuffhomhgrihhnpehmrghilhdqrghrtghhihhvvgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:DOLzXx8TDH1aB-FRP4yVajHSy91vJh1KXYQOv6dEyA57fAC_nFQ5zw> <xmx:DOLzX1pqyd5qGcoiJA2zdIgXLLO0zWv8G9o5sH5VA8D44s62vY4MxQ> <xmx:DOLzX6roiiQb9Q_YclzTKGr9KzgxgKSL42npnOf-cSmtXLKV4ZpL2Q> <xmx:DuLzXx2hxu80w0condTNSzpeQkxCWoWlJPK9_I608Hnn3YhmOKh50w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67C2720181; Mon, 4 Jan 2021 22:50:36 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 05 Jan 2021 14:50:15 +1100
From: Martin Thomson <>
To: Alan DeKok <>
Cc: Mohit Sethi M <>, 'Benjamin Kaduk' <>, "" <>, "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jan 2021 03:50:41 -0000

Hi Alan,

On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
> On Jan 4, 2021, at 6:26 PM, Martin Thomson <> wrote:
> > Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 and while it says "A peer MUST allow for this circumstance as described in this note.", I see no explanation of how to concretely make that allowance.  Are you saying that EAP methods don't really use EAP-Success and condition their behaviour on other signals?
>   EAP-Success by itself is *not* a reliable indication of Success.  See 
> RFC 3748 Section 4.2:
>    Success and Failure packets MUST NOT be sent by an EAP authenticator
>    if the specification of the given method does not explicitly permit
>    the method to finish at that point.

This is fine.  What you might be concerned about is the nature of the signals that the EAP authenticator is receiving from TLS.  What you had in the case of TLS 1.2 was the stack providing bytes to send (which were to go in EAP-Request) and then, after everything is done, a positive signal saying that the handshake was complete and satisfactory.  That latter signal is the important one.

TLS 1.3 muddies things by allowing bytes to be sent *after* the complete+satisfactory signal from TLS.  That's what you are grappling with here.  What I'm suggesting is that you don't rely on looking at what bytes hit the wire, but wait until two conditions are complete:

1. The TLS stack says that it is content: the handshake is complete and it is OK with whatever the other side has provided.
2. The TLS stack has no more bytes to send.

The latter is likely where the confusion comes from, but if the stack doesn't produce bytes when you give it bytes, then you don't need to keep waiting.  For what you depend on, that's enough.

The mistake with sending application data is that there is no obligation on the part of the TLS stack to order its sending of NewSessionTicket relative to the application data.  Nor is is possible for you to correctly distinguish TLS data that contains your Confirmation Message from a record that just contains a little bit of a session ticket.  But you don't need to worry about that.

An example might help illustrate:

1. ... many steps occur
2. Client sends EAP-Response ending in a TLS Finished.
3. Server reads that message, processes it and determines that the handshake is complete and acceptable (e.g., checks the client certificate against its policy).
4. As the server is happy, it writes the Confirmation Message to TLS.
5. Server asks TLS stack for outstanding data to write; TLS stack provides a bunch of application_data records.
6. Server writes TLS records into an EAP-Request and sends it.
7. Client receives this and sends an empty EAP-Response.
8. Server sends EAP-Success.

This is, I assume what you intend here, with a little more detail around steps 3-5.  But what happens if the TLS stack prioritizes application data above its own maintenance such that at step 5 the Confirmation Message is written to the wire before the TLS NewSessionTicket?  Is that a problem?  What validation is the client expected to perform at step 7?

>   With TLS 1.3, we don't know if the authentication has completed until 
> the TLS layer sees either (a) CloseNotify, or (b) application data.  So 
> the EAP-TLS implementations cannot distinguish a "finished 
> authentication" EAP-Success from a "spoofed" EAP-Success.  Because the 
> EAP-TLS implementation has no idea of TLS is done, and therefore no way 
> to tell that the EAP-Success is permitted at this point in the 
> negotiation.

As I indicated in my response to Mohit, if the intent is to provide the client with a signal, then using TLS application data to do that is imperfect, but probably OK.  What would have been ideal is some EAP-layer message that is authenticated somehow.

>   Therefore, we need an explicit signal to the EAP-TLS layer that the 
> EAP-TLS method has finished.  Discussion on the list went back and 
> forth between CloseNotify and sending one octet of application data.  
> Implementations have done both.  The conclusion was that the one octet 
> of application data was slightly easier to implement.
>   Plus, sending CloseNotify precluded the TLS layer from sending a TLS 
> Fatal Alert:, 
> which says in part:

I agree that sending a close_notify alert isn't ideal - during this process.  I also agree that making sure that genuine handshake failures are reported reliably using EAP-Request, that's just plain good sense.

I don't understand why you would want to send a fatal alert after successfully completing and accepting the handshake, but if that is something you care about, then that clearly rules out its use for signaling success.  I didn't suggest that.