Subject: Re: [Isms] securityName

From: "Tom Petch" <[email-masked]>
Date: Sun, 24 Jul 2005 10:21:11 +0200

<inline>
Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>; <[email-masked]>
Sent: Saturday, July 23, 2005 1:24 AM
Subject: RE: [Isms] securityName

>
> There is not necessarily a need to statically store the securityName
> on the system. A MIB is made available for specifying the mapping from
> a model-dependent name to a  model-independent name, because some
> models may require a static mapping function.
>
> In USM, the mapping function is not really needed - the mapping
> function simply uses the model-specific name as the securityName. Of
> course, the USM model-dependent name (and implicitly the securityName)
> is already stored statically on the system, which is the concern ISMS
> is trying to resolve.
>
> If a security model can provide a dynamic identity mapping, such as
> translating from the authenticated transport identity (e.g. SSH user)
> to securityName, then the mapping may not need to be stored in a MIB
> module. It might be a desirable to store the dynamic mapping in a MIB
> module to enable monitoring of the authentications, or even to support
> static mappings to a single securityName from multiple model-dependent
> identities, such as a USM user and an SNMPv1 communityname and an SSH
> username, for example.

I was rather assuming that if ssh-userauth authenticated a principal, then
although that is a model dependent name to isms, it would be the same principal
identifier as is used in other security systems in the organisation and would be
the same as the securityName.  I don't see the merit in having a separate
principal identifier and securityName, given that one of our aims is to
integrate better with existing security systems.

>
> That said, ISMS is not addressing the problem of having a static
> mapping from securityName to access control policies. I expect that
> once we resolve the need to use static storage of model-dependent
> identities to map to securityName, we will then start work to resolve
> the need to have static mappings from securityName to access control
> policies, and we will need to decide if having mappings from multiple
> security model identities to a common securityName is still desired.
>
I take this as the same point Juergen made, that VACM is outside our scope.  But
if we eliminate the need for separate maintenance of security credentials in the
security model but leave it in place in VACM, in the shape of the
vacmSecurityToGroupTable, then I do not see how we have achieved our objectives,
hence my concern about this (while recognising that VACM is a given, not to be
changed as a result of isms).

> David Harrington
> [email-masked]
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tom Petch
> > Sent: Friday, July 22, 2005 3:38 PM
> > To: [email-masked]
> > Subject: [Isms] securityName
> >
> > When we were debating which approach to take, one issue that
> > kept surfacing was
> > the use of securityName;  I do not think that choosing an
> > approach has solved
> > that problem.  We may have a secure pipe from Command
> > Generator to Command
> > Responder
> > so a securityName can be safely transmitted from one party to
> > another but I do
> > not see how that can then be used.
> >
> > I take (model independent) securityName as a given, from
> > SNMPv3 Architecture and
> > from VACM (both of which the charter requires us to adhere
> > to).  So within an
> > agent (a low powered, low function, remote Command
> > Responder), there must be a
> > securityName which is used to index into the
> vacmSecurityToGroupTable.
> >
> > If that information is stored permanently within the agent,
> > then we have the
> > maintenance problem that led to the need for isms in the
> > first place.  (I see
> > this as particularly acute when there is a need speedily to
> > remove security
> > credentials from a principal across a network with thousands
> > of agents).
> >
> > If the information is stored dynamically, then part of
> > session setup needs to
> > create the relevant entries in the agent which then need to
> > be safely removed at
> > end of session (whatever a session might be).
> >
> > Or the information can be obtained as and when needed by the
> > agent from a
> > security server but what does this require the agent to have
> > in the way of extra
> > protocol support?
> >
> > The preference I expressed earlier was to have predefined
> > generic entries in the
> > agent with the manager (which I assume has got all the
> > necessary access to the
> > security infrastructure) providing a mapping from the
> > securityName it knows
> > which is sent
> > over the secure pipe, but I recognise that that could be
> > construed as not
> > integrating adequately with existing security infrastructure.
> >
> > So, regardless of SSH or TLS or ... I do not see a good
> > solution to this
> > problem.
> >
> > Any ideas?
> >
> > Tom Petch
> >
> >
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> >
>
>

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 24 Jul 2005 13:15:12 +0200

On Sun, Jul 24, 2005 at 10:21:11AM +0200, Tom Petch wrote:

> I take this as the same point Juergen made, that VACM is outside our 
> scope.  But if we eliminate the need for separate maintenance of 
> security credentials in the security model but leave it in place 
> in VACM, in the shape of the vacmSecurityToGroupTable, then I do 
> not see how we have achieved our objectives, hence my concern about 
> this (while recognising that VACM is a given, not to be

I am not sure I can follow you here. Please take a look at the diagram
in section 3.1 of RFC 3415. It shows quite clearly what the input for
a VACM access control decision is. Obviously, the "who" is identified
by the securityName. I fail to see how one can eliminate that from
the access control decision or how it can be dynamic. Somehow, the
security administrator has to specify to whom access is granted.

The ISMS charter basically boils down to the requirement that ISMS 
has to provide the securityModel, securityName and securityLevel 
triple needed by access control models such as VACM.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Tom Petch" <[email-masked]>
Date: Sun, 24 Jul 2005 18:14:37 +0200

<inline>
Tom Petch
----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 24, 2005 1:15 PM
Subject: Re: [Isms] securityName

> triple needed by access control models such as VACM.

The problem I see is more a VACM one but one that if neglected could undermine
the work of isms, namely that isms may eliminate the need for a SNMP-specific
security system for the security model in the 'agent' but that the maintenance
of eg  vacmSecurityToGroupTable with entries indexed by securityName still
requires organisations to maintain a database in every 'agent' of everyone in
the organisation with authority to perform some level of access to the MIB;
which may be sufficient hassle for SNMPv3 still to be regarded as unacceptable.
Hence my queries as to whether eg that table is kept up-to-date at all times, or
only when access is being checked.

So a principal with a high level of access loses that access; does the security
of SNMPv3 depend on that table being updated immediately in all 'agents' in the
network?

Having a secure pipe from 'manager' to 'agent' does allow us to do things in
different places or to look again at the semantics of securityName if that gets
round the problem (if there is a problem:-)

tom

---

From: "David B Harrington" <[email-masked]>
Date: Sun, 24 Jul 2005 23:15:45 -0400

Hi Tom,

Let me provide some historical background before I address your
concerns:

SNMPv3 was deliberately made modular so different portions of the
SNMPv3 standard could be upgraded independently of other pieces. From
RFC 3411: "This modularity allows, for example, Security Models,
authenication and privacy mechanisms, and message formats to be
upgraded and supplemented as the need arises."

The authentication subsystem has been deliberately kept separate from
the access control subsystem. They are related only in that the output
of the authentication subsystem is securityModel, securityName, and
securityLevel, and the input to the access control subsystem is
securityModel, securityName, and securityLevel.

In the same way, the application subsystem has been kept separate from
the access control subsystem. They are related via the
IsAccessAllowed() ASI. The access control model does not know which
application is asking the question, and the application does not know
the details of how the answer to the IsAccessAllowed() question is
arrived at.

The SNMPv3 standard was developed with a set of initial models for
each subsystem, to prove that the pieces could be developed following
the modularity rules, and so the system could be implemented and "put
to the test" so we could determine what problems needed to be
resolved, and then resolve those problems by the development of other
models for those subsystems. The initial models all have proven to be
usable (to varying degrees), but not convenient, especially for large
networks.

The single largest complaint is that all the initial models require
configuration via SNMP MIB modules (which can be populated via the
SNMP protocol or via other means within the instrumentation). This ia
a problems for a number of reasons - 1) many implementations do not
support SNMP SETs, 2) many deployments do not allow SNMP SETs, and 3)
many have considered the use of SNMP MIB modules to be "static"
configuration that is hard to keep synchronized with other existing
infrastructure. Many have expressed the desire that SNMPv3 standard
models be developed that automate the configuration by leveraging
existing non-SNMP infrastructure to make the dynamic information
available to SNMP entities, rather than populating MIB modules
dynamically via SNMP.

Some of the reported problems with the initial models:
1) Using USM for SNMPv3 authentication requires SNMP "static"
configuration.
2) Using VACM for access control requires SNMP "static" configuration.
3) Using the SNMP-TARGET-MIB (RFC 3413) requires SNMP static
configuration.
4) Using the SNMP-NOTIFICATION-MIB (RFC 3413) requires static
configuration.
5) Using the SNMP-PROXY-MIB (RFC 3413) requires static configuration.

**These are separable problems and, by SNMPv3 architectural design,
separate problems.** 

To address your concerns:
1) ISMS has currently been chartered to resolve the problem that using
USM for SNMPv3 authentication requires SNMP static configuration. 
2) ISMS has explicitly NOT been chartered to resolve the problem that
using VACM for access control requires static configuration. 

And concerns that you might get around to considering as well:
3) ISMS has NOT been chartered to resolve the problem that using the
SNMP-TARGET-MIB (RFC 3413) requires static configuration.
4) ISMS has NOT been chartered to resolve the problem that using the
SNMP-NOTIFICATION-MIB (RFC 3413) requires static configuration.
5) ISMS has NOT been chartered to resolve the problem that using
SNMP-PROXY-MIB (RFC 3413) requires static configuration.

I don't think anybody believes that simply solving the problem that
using USM for SNMPv3 authentication requires static configuration will
make SNMPv3 imminently deployable. The VACM problam also needs to be
resolved. Once these two problems are solved, SNMPv3 might be more
deployable, but the other problems of static configuration will
probably need to be resolved as well. 

ISMS needs to stay focused on solving the problems of one subsystem at
a time. We should consider the ramifications to other subsystems, but
solving the problems of those other subsystems is not in scope.

David Harrington
[email-masked]

> Sent: Sunday, July 24, 2005 12:15 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Jul 2005 20:21:00 -0400

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> I was rather assuming that if ssh-userauth authenticated a
    Tom> principal, then although that is a model dependent name to
    Tom> isms, it would be the same principal identifier as is used in
    Tom> other security systems in the organisation and would be the
    Tom> same as the securityName.  I don't see the merit in having a
    Tom> separate principal identifier and securityName, given that
    Tom> one of our aims is to integrate better with existing security
    Tom> systems.

I'm not at all sure this is true.  In general, SASL and other
application protocols have found it useful to separate the identifier
authenticated by a security model from the identifier (authorization
ID for SASL) used to make authorization decisions.  IN many cases
there is a simple mapping that can be overridden.

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 28 Jul 2005 18:19:07 +0200

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 26, 2005 2:21 AM
Subject: Re: [Isms] securityName

> there is a simple mapping that can be overridden.

Sam

I've thought about this for 48 hours and still don't understand it:-(

securityName in SNMPv3 is intended to identify a principal in a security-model
independent manner and as Juergen pointed out, in USM that is likely to be the
identity mapping with the userName.  All I was saying was that that would be
a good starting point for any security model.  And in SNMPv3, the role of the
security model is message level security, timeliness, encryption,
authentication, not authorization.

So I am not sure where your comment about identifier for authorization decisions
comes from.  I have said elsewhere that I see groups as a - the - key part of
authorization so if you mean having an authenticated-principal-identifier
mapping into one or more authorization-groups, then I agree.  And as this thread
has explored, the presence of that mapping in the 'agent' does create a
configuration workload issue that I see as a bar to the deployment of SNMPv3.