Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-11 Thread Jan-Frederik Rieckers
On 12.11.19 00:15, Owen Friel (ofriel) wrote:
> One deployment consideration is if an operator wants to use a public PKI 
> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, 
> before these extensions could be supported (as Alan alludes to), so it would 
> also be good to define how this could work with standard RFC 6125 DNS-IDs / 
> RFC 5280 dNSNames.

I had a lot of thoughts about this topic.
I am experimenting with certificates in EAP-TLS contexts and experienced
the problems with getting a certificate with specific extension
properties from our public PKI. (In my case a test certificate with a
critical MustStaple extension)

The Problem with dNSNames is that they are also used in other contexts
(mainly HTTPS). There would be the possibility to define a specific
prefix to bind it to a Realm without having the certificate being valid
for the HTTPS host (e.g. eap-tls.uni-bremen.de for the realm
uni-bremen.de) but I don't see the advantage in that.
This will probably don't really lead to a change in the supplicants
implementations.

My deployment experience shows, that the certificate check is the main
security problem in WPA2-Enterprise networks. I have seen instructions
for installing WPA2-Enterprise networks where they have explicitly
suggested switching off the certificate check, probably because it was
too complicated for the users and would lead to people complaining at
the IT department about the complicated setup.

A setup of WPA2-Enterprise can be secure if all devices are part of a
centralized Device Management, but especially in eduroam this isn't
possible. We have a lot of people who don't really care about security.

  Jan-Frederik Rieckers



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


Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-11 Thread Alan DeKok
On Nov 11, 2019, at 6:15 PM, Owen Friel (ofriel)  wrote:
> 
> This is also related to ongoing anima discussions about RFC 8366, and how it 
> can bootstrap trust when the pinned domain cert is a public PKI CA, and not a 
> private CA, and hence additional domain (or realm or FQDN) info is also 
> needed in order for the peer to verify the identity of the server.
> 
> Its also relevant for ongoing Wi-Fi Alliance DPP discussions about 
> bootstrapping a supplicant onto an 802.1X network - after a supplicant 
> completes DPP and gets provisioned with a trust anchor - what if that trust 
> anchor is a public PKI? It’s the same problem.
> 
> One deployment consideration is if an operator wants to use a public PKI 
> (e.g. Lets Encrypt) for their AAA certs, then it could be years, if ever, 
> before these extensions could be supported (as Alan alludes to), so it would 
> also be good to define how this could work with standard RFC 6125 DNS-IDs / 
> RFC 5280 dNSNames.

  That sounds reasonable.

  Certificates for 802.1X authentication already use DNS names.  It's not 
wide-spread, but it's not rare.  There's no *meaning* to these names, as 
nothing checks them.

  It would be useful to suggest how a supplicant can use these fields to 
further verify a server certificate.  And for servers, what these fields should 
contain.

  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

2019-11-11 Thread 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

2019-11-11 Thread 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

2019-11-11 Thread 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

2019-11-11 Thread 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] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

2019-11-11 Thread Owen Friel (ofriel)



> -Original Message-
> From: Alan DeKok 
> Sent: 07 November 2019 17:43
> To: Owen Friel (ofriel) 
> Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org;
> EMU WG ; John Mattsson
> ; Michael Richardson
> 
> Subject: Re: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu-
> eap-tls13)
> 
> On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> >> [Joe]  Is EAP Identity Synonymous with the NAI?
> >
> > [ofriel] I'd also like to definitively understand this. Neither RFC3748 or
> RFC7542 are clear on this. Should this be an errata to clarify.. somewhere?
> 
>   The EAP Identity can largely be anything, so long as it is UTF-8.
> 
>  The *recommendation* in RFC 7542 is to make it an NAI.  But that isn't
> mandated anywhere.
> 
>   I'm not sure there's any errata required.

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

> 
> > Two other questions on RFC3748. Section 5.1 states:
> > "  It is RECOMMENDED that the Identity Response be used primarily for
> >  routing purposes and selecting which EAP method to use. "
> >
> > Is it defined anywhere how the Identity is used for EAP method selection?
> 
>   It is absolutely not mentioned anywhere.  For the simple reason that EAP
> provides for method negotiation.  We don't need to overload the Identity 
> field.

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

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

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

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

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

[ofriel]  Sure, but that's not what I am getting at, I was asking about EAP 
method selection and my confusion between the statements in sections 
5.1/Identity and 5.3/Nak.
> 
> > Or is this EAP method specific and should be defined in the method specific
> draft?
> 
>   No EAP document should recommend overloading Identity in order to do EAP
> method selection.
> 
> > E.g. we have documented in https://tools.ietf.org/html/draft-lear-eap-teap-
> brski-05#section-5 that:
> >
> > "   A device that has not been bootstrapped at all SHOULD send an
> >   identity of teap-bootstrap@TBD1. "
> >
> > If we register that "teap-bootstrap@TBD1" with IANA, then it could be the
> mechanism by which the peer tells the server that it wants to use TEAP. If the
> server does not support TEAP, it will return an error response.
> 
>   The discussion prior to IETF 105 was that we should use the ".arpa" domain:
> https://www.iana.org/domains/arpa  That domain is explicitly intended for this
> kind of negotiation.
> 
>   Note that using ".arpa" still isn't EAP method selection.  It's instead 
> signalling
> something else.
> 
> > For routing, the Identity provided includes a realm and it could be 
> > anonymous:
> e.g. "@example.com". If the server cannot route to that domain, it returns an
> error.
> 
>   i.e. an EAP Failure message.
> 
> > EAP provides no mechanism to return an error code to the peer. How could we
> signal in EAP the error difference between routing vs EAP method unsupported
> failures? Or can we at all?
> 
>   EAP provides for a NAK for negotiation, and a Notification packet for 
> signalling
> errors or messages. Unfortunately, most supplicants don't support 
> Notification.
> And the ones that do won't show Notification messages to the end user.

[ofriel] Ok, thanks.

> 
>   Alan DeKok.

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


Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

2019-11-11 Thread Jan-Frederik Rieckers
Hi,
Thank you for your feedback.

I was unaware of RFC 7585. I had a brief look on it and it seems that
the certificate part could be used for the goal I try to achieve.

I'm not quite sure if the naiRealm should be used for validation on
supplicants for EAP-TLS. I would assume it would not be a security
issue, but I don't have enough experience to be sure about that.

The main reason why I submitted this draft is my experience from the
deployment of eduroam at University Bremen.
With expiry of the used root CA and the needed migration, we have forced
all our users to use one specific outer Identity, to be sure the users
configure their devices with the eduroam Configuration Assistant Tool
(CAT, cat.eduroam.org) instead of a manual configuration, because in our
experience manual configured devices almost always lacked configuration
for certificate checking.
But I just have experience in local deployment, the federation
connections are done at higher levels (country research networks), I
don't have an insight there.

Greetings,
Jan-Frederik Rieckers



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