On 11.3.2022 9.38, Karri Huhtanen wrote:
On 4.3.2022 21.44, Alan DeKok wrote:
On Mar 4, 2022, at 1:48 PM, Heikki Vatiainen
<h...@radiatorsoftware.com> 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.
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.
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 anonym...@example.com 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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
