Re: [Reap] EAP - TLS 1.3

[John Mattsson <[e-mail]>]

Thanks for your comments Alan. Very helpful. See answers and comments below:

On Nov 16, 2017, Alan DeKok wrote:

>That's good.  But as Bernard points out, there's no need to change
>EAP-TLS.  You can just use TLS 1.3.

I don’t agree with that, see concrete details below.


>How so? 5216 says (essentially) "encapsulate TLS within EAP". How, exactly, >does this change with TLS 1.3?

If RFC5216 actually said that it would be less of a problem, but RFC5216 has a large amount of normative terminology that is correct for TLS 1.0 - 1.2, but wrong for TLS 1.3. Just looking quickly at the base case in RFC5216 (Section 2.1.1.):

"until the change_cipher_spec message"
(In TLS 1.3 change_cipher_spec is an optinal dummy record only used for Middlebox compatibility).

"a server_hello_done handshake message MUST be the last handshake message encapsulated in this EAP-Request packet."
(server_hello_done is used in TLS 1.3).

"a TLS server_key_exchange handshake message MUST also be included"
(server_key_exchange is used in TLS 1.3).

"MUST encapsulate one or more TLS records containing a TLS client_key_exchange, change_cipher_spec"
(client_key_exchange is used in TLS 1.3).

"the peer MUST send only the change_cipher_spec"
(see above)

EAP-TLS with TLS 1.3 would break a _large_ amount of MUST in RFC5216.


>What, exactly is different with the message flows in EAP-TLS when TLS 1.3 is >used?

While the message flows are exactly the same in TLS 1.0, TLS 1.1, and TLS 1.2

     ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished

The message flow and its content is completely different in TLS 1.3

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*         -------->
                                                       ServerHello  ^ Key
                                                      + key_share*  | Exch
                                                 + pre_shared_key*  v
                                             {EncryptedExtensions}  ^  Server
                                             {CertificateRequest*}  v  Params
                                                    {Certificate*}  ^
                                              {CertificateVerify*}  | Auth
                                                        {Finished}  v
                                 <--------     [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}                -------->

(I agree with Bernand than developers would likely get the message flows right, however such an implementation would break a _large_ number of MUST in RFC5216 (see above). I also think it would be good to give people wanting to use EAP-TLS how many roundtrips they can expect with TLS 1.3 (in general one less that with TLS 1.0 - 1.2).

  
>I think one of the concerns here is the procedural aspect.  Your proposal
>was to forbid everyone *else* from using TLS 1.0 because your requirements
>were for TLS 1.3.  That's not the way to gain support.

Yes, procedural aspects seem to be a large concern, but “obsolete” does not forbid anyone from using EAP-TLS with TLS 1.0. E.g. TLS 1.3 obsoletes TLS 1.2, which obsoletes TLS 1.1 etc. but that does not mean that people are forbidden to use TLS 1.2. If fact TLS provides a versioning mechanism and the TLS working group is even planning TLS 1.2 Long-term support. That said, I am perfectly fine with “update” if that is what the mailing list wants, I will change "obsolete" to "update" in the -01 version, and make it clear that in the text that the update is still compatible with RFC5216 using TLS 1.0.


>Implementations of EAP-TLS do need to change when the key derivation changes.
>Such as for TLS 1.2.  However, those changes are >largely limited to the TLS
>library, not the EAP-TLS code.

RFC5216, Section 2.5 defines that MSK, EMSK, and IV is derived with the TLS-PRF, which is the right way to do it in TLS 1.0, TLS 1.1, TLS 1.2. TLS 1.3 replaces the PRF with HKDF, thus requiring a new construction. How would someone trying to implement TLS 1.3 with RFC5216 derive the keys?

1. Follow RFC5216 and use the old TLS-PRF to derive MSK, EMSK, IV?

  Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
                     client.random || server.random)
                     
This would mean that the EAP-TLS code would have to implement the TLS-PRF, the TLS library would also need to be modified to enable extraction of master_secret, client.random, and server.random. That seems like a very bad solution.

Also would such an implementation use the TLS 1.2 or TLS 1.1 PRF?

2. Try to guess how to do something similar with the TLS HKDF construction

  Key_Material = Derive-Secret(Master Secret, "client EAP encryption", client.random || server.random)

3. Or equally likely replace ClientHello.random + ServerHello.random with ClientHello...server Finished as done in all key derivation in TLS 1.3    

  Key_Material = Derive-Secret(Master Secret, "client EAP encryption", ClientHello...server Finished)

4. Or do it the natural way in TLS 1.3 (Used in e.g. draft-ietf-quic-tls) 

  Key_Material = TLS-Exporter("client EAP encryption", "", 128)

I think this is extremely likely to lead to incompatible implementations of EAP-TLS with TLS 1.3 unless IETF gives guidance. My view is that a document is needed stating how the key derivation is done when EAP-TLS is used with TLS 1.3, my proposal would be:

  Key_Material = TLS-Exporter("client EAP encryption", "", 128)


>In addition, your other arguments are hand-waving, and don't provide concrete >details to back up your position.  Having concrete details would help.

I hope that the details above illustrate why I think an short document describing how to use EAP-TLS with TLS 1.3 is needed. I will update the document aligning with the comments received:

- "update" instead of "obsolete" and also making clear that an implamentation following the document is still compatible with EAP-TLS with TLS 1.0 (up to the application to decide). This means that the EAP-TLS with TLS 1.3 document can be shorter totally avoiding overlap with RFC5216, only describing any difference when usign TLS 1.3.

- Highlight which parts relevant for EAP-TLS that changes in TLS 1.3 and why an update is needed.

- Add information on how Key_Material and IV is derived when using EAP-TLS with TLS 1.3. Refering to RFC5216 for to get MSK, EMSK, etc, from Keying_Material.

Cheers,
John