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.
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.
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
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf