On Mar 10, 2019, at 1:27 PM, Michael Richardson wrote:
>
> If there is no legit use case for TLS resumption, then it seems that EAP
> servers SHOULD disable TLS resumption.
There are very many use-cases for TLS resumption.
The point is that all of these use-cases require additional
If there is no legit use case for TLS resumption, then it seems that EAP
servers SHOULD disable TLS resumption.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Emu mailing
I would totally agree that this type of guidance needs to be added to this
document.
Jim
> -Original Message-
> From: Alan DeKok
> Sent: Sunday, March 10, 2019 5:58 AM
> To: Jim Schaad
> Cc: Michael Richardson ; EMU WG
>
> Subject: Re: [Emu] Notes on session resumption with TLS-based
On Mar 9, 2019, at 7:46 PM, Jim Schaad wrote:
> Yes - The resumption credential is on the user's device and on the TLS
> server. If the user's device moves then things are just fine. Again, the
> TLS server would need to check the credentials from the cached session
My point is that neither
Welcome and thanks for your comments Oleg!
slon v sobstvennom palto ; wrote:
>Per my experience the existing fragmentation method described in EAP-TLS
>RFC 5216 serves good for all fragmentation needs. The method is reused by
>PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS
Hi,
As there was no objections, I made the following changes to the GitHub version
that will appear in draft-ietf-emu-eap-tls13-04
Section 2.1.1
OLD:
As stated in [RFC5216], the TLS cipher suite shall not be used to
protect application data. This applies also for early application
