On 2/10/16 9:00 PM, Alan DeKok wrote: > I think most people aren't aware of the history of AAA protocols in > the iETF. This message summarizes relevant documents in the area, > and makes an appeal to the WG to remove the document as a WG > document. > > RADIUS was standardized in 2000 in RFC 2058, after years of WG > discussion. The original protocol goes back to 1993, unlike the > TACACS+ draft, which was submitted in 1997. > > Diameter was standardized in 2003 in RFC 3588, again after years of > WG discussion. TACACS+ was never considered by the IETF as an AAA > protocol. > > The IETF created a process to specify requirements for AAA protocols. > This process is documented in RFC 2989 [1] (2000), which had about 20 > authors from all major networking companies at the time. It > solicited submissions, and established a panel to evaluate the > submissions. The results are documented inRFC 3127 [2] (2003). > TACACS+ was not even considered, as it did not meet the requirements > set out in RFC 2989. > > What is happening here is that a single WG is re-visiting a > multi-year process which involved dozens of experts in the area. A > process which established IETF consensus. A process which was > started almost two decades ago, and finished 13 years ago. > > While RFC 2989 and RFC 3127 are "informational", they are only > informational because they do not document a protocol design. They > do, however, document IETF consensus. > > Standardizing a new AAA protocol without IETF-wide discussion means > we're ignoring the requirements of RFC 2989, and discarding the > results shown in RFC 3127. > > Standardizing TACACS+ is like a single WG standardizing IPv8 on it's > own, after decades of work on IPv6, without achieving wider IETF > consensus, or even updating the WG charter. It's one WG doing a > complete end-run around IETF consensus. > > The document draft-ietf-opsawg-tacacs-00.txt *explicitly* describes > itself as an AAA protocol in it's abstract. Despite the authors > stating it is for "device administration", that phrase *does not > appear in the document*. Despite claims that it is not an AAA > protocol, the document itself claims TACACS+ is an AAA protocol. The > document discusses user authentication, authorization, and > accounting, in a manner which overlaps 100% with RADIUS. > > In fact, RADIUS has more capability than TACACS+. RADIUS is > standardized to transport many more attributes which describe > hundreds of possible pieces of information. The TACACS+ document > documents little more than the base protocol, and a less than 30 > kinds of information it can transport. > > The TACACS+ functionality therefore *explicitly* overlaps 100% with > RADIUS. It is explicitly *not* "device authorization". It is > uniformly inferior to RADIUS in functionality and capability. It > meets none of the requirements set out in RFC 2989, and wasn't even > considered in RFC 3127. > > The only *technical* capability that TACACS+ has which RADIUS doesn't > is "device administration". Perhaps what is meant here is "command > authorization", in which individual administrator commands are > authorized via the AAA protocol. However, this capability is *not* > documented in the draft, which means that any "device administration" > remains a proprietary vendor extension, and entirely outside of the > control of the IETF. > > > The document overturns nearly two decades of IETF consensus. It > competes directly with an established IETF protocol. It's > functionality is explicitly inferior to RADIUS. It's suggested > use-case is entirely undocumented in the draft. > > Therefore, I ask the WG, chairs, and AD, to withdraw this document as > a WG item. It is entirely inappropriate for a standards track > document.
Ok, we operate under the order of precidence in 2026: https://tools.ietf.org/html/rfc2026#section-6.5 I expect that prior to intercession on my part that an appeal will commence with the chairs considering the appeal. thanks joel > > > [1] https://tools.ietf.org/html/rfc2989 > > [2] https://tools.ietf.org/html/rfc3127 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
