eap Mailing List: RE: Issue 339: Use of Session-Timeout in Pre-authentication

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

It would seem that the ISP would loose money if it gives 1 hr 10
minutes, while charging for 1 hr. On the other hand if the user has a
session that she knows will be 1 hr, then and I am guessing the peer
client has no idea about session timeout value...

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Wednesday, March 29, 2006 7:47 PM
To: jari.arkko [at] piuha.net
Cc: eap [at] frascone.com
Subject: Re: [eap] Issue 339: Use of Session-Timeout in
Pre-authentication

Here is a scenario:

The home server wants to allow a maximum session time of 1 hour, but
would like the pre-authentication cache entry to remain for only 10
minutes so as to avoid over-using resources.  So they send a
Session-Timeout value of 1 hour, and a Preauth-Timeout value of 10
minutes.
If the Session-Timeout value applies only once the session is started,
then it is possible that the total lifetime will be 1 hour + 10 minutes.

Another way to approach this is to let Session-Timeout count down and so
if the session starts at 9 minutes then the remaining Session-Timeout
would be
51 minutes.  The issue with this is that the ISP cannot know what the
exact Session-Timeout will be;  they can only know it will be something
between 0 and Session-Timeout - Preauth-Timeout.


>From: Jari Arkko <jari.arkko [at] piuha.net>
>To: Bernard Aboba <bernard_aboba [at] hotmail.com>
>CC: eap [at] frascone.com
>Subject: Re: [eap] Issue 339: Use of Session-Timeout in 
>Pre-authentication
>Date: Wed, 29 Mar 2006 21:12:53 +0300
>
>I think I agree with your intent. However, can we add something about 
>the fact that such modifications should never INCREASE the lifetime 
>beyond Session-Timeout? I think that's something that should hold, no?
>
>Bernard Aboba wrote:
>
> >> I actually liked the old text since it was very clear: ALL exported

> >> keys expire at Session-Timeout time, no exceptions. This seems to 
> >> make sense, still.
> >>
> >> I do agree that it might make sense to have additional lifetimes 
> >> specified for the preauth case, but I see those as additional 
> >> constraints rather than something that replaces Session-Timeout.
> >
> >
> > I think the issue is how to specify *both* the Session-Timeout and 
> > the pre-auth timeout.  If only Session-Timeout is included, the 
> > meaning is clear -- all keys expire when Session-Timeout runs out. 
> > However, if a pre-auth timeout attribute is included then the 
> > question is how to specify the maximum lifetime of the session, as 
> > opposed to the key lifetime. I'd like to leave some wiggle room for
future documents.
> >
> > How about this?
> >
> > "Where EAP is used for pre-authentication, the session may not start

> > until some future time, or may never occur.  Nevertheless, the 
> > Session-Timeout value represents the maximum time after which 
> > transported EAP keying material, and all keys calculated from it, 
> > will have expired on the authenticator.  If the session subsequently

> > starts, re-authentication will be initiated once the Session-Time 
> > has expired. If the session never started, or started and ended, by 
> > default keys transported by AAA and all keys calculated from them 
> > will be expired by the authenticator prior to the future time 
> > indicated by Session-Timeout.
> > Note that in future additional attributes may be specified to 
> > control the lifetime of cached keys; these attributes may modify the

> > meaning of the Session-Timeout attribute in specific circumstances."
> >
> >
> >
> >
>
>


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap