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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 May 2008 08:25:27 +0200

Hi,

to make progress on draft-ietf-isms-secshell, we need to turn results
of discussion threads into concrete words to be put into the document.
It will help our editor tremendously if those who have been following
the discussion closely can take a look at draft-ietf-isms-secshell-10
and come up with concrete proposals what should be added or changed.

It seems that some of the issues discussed recently are already
covered (or at least implicitely covered) and it seems some other
discussion topics are more likely candidates for an appendix where
some background information is provided while yet other stuff seems to
be implementation considerations since we assume SSH configuration to
be out of scope for this work.

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.

Thanks,

/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: Wes Hardaker <[email-masked]>
Date: Tue, 27 May 2008 08:55:57 -0700

>>>>> On Tue, 27 May 2008 08:25:27 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> It seems that some of the issues discussed recently are already
JS> covered (or at least implicitely covered) and it seems some other
JS> discussion topics are more likely candidates for an appendix where
JS> some background information is provided while yet other stuff seems to
JS> be implementation considerations since we assume SSH configuration to
JS> be out of scope for this work.

I think it would be a grave failing of the working group not to make the
defined transport domain completely workable from an interoperable point
of view for all the expected use cases.

Will notifications work over SSH without a defined MIB that allows the
TARGET-MIB and NOTIFICATION-MIB to be useful?  Yes, assuming that
vendors provide a LCD configurable implementation themselves (as David
points out).

How is it useful to the community to make the configuration of the
needed parameters for sending a notification implementation-specific?
The O&M community has long jumped up and down stating that vendors
should implement a standardized configuration mechanism for their
features as soon as the features themselves are implemented.  How are
they supposed to do that if we don't provide a standardized MIB for
doing so?  It's not like it's a huge undertaking and a giant MIB to
write.  It's a single table with a few columns that are linked to the
existing notification and target tables.  We're fighting over the
linking and the architecture diagram, not whether it should be done or
not.  Where was that discussion?

I don't think in this case "SSH configuration to be out of scope" is the
appropriate stance to take.  We're not configuring all of SSH (that'd
take a lot more table).  But we do need to configure our usage of SSH
and how we're going to call it at a minimum level or else we're making
the transport useless (at least from an interoperability standpoint).

From the CG side of things, it doesn't matter as much because the CG
parameters are already implementation specific (and that's ok).  Every
app has their own dialog box, and that works because there is only a few
apps that exist and only 1-2 sets in use at a given organization.

However, there are many more implementations of agents that need to be
able to send notifications back to their management stations.  And the
need for a standardized way to configure how those notifications should
be sent is critical.  I don't consider this "SSH configuration".  I
consider it "Notification Generator" configuration.

Aside: yes, the TARGET-MIB can be used for CG configuration too and MIBs
like the DISMAN-EVENT-MIB will be equally as useless over SSH without a
standardized configuration system there as well.  I think notifications
are more important, which is why I'm harping on them.  But we'll get two
for the price of one in this case.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 May 2008 21:14:59 +0200

> the transport useless (at least from an interoperability standpoint).

My reading of the charter is such that it does not cover the remote
management and configuration of SSH itself, including things such as
defining how SSH implementations identitify keys or how to remotely
install keys to be used by SSH implementations.

Perhaps my reading of the charter is wrong, or your issue is that you
do not agree with the charter as it is written. We need to distinguish
between these two things.

> Aside: yes, the TARGET-MIB can be used for CG configuration too and
> MIBs like the DISMAN-EVENT-MIB will be equally as useless over SSH
> without a standardized configuration system there as well.  I think
> notifications are more important, which is why I'm harping on them.

We are talking about a layered system and the WG agreed before in some
other context that we treat SSH as a black box and do not try to sneak
inside. I am not trying to discourage anyone from starting work on SSH
configuration MIBs. However, right now, we do have well defined WG
deliverables that are overdue and we should focus on getting them out
before expanding the scope.

Summary: I am not saying SSH configuration should not be standardized.
I am just saying that we have to deliver what our charter calls for
first.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 May 2008 12:50:37 -0700

>>>>> On Tue, 27 May 2008 21:14:59 +0200, Juergen Schoenwaelder <[email-masked]> said:

>> the transport useless (at least from an interoperability standpoint).

JS> My reading of the charter is such that it does not cover the remote
JS> management and configuration of SSH itself

It doesn't cover or prohibit it.  Which is half the problem.  What it
defines is a set of goals (yay! that's what charters really should
define).

JS> , including things such as defining how SSH implementations
JS> identitify keys or how to remotely install keys to be used by SSH
JS> implementations.

JS> Perhaps my reading of the charter is wrong, or your issue is that you
JS> do not agree with the charter as it is written. We need to distinguish
JS> between these two things.

>> notifications are more important, which is why I'm harping on them.

JS> We are talking about a layered system and the WG agreed before in some
JS> other context that we treat SSH as a black box and do not try to sneak
JS> inside.

That's all well and good where it works.  It doesn't, it turns out, work
in a few important cases.

JS> Summary: I am not saying SSH configuration should not be standardized.
JS> I am just saying that we have to deliver what our charter calls for
JS> first.

The charter calls for six things, three of which are SSH related.  The
three that this discussion are:

  - Specify a mapping from locally-provisioned authentication and
  authorization parameter(s) to securityName and other corresponding SNMP
  parameters.

That hasn't been done within the current document for notification
systems.  The word "locally" there may be a show-stopper if you want to
read it in a literal way.

- Define how to use SSH between the two SNMP engines

The current SSH document does this.  Almost.  It defines how to use it
between CG's and CR operating engines.  It fails, in the real world,
when it comes to NGs trying to communicate with NRs.  Can you declare
victory because the engine's can "communicate" but can't trust the
communications because there is no way to perform the needed
authorization checks on the agent's side?  I'm arguing no. 

- Specify the SSH security model for SNMP.

Whoops.  We can never complete.  We aren't developing a SSH Security
Model at all.  If you want to discuss the charter literally and be sure
we meet ever word in it and do nothing else then the current draft is
entirely out of scope.  We're defining a SSH transport model not a
security model, after all.

I hope you'll agree that the point of the charter is to make it possible
to use existing SNMP operations over SSH in an interoperable way.  We
will not achieve that goal if we don't support all the existing use
cases.  This includes an interoperable way to send notifications from a
NG in a remote device to a NR housed within the management system.

Can we technically declare success?  Sure (with the above caveats)

Will it be a complete solution? no.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 May 2008 22:13:32 +0200

On Tue, May 27, 2008 at 12:50:37PM -0700, Wes Hardaker wrote:

[...]
 
> Will it be a complete solution? no.

I like to see forward progress on the current document set. I like to
see discussions converging towards concrete things that need to be
added / changed in these documents so we can put them into WG last
call. I do have some doubts that the SNMP over SSH transport mapping
document is the right place to define how SSH identifies keys or how
to configure keys to be used by SSH.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 May 2008 13:28:09 -0700

>>>>> On Tue, 27 May 2008 22:13:32 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> I like to see forward progress on the current document set.

As do we all.

JS> I like to see discussions converging towards concrete things that
JS> need to be added / changed in these documents so we can put them
JS> into WG last call.

Would that include proposals for fixing the issues I'm trying to
identify as "important"?

JS> I do have some doubts that the SNMP over SSH transport mapping
JS> document is the right place to define how SSH identifies keys or how
JS> to configure keys to be used by SSH.

It's hard to tell if you're speaking as a chair or a technical
contributor (or both).  Are you, as chair, stating that the current
solution is sufficient without notification configuration support and we
should stop discussing it?
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 May 2008 17:12:18 -0400

Hi,

comments inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Tuesday, May 27, 2008 11:56 AM
> To: [email-masked]
> Subject: Re: [Isms] ssh notifications and
draft-ietf-isms-secshell-10
> 
> >>>>> On Tue, 27 May 2008 08:25:27 +0200, Juergen 
> Schoenwaelder <[email-masked]> said:
> 

As demonstrated from our discussions, we can provide a MIB module that
is indexed by tranportDomain, transportAddress, securityNme, and
securityLevel, but then we don't know what the other columns must
contain. The current drafts say that lookup in the LCD should be
indexed by these parameters, but the actual LCD format is
implementation-specific.  

> features as soon as the features themselves are implemented.  

I am not an implementer, so I can only take the word of those who have
studied this problem. As I understand it, different SSH
implementatioins use different configuration mechanisms and different
APIs.

To specify the LCD format beyond a standardized ASI and index columns
really gets us into selecting which SSH toolkit configuration/lookup
design should be used, and we do not want to dictate implementation
choices.

> How are
> doing so?  

We have provided a standardized ASI that contains a set of
standardized columns for indexing a LCD (Local Configuration
Datastore). If you really want to provide a standardzied MIB, we can,
but it will only have the index and probably an
implementation-dependent octet string that maps to the local
configuration datastore of an implementation-dependent toolkit in an
implementation-dependent manner. And as Jeff points out, a single
"handle" may not be enough to index some configuration use cases.

Is having a MIB with a standardized index and an
implementation-dependent octet string pointer to an
implementation-dependent SSH-LCD better than saying "here are the
values to use to index the LCD, but the actual design of the LCD is
implementation-dependent"? I don't see much difference between what we
have and what that would offer.

> It's not like it's a huge undertaking and a giant MIB to

I think we already have the linkage from target and params tables, as
described in Appendix A of the Transport Security Model. The TSM
extracts the transportDomain, transportAddress, securityName, and
securityLevel from the target and params tables, and passes them to
the SSHTM via the sendMessage() ASI and the tmStateReference.

SSHTM setion 5.2 says:

      1) Determine the target index by extracting the transportDomain,
      transportAddress, securityName, and securityLevel from the
      tmStateReference.
      2) Lookup the session in the Local Configuration Datastore using
      the target index

if there is no session entry in the LCD, then SSHTM calls the
OpenSession ASI, as described in SSHTM section 5.3. Is th etext in
section 5.3 adequate to show the mapping from the transportDomain,
transportAddress, securityName, and securityLevel parameters? If not,
what more do you think is necessary?

> the transport useless (at least from an interoperability
standpoint).

Section 3.1.2 specifies required properties for interoperability.
SSHTM depends on the SSH Connection Protocol.

RFC4253 (SSH Connection Protocol) says:
"   This protocol is assumed to run on top of a secure, authenticated
   transport.  User authentication and protection against
network-level
   attacks are assumed to be provided by the underlying protocols."

RFC4251 (SSH architecture) says:
"
   One design goal has been to keep the base protocol as simple as
   possible, and to require as few algorithms as possible.  However,
all
   implementations MUST support a minimal set of algorithms to ensure
   interoperability (this does not imply that the local policy on all
   hosts would necessarily allow these algorithms).  The mandatory
   algorithms are specified in the relevant protocol documents."

RFC 4252 (SSH Authentication Protocol) says:
"   The only REQUIRED authentication 'method name' is "publickey"
   authentication.  All implementations MUST support this method;
   however, not all users need to have public keys, and most local
   policies are not likely to require public key authentication for
all
   users in the near future."

From an interoperability standpoint, we could specify a minimal
mandatory-to-implement configuration for use with SNMP that depends on
the "publickey" algorithm used with the SSH Authentication Protocol. 

The "hostbased" method name is optional in SSH, but I suppose we could
make it mandatory to implement for use with SSHTM, but using the
already mandatory-to-implement "publickey" method would seem less
burden to implementers and deployers.

Would it satisfy you to say something in the Security Considerations
about requiring "publickey" or "hostname" for interoperability?

> standardized configuration system there as well.  

I have not looked at the DISMAN-EVENT-MIB and its needs for SSH
configuration. I would think it depends on the target and params
tables, and SSHTM provides the linkage you are seeking.

> I think 
> notifications
David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 May 2008 10:54:19 +0200

> Would that include proposals for fixing the issues I'm trying to

I think it does not help to discuss such an abstract and in my view
also not very precise question.

I want to see concrete proposals how to change the document(s) and
then we can evaluate them one by one and see (a) where we have
consensus and (b) whether we can all agree this is in the scope of the
charter.

> should stop discussing it?

As chair, I am saying we should concentrate on the WG documents we
already have and try to get them finalized.

As technical contributor, I believe SSH configuration is something
that belongs into an SSH MIB module and not into an SNMP over SSH
transport mapping MIB module.

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

Hopefully this makes things clearer.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 28 May 2008 08:40:52 -0700

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

JS> I want to see concrete proposals how to change the document(s) and
JS> then we can evaluate them one by one and see (a) where we have
JS> consensus and (b) whether we can all agree this is in the scope of the
JS> charter.

That doesn't help me.  My question was:

If I come up with a technical solution that is insertable into the
document that is the form of a MIB that allows for minimal setup to
allow notifications to be sent from a NG to a NR using the
TARGET-MIB, NOTIFICATION-MIB and new objects would that be an acceptable
thing to consider?

I don't want to spend the effort to give you a concrete proposal if you
will decide later that (b) above takes precedence and even though the
proposal is sound it's now out of scope of the charter so the work was
in vein.

You are saying two things at once: 1) do work 2) the work is (possibly)
out of scope.  No one wants to do work if it's going to be declared of
out scope.

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

Making a SSH usable for SNMP is, though, and with whatever work that
might entail.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 May 2008 11:55:53 -0400

Hi Wes,

As chair of other WGs, I have had to make similar determinations. If
you write a MIB module, the WG/chairs/ADs will need to determine if it
is in scope. They will need to determine if the work is
well-constrained and achieveable, or if the work opens a tarpit that
is definiteky out of scope. Without seeing it, the chairs, WG, and ADs
cannot necessarily tell whether it would be out of scope.

If you do the work, there is no reason it could not be published. Even
if it is decided that the MIB is out of scope, you can always publish
it as an individual draft. And if the WG recharters, and work remains
to be done on the MIB, then the WG might choose to take on that work,
and the IESG might approve such a charter item.

Without seeing the proposal, I do not think a chair can determine
whether it is appropriate for the WG.

dbh

> Sent: Wednesday, May 28, 2008 11:41 AM
> To: Wes Hardaker
> Cc: [email-masked]
> 
> >>>>> On Wed, 28 May 2008 10:54:19 +0200, Juergen

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 28 May 2008 09:04:14 -0700

>>>>> On Wed, 28 May 2008 11:55:53 -0400, "David Harrington" <[email-masked]> said:

DH> Without seeing the proposal, I do not think a chair can determine
DH> whether it is appropriate for the WG.

I understand your points.  But hopefully you'll understand mine in that
if the decision has already been made (which is the question at hand)
then it'll affect the motivation of people to work on and review the
work.

DH> you can always publish it as an individual draft.

Yep.  But that means they'll be less community involvement, which may
not be a good thing.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 May 2008 12:24:22 -0400

Hi Wes,

> If I come up with a technical solution in the form of a MIB that
allows for minimal setup to
> TARGET-MIB, NOTIFICATION-MIB and new objects would that be an 

I am trying to understand what you think is missing that we need to
address.

I think notifications can be sent from an NG to an NR using the
TARGET-MIB and NOTIFICATION-MIB and an implementation-dependent SSH
LCD indirectly indexed by domain, address, name, and level. What is
Appendix A of TSM missing that is not addressed by the ASIs and
elements of procedures of the secshell document? 

What new MIB objects do you think are necessary for TSM and/or SSHTM?

Do you want an explicit MIB INDEX capturing the domain, address, name,
and level? 

Would it satisfy you if the only other column contained
implementation-dependent "index" to perform a lookup in an
implementation-dependent SSH LCD?Are you looking for a standardized
"index" into implementation-dependent SSH LCDs?

Are you looking for a mandatory-to-implement algorithm beyond what SSH
already provides?

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 28 May 2008 10:02:24 -0700

>>>>> On Wed, 28 May 2008 12:24:22 -0400, "David Harrington" <[email-masked]> said:

DH> I think notifications can be sent from an NG to an NR using the
DH> TARGET-MIB and NOTIFICATION-MIB and an implementation-dependent SSH
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
DH> LCD indirectly indexed by domain, address, name, and level.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What does the NG use for a SecurityName as an input to the VACM for
authorization purposes?

What user credentials are used on the NG as a client to open the SSH session?
(I suspect this is what you mean by the ^^^ mapping section above)

Can those two questions be answered in an interoperable way via
interoperable configuration knobs?  If the answer to this is "it can be
done only via implementation-dependent methods" then I think that's a
failure case.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 May 2008 14:32:23 -0400

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, May 28, 2008 1:02 PM
> To: David Harrington
> Cc: 'Wes Hardaker'; [email-masked]
> implementation-dependent SSH

It uses the securityName specified in snmpTargetParamsSecurityName.

> (I suspect this is what you mean by the ^^^ mapping section above)

It uses the credentials it gets from the SSH local configuration
datastore. this might be a key stored in the ssh_keys directory, for
example. How it finds the right credentials is implementation-specific
because different SSH implementations might store the creentials in
different locations or in different formats.

In SSHTM, there is an LCD indexed by domain, address, securityname,
securitylevel that indicates how to get the appropriate set of SSH
credentials. This must be implementation-dependent because we do not
know which SSH implementation is going to be used.

> interoperable configuration knobs?  

The first question is "yes, absolutely"; the TargetParamsTable is a
configuration database for the NG application, and it provides the
securityModel, securityname and securitylevel to be used when the NG
is performing access control. The TargetTable is also part of the
configuration database for the NG application, and it provides the
transportDomain and transportAddress to be used. 

> If the answer to this is 
> "it can be

We have standardized the index (transportDomain, transportAddress,
securityName, and securityLevel) to lookup the corresponding
implementation-dependent SSH credentials to open the SSH session.

For comparison, look at the usmUsertable. The authKey - the credential
that is actually used by the authentication protocol such as
HMAC-MD5-96 - is not visible via SNMP:
"   authKey
      If messages sent on behalf of this user can be authenticated,
the
      (private) authentication key for use with the authentication
      protocol.  Note that a user's authentication key will normally
be
      different at different authoritative SNMP engines.  The authKey
is
      not accessible via SNMP.  The length requirements of the authKey
      are defined by the authProtocol in use."
The mapping from the usmSecurityName (or the identical usmUserName) to
the (for example, HMAC-MD5-96) authkey is implementation-dependent.

We only need a similar implementation-dependent mapping. 

We do not need all the other stuff provided in the usmUsertable - we
know the transportDomain and transportAddress so we don't need
engineID in the INDEX; we are using the identity transform between SSH
user name and SNMP securityName; we know that SSH is our auth and priv
protocol (and which auth and priv mechanisms SSH is configured to use
to perform auth and priv for the user name is not our business); and
we are not handling SSH key changes via SNMP.

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 28 May 2008 12:34:42 -0700

>>>>> On Wed, 28 May 2008 14:32:23 -0400, "David Harrington" <[email-masked]> said:

>> What does the NG use for a SecurityName as an input to the VACM for

DH> It uses the securityName specified in snmpTargetParamsSecurityName.

(this is actually different than I last remember reading; but that's
fine with me...  I thought that was still up for debate, but there is a
thread I haven't finished reading so I'm sure it must be in there).

>> What user credentials are used on the NG as a client to open the SSH

DH> It uses the credentials it gets from the SSH local configuration
DH> datastore.

I assume this also includes the acceptable server-side credentials (eg,
host certificate) that is expected on the other end?

DH> We have standardized the index (transportDomain, transportAddress,
DH> securityName, and securityLevel) to lookup the corresponding
DH> implementation-dependent SSH credentials to open the SSH session.

Ok, just to be sure.  In order for me to set up 10k boxes to send
notifications to a notification receiver or two I need to first
configure through an out-of-band mechanism the user's credentials and
the server's expected credentials (host certificate) that the
notification receiver must present?  Right?  And if I need to add
another notification receiver I need to manually out-of-band reconfigure
all 10k nodes right?  Or if I change the NR certificate (say on a
regular basis of every year) then I need to manually out-of-band
reconfigure the device?  In a implementation-dependent way.

If that's acceptable to you, then the conversation is probably at a
stand still.

DH> For comparison, look at the usmUsertable.

The usmUserTable requires a single bootstap, not endless.  That's a huge
difference.  And, with SSH the bootstrap is actually possibly handled by
prior management station credentials (ssh users already set up for
coming into an ssh agent).  But devices today like don't have outgoing
ssh credentials in place.  That mapping you're referring to into the LCD
doesn't exist today and thus must be manually configured for
notifications to be usable.  I'm not saying it can't be done.  It can
be.  Painfully and in a non-interoperable way.  Once that's in place,
yes notifications can be sent in an interoperable way.

I really do understand the reasons behind wanting to shelve this and
saying "we're not going to do configuration at that level of detail".
But it will affect scalability of the results.

DH> The authKey - the credential that is actually used by the
DH> authentication protocol such as HMAC-MD5-96 - is not visible via
DH> SNMP

But it can be changed and uploaded.  I don't care about reading it as
much as I do writing it.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 May 2008 17:04:30 -0400

> thread I haven't finished reading so I'm sure it must be in there).

See Transport Security Model Appendix A.

> 
> >> What user credentials are used on the NG as a client to 
> open the SSH
> >> session?
> 

If SNMP agents are going to become SSH clients, they will need the
credentials typically needed by an SSH client, which I also assume
includes knowledge of acceptable server-side credentials. 

I believe you are correct that most devices containing SNMP agents do
not also support SSH clients, so adding SSH client support to SNMP
agents will certainly be a significant change.

Because a typical network may contain many workstations or other
devices that do contain SSH clients, I would expect that operations
staff have already addressed the scalability of configuring multiple
SSH clients, and they probably address the scalability issue of
heterogeneous SSH implementation support. If they currently use CLI
scripts to configure SSH clients on workstations, that solution could
probably also be used to configure the devices that now will need SSH
clients for sending SNMP notifications.

I don't consider having a myriad of non-standardized configurations or
management functionality a good thing. If I did, I probably would not
have spent 16 years doing IETF NM work. As a network management
standards engineer, I will confess to be less than impressed by the
standardized manageability of the IETF security protocols. I think the
SecSH WG should have been required to produce a MIB module for
management, just as most other WGs were required to do for their
protocols. But somehow, the message that security protocols need to be
manageable got lost in the IETF.

If operators realy care about the scalability problems associated with
configuring and managing SSH, they would push the vendors and the IETF
to produce standardized solutions. However, that problem is not one
assigned to this WG to resolve.

> notification receiver must present?  Right?  

I understand the desire for standardized configuration. However, the
operartors were very clear that they want to reuse their existing
solutions rather than have the SNMP community develop new solutions
for user and key management.

from the charter:
"The Simple Network Management Protocol version 3 (SNMPv3) provides
message security services through the security subsystem, for which
there is one currently defined model - the User-based Security Model
(USM). However, the USM approach has seen limited deployment so far.
One frequently reported reasons is the lack of integration of USM
key and user management into deployed authentication infrastructures.

SSH is a widely deployed access protocol for remote devices
configuration. Many devices support the integration of SSH user
authentication with AAA systems via protocols such as RADIUS.

The goal of the ISMS working group is developing a new security model
for SNMP that integrates with widely deployed user and key management
systems, as a supplement to the USM security model."

Hopefully the work we do integrating with AAA will help to minimize
the scalability issues of user management, and the existing key
management and configuration mechanisms for SSH will resolve the key
distribution problem.

> And if I need to add
> another notification receiver I need to manually out-of-band 

You would need to reconfigure out-of-band, but you might have an
automated out-of-band reconfiguration capability, such as CLI scripts
or Netconf data models.

> reconfigure

The good news is that this implementation-dependent way is consistent
with configuring syslog notifications as well. of course, the bad news
is that syslog chose to use TLS instead of SSH, and netconf chose a
completely different approach to notifications).

> If that's acceptable to you, then the conversation is probably at a

The real question is whether it is acceptable to operators. I suggest
we ask the OPS directorate for their thoughts on this.

> The usmUserTable requires a single bootstap, not endless.  

I'm sorry, I don't buy this argument. Both the usmUsertable and an SSH
table for notifications may need constant reconfiguration. I expect
that, absent AAA, the usmUserTable needs to be reconfigured for
frequent user adds/modifies/deletes, which will probably happen much
more frequently then SSH server certificate changes. And I do not
expect that operators change the logging aggregators in their networks
very often.

Given a choice between existing widely-deployed key distribution
mechanism and an SNMP-specific one, operators have already told us
they don't really want the SNMP-specific key change mechansism. It is
just extra overhead.

In addition, the SNMP key change mechanisms has some scalability
problems of its own, especially in light of SNMP implementations such
as command-line tools and other SNMP entities that are not
"always-on". It can difficult to synchronize all the players in a
network management system on a timely basis, and that work is better
left to existing widely-deployed key distribution systems.

> That's a huge

I think we might be better to expect that at some point in the future,
SSH configuration should be standardized, as should syslog, and TLS
and other non-standardzied management functionality for security
protocols. I think Netconf might be a better protocol than SNMP for
standardizing configuration of SSH. I would be happy to add an
Operability and Manageability section to the ISMS documents to include
discussion of scalable configuration, management, and key distribution
for notifications.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 May 2008 09:51:32 -0400

Hi Wes,

Eliot chose to restrict this discussion because he thought it was
water under the bridge. I don't know what issue he thinks is water
under the bridge. So I'm going back to the WG with the discussion.

I have asked repeatedly for proposed changes to text in the current
documents. Two of the reasons I keep asking for this is because 1) I
think we may be talking past each other, and 2) I want to be sure I
understand what you think the issue is.

I cannot edit the documents to represent your proposed changes because
I am not sure what you think needs to be changed. I am not resisting
the changes you want; I just don't know what changes you want.

Maybe I'm just thick. Can you please provide a fairly simple
explanation of what you think the problem is, and explain how the
current drafts do not address the problem, but should? (and PLEASE
read TSM appendix A before replying.) Don't just tell me that the
documents don't address your problem and you're tired of standing on
your head; tell me ***how*** they should address the problem.

Maybe then I will have a better understanding of what you are trying
to fix, and can edit the documents to address your concerns. I may
still be too thick to do that editing; If you can provide proposed
text and tell me where in the documents that text should be put, and
the WG agrees, I'll be happy to put them in.

dbh

> Sent: Friday, May 30, 2008 9:10 AM
> To: Eliot Lear
> Cc: David Harrington; 'Wes Hardaker'
> 
> >>>>> On Fri, 30 May 2008 13:07:53 +0200, Eliot Lear 
> <[email-masked]> said:
> 
> EL> I'm reducing because  my understanding is that this is 
> supposed to be
> EL> water under the bridge, and as such perhaps we should 
> move on.  I say
> EL> this as the guy who stood on his head on this issue some time
ago.
> 
> Yeah...  I realize that I think I'm the only one left on my head.
> 
> EL> Right.  That's not the problem.  But securing host keys 
> is a problem
> EL> because that's not in radius.  It's a one time issue so 
> long as you do
> EL> not rekey the server.
> 
> Or add a new trap receiver (or heck, even change it's address).  Or
> rekey the hosts.
> 
> EL> I do think it would help if there was another example 
> that used TSM,
> EL> like TLS.
> 
> I actually have a DTLS based TSM draft that I'll be publishing
before
> Dublin...  But it won't be considered till the SSH draft is
finished.
> (and that lets you know how much I think the scalability of 
> the current
> draft should be dealt with; trying to fix this means delaying the
SSH
> draft during the conversation and that slows down my own 
> attempt to get
> another draft in the door...  But I still think it's the 
> right thing to do)
> -- 
> Wes Hardaker
> Sparta, Inc.
>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 May 2008 10:09:24 -0400

Hi Wes and Eliot,

I'm bringing this to the list. The chair can tell us to take the
discussion off this list if the issue has already been settled. 

comments inline.

ago.
> EL> Right.  That's not the problem.  

I was quoting a three paragraph section of the charter. I was not
suggesting that this paragraph addressed the problem, only pointing
out what operators had asked for.

> EL> But securing host keys 
> is a problem

I think it is fair to characterize SSH host key distribution as a
one-time issue 90% of the time, but we also need to recognize that
there is another 10%. 

I am not sure that securing SSH host keys is a problem to be addressed
by this WG. I think host keys are already found in existing
infrastructure, and they are secured using implementation- and/or
deployment-specific ways. I think those same solutions should be used
here, when possible. 

Where not possible, the problem needs to be recognized and addressed,
but I think securing host keys is an SSH infrastructure issue, not an
ISMS issue.

We **are** proposing that the infrastrucure be deployed differently
than it is currently deployed, and I absolutely think we should at
least discuss this in the Security Considerations. 

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 30 May 2008 07:07:46 -0700

>>>>> On Fri, 30 May 2008 09:51:32 -0400, "David Harrington" <[email-masked]> said:

DH> I cannot edit the documents to represent your proposed changes because
DH> I am not sure what you think needs to be changed. I am not resisting
DH> the changes you want; I just don't know what changes you want.

I believe that I may be standing alone here (and I do think everyone now
understands what I was concerned about including you, since you wrote a
note to the ops-area list and the contents showed you understood what I
wished would be standardized).

So...  because of the fact I'm potentially alone here and because a few
responses on the ops-area list have backed up the opinions here that a
full interoperable configuration method may not be needed I think there
is consensus that the additional parts to the document shouldn't be written.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 May 2008 10:26:18 -0400

Hi, 

If the issue you are raising is the lack of a standardized mapping
table from a mechanism-specific identity to a securityName, then that
issue has already been identified in secshell-10 as Issue#2 in the
Open Issues list.

If the issue you are raising is the lack of a standardized mapping
table to a mechanism-specific identity from a securityName, then that
issue has already been identified in secshell-10 as Issue#3 in the
Open Issues list.

I think your discussion of the problem has been somewhat different
than Issue#2 and Issue#3, but I'm not sure because you have not
discussed them under these issue#s. You seem to be wandering into
other areas of concern, and I cannot tell whether you are raising new
Open Issues or not.

If you agree these are the issues you want to raise, then please use
these Issue#s in your subject lines, so we can keep the issues
properly separated.

I have added a new Issue#9 to discuss securing SSH host keys, since
that came up in the discussion and seems to be a different issue.

dbh

> Sent: Friday, May 30, 2008 10:08 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] Issue # ???
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 May 2008 16:39:53 +0200

Hi Dave,

FWIW the reason I didn't bring this stuff to the list was that I believe 
it went to the core of the decision to use SSH.  That is the water under 

> one-time issue 90% of the time, but we also need to recognize that

I think these numbers are as good as any, and would accept them for 
purposes of discussion.
> deployment-specific ways. I think those same solutions should be used

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.  If you think we need specific text for that, I'd be happy to 
give it a swag as a starting point, but it strikes me that Jeff is The 
Man for this one.

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.

Please do not take this text as an objection to the current draft.

Regards,

Eliot

---

From: "David Harrington" <[email-masked]>
Date: Fri, 30 May 2008 12:08:01 -0400

Hi,

I think the discussion that has been carried on recently demonstrates
that the lack of any **standardized mapping table** in the
specification makes it hard to understand the specification and how to
apply it to notifications. If the people in this discussion are having
trouble understanding what has to be specified where in the system,
and how they relate, then implementers and users will have a very hard
time.

I recognize that credentials should not be stored in a MIB, and that
the internal SSH mechanisms used to perform suthentication should not
be exposed, since that might be a layer violation.

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.

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

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.

dbh