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

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Tue, 25 Oct 2005 08:52:56 -0700

Hi David,

I think some authentication systems and even some domains such as DOCSIS
might require mapping of the authenticated "name" to a securityName. It
might be better to handle this within ISMS configuration (which would
probably be implementation dependent) and not security model independent
configuration since the mapping might be specific to particular
authentication systems.

regards,
  kaushik!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Monday, October 24, 2005 8:31 AM
To: [email-masked]
Subject: RE: [Isms] #32: is the securityName=username default OK?

David B Harrington writes...

> So, if the mapping between a mechanism-specific "username" and a 
> corresponding securityname is not explicitly specified in the Local 
> Configuration Datastore, then is setting securityName to the username
> (tmSecurityname) associated with the session the right thing to do?

While nothing would preclude having USM-style local configuration
information dealing with the creation of securityName, I think the
straightforward thing to do is eliminate any local configuration
dependency and *always* use the tmSecurityName as the securityName. 

This effectively deprecates the concept of a model independent
securityName.  While that was probably a nice concept in theory, and
practical as long as local configuration was intrinsically part of the
authentication mechanism, I think it makes little sense when used with
existing authentication (or AAA) infrastructures.  Remember, the whole
premise is to leverage existing, centralized identity management, so
having to configure an identity transform on each managed entity makes
no sense to me.  We don't want to have to configure the identities on
each managed entity, so why should we have to configure an identity
transform?

IMHO, the proposed default behavior is the only required behavior.

_______________________________________________
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: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 25 Oct 2005 13:21:03 -0400

>> I think some authentication systems and even some domains
>> such as DOCSIS might require mapping of the authenticated
>> "name" to a securityName.
>
> I suppose there might be such a requirement,
> but could you give us a concrete example?

Easily. SNMPv2p (that was implemented and did see some limited
deployment) identified entities by ASN.1-encoded OIDs. 

> If the tmSecurityName is a function of local per-user (or
per-meta-user)
> configuration information, then how is ISMS fundamentally different
from
> USM? 

First, who said that successful design must be "fundamentally
different"?
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. The major complaints about USM that I'm
aware of are: (a) USM requires SEPARATE infrastructure IN ADDITION to
what's already deployed, and (b) USM lacks short-lived session keys and
decent key update mechanism.

> ISMS is supposed to be more than USM over SSH.  :-)

Is it? :-)

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Oct 2005 13:49:23 -0400

Uri Blumenthal writes...
 
> deployment) identified entities by ASN.1-encoded OIDs.

Fine, but the ISMS charter is to develop an additional security method
for SNMPv3.

> First, who said that successful design must be "fundamentally

I, for one, would certainly make that statement.  If there isn't a
significant difference, why expend the efforts of an IETF WG?

> 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.  That has to include AAA
systems, as well as KDC systems.  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.

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.

> > ISMS is supposed to be more than USM over SSH.  :-)

Yes, I think so.

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Oct 2005 14:10:23 -0400

> I think this discussion is going off into ratholes.

What may be a rathole of inconsequential detail for one may be a
fundamental requirement for another. YMMV.

> Allowing for
> static configuration does not REQUIRE static copnfiguration, nor
> preclude dynamic configuration; Allowing for dynamic configuration
> does not preclude static configuration where desired.

Granted.  I see no harm is allowing the option for local, static
authentication information.  OTOH, my opinion is that, if local, static
authentication information is *all* you need, then USM meets your
requirements today.

> A AAA system could provide a mapping that is stored in the LCD as part
> of the session configuration. In this case, the securityname is not
> necessarily the same as the username used for authentication. For
> example, RADIUS permits sending an accounting identity to be sent as
> part of the ACCESS-ACCEPT message, if I recall correctly. This could
> be stored in the LCD and thus be "picked up" as the value for
> securityName rather than defaulting to the "username" field from the
> ACCESS-REQUEST message (which is the current source for the tm-cached
> identity).

It could, but why is this a requirement for ISMS?  I may be dense, but I
still fail to see the value added by this additional complexity.

> If desired, an SNMP MIB could be designed, comparable to the USM-MIB,
> that permitted static assignemnts of usernames to securityNames.

Yes, and that would make ISMS significantly different from USM in what
way?
 
> If desired, an LCD, possibly but not necessarily in MIB format, could
> be populated using CLI scripts or other non-SNMP configuration.

Ditto.

I don't object to a "compatibility" mode for ISMS in which it
effectively behaves as USM, but if that is all we see as needed, then I
suggest we don't bother and close the WG.  I firmly believe that in
order to be successful, and solve the customer problems that USM does
not solve, that ISMS MUST have a mandatory to implement mode of
operation in which it is fully independent of any locally configured
per-user (or per-meta-user) authentication information.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 25 Oct 2005 14:30:12 -0400

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

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

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

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Tue, 25 Oct 2005 11:34:14 -0700

Hi David,

Please find my reply inline. 

I suppose there might be such a requirement, but could you give us a
concrete example?

<Kaushik>

Sure, If we support X.509 certificates we would need to map attributes
(such as CN) from the client certificate to a username.

> It might be better to handle this within ISMS configuration (which
would
> configuration since the mapping might be specific to particular 

This seems like a potential pit-fall to me.  I can see all sorts of
interoperability problems arising out of localized, implementation
specific mappings of identity.  It may work very well in specific
deployment environments, where the rules are universally understood.
However, I can see difficulties in obtaining correct results from
multi-vendor interoperability testing.

If the tmSecurityName is a function of local per-user (or per-meta-user)
configuration information, then how is ISMS fundamentally different from
USM?  ISMS is supposed to be more than USM over SSH.  :-)

<Kaushik>

I think ISMS supports a variety of authentication systems, for a
majority of these authentication systems there isn't any local per-user
configuration but I want to make sure that we don't preclude that
possibility.

Regards,
 kaushik!

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 25 Oct 2005 15:11:09 -0400

> I guess a local password file is a *form* of infrastructure.
> IMHO, a degenerate case.

It's what many people use... 

>> want YET ANOTHER infrastructure to manage.
>
> OK.  I'll agree that describes a segment of the user population.
> Although I certainly hope that somebody cares about scalability!  :-)

The birth-reason of ISMS was - people already invested in SOME
infrastructure, and don't want to spend an extra dime on ANOTHER one. So
whatever scalability issues they had - they ALREADY ADDRESSED them in
whatever infrastructure that they chose.

> Yes.  As long as the Kerberos users and AAA users aren't saddled with
> the requirement to implement and configure localized user
authentication
> information in the managed entity, I suppose that's all fine.

It would be nice if ISMS can accomplish that. I don't know if it's
possible - but will be happy if it is.

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Oct 2005 15:22:33 -0400

Uri Blumenthal writes...

> whatever infrastructure that they chose.

There are a range of scalability properties in the already adopted
infrastructures.  Local password files have relatively low scalability,
while Kerberos, RADIUS, Diameter, TACACS and general PKI infrastructures
have relatively high scalability.  As long as the requirements of ISMS
don't force the reduction of scalability to the lowest common
denominator for all mechanisms, I will be well satisfied.

> > authentication information in the managed entity, I suppose that's 
> > all fine.
> 

I agree, however, I think that it is possible, and that it's more of a
MUST than a SHOULD.

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 26 Oct 2005 16:20:27 -0700

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, October 25, 2005 7:47 PM
> To: [email-masked]
> Subject: Re: [Isms] #32: is the securityName=username default OK?
> 
> Hi -
> 
> > From: "Salowey, Joe" <[email-masked]>
> > To: "Nelson, David" <[email-masked]>; <[email-masked]>
> > Sent: Tuesday, October 25, 2005 1:48 PM
> ...
> > I think mapping will need to happen and that mapping functions may 
> > vary from deployment to deployment.  It seems useful for an 
> entity to 
> > be able to assert a name it wants to use.  Mapping can 
> happen within 
> > the SSH implementation without direct involvement of SSHSM.  If the 
> > securityName field in the SNMP message then SSHSM would need to be 
> > involved in the mapping.  Doing the mapping in SSHSM adds 
> complexity 
> > and probably should be at most optional (the complexity 
> might be less if we had a decent
> > name mapping API).   
> ...
> 
> Do you envision that these mappings would be configured via a 
> MIB, or would some other mechanism ensure that the various 
> implementations in a deployment were using the right mappings?
> 

[Joe] Often I would expect there would be some reasonable default
behavior that would fit many cases.  If an override is necessary then
these configurations could be part of a MIB. The question is it a part
of an SSH MIB or an SSHSM MIB.