Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10

From: <[email-masked]>
Date: Wed, 4 Jun 2008 11:59:14 +0300

Juergen Schoenwaelder wrote
> So please, help us by taking a look at the document and sending out
> proposals what you think need to be changed or let us know that you
> took a look at the documents and they appear to be fine already.

Taking a look at draft-ietf-isms-secshell-10 only:

Section 4.2 needs to consider both SSH client and server cases
(probably separately); currently, the discussion about extracting an
identity from the SSH layer seems to properly describe only SSH server
behavior. Maybe something along these lines:

   SSH server:

   On SSH server, tmSecurityName is a human-readable name in
   SnmpAdminString format that is mapped from the user identity that
   has been authenticated by the SSH Authentication Protocol.

   How the SSH identity is mapped to a tmSecurityName should be
   administratively configurable in the LCD.

   Typically, the LCD would provide a mapping from the SSH user name
   (the user name field of the SSH_MSG_USERAUTH_REQUEST message) to
   tmSecurityName, and information about how the user is to be
   authenticated (e.g., way to verify the password for "password"
   authentication, or user's public key for "publickey"
   authentication). AAA services can also be used to provide
   this information.

   SSH client:
   
   On SSH client, tmSecurityName is a human-readable name in
   snmpAdminString format that is mapped to (1) how the server is
   authenticated, and (2) how the client authenticates itself to the
   server.

   This mapping is provided by the LCD. Typically, the LCD would
   contain at least (1) the server's host public key, and (2) the SSH
   user name to be sent by the client, the authentication method to
   use (e.g., "publickey" or "password"), and a credential appropriate
   for the authentication method (e.g., a private key or a password).

Section 4.3: if we assume that TARGET-MIB will contain the
notification receiver's IP address + the IANA-assigned port number,
and we do the "do we already have a session" check using both of them
(and not just the IP address), then we have the same restriction as
RFC 3430: notifications can't be sent over a transport session opened
by the other end. Section 4.3 probably needs a small update to reflect
this (and this restriction should be explicitly said somewhere earlier
in the document)

Section 5.1: the text about tmsSecurityName also assumes that
"incoming messages" implies "incoming SSH connection". This 
is clearly not the case for e.g. command responses.
suggested replacement:  "tmsSecurityName = see Section 4.2."

Section 5.3 is basically OK, but could benefit from some
clarifications.

Updated steps 1..3:

   1) The provided transport domain, transport address, securityName
   and securityLevel are used to lookup an associated entry in the
   Local Configuration Datastore (LCD).

   2) Using destTransportDomain and destTransportAddress, the client
   will establish an SSH transport connection using the SSH transport
   protocol, authenticate the server (using information in the LCD
   entry), and exchange keys for message integrity and encryption.
   The parameters of the transport connection are provided in an
   implementation-dependent manner.

   3)The client will then invoke an SSH authentications service to
   authenticate the user, such as that described in the SSH
   authentication protocol [RFC4252].  The user name and credentials
   used to authenticate are determined by the LCD entry.

   If the authentication is unsuccessful [...]

The section (or some other section) should also explain the behavior
of the other end (SSH server side). Here's a rough attempt:

   1) The server will listen for incoming connections; by default,
   the IANA-assinged TCP port is used.
    
   2) When a connection is received, the server will establish 
   an SSH transport connection using the SSH transport protocol.
   The host public/private keypair is provided in an implementation
   dependent manner.
    
   3) The server will then authenticate the client. How the client is
   authenticated is implementation dependent. It may involve
   communication with an AAA server. The LCD is used to determine the
   SNMP securityName for this user.

   4) The client wil then request a channel of type "session" and  
   invokve the SNMP subsystem.

   5) Create a session entry in the Local Configuration Datastore, 
   containing the transportDomain, transportAddress, securityName,
   securityLevel, and SSH-specific parameters, and create a 
   tmStateReference to reference the entry.

Section 6.3, "This MIB module models a sample Local Configuration
Datastore."  doesn't seem to be true anymore?

Section 7: the counters in the sshtmSession group seem to apply
only to SSH client side, not server? This should be said
explicitly.

Best regards,
Pasi
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 4 Jun 2008 12:13:52 -0400

Hi,

I will start to work on these suggestions (and those from other
emails). I will respond to the specific text suggestions in a separate
email. 

I need something from the WG and chair before I make the proposed
changes. 

I believe the WG reached consensus to permit reuse of an existing
session, even if it was initially established in the opposite
direction, as well as permitting agent initiation of a session.

The proposed text contains statements like "notifications can't be
sent over a transport session opened by the other end." The port we
will be sending to will already be listening, because it already
listens for responses. And the transport model doesn't know what type
of operation is contained in a message; it simply accepts an outgoing
wholeMessage from the MPM, or it simply accepts the wholeMsg from SSH
and passes it to the MPM, which detrmines which type of operation is
involved. So the SSH layer should not care which operation type is
contained in the message.

Unless of course, we think that SNMP command generator/responder
applications run over a different SSH service or a different SSH
subsystem than SNMP notification origination and notification receiver
applications. The RFC3411 architecture was designed such that an
entity is an entity, and which applications they support internally is
an implementation decision. The transport model shouldn't care, and
should be able to use the same SSH service/subsystem for all SNMP
applications.

--

While we have been discussing how to specify the agent as SSH client,
we asked the OPS-AREA and OPS-DIR operators for feedback on how they
want to do configuration/key distribution for SSH client credentials.
My impression of the feedback is that a MIB is not called to hold the
keys, but others should review the discussion as well.  

Part of the discussion there (parts of which I copied here) suggests
that a subscribe-style notification like that used in netconf might
also meet operators' needs for SNMP/SSH. If that is the case, then we
could avoid having the SNMP agent act as an SSH client. We might have
to provide some type of non-SSH request-for-SSH-session capability
(callhome), such as a USM or noAuthNoPriv notification to the manager.
I think we could design a solution where the "agent" can always be the
SSH server, never the client. This would be more consistent with
current SSH deployment, possibly simplify our processing (except the
callhome and possibly informs), and enable us to always use both
server and client authentication.

I think we should discuss this before making changes that force this
one way or the other.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, June 04, 2008 4:59 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Isms] ssh notifications and
draft-ietf-isms-secshell-10

---

From: <[email-masked]>
Date: Thu, 5 Jun 2008 23:11:44 +0300

> direction, as well as permitting agent initiation of a session.

I have nothing against this, if we come up with text specifying how it
works. But as I wrote earlier, if transportAddress contains both the
IP address and TCP port number, and we require both of them to match
when determining whether a session already exists, it seems reusing a
session won't usually happen.

If the port numbers are required to match, for "reuse in opposite
direction" to occur, the administrator configuring the notification
target has to know the source TCP port that will be used (or was used)
for the "inbound" connection (initiated by the notification receiver).

This actually would be the case when the notification receiver opens 
a connection, configures the TARGET-MIB (in effect "subscribing" to 
some notifications), and keeps the connection open. (So perhaps
it's not an unrealistic case.)

But it doesn't seem to really work for the case where notification
target configuration is static -- unless we specify a different
way to compare the transportAddresses (e.g. ignore the port number,
compare just the IP address part), or map the notification targets
to existing connections.

> listens for responses.  And the transport model doesn't know what
> type of operation is contained in a message; it simply accepts an
> outgoing wholeMessage from the MPM, or it simply accepts the
> wholeMsg from SSH and passes it to the MPM, which detrmines which
> type of operation is involved. So the SSH layer should not care
> which operation type is contained in the message.

I agree that the SSH layer should not care. BTW, the TCP transport
mapping (RFC 3430) has this constraint -- but I guess it doesn't
really inspect the operation type either..?

> should be able to use the same SSH service/subsystem for all SNMP

I agree, I don't think we need to assume separate SSH subsystems.

I agree this would be simpler (if it's otherwise an acceptable
solution).

It would need a way how the to-be-sent notifications are mapped to 
the existing connections that were initiated by the notification
receiver.

Would requiring that the notification receiver updates the
transportAddress in TARGET-MIB when he connects (in effect,
"subscribing" to notifications when a session starts) be acceptable?

Another way would be to ignore the TCP port number when determining
whether a session exists (just check securityName, transportDomain, IP
address, and securityLevel) -- although that would complicate running
multiple SNMP managers on the same host (and I haven't thought about
NATs yet).

Best regards,
Pasi

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Jun 2008 19:54:36 -0400

--On Wednesday, May 28, 2008 10:54:19 AM +0200 Juergen Schoenwaelder 
<[email-masked]> wrote:

> As chair, I believe writing an SSH MIB module is not part of our
> current charter.

Nor do I.  One of the reasons this is important is that participation in a 
working group is largely affefcted by who is interested in its chartered 
work.  Since our chartered work does not include an SSH MIB module, it 
seems reasonable to assume that there are people who would be interested in 
participating in such work, if it happened, who are not currently involved 
in this working group.  I would expect those to include members of the SSH 
community, including some of the many implementors of that protocol.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Jun 2008 20:31:55 -0400

--On Friday, May 30, 2008 12:08:01 PM -0400 David Harrington 
<[email-masked]> wrote:

> I suggest that we add a mapping table to the SSHTM-MIB that includes
> 1) an INDEX based on values of tmTransportDomain, tmTransportAddress,
> tmSecurityName, and tmSecurityLevel from the tmStateReference, and
> 2) an SSHIndex column that is an OCTET STRING, whose format and value
> is implementation-dependent, but the DESCRIPTION would be that it is a
> value that can be used in an implementation-dependent manner to refer
> to an SSH set of credentials associated with a particular SSH entity.

I would support adding such a table.

> If we want to require SSHindex to be human-readable to make it easier
> for operators, we can use an SnmpAdminString.

I suspect that in reality, the underlying values will usually be either 
human-readable strings or small integers.  This, storing this as an 
SnmpAdminString rather than as an OCTET STRING may be useful, especially if 
it will encourage user agents to display its value as a string.

> If the same SSH identity might be authenticated using different
> algorithms, then I would not be averse to adding columns that can
> specify the authProtocol values, similar to usmUserTable.

If the same SSH identity might be authentiated using different algorithms, 
then either you need multiple entries in the SSH LCD, or a single entry 
containing all the information necessary to support multiple algorithms.  I 
don't think there's any reason to treat this situation specially at the 
SSHTM layer, any more than we would treat specially support for multiple 
ciphers or hash algorithms (the LCD may tell the SSH client which 
algorithms are acceptable, but this information is not passed as an 
additional parameter separate from the SSH LCD index).

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Jun 2008 20:45:49 -0400

--On Friday, May 30, 2008 04:39:53 PM +0200 Eliot Lear <[email-masked]> 
wrote:

> I do not think securing host keys necessarily needs to be accomplished
> in this group, and I'm not even sure one should go to great effort to
> discuss them in security considerations, except as it directly relates
> to SNMP

Agree.

> On the other hand, the issue I had with host keys is that they do not
> lend themselves easily today to autoconfiguration out of the box when
> you have tens of thousands of devices.  That is something X.509 might
> prove to be more useful, and hence my interest in that area.

Until very recently, I saw little point in doing further work on X.509 for 
SSH.  There does not seem to be much interest in the SSH user community; 
most people seem to be perfectly happy with leap-of-faith, probably partly 
because it is convenient and partly because the ratio of information 
touting that convenient to information about the drawbacks is too high. 
There also has not been much interest in actually getting the work done; 
progress has been slow-to-stalled for several years.

However, as I've reviewed and prepared replies to an earlier thread, I've 
come to the conclusion that there are probably a large number of 
organizations whose existing authentication infrastructure is based partly 
or entirely on X.509 certificates, and for that constituency, ISMS does not 
really meet its goal if SSH does not support use of X.509 certificates.  As 
a result, I really would like to see someone pick up the SSH X.509 work, 
finish it, and get it published.  IMHO that is not in scope for ISMS, but 
it is something that could be done by a hypothetical 'sshext' WG (along 
with preparation of SSH MIB's), or as an individual submission.

Note that I don't think we've failed our charter here.  Using SSH has 
allowed us to produce a system that will allow many or most operators to 
use their existing infrastructure for _user_(*) authentication (i.e. 
RADIUS), which we would not have gotten with TLS, and still provides a 
better story for _server_ authentication than does USM, since it is 
possible to use leap-of-faith or to collect a list of devices' SSH keys and 
distribute them to management stations, or to make use of existing Kerberos 
infrastructure (in both directions).

-- Jeff

(*) Please excuse the non-SNMP-oriented terminology; its use here allows me 
to make my point more clearly
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 10 Jun 2008 21:03:33 -0400

> it's not an unrealistic case.)

Yes, but if you're going to do that, chances are that you are not actually 
listening for incoming connections on that transport address (in fact, many 
systems make it difficult or impossible to both listen for incoming TCP 
connections on a port and originate outgoing TCP connections from that 
port).  So you'd want that "subscription" to continue to exist only as long 
as the session is open.

I think at one time we agreed in principle that there was nothing wrong 
with reusing an existing incoming session which happened to match, but I 
don't think there was a strong feeling that this was an important feature. 
Of course, I may be wrong, and I particular like the notion of a management 
station which opens an SSH session and "subscribes" to notifications to be 
sent back along the same session as long as it is open.  Among other 
things, this would provide particular benefits for the scenario in which 
the management station is behind a NAT.

> the existing connections that were initiated by the notification

I don't make heavy use of SNMP as an operator, but I have enough experience 
with operatign and monitoring systems and services to have some idea what 
the common usage patterns probably are.  I see two kinds of likely patterns:

(1) A "dynamic" recipient, such as a management workstation that connects 
to a particular device and configures the device to send notifications to 
it as long as the user is interested in seeing them.

(2) A "static" recipient, such as a collector to which all or many devices 
are configured to send notifications for the purpose of logging, 
monitoring, or statistics-gathering.

The first kind benefits from a "subscription" model in which notifications 
are sent over the already-existing connection.  In this case, it would be 
possible to simply set the transportAddress appropriately when setting up 
the "subscription", and allow it to match the existing session for as long 
as it exists.  The main problem I see with this is that in practice, the 
interface between SNMP management software and the SSH client 
implementation is unlikely to allow the former to discover the local 
transport address of the outgoing SSH connection.  I think I've said this 
before, but I'd love to see a special kind of transport address that can 
express "my existing session", which is really what this kind of client 
wants.  Presumably this would be represented within an SNMP engine by a 
transportAddress containing the session's tmStateReference, at least 
conceptually, but I fear there is an abstraction violation here.  It would 
be great if someone could figure out how to do this right.

The second kind really can't reuse an existing session, because that would 
require the collector to maintain open SSH connections to every possible 
notification originator, which could potentially be tens or even hundreds 
of thousands of connections.  Further, while all the NO's likely know who 
the collector is, the reverse may not be true.  I believe that this kind of 
operation requires that notification originators be able to originate SSH 
connections.

> multiple SNMP managers on the same host (and I haven't thought about

I don't think this is a good idea, for exactly the reasons you quote.  It 
assumes not only that multiple connections from the same host are 
equivalent (which they probably are not), but that multiple connections 
from the same IP address are in fact from the same host, which 
unfortunately is often not the case either.  I'd avoid this approach; it's 
asking for trouble.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jun 2008 17:10:54 +0200

On Tue, Jun 10, 2008 at 09:03:33PM -0400, Jeffrey Hutzelman wrote:

> I don't make heavy use of SNMP as an operator, but I have enough 
> experience with operatign and monitoring systems and services to have 
> some idea what the common usage patterns probably are.  I see two kinds 
> of likely patterns:
>
> (2) A "static" recipient, such as a collector to which all or many 
> devices are configured to send notifications for the purpose of logging,  
> The first kind benefits from a "subscription" model in which 
> notifications are sent over the already-existing connection.  In this 
> case, it would be possible to simply set the transportAddress 
> appropriately when setting up the "subscription", and allow it to match 
> the existing session for as long as it exists.  The main problem I see 
> with this is that in practice, the interface between SNMP management 
> software and the SSH client implementation is unlikely to allow the 
> former to discover the local transport address of the outgoing SSH 
> connection.

There is some truth in this and clearly in the case of NATs, what you
discover might not be what the other side sees/needs.

> I think I've said this before, but I'd love to see a special 
> kind of transport address that can express "my existing session", which 
> is really what this kind of client wants.  Presumably this would be 
> represented within an SNMP engine by a transportAddress containing the 
> session's tmStateReference, at least conceptually, but I fear there is an 
> abstraction violation here.  It would be great if someone could figure 
> out how to do this right.

Associated to this is a need for garbage collection. If the session
goes away, we likely want the notification target subscription(s)
pointing to the session also to go away.

> The second kind really can't reuse an existing session, because that 
> would require the collector to maintain open SSH connections to every 
> possible notification originator, which could potentially be tens or even 
> hundreds of thousands of connections.  Further, while all the NO's likely 
> know who the collector is, the reverse may not be true.  I believe that 
> this kind of operation requires that notification originators be able to 
> originate SSH connections.

I agree. And given the tradition of SNMP always using pattern (2), I
believe we must support (2) while pattern (1) sounds like a nice to
have new feature if someone figures out how to make subscription and
garbage collection of subscriptions work.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Jun 2008 17:21:31 +0200

> the management station is behind a NAT.

I think you've just stated very well the reason why I feel strongly 
about this point.  Based on Pasi's comments I wonder whether the 
abstraction in the table is correct, and whether we would do better to 
refer to the ssh service name ("isms" or "snmp" or some such) instead of 
TCP port numbers.  Having another example OTHER than SSH I think would 
help, as Dave has indicated previously.

Eliot

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Jun 2008 12:09:01 -0400 (EDT)

On Fri, 13 Jun 2008, Eliot Lear wrote:

> TCP port numbers.

The ssh _service_ name is always going to be "userauth", followed by
"connect".  I think you're referring to a subsystem name.  It might be
reasonable to include an ssh subsystem name, and I won't object beyond
this one comment:

Subsystem names are intended to be treated as protocol constants, like
names of other kinds of extensions, rather than as values generated
automatically or selected by an administrator.  The DNS-based
extensibility is there, so one could certainly imagine a deployment where
the operator has made up names under his own domain, but this should not
be the expected model.

Even if we add a subsystem number, I don't think we can eliminate the
port, because I think it is very likely that there will be situations
where "normal" SSH and SNMP will need to run on separate ports.  On most
platforms, this is the case any time the SSH connections are handled by
different processes, which would be the case if the SNMP software came
with a different SSH implementation than that used on the rest of the
system, or even if they are the same but need to be configured
differently.  For example, one might want to run SNMP behind an SSH server
that lets in anyone who can authenticate, deferring all authorization
policy to VACM; this would be a separate server from one which only lets
in people who have accounts on a machine.

-- Jeff

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Jun 2008 20:13:10 +0200

Jeffrey Hutzelman wrote:
> "connect".  I think you're referring to a subsystem name.

You're right.  My error.

> It might be
> where "normal" SSH and SNMP will need to run on separate ports.

Yes, but remember what we're looking for- a registered instance of an 
SSH connection.  So as long as we're not indexing off of ports, I would 
imagine having the port there does no harm, but I'm also not sure what 
good it does.

>    On most

Right.  But just for clarity's sake, why does  a TCP port number need to 
be in any table?

Eliot

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Jun 2008 14:41:20 -0400 (EDT)

> imagine having the port there does no harm, but I'm also not sure what

Oh, I'm sorry; you're talking about _incoming_ connections.  Sure, you
don't need to know the remote port in that case.  But you need it in the
"transport address" because you need it to establish outgoing connections,
not only for notifications (and I think I explained why I think we still
need that), but also for commands.

> Right.  But just for clarity's sake, why does  a TCP port number need to

Does what I said above answer this, or at least clear up a
miscommunication?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Jun 2008 22:25:41 +0200

> need that), but also for commands.

For outgoing connections as well, only perhaps the situation is indeed 
more complex if this table is the source of SSH parameters used to 
connect.  If so, perhaps what's really going on here is that we need two 
separate tables- one for configuration and one with operational bindings 
between the two??
> Does what I said above answer this, or at least clear up a

I think so...

Eliot