Subject: [Isms] RE: Kerberos and PKI; was What is Out Of Band Keying; was CALL FOR CONSENSUS: ISMS Architecture

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 3 May 2005 15:10:56 -0700

>From: Tom Petch [mailto:[email-masked]] 
>Historically I have associated it [Kerberos] with Unix platforms 
>but since Microsoft has made it part of Windows 200x 
>Server, I expect it will become much more widely known 
>and deployed.  So although Wes' survey showed only 10% 
>(from memory) interest, I expect that to grow.

My memory is that Wes' survey occurred at a meeting that was primarily
populated by Internet Service Providers (ISP). Having "hung out" with
ISPs at the IETF for over a decade, I've concluded that the ISPs'
environments are very different from our (very large end users)
environments. For example, in our environments more than 90% of the
devices use a Microsoft operating system that natively supports Kerberos
by default. [Note: this is a statistic -- not a value judgement. Please
exclude me from Unix-vs-Microsoft or end-system-vs-intermediate-system
flames.]

Also, large end users have historic issues with supporting
authentication systems (e.g., for users and applications) due to our
staggeringly huge scale (literally multiple hundreds of thousands of
entities). Because of this, large corporations have also aggressively
pursued (and deploy) PKI-based systems.

Thus, while I respect Wes' numbers, I assert that if this WG is
interested in supporting the large end user, then it will support both
Kerberos and PKI, and hopefully client-server policy systems (e.g., AAA,
COPS server, Radius, Diameter) as well.

>But it does require, like any three party system, reliable 
>and rapid communications at session setup time, which is 
>fine when the agent is an enterprise server, may not be 
>for the workgroup switch or access router.  

Tom, you are bringing up very important issues. To me, this particular
issue is the "age old" delemma of "whether the system should naturally
support the needs of 97% of its population or whether the needs of the
3% should determine the total system approach." It is value judgement of
which population this community should favor -- assuming that router
management is indeed less capable than PCs (are you sure about that?? --
it certainly doesn't seem that way from my knot hole). I will state,
however, that to satisfy my type of community, the solution needs to
support both Kerberos and PKI. 

>Rather than a triangle, our communications may be a fast 
>reliable pipe from security server to SNMP manager-server 
>but not from manager to agent and even less so from agent 
>back to security server.  

I don't mean to be cruel, but your example seems to assume a wired
environment. As you know, our ISMS solution will ultimately need to
support a very wide range of possible deployments, including unreliable
wireless environments (possibly including MANET). Because our design
needs to address the needs of so many diverse types of users, it is
important that our solution support several different authentication
infrastructures including enterprise authentication mechanisms
(Kerberos, PKI) and client-server authentication mechanisms such as
policy servers.

>PKI? limited experience on a Windows platform and 
>there seemed to be quite a bit of administration 
>(eg revocation lists) which are fine on a central server, 
>less so on a distant network box.

This is our (i.e., the administrator's of end user networks) problem,
not the ISMS' WG's problem. I recommend that the ISMS WG design a
flexible authentication system that is able to use a wide variety of
authentication infrastructures. I recommend that all ISMS systems must
support one of these alternatives (i.e., one supportable by 100% of the
devices). Therefore, if a vendor is unable to support all of the
ISMS-supported alternatives for a particular device, then that device
could be supported by whatever the vendor can (or chooses to) support,
including the minimalist (universal) alternative. However, the end user
is also empowered to determine which primary authentication system to
use in their own deployment based on their own goals, requirements, and
environment -- including building special purpose management sub-systems
for the capability-limited systems, if indeed they are important enough
to that deployment to justify that type of expense.

Please note that I explicitly believe that there are a large number of
possible end user requirements and environments and that SNMPv3 USM
doesn't work well in many of them today because of its lack of
flexibility. This lack of flexibility is what I believe the ISMS WG is
trying to fix. Therefore, our goal should be to increase the
authentication flexibility, not continue to maintain a limiting lack of
flexibility. This, anyway, is the view from my knot hole.

--Eric

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 3 May 2005 22:23:03 -0400

Comments inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fleischman, Eric
> Sent: Tuesday, May 03, 2005 6:11 PM
> To: Tom Petch
> Cc: [email-masked]
> Subject: [Isms] RE: Kerberos and PKI; was What is Out Of Band 
> Keying;was CALL FOR CONSENSUS: ISMS Architecture
> 
> 
> authentication infrastructures. 

The SNMPv3 architecture was designed to provide that flexibility; it
allows multiple alternative security models to co-exist. 

We deliberately made SNMPv3 modular and able to support multiple
security models because it was recognized that trying to design one
security model to meet all needs is not likely to be feasible, and
trying to do so would probably result in never completing the work.
SNMPv3 is designed to allow multiple models to co-exist to meet
different needs. Operators can of course choose which to utilize for
their environments.

> I recommend that all ISMS systems must
> devices). 

USM is the one security model required for compliance to the SNMPv3
standard for purposes of interoperability. I am not convinced that
making compliance dependent on the presence of another security
infrastructure is a good idea, especially since it is obvious none of
the suggested infrastructures meets everybody's needs.

I hope ISMS does not try to satisfy all the people all of the time
with one security model, or even one security model architecture. The
constraint that we must choose one architecture, or one proposal, to
pursue is all about what this WG is chartered to do. That does not
mean SNMPv3 should be constrained to have one security model to meet
all needs. I personally would be satisfied to see all three
architecural models under discussion, or all three proposals,
implemented and made available for deployment to supplement the USM
security model. If in practice one of the new deployed security models
can be shown to meet everybody's (minimalist) needs, then we could
make that the rerquired-for-interoperability model to replace USM, but
I don't think we should be planning to eliminate USM until another
security model is proven in the field to be more adequate (at least we
have a low bar).

> Therefore, if a vendor is unable to support all of the

David Harrington
[email-masked]

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 4 May 2005 19:01:17 +0200

Eric, mmm ...  is your 90% Microsoft a percentage of the entire SNMP engine
base,
manager and agent, command generator and command responder, etc ?  I see a
similar figure for the population of workstations and servers, but not when I
include network devices (hub, switch, router, NAS, firewall etc) most of which
come from another three or four vendors.

So if we had a solution that was Microsoft only(!!!!!), perhaps relying on
Kerberos, would that meet 90% of your needs?

Because another tenet of mine is that the cost of perfection is infinite, so to
meet 100% of anything is astronomic and almost always uneconomic, so as an
engineer, I need to prioritise and meet a high enough percentage for 'it' to be
worthwhile eg if I cannot secure Notification class PDU, that is a loss, but
my judgement is that it is not a fatal loss (I think I know who is going to
disagree with me on that example :-).  Starting at the other end, if we only
secure the ability to Set operational and customisation parameters (while
meeting the
constraints of the isms charter), we would still have a worthwhile enhancement
(but I
expect you will disagree with that:-(

And yes, Wes survey was of operators, not enterprises (which is where most of my
experience comes from). To quote
"     5 ---
      3 Device Vendor
     71 Network Operator
      2 Research
      1 Software Vendor"

And the other quote
"Which user authentication mechanisms do you use:
     39 radius
     32 TACACS+
     61 local-accounts
     41 ssh-keys
      8 kerberos
     11 x.509-certificates"

Tom Petch

----- Original Message -----
From: "Fleischman, Eric" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 04, 2005 12:10 AM
Subject: RE: Kerberos and PKI; was What is Out Of Band Keying;was CALL FOR
CONSENSUS: ISMS Architecture

<snip>