[Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)

[Michael Richardson]

On 2019-11-07 12:43 p.m., Alan DeKok wrote:
>> 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.  


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)

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.

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)




pEpkey.asc
Description: application/pgp-keys
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

[Alan DeKok]

On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> 
> 
> [ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included 
> in draft-dekok-emu-tls-eap-types?

  If they're minor, it may be OK.

> Or in draft-lear-eap-teap-brski - and note that the title is changed to " 
> TEAP Update and Extensions for Bootstrapping "? Or potentially both? Eliot, 
> Nancy and I had planned on adding TLS1.3 updates to 
> draft-lear-eap-teap-brski, but haven't got it done yet.

  Since it looks like TEAP hasn't actually been implemented much, it's probably 
best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP" 
document.

  Alan DeKok.

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Alan DeKok]

On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> [ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. 
> draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I 
> don't think TLS with extern PSK is really intended for Web/Browser HTTPS 
> connections. Its more for devices/things which are preprovisioned with the 
> extern PSK.

  Then the EAP-TLS document should disallow it, too.  If TLS 1.3 doesn't 
support it, I don't see how something built on top of TLS 1.3 can support it.

> In TLS1.3, by design the protocol does not differentiate between resumption 
> and external PSKs, and says nothing about PSK ID format, as commented here 
> https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , 
> https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc 

  Which is fine.  I'm happy to have PSKs be anything.  The caveat is that we 
then MUST forbid the PSKs from being copied to the EAP Identity field.  So the 
EAP-TLS document has to make a recommendation.

> And its application specific how the two are differentiated, the spec says 
> nothing about it: 
> https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o
> 
> I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. 
> Surely it should be an EAP server implementation decision on whether to 
> support that feature or not, but we should not preclude a specific EAP server 
> implementation from supporting extern PSK by disallowing it in the spec. If a 
> particular EAP server does not want to support extern PSK - that’s fine.

  Then we need to give guidance on what implementors and administrators should 
do.  Even if it means adding text saying "you can do certs OR PSK, but NOT 
BOTH".

  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)

[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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Joseph Salowey
> Sent: 31 October 2019 04:45
> To: Alan DeKok 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson
> ; Michael Richardson
> ; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> On Wed, Oct 30, 2019 at 4:12 AM Alan DeKok
>  wrote:
> On Oct 30, 2019, at 5:02 AM, Eliot Lear  wrote:
> > A fair argument, if it can be made, and I am not convinced it has been fully
> expressed, is the idea that there is no context by which one can separate fast
> restart and initial authentication.  This is Alan’s concern.  I’m not saying 
> it’s
> without merit, but what I cannot yet see is whether it is an implementation 
> or a
> protocol matter.
> 
>   I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the same 
> as
> resumption handshakes.
> 
>   It's not clear to me how this issue was addressed when using TLS 1.3 with
> HTTPS.  But I do believe it's an issue there, too.
> 
> [Joe] Can you elaborate on what the issue is?  I think most TLS deployments
> operate in either a certificate based mode or a PSK mode, but not both at the
> same time.

[ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. 
draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I 
don't think TLS with extern PSK is really intended for Web/Browser HTTPS 
connections. Its more for devices/things which are preprovisioned with the 
extern PSK.

In TLS1.3, by design the protocol does not differentiate between resumption and 
external PSKs, and says nothing about PSK ID format, as commented here 
https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , 
https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc 

And its application specific how the two are differentiated, the spec says 
nothing about it: 
https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o

I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. 
Surely it should be an EAP server implementation decision on whether to support 
that feature or not, but we should not preclude a specific EAP server 
implementation from supporting extern PSK by disallowing it in the spec. If a 
particular EAP server does not want to support extern PSK - that’s fine.

> 
>   As an additional note, I believe it's also important that 
> draft-dekok-emu-tls-
> eap-types be published at the same time as the EAP-TLS document.  The only
> unknown there is FAST and TEAP.  I'm happy to remove them from the
> document.
> 
>   But at this point it's not even a WG document.  There's not even consensus 
> that
> the document necessary, which surprises me rather a lot.  Because password-
> based EAP methods are *much* more wide-spread than EAP-TLS.
> 
>   If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, 
> it
> will not only look bad, it will *be* bad.  And the industry press will 
> (rightfully)
> lambast the standards process.
> 
> [Joe] We need people to contribute to the document.  If we are going to 
> publish
> a document through the working group it needs to at least to include TEAP.   I
> know there are folks on this list who are implementing.  They need to step up
> and help with this document and the TEAP errata.
> 
>   Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Owen Friel (ofriel)]

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

[Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: 01 November 2019 11:08
> To: John Mattsson 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; Michael Richardson
> ; John Mattsson
> ; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Nov 1, 2019, at 6:15 AM, John Mattsson 
> 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.

[ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included in 
draft-dekok-emu-tls-eap-types? Or in draft-lear-eap-teap-brski - and note that 
the title is changed to " TEAP Update and Extensions for Bootstrapping "? Or 
potentially both? Eliot, Nancy and I had planned on adding TLS1.3 updates to 
draft-lear-eap-teap-brski, but haven't got it done yet.

> 
>   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.
> 
> 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.
> ---
> 
>   Alan DeKok.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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