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

[Joseph Salowey <[e-mail]>]

HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[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
>
>   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 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
>
>   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]
> https://www.ietf.org/mailman/listinfo/emu
>