Ummmm Bernard please check your calendar, it seems to be 18 days too early. Nice FUD anyway. Avi > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Bernard Aboba > Sent: Thursday, March 13, 2008 6:17 PM > To: ietf@xxxxxxxx > Subject: Re: IETF Last Call on Walled Garden Standard for the Internet > > Re: IETF Last Call on Walled Garden Standard for the Internet > (draft-ietf-hokey-emsk-hierarchy) > > The open nature of the Internet has been a problem for quite > a long time. In addition to the countless problems caused by > allowing users to run applications of their choosing, the > Internet also allows users to access content worldwide, some > of which may not be approved of by local, state or national > governments, warlords, or gangsters. > > The Internet Engineering Task Force (IETF) has further > compounded the problem by creating interoperable standards > for security, which have enabled hosts on the Internet to > protect traffic end-to-end or hop-by-hop. This has not only > harmed vendor profitability by requiring vendors to > interoperate with each other, but by enabling users to take > ownership of their own security without the approval of > operators or governmental authorities, criminal activity, > terrorism, and juvenile delinquincy have flourished. > > While these issues have long been recognized by the U.N. > Working Group on Internet Governance, until recently, the > IETF has shown little interest in solving these problems. > > It is therefore with great pleasure that I have read > draft-ietf-hokey-emsk-hierarchy, which finally offers a > solution to the issues that have bedeviled the Internet. > > How does this document work its magic? As noted in the > Introduction: > > This document defines the EMSK to be used solely for > deriving root keys using the key derivation specified. > The root keys > are meant for specific purposes called usages; a special > usage class > is the domain specific root keys made available to and used within > specific key management domains.... > > Different uses for keys derived from the EMSK have been proposed. > Some examples include hand off across access points in > various mobile > technologies, mobile IP authentication and higher layer application > authentication. > > In other words, this document creates a standard for the use > of EAP in application layer security, enabling operators and > governments to tie the use of applications to link layer > authentication mechanisms under their control. With EAP now > implemented within network interface cards, this gives > operators and governments granular control of what > applications can be run on the Internet. > > Of course, the solution would not be complete by also > allowing vendors or other SDOs to create their own security > solutions without IETF review, while still being able to > claim IETF standards compliance. How is this wonderful > outcome accomplished? > Section 8.1 states: > > Labels within the "ietf.org" organization are assigned based on the > IETF CONSENSUS policy with specification recommended. Labels from > other organizations may be registered with IANA by the person or > organization controlling the domain with an assignment policy of > SPECIFICATION REQUIRED. > > In other words, vendors and SDOs can self-assign labels, > creating their own key hierarchies, without being required to > register with IANA. > > A NOTE TO THE NAYSAYERS > > There are naysayers who will note that the document, by > enabling use of EAP as a universal application layer security > mechanism for the Internet, has exceeded both the HOKEY WG > charter, as well as the RFC 3748 applicability statement. > > These nattering nabobs simply do not get it. Requiring WGs > to stay within their charters is a barbaric practice that > limits creativity and encourages boredom and even hooliganism. > > Some of the architecturally minded IETF participants may also > note that by linking application layer security to the link > layer, the IETF is effectively adding EAP to host > requirements, since applications utilizing the key hierarchy > established in this document will not be able to run on link > layers that do not support EAP > (such as Fibre Channel). In effect, the "waist" of > the Internet has now been moved down into its shoes, which > can, in some circumstances, make it difficult to walk. > > Again, these ivory tower Archi-snobs do not get it. > Do you know how expensive it is to deploy new networking > technologies or to develop a new product? Do you know how > difficult it can be to pay for these things while being > hampered by your whiny notions of interoperability and openness? > > Rather than "IP over everything", the new, improved Walled > Garden Internet is based on "Everything over EAP". > Stop your endless whining and get used to it. > > CODA > > As I noted earlier, by establishing EAP as a universal > application layer security mechanism for the Internet, and by > enabling vendors and SDOs to create their own "usages" > without IETF approval or even publication, this document > establishes a Walled Garden standard for the Internet. > > Such a standard has been particularly assisted by the IETF's > Security Area, which has within a short time taken an > interoperable security mechanism developed for a narrow range > of uses, and turned it into a supremely general, > non-interoperable, non-backwards compatible solution to every > Internet problem, real or imagined. > > To paraphrase Tilda Swinton's Oscar Acceptance Speech: > > "To the IESG, you know, the seriousness and the dedication to > your art... you rock, man!" > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf