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

[Alan DeKok <[e-mail]>]

On Feb 11, 2022, at 6:04 AM, John Mattsson <[e-mail]> 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.
>  
> 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 [e-mail] 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.