Subject: RE: [Isms] securityName

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 27 Jul 2005 08:47:22 -0400

I think Randy is 100% correct in his evaluaion of  usage of VACM in
general and vacmSecurityToGroupTable in particular.

More so, I too consider the user-to-group mapping as a "glue" that is
necessary for any practical solution. Without such glue packet/user
authentication and packet encryption is useless. More so, I believe that
dynamic authentication is necessary if people want to avoid static
pre-configuration of SNMP users. 

Having one source providing all of the following: <user identity,
authenticity, mapping to VACM group>, seems well aligned with the ISMS
goal to use external-to-SNMP already-deployed security infrastructure
and to off-load the configuration and decision-making burden to somebody
else (RADIUS in case of EUSM).

Kaushik, I agree with what you said.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kaushik Narayan
Sent: Sunday, July 17, 2005 12:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Isms] securityName

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!

At 08:13 PM 7/26/2005, David B Harrington wrote:
>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]
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Randy Presuhn
> > Sent: Tuesday, July 26, 2005 8:37 PM
> > To: [email-masked]
> > Subject: Re: [Isms] securityName
> >
> > Hi -
> >
> > > From: "Juergen Schoenwaelder" <[email-masked]>
> > > To: "Tom Petch" <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Saturday, July 23, 2005 9:11 AM
> > > Subject: Re: [Isms] securityName
> > >> On Sat, Jul 23, 2005 at 03:26:47PM +0200, Tom Petch wrote:
> > ...
> > > > 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.
> > >
> > > 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.
> > ...
> >
> > 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-c
> > omparison-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
> >
> >
> >
> >
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> >
>
>
>
>_______________________________________________
>Isms mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
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: "David B Harrington" <[email-masked]>
Date: Wed, 27 Jul 2005 09:38:00 -0400

Hi Uri,

> else (RADIUS in case of EUSM).

I agree that this is a nice feature of RADIUS. But what about security
models that don't use RADIUS? Is this also a feature available from
say, SSH or TLS or Kerberos or other security infrastructure? If not,
who provides the dynamic user-to-group mappings? 

Do we call RADIUS after we have authenticated and decrypted the
TLS-protected message, to get the user-to-group mappings? Will this
require another user-authentication step?

If the BEEP TMSM proposal is accepted, for example, how will the
user-to-group mappings be accomplished? Is this something that all
proposed security models must specify?

David Harrington
[email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Sun, 17 Jul 2005 08:05:10 -0700

Hi David,

Here is a list of external authentication mechanisms that are required to be
supported from the ISMS charter

- Radius
- TACACS+
- Kerberos
- LDAP
- Diameter

All of these authentication protocols except for Kerberos have means to 
acquire
user-to-group mapping and provide that information to SNMP engines. RADIUS,
TACACS+ and Diameter require appropriate attributes to defined to communicate
this information. Acquiring Group information in LDAP is pretty standard.

Kerberos is probably the only exception since this is implementation specific.
Only the Windows KDC acquires the AD user groups and saves that information in
the Privilege Attribute Certificate (PAC).

The user-to-group mapping will work identical with any ISMS transport protocol/
security model.

regards,
   kaushik!

---

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

----- Original Message -----
From: "Kaushik Narayan" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 17, 2005 5:05 PM
Subject: RE: [Isms] securityName

> supported from the ISMS charter

Well, no, that is not what I see or would ever want to see in the charter
because I would regard it as impossible if it weren't that already.  What I see
the charter say is

"The following security infrastructures will be considered by the working group
as potential existing
authentication infrastructures to make use of within the new security model. The
solution will hopefully be able to be integrated with multiple of these user
databases although it is expected that one will be mandatory.

- Local accounts
- SSH identities
- Radius
- TACACS+
- X.509 Certificates
- Kerberos
- LDAP
- Diameter"

So we have to support one, hopefully more than one, never all.  And notice that
the order of the list is that of the percentage currently using it as revealed
in Wes' survey, so support for SSH counts for more than support for LDAP, by an
order of magnitude.

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 28 Jul 2005 11:01:57 -0700

Sure. I did not intend to mean that all of these authentication mechanisms were
mandatory to support for ISMS. I was just trying to explain that most of these
authentication protocols/mechanisms have means to communicate the user group
names to SNMP engines.