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

[Martin Thomson <[e-mail]>]

Hi Alan,

On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
> On Jan 4, 2021, at 6:26 PM, Martin Thomson <[e-mail]> 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:  https://www.mail-archive.com/[e-mail]/msg03092.html, 
> 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.