On 4.3.2022 21.44, Alan DeKok wrote:
On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen <[email protected]> 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:
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
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.
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 protected] 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
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
