Subject: Re: [Emu] TLS 1.3 and other EAP methods

From: John Mattsson <[email-masked]>
Date: Thu, 31 Jan 2019 15:13:43 +0000

Hi Alan, David,

I also strongly agree that all TLS-based EAP methods in use should be capable of working with TLS 1.3. You make a very strong case that this need to happen as soon as possible and that the most practical approach is to add the information to draft-ietf-emu-eap-tls13. Just like with EAP-TLS, we must absolutely avoid a situation where different TTLS / FAST / PEAP / TEAP implementations with TLS 1.3 cannot talk with each other.

I am ok with adding this information to draft-ietf-emu-eap-tls13, but I would like to have a go ahead from the chairs/ADs before doing so. My view is that this can be done in the current charter if text about "EAP TLS" is interpreted as TLS-based EAP methods. I would recommend that draft-ietf-emu-eap-tls13 then formally updates the other RFCs to make sure as many people as possible looking to implement e.g. EAP-TTLS finds the information on how to do the key derivation with TLS 1.3.
	
Is information about key derivation the only thing that is needed? Should TTLS / FAST / PEAP / TEAP for instance use an TLS empty record in the same way as EAP-TLS?

> On Jan 28, 2019, at 12:24 PM, Alan DeKok <[email-masked]>; wrote:

>>> Sure.  The question then becomes one of encoding.  For types < 256, 1 octet is >enough.  For others, it should be a 32-bit number in network byte order.
>> 
>> Maybe we can state that it is the EAP Method Type value in network byte order with any leading bytes of value zero removed? Then 13 is encoded as "0D", 256 is encoded as "0100", and 4294967295 is encoded as "FFFFFFFF".
>
>  Hmm... I think 8/32-bit numbers would be simpler.

Ok, let's do it like that.

Cheers,
John

---

From: Alan DeKok <[email-masked]>
Date: Thu, 31 Jan 2019 10:25:09 -0500

> I am ok with adding this information to draft-ietf-emu-eap-tls13, but I would like to have a go ahead from the chairs/ADs before doing so. My view is that this can be done in the current charter if…

  That works for TTLS and PEAP.  It doesn't work for FAST or TEAP. :(  Those methods have rather more complex key derivation requirements.
	
> Is information about key derivation the only thing that is needed?

  No, unfortunately.  There are additional considerations with application data && inner negotiation.

> Should TTLS / FAST / PEAP / TEAP for instance use an TLS empty record in the same way as EAP-TLS?

  Likely not.  They should instead start the inner tunnel negotiation.

  Hmm... if the changes are too complex, it may be better to have a new document.  I have a first draft written, and will be publishing it soon.  It's only about 12 pages, but it goes through a lot of detail that is likely not relevant for the EAP-TLS document.

  It still may be useful to give guidance in the EAP-TLS document.  e.g.:

---
Type-Code  = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type-Code, 128)
IV           = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64)
Method-Id    = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Type-Code, 64)
Session-Id   = Type-Code || Method-Id
MSK          = Key_Material(0, 63)
EMSK         = Key_Material(64, 127)
Enc-RECV-Key = MSK(0, 31)
Enc-SEND-Key = MSK(32, 63)
RECV-IV      = IV(0, 31)
SEND-IV      = IV(32, 63)

Other TLS-base EAP methods can perform similar key derivations by replacing the Type-Code with the value of their EAP type.  The Type-Code is defined to be 1 octet for values smaller than 256,
otherwise it is a 32-bit number (four octets), in network byte order.

Additional discussion of other EAP methods is outside of the scope of this document.
---

 That way there's at least *some* guidance.  Any additional discussion (and there may be lots) could go into another document.

  Alan DeKok.