On Nov 16, 2017, at 12:16 AM, Mohit Sethi <mohit.m.se...@ericsson.com> wrote: > > Coming back to our motivation for this draft. 3GPP has decided that > authentication in 5G can be done with any type of credential that the > operator accepts and that EAP will be used for authentication. The working > assumption is that EAP-TLS will be used for mutual authentication with > certificates. 3GPP would likely want to use TLS 1.3 as much as possible, > especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in > EAP-TLS as well as providing encryption of the handshake including the > certificates.
That's good. But as Bernard points out, there's no need to change EAP-TLS. You can just use TLS 1.3. I think one of the concerns here is the procedural aspect. Your proposal was to forbid everyone *else* from using TLS 1.0 because your requirements were for TLS 1.3. That's not the way to gain support. In addition, your other arguments are hand-waving, and don't provide concrete details to back up your position. Having concrete details would help. > If the EAP community decides that RFC5216 adequately describes how to use TLS > 1.3 and does not need an update we can live with that. Our conclusion is > however that an update of RFC2516 is needed for several reasons: > • RFC5216 is very much tied to the message flows and message formats in > TLS 1.0 - 1.2. The message flows and message content in TLS 1.3 is very > different. While a developer could theoretically figure out how to use > EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 How so? 5216 says (essentially) "encapsulate TLS within EAP". How, exactly, does this change with TLS 1.3? > and in the worst case, implementations would not even be compatible. > • TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 > is 1.2 is replaced with a HKDF. Our understanding is that an update defining > the Key Hierarchy in terms of the TLS-Exporter (similar to what is done in > draft-ietf-quic-tls) is needed. Implementations of EAP-TLS do need to change when the key derivation changes. Such as for TLS 1.2. However, those changes are largely limited to the TLS library, not the EAP-TLS code. > • RFC5216 specifies that "EAP-TLS implementations MUST support TLS > v1.0". You're free to deprecate TLS 1.0 in documents which update RFC5216... if you have IETF consensus. Further, you're free to mandate use of TLS 1.3 in 5G specifications. They're your specifications, and you're free to ignore IETF requirements if you so choose. > • RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and > MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS > version). The same comment as above applies here. > If IETF does not provide new message flow diagrams for EAP-TLS with TLS 1.3, > it is likely that 3GPP will do that, we would much rather see an IETF RFC > that 3GPP and other can refer to. What, exactly is different with the message flows in EAP-TLS when TLS 1.3 is used? Please be specific. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
