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

[Jari Arkko (jari.arkko]

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