Subject: Re: IETF Last Call on Walled Garden Standard for the Internet

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Mar 2008 15:17:01 -0700 (PDT)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Mar 2008 18:56:25 -0400

On Mar 13, 2008, at 6:17 PM, Bernard Aboba wrote:

> 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.

I'm hoping this comment is tongue-in-cheek.

If not, I'd encourage you to review http://www.arcchart.com/blueprint/ 
show.asp?id=428. I'll quote its final paragraph here:

> The culmination of attractive data pricing, improved usability and  
> mobile demand for Web 2.0 services, together with increased  
> availability of 3G devices is brewing to form the prefect data  
> storm – a tipping point where the majority of a subscriber base  
> accesses the data network with regularity. This is something which  
> operators like Vodafone have fought hard to achieve but, while they  
> have deployed the networks and supplied the devices, it is not  
> their walled-gardens or headline-grabbing media partnerships which  
> are causing the data winds to blow. It is the likes of MySpace,  
> Facebook, Google, Flickr, Jaiku, YouTube and Flirtomatic which are  
> seeding the stirring clouds. As data pricing erodes along the same  
> path travelled by voice, operators must now identify ways to tap  
> into revenues from web services or else be left exposed when the  
> data hurricane arrives.
>

In essence, it reviews Vodaphone's semi-annual numeric announcement  
in November, and concludes that the growth of Vodaphone - which is  
very nice, includes a 7% increase in voice revenue, a 9% increase in  
SMS revenue, and 49% growth in data revenue, the vast majority of  
which does not derive from Vodaphone's walled garden. One data point  
is just that - anecdotal evidence. But it points in a direction that  
market research analysts throughout the industry (such as were  
discussed in Marshall Eubank's talk this evening) are also pointing.

Since when are walled garden vendors (like I-Mode, which failed as a  
business last year after delivering one of the most-used walled  
gardens to date) shooting any feet but their own in promoting walled  
gardens?
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2008 19:03:51 -0400

Bernard,

For what it is worth, this ex-EAP co-chair also thinks that the use of
EAP keys for applications is a very bad idea. And I too am concerned
about introducing walled gardens through this.

Having said that, I think there are legitimate uses of EMSK in the area
of network access, such as various fast handover proposals in EAP. My
understanding is that HOKEY is working on this. So perhaps one potential
direction for resolving your issues is to provide a much stricter IANA
section and an applicability note.

I realize that this does not prevent people from grabbing values. But I
note that I know of one case at least where this has already happened,
even without an IETF specification. Arguably the situation with a
(sufficiently tight) spec might be better, because we can use the spec
to explain what usage is inappropriate. I realize we have RFC 3748
already, but since use of EMSK has been an IETF topic for 5+ years, I
think it would be reasonable to state what the final rules are on taking
specific keys out of the EMSK.

Disclaimer: I read the draft very quickly after your note, and have not
done a full review. I will do a very in-depth review when this document
comes to the IESG.

Jari

---

From: Avi Lior <[email-masked]>
Date: Thu, 13 Mar 2008 23:02:48 -0400

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

Nice FUD anyway.

Avi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bernard Aboba
> Sent: Thursday, March 13, 2008 6:17 PM
> To: [email-masked]
> Subject: Re: IETF Last Call on Walled Garden Standard for the Internet
>
> 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,
> Working Group on Internet Governance, until recently, the
> IETF has shown little interest in solving these problems.
>
> draft-ietf-hokey-emsk-hierarchy, which finally offers a
> solution to the issues that have bedeviled the Internet.
>
> 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:
>
> 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
>
> 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
> the Internet has now been moved down into its shoes, which
> can, in some circumstances, make it difficult to walk.
>
> 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".
> 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 the IESG, you know, the seriousness and the dedication to
> your art... you rock, man!"

---

From: Avi Lior <[email-masked]>
Date: Thu, 13 Mar 2008 23:19:43 -0400

> Behalf Of Jari Arkko
> Sent: Thursday, March 13, 2008 7:04 PM
> To: Bernard Aboba
> Cc: [email-masked]
> For what it is worth, this ex-EAP co-chair also thinks that
> the use of EAP keys for applications is a very bad idea.

Why?
> And I too am concerned about introducing walled gardens through this.

Why?

> Having said that, I think there are legitimate uses of EMSK
> in the area of network access, such as various fast handover
> proposals in EAP. My understanding is that HOKEY is working
> on this. So perhaps one potential direction for resolving
> your issues is to provide a much stricter IANA section and an
> applicability note.

Sure based on technical merits not FUD.

> I realize that this does not prevent people from grabbing
> values. But I note that I know of one case at least where
> this has already happened, even without an IETF
> specification. Arguably the situation with a (sufficiently
> tight) spec might be better, because we can use the spec to
> explain what usage is inappropriate.

Why?

> I realize we have RFC
> 3748 already, but since use of EMSK has been an IETF topic
> for 5+ years, I think it would be reasonable to state what
> the final rules are on taking specific keys out of the EMSK.

Sure based on technical merits and not FUD.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Mar 2008 23:49:41 -0400

Avi,

>> the use of EAP keys for applications is a very bad idea.

For a number of reasons. Take this from someone who has actually tried
to do this in the distant past and has realized that it was a bad idea.

But first let me clarify that I'm not criticizing HOKEY for EAP keys in
any way; HOKEY is a fine application for EAP keys. The document that
started this thread can be fixed by better IANA and applicability
sections. I've also changed the subject to reflect the new topic.

Back to the reasons for why application keying based on EAP is a bad
idea. First, there is an applicability statement in RFC 3748 which
discourages the use of EAP for other applications than network access.
We've generally treated this liberally and included things like VPN
access (IKEv2) and mobility services in this as well.

Use of EAP keys in other contexts than the network access itself
presents a number of problems. The primary problem is that while EAP
runs on many, many interfaces and products, the number of networks where
is still relatively small, or at least its nowhere near ubiquitous. This
presents a problem for applications that require EAP-based keys. This
hotel network supports web logins, not EAP so does that mean I would be
unable to use the EAP-based applications? And from the point of view of
an application provider, why would I want to exclude the 99.9% of
current Internet users that are not behind an EAP-based network interface?

The conclusion from this is that application keying should be arranged
independently of network access. Note that in some cases you can use the
same credentials to access a particular application, even if you are not
reusing keys from the network access phase. For instance, IKEv2 and its
EAP capability has been used in some mobility designs. But this is an
independent run of EAP, nothing to do with the network access EAP run
(if there even was one).

Finally, many of the things that you want to do are impossible if you
tie your applications to network access keys. For instance, if you are
mobile you would ideally want to move from one access network to
another. What if one of these access networks does not support EAP for
network access. E.g., Wimax -> 3G? What would this do to your ability to
use an application?

Jari

---

From: Avi Lior <[email-masked]>
Date: Fri, 14 Mar 2008 00:39:53 -0400

See inline....

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, March 13, 2008 11:50 PM
> To: Avi Lior
> Cc: Bernard Aboba; [email-masked]
> Subject: EAP applicability (Was: Re: IETF Last Call on Walled
> Garden Standard for the Internet)
>
> Avi,
>
> >> For what it is worth, this ex-EAP co-chair also thinks
> that the use
> >> of EAP keys for applications is a very bad idea.
> >>
> >
> > Why?
> >
>
> For a number of reasons. Take this from someone who has
> actually tried to do this in the distant past and has
> realized that it was a bad idea.
>
> But first let me clarify that I'm not criticizing HOKEY for
> EAP keys in any way; HOKEY is a fine application for EAP
> keys. The document that started this thread can be fixed by
> better IANA and applicability sections. I've also changed the
> subject to reflect the new topic.
>
> Back to the reasons for why application keying based on EAP
> is a bad idea. First, there is an applicability statement in
> RFC 3748 which discourages the use of EAP for other
> applications than network access.
> We've generally treated this liberally and included things
> like VPN access (IKEv2) and mobility services in this as well.

Okay.  So some applications are okay.  I agree we need to provide guidelines as to the shortcomings.  Let SDOs then decide what is and what is not appropriate for them to do.

The point is that the term 'applications' is rather broad.  There are many types of applications. I may agree that using EMSK to protect all applications may be a problem.  But in certain situations it could solve problems as well.

> Use of EAP keys in other contexts than the network access
> itself presents a number of problems. The primary problem is
> that while EAP runs on many, many interfaces and products,
> the number of networks where is still relatively small, or at
> least its nowhere near ubiquitous. This presents a problem
> for applications that require EAP-based keys. This hotel
> network supports web logins, not EAP so does that mean I
> would be unable to use the EAP-based applications? And from
> the point of view of an application provider, why would I
> want to exclude the 99.9% of current Internet users that are
> not behind an EAP-based network interface?
>
> The conclusion from this is that application keying should be
> arranged independently of network access. Note that in some
> cases you can use the same credentials to access a particular
> application, even if you are not reusing keys from the
> network access phase. For instance, IKEv2 and its EAP
> capability has been used in some mobility designs. But this
> is an independent run of EAP, nothing to do with the network
> access EAP run (if there even was one).
>
> Finally, many of the things that you want to do are
> impossible if you tie your applications to network access
> keys. For instance, if you are mobile you would ideally want
> to move from one access network to another. What if one of
> these access networks does not support EAP for network
> access. E.g., Wimax -> 3G? What would this do to your ability
> to use an application?
>
> Jari
>
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 13 Mar 2008 21:47:31 -0700

> current Internet users that are not behind an EAP-based network interface?

Let us consider the opposite situation.  Let us say the hotel network 
uses EAP for authentication and the hotel front desk gives the IETF 
folks a scratch card with credentials.  We then use the credentials for 
authentication using 802.1X-EAP (example only).  The hotel or an 
associated third party also offers some services/applications and wants 
to provide them for free for the IETF folks.  However the hotel does not 
want to share the credentials with the third party server.  Sure, the 
hotel may not make this facility of key management for all application 
providers out there and this mechanism is not useful for general purpose 
application access.  Why would we force the hotel to provide multiple 
sets of credentials for each additional service/application that they 
want to provide?

Perhaps your argument is to use IKEv2-EAP in that case.  Sure, we can 
use that.  But, why not use the optimization when it is available?  Why 
force IKEv2 again?  Please see below for additional notes.

> independent run of EAP, nothing to do with the network access EAP run

This is an interesting distinction and I would really like to understand 
the logic behind the restriction.

Using key material derived from the EMSK, derived after network access 
authentication using an EAP method for applications is not ok.

However using the MSK from an EAP method run over IKEv2 for applications 
is ok.

Are you saying that a fresh verification of possession of long term 
credentials is necessary for application access?

Or does this have to do with some access technologies not choosing to 
adopt our protocol, EAP and us trying to optimize for those situations? 
  If the latter, why wouldn't we add features to our protocols and 
increase adoption of our protocols?  Or, perhaps we are suggesting that 
other people should not be using EAP and build their own mechanisms.

Please clarify.

> network access. E.g., Wimax -> 3G? What would this do to your ability to

 From what I know Wimax and 3GPP2 use EAP.  3GPP does not.  We should 
optimize for access networks that use our protocols.  When the user does 
roam to a non-EAP capable network, we force them to use IKEv2-EAP and 
they bear the cost of IKEv2 and an EAP method run.

thanks,
Lakshminath

---

From: Theodore Tso <[email-masked]>
Date: Fri, 14 Mar 2008 09:17:08 -0400

> sets of credentials for each additional service/application that they 

OK, let's take this example as a thought experiment.  Where are the
applications going to come from?  In general, getting application
vendors to ship clients which implement any kind of security code has
been like pulling teeth.  We've been mildly successful with TLS/SSL
and in certain very specific cases (i.e., https and mail
applications).  

Something esoteric that only works on networks that happen to provide
EAP keying will be such a small part of the market that getting wide
availability such applications is going to be, um, difficult.  So that
basically means that the hotel is going to have to provide the
applications which use this hotel-specific service.  Training users
that, no really, it's OK to download applications from random hotels
and installing it on their corporate laptops is something which I'm
*sure* the I/T departments will treat with special joy --- and by joy,
I mean fear and loathing.  :-)

Certainly from a corporate perspective, applications which can't work
on home networks (that may not use EAP at all, or in any case, if they
have EAP, are coming from an untrusted home Linksys/D-Link/whatever
"router"), is going to be at all interesting.  And from a security
perspective, would certainly violate the end-to-end principle.

So aside from applications which are very much tied to the local
network --- i.e., network access protocols, maybe as a way of securing
a response from a dhcp server, etc. --- I'm not sure for which
applications an EAP based key would make any sense at all.

	     	    	      	    	     	   - Ted

---

From: Jari Arkko <[email-masked]>
Date: Fri, 14 Mar 2008 11:06:54 -0400

Lakshminath,

> Why would we force the hotel to provide multiple sets of credentials
> for each additional service/application that they want to provide? 

Credentials can still be the same. We're not really arguing against
that. It would indeed be silly if you had to have more credentials. In
some deployments the cost of this would be astronomical. But I note that
the same credentials can often be used. E.g., 802.1X and IKEv2 can use
the same credentials. HTTP digest can use credentials from cellular
networks via RFC 4169. And so on.

> use that.  But, why not use the optimization when it is available? 
> Why force IKEv2 again?  Please see below for additional notes.

The argument is that the optimization provides minor benefits (we're
talking about few roundtrips or even less) and even this can in many
cases be amortized across the whole life of an a connection to a server.

This, taken together with the costs involved in the optimization (tying
yourself to a particular network, limiting deployment, additional
protocol work etc) IMHO makes it very clear that we should avoid using
EAP keys for applications other than those relating to network access.

In any case, I don't think the HOKEY WG is doing applications, they are
working on network access improvements. Why are we even discussing this
topic? I don't see any (active) proposal on the my table that would
suggest doing something like this. Tighten up the language in the hokey
spec to not allow application keying, and we're done.

Jari

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 17 Mar 2008 13:52:02 -0700 (PDT)

Hi Jari,

> sections. I've also changed the subject to reflect the new topic.

  Actually I think it's a little more technical than editorial. This
problem is due to the fact that HOKEY is extracting a key derived from
the EMSK and making that "The Mother Of All Root Keys" (MOARK), which
can be used to derive all keys for all purposes to solve all problems in
the world.

  The document can be fixed by removing the MOARK from the draft and
having HOKEY define a _HOKEY-specific_ key derived from the EMSK. That
HOKEY-specific key is used for HOKEY and HOKEY only. If some other key
usage is needed then it can define another way to extract it's needed
keying material from the EMSK, and hopefully that process would be done
in the IETF (at least the chances are greater that it would be done in
the IETF if it's based on the EMSK and not the MOARK).

  This has the added benefit of simplifying the key hierarchy.

  regards,

  Dan.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Mar 2008 15:58:02 -0700 (PDT)

>   This has the added benefit of simplifying the key hierarchy.

I agree that the MOARK approach should be discarded, since its only use is 
to circumvent the EAP applicability statement in RFC 3748.  HOKEY WG was 
chartered to solve the EAP handoff problem, not to create a new security 
architecture for the Internet based on link layer security. 
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Avi Lior <[email-masked]>
Date: Thu, 20 Mar 2008 10:58:04 -0400

FYI. In WiMAX we derive keys directly from EMSK.  We don't use the MOARKs ;-)

It maybe a good idea or a bad idea -- we haven't had a chance to look at it because we did our stuff before the MOARK was conceived. We did align at one point with Joe's draft.

I am not sure whether defining a MOARK is the root of all evil.  It maybe a good idea to derive keys from it in general or it maybe a good idea for HOAKEY to derive its keys from it.

Simply removing MOARK is not sufficient to prevent the EMSK to be missused.  I think we need to provide the text to describe the pitfalls of EMSK missuse.

Also to note, in WiMAX the keys we derive from EMSK are for MIP and other network centric applications such as over the air provisioning.  I don't want to give the impression that in WiMAX we are using the EMSK for anything and everything.  At the same time, I don't want to give the impression that that is all that WiMAX will use the EMSK for in the future.  To be sure it is very tempting indeed to have a source of keying material that is known at the mobile and at the network.  That is why I look forward to *constructive* instructions from the IETF.

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Monday, March 17, 2008 4:52 PM
> To: Jari Arkko
> Cc: Avi Lior; [email-masked]; Bernard Aboba
> Subject: Re: EAP applicability (Was: Re: IETF Last Call on
> Walled Garden Standard for the Internet)
>
>
>   Hi Jari,
>
> actually tried
> EAP keys
> > in any way; HOKEY is a fine application for EAP keys. The document
> > that started this thread can be fixed by better IANA and
> applicability
>   Actually I think it's a little more technical than
> editorial. This problem is due to the fact that HOKEY is
> extracting a key derived from the EMSK and making that "The
> Mother Of All Root Keys" (MOARK), which can be used to derive
> all keys for all purposes to solve all problems in the world.
>
>   The document can be fixed by removing the MOARK from the
> draft and having HOKEY define a _HOKEY-specific_ key derived
> from the EMSK. That HOKEY-specific key is used for HOKEY and
> HOKEY only. If some other key usage is needed then it can
> define another way to extract it's needed keying material
> from the EMSK, and hopefully that process would be done in
> the IETF (at least the chances are greater that it would be
> done in the IETF if it's based on the EMSK and not the MOARK).
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 20 Mar 2008 08:48:10 -0700 (PDT)

Hi Avi,

  I agree that simply removing the MOARK (aka the DSRK) will not prevent
EMSK misuse but it will remove a large temptation to misuse. The sole
purpose I can see in the DSRK is to get around the fact that we do not
export the EMSK. If there are valid reasons to not export the EMSK then
those reasons apply equally to the DSRK and it should be eliminated. If
there are no valid reasons to not export the EMSK then let's just export
it and then the need for the DSRK goes away. Either way the DSRK should
be eliminated.

  If WiMAX wants constructive instruction from the IETF I suggest it
make a request through the 802.16 liaison to IETF.

  regards,

  Dan.

On Thu, March 20, 2008 7:58 am, Avi Lior wrote:
> It maybe a good idea or a bad idea -- we haven't had a chance to look at
> it because we did our stuff before the MOARK was conceived. We did align
> at one point with Joe's draft.
>
> I am not sure whether defining a MOARK is the root of all evil.  It maybe
> a good idea to derive keys from it in general or it maybe a good idea for
> HOAKEY to derive its keys from it.
>
> Simply removing MOARK is not sufficient to prevent the EMSK to be
> missused.  I think we need to provide the text to describe the pitfalls of
> EMSK missuse.
>
> Also to note, in WiMAX the keys we derive from EMSK are for MIP and other
> network centric applications such as over the air provisioning.  I don't
> want to give the impression that in WiMAX we are using the EMSK for
> anything and everything.  At the same time, I don't want to give the
> impression that that is all that WiMAX will use the EMSK for in the
> future.  To be sure it is very tempting indeed to have a source of keying
> material that is known at the mobile and at the network.  That is why I
> look forward to *constructive* instructions from the IETF.
>
>
>

---

From: Avi Lior <[email-masked]>
Date: Thu, 20 Mar 2008 14:48:55 -0400

Hi Dan,

I am not a MOARK expert nor a HOAKEY expert.  But they way I see it is that HOAKEY may need to export a root key around yet other applications may not.  Those it is a good idea the the real mother of root keys -- EMSK -- remain in the EAP layer so it can be used to derive other keys that can be or may not be exportable.

The notion of doing something to prevent temptation sounds like a religious thing.  SDOs will just derive a key and export it out.

> Sent: Thursday, March 20, 2008 11:48 AM
> To: Avi Lior
> Cc: Dan Harkins; Jari Arkko; [email-masked]; Bernard Aboba
> Subject: RE: EAP applicability (Was: Re: IETF Last Call on
>   I agree that simply removing the MOARK (aka the DSRK) will
> not prevent EMSK misuse but it will remove a large temptation
> to misuse. The sole purpose I can see in the DSRK is to get
> around the fact that we do not export the EMSK. If there are
> valid reasons to not export the EMSK then those reasons apply
> equally to the DSRK and it should be eliminated. If there are
> no valid reasons to not export the EMSK then let's just
> export it and then the need for the DSRK goes away. Either
> way the DSRK should be eliminated.
>
>   If WiMAX wants constructive instruction from the IETF I
> suggest it make a request through the 802.16 liaison to IETF.
>
>   regards,
>
>   Dan.
>
> > FYI. In WiMAX we derive keys directly from EMSK.  We don't use the
> > MOARKs
> > ;-)
> >
> > It maybe a good idea or a bad idea -- we haven't had a
> chance to look
> > at it because we did our stuff before the MOARK was
> conceived. We did
> > align at one point with Joe's draft.
> >
> > I am not sure whether defining a MOARK is the root of all evil.  It
> > maybe a good idea to derive keys from it in general or it
> maybe a good
> > idea for HOAKEY to derive its keys from it.
> >
> > missused.  I think we need to provide the text to describe the
> > pitfalls of EMSK missuse.
> >
> > Also to note, in WiMAX the keys we derive from EMSK are for MIP and
> > other network centric applications such as over the air
> provisioning.
> > I don't want to give the impression that in WiMAX we are using the
> > EMSK for anything and everything.  At the same time, I
> don't want to
> > give the impression that that is all that WiMAX will use
> the EMSK for
> > in the future.  To be sure it is very tempting indeed to
> have a source
> > of keying material that is known at the mobile and at the network.
> > That is why I look forward to *constructive* instructions
> from the IETF.
> >
> >
> >
> >> Subject: Re: EAP applicability (Was: Re: IETF Last Call on Walled
> editorial. This
> >> problem is due to the fact that HOKEY is extracting a key derived
> >> from the EMSK and making that "The Mother Of All Root
> Keys" (MOARK),
> >> which can be used to derive all keys for all purposes to solve all
> >> problems in the world.
> >>
> draft and
> >> having HOKEY define a _HOKEY-specific_ key derived from the EMSK.
> >> That HOKEY-specific key is used for HOKEY and HOKEY only. If some
> >> other key usage is needed then it can define another way
> to extract
> >> it's needed keying material from the EMSK, and hopefully
> that process
> >> would be done in the IETF (at least the chances are
> greater that it
> >> would be done in the IETF if it's based on the EMSK and not the
> >> MOARK).
> >>