Re: [Reap] EAP - TLS 1.3

[Bernard Aboba <[e-mail]>]

Alan said:

" 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."

[BA] There are many organizations who have imposed cryptographic or version
policies on their EAP-TLS implementations.  For example, governments
requiring FIPS 140-3 compliance configure their AAA servers to impose that
requirement.  No change to the specification is required for members of
3GPP to configure such restrictions in their AAA servers.

Of course, imposing such a restriction is only practical if you're willing
to deny access to devices that don't implement TLS 1.3. That typically is
only workable in the case of a new service that can only be accessed with
new devices conforming to a new specification.

If that is the situation we're talking about, 3GPP can add TLS
cryptographic or version restrictions to their specifications.  That
wouldn't violate RFC 5216, and it would avoid imposing huge costs on
everyone else.

On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok <[e-mail]>
wrote:

> On Nov 16, 2017, at 12:16 AM, Mohit Sethi <[e-mail]>
> 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.
>
>