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

2019-11-11 Thread Owen Friel (ofriel)



> -Original Message-
> From: Alan DeKok 
> Sent: 07 November 2019 17:43
> To: Owen Friel (ofriel) 
> Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org;
> EMU WG ; John Mattsson
> ; Michael Richardson
> 
> Subject: Re: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu-
> eap-tls13)
> 
> On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> >> [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?
> 
>   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.

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

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

[ofriel] Ok, thanks.

> 
>   Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2019-11-07 Thread Alan DeKok
On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
>> [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?

  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.

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

  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.

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

  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.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu