Subject: RE: Issue 8

From: <[email-masked]>
Date: Thu, 21 Aug 2003 14:06:20 +0300

For more information concerning this problem see:
http://www.merit.edu/mail.archives/aaa-wg/msg05043.html

PANA could use Authorization-Lifetime, Idle-Timeout and 
Session-Timeout AVPs.

If I have interpreted Diameter correctly these could mean as 
follows for PANA: PANA Session-Timeout AVP can be an optional 
AVP (or the value 0 would mean unlimited time). 
Authorization-Lifetime would mean the lifetime before next 
EAP reauthentication or EAP full authentication MUST happen. 
Idle-Timeout AVP is evident.

What is missing is a timer for PANA specific local reauthentication/ 
refresh, but I guess we don't want it, at least if Idle-Timeout 
is used.

This question is still left:
> Also, how does PANA relate to link layer triggers (link 
> up/down)? Should PAA terminate session for PaC if it gets 
> link-down notification for it?

- Dan

> -----Original Message-----
> From: ext [mailto:[email-masked]]
> Sent: 13 August, 2003 16:21
> To: [email-masked]; [email-masked]
> Subject: RE: Issue 8
> 
> 
> Couple of thoughts for this issue..
> 
> We have three levels of authentications with PANA. 
> 	1. PANA specific local re-auth.
> 	2. EAP re-auth.
> 	3. full EAP auth from scratch.
> How to manage these..
> 
> What lifetime does the "session lifetime" refer to in PANA? Diameter 
> specifies Session-Timeout (from RADIUS) and 
> Authorization-Lifetime AVPs. 
> Authorization-Lifetime tells to the AAA Client when to do 
> re-authorization (EAP re-auth in PANA case?).
> 
>    8.13  Session-Timeout AVP
> 
>    The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type 
> Unsigned32
>    and contains the maximum number of seconds of service to 
> be provided
>    to the user before termination of the session. When both the
>    Session-Timeout and the Authorization-Lifetime AVPs are 
> present in an
>    answer message, the former MUST be equal to or greater 
> than the value
>    of the latter.
> 
> If I have understood properly Session-Timeout tells when both the 
> authentication and authorization must be done from scratch, i.e. new 
> keys must be derived etc. (full EAP auth). So this is used to define 
> the session key lifetimes too?
> 
> Action to be taken can also be specified according to the NASREQ.
> Sec. 4.10. talks about Session-Timeout and Authorization-Lifetime too:
> 
>    The Termination-Action AVP is of type Enumerated and indicates what
>    action the NAS should take when the specified service is completed.
>    This AVP SHOULD only be present in authorization responses. The
>    following values are supported as listed in [RADIUSTypes]:
> 
>       DEFAULT                    0
>          Upon termination of the authorized service the NAS MUST
>          terminate the current session.
> 
>       AA-REQUEST                 1
>          When the authorized service terminates, the NAS SHOULD NOT
>          terminate the session or generate a 
> Session-Termination-Request
>          (STR) command.  Instead, it SHOULD generate a new AAR command
>          which contains the same value of the Session-Id AVP 
> it sent in
>          the previous AAR command.  It SHOULD also include 
> the State AVP
>          from the previous AA-Answer (AAA) command, if it 
> contained one.
> 
>    <klip>
> 
>    When used by 802.1X supplicants, the service typically 
> terminates due
>    to the expiry of the Session-Timeout AVP.  The access 
> device may then
>    reauthenticate the user with a new AA-Request.  The RECOMMENDED way
>    to do this in Diameter is to use just the 
> Authorization-Lifetime AVP
>    rather than Session-Timeout and Termination-Action AVPs.  However,
>    the Termination-Action AVP MAY be present when copied from a RADIUS
>    Access-Accept to a Diameter AA-Answer by a Translation Agent.
> 
> So NASREQ recommends to use Authorization-Lifetime AVP only 
> with Diameter. 
> Does NASREQ here mean full auth or just re-auth? From Diameter:
> 	
>    8.12  Re-Auth-Request-Type AVP
> 
>    The Re-Auth-Request-Type AVP (AVP Code 285) is of type 
> Enumerated and
>    is included in application-specific auth answers to inform 
> the client
>    of the action expected upon expiration of the 
> Authorization-Lifetime.
>    If the answer message contains an Authorization-Lifetime AVP with a
>    positive value, the Re-Auth-Request-Type AVP MUST be present in an
>    answer message. The following values are defined:
> 
>       AUTHORIZE_ONLY             0
>          An authorization only re-auth is expected upon expiration of
>          the Authorization-Lifetime. This is the default value if the
>          AVP is not present in answer messages that include the
>          Authorization-Lifetime.
> 
>       AUTHORIZE_AUTHENTICATE     1
>          An authentication and authorization re-auth is expected upon
>          expiration of the Authorization-Lifetime.
> 
> So, if Authorization-Lifetime AVP is used in the AAA backend 
> Re-Auth-Request-Type AVP is there too. Number of possible 
> re-authentications 
> before full authentication should be limited too 
> (recommendation from some 
> EAP methods, like EAP-SIM). How to do this?
> 
> --
> 
> I'm also a bit worried about the fuzzy (timing) use of 
> PANA-Reauth-Request 
> message. What if "session lifetime" is 2 days, but PaC looses 
> connection 
> after 10 minutes? If we don't use refresh period, we could 
> use Idle-Timeout 
> AVP from NASREQ:
> 
>    6.4.  Idle-Timeout AVP
> 
>    The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 
> and sets the
>    maximum number of consecutive seconds of idle connection allowed to
>    the user before termination of the session or prompt. It 
> MAY be used
>    in an authentication and/or authorization request (or 
> challenge) as a
>    hint to the server that an idle timeout is desired, but 
> the server is
>    not required to honor the hint in the corresponding response.  The
>    default is none, or system specific.
> 
> Also, how does PANA relate to link layer triggers (link 
> up/down)? Should 
> PAA terminate session for PaC if it gets link-down 
> notification for it?
> 
> 
> - Dan
> 
> > -----Original Message-----
> > From: ext Alper Yegin [mailto:[email-masked]]
> > Sent: 31 July, 2003 22:26
> > To: [email-masked]
> > Subject: Issue 8
> > 
> > 
> > 
> > The resolution recommended at the IETF presentation was to 
> carry only
> > session lifetime in PANA-bind-request message sent from PAA. 
> > This would be a
> > non-negotiable, informative parameter. Neither of grace 
> > period nor re-auth
> > timers will be exchanged between PAA and PaC.
> > 
> > Taking it one step further, we can also say it is the 
> > responsibility of the
> > PAA to initiate PANA authentication before the session expires.
> > Nevertheless, sending the lifetime to PaC is still useful as 
> > it helps PaC
> > manage EAP SA and PANA SA efficiently.
> > 
> > Comments? If there are no objections, let's close this issue.
> > 
> > Alper
> > 
> > 
> 
>