RE: AAA for Handovers

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

> Pre-emptive keying seeds the key cache at potential points of
> attachment, but the EAP peer only authenticates with the 
> target NAS, the AAA server never confirms that the EAP peer 
> used the key.  The only indication the AAA server receives is 
> an Accounting-Start from the target NAS, indicating that the 
> EAP peer has connected.
> 
> Because the AAA server can never confirm that the EAP peer
> was even considering the target NAS, it has no way to know 
> whether the Accounting-Start it received is authentic.  This 
> enables a rogue operator to generate fraudulent accounting 
> records that cannot be easily checked by the AAA server.
> 

I am not very familiar with how accounting works. Is the Accounting-Start message not authenticated? If it is authenticated using an SA shared between the NAS and the AAA server, I am wondering why that isn't enough to trust the NAS. 

> 
> The requirement that the EAP peer demonstrate interest in the 
> target NAS and prove its identity means that there is an 
> authentication attempt to go along with the Accounting-Start.
> 
> 

Is it that the AAA server relies on the successive timing of the authentication via the target NAS and the Accounting-Start message? 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? If it is the former, isn't there a problem with pre-authentication itself? The MN may have pre-authenticated via a target NAS well before handoff, but an Accounting-Start may be sent much later. On the other hand, if it is the latter, doesn't this cause concern for the state build-up in the AAA server? 

> 
> From what I can tell, the security of the "Key Request" 
> scheme is equal to or better than pre-emptive keying, without 
> requiring server-initiated messages or changes to the lower 
> layer neighbor reporting mechanisms.
> 

It seemed like there was concern about evolving key hierarhies - is that not true? For e.g., typically in EAP, the MSK is generated and using that MSK, the NAS and STA derive transient keys. In 802.11r, it seems like the R0, R1, R2 keys (I think they are called PMK-Rx) are derived successfully from one another, R0 being the MSK (in most cases). I noticed that there was no freshness added in generating these PMKs. Are such schemes as secure as regular EAP key derivation? 


> 
> One thing to keep in mind is that the total transaction time 
> is not the only factor determining whether a handoff can be 
> completed in time. A more important factor is the key cache 
> hit rate and the lead time.  If knowledge of key state is 
> synchronized and the neighboring NASes can be determined well 
> ahead of time, then the introduction of one or more 
> roundtrips to the AAA server may not matter that much because 
> EAP authentication or "Key Request" may be a rare event.
> 
> As an example, in a building where there are two WLAN 
> switches, an EAP peer with an awareness of the key cache 
> boundaries would only need to authenticate with each switch 
> once a key cache entry had expired.  So if the key lifetime 
> is 24 hours, the peer might authenticate with each switch at 
> the beginning of the day, and then not do any other EAP 
> authentications until the next day.
> 
> In such a situation the extra round-trips to the AAA server 
> of an EAP pre-authentication or "Key Request" do not affect 
> performance or AAA server loading that adversely.
> 

Yes, to an extent this becomes dependent on topology and makes it somewhat difficult to generalize the requirements here. 


> 
> I think it would probably be worth bringing the issue up in 
> IEEE 802.11r, so as to clarify exactly what (if anything) 
> they want from the IETF. From my perspective, a very valuable 
> contribution would be to develop a requirements document that 
> states clearly what the problem is and what a good solution 
> would look like.  For example, to date there are a lot of 
> different notions of what "fast" means, or what scenarios 
> need to be supported and why.  Without consensus on what the 
> problem is or how we know when it is solved, it is difficult 
> to make much progress.
> 

Okay. 

Thanks,
Vidya

--
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/>