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 13:36:02 -0700

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

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 2 May 2005 22:01:31 +0200

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,

--Eric