Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third party

From: "Tom Petch" <[email-masked]>
Date: Fri, 29 Apr 2005 21:02:47 +0200

<inline>
Tom Petch
----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 28, 2005 7:58 PM
Subject: RE: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party

> > > Comment #1:
> > > One intention of the SNMPv3 approach was to enable logging
> > of changes,
> > > including logging the securityName of the security
> > principal. In your
> > > solution, there would be no security principal known at the
> > agent, so
> > > audit logs could not be done. Is this correct?
> >
> > Logging is possible.  securityName is not stored in the agent
> > but is known (and
> > authenticated) to SNMP manager and security server, so the
> > manager can put it in
> > the security parameters to enable logging; but it is the
> > userj identifier that
> > is used for security checks at the agent on the incoming messages.
>
> In this approach, is there any authentication of the securityName in
> the security parameters, to ensure that the securityName and the
> assigned userj identifier refer to the same security principal? If I
> control the application, can I authenticate to get a userj identifier,
> and then use a securityName of "Tom Petch" so your name gets logged
> rather than mine when I do something I shouldn't? How does the SNMP
> agent prevent such a misleading thing form occuring, or, if the agent
> cannot detect and prevent this, how does an admin uncover this
> deliberately misleading tactic?

Ultimately, you probably cannot in a cryptographically strong manner.  If the
SNMP manager-server is open to attack, then there is little security since it
will have a local store of agent, session keys, end-user etc  I assume the
manager runs on such as Microsoft Windows Server 2003 or IBM z/OS or a Unix
equivalent which can protect their information when needed.  So the manager only
has permission from the security server to set up a session and send PDU from a
specified user-name to a specified agent and that is all that will happen.  The
protection depends on the shared secret between SNMP manager-server and security
server and the way in which the servers are built.

Third party security- Kerberos - is stronger but that requires more work at the
agent which it is my starting point not to have.

I don't expect most agents to log much - they are mostly entry level devices -
with servers (security, SNMP manager etc) doing most of that.  I expect logging
at the security server - ie AAA - it knows the end-user credentials, what
userj was used by them at which agent, potentially from which workstation; and
at the SNMP manager-server, which has much of the same information.

> >
> > > Comment#2:
>
> > Bundling the security server into the SNMP server as a single
> > standalone box is
> > a subset of this and seemed a less flexible architecture.
>
> When you say "SNMP server" are you referring to a manager (entity
> acting as a command generator) or an agent (entity acting as a command
> responder)?
>
>
> David Harrington
> [email-masked]
>
SNMP manager-server:-) ie a server-type platform - Windows Server 2003, z\OS,
Unix - with an SNMP command generator (yes, I know, and sometimes forget, that
the command responder is
really the server of a client-server relationship, port 161 and all that).  The
split in roles in SNMPv3 is a nice flexibility to have but is not something I
see much of yet, so I cast the security issue in terms of traditional SNMP
manager-agent.

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

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 29 Apr 2005 16:26:17 -0400

>agent which it is my starting point not to have.

<WG chair hat off>

I feel I must correct you here.  Kerberos requires relatively little
work at the _agent_.  In fact, Kerberos servers are relatively simple,
from both a management and programming aspect (we can debate what is
"simple" and what is not, but I'm just talking about the relation
between the manager and the agent).  The _manager_ is more complex.
This is of course not true for all trusted third party systems.

Sometimes I think the amount of complexity required for authentication
is constant, and the only real difference between different systems is
where they choose to put the complexity.  I know that's not true, but
it sure seems like it at times :-)

--Ken

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Apr 2005 13:44:52 -0700

>>>>> On Fri, 29 Apr 2005 21:02:47 +0200, "Tom Petch" <[email-masked]> said:

Tom> I don't expect most agents to log much - they are mostly entry
Tom> level devices - with servers (security, SNMP manager etc) doing
Tom> most of that.  I expect logging at the security server - ie AAA -
Tom> it knows the end-user credentials, what userj was used by them at
Tom> which agent, potentially from which workstation; and at the SNMP
Tom> manager-server, which has much of the same information.

Yes, but the only auditing that can be done doesn't include the actual
operations unless you're doing the auditing on the device itself.  I
could tell you my password, and I'd know I gave it to you and what you
could potentially do with it when logging into the machines I have
accounts on.  Only the machine could actually log what you did while
on the system though.

Putting all your trust into the management station and not putting
decent security services into the device itself is a recipe for
trouble.  Having said that, if you want to deploy your network such
that each user gets mapped to the same over-the-network root principal
to perform actions then that is your choice, but you certainly better
understand the security principals involved in how that management
software was developed.  It's *much* easier to attack a running
application to steal network keys from it than it is to attack a
remote machine when you don't know the network keys for it.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 29 Apr 2005 23:06:27 +0200

I agree that a shared secret (with a security server) in the agent with limited
logging is not as secure as USM.  Armour-plated security requires more work,
more hassle at the large number of remote agents and USM gives both:-)  And your
survey of operators showed a number who are happy with USM so for them, the
tradeoff is ok.

But USM does not scale, it does not scale down to the smaller organisations, the
like of which I see using telnet to login to a remote router to make
configuration changes with userid and password sent in the clear over the
network - and they think they have got security.  A shared secret that is never
sent anywhere, a fresh key for each session, that is a big increase in security
for them even if it is not up to USM standards.  It is scalability, better
security with one touch at the agent, that drives me.  And, as I said, this
shared secret with a security server can be updated as often and as much as the
organisation wants to get harder security - just don't put end user ids, their
keys, certificates etc into the agent as well:-)

Does that make me OOBK?  I am still thinking about it.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, April 29, 2005 10:44 PM
Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third
party

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Apr 2005 15:24:24 -0700

>>>>> On Fri, 29 Apr 2005 23:06:27 +0200, "Tom Petch" <[email-masked]> said:

Tom> But USM does not scale

Never said otherwise.

Your argument was that all trust should occur at the management
station, though, and it should be configured with keys to the kingdom
and parse out information from there as to who can do what.  That
doesn't fly in my book is all I was saying.  (this is different than
Kerberos, which is a centralized service running on one host that most
NM users wouldn't have access too.)

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Apr 2005 19:10:17 -0700

Hi -

> From: "Ken Hornstein" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, April 29, 2005 1:26 PM
> Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third party
>

> This is of course not true for all trusted third party systems.

I don't see how things would be any simpler at an "agent"
if it supports sending notifications as Informs.

> it sure seems like it at times :-)
...

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Apr 2005 19:51:33 -0700

>>>>> On Fri, 29 Apr 2005 19:10:17 -0700, "Randy Presuhn" <[email-masked]> said:

>> This is of course not true for all trusted third party systems.

Randy> I don't see how things would be any simpler at an "agent"
Randy> if it supports sending notifications as Informs.

If you're making the assumption that USM will be used to protect the
packets, then you're right.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 29 Apr 2005 23:03:14 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, April 29, 2005 7:51 PM
> Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third party
>

...

Not just USM.  The recipient of the notification needs to know that it is
authentic, which means that the notification originator somehow has to
come to have the right bits to sign it.  The at the notification originator side,
we need to know on whose behalf the notification is to be sent, so the right
access control policy can be consulted to determine whether it will be
permitted to go on the wire.  If the notification originator doesn't pick up
these bits on its own (making it just as complex as the "manager"), the
notification subscriber would have to put them there.  This would get
especially ugly with large potential fan-in or short expiration times.

Randy

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 30 Apr 2005 11:10:27 +0200

Ken

Where Kerberos is the third party to a end-user workstation and a server (FTP,
HTTP, SMTP, ...), then I have no issue with it; indeed, since its adoption by
Windows 200x Server, it is probably the industry standard (even if people think
Microsoft invented it:-(

But when the party is a desktop switch or access router with Telnet and TFTP and
not much else, that is when I see it as too much (and would make do with
something simpler, eg a pre-stored shared secret).  That is the context that
preoccupies me, where I look for a one touch solution.

Tom Petch

----- Original Message -----
From: "Ken Hornstein" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 29, 2005 10:26 PM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 30 Apr 2005 11:37:54 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, April 30, 2005 12:24 AM
Subject: Re: [Isms] Keep the agent simple; was RADIUS is not a trusted third
party

> station, though, and it should be configured with keys to the kingdom

Not so.  I take a third party security server as sine qua non and that server is
the third party to the end user workstation and to the server on which SNMP
manager runs.  The SNMP agent shares a secret with the security server, not with
the SNMP manager-server, and this secret is used to generate a session key; the
SNMP manager needs to know the session key as well so if the SNMP manager-server
is successfully attacked, then you lose security for the services on it - SNMP,
HTTP, SMTP, ....  Yes it can happen, but the loss of SNMP will be only one of
many headaches for the organisation.

If the agent is a server (FTP, HTTP, SMTP, ....), then of course it has all the
necessary infrastructure to be a party, with the SNMPmanager-server, to a third
party security server.

So I scale by having different degrees of security between agent and security
server, from pre-stored shared secret to Kerberos to ....

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 30 Apr 2005 11:59:13 +0200

Notifications I see as less of a concern; if we can safely perform set
operations on switches and routers, then I see that as a giant leap for network
management.  Securing notifications, in an unreliable network where polling is
the norm, I am less concerned with.  I struggle to think of a case where a
notification needs protection from disclosure; authentication, nice to have,
probably achieved, if required (big IF), by requiring the session to be in place
already, ie the manager polls the device regularly to keep the session alive and
so the authentication already exists - the agent is constrained to send a
notification only if a session exists.

Tom Petch

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, April 30, 2005 8:03 AM
Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a trusted third
party

party

---

From: "David T. Perkins" <[email-masked]>
Date: Sat, 30 Apr 2005 15:44:12 -0700 (PDT)

HI,

Tom - notification delivery is not so simple. The best kept secret
is SNMP informs. However, configuring their use (authNoPriv or authPriv)
is quite difficult. If one of the side effects of the a new
security model is the secure informs are actually easy to use,
I predict that they will see quite a bit more usage.

Note, I believe that it is not generally appropriate to
use the same session for request operations as that is
used for general notification delivery.

> notification only if a session exists.
Regards,
/david t. perkins