On Dec 27, 2019, at 1:54 PM, internet-dra...@ietf.org wrote:
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08
Which adds some text about identities:
It is RECOMMENDED to use anonymous NAIs with the same realm in the
resumption and the original full authentication. This requirement
allows EAP packets to be routable to the same destination as the
original full authentication.
That's good, thanks. I still would prefer some additional text as I had
suggested. The text explains related issues in more detail:
The alternative is to derive the EAP Identity from the identity used
inside of TLS. This derivation is common practice when using
certificates, and works because the "common name" field in the
certificate is typically compatible with EAP, and it contains a
routable identifier such as an email address. This practice cannot be
used for resumption, as the PSK identity may be a binary blob, and it
might not contain a routable realm as suggested by RFC 7542.
In some cases, the PSK identity is derived by the underlying TLS
implementation, and cannot be controlled by the EAP
authenticator. These limitations make the PSK identity unsuitable for
use as the EAP Identity.
I find it's easier for people to follow recommendations when they have a full
picture of the pros and cons of the choices being recommended.
For the original authentication:
Anonymous NAIs MAY be derived from
the client certificate used in TLS. Client certificates typically
contains an identity with a routable domain such as an email address.
How is this derivation done? Many things "may" be done, but that doesn't
help guide *why* or *how* things are done.
If there's no clear guidance possible, then that should be said, too.
I also believe that the document should also RECOMMEND that the
EAP-Response/Identity be in the form of an anonymous NAI.
I would prefer to have a separate section about identities. I find the
current text a bit unclear. It helps to explain why an anonymized NAI is
useful, even when there is no email address in a certificate.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
