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

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 2 May 2005 14:26:47 -0700

Tom,

I fully agree with you. Even though my "hot button" is creating a system
that can adequately scale large (huge), our total approach also needs to
support small deployments as well.

I don't want to necessarily impose my own thoughts on the WG, but the
approach that I had privately envisioned was to continue to support
SNMPv1, SNMPv2, and SNMPv3 USM for systems/deployments that are
well-supported by those approaches, but to make ISMS to also become
available for environments that are not well supported by those existing
approaches. This includes huge deployments and deployments with enhanced
security requirements.

--Eric

>From: Tom Petch [mailto:[email-masked]] 
Sent: Monday, May 02, 2005 1:02 PM
To: Fleischman, Eric
Cc: [email-masked]
Subject: Re: [Isms] securityName in Keep the agent simple;was RADIUS is
not a trusted third party

Thanks for that.  I am happy with all your requirements with one
proviso.  That the solution scales down to smaller organisations with
less support staff; and to smaller boxes which may never have the
capability to handle Kerberos etc (a recent post suggested that even D-H
would be too computationaly demanding for some systems - I have no
information on that but take the post seriously).  So I don't see a
shared secret put in at installation as strong security, but I do see it
as commensurate with some organisations and some boxes (and a lot better
than that which they have at the moment:-).

Where security really matters (DoD, banking, law enforcement, air
traffic control etc), then people buy powerful enough boxes to do what
it takes.  I am concerned for those where it matters less.

Tom Petch

----- Original Message -----
From: "Fleischman, Eric" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 02, 2005 10:36 PM
Subject: RE: [Isms] securityName in Keep the agent simple;was RADIUS is
not a trusted third party

Tom,

Yes, terminology can be problematic. In my own posting, I used AAA to
generically refer to client-server policy based systems such as COPS
servers, Radius, and Diameter. I wasn't explicitly intending the literal
meaning of the acronym (authentication, authorization, and accounting)
but rather the generic client-server technology approach often
associated with that acronym.

Since you asked, my own "hot buttons" are that I want whatever the WG
comes up with to be easily administrated in very large (i.e., huge,
vast) networks. I favor leveraging enterprise wide authentication
systems such as Kerberos and PKI, but also major client-server solutions
such as Radius. Our experience is that local-account based approaches
are really tough to scale to large networks in an operationally secure
manner. Also, if ISMS leverages USM, then I want the USM "keys" to
leverage major authentication systems already deployed within large
networks rather than persisting in using a "unique" system (i.e., no
other IETF protocol or deployed (application) authentication system uses
its keys today in many/most environments).

I am open to all three major keying mechanisms, depending on specifics
of how they are done. I am skeptical that OOB supports Kerberos, which,
if true, is A Big Deal and forms the nucleus of my questions to you. I
favor in-band because it is easy to create unique "session keys" from
"authentication keys" in a negotiated manner using widely deployed
protocol approaches (e.g., D-H). As you may recall, I am worried about a
number of session key issues, and prefer approaches supporting Perfect
Forward Secrecy (PFS). I believe PFS is more difficult in OOB approaches
but I am quite willing to support any approach that actually works.
Thus, my questions to you were all real questions to try to learn from
your insights.

--Eric

>From: Tom Petch [mailto:[email-masked]]
>And a question for you; would you clarify what you
>mean by AAA?  I tend to use it as a generic term to
>encompass accounting as well as elements of security,
>since the raw data of the two often overlap; I do
>not mean a specific technology such as Diameter..

>>From: Eric Fleischman
>>I am 100% in favor of giving operators choices.
>>However, the alternative which I value the most
>>is the choice to use enterprise-wide authentication
>>services (e.g., Kerberos, PKI). AAA is a fine alternative, but local 
>>accounts are a poor alternative (i.e., a real bear to regularize 
>>within large enterprises).

>>>Khanh Nguyen (khanhvn) [mailto:[email-masked]] wrote:
>>>So I think the ideal solution should be able to give operators both 
>>>choices: local user account and/or centralized AAA users. I think 
>>>EUSM, for example, supports both modes.

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