Subject: Re: [Reap] EAP - TLS 1.3

From: John Mattsson <[email-masked]>
Date: Fri, 1 Dec 2017 13:16:36 +0000

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

---

From: John Mattsson <[email-masked]>
Date: Fri, 1 Dec 2017 13:57:58 +0000

Hi Bernard,

On Thu, Nov 19, 2017, Bernard Aboba wrote:

>The big question is "Why not create a new EAP method"? 

>The overall intent seems to be to create an pre-shared key EAP method optimized for 5G,
>based on EAP-TLS v1.3.  

I don’t know why you have gotten the idea that the intent is pre-shared key authentication. 3GPP has no interest in EAP-TLS with pre-shared key authentication. 3GPP wants to use EAP-TLS with certificate authentication.

>Since the protocol described will not interoperate with any of the existing 2+ billion
>EAP-TLS devices, why reuse the EAP-TLS code point or EAP-TLS name?   What has been
>described is an entirely distinct authentication method, not a "clarification" to an
>existing specification.

>In fact, from how it has been described, it would appear that the new protocol is only for use
>with new devices supporting 5G and new 5G servers supporting the new method.  In which case,
>if the new method is not for general use on the Internet, why can't 3GPP just define the method >themselves and allocate their own private EAP type code? 

I don’t know why you has come to the conclusion that this would not interoperate with existing EAP-TLS devices. TLS 1.3 e.g. obsoletes TLS 1.2 but still interoperate just fine with all old versions of TLS. 3GPP plans to use EAP-TLS (RFC5216) with current versions of TLS. In the future, 3GPP (and probably many others) would like to use EAP-TLS with TLS 1.3.

3GPP has no special requirements when it comes to using EAP-TLS with TLS 1.3, and would like to be interoperable with all implementations of EAP-TLS with TLS 1.3. The major point with EAP-TLS is to use the TLS version negotiation, defining EAP-TLS with TLS 1.3 as a different code is not a good idea.

My view is that it is not clear how the key derivation is done when EAP-TLS is used with TLS 1.3. Non-interoperable implementations would not be good for the Internet. Furthermore, an implementation of EAP-TLS with TLS 1.3 would break a _large_ amount of MUSTs in RFC5126 as TLS 1.3 changes a lot from TLS 1.0 – 1.2. I think that an update to RFC5215 is needed irrespectively of 3GPP using EAP-TLS or not.

Cheers,
John