Subject: Re: [Isms] More questions on Security name

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2007 15:45:57 +0200

On Thu, Aug 23, 2007 at 10:40:48AM -0400, David Harrington wrote:
 
> > So the authoritative part of my comments should be ignore in terms
> > of architectural impact.
> > Again, I wish those who argued so vehemently in favor of making the
> > receiving end of an INFORM authoritative were participating.
> > There was (I believe, but do not recall details) more to it than
> > just USM. But in our current archtecture and documents, indeed the
> > architecture
> > does not speak of authoritative sides. Only USM does.
>
> I think there may have been a number of motivations for the
> authoritative difference. The main one in my mind is the use of clocks
> to detect timeliness, to help prevent replay. There are certain
> attacks that can be launched using replay, and causing the
> re-synchronization of clocks. It is important to check timeliness
> using the correct clock, and it is important to sync using the right
> clock. 

I think this WG has spend significant efforts to find out where the
notion of an authoritative engine has impact outside the USM (Bert
Wijnen was specifically working on this) and we did not find one. So I
think there is concensus to make the assumption that the notion of
authoritative engines is USM specific and does not concern SNMP or
more specifically ISMS on the architectural level.

/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://www1.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2007 16:19:18 +0200

On Thu, Aug 23, 2007 at 08:02:37AM -0400, David Harrington wrote:
 
> As I recall, no solution was found to this issue. I think we reached
> consensus that 
> 1) if a client had already established a connection, so we have a
> relevant securityname, then that connection could be reused for
> notiications.

This, of course, requires that appropriate entries exist in the
snmpTargetTable and friends that point to this notification
destination. In other words, this assumes a subscription mechanism
where you establish the SSH transport and then create entries that
direct notifications to the SSH session.

The only issue left with this approach (as I recall) is how to garbage
collect those dynamic entries in the snmpTargetTable and friends,
which likely needs a sparse augmentation of the snmpTargetTable.

> 2) if a notification needs to be sent, and no SSH connection exists,
> then the transport model will try to create a connection. How the
> credentials are supplied, and how the connectionis created is
> implementation-specific. The slides from IETF67 present three
> options for doing this, which may or may not work.

The straight forward approach is to have an SSH user name plus
whatever credentials needed for authentication on the "device" and to
use the authenticated host identity as the security name (and thus as
input for the access control decision).

We investigated turning SSH roles around and finally concluded that
this is not going to work due to security issues; at least not without
a surgery of SSH (which is not our business).

> 3) if a notification needs to be sent, and no SSH connection exists,
> then the agent can use USM to send the notification. This is
> implementation-specific.

Implementation-specific magic to fallback to USM does not seem to be a
solution to pursue on a standards-track.

So I think we essentially have 2) and an incomplete 1).

/js

---

From: "tom.petch" <[email-masked]>
Date: Mon, 17 Sep 2007 12:44:14 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 14, 2007 4:19 PM
Subject: Re: [Isms] More questions on Security name

> a surgery of SSH (which is not our business).
Agreed, but I believe that this is an architecture/subsystem discussion and the
fact that SSH cannot do it should not rule it out of the subsystem; a future
transport may have just what we need.

In a sense, this is an SSH problem because SSHTM says that the securityName is
the SSH user name (if the SSH host name were the securityName for notifications,
I do not see a problem - well, not this one:-).

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 18 Sep 2007 10:00:49 +0200

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "David Harrington" <[email-masked]>; "'Wijnen, Bert (Bert)'"
<[email-masked]>; "'Joseph Salowey (jsalowey)'"
<[email-masked]>; <[email-masked]>
Cc: "Jeffrey Hutzelman" <[email-masked]>
Sent: Tuesday, August 28, 2007 12:32 AM
Subject: RE: [Isms] More questions on Security name

<snip>

>
> When we get to talking about notifications, it still works to fold (1) and
> (2) into the transport address, because that is still the address of the
> agent we want to contact.  However, we run into trouble with (3) because
> SSH needs to know the username of the notification originator, while the
> architecture seems to assume here that securityName is the name of the
> notification receiver.  In USM that doesn't matter, because the
> securityName actually names the pair.  But for SSH it does; my name is
> _not_ the same as your name.
>
> Obviously it is possible for an implementation to work around this by
> providing an implementation-specific way to specify the username to be
> used, or by ignoring the architecture and declaring that for a
> notification, the username actually describes the NO and not the NR.  I
> imagine there are other possibilities as well.
>
> This problem is not unique to SSH; rather, the lack of it is unique (or
> nearly so) to USM.  IMHO that means there is a problem either with the
> architecture or with our understanding of it, and that problem needs to be
> solved before a clean solution to authenticating outgoing notifications is
> possible.

Jeff

I have been mulling this problem over, albeit without any profound insight.

SNMP requires the recipient of data (NR, CG) to be authenticated/authorised be
it for a simplex transaction (NO->NR) or a half-duplex one (CG<->CR).

SSH requires the initiator of the transaction (NO, CG) to become the user; SSHTM
makes the user's name the principal with the consequences described.

USM 'gets round' this by having a identity/security credentials for the
transaction rather than for each party to the transaction.

With a secure transport, the equivalent could be Pre-Shared Key or perhaps
Secure Remote Password.  The identity doesn't matter - could be
[email-masked] as Joe suggested - but, as ever, distributing
security credentials remains the problem; somewhat defeats the purpose of ISMS.

(Or we could take the syslog approach that it is the Notification Originator
that should be authenticated:-)

Tom Petch

> -- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Thu, 27 Sep 2007 01:50:32 -0400

Hi,

comments inline. 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 10:19 AM
> To: David Harrington
> Cc: 'Wijnen, Bert (Bert)'; 'Joseph Salowey (jsalowey)';
[email-masked]
> direct notifications to the SSH session.

I am not a system administrator, but my view of the world says that a
sysadmin would want to control who gets notifications. So I envision
the target table (subscriptions) being defined statically to include a
small number of targets, not dynamically for all SNMP users that can
establish an SSH transport. But I could be wrong; maybe the target
table could be generated dynamically and let the access control system
control who gets them.

> input for the access control decision).

The transport model doesn't know whether a message is a notification.
The userauth protocol allows for multiple authentication mechanisms,
but if we use the authenticated host identity as securityName, then we
not only need to specify different method names, we need to specify a
whole different "level" of authentication. I don't know how that would
be specified.

I am particularly concerned about combining reuse of a userauth
session for sending notifications, and having a totally different
level of authentication for others, all handled through the same
transport model/security model.

If I have a VACM securityName for user "gandalf" and TSM, does that
refer to a  userauth (client-auth) gandalf, or a hostauth
(server-auth) gandalf? If the channel was opened by the remote client,
and the connection is reused, then it refers to client auth; if a
notification needs to be sent before a request is received, it refers
to server-only-auth. And those two auths might have different security
properties related to access control.

One way to resolve this might be to define different transport
domains, one for userauth and another for server-auth-only. I'm not
sure transportDomain shows up in the access control decision, but it
does show up in the application decision of transport. 

In USM, we would treat these as different authn mechanisms leading to
securitynames, but that used static configuration of the usmUserTable
to get the mappings.