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 <m...@lowentropy.net> 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/emu@ietf.org/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 > t...@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
