- RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2.
[BA] EAP-TLS encapsulates TLS within EAP so the basic protocol flow is not version dependent. The (non-normative) examples were designed to illustrate the EAP-TLS protocol flow, so though they are based on TLS 1.0/1.1 (1.2 came later) that doesn't affect the protocol. - 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 and in the worst case, implementations would not even be compatible. [BA] While the TLS protocol changes with version 1.3, the basic flow of the EAP conversation (and EAP-TLS) does not change - it's just a tunneling protocol that takes TLS blobs and encapsulates them in EAP. As a result, there are already experimental implementations of EAP-TLS based on version 1.3 that required minimal code changes in EAP-TLS. Do you have an implementation of EAP-TLS that supported earlier versions? - 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. TLS 1.3 Section 7.3 defines how the keys are calculated - and so the TLS-Exporter changes should be straightforward. - RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0". [BA] Support for TLS v1.0 is required for backward compatibility. EAP-TLS has been deployed on over 2+ billion systems and is supported by a hardware ecosystem. Many of those existing implementations would be broken if the requirement to support TLS v1.0 were to be removed. So while any organization can decide they only want to allow a given version of TLS, the requirement to support 1.0 must remain. - 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). Those ciphersuite choices were based on the need for backward compatibility. An organization mandating more advanced versions of TLS will automatically inherit the mandatory ciphersuites of those versions. So this doesn't preclude interoperability of EAP-TLS 1.1, 1.2, 1.3 or any future version of TLS. On Wed, Nov 15, 2017 at 9:16 PM, Mohit Sethi <mohit.m.se...@ericsson.com> wrote: > Hi Bernard, > > 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. > > 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 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. > - RFC5216 specifies that "EAP-TLS implementations MUST support TLS > v1.0". > - 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). > > 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. > > John and Mohit > > > > On 10/30/2017 10:37 AM, Bernard Aboba wrote: > > RFC 5216 only insists on support (not use) of TLS 1.0 and its mandatory > ciphersuites in order to ensure interoperability with legacy > implementations and avoid an Internet-wide “flag day” requiring millions of > hardware devices to be replaced. But if a site wants to impose a TLS > version (and ciphersuite) policy, it can. > > Mandatory to support algorithms apply to a TLS version, so EAP-TLS > inherits them when that version is negotiated. Similarly, EAP-TLS inherits > features of each TLS version - all it does is tunnel TLS. > > Given this, I am puzzled as to why it is being proposed that RFC 5216 be > recycled at Proposed in a non-backward compatible manner with vast new IPR > encumbrance, completely new authors, and nearly identical text, rather than > being left alone or moving to the next standards level. > > > > > > > > On Oct 29, 2017, at 5:20 PM, Jim Schaad <i...@augustcellars.com> wrote: > > There is one advantage that can be obtained by using TLS 1.3, if you want > to hide the client name then it is no longer necessary to do an anonymous > connection followed immediately by a re-negotiation with the proper client > certificate. But that and perhaps mandatory algorithms is the only think I > can think of right off the bat. > > > > Jim > > > > > > *From:* saag [mailto:saag-boun...@ietf.org <saag-boun...@ietf.org>] *On > Behalf Of *Bernard Aboba > *Sent:* Sunday, October 29, 2017 3:59 PM > *To:* Randy Bush <ra...@psg.com> > *Cc:* Mohit Sethi <mohit.m.se...@ericsson.com>; Security Area Advisory > Group <s...@ietf.org> > *Subject:* Re: [saag] [Reap] PSA: New list for discussing EAP related > methods > > > > Randy asked: > > > > "bernard, for the clueless here, what change is needed for tls 1.3?" > > and > > > > [BA] None as far as I know. EAP-TLS makes use of TLS version negotiation > so it is both forward and backward compatible. So far, implementations of > RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as > far as I am aware. > > > > In general, EAP-TLS can leverage TLS policies the administrator chooses to > impose. So if the administrator wants to impose a version policy (e.g. > TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4), there > are a number of EAP servers that can be configured to support this. > > > > So rather than attempting to impose an Internet-wide TLS version or > ciphersuite policy (which would impose a huge cost on everyone, given that > there are 2+ billion devices supporting EAP-TLS), it makes a lot more sense > to let the administrators decide, possibly based on guidance from > organizations they trust, such as NIST. This is how things have been > working for more than a decade. > > > > > > > > > > > > > > > > > > > > On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush <ra...@psg.com> wrote: > > > Creating a separate list has real drawbacks and very little in the way of > > benefits. > > bernard, for the clueless here, what change is needed for tls 1.3? > > randy > > > > > > _______________________________________________ > saag mailing listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag > > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
