Subject: RE: [Isms] RE: Follow up on Authorize Only issue

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Jul 2006 14:48:41 -0400

David Harrington writes...

> Ergo, I believe SSHSM should never use the "authorize-only" 
> feature.

I'm more that a little fuzzy on the architecture, the ASIs, etc., so
please bear with me.

I agree that the Access Control Subsystem will be the ultimate consumer
of the "fine granularity" authorization, such as that provided by
Management-Policy-ID, or a similar attribute.

It is my understanding, and please correct me if I miss some details,
that the Transport Mapping Subsystem (e.g. the SSN server) has the
responsibility of enforcing "coarse granularity" authorization, i.e.
whether a SNMP subsystem may be spawned by the SSH server.  It also has
the responsibility to pass along the securityName to the Access Control
Subsystem.  Given that any additional authorization information that
comes during an integrated RADIUS authentication and authorization also
needs to be passed along with the securityName, that implies some
participation by the Transport Mapping Subsystem.

In the case where RADIUS is only used for authorization, it could be
argued that it is the responsibility of the Access Control subsystem to
obtain that information.  I suppose the interface would be
implementation dependent.

This needs to be described somewhere.  If not in the RADIUS Usage for
SSHSM document, then where?

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 15:04:43 -0400

> participation by the Transport Mapping Subsystem.

SNMP provides no interface by which that information can be conveyed 
between subsystems.

At one time, we thought the SSH transport mapping and security model would 
be tightly bound, with the transport mapping passing SSH-specific 
information to the security model via a new interface (an opaque blob whose 
meaning was known only to the TM and corresponding SM), and the real work 
being done in the SSHSM.  Now, I believe we've moved to a model where there 
is a generic "transport" security model which does basically no work, and 
all the work is done in the TM.

In either case, all the access model sees is the security name/type/level, 
and there is no way to provide more specific information.  In fact, it 
would be something of an abstraction violation to provide transport or 
security model-specific information to the ACM.  IMHO it would be even 
worse to expect those models to obtain information which is actually 
RADIUS-specific but _not_ specific to the TM or SM, and pass _that_ to the 
ACM.  After all, RADIUS might _not_ be in use, and some other authorization 
mechanism might be.

Now, it's entirely possible that an SSH+SNMP implementation could pass 
RADIUS attributes up to the ACM "behind the back" of the abstract model. 
However, that would be an optimization, not something described by the 
specification.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Tue, 25 Jul 2006 17:02:54 -0400

Hi David, 

<tongue in cheek>
You're fuzzy on the SNMPv3 architecure? How can that be? It is soooo
SIMPLE! ;-)
</tongue in cheek>
 comments inline.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> 

It should be described in a separate document, so we do not cause
other people to also be fuzzy on the architectural separation.

Please note the following from the charter.

The working group will cover the following work items:
- Specify an architectural extension that describes how to perform a
mapping from AAA-provisioned user-authentication and authorization
parameter(s)to securityName and other corresponding SNMP parameters.
- Specify a mapping from RADIUS-provisioned authentication and
authorization parameter(s) to securityName and other corresponding
SNMP parameters. This item may be a RADEXT work item last-aclled
in both groups.

And note this from the charter:
Work on new access control models or centralized administration of
View-based Access Control Model (VACM) rules and mappings is outside
the scope of the working group.

--
The RADIUS/SSHSM document should be describing how to use RADIUS to
authenticate a "user" and to authorize the estabishment for that user
of an snmp subsystem in SSH. 

The document needs to describe how to map from AAA-provisioned
information (or from the SSH information derived from the AAA
information) to securityName, securityModel, securityLevel, and other
SNMP parameters that are required for establishing the SSH snmp
subsystem. The SNMP securityname is deliberately human-friendly, so it
can be used for purposes such as logging. The default mapping for the
SNMP securityName parameter is to take it from the authenticated SSH
USER_NAME, but as Jeff mentioned, AAA might have an attribute to
provision a different securityName; this might be useful if the
authenticated SSH "user" is some human-unfriendly thing. 

But "provisioning SNMP parameters" explicitly does not include mapping
to the access control subsytem; that is a separate issue that is out
of scope for the WG, and should be dealt with in a separate document
when such a document is included in a subsequent ISMS charter. One
task at a time.

Please ask the chairs for their advice if this is fuzzy.

Dbh

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 25 Jul 2006 15:06:45 -0700

Hi -

> From: "Nelson, David" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 25, 2006 11:48 AM
> Subject: RE: [Isms] RE: Follow up on Authorize Only issue
...
> whether a SNMP subsystem may be spawned by the SSH server.
...

This may be a nit, or it may be a fundamental disconnect.
If we have SSH servers literally spawning SNMP subsystems,
something is very very wrong.

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 25 Jul 2006 18:12:53 -0400

> something is very very wrong.

David is using "subsystem" in the SSH sense, to refer to a service provided 
over an SSH channel instead of a shell, via a particular protocol 
mechanism.  Some implementations implement subsystems as separate programs 
which are spawned by the SSH server, but of course there is nothing that 
requires this.

In practice, I suspect what we'll be seeing a lot of is SSH servers 
establishing links to a long-lived SNMP subsystem, through some 
implementation-dependent local communication channel.