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

[Benjamin Kaduk <[e-mail]>]

Hi Martin,

Thanks for chiming in here; your insight has been quite helpful already.
(I am going to reply to the thread in reverse order so as to not duplicate
what you've already said.)

On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
> 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.

Yes.  Part of what had me so unhappy about this document is that the
Commitment Message is discussed only as a "promise to not send more
handshake messages", not "an indication that the handshake is complete and
the TLS layer is happy".  (Furthermore, what Alan writes below about
"cannot distinguish a "finished authentication" EAP-Success from a
"spoofed" EAP-Success" really needs to make its way into the document.)

> 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.

I agree that this is probably good enough.  There may be some complications
depending on how badly the availability of session resumption is desired (I
know OpenSSL provides an API to let the application requst a new session
ticket regardless of whether any were sent with the initial handshake -- I
wrote it -- though I need to tweak it so that it will not always wait for
application data to send before sending the ticket), but I believe this
provides the key functionality.

> 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.

(In particular, this is the TLSCiphext content type that is
"application_data", and the inner content type could be handshake or
application data.  The application doesn't have visibility into it.)

> 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?

I would like to see a more precise description of what properties are
actually needed by peer and responder here, yes.  I agree that TLS 1.3 has
changed things compared to 1.2, but the text currently in the draft doesn't
do very well to motivate why this information is important, and (at least
to me) doesn't give a strong enough justification to merit the awkwardness
of the proposed design.

> >   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.

This somewhat gets into another point that I was hoping would be discussed
more.  (The proposal for "close_notify" came up as the in-TLS way to
signify "no more records coming", which includes "no more handshake records
coming".)  The perceived issue with "close_notify" as the commitment
message, clearly discussed in the linked message, is that "close_notify" is
unsuitable as a commitment message when being sent in the same flight as
server Finished.  What is very unclear to me is how often that state could
actually be achievable.  For one, if we do move (per the previous
discussion) to the state where the "TLS is done" signal is something like
"TLS says it's done and has no more bytes to send", this situation *by
definition* cannot occur, since TLS will not report the handshake as
complete until client Finished is processed.  Even if we ignore that,
though, we have to consider the interaction between resumption and client
authentication.

My understanding is that EAP is primarily used as a mutual authentication
protocol, i.e., the client has a certificate it's going to use to
authenticate, and the EAP Peer's identity is the identity from that
certificate.  The desire to send the commitment message in the same flight
as the server Finished stems from the desire to avoid another round-trip.
But using TLS resumption will *also* save round trips, and in these
pessimal cases where the certificate chains are huge, resumption will save
a lot more than one round-trip.  But, if you send the commitment message
with the server Finished, you can't send a NewSessionTicket that includes
the client certification information at all.  So by gaining the 1 RTT from
moving up the commitment message, you sacrifice a lot more RTTs by losing
resumption.  Given my priors about how this is going to be used, that seems
like a lousy tradeoff.  I'm happy to hear that I'm making invalid
assumptions here, but it seems like you would only be able to take
advantage of that 1 RTT gain from the commitment message for the case of
unauthenticated clients, in expected deployments, and unauthenticated
clients seem to be rare.

-Ben