Proposed SSH Transport Address Changes (and a quick nit)

[Wes Hardaker-2]

I promised David a while ago to write this thought up...  I'm a bit late
in getting it out the door though.

Current the SnmpSSHAddress TC offers flexible support to accommodate a
name, a v4 address and a v6 address (surrounded by brackets) and by a
port number.  Thus the following values are legal:

  127.0.0.1:161
  host.example.com:161
  [::1]:161

(if I read everything correctly).

First, a quick issue: (which will be new to you Dave since I noticed it
after our discussion) is that the text about IPv6 says "surrounded by
brackets" which is not deterministic since there are two types of
brackets.  I assume you mean square brackets, because that's common
usage, but it should be spelled out (maybe using the ASCII character
numbers 0x5B and 0x5D like you did for the colon).


Second, SSH has a fairly common usage that allows one user on one host to
connect as a different user on the remote host.  Right now in the SSHSM
solution it's not possible to use a different remote user than the one
specified locally even though this is common usage within SSH users
today.

To fix this, I'd like to suggest another *optional* portion on the front
of the string that allows specifying the SSH user name to be used.
Specifically, the "@" sign (ASCII 0x40) in the address string would be a
delimiter to indicate that the beginning portion is a user name.  The @
symbol don't exist legally in the existing specification so it shouldn't
conflict with the existing structure and is easy to quickly look for and
parse out.  (and it is already common usage within at least some SSH
implementations).

Thus a transport address might look like these (in addition to the above
still being legal):

  wes@...:161
  wes@...:161
  wes@[::1]:161


What's the benefit?
----------------------------------------

A separation of the local securityName from the remote user used to
authenticate to the remote connection.  SSH users use this all the time
because their local identity name is different than the remote (I'm
"hardaker" on my local system, but "whardaker" on others).  From an SNMP
standpoint, I could use a single local username to do VACM and other local
information checks ("hardaker") but ssh-login to the remote site using
different names as needed and specified by the transport address.  The
only thing this affects is the SSH transport that uses the address
string.  And because some SSH stacks already support this, it's possible
they can still just pass the string along as is.  Operators already
understand the usage (and may expect that it'd work).

--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Juergen Schoenwaelder-2]

On Thu, Jul 03, 2008 at 09:43:05AM -0700, Wes Hardaker wrote:
 

> Second, SSH has a fairly common usage that allows one user on one host to
> connect as a different user on the remote host.  Right now in the SSHSM
> solution it's not possible to use a different remote user than the one
> specified locally even though this is common usage within SSH users
> today.
>
> To fix this, I'd like to suggest another *optional* portion on the front
> of the string that allows specifying the SSH user name to be used.
> Specifically, the "@" sign (ASCII 0x40) in the address string would be a
> delimiter to indicate that the beginning portion is a user name.  The @
> symbol don't exist legally in the existing specification so it shouldn't
> conflict with the existing structure and is easy to quickly look for and
> parse out.  (and it is already common usage within at least some SSH
> implementations).

Our implementation actually support this on the command line:

  snmpwalk -u schoenw ssh:schoenw@...:1234 ifTable

[I would prefer to get rid of the '-u schoenw' part but NET-SNMP
 5.3.0.1 seems to insist on having the -u option for v3; I guess we
 have to dig deeper.]

We currently don't implement any MIB objects but it seems straight
forward and operationally useful to support the 'user@' part. So I am
kind of in favour of this proposal.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[David Harrington]

Hi,

I do not support this for the current ISMS work.
I am of the impression this would require yet another mapping table to
support a feature that is not needed by everybody.

Remember the convention that an SNMP agent should be simple, and that
complexity should be handled by the manager application? This looks
like something that should be supported by the manager, not by every
SNMP engine. I do not think it is a lot to ask that admins use the
direct name in the notify tables rather than some indirect name.

We are approaching ISMS year four and we have yet to deliver a single
document to the IESG.
Let's not keep dreaming up additional features for unusual edge cases.

Let's get our first "basic" version released so operators can use it
in everyday circumstances.

dbh

> -----Original Message-----
> From: isms-bounces@... [mailto:isms-bounces@...] On
> Behalf Of Juergen Schoenwaelder
> Sent: Monday, July 14, 2008 6:20 AM
> To: Wes Hardaker
> Cc: isms@...
> Subject: Re: [Isms] Proposed SSH Transport Address Changes
> (and a quick nit)
>
> On Thu, Jul 03, 2008 at 09:43:05AM -0700, Wes Hardaker wrote:
>  
> > Second, SSH has a fairly common usage that allows one user
> on one host to
> > connect as a different user on the remote host.  Right now
> in the SSHSM
> > solution it's not possible to use a different remote user
> than the one
> > specified locally even though this is common usage within SSH

users

> > today.
> >
> > To fix this, I'd like to suggest another *optional* portion
> on the front
> > of the string that allows specifying the SSH user name to be used.
> > Specifically, the "@" sign (ASCII 0x40) in the address
> string would be a
> > delimiter to indicate that the beginning portion is a user
> name.  The @
> > symbol don't exist legally in the existing specification so
> it shouldn't
> > conflict with the existing structure and is easy to quickly
> look for and
> > parse out.  (and it is already common usage within at least some

SSH

> > implementations).
>
> Our implementation actually support this on the command line:
>
>   snmpwalk -u schoenw ssh:schoenw@...:1234 ifTable
>
> [I would prefer to get rid of the '-u schoenw' part but NET-SNMP
>  5.3.0.1 seems to insist on having the -u option for v3; I guess we
>  have to dig deeper.]
>
> We currently don't implement any MIB objects but it seems straight
> forward and operationally useful to support the 'user@' part. So I

am

> kind of in favour of this proposal.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> Isms mailing list
> Isms@...
> https://www.ietf.org/mailman/listinfo/isms
>

_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Wes Hardaker-2]

>>>>> On Mon, 14 Jul 2008 12:19:33 +0200, Juergen Schoenwaelder <j.schoenwaelder@...> said:

JS> snmpwalk -u schoenw ssh:schoenw@...:1234 ifTable

JS> [I would prefer to get rid of the '-u schoenw' part but NET-SNMP
JS> 5.3.0.1 seems to insist on having the -u option for v3; I guess we
JS> have to dig deeper.]

echo "defSecurityName schoenw" >> ~/.snmp/snmp.conf

But what I wanted to support was more like:

snmpwalk -u schoenw ssh:juergen@...:1234 ifTable

--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Wes Hardaker-2]

>>>>> On Mon, 14 Jul 2008 07:53:48 -0400, "David Harrington" <ietfdbh@...> said:

DH> I am of the impression this would require yet another mapping table to
DH> support a feature that is not needed by everybody.

Actually, I think it drops the need for one.

--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Juergen Schoenwaelder-2]

On Mon, Jul 14, 2008 at 06:43:22AM -0700, Wes Hardaker wrote:
> >>>>> On Mon, 14 Jul 2008 12:19:33 +0200, Juergen Schoenwaelder <j.schoenwaelder@...> said:
>
> JS> snmpwalk -u schoenw ssh:schoenw@...:1234 ifTable
>
> JS> [I would prefer to get rid of the '-u schoenw' part but NET-SNMP
> JS> 5.3.0.1 seems to insist on having the -u option for v3; I guess we
> JS> have to dig deeper.]
>
> echo "defSecurityName schoenw" >> ~/.snmp/snmp.conf

I wanted to get rid of the security name altogether and instead let
the app pick the security name from the transport specification...
 
> But what I wanted to support was more like:
>
> snmpwalk -u schoenw ssh:juergen@...:1234 ifTable

Not sure I understand this. For me, this means "authenticate as
'juergen' at host.example.com" but then what do I use 'schoenw' for?
The TM security name is going to be 'juergen' and assuming no further
mappings, this will be the securityName on the agent. So where do you
think 'schoenw' is going to be used?

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Wes Hardaker-2]

>>>>> On Mon, 14 Jul 2008 15:54:35 +0200, Juergen Schoenwaelder <j.schoenwaelder@...> said:

>> echo "defSecurityName schoenw" >> ~/.snmp/snmp.conf

JS> I wanted to get rid of the security name altogether and instead let
JS> the app pick the security name from the transport specification...

From a technical point of view, it doesn't mater where you specify the
security name that the Net-SNMP transport handler gets the name it's
supposed to use.  However, from a following-the-specs point of view
passing it in via the session makes more sense for what gets mapped to
the session's securityName to use.  The openSession ASI, for example,
expects the session's securityName to be passed as a separate parameter
from the address (this cut-n-paste is from the secshell draft, though it
exists in others too):

   openSession(
   IN   destTransportAddress     -- transport address to be used
   IN   tmSecurityName             -- on behalf of this principal
   IN   maxMessageSize           -- of the sending SNMP entity
    )

Thus having the securityName passed in via a session parameter more
closely mimics the ASI.

>> snmpwalk -u schoenw ssh:juergen@...:1234 ifTable

JS> Not sure I understand this. For me, this means "authenticate as
JS> 'juergen' at host.example.com" but then what do I use 'schoenw' for?
JS> The TM security name is going to be 'juergen' and assuming no further
JS> mappings, this will be the securityName on the agent. So where do you
JS> think 'schoenw' is going to be used?

What I was proposing is different.  The passed in securityName and the
securityName that would associated with the session is unmodified.  It
would still be "schoenw".

The SSH username passed via the SSH authentication scheme would be
"juergen" though, allowing the local "schoenw" user to log into
"juergen" on the remote machine.  This occurs all the time today when I,
as "hardaker" log into another machine as "whardaker".  For my proposal,
only the SSH transport needs to know about the remote username in the
address specification.  The local session would still hold "schoenw" as
the local securityName attached to the session.

Without that, I agree that it's not necessary and what's the point of
adding it to the address spec since another one is already passed in the
openSession arguments.  With it, it allows a local name to be different
than the remote name (which, as I've mentioned before, is a common
notion under SSH).

The only real added benefit is to allow notifications to be sent to
multiple remote destinations with different remote user names that are
all mapped to the same VACM entries locally for notification
authorization.

David's already against the idea and I'm fine with dropping it as well
in interest of forward progress.  It's a minor twiddle to the document
and I'd be happy to supply wording if support beyond myself is found.
Either way, it should probably be a MAY support, IMHO.
--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[David B. Nelson-2]

Wes Hardaker writes...

> This occurs all the time today when I, as "hardaker" log into
> another machine as "whardaker".

Well, yes.  There are various host-resident configuration files that make
that sort of thing happen (.rhosts is but one example).  I thought a major
initiative of the ISMS work was to create a path to independence from this
sort of dependency.  A dependency that, quite frankly, has scaling issues.

In an AAA-driven environment, the idea is to use the *same* user identity
(username) always and everywhere.


_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Wes Hardaker-2]

>>>>> On Tue, 15 Jul 2008 14:48:42 -0400, "David B. Nelson" <dnelson@...> said:

DBN> I thought a major initiative of the ISMS work was to create a path
DBN> to independence from this sort of dependency.

SSH users do use this sort of feature today (the difference is that the
authorization is performed always at the logged-into-site, unlike SNMP
notifications).  Regardless of whether it scales wonderfully or not,
it's common syntax that SSH users know and possibly expect.  The goal of
the ISMS working group was to give them what they know.

DBN> In an AAA-driven environment, the idea is to use the *same* user identity
DBN> (username) always and everywhere.

You're right: no one should mandate that they use it.

(it's when infrastructures collide that people frequently use it.  I do
have infrastructure I make use of with SSH that I can't change my
username account on to match what I am personally using everywhere else)

--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[David B. Nelson-2]

Wes Hardaker writes...

> (it's when infrastructures collide that people frequently use it.
> I do have infrastructure I make use of with SSH that I can't
> change my username account on to match what I am personally using
> everywhere else)

I realize that "single sign-on" (i.e. universal AAA) is like the "Holy
Grail" (much coveted, but never to be obtained).  However, that fact that we
don't have it continually irritates me, on a personal level.  It's what you
would call a "pet peeve".  :-)


_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Wes Hardaker-2]

>>>>> On Tue, 15 Jul 2008 15:03:24 -0400, "David B. Nelson" <dnelson@...> said:

DBN> I realize that "single sign-on" (i.e. universal AAA) is like the
DBN> "Holy Grail" (much coveted, but never to be obtained).  However,
DBN> that fact that we don't have it continually irritates me, on a
DBN> personal level.  It's what you would call a "pet peeve".  :-)

Yep.  I've spent many years trying to pick up the holy grail of single
signon.  The problem is that every time I pick up a grail, someone
taps me on the shoulder and hands me another one.


--
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Juergen Schoenwaelder-2]

On Tue, Jul 15, 2008 at 11:37:28AM -0700, Wes Hardaker wrote:

> >> snmpwalk -u schoenw ssh:juergen@...:1234 ifTable
>
> JS> Not sure I understand this. For me, this means "authenticate as
> JS> 'juergen' at host.example.com" but then what do I use 'schoenw' for?
> JS> The TM security name is going to be 'juergen' and assuming no further
> JS> mappings, this will be the securityName on the agent. So where do you
> JS> think 'schoenw' is going to be used?
>
> What I was proposing is different.  The passed in securityName and the
> securityName that would associated with the session is unmodified.  It
> would still be "schoenw".
>
> The SSH username passed via the SSH authentication scheme would be
> "juergen" though, allowing the local "schoenw" user to log into
> "juergen" on the remote machine.  This occurs all the time today when I,
> as "hardaker" log into another machine as "whardaker".  For my proposal,
> only the SSH transport needs to know about the remote username in the
> address specification.  The local session would still hold "schoenw" as
> the local securityName attached to the session.

For command generators, the local security name (schoenw in the
example) is kind of pointless. If I use ssh:juergen@...,
then the authenticated identity on the command responder side is
juergen.
 
> The only real added benefit is to allow notifications to be sent to
> multiple remote destinations with different remote user names that are
> all mapped to the same VACM entries locally for notification
> authorization.

Yes, once we talk about notifications, things are different since
access control is applied to the local user identity.

> David's already against the idea and I'm fine with dropping it as
> well in interest of forward progress.  It's a minor twiddle to the
> document and I'd be happy to supply wording if support beyond myself
> is found.  Either way, it should probably be a MAY support, IMHO.

I am fine with being silent enough about this to get things out and to
see what gets implemented and deployed.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

Wes Hardaker wrote:
>
> DH> I am of the impression this would require yet another
> DH> mapping table to support a feature that is not needed by
> DH> everybody.
>
> Actually, I think it drops the need for one.

This reply comes a bit late... but I think I agree with Wes here:
allowing "user@host" as SSH transport address could drop the need
for one mapping table on notification originators (it's not that
important for command generators).

An administrator configuring TARGET-MIB will of course include the
securityName used for VACM, but that's *our* name for the *recipient*
(e.g. "joe", an administrator).  To actually open the SSH connection,
SSH will need to send *their* name for *us* (e.g. "router134").

Configuring an extra table mapping "joe,192.0.2.1" to "router134" will
of course work, but allowing "router134@..." as transport
address could be simpler to deploy.

(SSH will still need a mapping from "192.0.2.1" to the host public
key, and from "router134@..." to the password/private key,
but IMHO those really belong in SSH module, not on SNMP side.)

Best regards,
Pasi
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

[Jeffrey Hutzelman]

--On Tuesday, August 05, 2008 12:33:48 PM +0300 Pasi.Eronen@... wrote:

> Wes Hardaker wrote:
>>
>> DH> I am of the impression this would require yet another
>> DH> mapping table to support a feature that is not needed by
>> DH> everybody.
>>
>> Actually, I think it drops the need for one.
>
> This reply comes a bit late... but I think I agree with Wes here:
> allowing "user@host" as SSH transport address could drop the need
> for one mapping table on notification originators (it's not that
> important for command generators).

+1

_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms