Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jul 3, 2021, at 7:47 AM, Eliot Lear wrote: > I don't think Tim could be blamed for holding the view that there is a > separation between specifications and how they are used. There's good and bad > to the practice. The good is that the spec can be used in ways that the > creators didn't intend, and thus perahsp there are fewer unnecessary > constraints. > > On the other hand, not having a theory of operation section, as we do have in > a good number of our specs, leads to people really not understanding when > they are applicable, and perhaps more importantly, when they are not. People don't even understand how to use the specs as intended. We're essentially telling people "EAP methods are applicable in these situations, but good luck actually trying to get them deployed, you're on your own". Each vendor does randomly different things for UI / credential management / workflow / whatever. The end result is that the spec is largely theoretical. In practice, people do any number of hacks to get something to work. Because the specs don't help here. If people can't deploy a spec easily and securely, then I see that as a failure of the specification. For example, over the last 20+ years, the "Security Considerations" section of RFCs has grown in importance and content. This is a good thing. > All of this having been said, perhaps the best way to go forward is to have a > requirements discussion in terms of the sorts of operations we would like to > see as part of the authentication process – as opposed to elsewhere. > > I see tremendous opportunity here, to be honest. But it's a lot of work. I agree. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Hi Alan, I don't think Tim could be blamed for holding the view that there is a separation between specifications and how they are used. There's good and bad to the practice. The good is that the spec can be used in ways that the creators didn't intend, and thus perahsp there are fewer unnecessary constraints. On the other hand, not having a theory of operation section, as we do have in a good number of our specs, leads to people really not understanding when they are applicable, and perhaps more importantly, when they are not. All of this having been said, perhaps the best way to go forward is to have a requirements discussion in terms of the sorts of operations we would like to see as part of the authentication process – as opposed to elsewhere. I see tremendous opportunity here, to be honest. But it's a lot of work. Eliot On 03.07.21 13:35, Alan DeKok wrote: We have specs with Security Considerations, and implementation guidelines. They're a lot more than just what bits go on the wire. In general, a BCP is too late in the process. Vendors have already implemented the base spec, so what's "current" is a random grab-bag of stuff decided on by product managers, or by junior engineers. I've seen many, many, sites unable to deploy the security they want, due to a wide range of limitations in products. IMHO, these are security issues, and should be treated as such in the base specification. There should be clear guidance given on a wide range of issues, such as security, implementation, UI, workflow, etc. Not having those guidelines is a large source of income for me. But it is endlessly frustrating for everyone involved. I would prefer to help people build useful systems, instead of having them pay me to paper over issues in multiple products. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jul 2, 2021, at 9:16 PM, Tim Cappalli wrote: > > >> The current specs define the base protocols, but leave pretty much > >> everything else undefined. > > That’s the job of a spec isn’t it? As far as I understand, deploying in the > real world / best practices should go in a BCP. We have specs with Security Considerations, and implementation guidelines. They're a lot more than just what bits go on the wire. In general, a BCP is too late in the process. Vendors have already implemented the base spec, so what's "current" is a random grab-bag of stuff decided on by product managers, or by junior engineers. I've seen many, many, sites unable to deploy the security they want, due to a wide range of limitations in products. IMHO, these are security issues, and should be treated as such in the base specification. There should be clear guidance given on a wide range of issues, such as security, implementation, UI, workflow, etc. Not having those guidelines is a large source of income for me. But it is endlessly frustrating for everyone involved. I would prefer to help people build useful systems, instead of having them pay me to paper over issues in multiple products. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
