Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 21 Apr 2005 17:43:59 -0400

But that was the whole problem! Admins did NOT want to enter a new set
of user-names and passwords in each agent, and then manage the lists.
The purpose of the linkage with RADIUS or such is to re-use the name
lists that are already there (no need to re-type) and the keys that are
already there (no need to re-key).

It's how EXACTLY to accomplish this, and WHAT existing infrastructures
to connect to, that people are arguing about bitterly here and now. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tom Petch
Sent: Thursday, April 21, 2005 4:35 PM
To: Nelson, David; Khanh Nguyen (khanhvn); [email-masked]
Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party

I'm with Khanh on this one.  We could have a system whereby the setup of
'USM'
was much simpler, users with fixed names, passwords being input at agent
setup,
no need for any contact between agent and third party; and changing the
behaviour
of the manager to fit in with this.  The manager is the easy part
because it is
on a server already replete with security systems - (almost) anything is
possible there, like requiring authorisation to send packets to port
161/162 if
that is what the security demands.
.
Tom Petch

----- Original Message -----
From: "Nelson, David" <[email-masked]>
To: "Khanh Nguyen (khanhvn)" <[email-masked]>; <[email-masked]>
Sent: Thursday, April 21, 2005 7:55 PM
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

Khanh Nguyen writes...

> ...why don't we do the samething to auth
> among SNMP entities directly w/out the need for a third party?

I think that's what we have today -- USM -- that operator's find to be
onerous to deploy and manage.

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

_______________________________________________
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: "Tom Petch" <[email-masked]>
Date: Tue, 26 Apr 2005 18:29:38 +0200

<in-line>

(I keep falling behind with all this:-)

Tom Petch

----- Original Message -----
From: "Blumenthal, Uri" <[email-masked]>
To: "Tom Petch" <[email-masked]>; "Nelson, David"
<[email-masked]>; "Khanh Nguyen (khanhvn)" <[email-masked]>;
<[email-masked]>
Sent: Thursday, April 21, 2005 11:43 PM
Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party

Perhaps you miss my point.  The problem I first heard Wes articulate was the
need to update all (eg) 1000 agents when one of the (eg) 150 end-users of the
SNMP manager changed.  I am saying don't bother.  Predefine users (user1 to
usern) in
the agent independent of the end-users, the operator customises shared secrets
for as many or as few as he requires at installation of the agent and only
changes them in accordance with security policy (monthly, yearly, after a
security breach, never).  This keeps the agent simple.

An end-user accesses the manager using its customary user id, is authenticated
by a security server which grants permission for an SNMP session and which
creates an SNMP sesssion key based on the secret shared between security server
and agent (but not with the manager).

The manager/security server have more work to do but that is ok, there are few
of them, often surrounded by operational staff (at least compared to agents) so
increase the workload there to keep the agent simple.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 26 Apr 2005 13:42:22 -0400

<wg chair hat off>

>security breach, never).  This keeps the agent simple.

I would note that you can do that today with USM.  But we have a lot of
people saying that doesn't suffice for their needs.

<wg chair hat on>

--Ken

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 26 Apr 2005 19:11:53 +0200

Mmm I must have some more gaps in my knowledge of USM:-)

1) I log on as TP377 using a secret known to me and the enterprise-wide security
server

2) The security server authenticates me and generates a key based on a secret
shared by security server and SNMP agent (probably localised by engine id) and
unknown to TP377 or the SNMP manager

3) The security server tells the SNMP manager TP377 is authorised to use the
SNMP manager to access SNMP agents (perhaps limited by IP address)  with
userName userj and the key it has generated

4) The SNMP manager sets up a secure channel with the SNMP agent using userName
userj and that key.

What I am missing is how the USM in the SNMP manager lets me do this, the
protocol it uses with the security server.

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

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 26 Apr 2005 14:34:17 -0400

>Mmm I must have some more gaps in my knowledge of USM:-)

Weeelll ... I guess it's all semantics.

You were saying (as I understood it) instead of having hundreds of users,
have a smaller number of "role-based" users, to limit the number of keys
that need to be changed.

You can do the same thing with USM (have a smaller number of role-based
users to limit the keys).  Now, they aren't part of your security
infrastructure, but it's a moot point.  The feedback we've gotten from
operators is that they want to be able to use their regular user
accounts to authenticate to SNMP, not role-based accounts.

--Ken

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 26 Apr 2005 21:29:09 +0200

But I am suggesting that humans use the same userid/password/security
credentials to logon whatever they are doing on whatever system - Telnet, SAP,
FTP, ... - using the organisation-wide security servers which is what I
understand operators want.

But this id is not used in the actual session between manager and agent (because
that means a change of human requires a change in every agent) so the SNMP
security system aided by the security server maps the human userid to one of a
small fixed pool in the agent (which shares a secret with the security server so
that they both can derive a session key when a human wants one).

This parallels what I see in use at present for non-SNMP (ftp, telnet) systems
with proprietary security.

Tom Petch

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

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 26 Apr 2005 16:37:54 -0400

>that means a change of human requires a change in every agent)

Ah.  This of course depends on the security infrastructure that you use.
I can think of several that do not require that (only one change is required
in one place).

I think if an operator wants to the system that you describe, then
that's fine (and I don't think anything that we've discussed will
prevent that), but from what I understood plenty of operators want to
use their "user" identities directly with SNMP.

--Ken

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 26 Apr 2005 16:51:55 -0400

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?

Comment#2:
Some applications already provide for user authentication via a
centralized server, and then use the identity of the application as
the SNMPv3 user. This allows for a very limited number of SNMPv3 users
at the agent, while allowing user-specific authentication at the
application. The application authorizes the authenticated user to
utilize its user-independent application identity for SNMPv3. 

Your suggestion depends on a third-party server to provide a similar
mapping between the authenticated-user at the application and a
user-independent identity temporarily assigned by an
authentication/authorization server used as the SNMPv3-user. Is that
correct?

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Tuesday, April 26, 2005 3:29 PM
> To: [email-masked]; Ken Hornstein
> Subject: Re: [Isms] Keep the agent simple;was RADIUS is not a 
> trusted third party 
>

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 28 Apr 2005 15:44:41 +0200

<inline>
Tom Petch

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

> use their "user" identities directly with SNMP.

I would like to clarify this.  Are you saying that the end user identity must be
present in the agent (as well as in the manager)?  Because if so, then the EUSM
approach would appear not to be viable because it dispenses with securityName in
the agent, only having Vacm group names (which is essentially what user1 to
usern are in my scribbles).

I agree with EUSM in wanting to dispense with end user identities in the agent
because that I see as the major hassle; but I part company from EUSM in wanting
a shared secret - not a protocol - betwen agent and security server.

---

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

>>>>> On Thu, 28 Apr 2005 15:44:41 +0200, "Tom Petch" <[email-masked]> said:

Tom> I would like to clarify this.  Are you saying that the end user
Tom> identity must be present in the agent (as well as in the
Tom> manager)?

He's saying that an authentication mechanism already exists in the
device.  That mechanism may be a an end user identity and method of
confirmation or it may be that the device is already configured to
talk to a RADIUS server.  The important part is that they don't want
*add* something new.  Operators that don't use RADIUS or other
centralized AAA architecture won't want to add it just to deploy
SNMP.  Similarly, operators that have done away with on-the-device
accounts in favor of centralized services won't want to deploy
on-the-device accounts.

That's what makes the problem hard.  It's actually multiple problems
that should have the same end requirements in the operators eyes: use
what they have, not something else.

-- 
Wes Hardaker
Sparta, Inc.