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

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Mar 2008 16:30:55 -0700 (PDT)

Jari Arkko said:

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

Thanks Jari.  I have no objection to any use of the EMSK relating to
link layer handoff, or even to IP layer things that might be somewhat 
related (e.g. Mobile IP).  But utilizing EAP as an application layer
security mechanism does seem inappropriate. 

In terms of how to fix this within the document, I have no good ideas at 
the moment.  The derivation of new keys via labels brings with it an 
extraordinary degree of flexibility which seems like it would be very
difficult to control.  

The issue may not be so much about trying to stop this (which is probably 
impossible), but to somehow make it clear that these usages are considered 
a bad idea by the IETF, so that customers and users cannot be confused by 
vendors claiming compliance to an IETF standard.  Also, I think it is a 
bad idea to allow SDOs to create their own usages without at least 
undergoing IETF review.  Again, we cannot stop them from doing that, but 
at least we can set expectations. 
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Fri, 14 Mar 2008 14:44:39 +0200

Bernard Aboba wrote:

> I have no objection to any use of the EMSK relating to link layer
> handoff, or even to IP layer things that might be somewhat related
> (e.g. Mobile IP).  But utilizing EAP as an application layer

There are two fundamentally different ways you could use EAP as 
an application layer security mechanism, and I think it's
important to make a distinction between them.

First, you could embed EAP payloads in the application protocol
itself. There have been proposals for adding EAP authentication to,
e.g., TLS and HTTP this way.  This isn't a totally horrible idea from
architectural point of view; however, certain properties of EAP make
it problematic to use this way (e.g., without channel bindings, EAP 
would not authenticate the identity of the TLS/HTTP server, only some 
backend AAA server). You don't need draft-ietf-hokey-emsk-hierarchy 
for this way of using EAP.

Second, you could run EAP in the link layer, and use
draft-ietf-hokey-emsk-hierarchy to derive additional keys that 
get distributed to application endpoints and used there. I think 
this is what the emsk-hierarchy draft means when it talks about 
using keys for "higher layer application authentication", and 
I guess you were primarily concerned about this case.

Here I agree with you fully: this is an extremely bad idea.
Architecturally linking application security to the link layer is 
just bad engineering, and hinders the ability of link layers and
applications evolve independently of each other. 

The emsk-hierarchy document should not give higher layer
applications as an example use case; instead, it should explain why 
this is a bad idea, and recommend that keys derived from link layer
authentication should be used solely for "link-layerish" things (such 
as link layer handoffs; Mobile IP is a borderline case here).

Best regards,
Pasi

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 14 Mar 2008 08:11:41 -0700

> applications evolve independently of each other. 

I look at this from the perspective of alternatives.  The alternative is 
to require additional configuration of keys for applications, which to 
say in simple terms, is not simple!  The other alternative is to require 
something like IKEv2-EAP, which of course relies on the same credentials 
as EAP originally would have.

The TSK is the link layer key; the EMSK is a temporary key generated 
after verification of EAP method credentials.  So, I am not sure I 
understand the references to bad engineering.

Could you also explain how enabling key management for applications in 
one context hinders the ability of link layers and applications evolving 
independently?  Is this an instance of the 'good' being an enemy of 
'perfect' argument?

> as link layer handoffs; Mobile IP is a borderline case here).

Glad we agree that we can use this for mobile IP.

If someone could explain to me why this is bad in concrete terms that 
would be useful.  If we want to engage in a debate on what might break 
some of the principles we fondly state but do not quite follow, I am 
happy to engage in that debate.  That would be about applying the 
"rules" consistently and not arbitrarily.

regards,
Lakshminath

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Mar 2008 11:16:21 +1300

> On 3/14/2008 5:44 AM, [email-masked] wrote:

...
> say in simple terms, is not simple!  

I don't think anbody said it was simple. Surely the underlying point
is that the trust model for application keying has absolutely nothing
to do with the trust model for network access. So I can't see any
reasonable scenarios where we mix the two together, except scenarios
where the network provider is a monopolist that is also providing
exclusive application services. And even that wouldn't work if
the provider was *also* trying to provide secure services for
users who were not its network-level customers. In the general
case, where the user has separate trust relationships with the
network service provider and with the application service provider,
and there is no trust relationship between the two providers,
there's no way to use a shared mechanism.

> The other alternative is to require 

By tempting application service providers to believe they can
piggy-back on lower layer keying, you actually make things worse -
either they will have to support two mechanisms, or they will have
no mechanism available for customers who don't happen to be using
lower layer keying.

I think Jari's suggestion is the right one. Make it clear in the
draft that this is not suitable as a universal mechanism for
apps.

   Brian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 17 Mar 2008 15:53:33 -0700

As much fun as I've had in catching up with this thread, I'd like to
remind all of us that we, at the IETF, do not dictate the way systems
get built in the real world.  There are SDOs that have gone ahead and
defined their own hierarchies out of the MSK and EMSK for various usages
at higher layers.  And, I use the term "usage" here, since "application"
seems unclear in terms of layering - for the purposes of this document,
"application" refers to anything that may be able to use EAP keying
material and not literally Layer 7. 

Having said that, I find it interesting that some people here find it
okay for Mobile IP to use EAP keying material, but not other
applications.  I have to deduce that this is because the term
"applications" to many of us reminds us of real applications, rather
than applications of the keying material.  I don't see why the argument
that using EAP-based keying material for applications would hinder them
running over non-EAP capable interfaces would not apply to Mobile IP.
Mobile IP is as much decoupled from a specific interface as any
application is - so, does that mean it is okay to not be able to provide
mobility across non-EAP capable interfaces using Mobile IP?  That would
certainly defeat the purpose of the protocol!  Not to say that Mobile IP
is THE solution to mobility, but let's save that discussion for another
day. 

All said and done, here is what it boils down to - any application of
EAP keying material to other services (using the term here to include
things ranging from handoffs to mobility to L7 applications) is only
feasible when those services are provided either by or through the
provider handling network access.  It is also only feasible when those
services are only running over EAP-capable interfaces (well, without
horrible abominations, anyway). So, if a network access provider
requiring EAP is rolling out applications, I don't see a good reason why
the application cannot use keys coming out of the EMSK.  

Our role at the IETF should be in defining the applicability of using
such key material such that readers understand that this does not work
when the application provider is independent of the network access
provider or when the application runs over interfaces that do not do
EAP.  And, I believe our role ends there.  

Jari wrote "Tighten up the language in the hokey spec to not allow
application keying, and we're done" and I don't believe we are.  We can
do that and just sit back and watch non-compliant key hierarchies
propping up everywhere (and worry about interoperating with those when
we write our next spec) or  do the responsible thing, which would be to
clearly define the applicability, along with providing an interoperable
means of defining the key hierarchy for those usages that want to/can
use it. 

Vidya

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 18 Mar 2008 03:23:32 +0100

> the application cannot use keys coming out of the EMSK.  
The counterargument is, of course, that such coupling will put the 
network access provider into a privilleged position wrt providing those 
applications on his networks; in particular, any competitor wanting to 
deliver those same services (think Internet telephony/Skype or 
video-on-demand/YouTube) will have to roll out his own 
authentication/authorization infrastrucure, and get users to adopt it in 
addition to the one they already have - OR to beg permission from the 
network owner to leverage his infrastructure.

This violates the principle of "network neutrality"; you could easily 
argue that this is a battle that should be fought in the courts of 
public opinion and the US legislature, not in the standards 
organizations, but traditionally, the IETF's participants has had strong 
opinions on this matter.
> EAP.  And, I believe our role ends there.  
I believe I agree with this statement, mostly.
> means of defining the key hierarchy for those usages that want to/can
If usages exist that we find reasonable at all (that is, if we define 
ANY extensible hierarchy), I think experience shows that we'll have 
trouble achieving control by restricting the registration procedure - 
the early years of MIME is the poster child for that.

While I have my doubts as to how much effect we have on the world by 
explaining why a particular thing is stupid/wrong/offensive/immoral, I 
have even more doubts about the effect of restricting registration as a 
controlling tool.

The anecdote I'm reminded of is one from the Norwegian army, just before 
the German invasion of 1940....

Senior Officer: "And if the country is invaded, Lieutenant, how would 
you prevent the enemy from using the railroad system to move troops?"
Junior Officer: "Burn all the tickets, SIR!"

                     Harald

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 17 Mar 2008 19:57:52 -0700

> organizations, but traditionally, the IETF's participants has had strong 

Fair enough.  Although, we already facilitate this with EAP over IKEv2. 
  The new stuff is just optimization, as Jari noted.  The contention, at 
least between him and me is whether the optimization is needed or not.

> Junior Officer: "Burn all the tickets, SIR!"

Funny! :)  Applicability statements and strong applicability statements 
come to mind!

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 17 Mar 2008 21:39:04 -0700

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Monday, March 17, 2008 7:58 PM
> To: Harald Tveit Alvestrand
> Cc: Narayanan, Vidya; [email-masked]
> Subject: Re: IETF Last Call on Walled Garden Standard for the Internet
> 
> >> provider handling network access.  It is also only feasible when 
> >> those services are only running over EAP-capable interfaces (well, 
> >> without horrible abominations, anyway). So, if a network access 
> >> provider requiring EAP is rolling out applications, I don't see a 
> >> good reason why the application cannot use keys coming out 
> of the EMSK.
> >>   
> > network access provider into a privilleged position wrt providing 
> > those applications on his networks; in particular, any competitor 
> > wanting to deliver those same services (think Internet 
> telephony/Skype 
> > or
> > authentication/authorization infrastrucure, and get users 
> to adopt it 
> > in addition to the one they already have - OR to beg 
> permission from 
> > the network owner to leverage his infrastructure.
> > 
> > organizations, but traditionally, the IETF's participants has had 
> > strong opinions on this matter.
> 
>   The new stuff is just optimization, as Jari noted.  The 
> contention, at least between him and me is whether the 
> optimization is needed or not.
> 

Jari also noted that such providers should be able to reuse the same
credentials in EAP and the application; just that the key hierarchies
should not have any inter-dependencies.  This essentially gives the same
level of control to the provider with respect to the applications as
Harald notes, just doesn't allow the optimizations to happen.  This
seems like a false level of separation that we think we may achieve by
maintaining an imaginary protocol boundary at the IETF.  

Recognizing that credential provisioning is an issue is a good step that
in my mind by itself warrants this EMSK-based key hierarchy for
meaningful usages.  In fact, I'd argue that credential reuse by multiple
protocols is a bad idea - we would be trading off cryptographically
coordinated key derivations for a mechanism that has no control over
disparate usages of the credentials with different algorithms and so on.

In fact, credential provisioning issues (and avoiding credential reuse)
is a far more compelling reason to allow the EAP-based keying hierarchy
for layers above than the optimizations itself.  Of course, the
optimizations are much needed in some cases, but, that is not the sole
reason. 

- Vidya

> >> such key material such that readers understand that this does not 
> >> work when the application provider is independent of the network 
> >> access provider or when the application runs over 
> interfaces that do 
> >> not do EAP.  And, I believe our role ends there.
> >>   
> >> application keying, and we're done" and I don't believe we 
> are.  We 
> >> can do that and just sit back and watch non-compliant key 
> hierarchies 
> >> propping up everywhere (and worry about interoperating with those 
> >> when we write our next spec) or  do the responsible thing, which 
> >> would be to clearly define the applicability, along with 
> providing an 
> >> interoperable means of defining the key hierarchy for those usages 
> >> that want to/can use it.
> > have even more doubts about the effect of restricting 
> registration as 
> > a controlling tool.
> > 
> > The anecdote I'm reminded of is one from the Norwegian army, just 
> > before the German invasion of 1940....
> > 
> Funny! :)  Applicability statements and strong applicability 
> statements come to mind!
> 
> regards,
> Lakshminath
> > 
> >                      Harald
> > 
> >

---

From: Avi Lior <[email-masked]>
Date: Tue, 18 Mar 2008 18:10:07 -0400

Pasi wrote:

> Architecturally linking application security to the link
> layer is just bad engineering, and hinders the ability of
> link layers and applications evolve independently of each other.

Lets start with this: Any application?

> applications as an example use case; instead, it should
> explain why this is a bad idea, and recommend that keys
> derived from link layer authentication should be used solely
> for "link-layerish" things (such as link layer handoffs;
> Mobile IP is a borderline case here).

Mobile IP is an application.  So I guess you are okay with some applications right?

---

From: Avi Lior <[email-masked]>
Date: Tue, 18 Mar 2008 18:13:57 -0400

Brian wrote:

> I think Jari's suggestion is the right one. Make it clear in
> the draft that this is not suitable as a universal mechanism for apps.

Jari's suggestion is too broad.  Since it is hard to classify applications.  And as we can see there are some class of applications that this is okay for.

I suggest we discuss the issues with deriving keys from EMSK so that people can make informed decisions.  Lets keep the FUD factor low.

Avi

---

From: Avi Lior <[email-masked]>
Date: Tue, 18 Mar 2008 18:16:01 -0400

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Narayanan, Vidya
> Sent: Monday, March 17, 2008 6:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: IETF Last Call on Walled Garden Standard for the Internet
>
>
> As much fun as I've had in catching up with this thread, I'd
> like to remind all of us that we, at the IETF, do not dictate
> the way systems get built in the real world.  There are SDOs
> that have gone ahead and defined their own hierarchies out of
> the MSK and EMSK for various usages at higher layers.  And, I
> use the term "usage" here, since "application"
> seems unclear in terms of layering - for the purposes of this
> document, "application" refers to anything that may be able
> to use EAP keying material and not literally Layer 7.

Right.

>
> Having said that, I find it interesting that some people here
> find it okay for Mobile IP to use EAP keying material, but
> not other applications.  I have to deduce that this is
> because the term "applications" to many of us reminds us of
> real applications, rather than applications of the keying
> material.  I don't see why the argument that using EAP-based
> keying material for applications would hinder them running
> over non-EAP capable interfaces would not apply to Mobile IP.
> Mobile IP is as much decoupled from a specific interface as
> any application is - so, does that mean it is okay to not be
> able to provide mobility across non-EAP capable interfaces
> using Mobile IP?  That would certainly defeat the purpose of
> the protocol!  Not to say that Mobile IP is THE solution to
> mobility, but let's save that discussion for another day.

Right.

>
> All said and done, here is what it boils down to - any
> application of EAP keying material to other services (using
> the term here to include things ranging from handoffs to
> mobility to L7 applications) is only feasible when those
> services are provided either by or through the provider
> handling network access.  It is also only feasible when those
> services are only running over EAP-capable interfaces (well,
> without horrible abominations, anyway). So, if a network
> access provider requiring EAP is rolling out applications, I
> don't see a good reason why the application cannot use keys
> coming out of the EMSK.

Exactly.

>
> Our role at the IETF should be in defining the applicability
> of using such key material such that readers understand that
> this does not work when the application provider is
> independent of the network access provider or when the
> application runs over interfaces that do not do EAP.  And, I
> believe our role ends there.

Exactly.

>
> Jari wrote "Tighten up the language in the hokey spec to not
> allow application keying, and we're done" and I don't believe
> we are.  We can do that and just sit back and watch
> non-compliant key hierarchies propping up everywhere (and
> worry about interoperating with those when we write our next
> spec) or  do the responsible thing, which would be to clearly
> define the applicability, along with providing an
> interoperable means of defining the key hierarchy for those
> usages that want to/can use it.

Exactly.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 18 Mar 2008 18:22:57 -0700 (PDT)

Hi Avi,

On Tue, March 18, 2008 3:13 pm, Avi Lior wrote:
[snip]
> I suggest we discuss the issues with deriving keys from EMSK so that
> people can make informed decisions.  Lets keep the FUD factor low.

  Good idea. Can we start with the Mother Of All Root Keys (MOARK) that
is derived from the EMSK? This seems like a particularly un-scope-able
and undefined key. It is not needed for Handover Keying; all HOKEY needed
to do was define a HOKEY-specific key from the EMSK but it didn't, it
defined a MOARK, and then a HOKEY-specific key is being derived from the
MOARK.

  Since the MOARK is really the only key being derived from the EMSK
I guess this makes for a nicely constrained discussion.

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Mar 2008 09:31:03 -0400

I think Vidya has a good point.

My opinion is that, bootstrapping protocols from long-term credentials
used for network access authentication is not such a bad idea, but we
just do not know yet the best way to realize it:

http://user.informatik.uni-goettingen.de/~mobiarch/2007/slides/mobiarch07-panel-YoshiroOhba.pdf

Yoshihiro Ohba

On Mon, Mar 17, 2008 at 09:39:04PM -0700, Narayanan, Vidya wrote:
> > application of

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Mar 2008 09:45:47 -0700 (PDT)

Hello,

  My apologies for being obtuse. This Mother of All Root Keys I've been
describing is what the EMSK Key Hierarchy calls the DSRK.

  The "HOKEY key" that the ERP/ERX draft uses can be derived in one of
two ways:

    EMSK
      |
    USRK    <-- the "HOKEY key", aka rRK

or like this:

    EMSK
      |
    DSRK    <--- the MOARK
      |
   DSUSRK   <-- the "HOKEY key", aka rRK

This latter derivation is the one that will be used in practice, I believe.

  This DSRK is not properly defined and cannot be properly scoped. It
really has nothing to do with "Handover Keying" which is what HOKEY is
supposed to be working on. I believe the DSRK is problematic and the
ability to derive a DSRK should be removed from the ESMK key hierarchy
draft and the corresponding change be made to the ERP/ERX draft to remove
reference to using a DSRK to derive HOKEY keys.

  This change would also simplify the key hierarchy and remove a
"you can do it this way, or you can do it that way" option which
experience has shown is a really bad idea.

  regards,

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 19 Mar 2008 09:53:58 -0700

The DSRK can be scoped just as the EMSK can be scoped.

regards,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Mar 2008 10:55:45 -0700 (PDT)

> The DSRK can be scoped just as the EMSK can be scoped.

  Really? Is there any context that it can be bound to?

  Furthermore, what is the _purpose_ of this key? Why would someone choose
to derive a DSRK or choose not to derive a DSRK for some particular
hierarchy? If it's just a "some like coke while others like pepsi" kind
of argument then that's just more reason to get rid of it. Experience
from the glamor ciphers and hash algorithms in IKE shows that such
pointless options really have a deleterious affect on the standard.

  regards,

  Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Mar 2008 11:33:26 -0400

I agree with removing DSRK.  Let me explain one of Dan's points in a
different way.

The domain in DSRK is defined for key management domain for HOKEY, and
ERX is the only usage defined for HOKEY.  It would be very hard to
justify deriving child keys from DSRK for usages other than HOKEY,
given this situation.

Yoshihiro Ohba

On Wed, Mar 19, 2008 at 09:45:47AM -0700, Dan Harkins wrote:
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
>

---

From: <[email-masked]>
Date: Tue, 25 Mar 2008 10:04:00 +0200

Yoshihiro Ohba wrote:

> My opinion is that, bootstrapping protocols from long-term
> credentials used for network access authentication is not such a bad
> idea, but we just do not know yet the best way to realize it:
> 

Such bootstrapping or "single sign-on" protocol could (and IMHO
should) still be independent of the link it's run over (i.e., it 
would work over any IP network).

BTW, 3GPP and 3GPP2 already have one such a "single sign-on" protocol,
which uses the same long-term credential you'd usually use for network
access authentication to set up short-term "security assocations" for
higher layer protocols (but it runs over any IP network, so it works
even if, e.g., your current access network did not require any
authentication). It's called "Generic Bootstrapping Architecture" 
or GBA.

(GBA design also allows adding new types of credentials between the 
client and the "key distribution center" (BSF) without impacting other 
elements of the system. You could, e.g., add support for EAP here in a 
way that would be independent of the link layer currently being used.
So far, 3GPP/3GPP2 have not needed this, but if GBA ends up being used
in other systems as well, it could be useful.)

Best regards,
Pasi

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 25 Mar 2008 07:48:41 -0400

Hi Pasi,

Thanks for your response.

> would work over any IP network).

I agree that a "single sign-on" protocol should work over any IP
network.

> authentication). It's called "Generic Bootstrapping Architecture" 

Yes, I know GBA.  My understanding is that GBA is based on AKA, but
your comment below seems to indicate that GBA has extensibility, which
is good.

> in other systems as well, it could be useful.)

This is quite interesting.  On the other hand, I believe that
bootstrapping applications is not just key creation - an additional
ground work would be needed for secure key distribution to make GBA or
any other potential "single sign-on" approaches to be truely
access-technology independent.

(BTW, as you may know, HOKEY WG is now discussing removal of peer
consent property from DSRK (or rRK) distribution under the name of
optimization and simplicity, but from security perspective, it is just
a retrograde step against future direction, IMO.)

Kind Regards,
Yoshihiro Ohba

---

From: <[email-masked]>
Date: Tue, 25 Mar 2008 09:49:34 +0200

> Lets start with this: Any application?

Well, at least applications which are not inherently (*) tied to 
a specific access network.

In other words: if it simply doesn't make any sense to use the
"application" from a different link or access network, then tying 
it to the link layer authentication might be one feasible option.
Otherwise, it's a bad idea.

(*) Inherently: by their nature -- and not e.g. just by current
business structures (which are likely to change due to mergers,
acquisitions, divestiture, etc.) or SDO boundaries (both users, 
access providers, and service providers are, over the time, likely 
to be interested in network access technologies from multiple SDOs).

> Mobile IP is an application.  So I guess you are okay with 

Someone mentioned DHCP as one "application" which is inherently
tied to a specific access network/link. 

If you want to use Mobile IP to provide mobility only within a single
access network -- and assume that neither you nor your customers will
ever be interested in other access technologies in the future (or
that mobility to e.g., IETF WLAN is either unimportant, or handled by 
some other mechanisms), then you could tie Mobile IP and link layer 
authentication. Otherwise, I'd recommend making it access independent.

Best regards,
Pasi

---

From: Avi Lior <[email-masked]>
Date: Tue, 25 Mar 2008 11:36:27 -0400

Hi Pasi,

I don't disagree.

We need to make recommendations along your thoughts and let SDOs and operators decide how to implement their networks.

By the way, a single-sign-on network is also a walled garden right? The walled garden is between the parties that aggregate around the identity service provider.  I am thinking Passport (especially), I am thinking Liberity Alliance,  I am thinking Open-ID.

In that vain it is also worthwhile to note that an operator may choose to bootstrap secruity associations from EMSK between a MN accessing its network and third pary Application Service Providers who have a relationship with the Operator.  In such a relationship the MN does not have to reauthenticate with the Application Service Providers.  This is an example of a single sign on.

The only way to elliminate any walled gardens is to have the mobile have its own relationship with each application provider.  This has advanatages and also disadvantages.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2008 3:50 AM
> To: Avi Lior; [email-masked]; [email-masked]
> Well, at least applications which are not inherently (*) tied
> to a specific access network.
>
> In other words: if it simply doesn't make any sense to use
> the "application" from a different link or access network,
> then tying it to the link layer authentication might be one
> feasible option.
> (*) Inherently: by their nature -- and not e.g. just by
> current business structures (which are likely to change due
> to mergers, acquisitions, divestiture, etc.) or SDO
> boundaries (both users, access providers, and service
> providers are, over the time, likely to be interested in
> network access technologies from multiple SDOs).
>
> explain why
> > > authentication should be used solely for "link-layerish" things
> > > (such as link layer handoffs; Mobile IP is a borderline
> case here).
> >
> Someone mentioned DHCP as one "application" which is
> inherently tied to a specific access network/link.
>
> If you want to use Mobile IP to provide mobility only within
> a single access network -- and assume that neither you nor
> your customers will ever be interested in other access
> technologies in the future (or that mobility to e.g., IETF
> WLAN is either unimportant, or handled by some other
> mechanisms), then you could tie Mobile IP and link layer