Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

From: John Mattsson <[email-masked]>
Date: Tue, 2 Feb 2021 23:48:23 +0000

Alan wrote:

><john.mattsson=[email-masked]> wrote:
>> 4. was something I thought was clear. The -13 version states that “The EAP->TLS server commits to not send any more handshake messages”. This was >according to my memory exactly what was requested from the implementors.
>
>  The text is in draft-mattsson-eap-tls13-02, but not in draft-ietf-emu-eap->tls13-00.  The announcement message is here:
>
>https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>  Which doesn't mention the commitment message.  I can't find any other >discussion about the commitment message on the archive.  That doesn't >necessarily mean much, as the archive is difficult to search.
>
>  So it's not clear where that came from.

I Agree. The initial problem was brought up by Jouni who identified both the problem with the extra round-trip as well as the uncertainty in the EAP state machine.
 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/

The idea with the commitment message was suggested by Jim Schaad during IETF 102 and then added in -01. The meaning of the commitment message was likely also discussed during that EMU session. I do not remember the exact discussions. It was likely not an implementor that suggested this definition. I mixed it up with Jouni raising the problem.

> In the last weeks discussion, the commitment message has been given a lot of >different interpretations that are not coming from the draft. The meaning of >and requirements for the -13 commitment message now seems quite unclear.
>
> An in-progress draft is not an authoritative source of information.  The WG >is discussing what the commitment message means, with an eye to making >recommendations for the draft, and implementors.

Of course not, but the exact same definition has been in the draft since -01 without anybody question it before now. This made me think it was clear and widely accepted. That does not make it right and I have never said it is wrong to question that definition. I think we can agree that the meaning of the commitment message now seems unclear.

/John

---

From: John Mattsson <[email-masked]>
Date: Wed, 3 Feb 2021 10:26:35 +0000

Hi,

Maybe not so important to figure out who suggested what, but I think the whole discussion took place at IETF 102. 

https://datatracker.ietf.org/meeting/102/materials/slides-102-emu-eap-tls-with-tls-13-00.pdf

https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00

https://www.youtube.com/watch?v=Ez2Y4wK94Sk

At the same meeting it was also ruled out to use the Reserved bits in EAP-TLS header and to make EAP-Success carry payload. Latency and security was discussed a lot with Bernard keeping the security high and Jouni expressing on the mailing list before the meeting that he wanted to cut even more roundtrips from the message flow.

According to the minutes it seems like Jim suggested the use of application data and Eric suggested the interpretation to make this mean no more handshake messages. This was added to the draft and everybody was happy with that for 2.5 years. While individual persons cannot represent the TLS WG, there was a large amount of senior TLS people present and active in the discussion.

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

John: Jouni implemented this draft and found the NewSessionTicket was inconvenient 

Darshak:  Point is well taken. We should not restrict NewSessionTicket. The server could signal with EAP that it will send other things.

Bernard: You are not changing EAP. EAP-Success can be spoofed. Understand exactly which state it is, not an EAP task but method specific. Reception of properly encrypted message should take precedence over EAP-Success. At every point, important to know if you are in continuing, success or failed state. It has nothing to do with EAP.
    
Jim Schaad: Have the server send an encrypted content message. Will add latency. 

Bernard: That's how EAP-TLS does currently with Finish message.

Darshak: Does sending this encrypted content message indicate that no more TLS messages will be sent. 

Jim: TLS content message (a record) to know when you are done and make transition. That takes the place of the TLS Finish message.

Hannes: Differenced to other EAP messages. Before there were clear definitions. What is finished actually? NewSessionTicket is still a handshake. Cram it in earlier in the exchange.
    
Darshak: Isn't the TLS server allowed to send NewSessionTicket later. Are you restricting it in EAP?

Eric: You want to know that there will be no more TLS messages? Profile TLS to say don't do this. None of the Post-Handshake messages are needed. 

John: Need more discussion on the mailing list. Could we use FLAG in EAP-TLS.
Bernard: If you use this and it determines cryptographic state, then you have just introduced a vulnerability. Don't do that. 

John: Piggyback Newsessionticket on the EAP-SUCCESS 
Bernard: Not a good idea.

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

Do close_notify even fulfill the requirements here. It cannot be spoofed, but it is a very strange alternative success message. It can also be sent by the server earlier to indicate failure for any reason....

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Wednesday, 3 February 2021 at 00:48
To: "[email-masked]" <[email-masked]>
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

/John

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Feb 2021 07:12:29 -0500

> According to the minutes it seems like Jim suggested the use of application data and Eric suggested the interpretation to make this mean no more handshake messages. This was added to the draft and…

  Does that mean all open issues have been addressed and resolved?

  The current suggestion from Eric is to *not* use application data, but to use CloseNotify instead.  Does this mean the earlier discussion was wrong, or is the current suggestion wrong?  Are we allowed to dig into reasons *why* we're doing this?

  I'm a little taken aback at the appeal to authority, and the opinion that the "best way forward" is to just publish a document we don't understand.

  I'll also note that you're defending the *process*.  You're not defending the *content* of the draft.  So do you stand behind it?  i.e. do *you* have reasons why this behaviour is necessary?  The above summary from 2.5 years ago discusses *what* was decided.  The draft (and the summary) still makes no mention of *why* it's done, or why it's useful.

  The purpose of the draft is not to just publish "something".  The purpose of the draft is to publish a clear, secure, spec for EAP-TLS 1.3.  The current discussion does not give me confidence that we're making progress

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Feb 2021 13:51:01 -0500

I haven't been able to follow all of thread on the impedance mismatch between
EAP and TLS, which the EAP-TLS specification is intended to resolve.
(I did talk on the phone with Alan yesterday, and he recapped some issues for
me.   My other qualification is that I implemented EAP-SIM 20 years ago, and
I did some EAP over IKEv1 work at one point)

My understanding is that:
  1) the TLS Finish message can now occur prior to the client certificate
     even being transmitted, let alone validated.
     This is a feature in TLS 1.3 that lets application data in the
     typical browser->http server occur very early.

  2) As such, it is possible to run the TLS-Exporter function prior to
     actually having authenticated the client.
     This is part of the TLS 1.3 changes that essentially permit either
     end to (re-)authenticate at any point in the protocol.

  3) The EAP-Success message is not authenticated in any way.

So it seems to be that:

a) The EAP-Success is meaningless.  The client needs to process it, but
   it should not affect the state machine at all!

b) Success means being able to use the derived keys.
   The keys won't be installed by the AAA server into the authenticator
   until it has performed appropriate validation of the client.
   (e.g, received and validated the client certificate)

c) More important than EAP-Success, is legitimate failure.   They need to be
   unforgeable by an attacker.   Success is easy to determine, and
   progress is easy to move forward with.  What breaks forward motion are
   failure messages.  They need to be properly authenticated.

While EAP-TLS does not really do anything with the resulting TLS channel
afterwards, there are some protocols like EAP-TEAP (and BRSKI-TEAP), that
would like to use the channel afterwards.  So anything learnt in EAP-TLS 1.3
will get repeated.

My instinct is that the best thing would be to have a TLS-level message which
EAP-TLS 1.3 should define.  This is the real success or failure message.  TLS
libraries would have to cope.

The application data, byte, vs zero-length data discussion seems to be
basically dancing around this.  TLS 1.3 is too flexible, and we can't either
constrain the TLS 1.3 state machine, nor can we depend upon it anymore the
way that one could with 1.2.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Feb 2021 15:32:53 -0500

>  3) The EAP-Success message is not authenticated in any way.

  Yes.

>   it should not affect the state machine at all!

  It really seems so.  The EAP-Success is largely a signal to the Access point / NAS / etc. that EAP has succeeded.  This signal needs to be independent of EAP type, so it's just a 4 byte "Success" packet.

>   (e.g, received and validated the client certificate)

  The key here is that the AAA server *can* define the keys earlier.  We may want to update the key derivation, so that the keys are derived from the client / server certificates, too.

>   failure messages.  They need to be properly authenticated.

  RFC 8446 Section E.1 says:

   As soon as the client and the server have exchanged enough
   information to establish shared keys, the remainder of the handshake
   is encrypted, thus providing protection against passive attackers,

  So the TLS Alert messages would seem to be encrypted.  It would be good to get clarification on this.  If true, it's one less thing that we have to worry about.

  If the TLS alert messages are encrypted, then they can't be forged.  A malicious actor could forge EAP-Failure, but RFC 3748 Section 7.16 says that peers should ignore unexpected failures:

   ... a peer silently discards a Failure packet
   received at a point where the method does not explicitly permit this
   to be sent.  For example, a method providing its own error messages
   might require the peer to receive an error message prior to accepting
   a Failure packet.

> would like to use the channel afterwards.  So anything learnt in EAP-TLS 1.3

  Yes.  We do need to ensure that whatever is done here will work for all other TLS-based EAP methods, for both the "full authentication", and the "resumption" exchanges.

> libraries would have to cope.

  I'm not sure that changing TLS is appropriate here.  But I can see how it would be useful.

  The "hacky" way to add signalling to EAP-TLS is to just send application data inside of the tunnel.  The (eventual) follow-on question is then how that affects other TLS-based EAP methods.

> way that one could with 1.2.

  Yes.

  It looks now like the main issue is getting an *authenticated* success from the EAP server to the EAP peer.  Neither CloseNotify, not the Commitment message are sufficient for that purpose.

  Alan DeKok.