Subject: [Isms] RE: Call for consensus

From: "Nelson, David" <[email-masked]>
Date: Tue, 16 Aug 2005 14:31:45 -0400

Tom Petch writes...

> I struggle with the way you do this.  You ask for those who disagree
> with 1. The ISMS WG will work on one transport protocol only
> to speak up so the list will contain only or mostly contrary views.  
> How then do you judge rough consensus on this if those in favour have 
> not spoken?

Asking for dissent is one valid method of sensing rough consensus. If
only a few object, then it is very likely to be rough consensus in
favor.

OTOH, if you believe that the majority is undecided, has no strong
opinion, or primarily consists of "lurkers" on the list, then a poll of
the "yeas" and "nays" may be required.

> (I am in favour)

FWIW, so am I.

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Aug 2005 22:08:28 +0200

For those who are in favor, it seems only fair that you answer the
following questions:

 - why is it reasonable for ISMS diverge from the method that
   NETCONF has specified for "call home" functionality?

 - what should be done to resolve the differences?

 - If you claim NETCONF should change, explain how that should be
   accomplished.

For demographic purposes, could you identify yourself as a vendor (and
one that will code) or an operator (one that will use the code)?

Eliot

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Aug 2005 00:19:45 +0200

Nelson,

> the "yeas" and "nays" may be required.

The session showed a clear majority agreeing.  I do not see why we should
ask all of them to send a message to the list.

Thanks,

    Juergen

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 17 Aug 2005 08:14:51 -0400

Hi Eliot and ISMS folks,

I've been trying to come up-to-speed on what is happening in this 
group, so I thought I'd jump in here.  Please let me know if I am 
misunderstanding something or hashing over something that has been 
well-hashed in the past...

>    NETCONF has specified for "call home" functionality?

I understand that there is a benefit (code re-use and unified 
security configuration) to using a shared "transport protocol" (to 
use that term loosely), such as SSH for both SNMP (through ISMS) and 
NETCONF.  But, I am not sure that it is important that SNMP and 
NETCONF use SSH in exactly the same way, because they don't have 
exactly the same properties.

I'm not really sure what you mean when you discuss "call home" 
functionality WRT SNMP...

SNMP has a well established paradigm where the manager sends SNMP 
query PDUs to the agent, perhaps polling for information as 
necessary, and the agent sends response PDUs only in response to 
queries.  If a managed device needs to send information to a manager 
asynchronously, this is done via notification PDUs or traps that are 
sent from a notification sender to a notification receiver.  In other 
words, SNMP is not a symmetric peer-to-peer protocol.

If you are talking about the situation where a new device comes 
on-line and, essentially, requests to be configured, monitored or 
managed via SNMP, I would _think_ that the best way to accomplish 
that within the SNMP paradigm would be for the new device to send a 
notification to a notification receiver running on the same system as 
the SNMP manager, and for the manager to start sending SNMP queries 
(for monitoring, provisioning, etc.) to the new device as a result of 
that notification.

If that is the type of exchange that you are trying to support, I 
think that the simplest way to support that would be to have two 
different types of SSH subsystem for SNMP, an "SNMP-agent" subsystem 
that is invoked on the agent by the manager, and an 
"SNMP-notification-receiver" subsystem that is invoked on the 
notification receiver by the notification sender.  The new device 
would establish an SSH session with a notification receiver to send 
the notification, and the manager would then establish an SSH session 
with the agent to send queries and receive responses.  I don't 
understand why this would require any special "call home" 
functionality, and I don't seen any reason why this would be 
difficult from an SSH perspective.

Or are you suggesting that this would all need to happen using a 
single SSH connection?  If so, I could see how that might be 
problematic, as I don't know that it is possible for a single SSH 
connection to be used first to invoke a subsystem on one end of the 
connection and later to invoke a subsystem on the other end -- I'd 
have to ask more SSH-knowledgable folks if that is even possible.  I 
also have trouble picturing how that would be consistent with the 
SNMP architecture and paradigms, since the manager/agent and 
notification sender/receiver are independent architectural entities...

Either way that you try to handle this, I think that there are a 
number of other complexities with this model, such as:  How would the 
new device get information about what notification receiver/manager 
to contact?  And, how would the new device get it's initial SNMP 
security configuration?

Could you explain what you are trying to do here?  Are there cases 
where the simpler scenario I've described above (new device sends 
notification, manager starts sending queries as a result of the 
notification) wouldn't work in situations where the more complex 
single-connection "call home" model would?  Perhaps if a NAT is 
involved?

>one that will code) or an operator (one that will use the code)?

I am a vendor of devices that are monitored via SNMP and that may be 
configured (at some point in the future) using NETCONF.

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Aug 2005 10:17:55 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:
    Margaret> Or are you suggesting that this would all need to happen
    Margaret> using a single SSH connection?  If so, I could see how
    Margaret> that might be problematic, as I don't know that it is
    Margaret> possible for a single SSH connection to be used first to
    Margaret> invoke a subsystem on one end of the connection and
    Margaret> later to invoke a subsystem on the other end -- I'd have
    Margaret> to ask more SSH-knowledgable folks if that is even
    Margaret> possible.  I also have trouble picturing how that would
    Margaret> be consistent with the SNMP architecture and paradigms,
    Margaret> since the manager/agent and notification sender/receiver
    Margaret> are independent architectural entities...

It cannot.  However you could set things up so that no matter which
side invokes the snmp subsystem, packets are allowed to flow in both
directions.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Aug 2005 10:21:50 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> For those who are in favor, it seems only fair that you
    Eliot> answer the following questions:

    Eliot>  - why is it reasonable for ISMS diverge from the method
    Eliot> that NETCONF has specified for "call home" functionality?

Our charter does not require us to align with netconf.  You can try
and convince people this is a desirable goal and to the extent you are
successful they will consider it in evaluating solutions.  However so
far I have not seen anything in the charter that requires us to align
with netconf nor have I seen a consensus declared that this is a
strong requirement for evaluating solutions.

Similarly, I don't see a requirement in our charter for call home
functionality.  Again, you can argue for such a requirement but so far
I have not seen a consensus that the group agrees there is such a
requirement.

--Sam

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 17 Aug 2005 11:26:18 -0400

Hi Sam,

>side invokes the snmp subsystem, packets are allowed to flow in both

SNMP communication is bi-directional, but it is not symmetrical, and 
I'm not sure that we can or should change that under the auspices of 
defining a new, better integrated security mechanism for SNMP.

As far as I can tell, the "call home" features is concerned with 
which side(s) can take the _initiative_ to establish an SNMP 
communication session.

I'd argue that having an SNMP agent (AKA the architectural element 
that response to queries) _decide_ (based on configuration, or 
whatever) that it wants to be managed (monitored, configured, etc.) 
by a particular manager (AKA an architectural element that sends 
queries) and then having that agent establish a connection to that 
manager for the purpose of being managed is a pretty big departure 
from the current SNMP model.  Today, the manager is active, and the 
agent is completely reactive.  If an a device needs to send 
information asynchronously to a management system, that is done by 
the notification sender on the device sending a notify or a trap.

It is my hope that ISMS will produce something that can be 
retro-fitted into existing SNMP implementations by changing the 
underlying transport layer and perhaps adding a few hooks into the 
existing SNMP agent for access control.

If that isn't the goal, and we're willing to revisit basic properties 
of SNMP, perhaps we should get rid of that pesky ASN.1 BER encoding 
while we are at it!  :-)  (<==  Note for the humour impaired:  this 
is a joke.  Please do not respond as if it were a serious suggestion.)

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Aug 2005 11:34:21 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> Hi Sam,

    Margaret> At 10:17 AM -0400 8/17/05, Sam Hartman wrote:
    >> It cannot.  However you could set things up so that no matter
    >> which side invokes the snmp subsystem, packets are allowed to
    >> flow in both directions.

    Margaret> SNMP communication is bi-directional, but it is not
    Margaret> symmetrical, and I'm not sure that we can or should
    Margaret> change that under the auspices of defining a new, better
    Margaret> integrated security mechanism for SNMP.

Is it asymmetric at the level that we're talking about though--at the
PDU transport level?

I do think the simplest level to do call home is to make the channel
bidirectional.  I do agree with you though that it is unclear what
call home would mean in an SNMP context and that we should convince
ourselves that we want call home and know what it means before
specifying it.

--Sam

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 17 Aug 2005 12:14:04 -0400

Hi,

Architecturally, a "call home" functionality would likely impact
multiple subsystems within the RFC3411 architecture - the transport
mapping (implied subsystem), the security subsystem, and the
application subsystem (RFC3413).

I agree with Sam that we should understand how we want to utilize this
functionality in SNMP before spending resources to developing it. So
far, I haven't seen a strong case that we need this, only an argument
that BEEP supports this, so we should want it to justify adopting
BEEP.

If the goal is to address NAT/firewall issues, that seems to me to be
an issue to be resolved at the transport layer, or within NAT/firewall
standards rather than within SNMP. SNMP already has its own solution
for this problem - the proxy application defined in RFC3413 allows an
SNMPv3 proxy entity to be co-resident with NAT/firewall functionality
and can establish two SSH trusted tunnels, one to the entity outside
the firewall, and one to the entity inside the firewall (or in the
public vs private addressing space). 

RFC2962 has a discussion of application-level gateways and proxies and
special considerations related to SNMP. If we choose to address issues
of NAT, that should certainly be included in the discussion.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Wednesday, August 17, 2005 11:34 AM
> To: Margaret Wasserman
> Cc: [email-masked]
> Subject: Re: [Isms] RE: Call for consensus
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Aug 2005 12:14:25 -0700

Hi -

> From: "Margaret Wasserman" <[email-masked]>
> To: "Sam Hartman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 17, 2005 8:26 AM
...
> which side(s) can take the _initiative_ to establish an SNMP
...

Let's take a concrete example:  A managed device comes up,
has persistant entries in RFC 3413's SNMP-TARGET-MIB,
SNMP-NOTIFICATION-MIB, and appropriate VACM entries.
Something happens that results in notifications needing to be
sent.  How do they get delivered, if our transport mechanism
requires a session of some kind to be in place?  Obviously
the "agent" needs to be able to establish the session, rather
than waiting for some management system to get around to
contacting it, particularly since there's no guarantee that the
configured notification targets will *ever* call the device themselves.

Sure one can get into arguing about whether fancier things may
or may not be needed, but this is rather rock-bottom functionality
that I think is hard to argue with.

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 17 Aug 2005 21:30:04 -0700 (PDT)

HI,

The model that SNMPv3/USM uses for delivering notifications 
(with are traps and informs), is that the notification
delivery system as defined in RFC 3413 is configured
for identities at transport address targets. There may
be multiple identities at each transport address, and
if so, a notification may be sent to each one. On the
notification receiver side, each SNMPv3/USM message
is verified with the credentials of the identity
specified in the notification SNMP message.

When a session approach is used, if a session is created
by a notification originator (the client) to a notification
receiver (the server) and mutul authentication is to be done,
then which identifies should be used by the client and
manager. For me, the "natural" identities are the
managed system for the client, and a user for the
server. However, to do this, then on session creation,
the client must tell the server what ID to use,
since the server can support many identities.
(Or at least, that is the model today, and it
"lines up" with the identities used when the
session is created by a "command generator".

So, from a "security purity" standpoint, what options
are there? I can see:
 1) yes, it is Ok for the client to tell the server
    the identity that the server should use.
 2) no, this is not OK. There can be only one
    identity used per transport address
 3) some other approach

Regards,
/david t. perkins

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Aug 2005 08:31:04 +0200

Margaret,

Margaret Wasserman wrote:
> As far as I can tell, the "call home" features is concerned with which
> side(s) can take the _initiative_ to establish an SNMP communication
> session.

Precisely, but see my earlier email.

> 
> I'd argue that having an SNMP agent (AKA the architectural element that
> response to queries) _decide_ (based on configuration, or whatever) that
> it wants to be managed (monitored, configured, etc.) by a particular
> manager (AKA an architectural element that sends queries) and then
> having that agent establish a connection to that manager for the purpose
> of being managed is a pretty big departure from the current SNMP model.

Then today's model fails a large component of the market - those
elements that must be managed through non-aware firewalls and NATs.
It's a reflection of the changing reality that we should acknowledge.

> Today, the manager is active, and the agent is completely reactive.  If
> an a device needs to send information asynchronously to a management
> system, that is done by the notification sender on the device sending a
> notify or a trap.

Actually, today for a given group of elements there is NO standard
management because communication is impossible.

Again, nobody proposes that call-home be the primary form contact
method.  There are all those OTHER devices that work just as you
describe ;-)

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Aug 2005 08:48:02 +0200

Dave, Margaret, all,

There is NO substantial difference between using SSH to connect in one
direction versus using SSH to connect in the other.  The ONLY difference
is in the form of authentication available, as I understand it, and even
THAT is subject to change, thanks to modularity.  We must solve every
problem that has been raised regarding mapping regardless of which way
the connection starts.  This includes notifications.

Eliot

David B Harrington wrote:
>>>>>>>"Margaret" == Margaret Wasserman 
>>
>><[email-masked]> writes:
>>
>>    Margaret> Hi Sam,
>>
>>    Margaret> change that under the auspices of defining a new,
> 
> better
> 
>>Is it asymmetric at the level that we're talking about though--at
> 
> the
> 
>>PDU transport level?
>>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 18 Aug 2005 14:43:42 -0400

Hi Eliot,

>It's a reflection of the changing reality that we should acknowledge.

I think that this is a question of scope...

I thought it was the purpose of this WG to specify an integrated 
security model for SNMP as it exists today.  Today, an SNMP agent 
does not have a concept of initiating communication to a manager in 
order to be managed by that manager.

You seem to be suggesting a fairly substantial extension to the SNMP 
model, and I personally don't see that as in-scope for this (security 
area) effort.

It is possible, if we decide that notifications should be secured 
using ISMS as well as queries/responses (has that been determined?), 
that devices (acting as notification senders) may end-up initiating 
SSH sessions to notification receivers.

I would personally find it more intuitive and more consistent with 
the SNMP model if the notification subsystem was distinct from the 
query/response subsystem, rather than considering a model where a 
device might send a notification to a manger that would then turn 
around and use that same SSH connection to issue queries to the 
device.  Perhaps you think otherwise, though?

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Thu, 18 Aug 2005 15:21:59 -0400

I'm sort of uncomfortable with this question.  The identities used
depend on the authentication mechanisms in use.  For example ssh
public keys have names nothing like Kerberos principals.

Some credential types distinguish users and servers; some do not.

The general answer to your question is that yes, from a security
standpoint it is reasonable for a client to tell a server what
identity the client wishes the server to use.

However not all security mechanisms work that way.  In particular,
ssh' existing key exchange mechanisms do  not work that way, nor do
all SASL mechanisms.

Also, ssh is more complicated because of how userauth works.  A user
does not actually present user credentials to an ssh server.  Instead
a user presents credentials (which may be user credentials depending
on the authentication mechanism) along with a username.  The ssh
server authenticates the party on the other end of the transport
against these credentials and then makes an authorization decision
about whether those credentials are allowed to request service as the
given user.  So, in a given ssh session, regardless of whether the
authentication method typically distinguishes user and server
credentials, there is always a user name that the client has chosen
(and been authorized) to act as.

In summary, for ssh, the following  identities are involved:

* identity associated with key exchange credential used to
  authenticate server to client.  Typically this is a credential type
  and type-specific identity.    Examples include  ssh DSA public keys, ssh RSA public keys, GSSAPI names.

* An identity that the client requested service as; this is a text user name, a NAI,  or some more obscure possibilities typically not used in practice.

* Zero or more sets of userauth method-specific identities
  corresponding to credentials used in requesting service as the given
  username.  Examples include ssh RSA public keys, SSH DSA public
  keys, GSSAPI names.  Passwords and challenge response interactions
  also fall into this category although it is not clear they have
  associated identities so much as raw associated credentials.

In terms of configuration, here is what seems natural from an ssh standpoint:

* Configure user name to request service as and credentials to present
   for  command generators.

* Configure transport target and as an implementation matter either
  use existing ssh mechanisms for confirming that the transport target
  is mutually authenticated (known hosts file, Kerberos) or store
  authentication method specific credentials that are expected to be
  used.  You will get much greater interoperability in the cases where
  you can use the ssh mechanisms but that will not work for some
  environments.

* Configure authorization based on username for command responders;
  leave what credentials are allowed to request service as that user
  to ssh.

* Configure username to request service as when sending notifications
  and credentials to present for notification senders.

* Configure transport target for notification senders; authentication
  handled the same as command generators. 

* Notification receivers need to authorize and route/handle
  notifications based on the username service is requested as.

Downsides of this approach:

* The command generator and notification sender don't really know what
  credential or low level identity  is used for mutual authentication.

* There is an asymmetry in the authentication.

* Command generators and notification senders may not actually know
  what access rights they have on the remote system, particularly if
  SecurityGroup mapping happens.  LDAP and IMAP provide solutions to
  this by defining a new operation that lets you know what identity
  you end up having and what rights you have.

--Sam

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Aug 2005 15:27:59 +0200

Margaret,

Let me defer a response to you on the matter of scope.  However...

> It is possible, if we decide that notifications should be secured using
> ISMS as well as queries/responses (has that been determined?), that
> devices (acting as notification senders) may end-up initiating SSH
> sessions to notification receivers.

We have demonstrable proof in the form of FTP that having one connection
 in one direction and another connection in another is a serious
mistake, thanks again to firewalls and NATs.  We have them, let's please
not stick our heads in the sand (again).  Let connection directionality
flow in a single direction - the one that works (whatever that might be).

> 
> I would personally find it more intuitive and more consistent with the
> SNMP model if the notification subsystem was distinct from the
> query/response subsystem, rather than considering a model where a device
> might send a notification to a manger that would then turn around and
> use that same SSH connection to issue queries to the device.  Perhaps
> you think otherwise, though?

I'm somewhat open to a number of possibilities here:

 - multiple connections within the SSH transport connection
 - multiple SSH connections
 - a hybrid where one opportunistically is able to use an existing
   SSH transport

I think more highly of the 3rd, could settle for the 2nd, and would not
cry if we ended up with the first.

Eliot

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 19 Aug 2005 11:26:27 -0400

Hi Eliot,

>Let me defer a response to you on the matter of scope.  However...

I'm not sure that you can really defer the question of scope, because 
that is the whole point:  What is the purpose (scope) of this 
particular WG effort?

There are SNMP "customers" who are using SNMP today (and therefore, 
by definition, can initiate communication from their management 
stations to their devices) who have not migrated from SNMPv1/v2 to 
SNMPv3, because of the cost/complexity (real or perceived) of 
deploying SNMPv3 security.  That is the problem that I think we are 
trying to solve in this working group, by integrating SNMP security 
with existing, widely deployed security infrastructure, such as 
RADIUS.

You have spoken about another, separate problem:  That devices behind 
NATs can't always be addressed or reached from the outside, making 
SNMP (as it exists today) a poor solution to manage those devices. 
FWIW, I agree with you that this problem exists, but it is certainly 
not specific to SNMP.  Furthermore, fixing this problem using the 
concept that you have described would require major changes to the 
SNMP operational model, and I don't think that this particular 
(Security area) WG is (or should be) chartered to do that work.

If you believe that your "call home" concept is a viable solution to 
the SNMP-through-a-NAT problem, and if you can point to a large set 
of "customers" who are likely to adopt SNMP if this problem is 
solved, then I think that you should write a draft and work with Bert 
to get an SNMP "call home" effort started in the OPS area.  I might 
even poke my head in from time-to-time...

Margaret