Subject: RE: [Isms] SSH vs SNMP concepts

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 29 Aug 2005 16:28:32 -0700

Multiple SSH clients can be resident on a host.  I believe that multiple
SSH server would require each server to run on a different port.
Depending on what you want to achieve you may be able to have multiple
subsystems running in a single server, however all of those subsystems
would be authenticated to the SSH client with the same credential used
in establishing the SSH session.  

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, August 29, 2005 4:03 PM
> To: [email-masked]
> Subject: [Isms] SSH vs SNMP concepts
> 
> Hi,
> 
> In SNMP, it is acceptable to have multiple engines resident 
> on the same device, typically listening at different 
> transport addresses.
> SNMPv3 uses the engineID (SNMPv3) to differentiate the engines.
> 
> If multiple SSH servers or multiple SSH clients exist on the 
> same host, how would one differentiate them? Is this standardized?
> 
> David Harrington
> [email-masked]
> 
> 
> 
> 
> _______________________________________________
> 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: "David T. Perkins" <[email-masked]>
Date: Mon, 29 Aug 2005 19:58:21 -0700 (PDT)

HI,

A little known secret of SNMP is that "command generators" (that
is, management applications) DO NOT need to have a value of
an engineID. Likewise, receivers of TRAPs and "proxy" senders
of INFORMs do not need a value for an SNMP engineID.

And in the majority of the implementations of SNMP management
applications, there is not a shared SNMP engine. Each one
uses a separate (and unique) transport address.

The reason that the above do not need an SNMP engineID is
that SNMPengineIDs are used for two purposes (identifying
the "source" of management info, and for use in USM of
identifying the "authoritative engine"), and that these
two uses are not applicable to command generators, TRAP
receivers, or proxy INFORM senders.

For ISMS-SSH security model, more than likely the sub-fields
of field msgAuthoritativeEngineID will be totally different
than those for USM, and thus, field msgAuthoritativeEngineID
will not be in messages!

Also, if is possible for multiple SNMP engines to be
sharing the same transport address. The value of 
contextEngineID specifies which command responder
that a request is for. That is, the transport addresse
(and message type) determines the value of
msgAuthoritativeEngineID to use for SNMPv3/USM, and
contextEngineID specifies for ALL SNMPv3/* messages
the "source" of the management info. 

Back to your question, for SSH, you can specify as
a startup option what port you want an SSH server
to use, (and the port that you want an SSH client
to use for the server). However,  I don't know if the
the "known_hosts" files used by most (maybe all) SSH
implementations, contain just NETWORK addresses (that is 
just IP address), or can also contain TRANSPORT addresses.
If so, then multiple SSH servers can be accessed 
on a system. This would only be needed if "ships
in the night" implementation was needed for multiple
SNMP command responders on the same system. Or
"ships in the night" implementation of a command
responder and one or more "notification receivers." 

I hope this helps, but it may confuse readers. Sorry.
Please ask questions if you are confused.

> > same host, how would one differentiate them? Is this standardized?

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 29 Aug 2005 21:01:23 -0700

Hi -

> From: "David T. Perkins" <[email-masked]>
> To: "Salowey, Joe" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, August 29, 2005 7:58 PM
> Subject: RE: [Isms] SSH vs SNMP concepts
...
> of INFORMs do not need a value for an SNMP engineID.

Of course, the keys for such an application can't be managed using
USM, since entries in the usmUserTable are indexed by, of all things,
usmUserEngineID, and usmUserName.  This means that even if one
has key update infrastructure in place to update all the "agents", these
"managers" are out in the cold.  Could this deployment strategy be a
problem?

> uses a separate (and unique) transport address.

It's perfectly reasonable for a single engine to use multiple transport
addresses.  Whether different applications do (or don't) share an
SNMP engine is an implementation decision.  For things like handling
notifications, using multiple engines would clearly have some rather
undesireable properties, but when we did SNMPv3 it was crystal clear
that the architecture had to be able to support it, and it was one of
the motivations for the introduction of the engineID concept.

> receivers, or proxy INFORM senders.

You omit a third important purpose: key distribution using the
mechanisms of RFC 3413.

> than those for USM, and thus, field msgAuthoritativeEngineID

I don't understand the logic of this statement.  USM knows nothing
about the sub-field structure of msgAuthoritativeEngineID.
The motivation for the structure of engineIDs is to provide a means
of ensuring uniqueness in an administrative domain, and not to support
any other inferences that might be made as a result of parsing them.
They are supposed to be essentially opaque.

> the "source" of the management info.
...

A slight clarification to Dave's statement: "determines" should
not be understood as "allows one to compute a priori".  Rather,
knowing the transport address and message type, if one has a
cached engineID for that combination, permits one to use that
engineID in the hope of avoiding a round-trip for engineID discovery.

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 30 Aug 2005 10:24:59 -0400

Hi,

Let's not confuse all the non-SNMP security people on this list by
discussing "little known secrets of SNMP" that have little relevance
to the question asked. If you want to discuss SNMP esoterica, I
suggest at least changing the subject line.

The question asked was about whether SSH had a mechanism that would
allow us to mirror a specific SNMP capability - "If multiple SSH
servers or multiple SSH clients exist on the 
same host, how would one differentiate them? Is this standardized?"

Thanks,
dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Tuesday, August 30, 2005 12:01 AM
> To: [email-masked]
> Subject: Re: [Isms] SSH vs SNMP concepts
> 
> Hi -
>