Subject: Re: [Isms] securityName

From: "Tom Petch" <[email-masked]>
Date: Mon, 1 Aug 2005 10:00:56 +0200

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>; "'Dave Harrington'" <[email-masked]>
Sent: Thursday, July 28, 2005 9:50 AM
Subject: Re: [Isms] securityName

> On Thu, Jul 28, 2005 at 02:51:28AM -0400, David B Harrington wrote:
>
> > -- requirements for a hack --

<snip>

> I see these options:
>
> a) provide a mechanism to retrieve (at least parts of a) VACM configuration
>    from an AAA server (not in our charter)
>
> b) do a N:1 mapping from user identities into security names in the
>    ISMS security model (rather than doing a 1:1 mapping like USM)
>
> c) generally change the SNMP architecture providing new or extended
>    ASIs to actually make this mapping something between the security
>    model and the access control model (not in our charter)

I am not sure that this is not in our charter.  To quote TMSM
"The RFC3411 ASIs would not need to be changed since the SNMPv3 WG expected that
additional parameters could be passed for value-add features of specific
implementations"

Passing the group name in isAccessAllowed adds substantial value when it reduces
the need to maintain AAA information in the 'agent'.  OK, I exaggerate slightly
but I think it hard to draw the line between adding references to a
tmStateReference that contains session and master keys and adding a reference to
a something that contains a securityName to vacmGroup mapping.

In which case, option a) is wide open as well eg by allowing the 'manager' to
retrieve the mapping and pass it over a secure pipe to the TMSM.

Tom Petch
>
> There are now technical pros and cons for all these options and there
> are process (charter) issues to consider. There was also the other
> option (not sure it really counts as an option):
>
> d) provide a wildcard mapping extension to VACM which can be exploited
>    to map all security name with the same security level and security
>    model together into a vacm group (works only on simple setups where
>    you basically do not distinguish between different MIB views for
>    authenticated users - but perhaps this is a low hanging fruit that
>    covers most existing VACM configurations anyway)
>
> Any other options to consider which I forgot to list?
>
> /js
>

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Aug 2005 02:36:30 -0700

>>>>> On Thu, 28 Jul 2005 09:50:07 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> d) provide a wildcard mapping extension to VACM which can be
Juergen> exploited to map all security name with the same security
Juergen> level and security model together into a vacm group (works
Juergen> only on simple setups where you basically do not distinguish
Juergen> between different MIB views for authenticated users - but
Juergen> perhaps this is a low hanging fruit that covers most existing
Juergen> VACM configurations anyway)

FYI (I'm trying in vain to catch up on mail before the coming WG
meeting; sorry for not responding to your previous note about this
idea), David P and I talked extensively about this one day about a
year ago or so.  Over the phone, we actually decided it was possible
to do what you've described above as an extension to the existing VACM
tables without requiring modifications to it (a good thing; IMHO).
However, we also talked about wildcarding many things, not just the
security names.  Security names to a single group mapping in a default
case ("*" => "defaultAuthor") makes a lot of sense so that you can
deploy generic access rules and having them apply to all unknown
users.

However, the other thing that we realized would be needed would be to
say things like any user "Jack" coming in over any SM protocol should
be mapped to "admin" or something like that.  The reason for this
style of wildcarding too is so you can deal with cases where we may
have a lot of different future security models (eg, one for BEEP one
for TLS/SASL using kerberos, one for ...).  I believe that different
mechanisms of authentication should result in their own security model
numbers so you *can* distinguish differences between week and stronger
transports in the VACM, but you then needed wildcarding of all of
names, levels, and security model numbers so wouldn't make deployment
more difficult when more fine grained decisions weren't needed.

However, I do think it's critical that the resulting potential
solutions from this WG for authentication and authorization not be
bound together by requirement.  Thus I see these three parts of the
solution as independent and should be separate work items:

1) authentication (current major charter goal)
2) authorization configuration (referenced but not a direct goal)
3) the wildcard mapping to make configuration easier regardless of
   whether it's static or comes from #2

I think they *all* need to be solved, but I disagree that any of them
need to be explicitly bound together.  Any document that specifies a
solution for #1 and allows for #2 but only when the solution for #1 is
in use fails to meet the broader goal of making #2 possible in all
cases.  SMs and ACMs in SNMPv3 are not bound together today, and they
shouldn't be in the future.  There is no reason that an ACM
configuration solution (over something centralized like AAA/radius or
anything else like some other magic mapping) needs to be explicitly
bound to a particular transport protocol.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 01 Aug 2005 05:16:36 -0700

>>>>> On Mon, 1 Aug 2005 10:00:56 +0200, "Tom Petch" <[email-masked]> said:

>> model and the access control model (not in our charter)

Tom> I am not sure that this is not in our charter.  To quote TMSM
Tom> "The RFC3411 ASIs would not need to be changed since the SNMPv3
Tom> WG expected that additional parameters could be passed for
Tom> value-add features of specific implementations"

The ASIs are described as examples and their arguments should not be
treated as a function (thus they're not called APIs).  When I (and
others) suggested dropping the argument list from the ASIs before the
v3 specs were published, the consensus was that they were useful even
though they may not be perfect in the future and nobody in their right
mind would treat them as APIs and would get what they had coming if
they decided they were fixed in stone.  I should go find the specific
thread from the SNMPv3 archives, but I'll pass...

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 1 Aug 2005 09:54:56 -0400

Hi,

Let me clarify the purpose of the ASIs: ASIs serve to differentiate
the functional responsibilities/requirements of the subsystems, and
identify the information that must pass between the subsystems
(similar to data flow diagrams). 

As Wes points out, ASIs are not implementation constraints, and do not
describe how implementations must modularize their code. 

However, ASIs **were** designed as constraints on future **model
proposals**, to ensure interoperability between model proposals for
one subsystem and model proposals for other subsystems. 

One concrete implication of this modular approach is that each
subsystem has its own MIB module(s) that are independent of the MIB
modules for other subsystems. The goal was to make MIB modules local
to each subsystem rather than global in scope to prevent side-effects
between subsystems. This was done deliberately because SNMPv2 had a
horrendous problem with side-effects between the different types of
functionality because the one MIB module for SNMPv2 was shared by all
functional processing, and was constantly tweaked to meet different
requirements, which caused unseen side-effects that violated other
requirements.

The SNMPv3 WG did recognize that in the future it may be desirable to
add additional parameters to the ASIs, but it is important to
standardize such additional parameters because it could create
bindings between models that do not exist between subsystems, and such
model-dependent bindings would defeat the purpose of the subsystem/ASI
modularity. So, if we are going to add parameters to the ASIs, the
parameters should be standardized, and co-existence with earlier
models needs to be addressed. 

If the xxxxSecurityToGroupTable were moved to the SM subsystem from
the AC subsystem, that we need to address how to reconcile this shift
of responsibility from the existing AC models (VACM) to the existing
SM models (USM and Community), how to move the MIB module from one
subsystem to the other subsystem, and how to document the change to
the architecture and the models given the IETF/RFC process.

If the TMSM is going to pass transport information from the transport
mapping to the SM subsystem, either through a cache or an ASI
parameter, we need to standardize how this is done, how it affects
existing models and MIB modules, and how to document these changes
within the IETF.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wes Hardaker
> Sent: Monday, August 01, 2005 8:17 AM
> To: Tom Petch
> Cc: [email-masked]