Comments below.
Date: Sun, 10 Feb 2008 22:24:58 -0500
From: clancy(_at_)cs(_dot_)umd(_dot_)edu
To: bernard_aboba(_at_)hotmail(_dot_)com
CC: ietf(_at_)ietf(_dot_)org; hokey(_at_)ietf(_dot_)org;
tim(_dot_)polk(_at_)nist(_dot_)gov
Subject: Re: Last Call: draft-ietf-hokey-reauth-ps (Handover Key Management
and Re-authentication Problem Sta
Bernard,
Thanks for the review. Most of your comments were addressed in the
recently submitted v08.
http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-08.txt
Some specific comments:
> Furthermore, these solutions do not deal with scenarios
> involving handovers to new authenticators, or do not conform
> to the AAA keying requirements specified in [RFC4962].
>
> [BA] Doesn't IEEE 802.11r deal with scenarios involving
> handovers to new authenticators?
My understanding of 11r was the R0KH was the authenticator, since
it's the only one that interacts with AAA. The R1KH never
interacts with AAA or the EAP server, so I don't see how it can
be called an authenticator.
[BA] The R0KH was the original authenticator. However, 11r
enables fast handoff to any R1KH that is within the Mobility Domain.
A Mobility Domain can encompass multiple R0KHs.
Also the 11r definition of "fast handoff" between authenticators is
< 50 ms, even with "break before make". The data I have seen
seems to indicate that 11r can meet this metric for inter-authenticator
handoff (assuming "push" mode).
> Under the existing model, any re-authentication requires a
> full EAP exchange with the EAP server in its home domain
> [RFC3748].
> [BA] Couldn't a local server terminate an EAP-TLS exchange
> without forwarding to the home domain? I believe that WiMAX
> takes advantage of this.
I can imagine authentication working okay, but what about
authorization? How does the local server know if the client is
authorized?
[BA] In WiMAX, authorization is determined from the device
certificate. If the device certificate chains to the WiMAX Forum
CA, then it is allowed network entry, after which provisioning
can occur. Since an unprovisioned device has no "home server",
there is really no other way that this can work.
For re-authentication there is also a need to sync up key state.
There's no way a client could re-authenticate to a server to
which it didn't initially authenticate, because the key cache
wouldn't be there.
> [BA] Question: Are you saying that it is ok to require changes
> on the peer, authenticator and server, as well as at the link
> layer? Would a solution that involves changes to fewer
> elements (e.g. peer + server or peer + authenticator + link
> layer) be more desirable?
The primary goal is to speed things up. Cut a mandatory 2RT to
1RT.
[BA] While reducing round-trips certainly can't hurt, one thing that
we've learned from handoff testing is that any protocol conversation
involving an EAP peer and AAA server/proxy (no matter now close by) involves
certain latencies just from EAP translation/forwarding and AAA protocol
parsing. These latencies are not insignificant.
Therefore "cutting a RT" may not necessarily enable an EAP-based
fast-reauth solution to compete with pure link-layer solutions in
terms of handoff latency.
However, that wouldn't necessarily be a disqualifying factor --
if the solution had major advantages in simplicity or ease of
deployment.
Beyond that, certainly minimizing impact to the lower layer
is important, but in order to achieve the primary goal, it's
impossible to completely avoid impacting the lower layers.
[BA] It would seem to me that the major benefit of an
EAP-based fast re-auth solution would be the ability to
function on existing EAP lower layers without modification,
enabling solutions to both the intra and inter-media handoff
problems within a single approach.
The need for this was understood fairly early on; as I recall,
some of the early EAP fast-reauth proposals involved no changes
to EAP at all, so that they could function on all existing EAP
lower layers without changes to authenticators.
After all, several EAP lower layers already offer their own
fast handoff solutions which require lower layer
modifications (and authenticator upgrades). Given that these
solutions involve link layer conversations solely between the peer and
authenticator, and do not involve IP-based AAA transport,
they will typically have an inherent performance advantage over an
EAP-based fast-reauth solution.
However, the problem is that link-specific solutions will typically
require authenticator upgrades. While it would probably be
possible for the new link layer functionality to be delivered via a firmware
upgrade, in reality modifications of this magnitude are typically
only delivered on the latest code tree, which usually means that
an authenticator upgrade is necessary. In addition to the cost
of purchasing the new equipment, there is the cost of installing
it. All this can add up to millions of dollars on a single campus.
Given the expense and difficulty of those upgrades, the ability to
avoid them would make an EAP-based fast-reauth solution quite
attractive from a financial standpoint, even if the solution were
somewhat inferior in performance to solutions which required
link layer (and authenticator) changes. "Good enough" and
"inexpensive" will often win out over "perfect" and "costly".
However, if you are saying that link layer changes are unavoidable, then
the major benefit vanishes, and in addition you are left with some
major procedural and deployment issues:
a. Since the lower layers that need to change are not under the control of
the IETF, deployment of an intra-media solution will depend on changes to link
layer specifications owned by other SDOs. This could take years, if it
happens at all.
b. Since the value of an inter-media handoff solution grows with the
square of the number of lower layers that support it, the requirement
for link layer changes dramatically reduces the utility of an EAP-based
fast-reauth solution to the inter-media handoff problem.
Given all of this, I would urge you to rethink the "performance uber alles"
requirement. "Good enough" performance along with ease of deployment
is likely to yield more value to the Internet community.
> Some existing link layers already define their own key
> hierarchy (e.g. WiMAX). Is it desirable to retain
> compatibility with those link layers?
The goal is to still deliver something that the lower layer
thinks is the MSK. Whatever key is delivered will be used as the
root of the keying hierarchy.
> [BA] Isn't channel binding an EAP method-specific issue? How
> does this relate to EAP re-authentication?
If an EAP method performs channel binding to authenticate the
NAS's BSSID, for example, you'd want that same validation when
re-authenticating to another NAS. Just because we're not running
the method doesn't mean we don't want the same guarantees about
the network. For example, if you decide to switch between base
stations because the other is offering a lower roaming rate,
you'd like to authenticate that rate, even if you're performing a
fast reauth to get there.
So, if you start carrying channel binding properties over your
EAP methods, it would be nice if your re-auth protocol could
carry them too.
> [BA] Are you saying that the EAP peer and EAP re-authentication
> server need to mutually authenticate?
To the extent it's necessary for the peer to ensure proper
service from the network. I've modified the text in that section
to reflect that.
> [BA] Can't an R1-KH represent a "new authenticator"?
Not that I'm aware of -- the linkage between the R0-KH and R1-KH
is purely internal to 802.11r, so I don't see why the R1-KH would
be a new authenticator.
[BA] Since an R1KH can be attached to any authenticator within the
Mobility Domain (which can encompass several authenticators),
it seems to me that 11r can support inter-authenticator handoff.
> [BA] Doesn't IEEE 802.11r address inter-controller handoff?
For CAPWAP, it potentially could.
[BA] 11r can be implemented either on stand-alone APs or on
controllers. So I don't think there is a dependency on a particular
architecture (or on CAPWAP).
But, CAPWAP hasn't really
decided how it plans to deal with 11r. It's beyond the scope of
the current document (11r was not included in the binding). It's
unclear whether 11r would exist inside CAPWAP, with CAPWAP acting
as the transport for 11r, or whether 11r would exist outside
CAPWAP, which could cause problems for roaming within a
single AC.
About a year ago I looked at CAPWAP and 11r. My conclusion was
that the AC would act as the R0-KH and R1-KH (no key transport
protocol required),
[BA] 11r can certainly function solely within an AC without a key
transport protocol. However, the 11r specification also talks about
"push" and "pull" modes of key transport, presumably in order to
support inter-authenticator handoff.
and the only benefit 11r would bring to
CAPWAP was optiming the four-way handshake. CAPWAP could
possibly push PMK-R1s out to WTPs to decrease the latency in the
SAP, but it gets messy and breaks the basic security
architecture.
All in all, in my opinion HOKEY would be a much better way to do
inter-AC handovers.
[BA] I think the problem comes in the definition of "better".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf