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

[Mohit Sethi M <[e-mail]>]

Hi again,

The following issues are related but not exactly the same:
1. indication from the server that the handshake is complete and it is 
okay to tear down the tunnel
2. indication from the server that no more post-handshake messages 
(containing NewSessionTicket or something else) will be sent.

We can't rely on EAP-Success as an indication of either since that 
message is never delivered to EAP-TLS and it maybe lost or spoofed. 
Ben's discuss arises from 2 and not 1. More at the end of the email.

On 1/5/21 7:26 AM, Benjamin Kaduk wrote:
> 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.
In figure 1 of the current EAP-TLS draft: 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13#section-2.1.1, 
the server already announces its intent of not issuing NewSessionTicket 
before receiving the client certificate (potentially saving one round 
trip). In figure 2: 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13#section-2.1.2, 
this is done after receiving the client certificate (causing one extra 
round trip but at the same time helping with resumption).

What I am gathering is that this commitment message should instead be 
made into a confirmation message, i.e. it should only be sent after 
receiving TLS Finished from the client? This would result in one extra 
round trip to both figure 1 and 3 in the current draft. So we would end 
up with the same number of messages as RFC 5216 for full authentication 
(https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do 
worse than RFC 5216 (one extra round trip) in case resumption 
(https://tools.ietf.org/html/rfc5216#section-2.1.2).

Maybe this is acceptable? The draft anyway notes that "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.". In which case, I am not sure if the 
reasons against using close_notify apply anymore.

--Mohit
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls