Avi Lior 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.
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).
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).
Mobile IP is an application. So I guess you are okay with
some applications right?
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.
IETF mailing list