Subject: RE: Issue 8

From: <[email-masked]>
Date: Mon, 23 Jun 2003 15:25:20 +0300

Hi Alper,

Here are some comments.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 11 June, 2003 21:48
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Subject: Re: Issue 8
> 
> 
> Dan,
> 
> > - We need a grace period too:
> > Authorization-Lifetime + Auth-Grace-Period <= Session-Timeout
> > Here
> > Auth-Grace-Period < Authorization-Lifetime
> > Unit is seconds. Auth-Grace-Period is a configurable parameter
> > and delivered from PAA to PaC.
> 
> I agree there might be a grace period, but I think this can be a local
> decision (via implementation, configuration). Does the 
> protocol have to
> carry this information to the other end (PaC)?

Grace period depends on the authorization and session lifetime. 
Network decides both of these (at least the limits), so PaC 
must be informed.

I guess we could have many authorization (refresh) periods in one 
session lifetime. If PaC fails to reauthenticate (PANA refresh) in 
the given authorization (refresh) period, the session is also torn
down.

> > - PaC should propose something and PAA then decides the actual
> > refresh period and session lifetime (the network knows better
> > the upper and lower limits for re-auth etc.).
> 
> Now that I'm thinking, maybe we should only pass the Session-lifetime
> between PAA and PaC, and not worry about Reauth-lifetime. PaC 
> and PAA don't
> need to share the Reauth-lifetime, each can trigger reauth as 
> often as they
> like/need. But for Session-lifetime, PaC should know it so that it can
> perform PANA authentication again before its session expires and PAA
> disables network access.

Is it PaC's or PAA's responsibility to do reauth? Protocol should be 
clear about this. Otherwise both PaC and PAA might try to do it at the
same time. Not clear enough for a protocol spec.

One way to go is to let PaC initiate the re-authentication after the 
authorization lifetime has been exceeded and grace period starts. Grace
period is needed for the processing the refresh/reauth (only the network
knows how much time a refresh can take).

> 
> 
> > PaC can optionally
> > propose a Authorization-Lifetime to PAA within a PANA-Auth-Request
> > message. 
> 
> I also thought about first PaC requesting a value and PAA 
> granting one. But
> then looking at the message flows, the other direction seems 
> to better fit
> the current design. Instead of one of the PANA-auth messages 
> carrying this
> info from PaC to PAA, and the response coming back in 
> PANA-success, I think
> doing it symmetrically in PANA-success/ack is better. PANA 
> module on the PaC
> won't really know in which PANA-auth message this AVP should 
> be included.

Yes, this is a problem. If PaC makes the final decision, then 
the network should inform both the lower and upper limits. We may
need more AVPs?

> 
> > PAA sends Authorization-Lifetime and Auth-Grace-Period
> > AVPs to PaC in PANA-Result-Request message. PAA can also send
> > Session-Timeout AVP to denote the total lifetime of the session.
> 
> I don't think we need to pass the grace-period to the PaC. 
> (well, if we do,
> it is no longer seen as grace period, but as part of granted period :)

Grace period doesn't add to the session lifetime, but to the 
authorization lifetime.

authorization_lifetime + grace_period <= session_lifetime

> 
> 
> How about this:
> 
> - PAA sends (offered) session-lifetime in PANA-success 
> message to the PaC.
> If PaC wants to lower the session-lifetime, it MAY include a lower
> session-lifetime in PANA-success-ack.

We need the lower limit too. I guess this could be stated in the spec,
but the scenarios are different and the network may want to use different 
limits, even dynamically (depending on the signaling load etc.).

> 
> - It's the responsibility of PaC to perform PANA before its 
> current session
> expires. [note: here we are talking about full authentication 
> where an EAP
> method is executed, not re-auth]

Yep. We have two authentications: local refresh, and EAP re-auth.

> 
> - Both PaC and PAA can initiate re-auth whenever they need to.

This must be clarified in the spec. The proposal for issue8 doesn't 
take care of this yet.

- Dan

> 
> Does this make sense?
> 
> > 
> > - PANA-Reauth-Request from PAA can optionally contain
> > Authorization-Lifetime AVP to denote the re-auth interval
> > (if network wants to change it)?
> > 
> > 
> 
> 
> Alper
> 
> > Br,
> > - Dan
> > 
> > 
> >> -----Original Message-----
> >> From: ext Alper Yegin [mailto:[email-masked]]
> >> Sent: 11 June, 2003 00:10
> >> To: [email-masked]
> >> Subject: Issue 8
> >> 
> >> 
> >> 
> >> http://danforsberg.info:8080/pana-issues/issue8
> >> 
> >> 
> >> How about if we:
> >> 
> >> - define a refresh (re-auth) lifetime AVP.
> >> - PAA MUST include this AVP in the PANA_success to provide 
> the maximum
> >> allowed refresh lifetime for the PANA session.
> >> - PAA MAY include this AVP in the PANA_success_ack to lower
> >> the required
> >> PANA refresh lifetime.
> >> 
> >> At the end of PANA_success round, both PAA and PaC knows 
> the refresh
> >> frequency. 
> >> 
> >> PaC MAY send PANA_reauth before this period expires. PAA MUST send
> >> PANA-reauth if there was no PANA-reauth exchange for one 
> full period.
> >> 
> >> Comments?
> >> 
> >> Alper
> >> 
> >> 
> > 
> > 
> > 
> 
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 23 Jun 2003 11:18:35 -0700

Hi Dan,

> Network decides both of these (at least the limits), so PaC

Network does not have to inform the PaC about the grace period. It does not
even have to have a grace period. It's just a courtesy to have one. Do you
have examples of other similar protocols carrying grace period in addition
to authorized lifetime to their clients?

> Is it PaC's or PAA's responsibility to do reauth?

Any can do. It's up to the entity. If PAA believes it needs to perform
re-auth, it can do so. Same for PaC. The signaling can be initiated from any
direction, and the other end has to respond when it receives a request.
That's why I don't think PaC and PAA need to coordinate anything on this.

> Protocol should be
> clear about this.

Is this not clear (this is in the pana-00 draft):

   The second type of re-authentication is based on a single protected
   message exchange without entering the authentication phase.
   PANA_reauth/PANA_reauth_ack messages are used for this purpose.  If
   there is an established PANA SA, both PaC and PAA can send a
   PANA_reauth message to the communicating peer whenever it needs to
   make sure the availability of the PANA SA on the peer and expect the
   peer to return a PANA_reauth_ack message.  Both PANA_reauth /
   PANA_reauth_ack messages MUST be protected with a MAC AVP.

> Otherwise both PaC and PAA might try to do it at the
> same time. 

Is this a problem? If PaC receives a PANA-reauth-request before it sends
its own, it can reset its timer (or, optionally keep its own timer and stick
to its schedule regarding sending PANA-reauth-requests). Even if two
PANA-reauth-requests cross each other, this cannot be a problem either, as
each peers would respond to them.

> Not clear enough for a protocol spec.
> 

In my proposed text, PAA already informs the PaC about the upper limit.

> limits, even dynamically (depending on the signaling load etc.).

Why do we need the lower limits? Do other protocols do that?

> Yep. We have two authentications: local refresh, and EAP re-auth.

No, this is exactly what I'm trying to clarify. What you refer to as "local
refresh" is done by using PANA-reauuth-req/ans. This should have nothing to
do with Session-lifetime. PaC and PAA can do this as often as they need to.

On the other hand, PANA-auth (that carries EAP) needs to be done before
Session lifetime exprires. This is what I'mm talking about in here.

> This must be clarified in the spec. The proposal for issue8 doesn't

Spec already has a text on this.

Alper