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 protected] On Fri, Feb 11, 2022 at 9:04 AM Alan DeKok <[email protected]> wrote: > On Feb 11, 2022, at 6:04 AM, John Mattsson <[email protected]> > 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 [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
