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. > 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? 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 thing up. Cut a mandatory 2RT to 1RT. 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. > 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] Doesn't IEEE 802.11r address inter-controller handoff? For CAPWAP, it potentially could. 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), 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. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland > > -------- Original Message -------- > Subject: Re: Last Call: draft-ietf-hokey-reauth-ps (Handover Key > Management and Re-authentication Problem Sta > Date: Thu, 24 Jan 2008 22:58:19 -0800 > From: Bernard Aboba <bernard_aboba@xxxxxxxxxxx> > To: <ietf@xxxxxxxx> > > > > Here is my review: > http://www.drizzle.com/~aboba/EAP/ps-review.txt > _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf