Subject: RE: [Isms] ISMS Operational Scenario/Goal

From: "David T. Perkins" <[email-masked]>
Date: Mon, 28 Feb 2005 15:42:38 -0800 (PST)

HI,

Picture.....

   A                   B                      C       
mgr system        managed system       system containing Radius server
----------        --------------       -------------------------------
|        |        |            |       |                             | 
----------        --------------       -------------------------------
Has address       Doesn't have         Has shared secret for IP addr C
of B              identity Joe         Knows identity Joe
Uses identity     Has IP address       Knows pw for Joe
"Joe"             of C
Has pw for        Has shared secret
"Joe"             with C for Radius
Doesn't           operations
know anything     Has RSA key pair
about C           for SSH or
Has finger        X.509 Cert
print of B's
RSA public
key or
CA cert for
B's cert

This is what exists for SSH and/or secure Web browser access
by operator Joe from any computer A.

Operator Alice may have set up systems B and C. Operator Joe
does not know how authentication occurs. It's magic to him.

There is NO NEED or DESIRE to set up on system A information
about the Radius server on system C.

On Mon, 28 Feb 2005, David B Harrington wrote:
> Hi, David P,
> 
> Isn't the operator that sets up the system also a management user? How
> does he use management with AAA centralized user authentication
> without having to know the IP address and AAA credentials to set up
> the system?
> 
> I don't think anybody is arguing that each management user must
> provide the IP address and secret in their requests; that is done once
> by the operator who sets up the system. Or is there specific text in
> one of the proposals or in the documentation for a specific AAA
> protocol that you are thinking about? If that is the case, can you
> point us to the text so we can all be on the same page?
> 
> David Harrington
> [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of David T. Perkins
> > Sent: Monday, February 28, 2005 5:58 PM
> > To: Nelson, David
> > Cc: [email-masked]
> > Subject: RE: [Isms] ISMS Operational Scenario/Goal
> > 
> > HI,
> > 
> > You are just not following. Let me give an example.
> > 
> > When using SSH, the user of SSH does not know anything
> > about Radius servers. The user doesn't know how authentication
> > is done. It's magic. All the user knows is the IP address
> > of the system to connect to, the user's ID, the user's
> > password, and the fingerprint of the SSH server on the
> > system. Now, if the operator that set up the system
> > want AAA, they set it up by configuring the managed
> > system to use Radius authentication, accounting,
> > and authorization. Again, the user does not know
> > what is going on "behind the curtain".
> > 
> > What is needed with a new SNMP security model is
> > something that requires no new work, nor new
> > information to be held by users to run SNMP
> > management applications. And it uses what ever
> > existing security infrastructure. That is what
> > I'm saying. Use existing infrastructure. Use
> > existing information.
> > 
> > 
> > On Mon, 28 Feb 2005, Nelson, David wrote:
> > 
> > > Dave Perkins writes...
> > > 
> > > > Show me now where management users need IP address and
> > > > secret of Radius server to perform management.
> > > 
> > > If you simply want to allow remote management of devices 
> > that provides
> > > for data confidentiality of the management "session", 
> > without providing
> > > the "single sign-on" infrastructure of an Authentication, 
> > Authorization,
> > > and Accounting (AAA) system, then you're correct -- no
> client-server
> > > relationship is required.
> > > 
> > > I think you miss the point about minimizing OpEx costs, however.
> > > Failing to utilize the existing AAA infrastructure, and 
> > instead relying
> > > on disjoint authentication mechanisms, is exactly the "cost" we
> are
> > > attempting to avoid, IMHO. 
> > > 
> > 
> > Regards,
> > /david t. perkins
> > 

Regards,
/david t. perkins

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Feb 2005 19:58:10 -0500

Hi DP,

Your text description of the scenario definitely was not clear. Thanks
for the picture.  

I think one thing is missing in your scenario. Typically RADIUS uses a
challenge and response protocol for user authentication. It is a
typical requirement at A for Joe to be present to provide the current
pw for Joe in response to a RADIUS challenge. For automated
every-5-minute-polling purposes, it would be rather undesirable for
the user to have to respond to a challenge for every poll. Allowing
the SNMP application to act as a RADIUS client to proxy for Joe can
mitigate that requirement. If you were to use automated scripts to
establish the SSH sessions for Joe, either Joe would need to run them
and respond to the challenge, or a lookup must be done to get Joe's
credentials using, say, a "Windows integrated security" single sign-on
approach, or Joe's password would need to be hardcoded into the
script. If the scripts need to know the password, then that solution
suffers the same "extra" work you refer to, and you have a credentials
distribution and update problem.

There may be other ways to work around this problem, but the
"requirement" of user presence at A should be recognized in your
scenarios for SSH and web-based management interfaces. We want to
avoid that requirement for SNMP.

David Harrington
[email-masked]

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Monday, February 28, 2005 6:43 PM
> To: David B Harrington
> Cc: 'Nelson, David'; [email-masked]
> |        |        |            |       |                      
>        |

---

From: Robert Story <[email-masked]>
Date: Mon, 28 Feb 2005 20:47:24 -0500

On Mon, 28 Feb 2005 19:58:10 -0500 David wrote:
DBH> There may be other ways to work around this problem, but the
DBH> "requirement" of user presence at A should be recognized in your
DBH> scenarios for SSH and web-based management interfaces. We want to
DBH> avoid that requirement for SNMP.

SSH allows for password-less authentication. I use it all the time for remote
backups. Joe's configuration would simply have to be set up to accept the
private key he is using on A.

You also seem to imply that SNMP doesn't require user presence. I don't see how
SNMP is any different from ssh. If I want to periodically poll a device, the
credentials have to be configured somewhere, or the user has to be present to
provide the information.

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