Re: [MIB-DOCTORS] [OPS-DIR] FW: Recharter: ISMS

["Dave Nelson" <d.b.nelson at comcast.net>]

David B Harrington writes...

> The simplest way to approach this problem is to have the
> RADIUS authorization attributes simply there in the background.

OK.  This was supposed to be a chartering discussion, but it's turning into
an architecture and design discussion.  Maybe going down that path for a
moment will help resolve the charter text issue. I'm not sure.

So, how do systems typically use RADIUS?  Well, you have a device to which
network connections can be made, that is sessions established and service
provided.  There is some gatekeeper function that moderates access.  That
gatekeeper function can call the RADIUS client module and ask the "Mother,
may I?" question on behalf of the user identity associated with the
connection attempt.  RADIUS comes back with a "Yes" or a "No" and perhaps
some modifiers or limitations.  The result of that consultation with RADIUS
does indeed exist in the background.  The gatekeeper function typically
keeps it as part of some session state.  Or maybe not.  It depends on what's
needed.

The key point here is that the gatekeeper function calls the RADIUS client
function to ask an access control question.  The RADIUS client, after
talking to the RADIUS server, provided an answer.  Typically this happens
only once at the point of session establishment.  For scalability and
efficiency reasons, it can't happen for every discrete operation.

All of that comports with the notion that the RADIUS attributes exist in the
background.  What is not accounted for is that doesn't happen by magic.
Something has to call on RADIUS to request that information, and if that
something isn't the Access Control Model, what is it?

> My concern is maintaining the modularity that was deliberately created
> by the SNMPv3 WG to allow modular extensibility. This is all about
> separating who knows what. RADIUS knows about authorization
> attributes, not about VACM.

The RADIUS client does not know about VACM.  VACM is simply a module (yes I
mean that, a piece of code) that calls the RADIUS client's API.  The RADIUS
client (asynchronously) calls back with the results of the authentication /
authorization request.  The RADIUS client doesn't know what VACM (the VACM
extension) is going to do with this the information.  As a matter of
practicality, the VACM extension will probably dynamically update one of its
MIB modules with the information obtained from RADIUS.  That information
will exist for the duration of the "session".  Probably the hardest thing
about this work will be for the VACM extension to figure out when the
"session" is over and when to flush the temporary information from its MIB
module.  We've encountered this issue already.

> When the charter says that RADIUS provides VACM username-to-groupname
> dynamic provisioning, that is wrong. RADIUS provides a policy name.

Pedantically, you're correct.  The RADIUS client provides the VACM extension
with a policy name that's bound to a username and the VACM extension uses
that information to populate the MIB table.