RE: [Isms] Separation of authn and authz when using RADIUS

["David B Harrington" <ietfdbh at comcast.net>]

Thanks, I suspected that was the answer.

dbh 

> -----Original Message-----
> From: isms-bounces at lists.ietf.org 
> [mailto:isms-bounces at lists.ietf.org] On Behalf Of Kaushik Narayan
> Sent: Tuesday, August 02, 2005 1:27 PM
> To: dbharrington at comcast.net
> Cc: isms at ietf.org
> Subject: Re: [Isms] Separation of authn and authz when using RADIUS
> 
> Hi David,
> 
> I think it is safe to assume that for purposes of administrative
> access, protocols such as RADIUS and TACACS+ should be
> treated as being stateless. i.e. Although you could perform
> authentication and authorization as part of separate requests,
> the NAS would need to pass principal name in the authorization
> request. We should not expect the AAA server to manage a user
> session and map a session ID to a principal.
> 
> p.s. - Note that I specifically mentioned administrative access,
since
> some RADIUS server implementations do track user session state
> but that is largely for network access use cases such as 
> accounting/billing,
> COA etc.
> 
> regards,
>    kaushik!
> 
> 
> At 09:41 AM 8/2/2005, David B Harrington wrote:
> 
> >I have a question. I don't have a through understanding of RADIUS
and
> >my terminology might be slightly wrong, but I'd like to see if my
> >understanding of the abstract flow of messages is accurate. Please
> >keep this thread only about my question so we can retire this
thread
> >once my question is answered.
> >
> >In RADIUS, a client sends an Access-Request to a RADIUS server; as
> >part of that process, the client establishes a security association
> >between the client and server (the server validates the client).
The
> >client identifies the user for whom access is requested, and
provides
> >to the server the authentication credentials provided by the user
(in
> >various ways depending on the chosen authentication mechanism), and
> >may also provide such factors as port. If found acceptable, 
> the server
> >returns an "Access-Accept" which might include the type of service,
> >packet filter IDs, etc.
> >
> >Does RADIUS support the ability of the client to go back to 
> the RADIUS
> >server later to ask for additional service acceptance, or are all
> >service attributes, filter IDs, etc. returned in the
"Access-Accept"
> >message? i.e. can RADIUS handle the user-authentication as one step
> >(ending with the Access-Accept" nad then go back for authorization
> >information (e.g. filterIDs)?
> >
> >Applied to an SSH model, if the SSH authentication creates a RADIUS
> >session, is there a RADIUS session identifier that could be made
> >available to the AC subsystem, which can subsequently query (or
> >trigger the query of) the RADIUS server for authorization
information
> >(say an SNMP filterID used to name a VACM group) for the
appropriate
> >principal using the same RADIUS session?
> >
> >My thinking is that, given the securityModel and securityName via
the
> >ASI, a RADIUS ACM might be able to ask the co-resident RADIUS
client
> >to query for the groups/policies to apply to the user and 
> populate the
> >model's securityToGroupTable. If that is possible, we shouldn't
need
> >to include the AAA connection in the charter.
> >
> >David Harrington
> >dbharrington at comcast.net
> >
> >
> >
> >
> >_______________________________________________
> >Isms mailing list
> >Isms at lists.ietf.org
> >https://www1.ietf.org/mailman/listinfo/isms
> 
> _______________________________________________
> Isms mailing list
> Isms at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms
> 



_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms