Alan said: "That's good. But as Bernard points out, there's no need to change EAP-TLS. You can just use TLS 1.3."
[BA] Existing implementations enable organizations to impose TLS version and ciphersuite requirements on *their* devices. For example, I have worked with organizations that require FIPS 140-3 support, who impose those cryptographic requirements through policy. Of course, such a constraint may bring with it the need to upgrade EAP-TLS clients and AAA servers - but that cost is imposed *only* on the organization imposing the policy. "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." [BA] The proposal would force the replacement of 2+ billion EAP implementations along with millions of smartcards and other hardware that is incompatible with TLS 1.3. It would also make every EAP-TLS implementation subject to patent declarations on later TLS versions. A search through the IPR declaration database discloses a horrifying number of declarations that would apply as a result. A proposal imposing such extraordinary costs requires extraordinary justification. So far, I am not aware of a declaration from any standards organization or authority that versions of TLS prior to 1.3 need to be phased out. "In addition, your other arguments are hand-waving, and don't provide concrete details to back up your position. Having concrete details would help." [BA] So far, I read the argument as "Someone implementing EAP-TLS from scratch with TLS 1.3 might not get it right." But given the *huge* number of deployed devices out there, we need something much more concrete - like test data demonstrating a real interoperability problem. On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok <al...@deployingradius.com> wrote: > 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
