Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 5 Apr 2005 14:00:50 -0400

<Wes>

As do I.  Specifically, I think Robert's ordering of requirements matches
mine.  In-band first, and encapsulated being a second choice. As I've
mentioned in multiple other messages, there are a large number of issues
with out-of-band keying that makes implementation difficult.  I suspect
Sharon must not agree with any of those other points?
</Wes>

No, not really. After our discussion in Minneapolis where you mentioned the
fact that you felt separate key management would be impossible to implement
in net-snmp, I went back and talked to some more SNMPv3 implementers to get
their view of implementing eUSM and although they observed there were some
missing elements of procedure, they saw nothing that they felt would cause
implementation problems.

I'm a big fan of modular architectures. It allows you to add functionality
as you need it and to ensures a good return in investment when looking to
add new features. Yes, there are points where having too many separate
modules to worry about starts to cost more than it saves and then you look
at combining things together to get some improvements. I don't think we are
there in this particular case.

Sharon

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Apr 2005 11:51:29 -0700

>>>>> On Tue, 5 Apr 2005 14:00:50 -0400 , "Sharon Chisholm" <[email-masked]> said:

Sharon> No, not really. After our discussion in Minneapolis where you
Sharon> mentioned the fact that you felt separate key management would
Sharon> be impossible to implement in net-snmp, I went back and talked
Sharon> to some more SNMPv3 implementers to get their view of
Sharon> implementing eUSM and although they observed there were some
Sharon> missing elements of procedure, they saw nothing that they felt
Sharon> would cause implementation problems.

Well, I don't think I said "impossible".  I said it would be difficult
to keep it portable.  I would suspect that anyone implementing a
portable SNMPv3 stack will run into  similar problems.  When you need
to interface with another protocol server (EG, EAP per EUSM) then you
need to either:

1) create your SNMP stack library so that it offers generic keying
   APIs and let the vendor who is producing a box tie it together with
   whatever keying stack they're using.  This means each vendor does a
   lot of work.

2) create your SNMP stack library so that it personally tries to
   interface with all other known keying stack vendors.  This means
   that each SNMP stack vendor (M total, say) would have to support N
   keying stack vendors.  You could only support one keying stack
   vendor, for example, but that's breaking portability which most
   SNMP stack vendors offer now.

3) create your SNMP stack so it offered its own keying stack/service
   itself.  This of course runs into conflicts when any other service
   on a device also needs to open a keying service or if 2 SNMP
   vendors are both going to exist on the same device (something my
   users do all the time).  This is the least friendly solution.

4) standardize on an API to talk between the keying stack and the SNMP
   stack (which really means just standardize on a keying API probably).

I didn't say it's impossible, because clearly it is possible.  It's
just difficult, requires a lot of work and you loose portability in
the process if you don't cover all possible permutations.

There are also security issues with passing those keys around within a
device and ensuring that the right service receives the right key.
This isn't a bad thing, it's just a difficult thing and it just needs
to be implemented carefully.  In some architectures, having the keys
readable by every application isn't an issue because they don't run on
memory-protected operating systems.  I use the other extreme most of
the time where I'm very picky about which applications have access to
which data.

-- 
Wes Hardaker
Sparta

---

From: Marcus Leech <[email-masked]>
Date: Tue, 05 Apr 2005 15:05:33 -0400

>the time where I'm very picky about which applications have access to
Everything in security (or any other piece of software for that matter)
  "needs to be implemented carefully".  I don't view that as any kind of
  argument for/against any particular architecture.  The converse
  "with architecture A, you can be quite sloppy in your implementation, 
and it'll
   probably still be secure" hangs by a very thin thread indeed.

With the exception of some very-highly-specialized pieces of hardware,
  once a key is in memory, one can get at it, whether the operating system
  enforces inter-application access controls or not.  Clearly, there are
  "prudent practices" those of us in the security implementation 
business use,
  but we must be very clear that such practices merely offer a barrier 
of *inconvenience*,
  rather than absolute security.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Apr 2005 12:26:03 -0700

>>>>> On Tue, 05 Apr 2005 15:05:33 -0400, Marcus Leech <[email-masked]> said:

Marcus> Everything in security (or any other piece of software for
Marcus> that matter) "needs to be implemented carefully".

Agreed.

Marcus> I don't view that as any kind of argument for/against any
Marcus> particular architecture.  The converse "with architecture A,
Marcus> you can be quite sloppy in your implementation, and it'll
Marcus> probably still be secure" hangs by a very thin thread indeed.

Never said otherwise.  When you have 1 keying service handing keys to
multiple other services which need those keys, it adds to system
complexity.  That's all I was saying and you seem to have taken a huge
leap to extrapolate what I was saying to proving that one architecture
is more secure than another.  I do consider some architectures to be
more complex than others, which does lead to implementation burdens
that may result in a greater number of places where mistakes can be
made.  It's often the case that if you implement any architecture
which has been proven to be secure perfectly you will never have
issues.  I agree.  I disagree that implementing all architectures
perfectly involve the same cost and complexity.

Marcus> With the exception of some very-highly-specialized pieces of
Marcus> hardware, once a key is in memory, one can get at it, whether
Marcus> the operating system enforces inter-application access
Marcus> controls or not.  Clearly, there are "prudent practices" those
Marcus> of us in the security implementation business use, but we must
Marcus> be very clear that such practices merely offer a barrier of
Marcus> *inconvenience*, rather than absolute security.

Agreed.  Security is always a sliding scale.  However, "trusted OSes"
that offer better protection than their counterparts are more secure
in most people's eyes because those "inconveniences" are difficult to
pass by easily.  Certainly specialized hardware is an even better
solution to the problem, assuming you can afford the cost.  But we
digress.

-- 
Wes Hardaker
Sparta

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 5 Apr 2005 12:48:57 -0700 (PDT)

HI,

Lets set up a conference call to talk this through.

Wes knows the internals of NET-SNMP. I've been going through
the SNMP Research code. Hopefully we can get some other
developers with knowledge of other SNMP stacks together
to work this out.

And if any developers that are using the SNMP Research stack
want to talk to me about details, I'm open to setting up
a private conversation. Send me email. (I cannot talk
in detail about the code, since it is covered by a
non-disclosure agreement, unless the other person
is also covered by the non-disclosure agreement.)

I would certainly appreciate talking with the SNMP developers
at Nortel. Let me know a time and a place, and I'll
try to come visit for a day or two. Likewise, if anyone
else wants to have a developer to developer talk,
please contact me.

I've been doing some serious work on SNMPv3 for the last
few months, and have had many meetings with the developers
from the network management group, and with the security
developers. SNMPv3 USM is quite difficult to understand,
and email doesn't provide an effective medium for
communication. Packet dumps, working code, multiple
screens with the RFCs are tools that are needed to
make progress.

> there in this particular case.

Regards,
/david t. perkins