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

From: "Martin Soukup" <[email-masked]>
Date: Sun, 6 Mar 2005 21:30:57 -0500

Wes,

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?

I think this is an implementation issue, which is easily overcome.

Martin.

> -----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.
> 
> 
> 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

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

---

From: Wes Hardaker <[email-masked]>
Date: Sun, 06 Mar 2005 18:46:14 -0800

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
problematic.  How does a XXX keying demon on a machine know which
of multiple SNMP processes to send the keys too?

-- 
Wes Hardaker
Sparta