On Jan 19, 2022, at 6:38 AM, John Mattsson <john.matts...@ericsson.com> wrote: > > draft-arkko-emu-rfc3748bis > > I heard significant opposition to that at the last EMU meeting. I don't > see a compelling reason to rev 3748. > > John: I think we should get back to this topic for more discussion on if and > how. Bernard expressed opposition to obsolete as he said that would require > recertification of products. But there was also a suggestion that we should > instead do Internet Standard instead. EAP does definitly deserve to be an > Internet Standard. Another suggestion was to make an update instead of > obsolete which would not trigger recertification.
Are there any implementors of EAP who are asking for it to be updated? From what I can see, the answer is "no". Which means that the IETF is free to work on a document, but it will be either opposed, or at best, ignored. > The following has been brought up as reasons for doing some kind of update: > - EAP is essential for network acces authentication and should be an Internet > Standard Like RADIUS accounting. But we've lived for 25+ years without that. I think it's fine. > - "Master" should be changed to "Main" tofollow inclusive language > recommendations (TLS is already doing this). This reminds me of a comment about "codes of conduct" for software projects. The observation was that in many cases, the proponents of such codes engaged in such extreme behavior that they should have been banned under the codes which they were proposing. Yet that never happened. The only conclusion then is that something else is going on. In linguistics these re-naming of "bad" things is called the "euphemism treadmill". History has other names for such morality plays. > - Several of the methods defines in RFC 3748 like MD5-Challenge would benefit > from security consideration and references to more recommended methods such > as EAP-TLS. While that's true, I would like to see how that benefit is worth the effort involved in updating the standard. > - There are errata. > - The consideration and recommendations for identity protection is not up to > data with current best practice. For me, that's been adequately patched in updates to EAP methods. i.e. methods where identity protection matter. For insecure methods, they're used in situations where identity protection doesn't really matter. > - RFC 3748 does not even mention forward secrecy is more and more becoming a > requirement to acceptable security. > - Mention new access technologies such as 5G where EAP is an essential part. I don't understand how this is useful. > - Mention of recommend use of documents such as [RFC4137] [RFC5113] [RFC5247] > [RFC6677] [RFC7029]. > > IETF is at least nowadays very often making updates such as this (RFC7296, > RFC8446bis, RFC7616, RFC8489, RFC8656, RFC8445, etc.) > > My personal view would be that the security considerations considering MD5, > identity protection, and forward secrecy would be worthwhile doing in some > way. It would also be good to mention essential updates such as RFC 4137. Given the significant opposition, I don't see how WG consensus can be achieved here. The only way forward would be to ignore all of the EAP implementors, and declare consensus despite their objections. > > draft-ingles-eap-edhoc > > That seems useful for limited situations (i.e. IoT). It also has issues > with publicizing identities. > > John: I think the only thing that is missing is to mandate use of ananymous > NAIs. I don't see any provision in the draft for providing a "real" identity. So the only NAI used is the outer one, which therefore cannot be fully anonymized. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
