Subject: [AAA-WG]: NASREQ Request-Type AVP???

From: "Martin Julien (ECE)" <[email-masked]>
Date: Mon, 11 Jun 2001 10:36:30 +0200

Hi,

Looking at the NASREQ Request-Type AVP, I would appreciate if 
someone could give me his interpretation of the following 
possible values for the Request-Type AVP.

      AUTHENTICATE_ONLY          1
         The request being sent is for authentication only, and MUST
         contain the relevant authentication AVPs that are needed by the
         Diameter server to authenticate the user. 
<<

Since the specification says that it should not be permitted to
authenticate-only a session, and then authorize-only the same session,
I was wondering for what that value could really be useful?
Should that Request-Type value be only used when answering a AA-Request 
Challenge?

That also suggests that a scenario in which an authenticate-only
followed by an authorize-only for the same session does not
seem to be a valid one between a NAS and a AAA server, right?
Then, AA-request with Authenticate-Only for sessions that are
not already started should simply be rejected. What result-code
should be used? DIAMETER_UNKNOWN_SESSION_ID?, or 
DIAMETER_AUTHORIZATION_REJECTED?

Also, when a session is already started,
should we consider the session to be renewed in terms of Authorization-
Lifetime, when it is received? I think that it should not be renewed, 
since only a re-authorization request should renew the authorization-
lifetime, unless it is in response to a challenge sent by the AAA server,
to re-authenticate, right?

      AUTHORIZE_ONLY             2
         The request being sent is for authorization only, and MUST
         contain the authorization AVPs that are necessary to identify
         the service being requested/offered.
<<

I guess that a new session should then be started, if not already started. 
Also, when it is
already started, such a request should renew the lease for the authorization,
which means the Authorization-Lifetime. Normally, that should be received
when a request for a tunnel is made, which I guess means that the NAS should
have known in advance that the request would be tunnelled???, and also
possibly for re-authorization of an existing session. 

Should such requests be rejected when received in the AAA for which no tunnel 
is defined and no session is already started?

By the way, when a AA-Request is received in a AAA server without a User-Name,
but containing either a Called-Station-Id or a Calling-Station-Id, is it
implicit that tunnelling should be defined in the receiving AAA node or not?
The thing is that I am wondering if it is possible for a AAA proxy server to
forward an AA-Request based on DNI or ANIS? Is it common practice?
Since the specification considers that the allowed usage of those fields is outside
its scope, I guess it does not have to be reserved for tunnel, but I´m not sure??

BR,
Martin

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 14 Jun 2001 13:59:37 +0200

See enclosed comments.

> On Mon, Jun 11, 2001 at 10:55:43AM +0200, Jacques Caron wrote:
> > At 10:36 11/06/01, Martin Julien (ECE) wrote:
> > >Hi,
> > >
> > The nasreq draft indeed says in 3.1.1:
> >     It is possible for a single session to be authorized 
> only first, then
> >     followed by an authentication request. However, the 
> inverse SHOULD
> >     NOT be permitted.
> 
> $*@&!^@
> 
> I think that this sentence needs to be changed:
> 
> If both authentication and authorization will be requested 
> for a given session,
> the former SHOULD be done prior to the latter. It is still 
> possible for
> authorization to be done without authentication.
> 
> This covers:
> - Authentication first, followed by authorization (such as tacacs+)
> - authorize only (may I answer this phone call?)
> - authenticate only (well, I have no idea what you'd do this for :(
> 
> PatC
> 

Does it also mean that an authorization-only could be followed 
by an authentication-only?

The thing is that I am wondering if an AAA server
needs to keep a session opened for an authorization-only or not? 
For example, in the case that a request is received for 
authorization-only, which gets routed to a tunnel, is there any 
point of keeping a session in the AAA or not? I guess there is
no point for accounting, neither authentication, am I right?

By the way, when a AA-Request is received in a AAA server 
without a User-Name,
but containing either a Called-Station-Id or a 
Calling-Station-Id, is it
implicit that tunnelling should be defined in the receiving 
AAA node or not?
The thing is that I am wondering if it is possible for a AAA 
proxy server to
forward an AA-Request based on DNI or ANIS? Is it common practice?
Since the specification considers that the allowed usage of 
those fields is outside
its scope, I guess it does not have to be reserved for 
tunnel, but I´m not sure??

Regards,
Martin