Subject: RE: Issue 8

From: <[email-masked]>
Date: Wed, 13 Aug 2003 16:20:56 +0300

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

---

From: Alper Yegin <[email-masked]>
Date: Thu, 21 Aug 2003 18:24:27 -0700

> 3. full EAP auth from scratch.

From PANA's perspective, when to perform #2 or #3 depends on EAP. Whenever
EAP decides to send an EAP packet (for re-auth or auth, it does not matter),
PANA sends it to its peer. PANA would not care about these timers other than
to know what to put in the session-lifetime AVP.

As I understand, there are some RADIUS-Diameter-AAA specific confusion in
there. http://www.merit.edu/mail.archives/aaa-wg/msg05043.html . Let's wait
to see its resolution in the AAA WG. Than we can talk about what AAA
parameter helps the PAA determine the session-lifetime. Even than, I think
this is not for the base protocol spec to talk about, but maybe a separate
document like draft-congdon-radius-8021x is needed.

> PAA terminate session for PaC if it gets link-down notification for it?

I think this is an implementation/deployment optimization. If the network
trusts the validity of its link-layer triggers, it can do that. I think we
are fine as long as we do not prevent that by the protocol design.

Alper