Subject: RE: [Isms] securityName

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 27 Jul 2005 12:29:28 -0400

<rambling mode on>

>> 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).
> 
>
> 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?

The answer of course is - SNMP (Simply Not My Problem). Obtaining this
mapping SOMEHOW SOMEWHERE BY SOMEBODY clearly is a-must - without it
security model cannot be used. Some authentication systems deal also
with authorization, and thus are capable of providing such mapping as
part of their "normal" service. Some others - this capability can be
hacked into. And some just can't do it, tough luck - for those an extra
service must be designed/implemented/deployed together with this new
security model, or the whole thing won't be deployable (what good is
having TLS-authenticated and encrypted traffic stream, if there is no
way to specify whether or not execute the  commands carried by that
stream?).

The short of it is - it has to be done, somehow somewhere. The easiest
place for it is nEWSM (see below), as it encapsulates this extra work
from other components. And while it doesn't HAVE to be a part of nEWSM
itself - releasing a security model without a clear idea of how its
output will be mapped onto VACM (or other ACM), IMHO is a waste of time.

> 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?

IMHO, no.  Caveat: I'm coming from the idea of sessions. Otherwise the
cost of online queries and possible public key cryptography cannot be
justified (it got to be amortized across multiple exchanges utilizing
the same credentials that were obtained and paid for so dearly, tied
together into a "structure" I call "session").

When this nEWSM (not Extended Wonderful Security System) negotiates and
establishes a "session", in addition to figuring out what identities are
being authenticated and authenticating them, what crypto parameters to
use (auth and encr algorithms, keys, lifetime, etc.) it also figures
what access rights the authenticated identities should have to SNMP
objects and maps those rights onto VACM by providing SecurityToGroup
table entries.

IF NEWSM DOES NOT DO THAT. {
 If nEWSM doesn't do that - then somebody else has to either 
  (a) recognize the identity as it comes out of nEWSM, preferably
      at the time of(or soon after) the successful authentication.
      So that subsequent traffic messages can be processed without
      undue delay and overhead;
  (b) know what VACM rights to give to it;
  (c) express that knowledge by populating vacmSecurityToGroupTable.
 or
  (a) beforehand know all the possible identities that can
      come out of nEWSM;
  (b) determine what rights to assign them; and
  (c) express that knowledge by populating vacmSecurityToGroupTable.

 Also, this may increase the difficulty of using
 dynamic names for SNMP authentication and sessions, difficulties
 in figuring out lifetime of authentication  (for how long should
 authentication result be valid?) etc. etc. It also may mean that
 SNMPv3 architecture changes and a new Module is introduced:
     SM-to-ACM Mapper, with defines functionality, ASI,
 interfaces, etc.
}

One simple alternative is: "all the identities coming from nEWSM are on
the same level and shall be granted access level X defined by VACM group
Y", then define a VACM group for nEWSM. It can work - but makes logging
more difficult, and is a touch hard on access granularity. And still
somebody has to insert that one entry into VACM table.

Another alternative is - write a piece of code that maps Unix groups
onto some very limited VACM groups and populate vacmSecurityToGroupTable
with those. Then have nEWSM use Unix identities as securityName, and an
extra module that determines the group by doing system lookup. Of course
those who do not use Unix groups in their security infrastructure, won't
be happy with this approach.

These poor alternatives are brought here mostly to demonstrate the
importance of that mapping, and the great benefits of having it somehow
integrated into Security Model, rather than having to figure it out
elsewhere.

> If the BEEP TMSM proposal is accepted, for example, how will the
> user-to-group mappings be accomplished?

Don't know. SNMP (see above :-).

> Is this something that all proposed security models must specify?

IMHO - yes. Because no nEWSM can be deployed, until a co-proposal is
written and accepted - that defines how to use securityName's it returns
with VACM. Because otherwise those who find it difficult to populate and
maintain User database and want to off-load it to RADIUS or Kerberos,
will surely find it as difficult to populate and maintain VACM
user-to-group database (as the problems are very tightly coupled). In
the end, they still won't deploy it until all the I's are dotted.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2005 20:08:28 +0200

> integrated into Security Model, rather than having to figure it out

The security name to group mapping is just a little piece of the access
control decision. I fail to see why solving this piece is of such high
importance while we ignore the rest.

I believe that the rest (that is the definition of suitable vacm views)
is rather static and on most devices will not change much during the
lifetime of the device. I also believe that a wildcard authenticated
user via mechanism xyz maps to group abc is going to be rather static
in most installations and hence it can be configured like all the
rest of VACM.

Sure, having the capability to retrieve VACM rules from a trusted AAA
server would be nice. I doubt, however, this is as crucial for this
work to succeed than some of the other people here. Anyway, if this
is crucial, then I think the proper solution is to fix the charter.

/js

P.S. I believe there is quite some confusion in this discussion about
     the usage of the word "group". VACM groups are surely very different
     from UNIX groups and I also believe that some of the AAA protocols
     mentions have yet other interpretations of groups. Perhaps this
     needs to be untangled in Paris.

-- 
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: Wed, 27 Jul 2005 21:09:42 +0200

<cherry picking the part I feel strongest about>
Tom Petch
----- Original Message -----
From: "Blumenthal, Uri" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 27, 2005 6:29 PM
Subject: RE: [Isms] securityName

<rambling mode on>

[tp]

Yes, absolutely.  isms is about reusing existing security systems at least in
part, whereas SNMPv3 USM + VACM set out to do everything alone and unaided.  We
have left open the question of just what we get from an existing security system
(beyond authentication of an enduser) and for me, the more we use, the more we
integrate, the better.  I am used to a widely deployed proprietary security
system (it did get a mention in Wes's survey) which does provide very fine
grained and powerful definitions of authorization, access rights, privileges
etc.  So I have no problem with a solution that says that this information,
mapping of end user to role and authorization, comes from elsewhere, be that
open standard like RADIUS or proprietary, as I am more used to.

<snip>