Subject: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 7 Nov 2019 17:30:07 +0000

> -----Original Message-----
> From: Emu <[email-masked]> On Behalf Of Joseph Salowey
> Sent: 03 November 2019 18:31
> To: Alan DeKok <[email-masked]>
> Cc: [email-masked]; EMU WG <[email-masked]>; John
> Mattsson <john.mattsson=[email-masked]>; Michael
> Richardson <[email-masked]>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok
> <mailto:[email-masked]> wrote:
> On Nov 1, 2019, at 6:15 AM, John Mattsson
> <mailto:[email-masked]> 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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Nov 2019 12:43:09 -0500

> [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?

  The EAP Identity can largely be anything, so long as it is UTF-8.

 The *recommendation* in RFC 7542 is to make it an NAI.  But that isn't mandated anywhere.

  I'm not sure there's any errata required.

> Is it defined anywhere how the Identity is used for EAP method selection?

  It is absolutely not mentioned anywhere.  For the simple reason that EAP provides for method negotiation.  We don't need to overload the Identity field.

  The issue we're running into here is not about EAP method selection.  It's about *TLS* method selection (PSK vs certs).  And that officially has little to do with EAP.

> Or is this EAP method specific and should be defined in the method specific draft?

  No EAP document should recommend overloading Identity in order to do EAP method selection.

> 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…

  The discussion prior to IETF 105 was that we should use the ".arpa" domain:  https://www.iana.org/domains/arpa  That domain is explicitly intended for this kind of negotiation.  

  Note that using ".arpa" still isn't EAP method selection.  It's instead signalling something else.

> 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.

  i.e. an EAP Failure message.

> 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?

  EAP provides for a NAK for negotiation, and a Notification packet for signalling errors or messages. Unfortunately, most supplicants don't support Notification.  And the ones that do won't show Notification messages to the end user.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 7 Nov 2019 14:10:23 -0500

>   The discussion prior to IETF 105 was that we should use the ".arpa" domain:  https://www.iana.org/domains/arpa  That domain is explicitly intended for this kind of negotiation.  

BTW, related to BRSKI is that the 6tisch CoJP protocol uses 6tisch.arpa
in the CoAP header.

(Not that we'd use the same one, but registering it wasn't hard)

>   EAP provides for a NAK for negotiation, and a Notification packet for signalling errors or messages. Unfortunately, most supplicants don't support Notification.  And the ones that do won't show N…

Owen, do we have a need to recognize that a device needs to perform
onboarding again after a movement?

i.e. device A enrolls on network 1, gets an LDevID usable on network 1,
uses that with EAP-FOOBAR.

device A then is moved to network 2, it tries to use same LDevID,
receives an error and then recognizes that it needs to perform another
enrollment.

What is that error, and is it recognizeable?  Do we need a new error
code to distinguish from "I reject you" from "I reject you but, you
could try enrolling with BRSKI-TEAP"

(hoping re-installed laptop works)

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 11 Nov 2019 17:27:45 +0000

> From: Alan DeKok <[email-masked]>
> Sent: 07 November 2019 17:43
> To: Owen Friel (ofriel) <[email-masked]>
> Cc: Joseph Salowey <[email-masked]>; [email-masked];
> EMU WG <[email-masked]>; John Mattsson
> <john.mattsson=[email-masked]>; Michael Richardson
> <[email-masked]>
> Subject: Re: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu-
> eap-tls13)
> 
> > [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?
> 

[ofriel] On reading RFC 7542 again, I certainly agree with the sentiment that the NAI is recommended for EAP identity, but I don't see that actually being explicitly definitively stated anywhere in the document.

>   It is absolutely not mentioned anywhere.  For the simple reason that EAP
> provides for method negotiation.  We don't need to overload the Identity field.

[ofriel] then why does https://tools.ietf.org/html/rfc3748#section-5.1 explicitly state " It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use."

It explicitly states: "selecting which EAP method to use "

Should there be an errata for RFC 3748 to remove the last few words from that sentence: "and selecting which EAP method to use"?

And the "EAP provides for method negotiation" is via Nak messages, Ok, then my confusion was on the EAP method selection statement in section 5.1.

> 
>   The issue we're running into here is not about EAP method selection.  It's about
> *TLS* method selection (PSK vs certs).  And that officially has little to do with
> EAP.

[ofriel]  Sure, but that's not what I am getting at, I was asking about EAP method selection and my confusion between the statements in sections 5.1/Identity and 5.3/Nak.
> > 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.
> 
>   The discussion prior to IETF 105 was that we should use the ".arpa" domain:
> https://www.iana.org/domains/arpa  That domain is explicitly intended for this
> kind of negotiation.
> 
> > 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?
> 
>   EAP provides for a NAK for negotiation, and a Notification packet for signalling
> errors or messages. Unfortunately, most supplicants don't support Notification.
> And the ones that do won't show Notification messages to the end user.

[ofriel] Ok, thanks.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Nov 2019 12:39:23 -0500

> [ofriel] On reading RFC 7542 again, I certainly agree with the sentiment that the NAI is recommended for EAP identity, but I don't see that actually being explicitly definitively stated anywhere in…

  The document recommend using NAI everywhere.  Unfortunately it couldn't update EAP.

> It explicitly states: "selecting which EAP method to use "

   See the 3G specs, or Section 4 of RFC 7542

   For instance, some EAP methods apply
   method-specific pseudonyms in the username part of the NAI [RFC3748].

> Should there be an errata for RFC 3748 to remove the last few words from that sentence: "and selecting which EAP method to use"?

  I don't think so.

> And the "EAP provides for method negotiation" is via Nak messages, Ok, then my confusion was on the EAP method selection statement in section 5.1.

  EAP is unfortunately complex.

  Alan DeKok.