Subject: RE: [AAA-WG]: Re: Issue 414: Keying AVPs

From: <[email-masked]>
Date: Wed, 13 Aug 2003 18:02:23 +0300

Bernard Aboba wrote:

> In RADIUS, Session-Timeout can be used to indicate the maximum
> amount of time that the user can have (with Termination-Action not
> specified or set to default), or the maximum time to
> re-authentication (if Termination-Action = RADIUS).  While it is
> true that a re-authentication implies a re-key, the reverse is not
> true; a re-key can be done without re-authenticating (e.g. rerun the
> 4-way handshake in 802.11).  Also typically a re-key is done after a
> certain amount of data is sent.  For example in block ciphers this
> is related to the birthday attack probability.  For a credible
> cipher (e.g. AES) this is typically quite a large number.  For WEP
> it was small due to its flaws and so people have set Session-Timeout
> to 10 minutes or less.  In general it would be useful to be able to
> set the re-key and re-authentication timers independently.

I agree with you that setting these timers separately
could be useful. One possible solution would be that 
Authorization-Lifetime (or Session-Timeout, I'm confused about them)
would specify the lifetime of the MSK (==after this period, you need
to contact the AAA server, which may give you a new MSK), and some 
new AVP (maybe "Rekeying-Interval") would specify link-layer 
rekeying interval (==TSK lifetime)?

Another possibility would be to configure TSK lifetime locally 
on the access points. This would also allow volume-based TSK 
lifetimes ("rekey TSK after sending X gigabytes"), or do
we need an AVP for also that?

This Rekeying-Interval AVP would be somewhat link layer specific, 
but I don't think it matters (some link layers might not even 
support TSK rekeying e.g. because they use good ciphers which 
don't need it, and even rekeying means different things in e.g.
802.11i, PANA and IKEv2).

Do you think something like this would work?

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Aug 2003 10:21:16 -0700 (PDT)

> Authorization-Lifetime (or Session-Timeout, I'm confused about them)

I'm also confused, and this worries me because we've had several people
say they were confused about this over the last few days.  Perhaps we need
to revisit whether the current NASREQ text on this really makes sense?

> rekeying interval (==TSK lifetime)?

One issue is that in practice the rekey interval (expressed in
terms of packets) depends on the negotiated ciphersuite.
So WEP needs to be rekeyed much more frequently than say, AES.
Since AAA and EAP are ciphersuite independent, the AAA server does
not in practice have the information required to set the rekey interval
appropriately, since the ciphersuite may not be determined until the
secure association protocol runs.

I think this means that a Rekey-Interval AVP isn't appropriate for
inclusion in the AAA-Key Grouped AVP.

> we need an AVP for also that?

This might make more sense, since one could configure the APs with
different lifetimes depending on the negotiated ciphersuite (e.g. a table
of ciphersuites and corresponding rekey intervals in octets).  This
would make it possible to set a WEP lifetime of X octets and an AES
lifetime of Y octets where Y >> X.  Doing this on a per-AP versus
per-session basis would work fine; there is no need to set different
sessions to different values other than because they negotiated different
ciphersuites.

> Do you think something like this would work?

I think you've made an argument for why the Rekey-Interval should be left
to link layer management rather than AAA.

However, I have some additional confusion to add to the mix :)

Yet another parameter that might need to be set is the AAA-Key caching
interval.  This is the time that the NAS retains the AAA-Key after the
session has terminated.  This is different from either the rekey
interval or the re-authentication interval.

Would this be appropriate for sending in the AAA-Key Grouped AVP?