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

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Feb 2019 05:25:05 +0000

Hi Alan,

Thanks for bringing this up. I agree that we should take this 
opportunity to fix other EAP methods which rely on TLS for the outer 
tunnel. I think that these updates merit a separate document. But I am 
not certain why the two documents need to be published simultaneously?

--Mohit

On 1/28/19 7:24 PM, Alan DeKok wrote:
> On Jan 28, 2019, at 12:10 PM, John Mattsson <[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.
>
>>> 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).
>    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.
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Feb 2019 08:16:43 -0500

> not certain why the two documents need to be published simultaneously?

  To be clear: they don't need consecutive RFC numbers.  But it will be absolutely a disaster if EAP-TLS is published, and then 18 months later "TLS 1.3 for other methods" is published.

  It makes zero sense to publish TLS 1.3 for EAP-TLS, and then to tell all of the other EAP methods "too bad, you're not getting updates".  People will want to use TLS 1.3 for other methods, and they will ask the very good question as to why the IETF punted on the problem.

  If there is no standard for TLS 1.3 for other methods, the customers *will* demand one, and implementors *will* create one.  At that point, the IETF will have ceded change control for those EAP methods over to those implementors.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Feb 2019 15:40:54 +0000

Hi Alan,

One could use the same argument. Those only interested in implementing 
EAP-TLS will be forced to wait while all other methods are being updated.

Anyhow, I don't expect the other document to take 18 months. I look 
forward to your submission (and reviewing it once it is available).

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Feb 2019 10:46:24 -0500

Yes.

  Sorry, but that's a good thing.  Revving one EAP method while ignoring the others is a major problem IMHO.

> forward to your submission (and reviewing it once it is available).

  It should be small.  And the WG should be incentivized to publish it quickly.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 5 Feb 2019 16:17:10 +0000

Purely a personal opinion:

Tying the fate of one document to another unless absolutely necessary is 
not a good idea. Just look at the RFC editor queue: 
https://www.rfc-editor.org/current_queue.php

There are documents with a MISSREF that were submitted to the RFC editor 
in 2014. I certainly don't want EAP-TLS to lie around for that long. 
Modular independent specs are better in my opinion.

--Mohit

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Feb 2019 15:06:44 -0500

On Feb 5, 2019, at 11:17 AM, Mohit Sethi M <[email-masked]> wrote:
> not a good idea.

  I would say that it *is* absolutely necessary to issue simultaneous TLS 1.3 updates for *all* TLS-based EAP methods.  Anything else is a complete and total disaster.

> Just look at the RFC editor queue: 

  Those missing refs are for large clusters of documents that all depend on each other.  And for whatever reason, some were submitted for publication in 2014, and the documents they need were submitted in 2019.

  This isn't happening here, so that comparison is moot.

> Modular independent specs are better in my opinion.

  To be clear, the specs aren't independent.  They all leverage TLS over EAP.  And software implements the various methods this way.  We can't just ignore these dependencies.

  I'm not saying we should hold the EAP-TLS document until the other TLS-based methods are updated.  I've tried to be clear on that.  We can publish EAP-TLS updates quickly.

  I'm saying that the second document needs to be published nearly simultaneously with the EAP-TLS document.

  Since that document is small and hopefully not contentious, this should be possible.

  Alan DeKok.