Issue 339: Use of Session-Timeout in Pre-authentication

Issue 339: Use of Session-Timeout in Pre-authentication
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.com
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

Bernard Aboba wrote:

>
> During the HOAKEY BOF, Avi Lior pointed out that
overloading of
> Session-Timeout for use in pre-authentication could
cause problems.

Reading on...

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

Yes.

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

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

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

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

>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

I agree.  

Yoshihiro Ohba

On Tue, Mar 28, 2006 at 03:40:52PM -0800, 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
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

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

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.arkkopiuha.net>
>To: Bernard Aboba <bernard_abobahotmail.com>
>CC: eapfrascone.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