RE: [Isms] #32: is the securityName=username default OK?

["Blumenthal, Uri" <uri.blumenthal at intel.com>]

> > Easily. SNMPv2p (that was implemented and did see some limited
> > deployment) identified entities by ASN.1-encoded OIDs.
>
> Fine, but the ISMS charter is to develop an additional security
> method for SNMPv3.

And SNMPv3 was designed to deal with more than one [different] security
model without breaking the rest of the architecture. That includes
security models that, like SNMPv2p, do NOT identify their entities by
human-readable strings.

You wanted an example of such security model - you were provided an
example (which, as I said, was implemented and deployed - though not
widely).

> > First, who said that successful design must be "fundamentally
> > different"?
>
> I, for one, would certainly make that statement.  If there isn't a
> significant difference, why expend the efforts of an IETF WG?

It has to differ in the important areas of dissatisfaction with USM.
There's no need for "fundamental difference" to address those (and IMHO
ISMS isn't so "fundamentally different", so far at least). 

IETF WG efforts normally are [supposed to be] expended to create a
technically acceptable deployable protocol that takes care of something
that other protocols don't (or don't do as well). "Being fundamentally
different" is a silly useless goal to begin with. As a home exercise -
consider what in TLSv1 is "fundamentally different" from SSLv3, and in
TLSv1.1 - from TLSv1.0.

> > Second - most SSH installations have some local info both about the
> > SSH config, AND about the users that can login via SSH. Often this
> > info is shared with operating system user list - password file(s),
> > but so what - the point is that local systems more often than not
> > store relevant per-user information locally.
>
> Sigh.  Having chosen SSH as the security transport, let's not lose
sight
> of the fact that the original problem was to integrate SNMPv3 security
> with existing authentication infrastructures. 

Which for some are local password files.

> That has to include AAA systems, as well as KDC systems.

But not PKI? :-)

> SSH implementations that rely on local password files are
> indistinguishable, IMHO, from USM in terms of being
> tied to locally configured user information, and therefore
> not scaleable.

People apparently aren't bothered by "scalability" - they simply don't
want YET ANOTHER infrastructure to manage. If today they're happy with
local password files (or domain logins) - that's what they want SNMP to
use for security. Of course Kerberos users want Kerberos, and AAA users
- want AAA.

> If we are considering a class of managed entities that includes native
> support for distributed authentication systems (e.g. NIS or Active
> Directory), then I see your point.  My understanding is that the class
> of managed entities we are primarily considering is embedded systems
> that do not have such native support, and are reliant on protocols
such
> as RADIUS, Diameter, TACACS, Kerberos, etc. for centralized AAA.

No, even embedded systems aren't necessarily AAA- etc. reliant. Some
are, some aren't... Welcome to diversity. :-)

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms