Subject: [Reap] EAP - TLS 1.3

From: Mohit Sethi <[email-masked]>
Date: Thu, 16 Nov 2017 13:16:21 +0800

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 <[email-masked] 
> <mailto:[email-masked]>> 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:[email-masked]] *On Behalf Of *Bernard Aboba
>> *Sent:* Sunday, October 29, 2017 3:59 PM
>> *To:* Randy Bush <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Mohit Sethi <[email-masked] 
>> <mailto:[email-masked]>>; Security Area Advisory Group 
>> <[email-masked] <mailto:[email-masked]>>
>> *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 <[email-masked] 
>> <mailto:[email-masked]>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Nov 2017 22:12:29 -0800

- 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 <[email-masked]>
wrote:

> 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
>    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).
>
> 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
>
>
>
> 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.
>
> 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 <[email-masked]> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Bernard Aboba
> *To:* Randy Bush <[email-masked]>
> *Cc:* Mohit Sethi <[email-masked]>; Security Area Advisory
> Group <[email-masked]>
> [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.
>
>
>
> 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 <[email-masked]> wrote:
>
> > Creating a separate list has real drawbacks and very little in the way of
> > benefits.
>
> saag mailing [email-masked]://www.ietf.org/mailman/listinfo/saag
>
>
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Nov 2017 20:02:28 +0800

I don’t want to push the decision in either direction without looking into the details.

But I wanted to point out that there’s usually a third alternative between “no need for new documents” and “need a new RFC to describe the new version”. Explaining that the old protocol can be used and what the implications are may by itself be a useful document. In the specific example, is not immediately obvious to me for instance if the security consideration would somehow change, or if 0-RTT can or can not be used, etc.

Jari

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Nov 2017 08:02:03 -0500

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Nov 2017 05:56:23 -0800

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 <[email-masked]>
wrote:

>   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.
>
> >       • 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
>
> >       • 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
>   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.
>
>   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).
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Nov 2017 06:14:53 -0800

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.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Nov 2017 15:20:15 -0800

The big question is "Why not create a new EAP method"?

The overall intent seems to be to create an pre-shared key EAP method
optimized for 5G, based on EAP-TLS v1.3.

Since the protocol described will not interoperate with any of the existing
2+ billion EAP-TLS devices, why reuse the EAP-TLS code point or EAP-TLS
name?   What has been described is an entirely distinct authentication
method, not a "clarification" to an existing specification.

In fact, from how it has been described, it would appear that the new
protocol is only for use with new devices supporting 5G and new 5G servers
supporting the new method.  In which case, if the new method is not for
general use on the Internet, why can't 3GPP just define the method
themselves and allocate their own private EAP type code?

On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko <[email-masked]> wrote:

> But I wanted to point out that there’s usually a third alternative between
> “no need for new documents” and “need a new RFC to describe the new
> version”. Explaining that the old protocol can be used and what the
> implications are may by itself be a useful document. In the specific
> example, is not immediately obvious to me for instance if the security
> consideration would somehow change, or if 0-RTT can or can not be used, etc.
>
> Jari
>
>