Subject: RE: [Isms] securityName

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 1 Aug 2005 14:09:55 -0700

Tom,

I agree with your point if our goal is to continue to leverage SNMPv3
USM and VACM. However, if we are "outsourcing" elements (or all of) the
ISMS security to alternative technologies, such as many have proposed,
then I disagree with you. I disagree with you because the order of Wes'
list reflects ISP response to current SNMPv3 authentication realities. 

As I've said many times, SNMPv3 authentication is totally unlike all
other authentication systems in our deployment, and my personal goal for
ISMS is for SNMP to directly leverage an existing authentication system
within our deployment. To the extent that my employer represents the
large end user, then I suggest that the preferable candidates are
Kerberos, PKI, Radius, or some other server-based authentication system
(including TACACS+). Local accounts just don't cut it because they don't
scale. 

--Eric

-----Original Message-----
From: Tom Petch [mailto:[email-masked]] 
Sent: Thursday, July 28, 2005 9:32 AM
To: Kaushik Narayan
Cc: [email-masked]
Subject: Re: [Isms] securityName

----- Original Message -----
From: "Kaushik Narayan" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 17, 2005 5:05 PM
Subject: RE: [Isms] securityName

> Hi David,
>
> Here is a list of external authentication mechanisms that are required

> to be supported from the ISMS charter
>
> - Radius
> - TACACS+
> - Kerberos
> - LDAP
> - Diameter
>

Well, no, that is not what I see or would ever want to see in the
charter because I would regard it as impossible if it weren't that
already.  What I see the charter say is

"The following security infrastructures will be considered by the
working group as potential existing authentication infrastructures to
make use of within the new security model. The solution will hopefully
be able to be integrated with multiple of these user databases although
it is expected that one will be mandatory.

- Local accounts
- SSH identities
- Radius
- TACACS+
- X.509 Certificates
- Kerberos
- LDAP
- Diameter"

So we have to support one, hopefully more than one, never all.  And
notice that the order of the list is that of the percentage currently
using it as revealed in Wes' survey, so support for SSH counts for more
than support for LDAP, by an order of magnitude.

_______________________________________________
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: Mon, 1 Aug 2005 17:51:28 -0400

Hi Eric, 

> within our deployment. 

Why don't you write up a security model proposal that directly
leverages an existing authentication system within your deployment?
The RFC3411 architecture was designed to explicitly permit such
supplementary models.

Why are you waiting for a standards body to develop something
custom-fitted to your environment?

If you want your solution to be an IETF standard, then after you
design it, submit it for consideration as a standard.

David Harrington
[email-masked]