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

From: John Mattsson <[email-masked]>
Date: Mon, 28 Jan 2019 17:10:35 +0000

>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".

>Thanks.  My only remaining nit here is that there should really be a sentence >alluding to other TLS-based EAP methods.  So we don't have to rev all of those >documents, too.  I'm not sure that this document is the best place to do it, but it's >only 1-2 sentences.

That is doable but maybe not completely trivial as:

- draft-ietf-emu-eap-tls13 should then probably formally update the RFCs for the other methods, e.g. EAP-TTLS (RFC 5281).

- I assume the other methods should use the same labels (e.g. "EXPORTER_EAP_TLS_Key_Material") as EAP-TLS

- EAP-FAST (RFC 4851) derives a 112 byte long key_block and TEAP (RFC 7170) derives an 40 byte long session_key_seed instead of the 128 byte long key_material in EAP-TLS.

- PAEP is widely deployed but not an RFC

/John

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jan 2019 12:24:20 -0500

> 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 e…

  Hmm... I think 8/32-bit numbers would be simpler.

> - draft-ietf-emu-eap-tls13 should then probably formally update the RFCs for the other methods, e.g. EAP-TTLS (RFC 5281).

  Maybe... that's up to the ADs,

> - I assume the other methods should use the same labels (e.g. "EXPORTER_EAP_TLS_Key_Material") as EAP-TLS

  Yes.

> - EAP-FAST (RFC 4851) derives a 112 byte long key_block and TEAP (RFC 7170) derives an 40 byte long session_key_seed instead of the 128 byte long key_material in EAP-TLS.

  <shrug>  Truncating 128 bytes to 112 or 40 bytes would be fine.  The goal is to have *something* that people can use.

> - PAEP is widely deployed but not an RFC

  Some guidance would still be useful.

  My $0.02 is that the worst thing we could do is to publish EAP-TLS for TLS 1.3, and to give no guidance for other TLS-based EAP methods.  I have a strong preference that *all* TLS-based EAP methods be capable of working with TLS 1.3.

  Maybe this document isn't the place for these updates.  But IMHO, any updates to TTLS, FAST, etc. MUST be published simultaneously with this spec.  Otherwise implementors will have no guidelines, and TTLS / FAST / PEAP / TEAP will be broken for *years*.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 28 Jan 2019 12:36:10 -0500

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

I’m retired now, so this is no longer my “professional” opinion, but I agree with Alan on this.