> -----Original Message-----
> From: Emu <emu-boun...@ietf.org> On Behalf Of Joseph Salowey
> Sent: 03 November 2019 18:31
> To: Alan DeKok <al...@deployingradius.com>
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG <emu@ietf.org>; John
> Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; Michael
> Richardson <m...@sandelman.ca>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>
>
> On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok
> <mailto:al...@deployingradius.com> wrote:
> On Nov 1, 2019, at 6:15 AM, John Mattsson
> <mailto:john.matts...@ericsson.com> wrote:
> > I strongly support working group adoption of draft-dekok-emu-tls-eap-types.
> Can we make sure to get this document going, I agree that this is a very
> needed
> draft. I think it should include updates for everything people wants to use.
> I do
> not think draft-ietf-emu-eap-tls13 strictly have to wait for
> draft-dekok-emu-tls-
> eap-types, but draft-dekok-emu-tls-eap-types should be published shortly
> after.
>
> I will do an update to my document shortly.
>
> I also added an issue with the EAP-TLS document on GitHub. The suggestion
> is
> to add text which explains how (and why) the EAP Identity is chosen during
> resumption:
>
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
> used during the original authentication. This requirement allows EAP packets
> to
> be routable through an AAA infrastructure to the same destination as the
> original authentication.
>
>
> 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.
>
> [Joe] Do implementations use the whole common name or just the domain
> portion. Using the whole common name is not advisable with TLS 1.3.
>
> 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.
>
> [Joe] Is EAP Identity Synonymous with the NAI?
[ofriel] I'd also like to definitively understand this. Neither RFC3748 or
RFC7542 are clear on this. Should this be an errata to clarify.. somewhere?
Two other questions on RFC3748. Section 5.1 states:
" It is RECOMMENDED that the Identity Response be used primarily for
routing purposes and selecting which EAP method to use. "
Is it defined anywhere how the Identity is used for EAP method selection? Or is
this EAP method specific and should be defined in the method specific draft?
E.g. we have documented in
https://tools.ietf.org/html/draft-lear-eap-teap-brski-05#section-5 that:
" A device that has not been bootstrapped at all SHOULD send an
identity of teap-bootstrap@TBD1. "
If we register that "teap-bootstrap@TBD1" with IANA, then it could be the
mechanism by which the peer tells the server that it wants to use TEAP. If the
server does not support TEAP, it will return an error response.
For routing, the Identity provided includes a realm and it could be anonymous:
e.g. "@example.com". If the server cannot route to that domain, it returns an
error.
EAP provides no mechanism to return an error code to the peer. How could we
signal in EAP the error difference between routing vs EAP method unsupported
failures? Or can we at all?
>
> ---
>
> Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
