Subject: [eap] Issue 339: Use of Session-Timeout in Pre-authentication

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 23 Mar 2006 11:55:40 -0800

Issue 339: Use of Session-Timeout in Pre-authentication
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: March 23, 2006
Reference:
Document: Keying-10
Comment type: T
Priority: S
Section: 3.4
Rationale/Explanation of issue:

During the HOAKEY BOF, Avi Lior pointed out that overloading of
Session-Timeout for use in pre-authentication could cause problems.
For example, it might be desirable to be able to specify both the
pre-authentication timeout and the Session-Timeout values at the
same time.

Section 3.4 of the keying document describes use of the Session-Timeout
attribute to set the pre-authentication timeout.  Rather than
specifying this here, it would be best to leave this to a future
document.

The proposed change is as follows:

In Section 3.4, delete

"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 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."

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

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 28 Mar 2006 10:14:01 -0800

> Session-Timeout for use in pre-authentication could cause problems.

Reading on...

> pre-authentication timeout and the Session-Timeout values at the

Yes.

> expired by the authenticator prior to the future time indicated by

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.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 28 Mar 2006 15:40:52 -0800

>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."

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 28 Mar 2006 22:26:53 -0500

I agree.  

Yoshihiro Ohba

On Tue, Mar 28, 2006 at 03:40:52PM -0800, Bernard Aboba wrote:
> 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?
> 
> 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."
> 
>

---

From: Jari Arkko <[email-masked]>
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:

> 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
> 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."
>
>
>
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 29 Mar 2006 17:46:30 -0800

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 <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked]
>Subject: Re: [eap] Issue 339: Use of Session-Timeout in Pre-authentication
>Date: Wed, 29 Mar 2006 21:12:53 +0300
>