Subject: RE: [Isms] achieving market saturation with ISMS

From: "Martin Soukup" <[email-masked]>
Date: Fri, 18 Feb 2005 04:06:46 -0500

Wes,

My understanding of the evaluation report was that there were two
mandatory-to-implement mechanisms, one implicit and the other explicit. The
explicit mechanism was in fact RADIUS but I believe the support of local
accounts was implicitly required as well (where the device acts as a RADIUS
key distributor) for clients connecting to it. Perhaps the evaluation team
can confirm?

I don't feel that those using SSH tunnelling require SNMPv3 (since SSH
provides authentication and privacy), so I'm not sure where that combination
comes from. Could you explain that?

I agree with Wes' point that the result of this effort should be careful to
address the requirement to make SNMPv3 deployment easy in existing
deployments but I would note that from this survey it would appear that
RADIUS is the market leader for centralized AAA, we just need to be sure to
support non-centralized AAA as well. I think most of the people on the list
have been saying this all along.

Martin.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Wes Hardaker
> Sent: February 18, 2005 12:22 AM
> To: [email-masked]
> Subject: [Isms] achieving market saturation with ISMS
> 
> 
> 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

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

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 18 Feb 2005 10:48:51 -0500

Hi Martin,
 
It is important to identify, preferably using SecSH terms and
references, just what "SSH tunneling" means.

SecSh Transport Layer Protocol provides authentication, integrity
checking, and encryption.
from draft-ietf-secsh-transport-22.txt: "Authentication in this
protocol level is host-based; this protocol does not perform user
authentication.  A higher level protocol for user authentication can
be designed on top of this protocol." SNMPv3 is designed to provide
per-user controlled access to data, so host authentication is
inadequate to meet the design goals for SNMPv3 (that were established
by IETF consensus).  

The SecSH Authentication Protocol (draft-ietf-secsh-userauth-25.txt)
provides user authentication, and that comes closer to meeting SNMPv3
per-user requirements. However, it is necessary to have a binding
between the user authentication of SecSH and the user identity used
for per-user access control. I could use SecSH authentication to
establish a session for user "dbh", and then pass an SNMPv1 message
claiming rights to the "super-user" community (or an SNMPv3 message
claiming a USM identity of "super-user" rather than dbh). There needs
to be a binding between the authentication of the user and the
application of access permissions for that user. So either SecSH needs
to be pass the authenticated user identity to the SNMP engine so SNMP
can apply appropriate access control, or SNMP has to perform its own
user authentication independent of SecSH.

Also, SNMPv3 provides a wealth of features beyond authentication and
privacy that are important to some, but not all, environments. I won't
go into them here, because that is not within the scope of this WG. I
leave it to you to understand the benefits of engineID,
contextEngineID, a standardized proxy, a standardized notification
addressing mechanism, a standardized notification filtering mechanism,
etc.

David Harrington
[email-masked]
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Soukup
	Sent: Friday, February 18, 2005 4:07 AM
	To: 'Wes Hardaker'; [email-masked]
	Subject: RE: [Isms] achieving market saturation with ISMS

	Wes, 

	My understanding of the evaluation report was that there were
two mandatory-to-implement mechanisms, one implicit and the other
explicit. The explicit mechanism was in fact RADIUS but I believe the
support of local accounts was implicitly required as well (where the
device acts as a RADIUS key distributor) for clients connecting to it.
Perhaps the evaluation team can confirm?

	I don't feel that those using SSH tunnelling require SNMPv3
(since SSH provides authentication and privacy), so I'm not sure where
that combination comes from. Could you explain that?

	I agree with Wes' point that the result of this effort should
be careful to address the requirement to make SNMPv3 deployment easy
in existing deployments but I would note that from this survey it
would appear that RADIUS is the market leader for centralized AAA, we
just need to be sure to support non-centralized AAA as well. I think
most of the people on the list have been saying this all along.

	Martin.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Feb 2005 15:49:29 -0800

Hi -

(Responding to points Wes and Martin raised, speaking for myself with
some knowledge of the discussions that led to the evaluation report - )

> From: "Martin Soukup" <[email-masked]>
> To: "'Wes Hardaker'" <[email-masked]>; <[email-masked]>
> Sent: Friday, February 18, 2005 1:06 AM

> key distributor) for clients connecting to it. Perhaps the evaluation team

Local accounts were *NOT* a mandatory-to-implement mechanism from
the perspective of the evaluation.  Operationally, I do believe that USM
users will need to be provisioned, in order to support fire-fighting access
when AAA infrastructure is down.

...
> have been saying this all along.
...

The members of the evaluation team had no great love of RADIUS.  The spirit of
the recommendation was, I believe, "whatever AAA protocol that is useable
that is most pervasive" should be mandatory to implement.

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?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Feb 2005 08:38:47 +0100

> making local accounts be an improvement?

Local accounts are a reality on all boxes that I can think of. You
telnet, ssh, whatever into local accounts as the default. On some
installations, you find AAA setups to simplify the maintenance of
accounts in the normal case (when the core network is running).
The point is that USM does typically not interface with neither
these local accounts nor AAA systems. In other words, USM is too
much work because it is extra work in _addition_ to the management
of local accounts or AAA accounts. [I am surprised that the core
of the problem still seems to be not well understood.]

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 24 Feb 2005 03:31:27 -0500

Hi,

I think the core problem is well understood, but many people simply
aren't looking at the problem from the right direction, and making it
harder for themelves. I suggest that USM and SNMPv3 could make it
easier to maintain local and centralized accounts for SSH, telnet,
web-based mgmt, and netconf.

As Randy points out, only an "initial" user needs to be configured
manually (or by default) in USM, and then subsequent users and
passwords can be configured using SNMPv3. If we specified how
implementers could utilize the USM MIB to store local accounts for all
management interfaces, then the work would not be extra. With
read-write SNMP agents, operators could configure their local accounts
programatically and securely using SNMPv3.

Converging the local accounts for SNMP and SSH and telnet and
web-based mgmt and netconf would greatly reduce the extra work
involved in configuring all these management interfaces. And if we add
support for centralized AAA or key distribution to SNMPv3, that could
also be used by the non-SNMP management interfaces.

And if we converged data models and access controls, we could reduce
the extra work of learning and configuring these for multiple
management interfaces.

Trying to force all management interfaces to emulate the CLI approach
with its lack of standardized data models, lack of standardized access
controls, and lack of standardized local accounts seems to be the
wrong direction in my eyes. We should be striving for convergence via
the use of standard data models, standardized access controls,
standardized local accounts, and standardized support for centralized
AAA, and SNMPv3 is the leader in providing such standardization,
except, so far, for the centralized AAA support.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Thursday, February 24, 2005 2:39 AM
> To: Randy Presuhn
> Cc: [email-masked]
> Subject: Re: [Isms] achieving market saturation with ISMS
>

---

From: Robert Story <[email-masked]>
Date: Thu, 24 Feb 2005 14:33:58 -0500

On Wed, 23 Feb 2005 15:49:29 -0800 Randy wrote:
RP> Here's what bugs me about local accounts:
RP> The effort required to provision and maintain local accounts is arguably
RP> even greater than that required to maintain USM users,

If we are talking about provisioning by hand, then that's probably true.

RP> at least the USM user maintenance is easily accomplished remotely through a
RP> highly standardized interface. 

If it's so easy, then were are the standardized tools to accomplish this? We're
going to have trouble getting people to switch from existing methods of
managing local accounts (eg Kerberos and NIS) to something that doesn't exist
yet. (More on getting it to exist in a bit.)

RP> If USM is too much work, then how would making local accounts be an
RP> improvement?

On Thu, 24 Feb 2005 09:23:57 -0500 Blumenthal, wrote:
BU> IMHO, the answer is "Simply Not My Problem". I think that proponents of
BU> this approach hope that local accounts somehow will have to be
BU> provisioned [for the box to function properly] AND SOMEBODY ELSE WILL
BU> HAVE TO TAKE CARE OF THAT.

I think it's more like somebody else has already taken care of it. Obviously
provisioning 100 new boxes will arguably require similar amounts of work for
initial provisioning. But the idea here is to take advantage of existing
infrastructure and tools.

On Thu, 24 Feb 2005 10:01:56 -0500 David wrote:
DBH> I think we should make both provisioning of local accounts and
DBH> leveraging centralized accounts part of the SNMPv3 solution. What we
DBH> need to do is to show that having SNMP do the provisioning for the
DBH> local accounts for all management interfaces would be easier than
DBH> provisioning the local accounts of different management interfaces
DBH> using different mechanisms. 

I think David hit Randy's nail on the head here. It would be wonderful to have
a standardized interface for user accounts. However, this isn't going to happen
anytime soon, and it's out of scope for this WG.

But I think the first step in this direction is in scope. First we need to get
our foot in the door by integrating with existing infrastructure. In keeping
with the SNMP tradition, this first step will be providing use and monitoring
of the existing infrastructure (eg read-only access). Once that is in place, we
can move on to the more lofty goal of standardized management.

--- 
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>

You are lost in a twisty maze of little standards, all different.