On Feb 19, 2021, at 2:12 AM, John Mattsson <john.matts...@ericsson.com> wrote: > But these are more implementation guidance/history then security requirements.
Do these issues affect security? If the answer is "no", then they can be ignored. If the answer is "yes", then they should be put in. You've approached this specification as a theoretical exercise in protocol design. I've tried to explain that protocols are implemented in the real world, by real people. As such, it is important for the document to give implementation guidance. Further, it's very useful for implementors to understand *why* things are done a particular way. Explaining the reasons for a particular choice helps implementors understand the higher level picture, which makes implementation easier. There are any number of RFCs which take this approach. Experience shows that specifications which do *not* have implementation guidance. too often result in insecure implementations. There have been a number issues brought up by people who have *coded* these protocols, and *used* them in the real world. You're opposing the requests to update the document with guidance that the implementors say they need. The reasons you give are largely from inexperience: "I don't understand why this matters". Well, it does. If you don't understand why, then please step aside, and let the work be done by others. If you won't step aside, then please stop resisting guidance from people who have experience in this area. To be perfectly frank: if this specification does not meet the needs of implementors, then they will ignore it, and go do whatever they want. This particular specification will be ignored. And once implementors are ready, they will bring a specification to the IETF which says "ignore the previous spec, this is what we actually did". > Might also be that the text in quoted text in RFC 5216 is not how things are > implemented. There is code publicly available. I suggest looking at it. > An alternative approach would be to check that the certificates are issues by > a CA that is exclusively used for EAP-TLS in a specific network and ignore > the identities. This topic has been discussed before in EMU, including explanations of what people have been doing for a decade in production networks Implementors have a long established a set of practices which are NOT written down in any standard. These practices help to both secure the network, and make these systems easier to deploy. i.e.: Instead of fighting with standards bodies, implementors have gone and done their own thing, because the specifications are lacking. Worse, the processes used by standards bodies are lacking. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
