RE: IETF Last Call on Walled Garden Standard for the Internet

Ummmm Bernard please check your calendar, it seems to be 18 days too early.

Nice FUD anyway.

Avi

> -----Original Message-----
> From: ietf-bounces(_at_)ietf(_dot_)org 
> [mailto:ietf-bounces(_at_)ietf(_dot_)org] On
> Behalf Of Bernard Aboba
> Sent: Thursday, March 13, 2008 6:17 PM
> To: ietf(_at_)ietf(_dot_)org
> 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(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf