|
Comments below. > Date: Sun, 10 Feb 2008 22:24:58 -0500 > From: clancy@xxxxxxxxxx > To: bernard_aboba@xxxxxxxxxxx > CC: ietf@xxxxxxxx; hokey@xxxxxxxx; tim.polk@xxxxxxxx > 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@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf