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

[Jorge Vergara <[e-mail]>]

>>DISCUSS: We have interoperable implementations of -13.  Does this mean that the EAP state machines *implicitly* work with the TLS state machines?  There is no *explicit* requirement in the draft about ordering, and no discussion thereof.  I suspect that this means the implementations work in part by accident, instead of by design.  So updates to TLS libraries *may* break EAP-TLS.  It would be best to make any assumptions explicit.  And / or to recommend to implementors that they be flexible with respect to changing order of the 0x00 octet vs session tickets.
>[Joe] Yes we should be clear about this.
[Jorge] My only recommendation would be to wordsmith this part of draft-13 found in section 2.5. I am not a good wordsmith but I see potential confusion here:
>After sending the Commitment Message, the EAP-TLS
>   server may only send an EAP-Success, an EAP-Failure, or an EAP-
>   Request with a TLS Alert Message.

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

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.

Jorge Vergara

From: Emu <[e-mail]> On Behalf Of Joseph Salowey
Sent: Friday, January 29, 2021 2:00 PM
To: Alan DeKok <[e-mail]>
Cc: EMU WG <[e-mail]>; Benjamin Kaduk <[e-mail]>; Martin Thomson <[e-mail]>; <[e-mail]> <[e-mail]>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[e-mail]<mailto:[e-mail]>> wrote:
  This is a new message to summarize history, requirements, etc. for EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and how the 0x00 commitment message versus CloseNotify meets those.  I'll ignore the exporter changes here, as those are less controversial.

  The original proposal in the EAP-TLS draft was to send a zero-length application data message in order to signal that no more post-handshake messages were needed.  From the -05 version:

   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

  However, the OpenSSL APIs (among others) do not allow for sending zero octets of application data.  The proposal was then changed to send a 0x00 octet.

 There was discussion that CloseNotify could achieve the same goals.  But CloseNotify requires an additional round trip.  There are strong opinions that additional round trips are bad.

  In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal Alert:  https://www.mail-archive.com/[e-mail]/msg03092.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Femu%40ietf.org%2Fmsg03092.html&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836111592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mvsTA5W4KMdnLyFin4tzW185JUB%2FuxP%2FyNjI2Mh2Mkg%3D&reserved=0>

  i.e. there would be no TLS layer signalling for the following situations:

   bad_certificate,  unsupported_certificate,  certificate_revoked,
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages are required by people deploying EAP-TLS.  Without those messages, it will be near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS handshakes.  So it's still possible for the EAP state machine to send a 0x00 octet, and then the TLS state machines sends that *before* a Session Ticket.

  In addition, RFC 8446 Figure 1 shows that application data can be sent by the server to the client, *before* the client certificate is sent to the server.  So sending this octet in EAP-TLS does not prove that the client certificate has been validated.

DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a positive signal of either "finished TLS", or "successful authentication".
[Joe] It would be good to be clear about the purpose of the message.

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.

DISCUSS: We have interoperable implementations of -13.  Does this mean that the EAP state machines *implicitly* work with the TLS state machines?  There is no *explicit* requirement in the draft about ordering, and no discussion thereof.  I suspect that this means the implementations work in part by accident, instead of by design.  So updates to TLS libraries *may* break EAP-TLS.  It would be best to make any assumptions explicit.  And / or to recommend to implementors that they be flexible with respect to changing order of the 0x00 octet vs session tickets.
[Joe] Yes we should be clear about this.


  In situations where resumption is not needed, figure 1 of https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-emu-eap-tls13-13&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836121589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1UC%2BP%2B1opA0%2Bq18bznKj3jgrfAqxUTZPLarrTCVCN0E%3D&reserved=0> is correct.  There are 3.5 rounds, which is about as low as possible.  Adding resumption here would *increase* there number of rounds to 4.5, which is worse!

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.


  In situations where the certificate chain is longer, the initial authentication will be >=4.5 round trips, and session tickets are perhaps more useful.

DISCUSS: the EAP-TLS draft should be updated to better explain the costs / benefits of using resumption


  I hope that this summary clarifies the issues and requirements.  The 0x00 octet is intended as a promise that no more handshake messages are sent.  I leave it to others to discuss whether or not that promise is useful.

  As for what to do, my $0.02 is that the behaviour described in -13 is fine.  The 0x00 octet is useful.  The key exporters are perhaps odd, but not problematic.  We have multiple inter-operable implementations.

  The remaining question is this:

DISCUSS: other than word-smithing the above points, are there serious objections to the behaviour documented in -13?  i.e. does the IETF want to recommend that EAP-TLS alpha testing begins *now*, or should it wait until 2022?
[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 would like to start "alpha" testing ASAP, if we find problems in the alpha test, it could result in implementation changes


  The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no "version" flag in the EAP-TLS header.  See https://tools.ietf.org/html/rfc5216#section-3.1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5216%23section-3.1&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836121589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tGmJaIg4RiU6bw3Y670yYp2LHw8TwsR7uDV934NH%2Fmw%3D&reserved=0>

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


  Alan DeKok.



_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836131579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FngrGmmyOMYXSItAC8ciJymsmG1liBdTcFryyw4822A%3D&reserved=0>