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

[Deb Cooley <[e-mail]>]

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
[e-mail]

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

> 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.
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>