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 <mailto: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] *On Behalf Of *Bernard Aboba *Sent:* Sunday, October 29, 2017 3:59 PM *To:* Randy Bush <ra...@psg.com <mailto:ra...@psg.com>>*Cc:* Mohit Sethi <mohit.m.se...@ericsson.com <mailto:mohit.m.se...@ericsson.com>>; Security Area Advisory Group <s...@ietf.org <mailto:s...@ietf.org>> *Subject:* Re: [saag] [Reap] PSA: New list for discussing EAP related methodsRandy 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 <mailto: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 list s...@ietf.org https://www.ietf.org/mailman/listinfo/saag
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
