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

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 06:55:39 -0500

On Feb 1, 2021, at 1:00 AM, Joseph Salowey <[email-masked]> wrote:
[ re: commitment message ]

> [Joe]  I'm not sure why it's needed. It's not clear to me why the peer can't hold the TLS session open until it receives more TLS messages (handshake or alert) or an EAP failure or EAP Success.  

  I suspect that it can.

  The larger issue for me is that in EAP + TLS 1.2, the "TLS Finished" message comes after the client certificate has been validated.  See Page 6 of https://tools.ietf.org/html/rfc5216

  In EAP + TLS 1.3, the proposal is that the "TLS Finished" message comes before the client certificate has been validated.

  To me, this means that the client has absolutely no idea whether or not it's certificate has been verified.  Any malicious actor could forge an EAP-Success (as it is entirely unauthenticated).  This seems to be a major difference from TLS 1.2, and potentially a major problem.

  There is a goal to get EAP-TLS working in 3.5 rounds.  That's a good goal, but I'd like to be sure that it doesn't come at the expense of security.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 07:09:14 -0500

On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk <[email-masked]> wrote:
> 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.

  Yes.

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

  The TLS exporter keys are used for 802.1X / MacSec.  But they're not always used.

> ... it
> seems like a lot of what is being described as desired here ends up relying
> on ordering between application data and handshake messages.

  I think there's no implementation issue here.  The draft should be clearer that there's no guaranteed ordering.

> (A lot of my hedging in messages on this thread is because I also don't
> really understand why the message is there.)
> I believe I read somewhere that it stemmed from the change in who speaks
> last in the TLS handshake, but am a bit hazy on how that implies it is
> needed.

  I would like clarification on just what that message *means*.  If we want an explicit EAP layer signal that the server saw the client cert and authenticated it, then we MUST NOT send any such signal until after the server has seen the client cert.  And because the EAP-Success is sent all alone, we MUST then have another full round of TLS exchange, before the final EAP-Success.   i.e.

    EAP-TLS Peer                                      EAP-TLS Server

                                                         EAP-Request/
                                 <--------                  Identity
    EAP-Response/
    Identity (Privacy-Friendly)  -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------                (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)             -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                              TLS CertificateRequest,
                                                     TLS Certificate,
                                               TLS CertificateVerify,
                                 <-------            TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)                -------->

                                                             EAP-Request/
                                                    EAP-Type=EAP-TLS
                             <--------        (TLS Commitment Message)

    EAP-Response/
    EAP-Type=EAP-TLS
     (TLS Ack)                 -------->
                                 <--------               EAP-Success

  In that scenario, the commitment message *does* have a purpose:

*  It was not needed in TLS 1.2, because the "TLS Finished" message from the server came after the server saw the client cert. 
*  In TLS 1.3, that behaviour has changed
* so the *implicit* meaning of "server sends TLS finished" is no longer "server has seen client cert"
*  Since EAP-TLS wishes to authenticate the client cert, it MUST have an EAP state after the "TLS Finished" message
*  Since EAP-TLS does not provide for any data exchanged in the EAP layer, any data MUST be mangled into TLS
* and the only possibility is TLS application data.

  I'd like to know if any of these assumptions are false.

  If all this is true, then the 3.5 round EAP-TLS goal is impossible.

> I don't disagree with what you say, but I will note that if we are seeing a
> conflict between a desire to ship something ASAP and uncertainty that the
> current specification is fully correct, it's easy process-wise to allocate
> a new type code for people to ship "now" without locking in behavior for
> 0x0d.  Whether we call it an early allocation, an experimental usage, or a
> normal allocation via specification required doesn't seem terribly
> important (and given that Joe is the expert and he basically suggested it,
> I suspect that allocation would occur quite quickly after a request).
> How easy it would be to get things back onto 0x0d in the future is less
> clear, though.

  As an implementor, I fervently hope to *not* support an "ad hoc" EAP type for the next 10 years.

  My preference is to get this right, even it means more delays.

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Feb 2021 06:55:17 -0800

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[email-masked]>
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/[email-masked]/msg03092.html

I agree that extra round trips are bad, I'd like to take a step back
here and think about what this message is trying to do. Here's
the relevant text:

   TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
   Handshake messages use the handshake content type and can be sent
   after the main handshake.  One such Post-Handshake message is
   NewSessionTicket.  The NewSessionTicket can be used for resumption.
   After sending TLS Finished, the EAP-TLS server may send any number of
   Post-Handshake messages in separate EAP-Requests.

The relevant question is when the server knows what post-handshake
messages it will send. There are two points at which the server might
wish to send post-handshake messages:

1. After the server's first flight.
2. After the client's second flight.

Let's take the second case first. If the server is sending (or
potentially sending) post-handshake messages after the client's second
flight (e.g., after reading its certificate), then it can easily send
a close_notify after sending all of them. This will appear in the same
flight as the commitment message would have (because you can't send it
before the post-handshake messages) and avoid the need for an extra
round trip.

The first case, where the commitment message is sent in 0.5-RTT,
is the interesting one. However, the server has no more information
after sending SFIN than it does sending EE, so I believe that the
easiest way to deal with this is with a TLS extension that says
"I do not send any post-handshake messages". This would still
leave the server free to send any relevant alerts in response to
the client's second flight.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 1 Feb 2021 15:06:02 +0000

>    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?

The mistaken belief that applications really wanted to control all the knobs and flow of control of the protocol.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 10:42:14 -0500

> before the post-handshake messages) and avoid the need for an extra

  That use of CloseNotify would be before the server receives the client certificates.  It prevents the server from sending TLS alerts for certificate errors (expired, unknown CA, etc).  That would be an unmitigated disaster for deployments.

  The CloseNotify *could* be sent after the server receives the client certs.  But that still means another full round of EAP, before the final EAP-Success.  So from that view, there's no difference between CloseNotify and an explicit commitment message.

> the client's second flight.

  Except that if the server likes the client cert, Figure 1 of draft-13 shows the next packet is EAP-Success.  So the client has no *authenticated* way of telling that it has been authenticated.  Any party to the conversation could send a blank EAP-Success (which is 4 bytes of unauthenticated data).  And thus break EAP-TLS.

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Feb 2021 08:09:04 -0800

On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok <[email-masked]> wrote:

>   That use of CloseNotify would be before the server receives the client
> certificates.  It prevents the server from sending TLS alerts for
> certificate errors (expired, unknown CA, etc).  That would be an
> unmitigated disaster for deployments.
>

That's not what I'm proposing. I'm only talking about the case where the
server says this after flight (2).

  The CloseNotify *could* be sent after the server receives the client
> certs.  But that still means another full round of EAP, before the final
> EAP-Success.  So from that view, there's no difference between CloseNotify
> and an explicit commitment message.
>

Right. But close_notify is the message that more matches the TLS semantics.

>   Except that if the server likes the client cert, Figure 1 of draft-13
> shows the next packet is EAP-Success.  So the client has no *authenticated*
> way of telling that it has been authenticated.  Any party to the
> conversation could send a blank EAP-Success (which is 4 bytes of
> unauthenticated data).  And thus break EAP-TLS.
>

I fear we are talking past each other.

Ignoring the protocol mechanics, let's just talk about what signals you
think the client ought to want to receive. The two I am aware of are:

1. From the server's perspective, the TLS handshake is complete.
2. The server will not be sending any more handshake messages to the client.

When client authentication is being used, then for obvious reasons (1)
cannot be delivered prior to the server receiving and processing the
client's certificate. Agreed? Indeed, this seems like a problem with the
flow shown in Figure 1, because the server sends Commitment prior to
reading the client's cert.

ISTM that the relevant question is when one might want to receive (2).  In
particular, when would the client want to learn that the server will not
send any more handshake messages when the client has second flight
handshake messages still outstanding? Can you explain to me how this is
useful?

-Ekr

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 11:22:36 -0500

On Feb 1, 2021, at 11:09 AM, Eric Rescorla <[email-masked]> wrote:
> That's not what I'm proposing. I'm only talking about the case where the server says this after flight (2).

  OK, my misreading of the text.

> Right. But close_notify is the message that more matches the TLS semantics.

  I agree.

> Ignoring the protocol mechanics, let's just talk about what signals you think the client ought to want to receive. The two I am aware of are:
> 
> When client authentication is being used, then for obvious reasons (1) cannot be delivered prior to the server receiving and processing the client's certificate. Agreed?

  Yes.

> Indeed, this seems like a problem with the flow shown in Figure 1, because the server sends Commitment prior to reading the client's cert.

  Yes.

> ISTM that the relevant question is when one might want to receive (2).  In particular, when would the client want to learn that the server will not send any more handshake messages when the client has second flight handshake messages still outstanding? Can you explain to me how this is useful?

  I'm just trying to summarize the discussion so far, and get clarification on exactly what we're trying to do. So take what I say with a grain of salt... I didn't write the text in the current draft.

  The main issue I can see where (2) might be useful is to deal with TLS 1.3's separation of "TLS finished" from other handshake messages.  If the SessionTicket message comes *after* "TLS finished", then it might be in a separate EAP packet.  The client doesn't know that there's an additional handshake until it receives that message.

  So an explicit CloseNotify sent by the server *after* receiving the client certificate would seem useful.  It's an authenticated message saying "yes, I agree we're done".

  If the client cert has issues, the server can send TLS alerts *before* the CloseNotify.  So the client has to either wait for those, OR an explicit CloseNotify, to see if it's (a) rejected, or (b) authenticated

  Alan DeKok.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Feb 2021 08:26:19 -0800

On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok <[email-masked]> wrote:

> client's certificate. Agreed?
>
>   Yes.
>
> > Indeed, this seems like a problem with the flow shown in Figure 1,
> because the server sends Commitment prior to reading the client's cert.
>
>   Yes.
>
> > ISTM that the relevant question is when one might want to receive (2).
> In particular, when would the client want to learn that the server will not
>   I'm just trying to summarize the discussion so far, and get
> clarification on exactly what we're trying to do. So take what I say with a
> grain of salt... I didn't write the text in the current draft.
>
>   The main issue I can see where (2) might be useful is to deal with TLS
> 1.3's separation of "TLS finished" from other handshake messages.  If the
> SessionTicket message comes *after* "TLS finished", then it might be in a
> separate EAP packet.  The client doesn't know that there's an additional
> handshake until it receives that message.
>
>   So an explicit CloseNotify sent by the server *after* receiving the
> client certificate would seem useful.  It's an authenticated message saying
> "yes, I agree we're done".
>
>   If the client cert has issues, the server can send TLS alerts *before*
> the CloseNotify.  So the client has to either wait for those, OR an
> explicit CloseNotify, to see if it's (a) rejected, or (b) authenticated
>

Yes, this is what I have in mind. So, maybe there's never any need for the
server to say "I won't say anything more" after just one round trip?

-Ekr

  Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Feb 2021 09:11:55 -0800

Hi Alan,

I'll second the thanks for putting this together; I think it covers the
important open points.

I did belatedly remember one more thing that is perhaps not critical, but
would also be good to get an answer for:

On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
[...]
> 
> 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?

I think that an exchange between Martin and Mohit raised the question of
whether the EAP server-id and peer-id would be available for use in the
'context' argument of the TLS Exporter, as that would help strengthen the
binding between keys and the authentication exchange.
I do recall a mention that WolfSSL doesn't support a context argument for
the exporter, but I don't know how prohibitive that limitation would be in
practice.

-Ben

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Feb 2021 10:30:43 -0800

On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk <[email-masked]> wrote:

> > 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] This could also address the early export of keys before the peer is
authenticated. RFC 5216 provides a canonical way to create these IDs, but
I'm not sure anyone follows it today and it may be difficult to implement
in practice due to ordering.  It might be simpler to just specify that the
end entity peer and client certificates are used in the key derivation.
Most libraries provide APIs to get the raw certs.
It looks like the WolfSSL API that Mohit linked is specifically for RFC5216
EAP keys and not a general exporter API.  I'm not sure if they have a
general exporter API.

> -Ben
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 14:24:47 -0500

On Feb 1, 2021, at 11:26 AM, Eric Rescorla <[email-masked]> wrote:
> Yes, this is what I have in mind. So, maybe there's never any need for the server to say "I won't say anything more" after just one round trip?

  I think so, yes.

  That means of course EAP-TLS will always require 4.5 round trips.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Feb 2021 11:32:17 -0800

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok <[email-masked]>
wrote:

> > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
>
>   I think so, yes.
>
[Joe] I don't follow why this means 4.5 round trips would be required.

> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Jorge Vergara <[email-masked]>
Date: Mon, 1 Feb 2021 19:48:39 +0000

There has been a lot of discussion on the ending of the handshake that I hope I have parsed. Here is my perspective as an client implementor (not an author):

1. I don't see a strict requirement for an authenticated signal at the end of the handshake. No prior version of EAP-TLS needed this and I don't necessarily see the need now. An EAP-TLS client should wait until it has satisfied all of its server validation policies and completes TLS before accepting a connection to the server, even if a "rogue" server starts sending EAP-Success all the time. Any client which blindly connects in this case is a broken client.

2. Although I don't see any security benefit, such a signal *may* be convenient to help EAP-TLS implementations update their state machines to support TLS 1.3. For example, if an EAP-TLS state machine previously used to assume that a "TLS complete" signal from its TLS library was sufficient to advance to a new state where it will no longer accept TLS payload might break when TLS 1.3 is used. Such a state machine would not necessarily know when to advance to this state with some similar sort of signal that the server is done.

A different state machine which simply will always process TLS payload even after a "TLS complete" signal from its TLS library may not need any updates at all to work with TLS 1.3. I believe such a state machine would be able to handle a NewSessionTicket after TLS completion without issues even without a signal.

Windows currently happens to fall into the first camp, where a signal is convenient. It seems to me that using close_notify is more semantically correct, but has some tradeoffs.

A. In some cases, where the commitment message may be able to allow for a shorter handshake, using close_notify doesn't allow the client to send an alert, which is a non-starter in my opinion.

B. If we settle for an extra round trip, we can use close_notify and make sure the client always has at least 1 chance to send an alert.

This seems to me to be roughly where we started the discussion. Perhaps I have some of the theoretical details regarding the authenticated end signal incorrect as my perception is definitely colored by being mainly a client implementor. I happen to prefer the draft-13 commitment message because it seems to allow one less round trip in some cases. I'm happy to see discussion occurring either way and hope my perspective as an implementor is useful in driving toward a resolution.

Jorge Vergara

From: Emu <[email-masked]> On Behalf Of Joseph Salowey
Sent: Monday, February 1, 2021 11:32 AM
To: Alan DeKok <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; EMU WG <[email-masked]>; Benjamin Kaduk <[email-masked]>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:

  I think so, yes.

  Alan DeKok.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7Cjovergar%40microsoft.com%7Cd91c71b48e0c4b698fbc08d8c6e850bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478048391997828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y8w56%2BgJwrxEOi%2B%2FgFCeQpZnA8%2FjPqslXFEngbk8dKE%3D&reserved=0>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 14:52:58 -0500

On Feb 1, 2021, at 1:30 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe] This could also address the early export of keys before the peer is authenticated. RFC 5216 provides a canonical way to create these IDs, but I'm not sure anyone follows it today

  FreeRADIUS does not officially expose Peer-Id or Server-Id.  But the certificate subjectAltNames are available via the policy engine.  The greater difficulty is *which* Id to use.

  RFC 5216 Section 5.2 says:

   It is possible for more than one subjectAltName field to be present
   in a peer or server certificate in addition to an empty or non-empty
   subject distinguished name.  EAP-TLS implementations supporting
   export of the Peer-Id and Server-Id SHOULD export all the
   subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
   export a non-empty subject distinguished name field within the Peer-
   Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
   considered valid.

> and it may be difficult to implement in practice due to ordering.  It might be simpler to just specify that the end entity peer and client certificates are used in the key derivation.  Most libraries provide APIs to get the raw certs.

  Yes.  We expose the certs to the policy engine, along with various fields.  Having the TLS exporter use more data should just be about updating some code.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 14:55:26 -0500

On Feb 1, 2021, at 2:32 PM, Joseph Salowey <[email-masked]> wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok <[email-masked]> wrote:

  If the CloseNotify signal is sent by the server *after* it receives the client certs, then another round trip is required.  At least, according to Figure 1 of draft-13.

  The CloseNotify can't be sent with the EAP-Success, because the EAP-Success can't carry data.  So the packet flow looks something like this:

                                                        EAP-Request/
                                <--------                  Identity
   EAP-Response/

                                                            EAP-Request/
                                                   EAP-Type=EAP-TLS
                            <--------        (TLS CloseNotify)

   EAP-Response/
   EAP-Type=EAP-TLS
    (TLS Ack)                 -------->
                                <--------               EAP-Success

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Feb 2021 12:00:33 -0800

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok <[email-masked]>
wrote:

>   If the CloseNotify signal is sent by the server *after* it receives the
> client certs, then another round trip is required.  At least, according to
> Figure 1 of draft-13.
>
>   The CloseNotify can't be sent with the EAP-Success, because the
> EAP-Success can't carry data.  So the packet flow looks something like this:
>
>
[Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
CloseNotify.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 15:04:46 -0500

On Feb 1, 2021, at 3:00 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require CloseNotify. 

  With TLS 1.2, the server sends TLS Finished to the client *after* it sees the client cert.

  With TLS 1.3, the server sends TLS Finished to the client *before* it sees the client cert.

  So the question is: when the client sees EAP-Success, has it's certificate been verified?  If there's no more TLS exchange server -> client, then malicious parties can forge an EAP-Success, and the client doesn't know any better.

  This attack isn't possible in TLS 1.2, because the client receives the TLS Finished from the server, as a *positive* acknowledgement that the server has authenticated the client.  In addition, the TLS exporter keys are not available until after the server sends TLS Finished.

  With TLS 1.3, the exporter keys are available *before* the client cert has been validated.  This "fast path" helps with non-EAP protocols.  But makes life more difficult for EAP.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 1 Feb 2021 15:09:45 -0500

On Feb 1, 2021, at 2:48 PM, Jorge Vergara <[email-masked]> wrote:
> 1. I don't see a strict requirement for an authenticated signal at the end of the handshake. No prior version of EAP-TLS needed this

  Prior versions *implicitly* relied on the server sending "TLS Finished" after the client certificate had been validated.

> and I don't necessarily see the need now. An EAP-TLS client should wait until it has satisfied all of its server validation policies and completes TLS before accepting a connection to the server, even if a "rogue" server starts sending EAP-Success all the time. Any client which blindly connects in this case is a broken client.

  We should ideally make the protocol robust to broken implementations.  RFC 4137 was written to deal with implementations having these sort of issues in broken EAP state machines.

> 
> 2. Although I don't see any security benefit, such a signal *may* be convenient to help EAP-TLS implementations update their state machines to support TLS 1.3. For example, if an EAP-TLS state machine previously used to assume that a “TLS complete” signal from its TLS library was sufficient to advance to a new state where it will no longer accept TLS payload might break when TLS 1.3 is used. Such a state machine would not necessarily know when to advance to this state with some similar sort of signal that the server is done.

  Yes.

> A different state machine which simply will always process TLS payload even after a “TLS complete” signal from its TLS library may not need any updates at all to work with TLS 1.3. I believe such a state machine would be able to handle a NewSessionTicket after TLS completion without issues even without a signal.

  True, but that's a bit of a separate issue.

> A. In some cases, where the commitment message may be able to allow for a shorter handshake, using close_notify doesn’t allow the client to send an alert, which is a non-starter in my opinion.

  I agree.

> B. If we settle for an extra round trip, we can use close_notify and make sure the client always has at least 1 chance to send an alert.

  Presuming that we *do* need an explicit signal, which I think is true.  If we do need it, then the extra round trip is unavoidable.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Feb 2021 13:52:04 -0800

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok <[email-masked]>
wrote:

>   So the question is: when the client sees EAP-Success, has it's
> certificate been verified?  If there's no more TLS exchange server ->
> client, then malicious parties can forge an EAP-Success, and the client
> doesn't know any better.
>
>   This attack isn't possible in TLS 1.2, because the client receives the
> TLS Finished from the server, as a *positive* acknowledgement that the
> server has authenticated the client.  In addition, the TLS exporter keys
> are not available until after the server sends TLS Finished.
>
>
[Joe]   There are some cases the finished will fail (math and path
problems), but  5216 allows for a different flow which is vulnerable to an
early EAP Success:

 In the case where the server authenticates to the peer successfully,
   but the peer fails to authenticate to the server, the conversation
   will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- EAP-Request/
                           Identity
   EAP-Response/
   Identity (MyID) ->
                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS Start)
   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
                             TLS certificate,
                    [TLS server_key_exchange,]
               TLS certificate_request,
                 TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
    TLS certificate_verify,
    TLS change_cipher_spec,
    TLS finished) ->

                           <- EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS change_cipher_spec,
                           TLS finished)
   EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- EAP-Request
                           EAP-Type=EAP-TLS
                           (TLS Alert message)
   EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- EAP-Failure
                           (User Disconnected)

>   With TLS 1.3, the exporter keys are available *before* the client cert
> has been validated.  This "fast path" helps with non-EAP protocols.  But
> makes life more difficult for EAP.
>
>
[Joe] We can use Ben's suggestion and make the exported keys depend on the
Peer and server's identities or certificates.  But if you are going to want
a protected result indication in EAP-TLS then you cannot end the early.
 5216 does not support protected result indicators, it's not clear to me if
implementations do or not.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Feb 2021 19:55:03 -0800

>    Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are

I had missed that part of 5216 before.
While you're mostly stuck doing that sort of "all names in the cert are
deemed valid" for the TLS client certificate, since the server just asks
for *some* cert and has to handle what it gets back, that's not the normal
pattern for authenticating the server.  Consider, e.g., the RFC 6125
procedure, which takes as input to validation the name that the TLS client
was attempting to initiate communication towards.  Depending on the
application protocol that might be a DNS-ID or URI-ID or whatever, but
there's still a clear "I initiated communication towards this specific
named entity; can the server prove that it is that entity" which is very
much not "they proved possession of the private key; all names are
verified".  Even for the same server and same certificate, the answer can
be different for different names in the certificate.  (I am about to clear
a DISCUSS position on draft-ietf-quic-http for just this topic; the
historical HTTP semantics are in line with RFC 6125.  It is perhaps not
strictly required that the EAP usage do the same, but it is surprising, at
least.)

>   Yes.  We expose the certs to the policy engine, along with various fields.  Having the TLS exporter use more data should just be about updating some code.

I think that you get better security properties if you include the entire
certificates, but even just identities are better than nothing (provided
there is a clear unique ordering/encoding, as you note).

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Feb 2021 20:23:35 -0800

>   The TLS exporter keys are used for 802.1X / MacSec.  But they're not always used.

Somehow I had convinced myself that the EMSK was only sometimes used, but
MSK was always used.  If MSK is always used, then key confirmation of the
MSK can play the role of handshake (and client authentication)
confirmation, but otherwise I seem to be coming around to your "4.5 round
trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
there is between cases that use the keys and those that don't, such that
the last round trip could be shaved off when the exported key is used for
key confirmation...

>   I think there's no implementation issue here.  The draft should be clearer that there's no guaranteed ordering.

I was going to stick this in a reply to Joe (at
https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it in
here and save a message in everybody's inbox.

My understanding (based on
https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
fragments TLS records, or in some cases, groups of records, and the first
fragment includes a four-byte length field for the total message being
fragmented.  Recalling that a given TLS record can only have payload of a
single content type, in the scenario with a 0x00 confirmation message and a
NewSessionTicket, that means one record with inner type application data
and another record with inner type handshake.  If they are both grouped
together to the EAP-TLS fragmentation engine, then I agree that there is no
issue and a proper implementation should be waiting to reassemble the whole
fragmented bundle, including both records, before finalizing processing.
But is it also allowed to fragment the two records separately?  I didn't
see anything that required the entire TLS flight of messages to be
a single fragmentation input, and it's in the case that the 0x00 and
NewSessionTicket are fragmented separately that the ordering becomes
relevant -- if the 0x00 is fragmented first then the peer gets the complete
fragmented message, sees the commitment message, and prepares its
authentication flight in the EAP-Response, and based on the supposed
commitment semantics would then somehow be expected to reject an
EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
had a way to tell it was a handshake message at all, that is...)

I'd love to hear what I am missing that makes the above incorrect, and/or
that we have a way to require the NewSessionTicket and commitment message
to be part of the same fragmentation unit.

>   I'd like to know if any of these assumptions are false.

(I cannot contradict any of those assumptions, though I don't think I would
be one of the likely candidates to do so.)

>   As an implementor, I fervently hope to *not* support an "ad hoc" EAP type for the next 10 years.

Understood!

Thanks,

Ben

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 1 Feb 2021 22:09:16 -0800

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk <[email-masked]> wrote:

> >   I think there's no implementation issue here.  The draft should be
> clearer that there's no guaranteed ordering.
>
[Joe] I would interpret the commitment message to mean that there are no
more handshake messages coming after completing the processing of this
entire EAP message.  An implementation should not stop processing the
packet in the middle of an EAP-TLS message, even if it is fragmented.  The
whole message should be consumed.

> >   I would like clarification on just what that message *means*.  If we
> want an explicit EAP layer signal that the server saw the client cert and
> authenticated it, then we MUST NOT send any such signal until after the
> server has seen the client cert.  And because the EAP-Success is sent all
> alone, we MUST then have another full round of TLS exchange, before the
> final EAP-Success.   i.e.
> >
> >
> > *  It was not needed in TLS 1.2, because the "TLS Finished" message from
> the server came after the server saw the client cert.

> > *  Since EAP-TLS wishes to authenticate the client cert, it MUST have an
> EAP state after the "TLS Finished" message

[Joe] Based on RFC 5216 the server could fail the finished message or as
section 2.1.3 shows it could send the finish and then it can send an Alert
and result in EAP-Failure.  In this case it would be possible for an
attacker to remove the Alert and send a success.  Whether your
implementation ends up in this scenario or not probably depends upon why
the auth failed and the behavior of your TLS library.

I do not believe that RFC 5216 provides protected result indications.   It
would be a fine thing to add, but it is new to the specification and I'm
not sure that is why the commitment message was added to begin with.

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Feb 2021 08:57:49 +0000

Hi,

I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS interact better is a very promising idea. This would probably take some time to get specified and implemented so it is probably a future optimization/simplification rather that something EAP-TLS 1.3 should wait for.

An extension that "I do not send any post-handshake messages" would work and remove the need for a commitment message.

------------------------------------
NoPostHandShake Extension
------------------------------------

Clients MAY send this extension in ClientHello. It contains no data.

Servers MAY send this extension in EncryptedExtentions. It contains no data.

When the "NoPostHandShake" extension is negotiated, the server MUST NOT send any post handshake messages.

-------------------------------------

However, this would also stop the client from doing resumption which is also very important. EAP-TLS fragments TLS into a large number of round-trips, and database lookup to authorize clients is often slow, so resumption is essential to get good performance.

The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS as is introduces the demand for the commitment message as well as introducing an extra round-trip. The NewSessionTicket mechanism is both complex and inefficient for EAP-TLS. Could a new ticket extension be designed that fits EAP-TLS better? Looking quickly it seems like it would be possible. It looks like the current NewSessionTicket mechanism was designed with a requirements to only use symmetric crypto. This would not be important for EAP-TLS.

The below quickly written suggestion use the same PSK derivation as NewSessionTicket, but makes the ticket_nonce a sequence, and use asymmetric HPKE encryption for client privacy.

------------------------------------
ImplicitTicket Extension
------------------------------------

Clients MAY send this extension in ClientHello. It contains the following structure:

struct {
                uint16 ticket_count_request;
} ImplicitTicketRequest;

With the ImplicitTicketRequest, the client requests ticket_count_request implicit tickets.

A server MAY send this extension in EncryptedExtentions. It contains the following structure:

struct {
                uint16 ticket_count;
                opaque hpke_pk<1..2^16-1>;
                uint32 ticket_lifetime;
                opaque ticket<1..2^16-1>;
   Extension extensions<0..2^16-2>;
} ImplicitTicketResponse;

When the "ImplicitTicket" extension is negotiated, it provisions ticket_count number of tickets. The tickets all have the same lifetime and extensions.

When doing resumption based on an implicit ticket, the identity is constructed as follows:

  identity = ENC(hpke_pk, ticket || ticket_seq || ticket_age_add )

  The uint16 ticket_seq is a that sequence that increases for each ticket the client uses. Valid values are 0..ticket_count-1.

  ticket_age_add in the identity replaces the ticket_age_add normally sent in the in the NewSessionTicket message.

  ticket_nonce is set to ticket_seq and the PSK associated with the ticket is computed as defined in RFC 8446.

---------------------------------

Used together, two such extentions would effectively solve all the EAP - TLS 1.3 related issues as they were known a month ago. There has since been discussion if EAP-TLS 1.3 needs keys derived from the client second flight, but I think more analysis before determining if that is the case or not.

Cheers,
John

From: TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Monday, 1 February 2021 at 15:56
To: Alan DeKok <[email-masked]>
Cc: EMU WG <[email-masked]>, Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok <[email-masked]<mailto:[email-masked]>> 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:

  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/[email-masked]/msg03092.html<https://protect2.fireeye.com/v1/url?k=16c4ad4c-495f9461-16c4edd7-8692dc8284cb-f1f3f2750d360a2a&q=1&e=36033566-ffb1-4757-9586-079c8d5e94a5&u=https%3A%2F%2Fwww.mail-archive.com%2Femu%40ietf.org%2Fmsg03092.html>

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Feb 2021 06:29:53 -0800

On Thu, Feb 4, 2021 at 12:57 AM John Mattsson <[email-masked]>
wrote:

> Hi,
>
>
>
> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
> interact better is a very promising idea. This would probably take some
> time to get specified and implemented so it is probably a future
> optimization/simplification rather that something EAP-TLS 1.3 should wait
> for.
>
>
>
> An extension that "I do not send any post-handshake messages" would work
> and remove the need for a commitment message.
>
>
>
> However, this would also stop the client from doing resumption which is
> also very important. EAP-TLS fragments TLS into a large number of
> round-trips, and database lookup to authorize clients is often slow, so
> resumption is essential to get good performance.
>
>
>
> The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS
> as is introduces the demand for the commitment message as well as
> introducing an extra round-trip.
>

I don't really understand what EAP needs here, but it seems to me that the
commitment message (or the close_notify) is serving two purposes:

1. Saying that the handshake completed successfully
2. Saying that there will be no more messages

I understand from the discussion that knowing that there will be no more
messages is useful. Do you think that the client knowing that the handshake
completed is unnecessary?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Feb 2021 06:31:39 -0800

On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla <[email-masked]> wrote:

>> The current Post-Handshake NewSessionTicket is not well-suited for
>> EAP-TLS as is introduces the demand for the commitment message as well as

> 1. Saying that the handshake completed successfully

Though note that this is an external semantic to TLS for close_notify. It's
not specified with that reqt.

-Ekr

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Feb 2021 14:57:19 +0000

From: Eric Rescorla <[email-masked]>
Date: Thursday, 4 February 2021 at 15:32
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>, Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 4, 2021 at 12:57 AM John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS as is introduces the demand for the commitment message as well as introducing an extra round-trip.

I don't really understand what EAP needs here, but it seems to me that the commitment message (or the close_notify) is serving two purposes:

Though note that this is an external semantic to TLS for close_notify. It's not specified with that reqt.

[John] Yes. It would also be on external semantic if an application data commit message is used.

I understand from the discussion that knowing that there will be no more messages is useful. Do you think that the client knowing that the handshake completed is unnecessary?

-Ekr

[John] Before this last explosion of discussion, the only publicly discussed purpose of the commitment message was to my knowledge 2. All versions of the EAP-TLS 1.3 drafts from -01 to -14 was written with only 2. in mind.

Recently people has also been brought up that also 1. is needed. My understanding is that this is not required by EAP in general, but it is required for secure interaction with 802.11.

After writing this mail suggesting extensions, I invested more time to read the mail Bernard recently sent and all the references in detail.

https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/

After reading up on the 802.11 interaction, it seems to me that the possibility to do 1. is required in at least some deployments. I think the EMU WG need to discuss and agree on this. If 1. is always needed, any TLS extensions would not be needed.