Subject: [Emu] EAP-TLS 1.3 TLS-Exporter context_value

From: John Mattsson <[email-masked]>
Date: Fri, 11 Jan 2019 13:13:27 +0000

Hi,

RFC 8446 defines the TLS-Exporter interface as:

   TLS-Exporter(label, context_value, key_length)

draft-ietf-emu-eap-tls13 is using the exporter interface without context:

   Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128)
   IV           = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64)
   Method-Id    = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64)
   Session-Id   = 0x0D || Method-Id

The working group did never really discuss the context_value parameter. So just to bring up the question: Is there any information from the EAP-Requests and EAP-Responses that should (and could) be included in the context_value to ensure that the EAP Peer and EAP Sever agree that they have gotten the same information. E.g. from these messages:

    EAP Peer                                              EAP Server

                                                         EAP-Request/
                               <--------                    Identity
    EAP-Response/
    Identity (Anonymous NAI)   -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                               <--------                  (TLS Start)

RFC 5216 does not include any such information in the key derivation, but as the group has agreed to modify the key derivation mechanism for EAP-TLS 1.3, it would be relatively easy to add context information is that is believed to increase current or future security.

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jan 2019 08:56:31 -0500

On Jan 11, 2019, at 8:13 AM, John Mattsson <[email-masked]> wrote:
> 
> The working group did never really discuss the context_value parameter. So just to bring up the question: Is there any information from the EAP-Requests and EAP-Responses that should (and could) be included in the context_value to ensure that the EAP Peer and EAP Sever agree that they have gotten the same information.

 I'll note that the TLS-Exporter function is used after authentication succeeds, which makes a difference to what information can be used.  If we use a context_value, we should choose one that has the most information, and therefore the most utility.

> E.g. from these messages:
> 
>    EAP Peer                                              EAP Server
> 
>                                                         EAP-Request/
>                               <--------                    Identity
>    EAP-Response/

  I would think that all of the public information (such as the data here) isn't suitable for use in the context_value.

  Even if it was suitable, what data would we use?  If we use certificate privacy and exchange the client cert only in the inner tunnel (i.e. EAP-TLS inside of EAP-TLS).  There is minimal data in the outer session that both peer and server can agree on.  Well, there's an anonymous NAI, but that isn't good for much.

> RFC 5216 does not include any such information in the key derivation, but as the group has agreed to modify the key derivation mechanism for EAP-TLS 1.3, it would be relatively easy to add context…

  If we believe the argument above, the only data suitable for use in context_value is data *both* parties know from the inner tunnel exchange.  That generally means information related to client / server certificates.

  And I'm not sure what information from the certs would be used.  We presume that the certs are already correct and validated.  TLS ensures that the TLS-Exporter function depends on the TLS exchange, which depends on the certs.   So using information from the certs seems pointless.

  And what additional information should be added to TLS-Exporter that would make it *better*?  EAP-TLS doesn't provide for a way to peer and server to send additional data, unlike EAP-TTLS, so there isn't much that can be done here

   In the end, I think any information we could use is already being used to derive TLS-Exporter, and there's no real way to get additional information.  And even if there was, it's not clear what information would make the TLS-Exporter "better". Or even what "better" means in this context.

  Alan DeKok.