Subject: RE: [Isms] RE: SNMP "access control" terminology

From: "Nelson, David" <[email-masked]>
Date: Wed, 28 Jun 2006 17:30:30 -0400

David Harrington writes...

> 1) access control is optional, to a degree. It is an advisory
> functionality used by an application.

> 2) The default configuration of VACM is determined by an 
> administrator (and the ability of an implementation to support 
> their decision.

Hmmm.  This means that a security analysis of the ISMS work is dependent
upon administrative configuration, for which the standard has no default
values.  It that right?  That may not be a big problem, or even unusual,
but it will likely play into the security considerations section.
 
> It would be incorrect to assume that the policies MUST come from
> a AAA server, or from the same AAA server that was part of the
> authentication process.

True.  I was attempting to describe what MUST happen if such policies
are in fact provisioned by a given AAA service.

> > This would be under the title of
> > "SSH-RADIUS Integration".  I think this is a very good thing, and
> > have in fact described RADIUS attributes that could be used to
> > provision SSH in such a fashion.
> 
> What are the normative requirements you mention?
> Let me be clear that SSH does NOT need to use RADIUS at all.

Yes, of course.  The requirement I'm thinking of is along the lines of:

It is optional to use RADIUS (or any other AAA service) to provision
SNMP service via SSH, using SSHSM.  If an implementation (and its
configuration) chooses to use AAA provisioning, this document describes
how it is to be implemented, including normative requirements as to
authentication, authorization and bindings between the two.

Or something vaguely along those lines.  The "If you choose to use it,
this is how you MUST use it", sort of thing.  We can debate whether the
keywords ought to be MUST, SHOULD or RECOMMENDED, depending on what
level of security assurances we might like to make.

> 1) SSH provides an "snmp" subsystem. I'm not sure NAS is 
> appropriate here.

"NAS" is RADIUS-speak for the system which contains the RADIUS client,
and upon which a RADIUS server provisions service, for an attached user.

> I'm not sure whether your "base-level" service provisioning goes
> beyond that.

No, it doesn't.

> 3) If SSH chooses to use a RADIUS server to advise it whether to
> provide the "snmp" subsystem requested by the SSH user, then SNMP
> should know nothing about the fact that SSH chose to consult RADIUS.

If SSH is the enforcer of the SNMP service, and there is no desire to
pass along "access control" information from an initial authentication
and authorization response, then yes.  If we hold open the possibility
of an operational mode in which SSH passes "access control" information
(like a policy name) for the ACM to use, then no.

> I'm not sure what other changes are required to SSH.

Do SSH server implementations today actually provision SNMP service
based on authorization attributes from an AAA service?  I think the
answer is no.  That is the type of change that I had envisioned.

> There are other changes that COULD be made to an SSH server. For
> example, such an SSH server might support the "managament" attributes
> you have proposed. But I'm not sure that is a requirement.

If you follow the RADIUS or Diameter architectures, and you have
configured AAA "control" of the services offered on the NAS, then IMHO,
this is a requirement.  AAA is generally more about mandatory
provisioning, and less about advisory provisioning.  Of course, the NAS
is the point of enforcement, so in terms of implementation behavior it's
always advisory.  However, in order for such an implementation to be
compliant with the normative requirements of RADIUS and Diameter RFCs,
the enforcement of service provisioning is mandatory.

I suspect this might be at variance with the SNMP architecture.

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