Subject: Re: [Isms] open issues

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Apr 2008 23:21:03 +0200

On Mon, Mar 31, 2008 at 02:00:09PM -0400, David B Harrington wrote:
 
> #2 could be resolved by allowing an operator to preconfigure a MIB
> like usmUserTable to provide the mapping from various
> mechanism-specific identities to securityName. Such preconfiguration
> could use the identity function to set secruityName if no mapping is
> provided. Or, they could preconfigure in an implementation-dependent
> manner. Without preconfiguration, and using a default identity
> function, an operator would need a VACM entry for each
> mechanism-specific identity.

Jeffrey Hutzelman clarified in January that SSH always provides you
with an authenticated user name, regardless which SSH authentication
mechanism is used. So it seems we do not need a mapping mechanism, at
least not for the sake of hiding details for different authentication
mechanisms. Can you go back to Jeff's message and see wether that
changes your mind? Or alternatively, can you explain why such a
mapping is still needed (in the simple case #2)?

> #3 (same as #2; opposite direction. Not sure if there are any
> additional complications in this direction.

This case is less well understood so I am not sure if in the opposite
direction a mapping would make things simpler.

> #5 and #8 can be resolved by having securityModel in tmStateRef
> override message processing selection of model. But we would need to
> discuss security considerations for doing so, and check whether there
> are any unforeseen implications (much as doing it the current way had
> implications with RFC3584). If we do this, then #2 and #3
> preconfiguration might become specific to each transport mapping, or
> share a common table.

I am not sure we want this "global override". While doing this override
for SNMPv1/SNMPv2c might make sense, I believe it is a feature to be
able to replace the TSM in case we figure out something better is
needed. I like the flexibility the current architecture allows. While
SNMPv3/USM/SSH may not make much sense, I consider it a feature that
it would actually work and who knows whether we ever need
SNMPv3/XXX/SSH.

An update of RFC3584 seems to be out of scope for this WG. I suggest
that people interested in updating RFC3584 work out the details on an
individual draft and then we can ask ADs for advice where such work
could fit in (e.g. the OPSAWG) and see whether there is support for
such work. We have to focus on making SNMPv3 run over SSH.
 
> #6 is about whether the access controls applied are for the same
> authenticated identity (client vs server) as in USM. I think this
> needs further research of who must be authenticated for each operation
> type, and whether the security rules about which identity must be
> authenticated when using an operation are consistent with SSH and USM
> and the architecture.

How can we make progress on this? Would a conference call help? We
have gone through this before; perhaps we need to revisit the options
we have and come up with pro/con criterias to select one.

/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: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 11 Apr 2008 17:56:53 -0400

--On Friday, April 11, 2008 11:21:03 PM +0200 Juergen Schoenwaelder 
<[email-masked]> wrote:

>> # 5 and #8 can be resolved by having securityModel in tmStateRef

I agree.  I don't see a major problem with allowing securityModel in 
tmStateRef to control when the MPM does not provide a way of carrying 
securityModel, as is the case with SNMPv1/SNMPv2c, but if the MPM does 
provide have that capability, as SNMPv3 does, it should be obeyed.

To contrive an example where it might matter...

Suppose instead of SSHTM+TSM, we had defined TLSTM+TSM, where TLSTM 
provides authentication using client certificates.  This new transport 
model would indicate use of TSM by setting securityModel in tmStateRef, 
exactly as SSHTM would today.

Now, someone might come along and provide a new GSS-API security model 
(GSM), which allows use of an arbitrary GSS-API mechanism to authenticate 
the user, and then uses channel bindings to tie that authentication to the 
channel provided by the underlying transport model.  Having defined this 
new model, we now want to use SNMPv3/GSM/TLSTM, binding the GSS-API 
authentication to the channel provided by TLS.  This is possible with the 
architecture as we have defined it, but would break if TLSTM's assertion 
that TSM is to be used is allowed to override the securityModel carried by 
SNMPv3 which indicates that GSM should be used.

Let's avoid this whole mess by defining the override behavior _only_ for 
SNMPv1/SNMPv2c.

-- Jeff

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 11 Apr 2008 18:11:04 -0400

Hi,

For incoming messages, the transport model has no idea which message
version is being used. The transport model only forwards the
wholeMessage as received from the network (e.g. passed by SSH).
Determining which message version does not happen until the Message
Processing Subsystem decodes the message version from the ASN.1
format, and then passes the wholeMessage to the appropriate message
processing model for processing. The transport subsystem should not
care which mesage version is being carried.

dbh

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Friday, April 11, 2008 5:57 PM
> To: [email-masked]; David B Harrington
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isms] open issues
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 12 Apr 2008 15:00:09 +0200

> care which mesage version is being carried.

The decision which security model is called is taken by the MPM; so is
it not sufficient to modify the community-based MPM to check the
existance of a tmStateReference?

/js

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 12 Apr 2008 11:07:08 -0400

I believe that could work. That means modifying RFC3584.
That would solve the problem for SNMPv1 and SNMPv2c.
And if a new SNMPv4 message is ever created, it can be written to
accommodate the presence or lack of tmStateReference.

dbh 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Saturday, April 12, 2008 9:00 AM
> To: David B Harrington
> Cc: 'Jeffrey Hutzelman'; [email-masked]

---

From: <[email-masked]>
Date: Mon, 21 Apr 2008 19:35:32 +0300

Juergen Schoenwaelder wrote:

> > needs further research of who must be authenticated for each
> > operation type, and whether the security rules about which
> > identity must be authenticated when using an operation are
> > consistent with SSH and USM and the architecture.
> 

As I'm new to this topic, could you provide e.g. some links to the
options that have been discussed before?

Best regards,
Pasi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Apr 2008 23:03:55 +0200

> options that have been discussed before?

Let me try to summarize what I think is our main problem. A
traditional SNMP agent has two "modes" of operation:

a) Management applications can query agents or modify state of an
   agent.

b) An agent can generate notifications in order to asynchronously
   notify a manager that a certain event has happened.

For the rest of the discussion, it is only important to remember that
a) implies that the manager is taking the initiative and b) implies
that the agent is taking the initiative. Once we talk about SSH as a
secure transport for SNMP, "mode" (a) implies the manager is becoming
an SSH client initiating a connection to the agent, acting as an SSH
server, while "mode" (b) implies that the agent initiates a connection
to the manager, acting as an SSH server.

The SNMP architecture includes an access control subsystem which
resides on the agent and which is called whenever information is
communicated to the outside world. In "mode" a), all attempts to
read/write information have to pass the access control subsystem.  In
"mode" b), all outgoing notifications have to pass the access control
subsystem as well. The idea is ensure that a principal can only get
access to the information he is authorized to receive, regardless
whether the information is read, written, or communicated via a
notification.

Our problem now is that SSH authentication is asymmetric - the SSH
client authenticates the SSH server while the SSH server authenticates
an SSH user identity residing on the SSH client. As a consequence, in
"mode" a) the agent has an authenticated SSH user name to base its
access control decision on while in "mode" b), the agent has an
authenticated host identity to base its access control decision on. It
may be important to note that on a given host, there can be multiple
notification receivers with different access control requirements.

Several options were investigated how to address this issue and so far
we have not found one that is really making people happy. Some options
considered:

A) A notification originator may initiates the underlying TCP
   connection but then the roles are swapped before the SSH exchange
   beginns. This "solution" has security problems and does not work.

B) Notifications always travel over an SSH connection that has been
   initiated by a "manager" application, so we always have an
   authenticated user identity for access control to work as expected.
   If there is no suitable SSH connection, one can either revert to
   SNMPv3/USM (means ISMS looses its value since you still need a
   fully configured SNMPv3/USM infrastructure) or one can use an
   unauthenticated notification to let the manager initiate a suitable
   SSH connection (ugly and likely has similar security issues like
   A). Furthermore, in many implementations, command generators and
   notification receivers are not really tight together so using a
   shared SSH connection may simply not be realistic for a large range
   of existing code bases.

C) Work around the issue by using SSH host-based authentication. This
   option has issues with situations where a single host may contain
   multiple notification receivers that are authorized to receive only
   different subsets of notifications, see above.

There might be more options or variations we have considered and which
I have forgotton to mention in this email.

Was this explanation understandable? If not, keep asking questions.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 22 Apr 2008 18:54:02 -0600

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 22, 2008 3:03 PM

> Was this explanation understandable? If not, keep asking questions.
...

While not disagreeing with Juergen's analysis, I think it might be helpful to
look at the problem in a slightly different way.

Think of a notification subscription as an information retrieval request,
and the notification as the (potentially much-delayed) response.  How
do we know the "response" (the notification) is going to the party that
requested it and not someone else?  After all, *anything* could have
been configured as the notification destination.  In the case of USM,
it's the symmetric key used by the notification subscriber that implicitly
makes this binding, and prevents anyone else from getting at the data first.
(If the data isn't encrypted, the whole question is really moot.)

With USM, there's a reasonable argument for using a separate identity
for notifications for each manager/agent pair.  Otherwise, the compromise
of one managed element would permit the impersonation of others as
notification generators.  (This is discussed in RFC 3414.)  Perhaps
this same approach (keeping the nofitication identities distinct from those
used for monitoring and configuration) might be helpful here.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Apr 2008 08:45:30 +0200

> (If the data isn't encrypted, the whole question is really moot.)

I guess you talk about this option:

D) The notification receiver establishes an SSH connection (acting as
   an SSH client) and configures the SNMP agent (acting as an SSH
   server) to send notifications via this SSH connection. This plays
   nicely with the way SNMP access control works.

   The drawbacks of this approach are that (i) you have to have a
   command responder co-located with a notification originator, (ii)
   it won't work with short-lived notification originators, such as
   snmptrap commandline utilities, (iii) you have to keep SSH
   connection alive to all notification receivers, and (iv) the
   garbage collection of notification target configurations when the
   SSH sessions disappear needs to be worked out (but that seems to be
   a minor issue).

If you have something else in mind, let me know.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Apr 2008 01:28:53 -0600

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 23, 2008 12:45 AM
...
...

That's not what I intended.  My point was that in the USM world,
the agent will have been configured with information that (1)
allows an access control policy to be applied before allowing
information to leave the box in a notification, and (2) prevents
that information from being used by anyone else without having
first passed through something that has the right key.  Also of
interest is (3) that the identity used for sending the notification
isn't necessarily the identity used to create the subscription.

(2) is *logically* authentication, but in fact in USM it's the symmetric
encryption key that makes it work.

I think it's pretty clear that session management for notification
streams should be handled by the notification originator, short-lived
or not.  For the notification receiver to be responsible for creation
and teardown would be much less robust and not scale as well.

So if the manager is an SSH server as far as notification streams
are concerned, I think things work out about as well as they do with
USM (if one has configured USM to not be vulnerable to the potential
compromise of an agent system.)  Specifically, it means that for a 
notification user, a separate securityName would need to be created
for each manager/agent pair.  (Otherwise one agent could impersonate
another.) Though the access control policy is applied on the agent,
that securityName is also what would be needed to establish the
SSH connection with whatever manager is to be used as the trap
destination, thus giving the desired authentication, or at least as
much authentication as a manger gets when it sends configuration
data to an agent.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Apr 2008 10:47:01 +0200

> much authentication as a manger gets when it sends configuration

But if the manager is the SSH server, then all you have is an
authenticated host the server is running on. You made the point that
there can be distinct notification receivers on the same host. So how
do you solve that puzzle?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Apr 2008 11:53:16 -0600

Hi -

> Sent: Wednesday, April 23, 2008 2:47 AM
...
...

I don't.  Our architecture, both on the manager and on the agent ends,
strongly assumes that security mechanisms are able to authenticate
to the granularity of a principal.  RFC 3411 sections 3.2.1 and 3.2.2
should make that clear.  If SSH doesn't provide (or can't be made to
provide) that service, then it's not suitable.  It's as simple as that.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Apr 2008 23:33:43 +0200

> provide) that service, then it's not suitable.  It's as simple as that.

Here is the relevant text (for those who are too lazy to look it up):

  3.2.1.  Principal

     A principal is the "who" on whose behalf services are provided or
     processing takes place.

     A principal can be, among other things, an individual acting in a
     particular role; a set of individuals, with each acting in a
     particular role; an application or a set of applications; and
     combinations thereof.

  3.2.2.  securityName
  
     A securityName is a human readable string representing a principal.
     It has a model-independent format, and can be used outside a
     particular Security Model.

So is the conclusion here that SSH is a dead end? Do we have to revisit
the discussion of SSH vs. TLS?

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Apr 2008 19:02:30 -0400

Hi,

I think we need to make it clear (assuming we don't find a way to
solve this problem) that operators need to understand that
notifications over SSH can only be delivered to host granularity, not
to user-level granularity.

Since ACM uses securityName/securityModel, this would actually apply
to any transport model that uses TSM.

I am not convinced that host-level granularity satisfies the
operators' requests for database access controls. If host-level is
enough for operators, including for GET/SET requests, then we can
control access based on (authenticated host) transport address rather
than authenticated user, and greatly simplify SNMPv3. This is not what
Enterasys customers asked for; they wanted user-granularity
authentication and access controls.

If the granularity of access control for notifications is different
than the granularity for GET/SET requests, we need to consider
security implications of reporting something to a user in a trap that
he is not authorized to see using a GET request.

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, April 23, 2008 5:34 PM
> To: Randy Presuhn
> Cc: [email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 23 Apr 2008 19:13:48 -0400

Randy Presuhn writes...

> Our architecture, both on the manager and on the agent ends,
> provide) that service, then it's not suitable.

The authentication inherent to SSH is asymmetric.  It was originally
designed to facilitate users logging into remote hosts.  An SSH client is
able (by various SSH Authentication Methods) to authenticate to an SSH
server at the granularity of a principal.  An SSH server authenticates to
the SSH client at the granularity of a host (i.e. the host identity of the
SSH server).

If you assume that the shared keys of USM are shared at the granularity of a
principal at both the agent and management station ends on an SNMP
connection, then USM provides symmetric authentication at the granularly of
a principal.

In order to provide authentication at the granularity of a principal in the
notification case for SSHTM, one would presumably require that the agent act
as an SSH client and present principal granularity credentials for
authentication by the SSH server, i.e. the management station.

The fly in the ointment here is that one of the primary reasons for having
SSHTM is to avoid the need to provision credentials (at principal
granularity) on all the managed entities in an organization.  In the case of
a management station sending SNMP commands to an agent, we assume that the
management station application, or the user invoking that application, has
an identity that can be validated via some method such as AAA, at the agent.
That identity may become from some non-volatile configuration store, or it
may come from the user's login credentials.  I think that the latter case is
more common.

It is perfectly possible to provision device credentials in the non-volatile
configuration store of the managed entities (notification generators) if you
are willing to experience USM-like scaling properties.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Apr 2008 17:35:43 -0600

Hi -

> From: "David B. Nelson" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, April 23, 2008 5:13 PM

With key localization, this is indeed how it works for command generators
and responders.  For the notification case it *can* work the same way,
though with an unfortunate proliferation of securityNames and associated
keys.  (Keeping it simple opens the possibility that a compromised
notification generator could impersonate another.)

> authentication by the SSH server, i.e. the management station.

This sounds fine.

> are willing to experience USM-like scaling properties.

It'd be no worse than USM.  That sounds like a victory.  :-)

Before descending into gloom it might be helpful to carefully think through
the trust model for notification receivers in USM, to understand whether it
is really necessary to go that far.

In the USM world, the transmitting SNMP engine uses the securityName to
determine whether the information in the notification should be allowed to
leave the box.  The SNMP engine receiving that notification uses the
authentication information to make sure the information is genuine.  How
does the sender know the notification has gone to the "right" user?  All it
*really* knows is that the SNMP engine for the notification receiver has
to have that shared key in order to decrypt the payload, and that the
notification's ultimate consumer must have entrusted that engine with
the key.  This gives us an implicit two-way authentication, at least as far
as the protocol engines. In terms of demultiplexing incoming notification streams to
the correct user of the management system, whether based on securityName
or something else, all RFC 3413 has to say in section 3.4 (3) is "After this,
processing depends on the particular implementation."

Consequently, I think whether collapsing things down to a single securityName
per agent for incoming notifications would be adequate depends on
the extent to which implementations of notification receiver applications
rely on securityName to demultiplex notifications corresponding to
different "subscriptions."

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Apr 2008 08:32:55 +0200

> to any transport model that uses TSM.

I fail to see why. Suppose I have a secure transport where the
principals at both endpoints are authenticated using say PGP keys.
Why should TSM then not be able to do the right thing?

/js

---

From: "David Harrington" <[email-masked]>
Date: Thu, 24 Apr 2008 04:08:34 -0400

OK.

dbh

> Sent: Thursday, April 24, 2008 2:33 AM
> To: David Harrington
> Cc: 'Randy Presuhn'; [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Apr 2008 20:44:33 +0300

Randy Presuhn wrote:

> In the USM world, the transmitting SNMP engine uses the securityName
> to determine whether the information in the notification should be
> allowed to leave the box.  The SNMP engine receiving that
> notification uses the authentication information to make sure the
> information is genuine.  How does the sender know the notification
> has gone to the "right" user?  All it *really* knows is that the
> SNMP engine for the notification receiver has to have that shared
> key in order to decrypt the payload, and that the notification's
> ultimate consumer must have entrusted that engine with the key.
> This gives us an implicit two-way authentication, at least as far as
> the protocol engines. In terms of demultiplexing incoming
> notification streams to the correct user of the management system,
> whether based on securityName or something else, all RFC 3413 has to
> say in section 3.4 (3) is "After this, processing depends on the
> particular implementation."

I guess in case of SSH, this would mean that the notification
originator (acting as SSH client) needs to know:

in the application:
- transportAddress (of the destination)
- securityName (used primarily to determine whether this 
  information should be allowed to leave the box)

in SSHTM (or somewhere): for each (transportAddress, securityName) 
pair, how to do authentication in ssh client role:
- user name to send in SSH
- authentication method (e.g., password or publickey)
- the secret to use (e.g., password, private key)

in SSH:
- for each transportAddress, the host public key

It seems that in this direction, the securityName and SSH user name
won't be the same: securityName would identify someone who's allowed
to see the information ("researchDeptAdmins" or "John"), but SSH user
name would identify the notification originator ("router37" or
"switch12.44.subunit7.example.com"), right?

(In the command generator case, the securityName and SSH user
name identify the same principal, so they could be the same.)

> Consequently, I think whether collapsing things down to a single
> securityName per agent for incoming notifications would be adequate
> depends on the extent to which implementations of notification
> receiver applications rely on securityName to demultiplex
> notifications corresponding to different "subscriptions."

BTW, is the securityName only handled solely by the security model, 
or is it included somewhere inside the PDU even when you're using
SSHTM? 

If it's not, could we somehow include it just for this purpose 
(allowing notification receiver to do internal processing)?

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 24 Apr 2008 21:07:14 +0300

Juergen Schoenwaelder wrote:

> So is the conclusion here that SSH is a dead end? Do we have to
> revisit the discussion of SSH vs. TLS?

I'm not sure if the situation would be considerably simpler even with
TLS... or it would require small extensions to TLS.

Suppose a command responder authenticates connections with TLS and
client certificates. A certificate from trusted CA, containing name
"[email-masked]", would give access with that securityName,
and things would probably largely as you'd expect.

However, for the notification originator part, if the same
transportAddress has multiple different notification receivers, the
notification originator, when starting TLS handshake, would need to
tell the receiver "I have stuff to send to [email-masked]", 
so that the receiver would know to authenticate with that certificate
(instead of, say, "mgmtpc4.example.com" or "[email-masked]").

Current TLS doesn't support that; you'd need to extend the 
the server_name TLS extension to support other types of identities 
than host names. 

And if a given transportAddress has just one principal behind it, 
we don't really have problems with SSH either, right? 

On the other hand, even if you do have multiple principals, the
software receiving the connection would still have access to both
John's and Alice's private keys. So we're trusting it anyway...

What if the SSHTM also included a security model that didn't
actually do any crypto or anything, but just included the 
securityName in the PDU so that the notification recipient could 
do internal processing (knowing that this notification should
be seen only by John)? Or perhaps there are some easier ways
to achieve this?

Best regards,
Pasi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Apr 2008 20:31:23 +0200

> the server_name TLS extension to support other types of identities 

Thanks, this is valuable to know.

> we don't really have problems with SSH either, right? 

Almost. And SSH hostkey, as I understand it, identifies a host, not
just a transport endpoint. But there might be ways to weak SSH to use
different hostkeys for different transport endpoints on the same host.

> be seen only by John)? Or perhaps there are some easier ways

I am not so much concerned about the multiplexing on the notification
receiver side. The real issue is that we need an authenticated
principal for the access control to work correctly and there might be
several different principals behind the same notification receiver
endpoint.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 24 Apr 2008 11:54:41 -0600

Hi -

> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Thursday, April 24, 2008 11:44 AM
> Subject: RE: [Isms] open issues
...
> "switch12.44.subunit7.example.com"), right?

Perhaps there's an implementation / deployment choice here,
driven by the trust model.  When a notification stream is
presented to a management application, whose credentials 
would one want to use to decide whether to accept that stream?
Ones associated with the subscriber, ones associated with the
agent, or ones associated with both  (i.e. that subscriber at that
agent, as in a paranoid USM deployment)?

The second consideration is whether existing notification receiver
applications are using securityName to figure out where to internally
(within the management system) route notifications.  This is outside
the scope of what we nail down in the SNMP specifications, but would
be a practical consideration.  We need to hear from the management
application people.

...
...

RFC 3413 section 3.4 specifies that securityName is provided
to the notification receiver application.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 24 Apr 2008 12:03:37 -0600

Hi -

> Sent: Thursday, April 24, 2008 12:31 PM
...
...

With USM, even though the privacy key gives us the other half
of the authentication, we *still* have to trust the notification receiver
to demultiplex things correctly, and that's beyond the scope of the
SNMP RFCs.

So I think the real concern has be making sure that the SNMP
engine in front of the notification receiver application is indeed
the one requested by the subscriber, while still maintaining
sufficient information in the PDU to permit demultiplexing.

The question would still arise about the possibility of a forged
subscription, but that is handled through the design of the
target and notification MIBS in conjunction with VACM, as
long as we don't start coalescing securityNames.

Randy

---

From: <[email-masked]>
Date: Wed, 30 Apr 2008 10:01:37 +0300

> different hostkeys for different transport endpoints on the same host.

Although the SSH RFCs talks about "hosts", if a host would have more
than one SSH server running, they could have different "host" keys
(just like if you have multiple applications using TLS on the same
host, they might need different certificates).

> several different principals behind the same notification receiver

Do you mean access control on the notification receiver side, or
on the notification originator side?

(I think we can handle the latter: the securityName given by the
notification originator application would identify the intended
recipient, and would be used for access control on the notification
originator side -- but the SSH user name sent when connecting
to the notification receiver would identify the originator.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 30 Apr 2008 10:02:41 +0300

Randy Presuhn wrote:

> > It seems that in this direction, the securityName and SSH user 
> > name won't be the same: securityName would identify someone 
> > who's allowed to see the information ("researchDeptAdmins" or 
> > "John"), but SSH user name would identify the notification 
> > originator ("router37" or "switch12.44.subunit7.example.com"), 
> > right?
> 

Perhaps we're discovering a limitation that RFC 341x didn't really
consider: when you use pairwise secret keys, the key (and its
securityName) always identifies (at least implicitly) both ends of the
relationship. In case of public key crypto, that's not the case.
 
> to the notification receiver application.

Yes.. but it's not clear whether this is always the same securityName
that was provided by the notification originator application
(identifying the receiver, used for access control on the originator
side), or a securityName identifying the originator.

For pairwise secret keys, it doesn't matter. For public keys, if it's
important to know the former on the notification receiver side, we
might need to pass it separately from the SSH user name.

Best regards,
Pasi

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Apr 2008 09:20:00 -0600

Hi -

> Sent: Wednesday, April 30, 2008 1:02 AM
...
> relationship. In case of public key crypto, that's not the case.

My recollection was that we consciously used this property in the design
of USM.  I don't recall any discussions of whether the property held true for
public keys.

...
> might need to pass it separately from the SSH user name.

The assumption when the architecture was designed was that the
securityName delivered to the notification receiver application would
be whatever one was supplied by the notification generator, which would
be whatever was used by access control to determine whether the information
should be permitted to be delivered to that party.  It's *not* a securityName
identifying "the originator" - the only thing in the architecture that comes close
to that concept would be the snmpEngineID.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Apr 2008 12:26:52 -0400

The securityName represents the principal on whose behalf the
notification was originated. So typically, this is not the host, but
the identity of the "user" on whose behalf the notification is sent.

**on whose behalf** was an important phrase during SNMNPv3
development.

dbh

> Behalf Of Randy Presuhn
> Sent: Wednesday, April 30, 2008 11:20 AM
> To: [email-masked]

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 30 Apr 2008 09:34:10 -0700

> Sent: Wednesday, April 30, 2008 8:20 AM
> To: [email-masked]
> My recollection was that we consciously used this property in 
> the design of USM.  I don't recall any discussions of whether 
> the property held true for public keys.
> 
[Joe] USM key localization changes this a bit in that the key that is
used depends upon both the security name and Engine ID.  I don't think
that this is explicitly part of the architecture, but it does creep into
to how one deals with the security issues. 

> ...
> > > RFC 3413 section 3.4 specifies that securityName is 
> provided to the 
> > > notification receiver application.
> >
> The assumption when the architecture was designed was that 
> the securityName delivered to the notification receiver 
> application would be whatever one was supplied by the 
> notification generator, which would be whatever was used by 
> access control to determine whether the information should be 
> permitted to be delivered to that party.  It's *not* a 
> securityName identifying "the originator" - the only thing in 
> the architecture that comes close to that concept would be 
> the snmpEngineID.
> 
[Joe] When considering authorization for delivering notifications you
want to authorize the identity of the recipient of the notification.  In
USM this corresponds to the one holding the key associated with the
security name that can decrypt the message upon reception.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Apr 2008 09:34:29 -0600

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, April 30, 2008 10:26 AM

...

Yes.  And in the case of the notification originator, it isn't necessarily
the same string as the securityName used by the subscriber, even
though that's probably the most common case.  (The reason for
making it different is if one is extremely paranoid about the possibility
of compromised systems being used to generate phony notification
streams puporting to come from some other system.)  But even in that
case, this other securityName is still conceptually used to identify (as an
alias, if you will) the user on whose behalf the information is being sent.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Apr 2008 12:45:34 -0400

In SNMPv3, we mixed things up fairly well.

I think the two things we wanted to achive are
1) determine whether the receiver is authorized to receive the data in
the notification (i.e. whether to send the notificastion), and
2) the receiver wants to authenticate the message as being from the
right engineID, the right principal, within the allowed time window,
and integrity-checked, encrypted (if called for), etc.

Since we only dealt with symmetric protocols, we allowed the
assumption to leak in that one securityName worked for both purposes.
 
dbh

> Behalf Of Joseph Salowey (jsalowey)
> Sent: Wednesday, April 30, 2008 12:34 PM
> To: Randy Presuhn; [email-masked]