Subject: [Isms] Parallel vs in-band session setup.

From: Wes Hardaker <[email-masked]>
Date: Sun, 06 Mar 2005 13:32:23 -0800

As David P. has pointed out, every solution to date has talked about
the establishment of a session so I'm going to use that terminology
within, even though I'm not referring just to the SBSM protocol.

There are a number of ways to begin a session and establish the
necessary runtime parameters to make use of the session establishment
results.  The fundamental task ISMS is targeted with is the
establishment of at least keying information, regardless if that
keying information is to be used by USM or another security model.
For this discussion, I'm only going to talk about the session setup
aspect regardless of what information will be set up there.  We will
assume at least keying, however, though likely things like a session
ID or some other key material identify identifier and potentially
other properties might be needed in a full scenario.

The comparison document did a good job discussing the architectures
produced by the various solutions, but didn't discuss much of the
system ramifications of each of these architectures.  Here's a recap
of the architectures that will be useful for this message:

  2.4.1  USM and 2.4.3 SBSM  [Figure 1/4]

  [These are functionally very similar diagrams, so I'm only including
  one.  The fundamental point behind them is that they are direct and
  integrated within the protocol itself]

   +----------------------+          +----------------------+
   |       Manager        |          |       Managed        |
   |       Computer       |          |       Device         |
   | +------------------+ |          | +------------------+ |
   | |   SNMP Engine    | |          | |    SNMP Engine   | |
   | |                  | |          | |                  | |
   | |                  | | <------> | |                  | |
   | | +-----+ +------+ | |          | | +------+ +-----+ | |
   | | | USM | | SBSM | | |          | | | SBSM | | USM | | |
   | | +-----+ +------+ | |          | | +------+ +-----+ | |
   | +------------------+ |          | +------------------+ |
   +----------------------+          +----------------------+

  2.4.4  Transport-Layer Security Model [TLSM; Figure 5]

   +------------------------+               +------------------------+
   |        Manager         |               |        Managed         |
   |        Computer        |               |        Device          |
   | +--------------------+ |               | +--------------------+ |
   | |    SNMP Engine     | |               | |     SNMP Engine    | |
   | |                    | |               | |                    | |
   | |                    | | <- - - - - -> | |                    | |
   | | +------+ +-------+ | |               | | +-------+ +------+ | |
   | | | TLSM | |  USM  | | |               | | |  USM  | | TLSM | | |
   | | +------+ +-------+ | |               | | +-------+ +------+ | |
   | +----^---------------+ |               | +-----^--------------+ |
   |      |                 |               |       |                |
   | +----v---------------+ |               | +-----v--------------+ |
   | |  Security layer    | | <-----------> | |   Security layer   | |
   | +--------------------+ |               | +--------------------+ |
   +------------------------+               +------------------------+

  2.4.2  External User Security Model [EUSM, figure 2]

   +------------------------+                   +----------------------+
   |        Manager         |                   |        Managed       |
   |        Computer        |                   |        Device        |
   |                        |                   |                      |
   |            +---------+ |                   | +--------+           |
   |            | Session | | Session establish | | Session|           |
   |            | Mgmt    | |<----------------->| | Mgmt   |           |
   |            +---------+ |                   | +--------+           |
   |                 ^      |                   |     ^                |
   | +---------------|----+ |                   | +---|--------------+ |
   | |   SNMP Engine |    | |                   | |   | SNMP Engine  | |
   | |               |    | |  Message traffic  | |   |              | |
   | |               v    | | <---------------> | |   v              | |
   | |          +-------+ | |                   | | +-------+        | |
   | |          |  USM  | | |                   | | |  USM  |        | |
   | |          +-------+ | |                   | | +-------+        | |
   | +--------------------+ |                   | +------------------+ |
   +------------------------+                   +----------------------+

   [Editorial note: I changed "key establish" to "session establish"
   in the above diagram, as we have not yet decided that only keying
   information is needed.  IE, I'm using "session establishment" in a
   way that includes "key establishment" but is not limited to just
   key negotiation.]

One key difference in all of these diagrams is important to
understand.  Specifically, whether keying and session setup is passed
directly within the communication "path".  In USM and SBSM everything
is done by the security model.  In TLSM, it is done by a lower layer
within the stack, but none the less is done over the same transport
domain/address that will be used to fundamentally communicate over
after the session has been set up.

However, in EUSM and any replacements that involve parallel
establishment of session and keying information, this establishment is
manipulated over a separate transport domain/address which means that
internally to the box the information needs to be conveyed from one
service (the key establishment service) to another (the SNMP engine
that needs it).  For some devices, these services maybe implemented as
a single entity (EG, a "process" under many common operating systems;
if you want a SNMP reference see HOST-RESOURCES-MIB::hrSWRunIndex).

If these services are to be implemented independently, this means that
session information needs to be passed from the session establishment
service to the SNMP engine responsible for handling the request.  IE,
in EUSM from the EAP and AAA/Radius services to the SNMP Engine in the
device.

What does this mean internally in today's modern operating systems?
It means that the processes need a decent form of inter-process
communication which is also protected from disclosure and modification
from the other processes as well.  This can be implemented in many
ways, and is frequently done so using anything from shared memory on
simple devices to internal signaling mechanisms to ...  Thus vendors
of session establishment services will need to work closely with
vendors of SNMP stacks in order to make this possible.  For highly
portable packages, it may be extremely difficult to handle every
possible internal communication path that may be found on the systems
it wants to support.  It means that commercial companies may be able
to force users to buy not only their SNMP stack but their
session establishment system as well.

What makes this even harder is the number of ways in which SNMP is in
use today.  For SNMP, it is important to remember that there are
really 2 services that need to be thought about.  Specifically, many
systems contain both a command receiver as well as a notification
receiver and frequently a proxy as well.  Many systems have these
services each running as separate "processes" within the operating
system.  I've worked with many users that also run the same service in
parallel on two different network ports.  EG, they'll run one snmp
command responder on the default port 161 and another on port 9161
because they offer different features and both are needed for some
reason or another.  The end result is that figure 2 above from section
2.4.2 is somewhat misleading about the internal complexity of what
will need to be implemented.  A potentially better diagram would
depict multiple data paths and multiple engines:

   +------------------------+                   +----------------------+
   |        Managed         |                   |        Manager       |
   |        Device          |                   |        Computer      |
   |                        |                   |                      |
   |            +---------+ |                   | +--------+           |
   |            | Session | | Session establish | | Session|           |
   |            | Mgmt    | |<----------------->| | Mgmt   |           |
   |            +---------+ |                   | +--------+           |
   |               ^      ^ |                   |     ^                |
   | +-------------|----+ | |                   | +---|--------------+ |
   | | SNMP Engine |    | | |                   | |   | SNMP Engine  | |
   | | #1          |    | | |  Message traffic  | |   |              | |
   | |             v    | | | <---------------> | |   v              | |
   | |        +-------+ | | |                   | | +-------+        | |
   | |        |  USM  | | | |                   | | |  USM  |        | |
   | |        +-------+ | | |                   | | +-------+        | |
   | +------------------+ | |                   | |                  | |
   |                      | |                   | |                  | |
   |               ______/  |                   | |                  | |
   |               |        |                   | |                  | |
   | +-------------|----+   |                   | |                  | |
   | | SNMP Engine |    |   |                   | |                  | |
   | | #2          |    |   |  Message traffic  | |                  | |
   | |             v    |   | <---------------> | |                  | |
   | |        +-------+ |   |                   | |                  | |
   | |        |  USM  | |   |                   | |                  | |
   | |        +-------+ |   |                   | |                  | |
   | +------------------+   |                   | +------------------+ |
   +------------------------+                   +----------------------+

   [I put the managed device on the left this time because I started
   editing that box first and should have done the other; really
   either side could contain any number of engines and it doesn't
   matter]

This means that as a given device needs to send SNMP messages to
another device, it needs to kick the session establishment service to
say "hey, go make this connection for me" and the receiving end must
be properly told which internal engine to pass the information too.
I've had clients with 4 engines running on one system before, with at
least 3 of them being from different vendors.  At a minimum, 2 must be
supported by the resulting architecture since most packages I'm aware
of implement the notification receiver in a separate process from the
command generator.

In order to make a parallel establishment setup work, such as EUSM or
an IKE replacement or..., we would have to:

1) Declare the above an implementation problem and not worry about
   it.  Note that implementing such internal message passing is
   subject to potential security and implementation problems resulting
   from the complexity and sensitivity of the information being passed
   around.  [Plus the interoperability and portability problem
   mentioned above]

2) Standardize an internal session information passing mechanism along
   with the protocol we're going to use.

3) Not choose an architecture that requires parallel session
   establishment.  Both TLSM and SBSM don't require this.  An
   internally passed SASL implementation wouldn't require this
   either.

I'm strong against #1, but I think #2 is at least usable but I really
think #3 is the right way to go and that we should stick to an
architecture that does not require such complex internal message
passing.

-- 
Wes Hardaker
Sparta

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 7 Mar 2005 00:04:41 -0500

>> Just wondering, but wouldn't it make more sense for the
session/key establishment mechanism
	>>  to be implemented as a library-type-thing (i.e. shlib) and
thus execute within whatever SNMP
	>>  Engine process is requesting a session?
	>
	> It's the receiving side of the connection establishment which
is more
      > problematic. How does a XXX keying demon on a machine know which
      > of multiple SNMP processes to send the keys too?
     
[Uri>] First question: do you want the "keying entity" to live within
the
SNMP engine, or outside of it (like IKE in IPsec)? My answer is - it
should
be inside, as a part of SNMP engine.

I propose making "keying subsystem" a new security model, whose sole 
responsibilities are:

   1. authenticating the parties;
   2. authorizing them (possibly via back-end such as RADIUS);
   3. determining session lifetime and creating (or assigning) identity;
   4. obtaining VACM group entry and mapping that identity onto it;
   5. generating session keys and installing them into USM (for those
who
      just can't stand this model - to xSM :-).

In that case all the session establishment traffic can be cleanly
encapsulated
in SNMPv3, be parsed by SNMPv3 protocol engine and handled to the right
Security
Model (which in turn will configure the other Security Models for
upcoming SNMP
traffic).  [started sounding similar to SBSM]

Another advantage of following the above - SNMP engine can preserve its 
multi-version multi-lingual capabilities. And no intreaction with 

Regarding use of EAP - we cannot use EAP encapsulation. But we'll
probably have to re-use the algorithms (like ARCHIE EAP method),
because there are just so many ways to do key exchange...

In the below analysis, I believe that Wes is correct. Except that IMHO
it is not enough to do just the keying - xACM mapping is also necessary.

	 > -----Original Message----- 
	> From: [email-masked]
[mailto:[email-masked]] On 
	> Behalf Of Wes Hardaker 
	> Sent: March 6, 2005 4:32 PM 
	> To: [email-masked] 
	> Subject: [Isms] Parallel vs in-band session setup. 
	> 
	> 
	>    |        Manager         |               |        Managed
| 
	>    |        Computer        |               |        Device
| 
| | 
	>    |      |                 |               |       |
| 
	>    |        Manager         |                   |
Managed       | 
	>    |        Computer        |                   |
Device        | 
	>    |                        |                   |
| 
	>    |                 ^      |                   |     ^
| 
	>    |        Managed         |                   |
Manager       | 
	>    |        Device          |                   |
Computer      | 
	>    |                        |                   |
| 
	>    |               ^      ^ |                   |     ^
| 
	>    |                      | |                   | |
| | 
	>    |               ______/  |                   | |
| | 
	>    |               |        |                   | |
| | 
	>    | |        +-------+ |   |                   | |
| | 
	>    | |        |  USM  | |   |                   | |
| | 
	>    | |        +-------+ |   |                   | |
| |

---

From: "Martin Soukup" <[email-masked]>
Date: Wed, 16 Mar 2005 21:50:07 -0500

You do, potentially, need a shared data store on the Managed Device. All
keying information requests could come from the SNMP Engines (i.e.
requesting a session of the SNMP Engine will have it request keys from its
local session "controller"). Maybe I've misunderstood something, but I don't
see any hard need to do IPC in the implementations, although you may need a
shared store the heap or the file system tend to be adequate. Furthermore,
in the integrated version no local information storage is required since the
key negotiation in eUSM happens outside the SNMP IPC.

Martin.

> From: Wes Hardaker [mailto:[email-masked]]
> Sent: March 6, 2005 9:46 PM
> To: Soukup, Martin [CAR:5K50:EXCH]
> Cc: [email-masked]
> Subject: Re: [Isms] Parallel vs in-band session setup.
> 
> 
> Martin> Just wondering, but wouldn't it make more sense for the
> Martin> session/key establishment mechanism to be implemented as a
> Martin> library-type-thing (i.e.  shlib) and thus execute within
> Martin> whatever SNMP Engine process is requesting a session?
> 
> It's the receiving side of the connection establishment which is more