Subject: RE: [AAA-WG]: Issue 77: Possibility for implicit termination of an Authentication or Authorization session.

From: "Irene Martin Cabello (ECE)" <[email-masked]>
Date: Tue, 12 Jun 2001 10:43:42 +0200

In the Base Protocol (chapter 10.4, Authorization Lifetime) is writen: 
"A value of zero means that no re-authorization is required". 
I thought this value of zero was useful when AAA does not require a re-authentication and/or re-authorization initiated from the access device, because the AAA will be in charge of initiating it by means of sending an unsolicited AA-Answer message with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH (former "AA-Challenge" message).

But, according to your proposal, the value of zero implies that no session information will be stored in the AAA. Then my above assumption was wrong, but then my question is: when could be useful for the AAA to send an unsolicited re-authentication and/or re-authorization? I think always the access device must be in charge of requesting a re-authentication and/or re-authorization, and the AAA MUST clean up resources when the Authorization lifettime expires without re-authorization.

Also, I thought that when an "authentication only" request message is received in the AAA, the AAA should validate the authentication but the AAA should not store any session information since authorization is not requested. Is this wrong?
It would be very useful if it is clarified in NASREQ draft, when "authentication only" and "authorization only" should be allowed/rejected.

Another question: when re-authorization is requested, the AAA should just extend the "life" of the session and return the Authorization Lifetime in the AA-Answer message, or should this message also include again the authorization AVPs provided in the first AA-Answer message?

Thanks in advance for your answers,
	Irene

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2001 2:48 AM
> To: Tony Johansson
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Issue 77: Possibility for implicit 
> termination of
> an Authentication or Authorization session.
> 
> 
> Tony,
> 
> This works for me, and including a zero 
> Authorization-Lifetime is a great way
> for an access device to signal that it doesn't expect to send 
> additional messages to
> the home server. Of course, I *think* that some issues MAY 
> arise if the home server
> decides that it wishes to maintain state, so a Result-Code 
> value must also be 
> created to allow the server to reject specifically this 
> request (as opposed to some
> complicated Failed-AVP processing.
> 
> Anyone object to this reasonable request? I can think of 
> quite a few uses.
> 
> PatC
> On Mon, Jun 11, 2001 at 04:45:12PM -0700, Tony Johansson wrote:
> > All,
> > 
> > Here is a new issue.
> > 
> > /Tony
> > 
> > Issue 77:  Possibility for implicit termination of an 
> Authentication or
> > Authorization session.
> > Submitter name: Tony Johansson
> > Submitter email address: [email-masked]
> > Date first submitted: 2001-06-11
> > Reference:
> > Document: Base
> > Comment type: T
> > Priority: 1
> > Section: 10
> > Rationale/Explanation of issue:
> > There may be cases where you don't need to store any 
> session information
> > in the AAA. For example, there may be cases where the 
> access device will
> > handle all seesion information. Thus, an access device may request
> > authentication as a one time thing and no further messages would be
> > needed between the access device and the AAA.
> > 
> > Proposal:
> > Perhaps a request from the access device SHOULD allow the
> > Authorization-Lifetime (as a hint to the server). A value of zero
> > implies that no state should be created, and no STR will be sent. A
> > value of zero is a one-shot thing (auth once, never hear 
> from me again).
> > 
>

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 12 Jun 2001 09:26:50 -0700

On Tue, Jun 12, 2001 at 10:43:42AM +0200, Irene Martin Cabello (ECE) wrote:
> I thought this value of zero was useful when AAA does not require a re-authentication 
> and/or re-authorization initiated from the access device, because the AAA will be in 
> charge of initiating it by means of sending an unsolicited AA-Answer message with the 
> Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH (former "AA-Challenge" message).

I believe what is being said here is that applications that KNOW that servers do not 
maintain session state may not require the overhead of STR messages. These service would
require a one-shot authorization and/or authentication request.

Here is an example. An incoming call on a NAS generates an autorization request to the
local server, on whether the call should be answered or not. If a successful answer is
sent, the NAS answers the phone, and begins PPP, etc.

If the existing state machine was used, the authorization request (may I answer the
call?) would require an STR.

So, without the change, we have the following:

1. Authorization Request
2. Authorization Answer
3. STR
4. STA
5. Authentication/Authorization (PPP) Request
6. Authentication/Authorization (PPP) Answer
7. STR
8. STA

with the proposed fix, we would have:
1. Authorization Request
2. Authorization Answer
3. Authentication/Authorization (PPP) Request
4. Authentication/Authorization (PPP) Answer
5. STR
6. STA

reducing the number of messages from 8 to 6, and this is just one such example.

> 
> But, according to your proposal, the value of zero implies that no session information 
> will be stored in the AAA. Then my above assumption was wrong, but then my question is: 
> when could be useful for the AAA to send an unsolicited re-authentication and/or 
> re-authorization? I think always the access device must be in charge of requesting 
> a re-authentication and/or re-authorization, and the AAA MUST clean up resources when 
> the Authorization lifettime expires without re-authorization.

I would claim that only stateful servers will ever issue re-auth messages towards the
access device. So, if a request is received with an Authorization-Lifetime of zero (0),
then the server can determine whether it is willing to accept this value or not. If it
wishes to maintain state information, it could either return an error, or simply insert
its own Authorization-Lifetime, which would cause the access device to send an STR when
the session is complete.

> 
> Also, I thought that when an "authentication only" request message is received in the 
> AAA, the AAA should validate the authentication but the AAA should not store any 
> session information since authorization is not requested. Is this wrong?

No, this is true.

> It would be very useful if it is clarified in NASREQ draft, when "authentication only" 
> and "authorization only" should be allowed/rejected.
ok

> Another question: when re-authorization is requested, the AAA should just extend the 
> "life" of the session and return the Authorization Lifetime in the AA-Answer message, 
> or should this message also include again the authorization AVPs provided in the 
> first AA-Answer message?
I suspect it would make sense to send in a complete request, in case it hits a different 
Diameter server in the network.

Thanks,

PatC