[Isms] Further ACM design discussions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Isms] Further ACM design discussions
While we're wrestling with modularity issues, I need to bring up an old
discussion regarding modularity vs. identity bindings.
We want the Access Control Subsystem to be independent of all other
subsystems, except for the information passed explicitly in ASIs or
implicitly via "caches". Very good.
The question I want to pose is what's the relationship between the
authenticated identity associated with the Transport Subsystem's protected
session, and the securityName passed into the Access Control Subsystem?
We had a debate about whether an authorization service ought to be separate
from an authentication service -- Jeff -- but we know that RADIUS was not
designed with that separation in mind. In fact, RADIUS authorization is
always tied to RADIUS authentication, either directly or indirectly.
How does the RADIUS data access control information, e.g.
Management-Policy-ID, get to the place where it's needed? Does the RADIUS
client pass that information up through PAM to the SSH server and hence to
SSHTM, which stashes it in a "cache" that some VACM-related function can
later access? Or do we expect that the ACM will somehow cause a second
RADIUS exchange to occur?
What happens if there is a name-mapping that occurs between the time a
Username Attribute is sent in a RADIUS Access-Request message and
securityName is presented to an Access Control Model? It seems to me that
the data access control information provided by RADIUS is bound to the
Username in the Access-Request, and for correct operation the securityName
presented to the ACM must be similarly bound to the RADIUS-authenticated
identity.
I need to go back and read our I-Ds, now in the RFC Editor Queue, to refresh
my memory, but I recall all sorts of debate on this list about name mappings
and translations that might occur between what happens in RADIUS and what
happens in ACM.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.