Subject: RE: [Isms] securityName

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 28 Jul 2005 10:52:33 -0400

>> I'm not sure how authentication would work for a TMSM approach, if
the
>> SSH user used for authentication is in fact a different user,
>> especially if a CHAP authentication is used to establish a session.
>> For this reason, the securityName really needs to identify the
>> principal, not just a group mapping. 
>
> Not sure I understand your concerns here. You authenticate a user and
> an AAA server provides a user to security name mapping.

The point is that conceptually and traditionally Security Model did not
determine such mapping by itself, and limited its scope of knowledge to
the principal it authenticated. Assumption was - somebody outside of
SNMP (statically ?) defined/configured that mapping.

What ISMS is actually doing is a meta-framework, because the "principal"
of per-message security becomes "session ID". That "extra piece of
functionality" can (and IMHO should) do both establish the "session ID"
(or "session principal") based on the "high-level" principal who
authenticates the initial exchange, and setting up access control for
this session.

It seems to me that the issue is not "how to bolt TLS (or SSH) onto SNMP
so that users somehow authenticate without creating an extra database",
but "how to accomodate architecturally addition of sessions and ACM
mappings".

>> It might be ok to pass both the principal and group(s) in the
>> securityName. However, if we modify the semantics of securityName,
>> then all RFC341x references to securityName will subsequently be
>> wrong.
>
> Why? Does RFC 341x say somewhere that the security name must directly
> identify a principal?

securityName identifies a principal, and if one cannot unambiguously map
back from securityName to an authenticated principal, the effect is of
sharing userID's - a practice reasonable people frown upon.

> My understanding is that we have the desired N:1 mapping table in VACM
> and the only concern that I heard hear on this list is that people do
> not want to touch this table when they add/remove users and they
> prefer that this mapping actually comes from say an AAA server. How
> does introducing another table solve that problem?

Jurgen, I'm with you here.

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

Workable - assuming that *Security* model is not chartered with it.

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

First, this is ugly as a mule. Second - it breaks identification for
cases when it matters. Right now only audit and VACM care who it is that
authenticated the request. In general, it is not necessarily so. A
Security Model should not authenticate a group, and It should be clear
outside of the given Security Model what principal it dealt with.
Grouping is ACM's job.

> 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'd prefer to see an extra module that does it. So I am for your option
(c).

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):

> Any other options to consider which I forgot to list?

Those above are enough, methinks. :-)

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