[Top] [All Lists]

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

2008-03-16 15:16:59

On 2008-03-15 04:11, Lakshminath Dondeti wrote:
On 3/14/2008 5:44 AM, Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:

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. 

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!  

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

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


IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>