Re: [Isms] wg last call followup - sshtm

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
To: "tom.petch" <cfinss at dial.pipex.com>
Cc: "David Harrington" <ietfdbh at comcast.net>; <isms at ietf.org>
Sent: Wednesday, March 04, 2009 4:40 PM
Subject: Re: [Isms] wg last call followup - sshtm


> On Wed, Mar 04, 2009 at 01:59:09PM +0100, tom.petch wrote:
>
> > Yes, and that is a concern for me.  When user at host was first mooted,
> > I recall a comment, Jeff I think, that this format was a commonplace
> > in ssh. This means that people will have expectations which isms may
> > or may not meet. I do not know what those expectations are.  I have
> > trawled the documentation of various manufacturers - eg Cisco,
> > Juniper - for what they can do with ssh and see no reference to it.
> > This does not surprise me, I probably need an programmer's guide
> > with ssh APIs in it, not the sort of thing Cisco would put on its
> > web site.  Doubtless such a thing is available in a toolkit for
> > Linux but that is not an area I am comfortable in.
> >
> > So instead I want a little more clarity in our documentation so that
> > those coming from an ssh background with an intimate knowledge of
> > what user at host will do for them, can see whether or not we do what
> > they expect.
>
> Take your average Unix system and do 'man ssh' and the user at host
> syntax pops up immediately. On Windows, you find graphical clients
> that tend to ask for
>
>      Host:
>      User:
>      Password:
>
> and this is the same thing in a GUI. Since this is a client issue, the
> Cisco's of the world probably do not spend much effort documenting
> this (but I actually did find screenshots on Cisco web pages). SSH's

I will look again

> user at host notation is very wide-spread if you ask me. You clearly do
> not need a programmer's eye to use it.
>
> > Note too that yesterday, you said
> >
> > "The point is that for notifications, access control
> > uses securityName to identify the notification receiver while SSH uses
> > the SSH user name to identify the notification sender. In many cases,
> > these will not be the same. So the user at host format allows to make
> > this important distinction. Is this understandable?"
> >
> > Understandable yes, but this appears to be the exact opposite of my
> > current thinking.  I think that securityName identifies the
> > principal in the notification sender/originator and SSH user name
> > identifies the principal in the notification receiver.
>
> When you send a notification, the ACM filters on the identity of the
> receiver. We worked this out quite some time ago. In other words, I
> have a securityName on the NO, say "trapsink" and I apply access
> control such that "trapsink" only gets what it is allowed to see.
> When I use SSH to connect to the NR, the SSH user name is used by the
> NR to identify the sender of the notification while the notification
> sender has to verify that the hostkey matches the expected hostkey
> associated with the SSH transport address. So the binding between the
> securityName "trapsink" on the NO and the SSH transport address given
> by the local configuration is really the important part from the
> notification sender's perspective.

Ok, I now see that explanation too.  I understand and agree the mechanics so as
long as those are called out, as they are eg in the tsm appendix, then I can
live with the terminology.  I see the terminology of roles as more like a
question of philosophy, of identity and identifiers, and as long as we get the
mechanics across clearly, then the terminology actually used does not matter.

I will re-read those long e-mails of Wes from 2006 again, something I do every
so often, to see how our thinking on Notifications has evolved.

Tom Petch



>
> > Which way round is going to be the expectation of all those SSH
> > experts?
>
> They will understand that by putting "user at host" into the SSH
> transport address, the NO will authenticate as "user" to the NR
> running on "host". This is straight forward.
>
> /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/>