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

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 12:41:31 -0400

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
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 02 Aug 2005 10:26:58 -0700

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!

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 14:40:14 -0400

Thanks, I suspected that was the answer.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Kaushik Narayan
> Sent: Tuesday, August 02, 2005 1:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] Separation of authn and authz when using RADIUS
> 
> Hi David,
>