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

[Joseph Salowey]

On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok 
wrote:

> On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel) 
> wrote:
> >
> > [ofriel]  Is the primary reason they MUST NOT be copied because of
> encoding differences? UTF-8 vs. TLS raw bytes?
>
>   Yes.  EAP Identities are UTF-8 encoded strings.  Non-compliant
> identities will likely result in the packet being dropped.
>
> > On the privacy aspect, as the TLS PSK ID is sent unprotected and
> unencrypted in cleartext in the ClientHello, what information leakage are
> we preventing by not sending that same data in cleartext in the Identity
> Response?
>
>   Not much.  Except that if we send the data in the Identity, it MUST be
> encoded in some format which is acceptable to EAP, RADIUS, etc.
>
>   Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets
> in length.  While EAP can carry large identities, RADIUS cannot.  So we're
> left with a practical limitation of ~250 octets for the identity field.
>
>   At that point, it's best to recommend that the EAP Identity carry only
> an anonymous NAI.  That avoids the issue of PSK length and encoding
> entirely.  Further, it means that all uses of EAP-TLS have the same
> recommendation: the Identity is an anonymous NAI.
>
>
[Joe] I agree that its best to only include the anonymous NAI.  Including
more information may cause a problem if the PSK works changes in the future
or if you are copying the original NAI into subsequent transactions.


> > This is a different question to the difference between an extern PSK and
> a resumption PSK. That is implementation specific and not defined in TLS1.3
>
>   i.e. "good luck".  :(
>
>   It's difficult for implementors to do the right thing in such a
> situation.
>
> > [ofriel] I agree some implementation advice would be good here. Should
> this be in EAP, or should we push for a TLS1.3 errata? It's the same advice
> that a standard TLS1.3 server implementor needs. OpenSSL for example
> defines its own resumption format, and provides a callback hook to check
> for extern PSKs, and it looks like OpenSSL lets the application check for
> an extern PSK match first before checking its internal resumption cache:
> https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093.
> But of course that is TLS stack specific. We would need to document
> guidance olong the lines of checking for TLS stack behaviour.
>
>   I think it's best to give guidance in this document.
>
>
[Joe] If its needed then I also think we should include it in the EAP-TLS
document.  It wouldn't be bad to file an errata on TLS 1.3, but I think
this is more of a corner case for them.


>   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

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

[Alan DeKok]

On Nov 11, 2019, at 12:52 PM, Owen Friel (ofriel)  wrote:
> 
> [ofriel]  Is the primary reason they MUST NOT be copied because of encoding 
> differences? UTF-8 vs. TLS raw bytes?

  Yes.  EAP Identities are UTF-8 encoded strings.  Non-compliant identities 
will likely result in the packet being dropped.

> On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypted 
> in cleartext in the ClientHello, what information leakage are we preventing 
> by not sending that same data in cleartext in the Identity Response?

  Not much.  Except that if we send the data in the Identity, it MUST be 
encoded in some format which is acceptable to EAP, RADIUS, etc.

  Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets in 
length.  While EAP can carry large identities, RADIUS cannot.  So we're left 
with a practical limitation of ~250 octets for the identity field.

  At that point, it's best to recommend that the EAP Identity carry only an 
anonymous NAI.  That avoids the issue of PSK length and encoding entirely.  
Further, it means that all uses of EAP-TLS have the same recommendation: the 
Identity is an anonymous NAI.

> This is a different question to the difference between an extern PSK and a 
> resumption PSK. That is implementation specific and not defined in TLS1.3

  i.e. "good luck".  :(

  It's difficult for implementors to do the right thing in such a situation.

> [ofriel] I agree some implementation advice would be good here. Should this 
> be in EAP, or should we push for a TLS1.3 errata? It's the same advice that a 
> standard TLS1.3 server implementor needs. OpenSSL for example defines its own 
> resumption format, and provides a callback hook to check for extern PSKs, and 
> it looks like OpenSSL lets the application check for an extern PSK match 
> first before checking its internal resumption cache: 
> https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093.
>  But of course that is TLS stack specific. We would need to document guidance 
> olong the lines of checking for TLS stack behaviour.

  I think it's best to give guidance in this 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

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: 08 November 2019 12:43
> To: Joseph Salowey 
> Cc: EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Nov 7, 2019, at 11:08 PM, Joseph Salowey  wrote:
> > [Joe] How about
> > "If an implementation supports an external PSK it MUST provide a way to
> configure the realm so it can create an Anonymous NAI to send in the EAP-
> Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the PSK-ID
> into the EAP-Identity response. "
> 
>   That's good.

[ofriel]  Is the primary reason they MUST NOT be copied because of encoding 
differences? UTF-8 vs. TLS raw bytes?

On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypted in 
cleartext in the ClientHello, what information leakage are we preventing by not 
sending that same data in cleartext in the Identity Response?

Note that TLS1.3 PSK IDs are different to TLS1.3 client certs: PSK IDs are sent 
in cleartext in the ClientHello, client certs are sent encrypted inside the 
client's second flight. PSK IDs are not protected, client certs are (assuming 
of course that the client can validate the server identity when the server 
sends its first flight to the client).


> 
> > If someone thinks there is a need to allow the PSK-ID to be copied then the
> phrase could be extended with " unless there is prior knowledge that this will
> have an acceptable impact to privacy and the use case supports Identity
> responses that are not in the form of an NAI.
> 
>   ... and the PSK identity is compatible with the requirements of the EAP 
> Identity
> field, i.e. UTF-8.
> 
> > [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as
> mutually exclusive for a particular handshake.   I do not think it restricts a
> particular server from supporting both external PSK and certificate
> authentication for separate connections.

[ofriel] Right.

> 
>   OK.  I'm back to "how do you tell?"

[ofriel]  You can of course trivially tell the difference between an extern PSK 
and a cert based auth - the ClientHellos are different.

This is a different question to the difference between an extern PSK and a 
resumption PSK. That is implementation specific and not defined in TLS1.3

> 
>   If the document suggests that plain PSK is OK, it would be very useful to
> describe the impact of that.  What does an implementation do?  How should
> administrators tell PSK identities apart?  If the EAP authenticator can't 
> control
> the derivation of PSK identities for resumption, is it even possible to have
> manually provisioned PSKs?

[ofriel] I agree some implementation advice would be good here. Should this be 
in EAP, or should we push for a TLS1.3 errata? It's the same advice that a 
standard TLS1.3 server implementor needs. OpenSSL for example defines its own 
resumption format, and provides a callback hook to check for extern PSKs, and 
it looks like OpenSSL lets the application check for an extern PSK match first 
before checking its internal resumption cache: 
https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093.
 But of course that is TLS stack specific. We would need to document guidance 
olong the lines of checking for TLS stack behaviour.

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

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

[Owen Friel (ofriel)]

> -Original Message-
> From: Alan DeKok 
> Sent: 07 November 2019 17:48
> To: Owen Friel (ofriel) 
> Cc: Joseph Salowey ; 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 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.

[ofriel]  TLS1.3 does not allow both PSK and cert based auth simultaneously on 
the same TLS session. It does allows support of both PSK and cert based auth on 
the same server, just on different TLS sessions. What 
draft-ietf-tls-tls13-cert-with-extern-psk does is allow both PSK and cert based 
auth simultaneously on the same TLS session. I can see how my statement was 
confusing, apologies.

> 
> > 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".
[ofriel] You can do certs or PSK on the same TLS server, just not on the same 
TLS session. Unless draft-ietf-tls-tls13-cert-with-extern-psk became a thing.
> 
>   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 11:08 PM, Joseph Salowey  wrote:
> [Joe] How about 
> "If an implementation supports an external PSK it MUST provide a way to 
> configure the realm so it can create an Anonymous NAI to send in the 
> EAP-Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the 
> PSK-ID into the EAP-Identity response. "

  That's good.

> If someone thinks there is a need to allow the PSK-ID to be copied then the 
> phrase could be extended with " unless there is prior knowledge that this 
> will have an acceptable impact to privacy and the use case supports Identity 
> responses that are not in the form of an NAI.  

  ... and the PSK identity is compatible with the requirements of the EAP 
Identity field, i.e. UTF-8.

> [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as 
> mutually exclusive for a particular handshake.   I do not think it restricts 
> a particular server from supporting both external PSK and certificate 
> authentication for separate connections.  

  OK.  I'm back to "how do you tell?"

  If the document suggests that plain PSK is OK, it would be very useful to 
describe the impact of that.  What does an implementation do?  How should 
administrators tell PSK identities apart?  If the EAP authenticator can't 
control the derivation of PSK identities for resumption, is it even possible to 
have manually provisioned PSKs?

  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] 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
> <mailto:al...@deployingradius.com> wrote:
> On Oct 30, 2019, at 5:02 AM, Eliot Lear <mailto:l...@cisco.com> 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

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

[Alan DeKok]

  After checking the draft again, Section 2.1.4 does have comments about 
anonymizing the NAI.  But those comments are limited to NAIs derived from 
certificates.

  I think that the text needs to be expanded to make the recommendations more 
genetic, and clearer.  I hope that my previous message clarified some of the 
issues here.

  I would like to see some discussion of these topics in the draft.  I don't 
think it's clear enough that the EAP Identity should always be "@realm", and 
there is no discussion on EAP Identity and resumption.

  I would suggest a new section called "Identities".  This section could go 
after 2.1.1, and incorporate some existing text from the Privacy section.  
Suggested text follows.

Identities

EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
username in cleartext in the Identity Response.  It is RECOMMENDED to
use anonymous NAIs, but other solutions where the username is
encrypted MAY be used.

This recommendation applies to all uses of EAP-TLS, no matter the underlying 
TLS authentication mechanism.  This recommendation also applies when resumption 
is used.

The anonymous NAI can often be derived automatically.  When certificates are 
used, the certificate common name is often in the form of an email address.  
The anonymous NAI can be derived from that address by using only the "@realm" 
portion.  This derivation has privacy implications, as discussed in the Privacy 
section, below.

In some cases, the anonymous NAI cannot be derived from the underlying TLS 
authentication mechanism.  For example, when PSKs are used, the PSK identity 
may be an opaque binary string.  Binary data is not compatible with the EAP 
Response / Identity field, as Section 5.1 of 3748 requires that the Identity 
field be composed solely of UTF-8 encoded ISO 10646 characters.  Instead, the 
Identity may be statically pre-provisioned.  Or for resumption, the Identity 
used for resumption SHOULD be the same as the Identity used for the original 
authentication.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

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?


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

[Eliot Lear]

Hi!

> On 1 Nov 2019, at 13:05, Alan DeKok  wrote:
> 
> On Nov 1, 2019, at 7:53 AM, Eliot Lear  wrote:
>> 
>>> 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.
>> 
>> Just a question: why SHOULD and not MUST?
> 
>  I'm happy to have it a MUST.
> 
>  I'm prepared for some people to say it can be different, i.e a different AAA 
> server can be used for resumed sessions.  But I don't see that as important.
> 
>>> 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.
>> 
>> Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for 
>> federated realms (we may both have this wrong).  My presumption here is that 
>> an anonymous NAI is always used, but that the realm is what people would key 
>> off of, and this would always be present.
> 
>  As the EAP Identity, yes.
> 
>> But that presumption doesn’t hold true with the current TEAP update that 
>> we’re working on and that may be problematic.  In any case, this means that 
>> that at least the externalized identity can be used to route, and that 
>> normal TLS semantics can be used for authenticating.  It does require that 
>> tickets be managed on both ends.
> 
>  If the authentications are performed within a constrained system, it's fine 
> to skip using NAIs.  I would suggest that for device bootstrapping you want 
> to ensure that the authentications *aren't* routed outside of the current 
> network.  So they *shouldn't* use a realm.


Ok.  Got it.  I think we have to be quite careful about use of the realm, then, 
and mechanism selection must be done exclusively with EAP-Request/Type.  I 
think it’s okay for federations to bootstrap; although we needn’t define that 
here.

I’ll be updating our draft accordingly.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
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 1, 2019, at 7:53 AM, Eliot Lear  wrote:
> 
>> 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.
> 
> Just a question: why SHOULD and not MUST?

  I'm happy to have it a MUST.

  I'm prepared for some people to say it can be different, i.e a different AAA 
server can be used for resumed sessions.  But I don't see that as important.

>> 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.
> 
> Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for 
> federated realms (we may both have this wrong).  My presumption here is that 
> an anonymous NAI is always used, but that the realm is what people would key 
> off of, and this would always be present.

  As the EAP Identity, yes.

>  But that presumption doesn’t hold true with the current TEAP update that 
> we’re working on and that may be problematic.  In any case, this means that 
> that at least the externalized identity can be used to route, and that normal 
> TLS semantics can be used for authenticating.  It does require that tickets 
> be managed on both ends.

  If the authentications are performed within a constrained system, it's fine 
to skip using NAIs.  I would suggest that for device bootstrapping you want to 
ensure that the authentications *aren't* routed outside of the current network. 
 So they *shouldn't* use a realm.

  That's why my suggested text said "resumption uses same identity as the 
original authentication"  whatever that is.  That initial identity doesn't 
need to be an NAI.

  However, the identities still need to be acceptable to EAP / AAA systems.  
Which means that any binary identity should likely be converted to a 
"printable" form, via something like base64.

> My presumption is further that federation doesn’t really occur beyond the TLS 
> endpoint, of it it does that is entirely an internal matter for the server.

  Yes.

  Federation works because nothing examines the contents of EAP.  Instead, the 
packets are routed solely based on the NAI.

>  We have a working example of callouts based on the identity of a client for 
> purposes of authorization, but for authentication, I would think that would 
> be largely a bad idea, due to secret sharing issues (when I say “federation” 
> I mean that there should be no trust TLS secret sharing).
> 
> Is my understanding correct?

  Yes.

  There may be federations which share a common CA cert.  But each 
authentication system is unique, and does not share its secrets / identity with 
any other system.

  Aln DeKok.

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

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

[Eliot Lear]

Thanks, Alan.  Please see below.

> On 1 Nov 2019, at 12:08, 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.

Just a question: why SHOULD and not MUST?

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

Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for 
federated realms (we may both have this wrong).  My presumption here is that an 
anonymous NAI is always used, but that the realm is what people would key off 
of, and this would always be present.  But that presumption doesn’t hold true 
with the current TEAP update that we’re working on and that may be problematic. 
 In any case, this means that that at least the externalized identity can be 
used to route, and that normal TLS semantics can be used for authenticating.  
It does require that tickets be managed on both ends.

My presumption is further that federation doesn’t really occur beyond the TLS 
endpoint, of it it does that is entirely an internal matter for the server.  We 
have a working example of callouts based on the identity of a client for 
purposes of authorization, but for authentication, I would think that would be 
largely a bad idea, due to secret sharing issues (when I say “federation” I 
mean that there should be no trust TLS secret sharing).

Is my understanding correct?

Eliot


> ---
> 
>  Alan DeKok.
> 



signature.asc
Description: Message signed with OpenPGP
___
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 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.

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

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

[Joseph Salowey]

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.


>   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

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

[Joseph Salowey]

Hi Jorge,

Thanks for joining the conversation.

On Wed, Oct 30, 2019 at 6:11 PM Jorge Vergara  wrote:

> Hello - I am the primary maintainer of Microsoft's EAP implementation. I
> am sorry for joining late to this conversation, but hope our input is
> welcome.
>
> On the topic of draft-dekok-emu-tls-eap-types:
>
> I agree that it is necessary to standardize other TLS based EAP methods at
> the same time as EAP-TLS. The alternatives if this doesn't happen were
> discussed here previously at
> https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo -
> namely, either implementations will forge ahead with non-standard updates
> anyways, or they will be forced to wait to update EAP-TLS until the other
> methods are updated.
>
> We are taking the second approach - we do not plan to update our EAP-TLS
> implementation until it is clear what the updates to other EAP methods will
> look like. We do not want to see non-standard vendor implementations to
> become difficult to implement de-facto standards. We would also like to see
> TEAP covered in this update.
>
> A brief review on the material contained in the
> draft-dekok-emu-tls-eap-types:
>
> I believe the 0x00 "Commitment message" not to send anymore TLS handshake
> data should be mentioned in this document, since it was established during
> https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo
> that even tunnel based methods will need this.
>
> The key derivation proposed for TEAP/FAST uses the definition from FAST,
> which is not identical to the TEAP derivation. Namely, FAST used MSK[j] in
> the derivation, but TEAP uses IMSK[j], which may be equivalent in some
> cases, but may not in others where the inner method exports an EMSK. I
> understand there may be a TEAP errata related to this and I may not be
> fully up to date on the errata discussion, so perhaps this is already taken
> into consideration.
>
>
[Joe] I know that Alan has been asking for help with this draft especially
with TEAP and EAP-FAST.  I hope that you and others can work with him to
get the draft in a shape that we can progress through the working group.  I
agree that this is an important thing to do.

The EAP-TLS 1.3 draft is fairly far along and I do not think we have
consensus to add TEAP into the document at this point, but I think we can
make faster progress on the TLS types document if we have people interested
in working on it.


> Jorge Vergara
>
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Wednesday, October 30, 2019 4:12 AM
> To: Eliot Lear 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson  40ericsson@dmarc.ietf.org>; Michael Richardson ;
> EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>
> 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.
>
>   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.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3Dreserved=0
> ___
> 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

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

[Jorge Vergara]

Hello - I am the primary maintainer of Microsoft's EAP implementation. I am 
sorry for joining late to this conversation, but hope our input is welcome.

On the topic of draft-dekok-emu-tls-eap-types:

I agree that it is necessary to standardize other TLS based EAP methods at the 
same time as EAP-TLS. The alternatives if this doesn't happen were discussed 
here previously at 
https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo - namely, 
either implementations will forge ahead with non-standard updates anyways, or 
they will be forced to wait to update EAP-TLS until the other methods are 
updated.

We are taking the second approach - we do not plan to update our EAP-TLS 
implementation until it is clear what the updates to other EAP methods will 
look like. We do not want to see non-standard vendor implementations to become 
difficult to implement de-facto standards. We would also like to see TEAP 
covered in this update.

A brief review on the material contained in the draft-dekok-emu-tls-eap-types:

I believe the 0x00 "Commitment message" not to send anymore TLS handshake data 
should be mentioned in this document, since it was established during 
https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo that even 
tunnel based methods will need this.

The key derivation proposed for TEAP/FAST uses the definition from FAST, which 
is not identical to the TEAP derivation. Namely, FAST used MSK[j] in the 
derivation, but TEAP uses IMSK[j], which may be equivalent in some cases, but 
may not in others where the inner method exports an EMSK. I understand there 
may be a TEAP errata related to this and I may not be fully up to date on the 
errata discussion, so perhaps this is already taken into consideration.

Jorge Vergara

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Wednesday, October 30, 2019 4:12 AM
To: Eliot Lear 
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 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.

  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.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3Dreserved=0
___
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 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.

  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.

  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

[Eliot Lear]

> On 30 Oct 2019, at 06:22, Joseph Salowey  wrote:
> 
> 
> 
> On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear  > wrote:
> 
> 
> > On 11 Oct 2019, at 16:09, Michael Richardson  > > wrote:
> >
> > So, can wired just be a degenerate version of wifi, where there can be only
> > one "ESSID", and there are no beacons to consider?
> 
> 
> On the whole that has been my thought.  But it is a matter of which mechanism 
> to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public keys++?  
> And again, this is the on-prem case.  For cloud, we are well along.
> 
> [Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem 
> right to delay it for functionality that we are not sure we have a use case 
> for.  If a use case develops then we can publish an update to EAP-TLS 1.3.  
> Do we have a use case for EAP-TLS-PSK that is blocked in the current 
> situation?
> 

I would suggest that we do have a well-identified use case, although it has 
some issues, and that is IoT onboarding for on-prem equipment, as Owen 
described.  I do not know if we will end up executing on that use case, but it 
is a use case.  On the whole, the argument has to go the other way: why should 
we cripple a particular TLS method without strong justification?  The more we 
specialize the longer it takes to deliver new services, and the harder they are 
to support.

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.

Eliot

> 
> 
> Eliot



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

On Fri, Oct 11, 2019 at 7:34 AM Eliot Lear  wrote:

>
>
> > On 11 Oct 2019, at 16:09, Michael Richardson  wrote:
> >
> > So, can wired just be a degenerate version of wifi, where there can be
> only
> > one "ESSID", and there are no beacons to consider?
>
>
> On the whole that has been my thought.  But it is a matter of which
> mechanism to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public
> keys++?  And again, this is the on-prem case.  For cloud, we are well along.
>

[Joe] We are currently in a holding pattern with EAP-TLS.  It does not seem
right to delay it for functionality that we are not sure we have a use case
for.  If a use case develops then we can publish an update to EAP-TLS 1.3.
Do we have a use case for EAP-TLS-PSK that is blocked in the current
situation?



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

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

[Eliot Lear]

> On 11 Oct 2019, at 16:09, Michael Richardson  wrote:
> 
> So, can wired just be a degenerate version of wifi, where there can be only
> one "ESSID", and there are no beacons to consider?


On the whole that has been my thought.  But it is a matter of which mechanism 
to degenerate to.  Is it TLS-PSK?  eDPP++?  TLS with naked public keys++?  And 
again, this is the on-prem case.  For cloud, we are well along.

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Eliot Lear  wrote:
>> Eliot Lear  wrote:
>>> Before we nail this down, it seems like we need to have a discussion
>>> about how best to onboard wired IoT devices in particular from an
>>> on-prem view.  The issue here is that EAP-TLS-PSK is useful for that
>>> purpose, as we discussed.  Now there is nothing particularly special
>>> about PSK and we could run with a naked public key pair as well in
>>> 1.3, but we have to choose something.
>> 
>> okay, so why do you prefer PSK?

> I do not.  But we need to have *a* flow for on prem onboarding.
> TLS-PSK is one approach, but there are others.  I just want a
> discussion before we nail this down, as I wrote.

>> 
>>> The fundamental question is what does a manufacturer stamp into the
>>> device and what is placed on a label.  We have a running example of
>>> DPP doing this for wireless with public key code, but that doesn’t
>>> get us to proper onboarding for wired – the signaling just isn’t
>>> there.
>> 
>> I don't understand this.  Are you saying that because it's wired,
>> people do not expect to scan anything?

> No quite the opposite- I’m saying that there is at least one way to do
> this with Wifi, but no way to do this for wired right now, an we need
> one.

So, can wired just be a degenerate version of wifi, where there can be only
one "ESSID", and there are no beacons to consider?

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Eliot Lear]

> On 11 Oct 2019, at 13:04, Michael Richardson  wrote:
> 
> 
> Eliot Lear  wrote:
>> Before we nail this down, it seems like we need to have a discussion
>> about how best to onboard wired IoT devices in particular from an
>> on-prem view.  The issue here is that EAP-TLS-PSK is useful for that
>> purpose, as we discussed.  Now there is nothing particularly special
>> about PSK and we could run with a naked public key pair as well in 1.3,
>> but we have to choose something.
> 
> okay, so why do you prefer PSK?

I do not.  But we need to have *a* flow for on prem onboarding.  TLS-PSK is one 
approach, but there are others.  I just want a discussion before we nail this 
down, as I wrote.

> 
>> The fundamental question is what does
>> a manufacturer stamp into the device and what is placed on a label.  We
>> have a running example of DPP doing this for wireless with public key
>> code, but that doesn’t get us to proper onboarding for wired – the
>> signaling just isn’t there.
> 
> I don't understand this.
> Are you saying that because it's wired, people do not expect to scan
> anything?

No quite the opposite- I’m saying that there is at least one way to do this 
with Wifi, but no way to do this for wired right now, an we need one.

Eliot

> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 



signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Eliot Lear  wrote:
> Before we nail this down, it seems like we need to have a discussion
> about how best to onboard wired IoT devices in particular from an
> on-prem view.  The issue here is that EAP-TLS-PSK is useful for that
> purpose, as we discussed.  Now there is nothing particularly special
> about PSK and we could run with a naked public key pair as well in 1.3,
> but we have to choose something.

okay, so why do you prefer PSK?

> The fundamental question is what does
> a manufacturer stamp into the device and what is placed on a label.  We
> have a running example of DPP doing this for wireless with public key
> code, but that doesn’t get us to proper onboarding for wired – the
> signaling just isn’t there.

I don't understand this.
Are you saying that because it's wired, people do not expect to scan
anything?

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

I am aware that Openssl has support for external PSK. The Selfie attack 
was demonstrated using this Openssl implementation: 
https://eprint.iacr.org/2019/347

However, the github issue you posted is still helpful. If I understand 
the resolution of this issue: Openssl will first check for a valid 
external PSK before checking for resumption PSKs.

I think we can include EAP-TLS-PSK without major changes to the current 
document. I only want to ensure that EAP-TLS-PSK does not leave any 
implementation ambiguities.

--Mohit

On 10/10/19 7:18 PM, John Mattsson wrote:
> Mohit Sethi M mailto:mohit.m.se...@ericsson.com wrote:
>
>> Can you give an example of an existing TLS 1.3 deployment that offers both 
>> resumption PSKs and external PSKs?
> Don’t know if it is deployed anywhere, but OpenSSL supports resumption of PSK 
> sessions. There was a bug that stopped it from working that was patched 12 
> months ago.
> https://github.com/openssl/openssl/issues/7433
>
>
> ___
> 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

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

[John Mattsson]

Mohit Sethi M mailto:mohit.m.se...@ericsson.com wrote:

> Can you give an example of an existing TLS 1.3 deployment that offers both 
> resumption PSKs and external PSKs? 

Don’t know if it is deployed anywhere, but OpenSSL supports resumption of PSK 
sessions. There was a bug that stopped it from working that was patched 12 
months ago. 
https://github.com/openssl/openssl/issues/7433


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

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

[Mohit Sethi M]

Yes, but I do not see how EAP would differ from any other TLS deployment with 
external PSK.

Can you give an example of an existing TLS 1.3 deployment that offers both 
resumption PSKs and external PSKs?

EAP-TLS would not be different from other TLS deployments with external PSKs. 
However, so far EAP-TLS has only been used with certificates. If we are adding 
support for external PSKs, we should make sure that implementations know how to 
handle them.

--Mohit

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

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

[Mohit Sethi M]

Hi Elliot,

PSK and certificates have different security properties. That being said, both 
are needed.

As I stated earlier: a modern EAP method with PSK is needed and TLS-PSK is the 
right choice. I am happy to have it in the current 
draft-ietf-emu-eap-tls13<https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-07>
 draft if that is what the general consensus is.

--Mohit

On 10/10/19 12:24 PM, Eliot Lear wrote:
Hi Mohit,

On 10 Oct 2019, at 09:55, Mohit Sethi M 
mailto:mohit.m.se...@ericsson.com>> wrote:

@Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
clearl precedent. The original EAP-TLS specification in RFC 5216 
(https://tools.ietf.org/html/rfc5216) has no mention of PSKs.

*Architecturally* I am angling toward code impact.  Is there a fundamental 
issue with TLS-PSK or is it just EAP-TLS-PSK?  This is a matter of how one 
would want to address the problem in OpenSSL/GNUTLS/TinySSL/WolfSSL and what 
the calling interfaces should be.

I want to stress again: whether it’s PSK or public key is conceptually not that 
different here.  There is some potential theft protection in public key 
mechanisms, but only if a real TEE is used.  We’re not seeing that as much as 
we would like yet, but it may make sense to aim in that direction.

Thus one potential outcome of this discussion is: PSK is just bad, and never 
use it, regardless of EAP or other.  Another potential outcome is the opposite. 
 And then there are some states in between.

Eliot

--Mohit

On 10/10/19 10:44 AM, John Mattsson wrote:
Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. I 
strongly think we need an EAP method with PSK + PFS for IoT, and the easiest 
way to achieve that seems to be EAP-TLS-PSK.

Cheers,
John

From: Eliot Lear <mailto:l...@cisco.com>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <mailto:j...@salowey.net>
Cc: John Mattsson 
<mailto:john.mattsson=40ericsson@dmarc.ietf.org>,
 "draft-ietf-emu-eap-tl...@ietf.org"<mailto:draft-ietf-emu-eap-tl...@ietf.org> 
<mailto:draft-ietf-emu-eap-tl...@ietf.org>, 
EMU WG <mailto:emu@ietf.org>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <mailto:alias-boun...@ietf.org>
Resent to: John Mattsson 
<mailto:john.matts...@ericsson.com>, 
<mailto:mo...@piuha.net>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,


On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT devices in particular from an on-prem view.  The 
issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed.  
Now there is nothing particularly special about PSK and we could run with a 
naked public key pair as well in 1.3, but we have to choose something.  The 
fundamental question is what does a manufacturer stamp into the device and what 
is placed on a label.  We have a running example of DPP doing this for wireless 
with public key code, but that doesn’t get us to proper onboarding for wired – 
the signaling just isn’t there.

Also, maybe it’s me, but I remain uncomfortable about this group constraining 
TLS 1.3.

Eliot



Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi Alan,

I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
they are good to point out.

I am not sure about the other suggestions, I am hesitant to discuss anything 
detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or 
are useful for users of EAP-TLS. My feeling is that adding some extension, but 
not other would be even more confusing. The diagrams are there to show the 
message flows, which have a strong connection to the EAP state machine. For 
other details I think implementors have to read RFC 8466.

/John

-Original Message-
From: Alan DeKok mailto:al...@deployingradius.com>>
Date: Wednesday, 18 September 2019 at 15:21
To: 
"draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC 

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

[Owen Friel (ofriel)]

From: Emu  On Behalf Of John Mattsson
Sent: 10 October 2019 09:30
To: Mohit Sethi M ; Eliot Lear 
Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson 
; EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Mohit Sethi M mohit.m.se...@ericsson.com<mailto:mohit.m.se...@ericsson.com> 
wrote:

I think these are mostly TLS questions that would not be specific for 
EAP-TLS-PSK

> For example: the current TLS 1.3 spec requires external PSKs to be 
> provisioned for a specific hash function.

Yes, but if there is no specific hash function, SHA-256 is used as a default.

>Then there is also the discussion on how does a server handle external PSK vs. 
>PSK for resumption? They will clearly be >in different parts of the stack: 
>external PSKs with the EAP server and resumptions PSKs with the TLS server 
>library.
>Also, should a server issue resumption PSKs when the original authentication 
>is based on an external PSK. The only >benefit would be that it would make 
>tracking of peers/clients much harder.


[ofriel] I wouldn’t say that the only benefit is to make tracking of 
peers/clients harder. A server could use PSK for initial auth, and then issue 
local credentials for the thing within the EAP tunnel. The thing can now be let 
on the network immediately, and on subsequent reboots/reauths/reconnects can 
use its locally issued credential. In either scenario (initial bootstrap or 
subsequent reauth using the local credential), the server may issue resumption 
PSKs.


Yes, but I do not see how EAP would differ from any other TLS deployment with 
external PSK.


[ofriel] Agree. I do not see why EAP should place artificial constraints on 
TLS. I cannot see a good reason why an EAP-TLS implementation couldn’t be coded 
to have the same flexibility as any other TLS1.3 server. A particular EAP 
implementation could of course choose not to support authentication PSKs, but 
it seems a mistake to prohibit this in the specification.


>There is ongoing work in the TLS working group but the question is how long 
>should we wait: 
>https://tools.ietf.org/html/>draft-ietf-tls-external-psk-importer-01<https://tools.ietf.org/html/%3edraft-ietf-tls-external-psk-importer-01>

I see no reason to wait for that draft. What 
draft-ietf-tls-external-psk-importer does is to allow a single external PSK to 
be used to negotiate both TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. 
Most IoT would not want to negotiate AES-256 and SHA-384, and those who want 
(like e.g. US government devices using the CSNA suite) would probably not want 
to negotiate AES-128 and SHA-256. draft-ietf-tls-external-psk-importer fills a 
gap in the TLS 1.3 protocol, but is not a game changer in any way.

John

From: Mohit Sethi M 
mailto:mohit.m.se...@ericsson.com>>
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear mailto:l...@cisco.com>>, John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: 
"draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13


I wouldn't say that TLS 1.3 is wrong but there is some stuff that could benefit 
from further clarification. For example: the current TLS 1.3 spec requires 
external PSKs to be provisioned for a specific hash function. Then there is 
also the discussion on how does a server handle external PSK vs. PSK for 
resumption? They will clearly be in different parts of the stack: external PSKs 
with the EAP server and resumptions PSKs with the TLS server library. Also, 
should a server issue resumption PSKs when the original authentication is based 
on an external PSK. The only benefit would be that it would make tracking of 
peers/clients much harder.

There is ongoing work in the TLS working group but the question is how long 
should we wait: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01

--Mohit
On 10/10/19 10:51 AM, Eliot Lear wrote:
I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot



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

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

[Eliot Lear]

Hi Mohit,

> On 10 Oct 2019, at 09:55, Mohit Sethi M  wrote:
> @Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
> clearl precedent. The original EAP-TLS specification in RFC 5216 
> (https://tools.ietf.org/html/rfc5216 <https://tools.ietf.org/html/rfc5216>) 
> has no mention of PSKs.
> 

*Architecturally* I am angling toward code impact.  Is there a fundamental 
issue with TLS-PSK or is it just EAP-TLS-PSK?  This is a matter of how one 
would want to address the problem in OpenSSL/GNUTLS/TinySSL/WolfSSL and what 
the calling interfaces should be.

I want to stress again: whether it’s PSK or public key is conceptually not that 
different here.  There is some potential theft protection in public key 
mechanisms, but only if a real TEE is used.  We’re not seeing that as much as 
we would like yet, but it may make sense to aim in that direction.

Thus one potential outcome of this discussion is: PSK is just bad, and never 
use it, regardless of EAP or other.  Another potential outcome is the opposite. 
 And then there are some states in between.

Eliot
> --Mohit
> 
> On 10/10/19 10:44 AM, John Mattsson wrote:
>> Hi Eliot,
>> 
>> I agree that the question boils down to IoT. There are currently a lot of 
>> IoT systems using PSK, and many of them will likely want to stay on PSK, 
>> rather than migrating to RPK. Using a protocol with PFS is nowadays 
>> recommended practice. EAP-PSK does not provide PFS, and EAP-PWD is not 
>> suitable for IoT. I strongly think we need an EAP method with PSK + PFS for 
>> IoT, and the easiest way to achieve that seems to be EAP-TLS-PSK.
>> 
>> Cheers,
>> John
>> 
>> From: Eliot Lear  <mailto:l...@cisco.com>
>> Date: Thursday, 10 October 2019 at 09:14
>> To: Joseph Salowey  <mailto:j...@salowey.net>
>> Cc: John Mattsson  
>> <mailto:john.mattsson=40ericsson@dmarc.ietf.org>, 
>> "draft-ietf-emu-eap-tl...@ietf.org" 
>> <mailto:draft-ietf-emu-eap-tl...@ietf.org> 
>>  
>> <mailto:draft-ietf-emu-eap-tl...@ietf.org>, EMU WG  
>> <mailto:emu@ietf.org>
>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>> Resent from:  <mailto:alias-boun...@ietf.org>
>> Resent to: John Mattsson  
>> <mailto:john.matts...@ericsson.com>,  
>> <mailto:mo...@piuha.net>
>> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)
>> 
>> Hi Joe,
>> 
>> 
>> On 7 Oct 2019, at 02:42, Joseph Salowey > <mailto:j...@salowey.net>> wrote:
>> 
>> There is a TLS working group draft on importing external PSKs for use with 
>> TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 
>> <https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01>.  This 
>> draft can mitigate some of the issues with using external PSKs.
>> 
>> My suggesting is to leave the draft as is and deal with external PSKs as an 
>> update to EAP-TLS 1.3 or as a separate method.
>> 
>> 
>> Before we nail this down, it seems like we need to have a discussion about 
>> how best to onboard wired IoT devices in particular from an on-prem view.  
>> The issue here is that EAP-TLS-PSK is useful for that purpose, as we 
>> discussed.  Now there is nothing particularly special about PSK and we could 
>> run with a naked public key pair as well in 1.3, but we have to choose 
>> something.  The fundamental question is what does a manufacturer stamp into 
>> the device and what is placed on a label.  We have a running example of DPP 
>> doing this for wireless with public key code, but that doesn’t get us to 
>> proper onboarding for wired – the signaling just isn’t there.
>> 
>> Also, maybe it’s me, but I remain uncomfortable about this group 
>> constraining TLS 1.3.
>> 
>> Eliot
>> 
>> 
>> 
>> Is the current published version up to date with the rest of the comments?
>> 
>> Thanks,
>> 
>> Joe
>> 
>> On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
>> > <mailto:40ericsson@dmarc.ietf.org>> wrote:
>> Hi Alan,
>> 
>> I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
>> they are good to point out.
>> 
>> I am not sure about the other suggestions, I am hesitant to discuss anything 
>> detailed about TLS 1.3 that does not have a specific connection to EAP-TLS 
>> or are useful for users of EAP-TLS. My feeling is that adding some 
>> extension, but not other would be even more confusing. The diagrams are 
>> there to show the message flows, which have a strong connection t

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

[John Mattsson]

Mohit Sethi M mohit.m.se...@ericsson.com wrote:

I think these are mostly TLS questions that would not be specific for 
EAP-TLS-PSK

> For example: the current TLS 1.3 spec requires external PSKs to be 
> provisioned for a specific hash function.

Yes, but if there is no specific hash function, SHA-256 is used as a default.

>Then there is also the discussion on how does a server handle external PSK vs. 
>PSK for resumption? They will clearly be >in different parts of the stack: 
>external PSKs with the EAP server and resumptions PSKs with the TLS server 
>library.
>Also, should a server issue resumption PSKs when the original authentication 
>is based on an external PSK. The only >benefit would be that it would make 
>tracking of peers/clients much harder.

Yes, but I do not see how EAP would differ from any other TLS deployment with 
external PSK.

>There is ongoing work in the TLS working group but the question is how long 
>should we wait: 
>https://tools.ietf.org/html/>draft-ietf-tls-external-psk-importer-01

I see no reason to wait for that draft. What 
draft-ietf-tls-external-psk-importer does is to allow a single external PSK to 
be used to negotiate both TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. 
Most IoT would not want to negotiate AES-256 and SHA-384, and those who want 
(like e.g. US government devices using the CSNA suite) would probably not want 
to negotiate AES-128 and SHA-256. draft-ietf-tls-external-psk-importer fills a 
gap in the TLS 1.3 protocol, but is not a game changer in any way.

John

From: Mohit Sethi M 
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear , John Mattsson 
Cc: "draft-ietf-emu-eap-tl...@ietf.org" , 
John Mattsson , EMU WG 

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


I wouldn't say that TLS 1.3 is wrong but there is some stuff that could benefit 
from further clarification. For example: the current TLS 1.3 spec requires 
external PSKs to be provisioned for a specific hash function. Then there is 
also the discussion on how does a server handle external PSK vs. PSK for 
resumption? They will clearly be in different parts of the stack: external PSKs 
with the EAP server and resumptions PSKs with the TLS server library. Also, 
should a server issue resumption PSKs when the original authentication is based 
on an external PSK. The only benefit would be that it would make tracking of 
peers/clients much harder.

There is ongoing work in the TLS working group but the question is how long 
should we wait: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01

--Mohit
On 10/10/19 10:51 AM, Eliot Lear wrote:
I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot


On 10 Oct 2019, at 09:44, John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:

Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. I 
strongly think we need an EAP method with PSK + PFS for IoT, and the easiest 
way to achieve that seems to be EAP-TLS-PSK.

Cheers,
John

From: Eliot Lear mailto:l...@cisco.com>>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 "draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.net>>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,



On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT 

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

[John Mattsson]

Mohit Sethi M mohit.m.se...@ericsson.com wrote:

> @Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
> clearl precedent. The original EAP-TLS specification in RFC 5216 
> (https://tools.ietf.org/html/rfc5216) has no mention of PSKs.

That was quite different. When EAP-TLS (RFC 2716) was first published, there 
was no PSK mode in TLS at all. When RFC 5216 was published, TLS-PSK was a quite 
recent and not so well-supported extension. Also TLS 1.2 (RFC 5246) has no 
mention of PSKs. TLS 1.3 embraces PSK because the demand from IoT and makes it 
part of the main specification.

From: Mohit Sethi M 
Date: Thursday, 10 October 2019 at 09:55
To: John Mattsson , Eliot Lear , 
Joseph Salowey 
Cc: John Mattsson , 
"draft-ietf-emu-eap-tl...@ietf.org" , EMU WG 

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


Hi,

Speaking purely as an individual contributor. I agree that this is a use-case 
we should address. I am open to discussions whether it should be done in this 
draft or separately and whether we should have a separate method type or use 
the same.

@Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
clearl precedent. The original EAP-TLS specification in RFC 5216 
(https://tools.ietf.org/html/rfc5216) has no mention of PSKs.

--Mohit
On 10/10/19 10:44 AM, John Mattsson wrote:
Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. I 
strongly think we need an EAP method with PSK + PFS for IoT, and the easiest 
way to achieve that seems to be EAP-TLS-PSK.

Cheers,
John

From: Eliot Lear <mailto:l...@cisco.com>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <mailto:j...@salowey.net>
Cc: John Mattsson 
<mailto:john.mattsson=40ericsson@dmarc.ietf.org>,
 "draft-ietf-emu-eap-tl...@ietf.org"<mailto:draft-ietf-emu-eap-tl...@ietf.org> 
<mailto:draft-ietf-emu-eap-tl...@ietf.org>, 
EMU WG <mailto:emu@ietf.org>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <mailto:alias-boun...@ietf.org>
Resent to: John Mattsson 
<mailto:john.matts...@ericsson.com>, 
<mailto:mo...@piuha.net>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,



On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT devices in particular from an on-prem view.  The 
issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed.  
Now there is nothing particularly special about PSK and we could run with a 
naked public key pair as well in 1.3, but we have to choose something.  The 
fundamental question is what does a manufacturer stamp into the device and what 
is placed on a label.  We have a running example of DPP doing this for wireless 
with public key code, but that doesn’t get us to proper onboarding for wired – 
the signaling just isn’t there.

Also, maybe it’s me, but I remain uncomfortable about this group constraining 
TLS 1.3.

Eliot




Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi Alan,

I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
they are good to point out.

I am not sure about the other suggestions, I am hesitant to discuss anything 
detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or 
are useful for users of EAP-TLS. My feeling is that adding some extension, but 
not other would be even more confusing. The diagrams are there to show the 
message flows, which have a strong connection to the EAP state machine. For 
other details I think implementors have to read RFC 8466.

/John

-Original Message-
From: Alan DeKok mailto:al...@deployingradius.com>>
Date: Wednesday, 18 September 2019 at 15:21
To: 
"draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.n

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

[Mohit Sethi M]

I wouldn't say that TLS 1.3 is wrong but there is some stuff that could benefit 
from further clarification. For example: the current TLS 1.3 spec requires 
external PSKs to be provisioned for a specific hash function. Then there is 
also the discussion on how does a server handle external PSK vs. PSK for 
resumption? They will clearly be in different parts of the stack: external PSKs 
with the EAP server and resumptions PSKs with the TLS server library. Also, 
should a server issue resumption PSKs when the original authentication is based 
on an external PSK. The only benefit would be that it would make tracking of 
peers/clients much harder.

There is ongoing work in the TLS working group but the question is how long 
should we wait: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01

--Mohit

On 10/10/19 10:51 AM, Eliot Lear wrote:
I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot

On 10 Oct 2019, at 09:44, John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:

Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. I 
strongly think we need an EAP method with PSK + PFS for IoT, and the easiest 
way to achieve that seems to be EAP-TLS-PSK.

Cheers,
John

From: Eliot Lear mailto:l...@cisco.com>>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 "draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.net>>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,


On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT devices in particular from an on-prem view.  The 
issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed.  
Now there is nothing particularly special about PSK and we could run with a 
naked public key pair as well in 1.3, but we have to choose something.  The 
fundamental question is what does a manufacturer stamp into the device and what 
is placed on a label.  We have a running example of DPP doing this for wireless 
with public key code, but that doesn’t get us to proper onboarding for wired – 
the signaling just isn’t there.

Also, maybe it’s me, but I remain uncomfortable about this group constraining 
TLS 1.3.

Eliot



Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi Alan,

I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
they are good to point out.

I am not sure about the other suggestions, I am hesitant to discuss anything 
detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or 
are useful for users of EAP-TLS. My feeling is that adding some extension, but 
not other would be even more confusing. The diagrams are there to show the 
message flows, which have a strong connection to the EAP state machine. For 
other details I think implementors have to read RFC 8466.

/John

-Original Message-
From: Alan DeKok mailto:al...@deployingradius.com>>
Date: Wednesday, 18 September 2019 at 15:21
To: 
"draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.o

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

[Mohit Sethi M]

Hi,

Speaking purely as an individual contributor. I agree that this is a use-case 
we should address. I am open to discussions whether it should be done in this 
draft or separately and whether we should have a separate method type or use 
the same.

@Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
clearl precedent. The original EAP-TLS specification in RFC 5216 
(https://tools.ietf.org/html/rfc5216) has no mention of PSKs.

--Mohit

On 10/10/19 10:44 AM, John Mattsson wrote:
Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. I 
strongly think we need an EAP method with PSK + PFS for IoT, and the easiest 
way to achieve that seems to be EAP-TLS-PSK.

Cheers,
John

From: Eliot Lear <mailto:l...@cisco.com>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <mailto:j...@salowey.net>
Cc: John Mattsson 
<mailto:john.mattsson=40ericsson@dmarc.ietf.org>,
 "draft-ietf-emu-eap-tl...@ietf.org"<mailto:draft-ietf-emu-eap-tl...@ietf.org> 
<mailto:draft-ietf-emu-eap-tl...@ietf.org>, 
EMU WG <mailto:emu@ietf.org>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <mailto:alias-boun...@ietf.org>
Resent to: John Mattsson 
<mailto:john.matts...@ericsson.com>, 
<mailto:mo...@piuha.net>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,


On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT devices in particular from an on-prem view.  The 
issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed.  
Now there is nothing particularly special about PSK and we could run with a 
naked public key pair as well in 1.3, but we have to choose something.  The 
fundamental question is what does a manufacturer stamp into the device and what 
is placed on a label.  We have a running example of DPP doing this for wireless 
with public key code, but that doesn’t get us to proper onboarding for wired – 
the signaling just isn’t there.

Also, maybe it’s me, but I remain uncomfortable about this group constraining 
TLS 1.3.

Eliot



Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi Alan,

I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
they are good to point out.

I am not sure about the other suggestions, I am hesitant to discuss anything 
detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or 
are useful for users of EAP-TLS. My feeling is that adding some extension, but 
not other would be even more confusing. The diagrams are there to show the 
message flows, which have a strong connection to the EAP state machine. For 
other details I think implementors have to read RFC 8466.

/John

-Original Message-
From: Alan DeKok mailto:al...@deployingradius.com>>
Date: Wednesday, 18 September 2019 at 15:21
To: 
"draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.net>>
Resent date: Wednesday, 18 September 2019 at 15:21

  Just re-reading the text on PSK, I noticed a few things.  The text in 
Section 2.1.2 talks about PSK, the session ticket, and a "key_share" extension. 
  The accompanying diagram doesn't include any of those.  I suggest updating 
the diagram to include them.

  As a related note, if the PSK *is* in the resumption cache, but the key 
is wrong, the cache entry should not be discarded.  Otherwise an attacker can 
disable caching for *all* users.  This issue could be clearer in this document.

  Perhaps it would be useful to add a short note in Section 5 about 
security of resumption.  It should reference RFC 8446 Section 8.1, and 8.2, 
which discuss this issue.  Also, Section 4.2.11 of that document has an 
"Implementor's note:" which is important.

  Alan De

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

[Eliot Lear]

I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot

> On 10 Oct 2019, at 09:44, John Mattsson  wrote:
> 
> Hi Eliot,
> 
> I agree that the question boils down to IoT. There are currently a lot of IoT 
> systems using PSK, and many of them will likely want to stay on PSK, rather 
> than migrating to RPK. Using a protocol with PFS is nowadays recommended 
> practice. EAP-PSK does not provide PFS, and EAP-PWD is not suitable for IoT. 
> I strongly think we need an EAP method with PSK + PFS for IoT, and the 
> easiest way to achieve that seems to be EAP-TLS-PSK.
> 
> Cheers,
> John
> 
> From: Eliot Lear mailto:l...@cisco.com>>
> Date: Thursday, 10 October 2019 at 09:14
> To: Joseph Salowey mailto:j...@salowey.net>>
> Cc: John Mattsson  <mailto:john.mattsson=40ericsson@dmarc.ietf.org>>, 
> "draft-ietf-emu-eap-tl...@ietf.org 
> <mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
>  <mailto:draft-ietf-emu-eap-tl...@ietf.org>>, EMU WG  <mailto:emu@ietf.org>>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: mailto:alias-boun...@ietf.org>>
> Resent to: John Mattsson  <mailto:john.matts...@ericsson.com>>,  <mailto:mo...@piuha.net>>
> Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)
> 
> Hi Joe,
> 
> 
>> On 7 Oct 2019, at 02:42, Joseph Salowey > <mailto:j...@salowey.net>> wrote:
>> 
>> There is a TLS working group draft on importing external PSKs for use with 
>> TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 
>> <https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01>.  This 
>> draft can mitigate some of the issues with using external PSKs.
>> 
>> My suggesting is to leave the draft as is and deal with external PSKs as an 
>> update to EAP-TLS 1.3 or as a separate method.
> 
> 
> Before we nail this down, it seems like we need to have a discussion about 
> how best to onboard wired IoT devices in particular from an on-prem view.  
> The issue here is that EAP-TLS-PSK is useful for that purpose, as we 
> discussed.  Now there is nothing particularly special about PSK and we could 
> run with a naked public key pair as well in 1.3, but we have to choose 
> something.  The fundamental question is what does a manufacturer stamp into 
> the device and what is placed on a label.  We have a running example of DPP 
> doing this for wireless with public key code, but that doesn’t get us to 
> proper onboarding for wired – the signaling just isn’t there.
> 
> Also, maybe it’s me, but I remain uncomfortable about this group constraining 
> TLS 1.3.
> 
> Eliot
> 
> 
>> 
>> Is the current published version up to date with the rest of the comments?
>> 
>> Thanks,
>> 
>> Joe
>> 
>> On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
>> > <mailto:40ericsson@dmarc.ietf.org>> wrote:
>>> Hi Alan,
>>> 
>>> I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
>>> they are good to point out.
>>> 
>>> I am not sure about the other suggestions, I am hesitant to discuss 
>>> anything detailed about TLS 1.3 that does not have a specific connection to 
>>> EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some 
>>> extension, but not other would be even more confusing. The diagrams are 
>>> there to show the message flows, which have a strong connection to the EAP 
>>> state machine. For other details I think implementors have to read RFC 8466.
>>> 
>>> /John
>>> 
>>> -Original Message-
>>> From: Alan DeKok >> <mailto:al...@deployingradius.com>>
>>> Date: Wednesday, 18 September 2019 at 15:21
>>> To: "draft-ietf-emu-eap-tl...@ietf.org 
>>> <mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
>>> >> <mailto:draft-ietf-emu-eap-tl...@ietf.org>>, EMU WG >> <mailto:emu@ietf.org>>
>>> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
>>> Resent from: mailto:alias-boun...@ietf.org>>
>>> Resent to: John Mattsson >> <ma

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

[Alan DeKok]

On Oct 7, 2019, at 10:55 AM, Eliot Lear  wrote:
> 
> If we evolve draft-lear-eap-teap-brski into a more generic TEAP update we 
> could cover TLS 1.3 there.

  Given Jouni's experience with implementing TEAP, that may be best.

  i.e. TEAP cannot be implemented as-is.  The spec needs to be updated so that 
we can create inter-operable versions.

  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

[Eliot Lear]

> On 7 Oct 2019, at 15:10, Alan DeKok  wrote:
> 
> On Oct 7, 2019, at 2:32 AM, John Mattsson 
>  wrote:
>> 
>> Joseph Salowey  wrote:
>> 
>>> Is the current published version up to date with the rest of the comments?
>> 
>> Yes, to my knowledge, the current draft handles all the other comments. If 
>> we decide to leave EAP-TLS PSK discussions for another draft, I think 
>> draft-ietf-emu-eap-tls13-07 is ready to move forward in the publication 
>> process.
> 
>  I agree.
> 
>  My one worry is that if we update EAP-TLS without also updating PEAP and 
> TTLS, then bad things will happen.
> 
>  My $0.02 is to remove the discussion of FAST and TEAP from 
> draft-dekok-emu-tls-eap-types, as the remaining items are not controversial.  
> The document should then be published simultaneously with the EAP-TLS updates.


If we evolve draft-lear-eap-teap-brski into a more generic TEAP update we could 
cover TLS 1.3 there.

Eliot



signature.asc
Description: Message signed with OpenPGP
___
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 Oct 7, 2019, at 2:32 AM, John Mattsson 
 wrote:
> 
> Joseph Salowey  wrote:
> 
>> Is the current published version up to date with the rest of the comments?
> 
> Yes, to my knowledge, the current draft handles all the other comments. If we 
> decide to leave EAP-TLS PSK discussions for another draft, I think 
> draft-ietf-emu-eap-tls13-07 is ready to move forward in the publication 
> process.

  I agree.

  My one worry is that if we update EAP-TLS without also updating PEAP and 
TTLS, then bad things will happen.

  My $0.02 is to remove the discussion of FAST and TEAP from 
draft-dekok-emu-tls-eap-types, as the remaining items are not controversial.  
The document should then be published simultaneously with the EAP-TLS updates.

  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

[John Mattsson]

Joseph Salowey  wrote:

> Is the current published version up to date with the rest of the comments?

Yes, to my knowledge, the current draft handles all the other comments. If we 
decide to leave EAP-TLS PSK discussions for another draft, I think 
draft-ietf-emu-eap-tls13-07 is ready to move forward in the publication process.

Cheers,
John

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

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

[Joseph Salowey]

There is a TLS working group draft on importing external PSKs for use with
TLS - https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.
This draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an
update to EAP-TLS 1.3 or as a separate method.

Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson  wrote:

> Hi Alan,
>
> I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree
> that they are good to point out.
>
> I am not sure about the other suggestions, I am hesitant to discuss
> anything detailed about TLS 1.3 that does not have a specific connection to
> EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some
> extension, but not other would be even more confusing. The diagrams are
> there to show the message flows, which have a strong connection to the EAP
> state machine. For other details I think implementors have to read RFC 8466.
>
> /John
>
> -Original Message-
> From: Alan DeKok 
> Date: Wednesday, 18 September 2019 at 15:21
> To: "draft-ietf-emu-eap-tl...@ietf.org" ,
> EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> Resent from: 
> Resent to: John Mattsson , 
> Resent date: Wednesday, 18 September 2019 at 15:21
>
>   Just re-reading the text on PSK, I noticed a few things.  The text
> in Section 2.1.2 talks about PSK, the session ticket, and a "key_share"
> extension.   The accompanying diagram doesn't include any of those.  I
> suggest updating the diagram to include them.
>
>   As a related note, if the PSK *is* in the resumption cache, but the
> key is wrong, the cache entry should not be discarded.  Otherwise an
> attacker can disable caching for *all* users.  This issue could be clearer
> in this document.
>
>   Perhaps it would be useful to add a short note in Section 5 about
> security of resumption.  It should reference RFC 8446 Section 8.1, and 8.2,
> which discuss this issue.  Also, Section 4.2.11 of that document has an
> "Implementor's note:" which is important.
>
>   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

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

[Alan DeKok]

On Sep 19, 2019, at 2:27 AM, Jim Schaad  wrote:
> 
> I am going to come down on the side of no PSK should not be supported.
> However my issues have nothing to do with how things are implemented and
> more to do with the security properties of the EAP method.

  I'm leaning that way myself.  I'm not opposed in principle, but it looks like 
other options have better properties.

> When you use certificates, there is no leakage of who the client is as this
> is encrypted by TLS.  When you use a restore session ticket, it is possible
> to limit the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  If
> one is using PSK for the purpose of authentication then that value will
> always be visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK,
> but you are going to send that PSK identifier over the wire many times.

  i.e. the only secure way to use PSK is one-time authentication, as per Owen's 
IoT use-case.

  If we do allow it, there's just no question that people will abuse it.  That 
for me is a strong reason to forbid it.

  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 Sep 19, 2019, at 6:04 AM, John Mattsson  wrote:
> 
> I am starting to come down on the side the EAP-TLS PSK should be specified.
> 
> - I think EAP-PSK should be phased out like all other methods not giving PFS.

  EAP-TLS using PSK has worse security properties than EAP-PSK, I think.

> - The security of the Dragonfly handshake used in EAP-PWD (and WPA3) seems 
> quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked into 
> the details.

  Yes.  There are updates coming.

  EAP-PWD is widely deployed and is widely used.  Given it's simplicity, I 
recommend using it where simple name / password authentication is required.

> - An EAP password method for the future should likely use the PAKE that CFRG 
> will soon standardize.
> - EAP methods should in the future support some PQC key exchange.
> 
> TLS will very likely get support for both the CFRG PAKE and PQC key exchange 
> algorithms. I am not sure the EAP group want to spend time updating either 
> EAP-PSK or ESP-PWD. Unless there are other benefits with EAP-PSK or EAP-PWD, 
> I think standardizing EAP-TLS PSK makes a lot of sense.

  It's not clear to me how EAP-TLS PSK is *better* than EAP-PWD.

> I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless 
> IETF thinks PSK and passwords should not be used (which does certainly not 
> seem to be the case as TLS 1.3 is including PSK and CFRG is standardizing 
> password based AKE) I think that EMU should make some PSK and password based 
> method Standards Track. At the moment EAP-TLS 1.3 looks like the best choice.

  PEAP is informational.  EAP-TTLS is informational.  Yet both are widely used. 
 The document status is largely a byproduct of the IETF process.  I think we 
should take into account what people *do* with EAP methods.

  In this case, people have voted with their feet.  EAP-PWD, PEAP, and EAP-TTLS 
are widely deployed.  They all support some form of name / password 
authentication.  PEAP and EAP-TTLS also include support for anonymous outer 
identities, which is impossible with EAP-TLS PSK.

  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: John Mattsson 
> Sent: 19 September 2019 11:04
> To: Owen Friel (ofriel) ; Jim Schaad
> ; 'Alan DeKok' 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> I am starting to come down on the side the EAP-TLS PSK should be specified.
> 
> - I think EAP-PSK should be phased out like all other methods not giving PFS.
> - The security of the Dragonfly handshake used in EAP-PWD (and WPA3)
> seems quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked
> into the details.
> 
> - An EAP password method for the future should likely use the PAKE that
> CFRG will soon standardize.
> - EAP methods should in the future support some PQC key exchange.
> 
> TLS will very likely get support for both the CFRG PAKE and PQC key
> exchange algorithms. I am not sure the EAP group want to spend time
> updating either EAP-PSK or ESP-PWD. Unless there are other benefits with
> EAP-PSK or EAP-PWD, I think standardizing EAP-TLS PSK makes a lot of sense.

Right, we have already started a couple of drafts along these lines, but are in 
a holding pattern now until CFRG are done:

https://tools.ietf.org/html/draft-barnes-tls-pake-04
https://tools.ietf.org/html/draft-sullivan-tls-opaque-00


> 
> I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless
> IETF thinks PSK and passwords should not be used (which does certainly not
> seem to be the case as TLS 1.3 is including PSK and CFRG is standardizing
> password based AKE) I think that EMU should make some PSK and password
> based method Standards Track. At the moment EAP-TLS 1.3 looks like the
> best choice.
> 

Additionally, we have had early discussions about updating TEAP RFC7170 to 
explicitly handle TLS 1.3, these updates could possibly be incorporated into 
https://tools.ietf.org/html/draft-lear-eap-teap-brski-04 , which is more and 
more looking like a general TEAP extensions / update draft, not a BRSKI 
specific draft.

And FYI, some movement has been made on TEAP with experimental support added to 
wpa_supplicant https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog 


> Jim wrote:
> > and more to do with the security properties of the EAP method.
> 
> If that is seen as a problem, standardizing a separate Type-Code for EAP-TLS
> with PSK authentication would solve the problem.
> 
> /John
> 
> -Original Message-
> From: "Owen Friel (ofriel)" 
> Date: Thursday, 19 September 2019 at 11:17
> To: Jim Schaad , 'Alan DeKok'
> 
> Cc: "draft-ietf-emu-eap-tl...@ietf.org"  tl...@ietf.org>, 'EMU WG' 
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent
> from:  Resent to: John Mattsson
> ,  Resent date:
> Thursday, 19 September 2019 at 11:17
> 
> 
> 
> > -Original Message-
> > From: Jim Schaad 
> > Sent: 19 September 2019 07:28
> > To: 'Alan DeKok' ; Owen Friel (ofriel)
> > 
> > Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> > Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> > I am going to come down on the side of no PSK should not be supported.
> > However my issues have nothing to do with how things are implemented
> > and more to do with the security properties of the EAP method.
> >
> > When you use certificates, there is no leakage of who the client is as 
> this
> is
> > encrypted by TLS.  When you use a restore session ticket, it is 
> possible to
> limit
> > the number of times that the ticket can be used (for example once).
> > The PSK identity is public and unprotected so it can be used to track.  
> If
> one is
> > using PSK for the purpose of authentication then that value will always 
> be
> > visible to intermediate parties for the purpose of tracking.
> > This can be slightly mitigated by using restore session tickets with 
> PSK,
> but
> > you are going to send that PSK identifier over the wire many times.
> 
> The IoT use case is to use the PSK one time for authentication during
> bootstrapping, then get credentialed, and thereafter use a certificate for
> subsequent EAP authentications. The bootstrap PSK enables proof of
> possession i.e. the thing will only bootstrap against a network that knows its
> PSK.
> 
> >
> >
> > This is just informational and can be ignored:
> >
> > My current favorite way to deal with PSK/ticket identifiers is with
> > encryption:
> >
> > 32 bytes of index into table
> > 32 bytes of date information
> > 32 bytes o

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

[John Mattsson]

I am starting to come down on the side the EAP-TLS PSK should be specified.

- I think EAP-PSK should be phased out like all other methods not giving PFS.
- The security of the Dragonfly handshake used in EAP-PWD (and WPA3) seems 
quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked into 
the details.

- An EAP password method for the future should likely use the PAKE that CFRG 
will soon standardize.
- EAP methods should in the future support some PQC key exchange.

TLS will very likely get support for both the CFRG PAKE and PQC key exchange 
algorithms. I am not sure the EAP group want to spend time updating either 
EAP-PSK or ESP-PWD. Unless there are other benefits with EAP-PSK or EAP-PWD, I 
think standardizing EAP-TLS PSK makes a lot of sense.

I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless IETF 
thinks PSK and passwords should not be used (which does certainly not seem to 
be the case as TLS 1.3 is including PSK and CFRG is standardizing password 
based AKE) I think that EMU should make some PSK and password based method 
Standards Track. At the moment EAP-TLS 1.3 looks like the best choice.

Jim wrote:
> and more to do with the security properties of the EAP method.

If that is seen as a problem, standardizing a separate Type-Code for EAP-TLS 
with PSK authentication would solve the problem.

/John

-Original Message-
From: "Owen Friel (ofriel)" 
Date: Thursday, 19 September 2019 at 11:17
To: Jim Schaad , 'Alan DeKok' 

Cc: "draft-ietf-emu-eap-tl...@ietf.org" , 
'EMU WG' 
Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: 
Resent to: John Mattsson , 
Resent date: Thursday, 19 September 2019 at 11:17



> -Original Message-
> From: Jim Schaad 
> Sent: 19 September 2019 07:28
> To: 'Alan DeKok' ; Owen Friel (ofriel)
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
    > Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> I am going to come down on the side of no PSK should not be supported.
> However my issues have nothing to do with how things are implemented
> and more to do with the security properties of the EAP method.
> 
> When you use certificates, there is no leakage of who the client is as 
this is
> encrypted by TLS.  When you use a restore session ticket, it is possible 
to limit
> the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  
If one is
> using PSK for the purpose of authentication then that value will always be
> visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK, 
but
> you are going to send that PSK identifier over the wire many times.

The IoT use case is to use the PSK one time for authentication during 
bootstrapping, then get credentialed, and thereafter use a certificate for 
subsequent EAP authentications. The bootstrap PSK enables proof of possession 
i.e. the thing will only bootstrap against a network that knows its PSK.

> 
> 
> This is just informational and can be ignored:
> 
> My current favorite way to deal with PSK/ticket identifiers is with
> encryption:
> 
> 32 bytes of index into table
> 32 bytes of date information
> 32 bytes of SIV (synthetic IV)
> 
> Encrypt the first two items using the SIV.  You can then have multiple 
keys for
> decryption.  One for PSKs and a resolving one for session tickets.  If the
> identifier does not decrypt then you reject.  Otherwise you look at the 
date
> information and the index in the table for the secret information.
> 
> It is even possible to play games with AAD to do things like scope the 
tickets
> up front - if you put in the name/address of the NAS then you have a
> prescreen on where the ticket can be used.
> 
> Jim
> 
> 
> 
> 
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Wednesday, September 18, 2019 2:59 PM
> To: Owen Friel (ofriel) 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> > Giving some implementation guidance seems appropriate here. Naively,
> > one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no 
match is
> found then check the NewSessionTickets tab

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

[Owen Friel (ofriel)]

> -Original Message-
> From: Jim Schaad 
> Sent: 19 September 2019 07:28
> To: 'Alan DeKok' ; Owen Friel (ofriel)
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> I am going to come down on the side of no PSK should not be supported.
> However my issues have nothing to do with how things are implemented
> and more to do with the security properties of the EAP method.
> 
> When you use certificates, there is no leakage of who the client is as this is
> encrypted by TLS.  When you use a restore session ticket, it is possible to 
> limit
> the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  If 
> one is
> using PSK for the purpose of authentication then that value will always be
> visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK, but
> you are going to send that PSK identifier over the wire many times.

The IoT use case is to use the PSK one time for authentication during 
bootstrapping, then get credentialed, and thereafter use a certificate for 
subsequent EAP authentications. The bootstrap PSK enables proof of possession 
i.e. the thing will only bootstrap against a network that knows its PSK.

> 
> 
> This is just informational and can be ignored:
> 
> My current favorite way to deal with PSK/ticket identifiers is with
> encryption:
> 
> 32 bytes of index into table
> 32 bytes of date information
> 32 bytes of SIV (synthetic IV)
> 
> Encrypt the first two items using the SIV.  You can then have multiple keys 
> for
> decryption.  One for PSKs and a resolving one for session tickets.  If the
> identifier does not decrypt then you reject.  Otherwise you look at the date
> information and the index in the table for the secret information.
> 
> It is even possible to play games with AAD to do things like scope the tickets
> up front - if you put in the name/address of the NAS then you have a
> prescreen on where the ticket can be used.
> 
> Jim
> 
> 
> 
> 
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Wednesday, September 18, 2019 2:59 PM
> To: Owen Friel (ofriel) 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> > Giving some implementation guidance seems appropriate here. Naively,
> > one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no match is
> found then check the NewSessionTickets table.
> 
>   Which works, but should be called out in the draft.
> 
>   And what is to prevent the system from generating conflicting PSK
> identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3 
> resumption
> means that OpenSSLL will choose whatever PSK identity it deems fit.
> 
>   As an implementor and/or admin, how do I choose *pre-provisioned* PSK
> identities which won't conflict with the ones OpenSSL choose?
> 
> > The default OpenSSL NSK ticketId is 32 bytes long
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86a
> d1fa4c
> 8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if
> there is a clash (poor randoms, etc.).
> 
>   i.e. "pick a long string and that should be good enough".
> 
>   If that really is the guidance, then this should also be called out in the 
> draft.
> PSK identities MUST be long (ideally 32 octets or more), and MUST be
> generated from a CSPRNG.
> 
>   Which then leads to the question of what will the poor user enter in a UI?
> If "end users" shouldn't be doing this, the draft also needs to call that out.
> 
> > Well, more precisely, the PSK identity is visible in the ClientHello,
> > not
> the actual PSK of course.
> 
>   Sure.
> 
> > And the PSK *must not* be a user-manageable string such as the
> >> NAI.  On the other hand, if the PSK is sent after encryption begins,
> >> then the PSK *should* be a user-manageable string such as an NAI.
> >
> > https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> > ...
> > so TLS-PSK is not suitable for a user entered low entropy password. We
> > need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)
> 
>   Sure.
> 
> > There are some use cases Eliot and I are looking at related to IoT
> onboarding where a TLS-PSK 

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

[Jim Schaad]

I am going to come down on the side of no PSK should not be supported.
However my issues have nothing to do with how things are implemented and
more to do with the security properties of the EAP method.

When you use certificates, there is no leakage of who the client is as this
is encrypted by TLS.  When you use a restore session ticket, it is possible
to limit the number of times that the ticket can be used (for example once).
The PSK identity is public and unprotected so it can be used to track.  If
one is using PSK for the purpose of authentication then that value will
always be visible to intermediate parties for the purpose of tracking.
This can be slightly mitigated by using restore session tickets with PSK,
but you are going to send that PSK identifier over the wire many times.


This is just informational and can be ignored:

My current favorite way to deal with PSK/ticket identifiers is with
encryption:

32 bytes of index into table
32 bytes of date information
32 bytes of SIV (synthetic IV)

Encrypt the first two items using the SIV.  You can then have multiple keys
for decryption.  One for PSKs and a resolving one for session tickets.  If
the identifier does not decrypt then you reject.  Otherwise you look at the
date information and the index in the table for the secret information.  

It is even possible to play games with AAD to do things like scope the
tickets up front - if you put in the name/address of the NAS then you have a
prescreen on where the ticket can be used.

Jim




-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Wednesday, September 18, 2019 2:59 PM
To: Owen Friel (ofriel) 
Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> Giving some implementation guidance seems appropriate here. Naively, one
could envisage the implementation simply having a DB table for extern PSKs
and a table that holds NewSessionTickets. An implementation could simply
check the extern PSK table using the PskIdentity.identity, and if no match
is found then check the NewSessionTickets table.

  Which works, but should be called out in the draft.

  And what is to prevent the system from generating conflicting PSK
identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3
resumption means that OpenSSLL will choose whatever PSK identity it deems
fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK
identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long
https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c
8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if
there is a clash (poor randoms, etc.). 

  i.e. "pick a long string and that should be good enough".

  If that really is the guidance, then this should also be called out in the
draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be
generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?
If "end users" shouldn't be doing this, the draft also needs to call that
out.

> Well, more precisely, the PSK identity is visible in the ClientHello, not
the actual PSK of course.

  Sure.

> And the PSK *must not* be a user-manageable string such as the
>> NAI.  On the other hand, if the PSK is sent after encryption begins, 
>> then the PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> ...
> so TLS-PSK is not suitable for a user entered low entropy password. We 
> need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)

  Sure.

> There are some use cases Eliot and I are looking at related to IoT
onboarding where a TLS-PSK authentication has definite value, and we really
don't want to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.
I'm not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be
using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be
automatically provisioned with long binary data for both PSK identity and
PSK itself".  Or even "PSK identities and/or passwords that are composed
solely of printable ASCII characters are likely to be humanly entered, and
thus insecure".

  Which means, of course, that people will ignore that and demand simple
user names / passwords for EAP-TLS with PSK.  Because that's ever so much
easier than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding
it.

  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

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

[Alan DeKok]

On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> Giving some implementation guidance seems appropriate here. Naively, one 
> could envisage the implementation simply having a DB table for extern PSKs 
> and a table that holds NewSessionTickets. An implementation could simply 
> check the extern PSK table using the PskIdentity.identity, and if no match is 
> found then check the NewSessionTickets table.

  Which works, but should be called out in the draft.

  And what is to prevent the system from generating conflicting PSK identities? 
 i.e. I don't control OpenSSL.  From what I see, TLS 1.3 resumption means that 
OpenSSLL will choose whatever PSK identity it deems fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK 
identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long 
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127
>  so something has gone seriously wrong if there is a clash (poor randoms, 
> etc.). 

  i.e. "pick a long string and that should be good enough".

  If that really is the guidance, then this should also be called out in the 
draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be 
generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?  
If "end users" shouldn't be doing this, the draft also needs to call that out.

> Well, more precisely, the PSK identity is visible in the ClientHello, not the 
> actual PSK of course.

  Sure.

> And the PSK *must not* be a user-manageable string such as the
>> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
>> PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> ...
> so TLS-PSK is not suitable for a user entered low entropy password. We need a 
> PAKE for that (c.f. the ongoing CFRG PAKE assessment)

  Sure.

> There are some use cases Eliot and I are looking at related to IoT onboarding 
> where a TLS-PSK authentication has definite value, and we really don't want 
> to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.  I'm 
not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be 
using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be 
automatically provisioned with long binary data for both PSK identity and PSK 
itself".  Or even "PSK identities and/or passwords that are composed solely of 
printable ASCII characters are likely to be humanly entered, and thus insecure".

  Which means, of course, that people will ignore that and demand simple user 
names / passwords for EAP-TLS with PSK.  Because that's ever so much easier 
than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding it.

  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)]

And one other draft of interest: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00

> -Original Message-
> From: Emu  On Behalf Of Owen Friel (ofriel)
> Sent: 18 September 2019 22:42
> To: Alan DeKok ; John Mattsson
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > -Original Message-
> > From: Alan DeKok 
> > Sent: 18 September 2019 14:40
> > To: John Mattsson 
> > Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> > tl...@ietf.org; EMU WG 
> > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> >
> >
> > > On Sep 18, 2019, at 9:21 AM, John Mattsson
> >  wrote:
> > >
> > > If I understand you correctly Alan, your implementation would have
> > different databases (one resumption DB and one external PSK DB) and
> > you do not want to do two database lookups.
> >
> >   It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2
> > talk about using multiple DBs, too.
> >
> > > The format of the PSKidentities is free for the deployment to decide
> > > upon
> > and the resumption PSKs can be completely be determined by the EAP-TLS
> > implementation. Your implementation could for example put a message
> > authentication code inside the PSK identity. The MAC would be
> > calculated with a symmetric key the EAP server has randomly generated
> > by itself. I think that would solve your problem.
> >
> >   I suggest giving guidance to implementors.  Otherwise the issue is
> > open to implementation-defined behaviour, which is problematic.
> 
> Giving some implementation guidance seems appropriate here. Naively, one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no match is
> found then check the NewSessionTickets table. The default OpenSSL NSK
> ticketId is 32 bytes long
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86a
> d1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously
> wrong if there is a clash (poor randoms, etc.). An additional layer of
> protection is provided by the PskBinderEntry as this is a HMAC derived using
> the PSK as one input, so the server even if there happened to be an identity
> clash, the binders will not match.
> 
> Implementations should also note
> https://tools.ietf.org/html/rfc8446#appendix-E.6.
> 
> >
> >   If PSKs are used only for resumption, the the format doesn't matter.
> > If PSKs are used for both authentication *and* resumption, then I
> > strongly recommend giving guidance.
> >
> >   For example, RFC 8446 Section 4.1.2 says:
> >
> >   struct {
> >   opaque identity<1..2^16-1>;
> >   uint32 obfuscated_ticket_age;
> >   } PskIdentity;
> >
> >   i.e. the PSK identity is an opaque binary string.  How is the user
> > supposed to enter a binary string into a "username" field in their
> > GUI?  What are the recommended formats?
> >
> >   If the ClientHello isn't encrypted, then the PSK is visible to
> > anyone (I believe).
> 
> Well, more precisely, the PSK identity is visible in the ClientHello, not the
> actual PSK of course.
> 
> And the PSK *must not* be a user-manageable string such as the
> > NAI.  On the other hand, if the PSK is sent after encryption begins,
> > then the PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> 
> "   Note:  When using an out-of-band provisioned pre-shared secret, a
>   critical consideration is using sufficient entropy during the key
>   generation, as discussed in [RFC4086].  Deriving a shared secret
>   from a password or other low-entropy sources is not secure.  A
>   low-entropy secret, or password, is subject to dictionary attacks
>   based on the PSK binder.  The specified PSK authentication is not
>   a strong password-based authenticated key exchange even when used
>   with Diffie-Hellman key establishment.  Specifically, it does not
>   prevent an attacker that can observe the handshake from performing
>   a brute-force attack on the password/pre-shared key. "
> 
> so TLS-PSK is not suitable for a user entered low entropy password. We need
> a PAKE for that (c.f. the ongoing CFRG PAKE assessment)
> 
> 
> >
> >   I see it being useful for EAP-TLS to allow PSK auth

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

[Owen Friel (ofriel)]

> -Original Message-
> From: Alan DeKok 
> Sent: 18 September 2019 14:40
> To: John Mattsson 
> Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > On Sep 18, 2019, at 9:21 AM, John Mattsson
>  wrote:
> >
> > If I understand you correctly Alan, your implementation would have
> different databases (one resumption DB and one external PSK DB) and you
> do not want to do two database lookups.
> 
>   It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2 talk
> about using multiple DBs, too.
> 
> > The format of the PSKidentities is free for the deployment to decide upon
> and the resumption PSKs can be completely be determined by the EAP-TLS
> implementation. Your implementation could for example put a message
> authentication code inside the PSK identity. The MAC would be calculated
> with a symmetric key the EAP server has randomly generated by itself. I think
> that would solve your problem.
> 
>   I suggest giving guidance to implementors.  Otherwise the issue is open to
> implementation-defined behaviour, which is problematic.

Giving some implementation guidance seems appropriate here. Naively, one could 
envisage the implementation simply having a DB table for extern PSKs and a 
table that holds NewSessionTickets. An implementation could simply check the 
extern PSK table using the PskIdentity.identity, and if no match is found then 
check the NewSessionTickets table. The default OpenSSL NSK ticketId is 32 bytes 
long 
https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127
 so something has gone seriously wrong if there is a clash (poor randoms, 
etc.). An additional layer of protection is provided by the PskBinderEntry as 
this is a HMAC derived using the PSK as one input, so the server even if there 
happened to be an identity clash, the binders will not match.

Implementations should also note 
https://tools.ietf.org/html/rfc8446#appendix-E.6. 

> 
>   If PSKs are used only for resumption, the the format doesn't matter.  If 
> PSKs
> are used for both authentication *and* resumption, then I strongly
> recommend giving guidance.
> 
>   For example, RFC 8446 Section 4.1.2 says:
> 
>   struct {
>   opaque identity<1..2^16-1>;
>   uint32 obfuscated_ticket_age;
>   } PskIdentity;
> 
>   i.e. the PSK identity is an opaque binary string.  How is the user supposed 
> to
> enter a binary string into a "username" field in their GUI?  What are the
> recommended formats?
> 
>   If the ClientHello isn't encrypted, then the PSK is visible to anyone (I
> believe).  

Well, more precisely, the PSK identity is visible in the ClientHello, not the 
actual PSK of course.

And the PSK *must not* be a user-manageable string such as the
> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
> PSK *should* be a user-manageable string such as an NAI.

https://tools.ietf.org/html/rfc8446#section-2.2 also states:

"   Note:  When using an out-of-band provisioned pre-shared secret, a
  critical consideration is using sufficient entropy during the key
  generation, as discussed in [RFC4086].  Deriving a shared secret
  from a password or other low-entropy sources is not secure.  A
  low-entropy secret, or password, is subject to dictionary attacks
  based on the PSK binder.  The specified PSK authentication is not
  a strong password-based authenticated key exchange even when used
  with Diffie-Hellman key establishment.  Specifically, it does not
  prevent an attacker that can observe the handshake from performing
  a brute-force attack on the password/pre-shared key. "

so TLS-PSK is not suitable for a user entered low entropy password. We need a 
PAKE for that (c.f. the ongoing CFRG PAKE assessment)


> 
>   I see it being useful for EAP-TLS to allow PSK authentication.  I just want 
> to
> be sure I know what that means, and what the impacts are.

There are some use cases Eliot and I are looking at related to IoT onboarding 
where a TLS-PSK authentication has definite value, and we really don't want to 
see this avenue closed off in EAP. Happy to provide any suggestions on 
Implementation Notes to your draft.

> 
> > I do not see how an attacker could do anything. an attacker can
> definitely reuse any PSK identity, but would not have the corresponding PSK
> and the ClientHello would therefore not be accepted. The worst thing an
> attacker could do is to replay a ClientHello, then the handshake would fail
> then the EAP server verifies the Finished message.

And note https://tools.ietf.org/html/rfc8446#appendix-E.6 where there is 
guidanc

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

[Alan DeKok]

> On Sep 18, 2019, at 9:21 AM, John Mattsson  wrote:
> 
> If I understand you correctly Alan, your implementation would have different 
> databases (one resumption DB and one external PSK DB) and you do not want to 
> do two database lookups.

  It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2 talk about 
using multiple DBs, too.

> The format of the PSKidentities is free for the deployment to decide upon and 
> the resumption PSKs can be completely be determined by the EAP-TLS 
> implementation. Your implementation could for example put a message 
> authentication code inside the PSK identity. The MAC would be calculated with 
> a symmetric key the EAP server has randomly generated by itself. I think that 
> would solve your problem.

  I suggest giving guidance to implementors.  Otherwise the issue is open to 
implementation-defined behaviour, which is problematic.

  If PSKs are used only for resumption, the the format doesn't matter.  If PSKs 
are used for both authentication *and* resumption, then I strongly recommend 
giving guidance.

  For example, RFC 8446 Section 4.1.2 says:

  struct {
  opaque identity<1..2^16-1>;
  uint32 obfuscated_ticket_age;
  } PskIdentity;

  i.e. the PSK identity is an opaque binary string.  How is the user supposed 
to enter a binary string into a "username" field in their GUI?  What are the 
recommended formats?

  If the ClientHello isn't encrypted, then the PSK is visible to anyone (I 
believe).  And the PSK *must not* be a user-manageable string such as the NAI.  
On the other hand, if the PSK is sent after encryption begins, then the PSK 
*should* be a user-manageable string such as an NAI.

  I see it being useful for EAP-TLS to allow PSK authentication.  I just want 
to be sure I know what that means, and what the impacts are.

> I do not see how an attacker could do anything. an attacker can 
> definitely reuse any PSK identity, but would not have the corresponding PSK 
> and the ClientHello would therefore not be accepted. The worst thing an 
> attacker could do is to replay a ClientHello, then the handshake would fail 
> then the EAP server verifies the Finished message.

  I agree.  My larger point was that in the absence of guidance, it's 
impossible to know what to do with a PSK identity.

> I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that 
> in any other application of EAP-TLS.

  I agree.

  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

[John Mattsson]

If I understand you correctly Alan, your implementation would have different 
databases (one resumption DB and one external PSK DB) and you do not want to do 
two database lookups. The format of the PSKidentities is free for the 
deployment to decide upon and the resumption PSKs can be completely be 
determined by the EAP-TLS implementation. Your implementation could for example 
put a message authentication code inside the PSK identity. The MAC would be 
calculated with a symmetric key the EAP server has randomly generated by 
itself. I think that would solve your problem.

I do not see how an attacker could do anything. an attacker can definitely 
reuse any PSK identity, but would not have the corresponding PSK and the 
ClientHello would therefore not be accepted. The worst thing an attacker could 
do is to replay a ClientHello, then the handshake would fail then the EAP 
server verifies the Finished message.

I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that in 
any other application of EAP-TLS.

/John

-Original Message-
From: Alan DeKok 
Date: Wednesday, 18 September 2019 at 15:07
To: "Owen Friel (ofriel)" 
Cc: John Mattsson , 
"draft-ietf-emu-eap-tl...@ietf.org" , EMU WG 

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

On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>>  Which means that if PSK was allowed, the server can't look at the 
packets to
>> distinguish resumption from "raw" PSK.  Instead, the server has to look 
at it's
>> resumption cache which may be in a DB.
> 
> The server can use the PskIdentity in the PreSharedKeyExtension to 
differentiate between an offline PSK used for authentication vs. a PSK 
established via NewSessionTicket.

  Please define "use".  As an implementor, I can't implement "my code USES 
a field".  I need to know what the code *does* with it.

  How does the code differentiate between PSK identities?  Are the identity 
formats different?  If so, how and why?

  What prevents a malicious attacker from "using" a format which matches an 
identity coming from NewSessionTicket?

  My understanding is that the code *cannot* make any decisions simply by 
looking at the PSK identity field.  Instead, it has to look at the resumption 
cache to see if a given PSK matches a cached one.  Or maybe the code looks in a 
DB to see if the given PSK is a real "end-user" PSK in the DB.

  Simply waving your hands and saying it "uses" a field is unhelpful.  
Please give substantive feedback and/or advice about what the code *does*.

  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]

  Just re-reading the text on PSK, I noticed a few things.  The text in Section 
2.1.2 talks about PSK, the session ticket, and a "key_share" extension.   The 
accompanying diagram doesn't include any of those.  I suggest updating the 
diagram to include them.

  As a related note, if the PSK *is* in the resumption cache, but the key is 
wrong, the cache entry should not be discarded.  Otherwise an attacker can 
disable caching for *all* users.  This issue could be clearer in this document.

  Perhaps it would be useful to add a short note in Section 5 about security of 
resumption.  It should reference RFC 8446 Section 8.1, and 8.2, which discuss 
this issue.  Also, Section 4.2.11 of that document has an "Implementor's note:" 
which is important.

  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 Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>>  Which means that if PSK was allowed, the server can't look at the packets to
>> distinguish resumption from "raw" PSK.  Instead, the server has to look at 
>> it's
>> resumption cache which may be in a DB.
> 
> The server can use the PskIdentity in the PreSharedKeyExtension to 
> differentiate between an offline PSK used for authentication vs. a PSK 
> established via NewSessionTicket.

  Please define "use".  As an implementor, I can't implement "my code USES a 
field".  I need to know what the code *does* with it.

  How does the code differentiate between PSK identities?  Are the identity 
formats different?  If so, how and why?

  What prevents a malicious attacker from "using" a format which matches an 
identity coming from NewSessionTicket?

  My understanding is that the code *cannot* make any decisions simply by 
looking at the PSK identity field.  Instead, it has to look at the resumption 
cache to see if a given PSK matches a cached one.  Or maybe the code looks in a 
DB to see if the given PSK is a real "end-user" PSK in the DB.

  Simply waving your hands and saying it "uses" a field is unhelpful.  Please 
give substantive feedback and/or advice about what the code *does*.

  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 Alan DeKok
> Sent: 12 September 2019 16:28
> To: John Mattsson 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 12, 2019, at 10:55 AM, John Mattsson
>  wrote:
> >
> >> See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we
> *cannot* use PSK for >authentication in EAP-TLS.
> >
> > I don't understand why this could not be done. My view is that allowing PSK
> authentication would be quite easy.
> 
>   How would systems tell the difference between "raw" PSK and
> "resumption" PSK?
> 
>   When allowing resumption, the server has sent a PSK identity in a
> NewSessionTicket message.  The client caches this and re-uses this.  But the
> client signals that it is performing resumption via the act of using PSK.  
> There's
> nothing else.
> 
>   Which means that if PSK was allowed, the server can't look at the packets to
> distinguish resumption from "raw" PSK.  Instead, the server has to look at 
> it's
> resumption cache which may be in a DB.

The server can use the PskIdentity in the PreSharedKeyExtension to 
differentiate between an offline PSK used for authentication vs. a PSK 
established via NewSessionTicket.

There should be no problem here, and the statement

" Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption. "

should be updated to clarify.

> 
> >>> While there is the EAP-PSK method, I would much rather use EAP-TLS
> with PSK because it >provides identity protection and perfect forward
> secrecy, unlike EAP-PSK.
> >>
> >> Use EAP-PWD for that.
> >
> > Standardizing EAP-TLS should only be done if it has some significant
> advantages over EAP-PWD, and there are people wanting to implement and
> use it. 3GPP is e.g. adding  identity protection and perfect forward secrecy 
> to
> EAP-AKA instead.
> 
>   I would prefer to forbid PSK in EAP-TLS.
> 
>   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

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

[Alan DeKok]

On Sep 12, 2019, at 10:55 AM, John Mattsson  wrote:
> 
>> See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we 
>> *cannot* use PSK for >authentication in EAP-TLS.
> 
> I don't understand why this could not be done. My view is that allowing PSK 
> authentication would be quite easy.

  How would systems tell the difference between "raw" PSK and "resumption" PSK?

  When allowing resumption, the server has sent a PSK identity in a 
NewSessionTicket message.  The client caches this and re-uses this.  But the 
client signals that it is performing resumption via the act of using PSK.  
There's nothing else.

  Which means that if PSK was allowed, the server can't look at the packets to 
distinguish resumption from "raw" PSK.  Instead, the server has to look at it's 
resumption cache which may be in a DB.

>>> While there is the EAP-PSK method, I would much rather use EAP-TLS with PSK 
>>> because it >provides identity protection and perfect forward secrecy, 
>>> unlike EAP-PSK. 
>> 
>> Use EAP-PWD for that.
> 
> Standardizing EAP-TLS should only be done if it has some significant 
> advantages over EAP-PWD, and there are people wanting to implement and use 
> it. 3GPP is e.g. adding  identity protection and perfect forward secrecy to 
> EAP-AKA instead.

  I would prefer to forbid PSK in EAP-TLS. 

  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

[John Mattsson]

See comments inline

-Original Message-
From: Alan DeKok 
Date: Thursday, 12 September 2019 at 15:56
To: Aura Tuomas 
Cc: EMU WG , "draft-ietf-emu-eap-tl...@ietf.org" 

Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: 
Resent to: John Mattsson , 
Resent date: Thursday, 12 September 2019 at 15:56

>Alan DeKok wrote:
>On Sep 12, 2019, at 9:53 AM, Aura Tuomas  wrote:
>   > 
>> I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it 
> forbids PSK >authentication. Why is that?

There was discussion regarding this on the list some years ago. The conclusion 
was to use the EAP-TLS Type-Code should be exclusively for certificate 
authentication. At that point, nobody expressed wish to use EAP-TLS with PSK 
authentication. If someone wants to use EAP-TLS with symmetric keys that should 
probably be a  new code point.

>  See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we 
> *cannot* use PSK for >authentication in EAP-TLS.

I don't understand why this could not be done. My view is that allowing PSK 
authentication would be quite easy.

>> While there is the EAP-PSK method, I would much rather use EAP-TLS with 
> PSK because it >provides identity protection and perfect forward secrecy, 
> unlike EAP-PSK. 
>
>  Use EAP-PWD for that.

Standardizing EAP-TLS should only be done if it has some significant advantages 
over EAP-PWD, and there are people wanting to implement and use it. 3GPP is 
e.g. adding  identity protection and perfect forward secrecy to EAP-AKA instead.

>
>> In fact, I think EAP-TLS with PSK should become the standard 
> authentication method for >networks that rely on shared secrets, e.g. 
> WPA-Personal. Unifying the Wi-Fi authentication >around EAP would greatly 
> simplify the Wi-Fi protocol stack. Not that I expect it to happen 
> >immediately, but we should not close sensible paths forward.
>
>  The time to fix that was before TLS 1.3 was standardized.
>
>  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 Sep 12, 2019, at 9:53 AM, Aura Tuomas  wrote:
> 
> I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it forbids 
> PSK authentication. Why is that?

  See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we 
*cannot* use PSK for authentication in EAP-TLS.

> While there is the EAP-PSK method, I would much rather use EAP-TLS with PSK 
> because it provides identity protection and perfect forward secrecy, unlike 
> EAP-PSK. 

  Use EAP-PWD for that.

> In fact, I think EAP-TLS with PSK should become the standard authentication 
> method for networks that rely on shared secrets, e.g. WPA-Personal. Unifying 
> the Wi-Fi authentication around EAP would greatly simplify the Wi-Fi protocol 
> stack. Not that I expect it to happen immediately, but we should not close 
> sensible paths forward.

  The time to fix that was before TLS 1.3 was standardized.

  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

[Aura Tuomas]

I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it forbids PSK 
authentication. Why is that? While there is the EAP-PSK method, I would much 
rather use EAP-TLS with PSK because it provides identity protection and perfect 
forward secrecy, unlike EAP-PSK. 

In fact, I think EAP-TLS with PSK should become the standard authentication 
method for networks that rely on shared secrets, e.g. WPA-Personal. Unifying 
the Wi-Fi authentication around EAP would greatly simplify the Wi-Fi protocol 
stack. Not that I expect it to happen immediately, but we should not close 
sensible paths forward.

Tuomas

___
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 Aug 3, 2019, at 5:53 PM, Jim Schaad  wrote:
> 
> In section 5.7 - I am not sure why one could not re-check for revocation
> when doing a resumption, I would expect that this is only server side that
> would do it but the current paragraph two outlaws it.

  I think it's best to *always* apply authorization policies.  The alternative 
is to allow the server to *not* check authorization policies during resumption. 
 Which then means that the client is in charge of authorization, not the server.

  Alan DeKok.

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

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

[Jim Schaad]

I am just finally getting caught up on mail for the EMU WG and am getting
this done.

It should probably be clarified that Figure 1has the additional restriction
that the server is not sending any resumption tickets as well.It would
also be better to label the TLS Application Data as the commitment message
as no other TLS Application data is being sent.

I think that it might be reasonable to put in a note for Figure 2 that if a
client does receive a fatal from the hello message, then changing the
offered key share algorithm is one thing that might be successful in the
future - That is put in a note to match what the request retry message does.
Okay - I found the use of the retry down below but it is not referenced from
here but it is still labeled as a server rejects the client hello.

In section 2.1.5 - You are mandating support for resumption.  Is this really
what you are planning to do?  If this is true then lots of the previous text
seems to be off because this is not part of that discussion.

In section 2.1.6 - Should there be a recommendation (or not) that when a
resumption ticket is used, then a new ticket (or set of tickets) ought to be
provided to the client.

In section 2.5 - I don't know that I have the ability to control what the
TLS block looks like to the extent that this seems to be wanting to do.

In section 5.7 - I am not sure why one could not re-check for revocation
when doing a resumption, I would expect that this is only server side that
would do it but the current paragraph two outlaws it.

I am a little surprised that the padding feature of TLS 1.3 received
absolutely no mention in this document.

Jim


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