Subject: [Isms] securityName

From: "Tom Petch" <[email-masked]>
Date: Fri, 22 Jul 2005 21:37:39 +0200

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

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 22 Jul 2005 15:31:01 -0700

Hi Tom,

I think the assumption at least in my mind has been that the
securityName would be stored part of a session object that
is created after a successful security context has been
created at the transport layer. This session object MUST be
managed by the new security  model which would be responsible
for clean up as sessions are invalidated.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 22 Jul 2005 19:24:20 -0400

Hi Tom,

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.

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.

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
>

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 23 Jul 2005 15:26:47 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Kaushik Narayan" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Sent: Saturday, July 23, 2005 12:31 AM
> for clean up as sessions are invalidated.

Two queries.

1) I see a secure pipe between manager and agent over which PDU from multiple
securityName are multiplexed; when you say session, is that per securityName or
per manager-agent pair?  eg SSH has a host key which can be used to create a
secure pipe but I did not envisage that as fine enough granularity to
differentiate separate securityName

2) when does the entry in the vacmSecurityToGroupTable get created, when
destroyed w.r.t. a session? I see maintenance of that table as a problem.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 23 Jul 2005 18:11:52 +0200

> differentiate separate securityName

I think the securityName comes from the authentication protocol which
usually in my environment authenticates a user identity. Yes, this
requires to have different ssh connections if different identities
access a device. But I think this is also how you get into most CLIs
as a different user.
 
> destroyed w.r.t. a session? I see maintenance of that table as a problem.

For me, the vacmSecurityToGroupTable belongs to the access control
configuration on the device and I therefore believe this is out of
scope for ISMS at this point in time.

/js

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

---

From: Kaushik Narayan <[email-masked]>
Date: Sat, 23 Jul 2005 11:37:54 -0700

Hi Tom,

Please find reply inline.

<snipped>

>differentiate separate securityName

That's not accurate, there will need to be multiple secure pipes, one for each
securityName since the channel is negotiated for a specific securityName.

>destroyed w.r.t. a session? I see maintenance of that table as a problem.

I am not sure we need to use existing VACM MIB objects to hold ISMS session
state information, we should probably look at new MIB objects for ISMS, i.e.
the securityName to group mapping would be dynamic and won't be part of the
MIB for ISMS security models. The other parts of VACM such as views, groups
etc. will be managed via the VACM MIB.

regards,
   kaushik!

> > >so a securityName can be safely transmitted from one party to another 
> but I
>do
> > >agent (a low powered, low function, remote Command Responder), there 
> must be
>a

---

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

<inline>
Tom Petch

----- Original Message -----
From: "Kaushik Narayan" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 23, 2005 8:37 PM
Subject: Re: [Isms] securityName
> securityName since the channel is negotiated for a specific securityName.

Just to be clear about SSH; what I hear is that there can only be one
ssh-userauth per ssh-transport so while there can be multiple ssh-connection,
they all relate to the same ssh-userauth. Yes?

The consequence then: either, if ssh-userauth corresponds to a principal and
securityName, then, as you say, there must be multiple transports, one per
principal; or ssh-userauth, like host key, is on a per box basis in which case
we could have one principal per ssh-connection but ssh will not provide
authentication of them.

How does this interact with other uses of ssh such as telnet?  Does each telnet
user set up a separate transport?  If the same principal were to use telnet and
isms, would they use the same transport with different ssh-connections?

---

From: Kaushik Narayan <[email-masked]>
Date: Sun, 24 Jul 2005 12:31:10 -0700

Hi Tom,

<inline>

>isms, would they use the same transport with different ssh-connections?

To answer your question, each SSH user will use a separate transport.

The question of whether the telnet (NetConf, Syslog) and isms can share a 
single
underlying transport session and leverage multiple connections within the same
session is an open item for the WG to discuss.

regards,
   kaushik!

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 25 Jul 2005 14:58:14 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Kaushik Narayan" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 24, 2005 9:31 PM
Subject: Re: [Isms] securityName and eg SSH

<snip>
single
> session is an open item for the WG to discuss.

Funny you should say that.  Another question that I have is what ports isms
should use?

Some time ago, there was a discussion about the use of ports when an application
started using security, should the port be that of the application or of the
security protocol or something else; as I recall, this was on the main IETF
list although I cannot find it at present.

I notice netconf over ssh has gone for something else, asking for a new port
from IANA (I know, there isn't a netconf native application port per se).

tom

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Jul 2005 16:40:22 +0200

> from IANA (I know, there isn't a netconf native application port per se).

See the analysis in Kaushik's draft about this.  It boils down to
intended use.  I personally think ISMS and NETCONF should share a port.
 The reason SSH does not share a port in NETCONF is that it is possible
for SSH to be used for non-administrative purposes (like users logging
in to read mail) and one might want a different firewall policy for one
versus the other.

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 17:36:30 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> Sent: Saturday, July 23, 2005 9:11 AM
...
> scope for ISMS at this point in time.
...

However, I'd like to remind folks what we wrote in section 3.3 of
http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt

   Dynamic authentication of users is not operationally sufficient,
   given how VACM works.  Requiring security administrators to
   pre-configure the vacmSecurityToGroupTable [RFC3415] for dynamically
   authenticated users would defeat the whole purpose of doing dynamic
   authentication.  Consequently, the evaluation team recommends the
   inclusion of something similar to the EUSM proposal's mechanism for
   conveying user-to-group mappings from the AAA-server-equivalent.
   This should not be confused with full-scale configuration of VACM,
   which is out of scope for this working group.

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 26 Jul 2005 23:13:35 -0400

Hi Randy,

I have serious concerns with the EUSM dynamic population of the
vacmSecurityToGroupTable.

The SNMPv3 architecture separates authentication from access control
so that subsystems can be updated with new models independent of other
subsystems. We need to make a decision about which subsystem defines
the user-to-group mappings or the architectural modularity goes to
hell. The SNMPv3 WG decided this should be done in the access control
subsystem.

As I recall, the consensus of the SNMPv3 WG was that not all access
control models would necessarily support a security-to-group mapping.
VACM represented one approach to access control, but there were
supporters of other approaches as well, especially for purposes of
leveraging existing access control mechanisms. We need to be careful
we don't limit future access control models to accommodate the VACM
approach in this case.  

The EUSM approach of dynamically configuring the
vacmSecurityToGroupTable  violates the SNMPv3 architecture goals,
since another security model (such as USM) would not necessarily do
this dynamic configuration of VACM tables, and an access control model
that doesn't use the vacmSecurityToGroupTable cannot work with the
EUSM proposal. 

If the consensus of this WG (and the rest of the IETF, of course) is
that it does make sense to require all security models to also
generate a securityGroupName, then maybe we should define a
user-to-group mapping table as part of the security (authentication)
subsystem rather than as part of the access control subsystem, and
modify USM and VACM to shift the vacmSecurityToGroupTable
functionality into the USM security model, and change the ASIs to pass
a groupname.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Tuesday, July 26, 2005 8:37 PM
> To: [email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Sat, 16 Jul 2005 21:50:08 -0700

Hi David,

If we retain the user to group mapping as part of the access control
subsystem (VACM), even though might obtain external user
authentication via ISMS, we will still need operators to define all users
on all agents since user to group mapping would need to be done
locally. This will be a significant deterrent to ISMS deployment.

This is the reason we took a pragmatic approach in EUSM by allowing
the security model acquire the group mapping from the authentication
system that can then be used by the access control model. This is a
very common model of integration of access control with multiple
authentication systems.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 27 Jul 2005 09:20:45 -0400

Hi,

I understand why this was done, and I personally prefer that the
user-to-group mapping be done as part of the authentication mechanism
for exactly the reasons that you and Randy and Uri argue - if we don't
automate this dynamic mapping, the goals of ISMS (as compared to the
charter of ISMS) will not be met, and user adds/deletes would be
difficult to work with. I think it makes sense because the
user-to-group mapping is likely to be as volatile as the
user-authentication itself, while the rest of the access control
subsystem configuration is likely to be fairly static.

My issue is about compliance with the modularity requirement. We
cannot have the user-to-group mapping done by some, but not all,
security models, or, in order to provide group-level access controls,
the  access control models will need to know about the "glue" provided
by different security models, and we end up with unwanted bindings
between the models. We need to make it unambiguous which subsystem has
the responsibility for this task, and what the interfaces between
subsystems (ASIs) look like, or security models and access control
models cannot be freely mixed and matched. 

After the SNMPv2 meltdown, which was largely the result of the SNMPv2
architecture being monolithic rather than modular so you could not
address specific issues without causing side effects on everything
else, I don't want to see us throw out the modularity requirements. I
cannot stress enough how important modularity is to SNMPv3 being able
to accommodate different industry segments' differing requirements.

If everybody is in agreement that the user-to-group mapping
functionality should be handled by the authentication subsystem, then
I suggest we figure out a way to make such an architectural change to
SNMPv3, and retro-fit USM and VACM to that change. This, of course, is
out of scope for this WG, but might be a necessary change to meet ISMS
goals. If we are not allowed to modify the architecture, then we may
need to provide a standard hack to achieve the same effect.

If the security model has the responsibility, then we need to
determine how that mapping gets passed to the access control
subsystem. It might be as simple as standardizing a modification to
securityName, to use a format similar to "user (group1, group2, ...)",
or simply passes the groupname as the securityName (but this would be
difficult for specifying the outgoing user-principal). If we do this,
we need to make it standard so security models know how to construct
the securityName, and access control models know how to extract the
information in a consistent manner. 

How and whether different access control models utilize the group
information would be up to the specific access control models. 

David Harrington
[email-masked]

> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Sunday, July 17, 2005 12:50 AM
> To: [email-masked]
> Cc: 'Randy Presuhn'; [email-masked]
> Subject: RE: [Isms] securityName
> 
> Hi David,
> 
> > >    inclusion of something similar to the EUSM proposal's
mechanism
> >for

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2005 14:36:13 +0200

> very common model of integration of access control with multiple

What about an extension of the VACM security name to group mapping
feature which allows to express policies like "all access with a given
security level for a given security model map into group xyz". Such a
rule would not need to change if you add/remove authenticated
identities and it probably is good enough for many operational
environments. For those who need finer grained access control, you can
still use the existing VACM security name to group mapping mechanism.

I am thinking loud here - so there might be reasons why this won't
work. But that put aside, if something like this makes sense, I still
consider this architectually an extension of VACM.

/js