Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-reauth-ps (Handover Key Management and Re-authentication Problem Sta

From: Charles Clancy <[email-masked]>
Date: Sun, 10 Feb 2008 22:24:58 -0500

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 <[email-masked]>
> To:     <[email-masked]>
> 
> 
> 
> Here is my review:
> http://www.drizzle.com/~aboba/EAP/ps-review.txt
> 
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: "Clint Chaplin" <[email-masked]>
Date: Mon, 11 Feb 2008 08:57:45 -0800

On 2/10/08, Bernard Aboba <[email-masked]> wrote:
>
>
> 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).
>
TGr may have used this metric, but only unofficially.  It was never
codified in the PAR or the draft.

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey