Re: [Isms] Further ACM design discussions

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "Dave Nelson" <d.b.nelson at comcast.net>
To: <isms at ietf.org>
Sent: Saturday, June 13, 2009 8:30 PM
Subject: [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?
>

Not sure where you got to with this, but securityName is the name that is used
by the application and ASIs throughout the engine, the principal on whose behalf
the transaction is performed.

Except that we introduced an ASI bypass in the shape of transportAddress which,
when in the 'e-mail address' format, can be used by the application to pass
another identifier to ssh for use in authentication.

A technique that could be used elsewhere to bypass awkward architectural
restrictions:-)

Tom Petch

> 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.
>
>