Subject: Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt

From: John Mattsson <[email-masked]>
Date: Fri, 11 Feb 2022 11:04:23 +0000

Hi,

I think it would be very good if IETF/EMU could agree on simpler, more automatic, and secure deployment and configuration of TLS-based EAP methods. This is severely needed. Both complexity and security are very real problems.

https://threatpost.com/misconfiguration-university-wifi-login-credentials/175157/

RFC 8446, RFC 5216, and draft-ietf-emu-eap-tls13 does not give much guidance on this and the security requirement for cerficates are soft.

Any work should likely align with https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

I have not read draft-dekok-emu-eap-usability-00 yet. Inter-operability issues between implementations seems to be an issue, how easy will it be to reach consensus between different implementations?

Cheers,
John

From: Emu <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Date: Friday, 16 July 2021 at 21:32
To: Carolin Baumgartner <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Emu] Version Notification for draft-dekok-emu-eap-usability-00.txt
On Jul 16, 2021, at 6:26 AM, Carolin Baumgartner <[email-masked]> wrote:
>>   Provided there's some network connection available, everything else can be automatic.
> ah yes. I guess it might make sense to make that clear towards the beginning of the document :-) I only got a later ....

  I'll definitely fix that.

> I finished the document now and really like it. I just think the normative part comes quite late in the document. Maybe it should also be referenced in earlier sections. To make it stronger, you could even use SHOULD instead of RECOMMENDED (in section 8.2), I guess

  SHOULD and RECOMMENDED are synonyms for this purpose.

  I left the normative bits to the end because I wanted to explain the problem, and then give examples of the solution first.  Once those are clear, they then motivate the normative text.

  I found that if I put the normative text earlier, then people would ask "why these decisions?", only to have them answered later in the document.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Feb 2022 09:04:33 -0500

> https://threatpost.com/misconfiguration-university-wifi-login-credentials/175157/

  That attack was in fact first publicly presented by my team in 2016, at NetworkShop 44.  We also published an article on it in August of 2021 on our web site:

https://networkradius.com/articles/2021/08/04/wifi-spoofing.html

  Then magically in September 29 2021, Wizcase says "WizCase’s security team, ... has discovered a major security issue affecting the users of WiFi provider eduroam".  And "We contacted eduroam on December 2020 "

  No, they didn't discover anything.  This issue was well known for years before they did their "research".

> RFC 8446, RFC 5216, and draft-ietf-emu-eap-tls13 does not give much guidance on this and the security requirement for cerficates are soft.

  The IETF has historically avoided doing configuration in this space.

> Any work should likely align with https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

  On quick inspection, that document could have some relevance.

> I have not read draft-dekok-emu-eap-usability-00 yet.

  Despite it's length, it makes a very simple proposal.  One which draft-ietf-uta-rfc6125bis touches on in Section 4.2:

   Consider an IMAP-accessible email server at the host mail.example.net
   servicing email addresses of the form [email-masked] and
   discoverable via DNS SRV lookups on the application service name of
   example.net.  A certificate for this service might include SRV-IDs of
   _imap.example.net and _imaps.example.net 

  At it's heart, draft-dekok-emu-eap-usability-00 makes a similar proposal for EAP.  A client can do DNS SRV lookups for _eap.example.net, and can determine location, etc. for EAP services.

  Where my document extends this idea is that it also allows clients to discover which certificates are being used for a service.  draft-ietf-uta-rfc6125bis does not seem to touch on this topic, and gives only examples of public (not private) CAs.  In contrast, many EAP deployments use private CAs for security and ease of management.  As such, it is important to have an easy way to discover these certificates.

  If we're doing DNS SRV lookups for services, we might was well do DNS SRV lookups for information associated with those certificates.

  For example, there's no reason for a company to use a public CA for private services such as IMAP.  It would add security for IMAP servers to use private CAs and client certs issued by those private CAs.  The only reason this isn't done is that configuring mail clients is difficult.

  I'll also add a personal note that I wish SRV records would become more ubiquitous.  I fail to understand why in 2021 I have to manually configure IMAP for a new mail client, when the client could simply ask for a SRV recorrd of "_imaps.example.net", and get told "IMAP servers are at this DNS name, using this certificate".

> Inter-operability issues between implementations seems to be an issue, how easy will it be to reach consensus between different implementations?

  Inter-operability for my draft?  The happy news is that there are no implementations other than my toy one.

  Even better, my draft proposes nothing more than well-known DNS lookups, and well-known URIs.  We know that DNS and HTTPS work very well.  Any client EAP configuration is done solely by code on the client, which means that it doesn't have to inter-operate with anything.

  Stefan Winter proposed a standard EAP configuration format in the IETF many years ago.  It never got traction, so he went to the WiFi alliance.  Their latest spec now mandates an XML configuration format.

  Alan DeKok.

---

From: Deb Cooley <[email-masked]>
Date: Tue, 15 Feb 2022 13:08:33 -0500

Is there a plan to continue work on this draft (I think it has expired)?  I
skimmed through it a while ago, had thoughts/comments, but have resisted
the urge to provide them (why work on something that is OBE?).

It is longish, but it is not a difficult read.

Deb Cooley
[email-masked]

On Fri, Feb 11, 2022 at 9:04 AM Alan DeKok <[email-masked]>
wrote:

> > I think it would be very good if IETF/EMU could agree on simpler, more
> automatic, and secure deployment and configuration of TLS-based EAP
> methods. This is severely needed. Both complexity and security are very
> real problems.
> >
> >
>   That attack was in fact first publicly presented by my team in 2016, at
> NetworkShop 44.  We also published an article on it in August of 2021 on
> our web site:
>
>   Then magically in September 29 2021, Wizcase says "WizCase’s security
> team, ... has discovered a major security issue affecting the users of WiFi
> provider eduroam".  And "We contacted eduroam on December 2020 "
>
> > RFC 8446, RFC 5216, and draft-ietf-emu-eap-tls13 does not give much
> guidance on this and the security requirement for cerficates are soft.
>
> > Any work should likely align with
> https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/
>
>   Despite it's length, it makes a very simple proposal.  One which
> draft-ietf-uta-rfc6125bis touches on in Section 4.2:
>
>   At it's heart, draft-dekok-emu-eap-usability-00 makes a similar proposal
> for EAP.  A client can do DNS SRV lookups for _eap.example.net, and can
> determine location, etc. for EAP services.
>
>   Where my document extends this idea is that it also allows clients to
> discover which certificates are being used for a service.
> draft-ietf-uta-rfc6125bis does not seem to touch on this topic, and gives
> only examples of public (not private) CAs.  In contrast, many EAP
> deployments use private CAs for security and ease of management.  As such,
> it is important to have an easy way to discover these certificates.
>
>   If we're doing DNS SRV lookups for services, we might was well do DNS
> SRV lookups for information associated with those certificates.
>
>   For example, there's no reason for a company to use a public CA for
> private services such as IMAP.  It would add security for IMAP servers to
> use private CAs and client certs issued by those private CAs.  The only
> reason this isn't done is that configuring mail clients is difficult.
>
>   I'll also add a personal note that I wish SRV records would become more
> ubiquitous.  I fail to understand why in 2021 I have to manually configure
> IMAP for a new mail client, when the client could simply ask for a SRV
> recorrd of "_imaps.example.net", and get told "IMAP servers are at this
> DNS name, using this certificate".
>
> > Inter-operability issues between implementations seems to be an issue,
> how easy will it be to reach consensus between different implementations?
>
>   Even better, my draft proposes nothing more than well-known DNS lookups,
> and well-known URIs.  We know that DNS and HTTPS work very well.  Any
> client EAP configuration is done solely by code on the client, which means
> that it doesn't have to inter-operate with anything.
>
>   Stefan Winter proposed a standard EAP configuration format in the IETF
> many years ago.  It never got traction, so he went to the WiFi alliance.
> Their latest spec now mandates an XML configuration format.
>
>   Alan DeKok.
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Feb 2022 14:10:56 -0500

On Feb 15, 2022, at 1:08 PM, Deb Cooley <[email-masked]> wrote:
> 
> Is there a plan to continue work on this draft (I think it has expired)?  I skimmed through it a while ago, had thoughts/comments, but have resisted the urge to provide them (why work on something that is OBE?).  

  I plan to keep working on it.  I've had positive feedback on it, but the IETF tends to work slowly.

> It is longish, but it is not a difficult read.

  Thanks.  I tried to explain everything in detail, with examples.  The subject is complex enough that a shorter document would have left a lot of open questions.

  Alan DeKok.