4 ms·

To be fair, the parent comment is slightly misleading. I don't know the exact story of MSCHAPv2 but note that it is an informational RFC published by the pppext

To be fair, the parent comment is slightly misleading. I don't know the exact story of MSCHAPv2 but note that it is an informational RFC published by the pppext WG: https://tools.ietf.org/html/rfc2759 https://tools.ietf.org/html/rfc2759 For an RFC to be published by a WG, it must first be "adopted" by the group, which means a first draft is submitted by the author, and then debatted (sometimes lightly) until the group agrees that it fits the topic and is suitable for adoption. Similarly, once the RFC is adopted, it goes through a series of calls by the WG chair where people have opportunities to comment, until it is finally published. Informational RFCs have lighter requirements than standard tracks one, so they are easier to get published, but they still get some amount of review and comments before publication. It took 14 months and 4 drafts for MSCHAPv2 to get published: https://datatracker.ietf.org/doc/rfc2759/ https://datatracker.ietf.org/doc/rfc2759/ In fact, even "independent submissions" with "experimental" status (that do not go through a WG at all, https://tools.ietf.org/html/rfc2026#section-4.2.1 https://tools.ietf.org/html/rfc2026#section-4.2.1) get reviewed before publication. The reviews in that case are private, but a RFC editor is responsible for sanity-checking the document and sometimes requests additional input from reviewers specialized in the domain area covered by the draft. [Edit: the actual WG for MSCHAPv2 was https://tools.ietf.org/wg/pppext/ https://tools.ietf.org/wg/pppext/, not "Networking" which is just the generic name on top of the RFC]

tialaramex 8y ago
Although you're correct that there was a drafting process for MSCHAPv2, the actual protocol it describes had already shipped in Windows. As a result "But this is a bad idea" would not have been a useful contribution to the drafting process, the zero draft describes the exact same protocol, just with different words. Edited to add: The drafting process wasn't worthless, it fixed typographical errors, unclear descriptions, and so on. For example the zero draft insists Windows usernames are "Unicode" (UCS-2) but actually they're just ASCII, the examples show ASCII encoded hexadecimal but the text in the zero draft specifically calls it Unicode. And originally the document repeatedly says something is a 16-bit value in the text while showing a 24-bit value in structures, the final RFC has corrected this to split out an 8-bit "reserved" all zero field in the structure when this happens. In at least one place the RFC seems to "extend" the protocol compared to the zero draft, but again this isn't a response to Working Group feedback, it's documenting a patch Microsoft shipped in later Windows versions after the zero draft. I don't know how much a WG chair could have usefully interfered here. As I say it's documenting something that already existed, so "fixing" it to document a more secure protocol nobody was using wouldn't help. The IETF's role here was to help people interoperate with Microsoft's solution, your non-Windows OS that can sign-in to a corporate WiFi system with Windows domain servers is enabled by this documentation.

tialaramex 8y ago

Although you're correct that there was a drafting process for MSCHAPv2, the actual protocol it describes had already shipped in Windows. As a result "But this is a bad idea" would not have been a useful contribution to the drafting process, the zero draft describes the exact same protocol, just with different words. Edited to add: The drafting process wasn't worthless, it fixed typographical errors, unclear descriptions, and so on. For example the zero draft insists Windows usernames are "Unicode" (UCS-2) but actually they're just ASCII, the examples show ASCII encoded hexadecimal but the text in the zero draft specifically calls it Unicode. And originally the document repeatedly says something is a 16-bit value in the text while showing a 24-bit value in structures, the final RFC has corrected this to split out an 8-bit "reserved" all zero field in the structure when this happens. In at least one place the RFC seems to "extend" the protocol compared to the zero draft, but again this isn't a response to Working Group feedback, it's documenting a patch Microsoft shipped in later Windows versions after the zero draft. I don't know how much a WG chair could have usefully interfered here. As I say it's documenting something that already existed, so "fixing" it to document a more secure protocol nobody was using wouldn't help. The IETF's role here was to help people interoperate with Microsoft's solution, your non-Windows OS that can sign-in to a corporate WiFi system with Windows domain servers is enabled by this documentation.