Re: [Emu] Notes on session resumption with TLS-based EAP methods
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 information. i.e. the credentials from the original authentication. As such, this document needs to give guidance on this topic. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
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 list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
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 EAP > methods > > 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 RFC 5216 nor this document gives any guidance > here. They don't even mention checking cached authentication data. > > Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Notes on session resumption with TLS-based EAP methods
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 RFC 5216 nor this document gives any guidance here. They don't even mention checking cached authentication data. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP and Fragmentation
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 RFC that >doesn't specify whether a not-fragmented message should have the L bit and >the 4 octets length field so different peers treat it differently. However, >for example, EAP-TTLS RFC closed it tightly saying that even a >single-fragment message should have it nevertheless on its redundancy. I cannot find anything in EAP-TTLS (RFC 5281) saying that the L bit should be set. As you have noticed, EAP-TLS (RFC 5216) does not say anything about the L bit in unfragmented messages and my understanding is that the ambiguity is if unfragmented messages can (not should) have the L bit set. As far as I can see, EAP-TTLS (RFC 5281) states that unfragmented messages MAY set the L bit. RFC 5281 Section 9.2.2: “Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant).” I looked through the other TLS-based EAP methods (both RFCs and drafts) and none of them seems to say anything new about the L bit. draft-ietf-emu-eap-tls13 should clarify any ambiguity. Should draft-ietf-emu-eap-tls13-04 just copy the sentence from RFC 5281 or do the group want something different? Cheers, John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question about draft-ietf-emu-eap-tls13-03 && application data
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 data. When EAP-TLS is used with TLS 1.3, early application data SHALL NOT be used. NEW: TLS 1.3 introduces early application data; early application data SHALL NOT be used with EAP-TLS. Section 2.4 ADDED: While EAP-TLS does not protect any application data, the negotiated cipher suites and algorithms MAY be used to secure data as done in other TLS-based EAP methods. Section 2.5 DELETED: Note that the use of an empty application data record does not violate the requirement that the TLS cipher suite shall not be used to protect application data, as the application data is the empty string, no application data is protected. Cheers, John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
