RE: AAA for Handovers

[Narayanan Vidya-CVN065 <vidya@motorola.com>]

Emile, Bernard,
Thanks for the clarification on the accounting issues. 

Does anyone know how this will work with 802.11r-like key hierarchy? As per the key hierarchy, it seems like the station will have to establish the MSK by contacting the R0 key holder. However, the PTK it shares is with the R2 key holder. So, technically, the PMK-R0 is only used to derive the PMK-R1 and the latter to derive PMK-R2. I would imagine the RADIUS client would reside in the R0-KH - right? However, the station may handoff to different R2-KHs within the same R0-KH - how and when will accounting-start messages be sent in this case? Or, is it that the accounting messages only need to be sent when the station first derives the PMK-R0? 

About IAPP, I wasn't referring to the use of it here. I think mandating use of IAPP for sake of authentication or accounting perhaps leads to more complications. 

Vidya


> -----Original Message-----
> From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] 
> Sent: Thursday, August 11, 2005 7:21 PM
> To: Bernard Aboba
> Cc: Narayanan Vidya-CVN065; radiusext@ops.ietf.org; 
> aaa-wg@merit.edu; Korus Mike-CMK013
> Subject: Re: AAA for Handovers
> 
> 
> Hi,
> 
> On Thu, Aug 11, 2005 at 04:52:51PM -0700, Bernard Aboba wrote:
> 
> > > However, AAA servers can authenticate accounting messages by 
> > > including a Class attribute in its access accept message. 
> According 
> > > to RFC2865, the NAS SHOULD echo the given A/V pair, regardless of 
> > > value, in all its accounting messages that pertain to the 
> session, 
> > > including Accounting-Start.
> > 
> > Yes, but Class was created to link the accounting message to a 
> > previous authentication on the same NAS.  In pre-emptive keying the 
> > problem is linking an accounting message on one NAS to an 
> > authentication that occurred previously on another NAS.
> > 
> > Specifically, with pre-emptive keying, getting an 
> Accounting message 
> > with an echo'd class attribute doesn't actually demonstrate 
> that the 
> > user authenticated to the NAS, since no evidence is provided to the 
> > AAA server.
> 
> No, but it does demonstrate that the second NAS obtained it 
> from the first one, possibly with other context and 
> credentials, as part part of an IAPP.
> 
> > This means that any NAS that received a Class attribute 
> along with the 
> > pushed key can subsequently send an Accounting-Start regardless of 
> > whether the user actually connected to the NAS and actually 
> used the 
> > key.
> 
> I would say the sequence would be
> 
> 0. user connects to NAS X
> 1. AAA receives authentication request from NAS X
> 2. AAA sends key + Class + other authorization parameters to 
> nas X 3. AAA sends key to nas Y, Z, etc.
> 
> and nas Y and Z will only be able to use the key and send 
> accounting if they are trusted by nas X, because nas X 
> decided to give them Class. 
> 
> Or am I shifting the problem too easily to the NASes? Is the 
> underlying assumption for this work that there's no IAPP 
> operating at all?
> 
> > > cannot fabricate sessions that never took place, because the home 
> > > AAA can test whether the unique value of Class corresponds to a 
> > > session autenticated by it earlier.
> > 
> > If the AAA server sends pre-emptive notifications to several NAS 
> > devices, each one of them can pretend that the user 
> connected to it, 
> > and can generate Accounting records with the correct Class 
> attribute.  
> > Without user authentication there is no way for the AAA 
> server to know 
> > whether the Accounting-Start messages are valid.
> 
> Not if those notifications don't include Class. Class would 
> then only be transported between NASes through an IAPP, at 
> the actual handoff time.
> 
> > > And by tying the accounting record
> > > to a specific authentication instance, the home AAA can verify if 
> > > the session duration given by Acct-Session-Time in 
> Accounting-Stop 
> > > messages doesn't exceed the time granted in its earlier 
> > > Access-Accept.
> > 
> > The problem is that pre-emptive keying does not require a client to 
> > demonstrate possession of the key to the AAA server.  The 
> AAA server 
> > just pushes the key out and assumes that it is either used 
> or expires 
> > on the NAS.  As a result, there may be no corresponding 
> authentication 
> > instance for each accounting record sent by a NAS.  That means that 
> > the AAA server cannot verify the Acct-Session-Time or even 
> whether the 
> > session started at all.
> 
> I think if there is one Class per session, instead of one 
> Class per session per NAS, this problem does not occur.
> 
> > > The secure tying of accounting to an earlier 
> authentication can be 
> > > done securely by the home AAA if the home AAA generates Class as
> > >
> > >   nonce + locally-unique-session-id + HMAC(Class + local-secret)
> > 
> > Unfortunately in pre-emptive keying there may be no "local-secret" 
> > between the NAS and the home AAA server.
> 
> No, local as in only known on the AAA server. It's talking to 
> itself via the NAS, which only echos Class after all.
> 
> > > Or, is the AAA server keeping track of the fact that the MN 
> > > authenticated through the target NAS and checks that when 
> receiving 
> > > the Accounting-Start?
> > 
> > The AAA server doesn't need to check this in real-time but if a 
> > question arises it is helpful to have logs to be able to figure out 
> > what happened.
> > 
> > > On the other hand, if it is the latter, doesn't this 
> cause concern 
> > > for the state build-up in the AAA server?
> > 
> > For forensic purposes, it isn't necessary for the AAA 
> server to keep 
> > state on authentications and corresponding accounting 
> records; logging 
> > is sufficient.  However, both pre-emptive keying and key-request 
> > require the AAA server to cache key state, which does represent a 
> > fundamental change.
> 
> As long as such caching it can be done on a layer above the 
> core protocol as given in RFC2865, -6, -9, it needn't be any 
> worse than other schemes that use accounting information for 
> subsequent authentications.
> 
> > > As illustrated above, the home AAA /can/ check that the MN was 
> > > authenticated by it before accepting an accounting start.
> > 
> > In pre-emptive keying, there is no corresponding 
> authentication on the 
> > NAS that produces the accounting-start.
> > 
> > > Other than that, I would like to second a preference 
> towards a key 
> > > request (as a form of lightweight authentication; of 
> course the home 
> > > AAA must see /some/ form of credentials or session cookie 
> before it 
> > > should hand out keying material) rather than the AAA pushing 
> > > material outwards.
> > 
> > Key-Request does not bring up these concerns because there 
> can be an 
> > authentication corresponding to each accounting-start.  This means 
> > that a log can verify that the client authenticated to the 
> AAA server 
> > via a particular NAS and this can be correlated with a subsequent 
> > accounting-start.
> 
> Exactly. The model where a user session is a set of 
> lightweight RADIUS sessions, one session per NAS contact, is 
> probably easier to design and implement.
> 
> I think we should only choose one of the extremes: either use 
> a full RADIUS authentication/start/interim/stop per NAS 
> contact, implying we must solve caching and reauthentication 
> speed issues at the EAP layer, or use one RADIUS 
> authentication/start/interim/stop per full user session, and 
> let handoff be done wholly outside RADIUS, through an IAPP.
> 
> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           emile@e-advies.nl      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>