Subject: Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

From: Heikki Vatiainen <[email-masked]>
Date: Fri, 4 Mar 2022 20:48:19 +0200

On Fri, 18 Feb 2022 at 19:18, Joseph Salowey <[email-masked]> wrote:

This is a working group last call for TLS-based EAP types and TLS 1.3. The
> document is available here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/
>
> Please review the document and provide comments by March 4, 2022
>
Would it be useful to clarify the use of protected success indication, TLS
application data 0x00, with resumption. I'm mainly thinking of EAP-TTLS
which can end resumption very quickly. For example, this EAP-TTLS
resumption sequence diagram shows how resumption typically happens:
https://datatracker.ietf.org/doc/html/rfc5281#section-15.3

This EAP-TTLS RFC also mentions that this could happen with client
certificate authentication too:
https://datatracker.ietf.org/doc/html/rfc5281#section-7.6

The 3rd paragraph in Section 2 in the draft mentions 0x00 octet once and
then refers to Section 3. It also could refer to Section 4 where new text
could say something like this: If the EAP peer nor EAP server does not
initiate an "inner tunnel" method, the EAP server must send 0x00 inside the
TLS tunnel.

Section 4 in the draft already states that RFC 9190 (EAP-TLS 1.3) defines
how resumption is done. Strengthening this by mentioning 0x00 octet would
make it clear to the implementation developers that they always have to
expect and require at minimum 0x00 octet over a TLSv1.3 tunnel when an
EAP-based TLS method is about to skip tunnelled authentication.

As an example, wpa_supplicant recognises this and logs 'EAP-TTLS: ACKing
EAP-TLS Commitment Message' during EAP-TTLS resumption.

Thanks,
Heikki

-- 
Heikki Vatiainen
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Fri, 4 Mar 2022 14:44:13 -0500

On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen <[email-masked]> wrote:
> Would it be useful to clarify the use of protected success indication, TLS application data 0x00, with resumption. I'm mainly thinking of EAP-TTLS which can end resumption very quickly. For example, this EAP-TTLS resumption sequence diagram shows how resumption typically happens:
> This EAP-TTLS RFC also mentions that this could happen with client certificate authentication too: 

  I would argue that EAP-TTLS with only a client certificate doesn't make sense.  I'm not sure why it's in RFC 5281.  If you want to only use a client certificate, you should just use EAP-TLS.

  I suggest for this document that we just forbid the case of using only a client certificate with TTLS.

> The 3rd paragraph in Section 2 in the draft mentions 0x00 octet once and then refers to Section 3. It also could refer to Section 4 where new text could say something like this: If the EAP peer nor EAP server does not initiate an "inner tunnel" method, the EAP server must send 0x00 inside the TLS tunnel.

  Thanks.  I'll add some text here.

> Section 4 in the draft already states that RFC 9190 (EAP-TLS 1.3) defines how resumption is done. Strengthening this by mentioning 0x00 octet would make it clear to the implementation developers that they always have to expect and require at minimum 0x00 octet over a TLSv1.3 tunnel when an EAP-based TLS method is about to skip tunnelled authentication.

  Agreed.  I'll add some text.

  Alan DeKok.

---

From: Heikki Vatiainen <[email-masked]>
Date: Mon, 7 Mar 2022 15:40:47 +0200

On Fri, 4 Mar 2022 at 21:44, Alan DeKok <[email-masked]> wrote:

>   I would argue that EAP-TTLS with only a client certificate doesn't make
> sense.  I'm not sure why it's in RFC 5281.  If you want to only use a
> client certificate, you should just use EAP-TLS.
>

No objection from me - and it now appears to be in draft version -05. While
there may have been client software that supported this, I have not seen
any recent clients that support this. The only reason I mentioned this RFC
5281 feature is that it's mentioned in the RFC, not that I have seen it
used.

I noticed there's also a similar new paragraph in draft -05 for PEAP. This
is a good and symmetrical clarification which I see being compatible with
[MS-PEAP]. The document Microsoft maintains says very little about client
certificates, basically just allowing them to be requested by the server. I
don't see anything that changes the use of inner tunnel authentication by
the use of them and now the draft confirms this.

Thanks,
Heikki
-- 
Heikki Vatiainen
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Mon, 7 Mar 2022 08:43:40 -0500

On Mar 7, 2022, at 8:40 AM, Heikki Vatiainen <[email-masked]> wrote:
> No objection from me - and it now appears to be in draft version -05. While there may have been client software that supported this, I have not seen any recent clients that support this. The only reason I mentioned this RFC 5281 feature is that it's mentioned in the RFC, not that I have seen it used.

  I can't recall seeing it used, either.  But we'll talk about this at the next meeting, and see if there are any concerns.

> I noticed there's also a similar new paragraph in draft -05 for PEAP. This is a good and symmetrical clarification which I see being compatible with [MS-PEAP]. The document Microsoft maintains says very little about client certificates, basically just allowing them to be requested by the server. I don't see anything that changes the use of inner tunnel authentication by the use of them and now the draft confirms this.

  If I recall, Windows can't do client certs for PEAP.  Maybe that changed with Windows 11 and TLS 1.3.  But it didn't work historically.

  I think it's a good idea to forbid (a) duplicate features, and (b) features no one uses, and (c) features we're not sure have any value.

  Alan DeKok.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 7 Mar 2022 15:44:56 +0000

Maybe it is a terminology issue but TLS at least requires server-authentication.

From: Emu <[email-masked]> On Behalf Of Heikki Vatiainen
Sent: Monday, March 7, 2022 2:41 PM
To: Alan DeKok <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

On Fri, 4 Mar 2022 at 21:44, Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Heikki
--
Heikki Vatiainen
[email-masked]<mailto:[email-masked]>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Heikki Vatiainen <[email-masked]>
Date: Tue, 8 Mar 2022 11:39:28 +0200

> Maybe it is a terminology issue but TLS at least requires

Terminology issue, I think. By "only client certificate" I'm thinking of
what a client needs to do to authenticate. The use of server-authentication
with server certificate remains as it is.

EAP-TTLS RFC discusses the possibility of client-authentication with
certificate being sufficient for completing the whole authentication dialog
without tunnelled (AKA phase2) authentication. As far as I know, this
hasn't been used, not at least recently, and now when TLS 1.3 forces
changes to implementations it would also provide a good chance to let go of
features that are not needed any longer.

Thanks,
Heikki

--
Heikki Vatiainen
[email-masked]

---

From: Karri Huhtanen <[email-masked]>
Date: Fri, 11 Mar 2022 09:38:46 +0200

>    I suggest for this document that we just forbid the case of using only a client certificate with TTLS.

There is one corner use case for using client certificates within 
EAP-TTLS and that is to hide the actual client certificate details for 
privacy or interoperability reasons within the TTLS.

Many EAP-TTLS implementations allow defining the EAP outer identity 
separately from the inner identity. This makes it possible to envelope 
the actual client certificate and its details, but have an anonymous 
identity such as for example [email-masked] as an outer identity, 
but then use any client certificate as the inner identity.

In the federated roaming, such as eduroam/govroam/etc., one can now fix 
routing of the otherwise not routable client certificates (e.g. the ones 
missing realms in CN/SubjectAltName) and also in some cases hide the 
client certificate details behind that anonymous envelope.

Nowadays it seems that also with Windows systems one can define realms 
to be part of the CN/SubjectAltName more freely when issuing client 
certificates so from the routing perspective this is not so important 
anymore since EAP-TLS with routing compatible certificates can be used.

I think the privacy aspect still remains or can this be solved with 
EAP-TLS or TLSv1.3 developments?

// kh

---

From: Karri Huhtanen <[email-masked]>
Date: Fri, 11 Mar 2022 12:53:34 +0200

On 11.3.2022 9.38, Karri Huhtanen wrote:
>>> Would it be useful to clarify the use of protected success 
>>> indication, TLS application data 0x00, with resumption. I'm mainly 
>>> thinking of EAP-TTLS which can end resumption very quickly. For 
>>> example, this EAP-TTLS resumption sequence diagram shows how 
>>> resumption typically happens:
>>    I would argue that EAP-TTLS with only a client certificate doesn't 
>> make sense.  I'm not sure why it's in RFC 5281.  If you want to only 
>> use a client certificate, you should just use EAP-TLS.
>>

Heikki clarified that this was about the phase1 so the use case in my 
previous email and below does not apply. It may however be something to 
be considered in other drafts if binding of the outer and inner identity 
realm is defined.

// kh

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Mar 2022 08:45:05 -0500

On Mar 11, 2022, at 5:53 AM, Karri Huhtanen <[email-masked]> wrote:
> Heikki clarified that this was about the phase1 so the use case in my previous email and below does not apply.

  Yes.  TLS 1.3 encrypts the client certificate, so there's no need to "hide" EAP-TLS inside of another EAP method.

  It probably wouldn't hurt to forbid the use of it, to be honest.  But that's a larger question for the working group.

  i.e. does TTLS with inner EAP-TLS add any value?  Is it useful?

> It may however be something to be considered in other drafts if binding of the outer and inner identity realm is defined.

  The current draft has a long section on inner vs outer identities:  https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-05#section-3.1

  In short, there's no reason to have different realms for inner/outer identities.  Either the inner identity has no realm, or the realm matches the outside one.

  The only use-case for different realms is to separate AAA routing from AAA authentication.  i.e. a company "example.com" defines users, but the AAA server is hosted at "example.org".  In that case, the outer identity would route the packets to the hosting provider, who would then use the inner identity to authenticate the user.

  IMHO this practice should be strongly discouraged, for reasons discussed in the draft.

  Alan DeKok.