Subject: [Isms] achieving market saturation with ISMS

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Feb 2005 15:22:17 -0800

One of the whole reasons behind David and my efforts to get this work
under way within the IETF was to try and help the operators with
deployed authentication infrastructures (of any type) to be able to
access their devices securely over SNMPv3 using identical
authentication mechanisms.  The most critical problem with deploying
SNMPv3 wasn't that it wasn't better than v1/v2c but that it was hard
to deploy due the maintenance it required.  This is, of course,
already known.

When we approached the IESG about starting a working group, we were
asked to prove that people needed such a change and this was the
reason many people weren't using SNMPv3 in the first place.  To do
this, we offered a survey and advertised it to NANOG and a few other
places.  We got 149 responses.  Some of the questions that were asked
had surprising results, some were expected.

To recap some of the important things to consider as this work goes forward:

26% of the people that responded used SNMPv3 at that time.

Of the various authentication systems in use at that time by the
people that responded:

  66%  local accounts
  49%  SSH-keys
  40%  Radius
  29%  TACACS+
  14%  X.509 Certificates
  10%  Kerberos

  [numbers don't add to 100 because more than one option could be selected]

This result set actually surprised me.  I knew that SSH was popular as
was local accounts, but I actually expected Radius to be in greater
use than it was.  40% is certainly heavy usage, but it is hardly
market dominance.

One of the reasons that I've told many people that I'd be happy with a
transport based solution, such as the TLSM solution had offered, even
though it wasn't my number one choice, was that it would at least meet
the criteria of getting the largest percentage of deployment
possible.  Specifically, it would be easy to make it work with both
local accounts over a TLS tunnel as well as SSH based identities over
a SSH tunnel.  Thus, it would likely have a huge impact on the
usability of SNMPv3.

Where I'm going with all of this is that I disagree with section
3.2 that states:

   The evaluation team also recommends, in the interest of
   interoperability, that the working group select a single
   mandatory-to-implement mechanism.  The evaluation team recommends
   RADIUS [RFC2865] for this purpose, due to its widespread use.

If you offered operators a solution which was couched around Radius
and they didn't use it, you wouldn't be offering them anything.  It's
somewhat akin to saying "Ok, we learned that you didn't like SNMPv3
because you didn't want to maintain another infrastructure.  We've now
fixed that, here install this different infrastructure (Radius) instead."

We've already seen the ramifications of selecting an authentication
system which people didn't want to use.  I don't think that if you
selected Radius as a mandatory to implement protocol that you would
much greater than 40% saturation with it, which in my opinion is way
too low.  As much as the security side of me hates to say it, I think
we should strongly consider making local accounts the mandatory to
implement form because that is simply what is in use the most.

Even worse, if EUSM-like is the path chosen it requires that Radius or
any other protocol be modified before it could be used by this
architecture.  That's a rather important point, so I'll restate it.
The other protocols must be modified before they'll work.  It's
important because it means the current deployed base of the modified
protocol is 0%.  It means that even if you shipped the solution today,
everyone would have to upgrade their infrastructure or install new
infrastructures in order to make the solution work.  That, to me, is
not giving the operators what they've been asking for: to make SNMPv3
work with what they have today.

-- 
Wes Hardaker
Sparta

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 24 Feb 2005 14:58:54 -0500

Well, provisioning of local accounts is nice - but it requires a large
chunk of software to do/manage it, plus an acceptable MIB...

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 10:02 AM
To: Blumenthal, Uri; 'Randy Presuhn'; [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS

Hi,

I'm a proponent of having local accounts as a fallback to centralized
accounts. I believe this is important for troubleshooting broken
networks when a AAA server or centralized key distribution
infrastructure may not be reachable.

I don't think we should just provide an interface to local accounts
that are somehow provisioned in a way that is "simply not my problem".
I think we should make both provisioning of local accounts and
leveraging centralized accounts part of the SNMPv3 solution. What we
need to do is to show that having SNMP do the provisioning for the
local accounts for all management interfaces would be easier than
provisioning the local accounts of different management interfaces
using different mechanisms. 

The biggest win would be to converge the multiple local account
databases into one consistent local account database that is
manageable using any of the (equivalently-secure) management
interfaces. To do this means we need to develop a standard virtual
data model for a user-authentication database that can be used by the
different user-authentication mechanisms supported by different
management interfaces (e.g. the USM-MIB). 

We would also need to develop equivalent (or at least balanced)
security for each of the management interfaces, so one interface
doesn't provide less protection of the keys than other interfaces. If
SNMPv3 uses its own unique security model, then we'll need to figure
out how to provide equivalenet security for other management protocols
to converge them; it would be easier to achieve equivalent security by
having SNMP adopt the existing security solutions used by other
management interfaces (even if this might mean lessening the strength
of SNMPv3 security to match the other solutions).

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
> Sent: Thursday, February 24, 2005 9:24 AM
> To: Randy Presuhn; [email-masked]
> Subject: RE: [Isms] achieving market saturation with ISMS
> 
> > Here's what bugs me about local accounts:
> > The effort required to provision and maintain local accounts is
> arguably
> > even greater than that required to maintain USM users, because at
> least
> > the USM user maintenance is easily accomplished remotely through a
> > highly standardized interface.  If USM is too much work, then how
> would
> > making local accounts be an improvement?
> 
> IMHO, the answer is "Simply Not My Problem". I think that 
> proponents of
> this approach hope that local accounts somehow will have to be
> provisioned [for the box to function properly] AND SOMEBODY ELSE
WILL
> HAVE TO TAKE CARE OF THAT. So if they just offer an interface to
local
> account-based authentication, they'll avoid all the 
> provisioning needs.
> :-)
>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 24 Feb 2005 17:17:40 -0800

There is a difference between ISMS provisioning local accounts and ISMS
being designed with interfaces so that it could interwork with an
existing IETF approach (e.g., RADIUS, COPS) to provision local accounts.

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 10:02 AM
To: Blumenthal, Uri; 'Randy Presuhn'; [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS

Hi,

I don't think we should just provide an interface to local accounts that
are somehow provisioned in a way that is "simply not my problem". I
think we should make both provisioning of local accounts and leveraging
centralized accounts part of the SNMPv3 solution. What we need to do is
to show that having SNMP do the provisioning for the local accounts for
all management interfaces would be easier than provisioning the local
accounts of different management interfaces using different mechanisms. 

The biggest win would be to converge the multiple local account
databases into one consistent local account database that is manageable
using any of the (equivalently-secure) management interfaces. To do this
means we need to develop a standard virtual data model for a
user-authentication database that can be used by the different
user-authentication mechanisms supported by different management
interfaces (e.g. the USM-MIB). 

We would also need to develop equivalent (or at least balanced) security
for each of the management interfaces, so one interface doesn't provide
less protection of the keys than other interfaces. If SNMPv3 uses its
own unique security model, then we'll need to figure out how to provide
equivalenet security for other management protocols to converge them; it
would be easier to achieve equivalent security by having SNMP adopt the
existing security solutions used by other management interfaces (even if
this might mean lessening the strength of SNMPv3 security to match the
other solutions).

David Harrington
[email-masked]

WILL
local
> [email-masked] https://www1.ietf.org/mailman/listinfo/isms
>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 25 Feb 2005 08:50:56 -0500

> existing IETF approach (e.g., RADIUS, COPS) to provision local
accounts.

To provision anything, MIB and corresponding code must exist - in
addition to interfaces to other things (RADIUS, etc).

I don't think I got your point - are you objecting that in order to use
SNMP for provisioning, [large] extra piece of software and a
corresponding MIB will be necessary - in addition to whatever code is
written to use that thing (local accounts?) to authenticate SNMP
messages themselves?

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Thursday, February 24, 2005 10:02 AM
To: Blumenthal, Uri; 'Randy Presuhn'; [email-masked]
Subject: RE: [Isms] achieving market saturation with ISMS

Hi,

David Harrington
[email-masked]

WILL
local

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 25 Feb 2005 09:38:27 -0800

>I don't think I got your point - are you objecting that in order 
>to use SNMP for provisioning, [large] extra piece of software and 
>a corresponding MIB will be necessary - in addition to whatever 
>code is written to use that thing (local accounts?) to authenticate 
>SNMP messages themselves?

I was merely thinking that each of the proposals have assumed other IETF
work as mechanisms to enhance aspects of SNMP USM security. That other
IETF work has desirable attributes from which we could benefit
regardless of whether we incorporate it into ISMS in a monolithic manner
or whether we provide interfaces from ISMS to that other technology. I
am fond of the latter approach because it permits us to benefit from
however those technologies are enhanced over time and it reduces our
work overall. For example, if we decide to leverage TLS, our
responsibility is to do so via a secure and flexible interface but it is
not our responsibility to define MIBs or other structures for TLS --
that rather is work that we have offloaded to the keepers of TLS.
Similarly, if we choose an approach like EUSM, then we can benefit from
RADIUS' ability to orchestrate local accounts without having to invent
our own local account management approach (in addition to the approach
already present in USM).