Subject: Re: [Isms] SSH in TMSM

From: "Tom Petch" <[email-masked]>
Date: Mon, 6 Jun 2005 11:01:52 +0200

Interesting; time I think to split this thread.

A basic SSH question, what I wanted to clarify when I wrote my comment; do
applications running over SSH always use connections or do some, those in no
need of what connections have to offer, run direct over ssh-transport, with or
without using ssh-userauth?

As I said earlier, I saw ssh as ssh-architecture, ssh-transport, ssh-connect?,
ssh-userauth.  I put it as 'ssh-connect?' because I was not clear if connections
were always used, were regarded as a part of a conformant stack.  Anyone know?

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>; <[email-masked]>
Sent: Friday, June 03, 2005 7:47 PM
Subject: RE: [Isms] SSH in TMSM

> Hi Tom,
>
> Comments inline.
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Tom Petch
> > Sent: Friday, June 03, 2005 9:32 AM
> > To: [email-masked]
> > Subject: [Isms] SSH in TMSM
> >
> [...]
> >
> > I did wonder why the tmStateReference should be passing so
> > much information
> > about the session to the MPSP; I would have expected the
> > master secret, eg,  to
> > have stayed in the TMSP
>
> The requirements of ISMS are not clear regarding sessions. The RFC3411
> architecture does not have sessions, so if sessions are only supported
> at the transport mapping, and are not seen by the applications or the
> messaging subsystems, then the session data should not need to be
> passed to the MPSP.
> >
> > I also wonder about the multiplexing of upper layers onto
> > lower.  SSH has
> > connections and I have assumed that SNMP uses them and so the
> > state includes a
> > channel number, as opposed to using raw ssh transport.  But
> > for TLS, application
> > data
> > seems to map directly onto the TLS Record Protocol with no
> intervening
> > multiplexing.
>
> RFC3413 applications make the transport address decision, such as
> whether to use UDP port 161 or port 162. There is little discussion
> about how the application knows which transport mappings exist and
> should be used, unless the RFC3413 MIB modules are used. For
> Responses, the Command Responder sends the stateReference to the
> dispatcher via returnResponsePDU(); stateReference is a "reference to
> state information needed when sending a response."
>
> The RFC3413 applications do not support sessions or channels, unless
> that information is passed in the stateReference, or made available
> via the SNMP-TARGET-MIB suite.
>
> If sessions or channels can somehow be encoded into a transportDomain
> and transportAddress, they could fit into the existing stateReference
> and SNMP-TARGET-MIB suite. Whether various expectations of usage would
> fit into stateReference and the RFC3413 MIB modules is another thing.
> I expect the RFC3413 MIB modules are SET with a static configuration,
> representing administrative policy; I don't know how dynamic sessions
> can be configured into those MIB modules.
>
> If the expectation is that different SSH connections or channels will
> be used for request/response traffic and for notifications (Cf: ports
> 161/162), then the information "needed when sending a response" must
> be passed in the stateReference, and for non-response messages, the
> applications need to know how to request the different channels, and
> need to make the distinction in the transportDomain/transportaddress
> parameters of sendPDU().
>
> RFC3430 discusses some issues regarding connections. I think that the
> description of a transport-mapping for snmp-over-TLS or snmp-over-SSH
> would probably need to be as comprehensive as RFC3430. Such a
> transport mapping should include definition of a suitable
> trasnportDomain and transportAddress format, how to manage
> connections, how to use the RFC3413 MIB modules to store
> (dynamically-generated-channel) addresses for RFC3413 applications,
> and the security considerations.
>
> If the expectation is that different SSH connections/channels are used
> for different securityLevels, then the same applies. However, the
> RFC3413 applications do not know how to decide which securityLevel is
> needed for different types of data, so a new application model would
> probably need to be written that describes how the channel selection
> is made based on data sensitivity, and it would need to be discussed
> how the application would register itself with the dispatcher (new
> verbs - GETsensitive and GETinsensitive??). That is definitely outside
> the scope of this WG.
>
> David Harrington
> [email-masked]
>
>

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

---

From: Sam Hartman <[email-masked]>
Date: Sat, 18 Jun 2005 17:31:25 -0400

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> Interesting; time I think to split this thread.  A basic SSH
    Tom> question, what I wanted to clarify when I wrote my comment;
    Tom> do applications running over SSH always use connections or do
    Tom> some, those in no need of what connections have to offer, run
    Tom> direct over ssh-transport, with or without using
    Tom> ssh-userauth?

I'd generally expect anything in this space to be an ssh subsystem
(and thus use the connection protocol).  I don't think that would be
required; you could presumably start another service besides the
connection protocol, but I don't see why you would.  Implementing your
own service would involve more complexity, more coordination for
assigned numbers and more implementation complexity.

I'd look at netconf and sftp as examples of how to implement a
subsystem.