Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote: > Alan DeKok writes: > > >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages > >*after* the Finished message. i.e. the Session Ticket, etc. When an > >application calls SSL_Read(), all of the TLS data is processed, instead of > >just the "TLS finished" message. They've made this the default, because most > >applications get it wrong. > > Asking as the author of a TLS library that has always done this, why would you > stop immediately after the Finished and leave metadata messages sitting unread > in the input stream? Was it just some arbitrary implementation decision, or > is there a technical reason for it? I expect (but did not attempt to validate) that this was SSLeay-vintage logic involving only reading a single record from the wire per call to SSL_read(). If that record was a handshake record and not application data, well, then the SSL_read() didn't do something useful and so the special "try again" code was returned and the application was supposed to call SSL_read() again. There's no technical reason that I'm aware of. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Alan DeKok writes: >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages >*after* the Finished message. i.e. the Session Ticket, etc. When an >application calls SSL_Read(), all of the TLS data is processed, instead of >just the "TLS finished" message. They've made this the default, because most >applications get it wrong. Asking as the author of a TLS library that has always done this, why would you stop immediately after the Finished and leave metadata messages sitting unread in the input stream? Was it just some arbitrary implementation decision, or is there a technical reason for it? Peter. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk wrote: > On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > > DISCUSS: the EAP-TLS draft should also explain that session tickets > may be sent either before or after the 0x00 octet. Does the packet flow > look any different for the two cases? If so, what does that mean? > > > > > > [Joe] I believe the flow of the message flights would be the same, but > the on-the-wire format of those flights could be reversed. I don't think > this will necessarily cause a problem since the application data is > consumed by the EAP TLS and the NewSessionTicket is consumed by TLS, > However I think the draft should be clear that this can happen. > > > > I think so, too. > > I think we should talk about that, yes. > But I haven't managed to convince myself yet that it is 100% safe in the > face of fragmentation -- can we rule out a case where we end up delivering > an EAP-TLS message that ends exactly at the end of the application data > record (say, if bundled along with the tail end of the server handshake > flight) and there is a NewSessionTicket queued that would get fragmented > into the next EAP-TLS message? > > [Joe] As Alan points out, the peer should parse all fragments to get the complete message and pass them all to the TLS layer. It would be good to call this out, but I don't think it should be a problem for implementations. For example, if the peer is notified that application data is available before it has finished passing all the data to the TLS layer it should pass the rest of the data to the TLS layer before responding. > > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note > that this examples does not include Session Tickets. Section 2.1.2 should > be updated to note that there are more rounds than for the previous section. > > > > > > [Joe] Yes. It might be helpful to say that the commitment message may > be sent before or after the client authentication is verified, but in the > case that resumption is used it will always be after. > > > > I think that's a good idea. The current draft doesn't make this > explicit. > > > > But... if the commitment message is sent before the client > certificates have been authenticated, what does that commitment message > *mean*? > > > > i.e. can the server send the commitment message, ignore the client > cert information, and send an EAP-Success? Even if the client certs have > expired, been revoked, etc.? Can the client detect a rogue server which > always answers "yes"? > > That's a scenario that I was starting to puzzle over this weekend as well > -- with EAP-Success "completely unauthenticated", it would be fairly easy > for an on-path attacker to send the EAP-Success the EAP peer was expecting > and make the EAP peer think things succeeded even if the server had > rejected the client cert. Now, a server that has rejected the client cert > is hopefully not going to be exporting the keys and continuing to run the > next steps of protocol operation, but to some extent it seems that the > security of the system as a whole relies on the server operating correctly > in this regard. Strictlys speaking, it need not do so -- we could have > defined a mechanism where the exported keys depend, cryptographically, on > the client authentication flight such that the TLS layer will not produce > the needed keys on failed authentication. [0] > > [Joe] This could be also a difference between EAP-TLS 1.2 and EAP-TLS 1.3. In 1.2, the server's finished came second so, if the server rejected the peer certificate it could abort before sending the finished and the client's state machine would not be able to continue. However, 5216 section 2.1.3, suggests that errors should be sent after the finished which means they could be removed from the conversation and the peer would be none the wiser. It seems the behavior between 1.2 and 1.3 would be similar in this regard. I'm assuming that people will not be terribly keen on switching to such a > scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter > variant that includes the full transcript hash, [1] not just up to Server > Finished, which would incur at a minimum several months' delay. It might > be worth asking the teams that did formal analysis work on TLS 1.3 how they > modelled client authentication and what assumptions on server behavior they > made. > > So, if we do not wait for a cryptographic method to assure successful > client authentication, and thus are going to be stuck requiring some amount > of trust that the server is doing the right thing with the keys, how is it > different to say that the server is going to not export the keys if the > client authentication fails vs saying that the server is going to not > export the keys if it is not done sending handshake messages? There is > perhaps some detail in terms of how EAP-TLS interacts with the
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Alan, With my apologies to everyone on the thread for so many mails in succession... On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk wrote: > > With respect to the exporter usage, I do see you had asked about using the > > type-code as the exporter context value that Martin didn't see much value > > in, but I am willing to accept that as a boon for safety of portability to > > other TLS-using EAP mechanisms. > > OK. > > > (I do note that the current editor's copy > > shows calls to TLS-Exporter() with only two arguments, but three are > > required; the construction there also seems to include a propspect for > > violation of the requirement that "one label is not a prefix of any other > > label" when both regular one-byte and extended type codes are used, but if > > the type code is meant to be the context argument I believe that risk goes > > away.) > > The EAP type codes are one octet: 0x00 through 0xfd. The "expanded" type > codes begin with 0xfe. So there is no prefix issue, even if the type codes > form part of the label. Ah, of course I should have realized that the 0xfe octet separates them. You are correct; there is no issue with prefixes, and sorry for the confusion. Thanks, Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
Hi Mohit, The quoting in your note is not coming across usefully in my MUA, so I'm trimming to (what I think are) just your remarks without other history. On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote: > Hi Ben, > > RFC 5705 says: > >If no context is provided, it then computes: > >PRF(SecurityParameters.master_secret, label, >SecurityParameters.client_random + >SecurityParameters.server_random >)[length] > >If context is provided, it computes: > >PRF(SecurityParameters.master_secret, label, >SecurityParameters.client_random + >SecurityParameters.server_random + >context_value_length + context_value >)[length] > > > We use only two arguments and say "No context data is used in the TLS > exporter interface.". We could show the context argument as empty in the > calls to make things clearer. By the way, this is what is done by TEAP also. > RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined > in [RFC5705] to derive the session_key_seed. The label used in the > derivation is "EXPORTER: teap session key seed". The length of the session > key seed material is 40 octets. No context data is used in the export > process." We're using the TLS 1.3 exporter, though, so the RFC 8446 (https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument form seems most relevant. Note that there is no difference in TLS 1.3 between an absent context and a zero-length context. > The change of moving the type-code from the context to the label was made > based on your review (comments from Martin) and the fact that some libraries > such as wolfssl don't support passing a context (so far). See: > https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996 I'm not going to get super hung-up on label vs context (but it's clearly a bug if WolfSSL doesn't support contexts). I guess Martin even wanted the type code to be in the label part in the first place, so having it in the label is "better"; we just need to actually show that there's an empty context argument. > I think there was a misunderstanding that an authenticated signal of > authentication completed was needed. Only a signal of no more post handshake > messages was needed. I think Alan's summary might also explain the situation > better. I note that Alan seems to also be a bit unclear about exactly what purpose the commitment message serves; I look forward to seeing how the questions he has listed get answered. Thanks, Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote: > On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > > sent either before or after the 0x00 octet. Does the packet flow look any > > different for the two cases? If so, what does that mean? > > > > [Joe] I believe the flow of the message flights would be the same, but the > > on-the-wire format of those flights could be reversed. I don't think this > > will necessarily cause a problem since the application data is consumed by > > the EAP TLS and the NewSessionTicket is consumed by TLS, However I think > > the draft should be clear that this can happen. > > I think so, too. I think we should talk about that, yes. But I haven't managed to convince myself yet that it is 100% safe in the face of fragmentation -- can we rule out a case where we end up delivering an EAP-TLS message that ends exactly at the end of the application data record (say, if bundled along with the tail end of the server handshake flight) and there is a NewSessionTicket queued that would get fragmented into the next EAP-TLS message? > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that > > this examples does not include Session Tickets. Section 2.1.2 should be > > updated to note that there are more rounds than for the previous section. > > > > [Joe] Yes. It might be helpful to say that the commitment message may be > > sent before or after the client authentication is verified, but in the case > > that resumption is used it will always be after. > > I think that's a good idea. The current draft doesn't make this explicit. > > But... if the commitment message is sent before the client certificates > have been authenticated, what does that commitment message *mean*? > > i.e. can the server send the commitment message, ignore the client cert > information, and send an EAP-Success? Even if the client certs have expired, > been revoked, etc.? Can the client detect a rogue server which always > answers "yes"? That's a scenario that I was starting to puzzle over this weekend as well -- with EAP-Success "completely unauthenticated", it would be fairly easy for an on-path attacker to send the EAP-Success the EAP peer was expecting and make the EAP peer think things succeeded even if the server had rejected the client cert. Now, a server that has rejected the client cert is hopefully not going to be exporting the keys and continuing to run the next steps of protocol operation, but to some extent it seems that the security of the system as a whole relies on the server operating correctly in this regard. Strictlys speaking, it need not do so -- we could have defined a mechanism where the exported keys depend, cryptographically, on the client authentication flight such that the TLS layer will not produce the needed keys on failed authentication. [0] I'm assuming that people will not be terribly keen on switching to such a scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter variant that includes the full transcript hash, [1] not just up to Server Finished, which would incur at a minimum several months' delay. It might be worth asking the teams that did formal analysis work on TLS 1.3 how they modelled client authentication and what assumptions on server behavior they made. So, if we do not wait for a cryptographic method to assure successful client authentication, and thus are going to be stuck requiring some amount of trust that the server is doing the right thing with the keys, how is it different to say that the server is going to not export the keys if the client authentication fails vs saying that the server is going to not export the keys if it is not done sending handshake messages? There is perhaps some detail in terms of how EAP-TLS interacts with the TLS layer and what information is available when, but it seems that if you have an interface with TLS of "provide input bytes; get output bytes out" [2] you could achieve this by not exporting keys until you've sent all those bytes into EAP-TLS messages. > RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine > for EAP peer and server. Does this work follow that? A good question! > > [Joe] If we are going to make a change in the key derivation we should do > > it now. Personally, I think we should update the key derivation to > > separate the MSK and EMSK, but it is workable as is. > > I think there are potential issues around the ordering of the 0x00 octet > > and other messages, but I don't think this will require changes to > > implementations in the short term, but the spec needs to clarify this. > > I agree. I wonder if (assuming that 0x00 goes forward instead of "close_notify") we should also go further and say that this mechanism does not use stock TLS 1.3, but rather a variant of the protocol that imposes an additio
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Jan 29, 2021, at 5:35 PM, Jorge Vergara wrote: > > [Jorge] The diagrams in the draft mostly imply that the commitment message > being the last thing sent, after any NewSessionTicket. As stated, this is > problematic since the TLS stack may re-order these, and the NewSessionTicket > may have to come in another EAP-TLS fragment entirely if the combined message > ends up crossing a fragment boundary. > > In my mind, it is obvious that the rest of the EAP-TLS packet should be > processed so that the EAP-TLS client can correctly receive the > NewSessionTicket and any other handshake data that may have been in this > final message. OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages *after* the Finished message. i.e. the Session Ticket, etc. When an application calls SSL_Read(), all of the TLS data is processed, instead of just the "TLS finished" message. They've made this the default, because most applications get it wrong. It would be good for the draft to note that TLS libraries should process all of the TLS messages before handing application data over to the application. > However, once that complete EAP-TLS packet is processed, the next message > from the server should indeed be an EAP-Success, EAP-Failure, or EAP-Request > with a TLS Alert Message as draft-13 indicates. Section 2.1.1. says: After the EAP-TLS server has recieved a EAP- Response to the EAP-Request containing the Commitment Message, the EAP-TLS server sends EAP-Success. Which *could* be seen as mandating EAP-Success, no matter what certificate is sent by the client. I suggest making this behaviour clearer. i.e. the document should include something like your sentence above. > This is currently how the Windows client implementation operates, but it is > mostly by chance. If we made the full processing of the EAP-TLS packet > explicit, then I think this would resolve the concerns around ordering here. I agree. I would also like clarification on just what the commitment message does, and why it's needed here, and not for TLS 1.2. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Jan 29, 2021, at 5:00 PM, Joseph Salowey wrote: > DISCUSS: the EAP-TLS draft should also explain that session tickets may be > sent either before or after the 0x00 octet. Does the packet flow look any > different for the two cases? If so, what does that mean? > > [Joe] I believe the flow of the message flights would be the same, but the > on-the-wire format of those flights could be reversed. I don't think this > will necessarily cause a problem since the application data is consumed by > the EAP TLS and the NewSessionTicket is consumed by TLS, However I think the > draft should be clear that this can happen. I think so, too. > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this > examples does not include Session Tickets. Section 2.1.2 should be updated > to note that there are more rounds than for the previous section. > > [Joe] Yes. It might be helpful to say that the commitment message may be > sent before or after the client authentication is verified, but in the case > that resumption is used it will always be after. I think that's a good idea. The current draft doesn't make this explicit. But... if the commitment message is sent before the client certificates have been authenticated, what does that commitment message *mean*? i.e. can the server send the commitment message, ignore the client cert information, and send an EAP-Success? Even if the client certs have expired, been revoked, etc.? Can the client detect a rogue server which always answers "yes"? RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine for EAP peer and server. Does this work follow that? > [Joe] If we are going to make a change in the key derivation we should do it > now. Personally, I think we should update the key derivation to separate the > MSK and EMSK, but it is workable as is. > I think there are potential issues around the ordering of the 0x00 octet and > other messages, but I don't think this will require changes to > implementations in the short term, but the spec needs to clarify this. I agree. There's also the question of *why* the commitment message is there. It's not in EAP-TLS for TLS 1.2. The draft doesn't explain why it's not needed in TLS 1.2, but is needed for TLS 1.3. Such an explanation would go a long way to clarifying many issues around the commitment message. > So if we later discover that EAP-TLS is flawed, we can only deprecated > EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type code. > > [Joe] Perhaps we could use an expanded EAP-Type for the alpha? Or perhaps > experimental or a temporary experimental allocation could be made (not sure > if that would be possible). I think the issue for MS is less "alpha" code than "shipping" code. If we use an experimental type, it doesn't matter if it's interoperable, because people won't deploy it in production. Implementors are already verifying code behind the scenes in builds which aren't shipped to customers. So the type code is less of an issue, because that interoperability is "inter-engineer", and not "inter-customer". Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
