Subject: [Isms] user@address:port proposal for secshell

From: Wes Hardaker <[email-masked]>
Date: Mon, 25 Aug 2008 14:11:57 -0700

We discussed this in the meeting and it's unclear that consensus on it
has been reached, but I wanted to spell out the details of what would
need to be changed if we support what I outlined in:

     From: me
  Subject: [Isms] Proposed SSH Transport Address Changes (and a quick nit)
     Date: Thu, 03 Jul 2008 09:43:05 -0700

Specifically, if you'll recall, I was proposing allowing for these since
SSH users are familiar with the syntax, and as Pasi pointed out in the
meeting we can name both sides of the connection in an
bidirectional/asymmetric authentication protocol:

  [email-masked]:161
  [email-masked]:161
  wes@[::1]:161

The list of document changes to the secshell draft that are need to
support this (IMHO) are really only 2 small changes and a possible large
deletion:

* Section 5.3, bullet 1:

  - Change:
    OLD:
      "The parameters of the transport connection and the credentials used
      to authenticate are provided in an implementation-dependent manner."

    NEW:
      "The destTransportAddress field may contain a "USER@" style prefix
      that will indicate a specific string that should presented to the
      ssh server as the "user name" for authentication purposes.  This
      may be different than the passed tmSecurityName value which should
      be used in the remaining steps.  The parameters of the transport
      connection and the credentials used to authenticate are provided
      in an implementation-dependent manner."

* Section 7 in the MIB Module

  - The SnmpSSHAddress should be modified to allow for the new leading
    prefix.  Suggest a rewrite of the beginning text to the following
    (adding bits and pieces to make it work):

         "Represents either a hostname with a port number, an IP
         address with a port number, a username, hostname and port
         number or a username, IP address and port number.

         The beginning of the address specification may contain a
         username followed by an '@' (ASCII character 0x40).  This
         portion of the address will indicate the user name that should
         be used when authenticating to an SSH server.  If missing, the
         SNMP securityName should be used.  After the optional user name
         field and '@' character comes the hostname.

         The hostname must be encoded in ASCII, as specified in
         RFC3490 (Internationalizing Domain Names in Applications)
         followed by a colon ':' (ASCII character 0x3A) and a
         decimal port number in ASCII. The name SHOULD be fully
         qualified whenever possible.

         An IPv4 address must be a dotted decimal format followed
         by a colon ':' (ASCII character 0x3A) and a decimal port
         number in ASCII.

         An IPv6 address must be a colon separated format, surrounded by
         brackets ('[' ASCII character 0x5B and ']' ASCII character
         0x5D), followed by a colon ':' (ASCII character 0x3A) and a
         decimal port number in ASCII.

         Values of this textual convention may not be directly useable
         ...  continue as before ...

* I THINK the sshtmLCDTable object can be removed after completion
  of this since the mapping is no longer needed.  The authentication
  credentials to be used I think can be safely pulled using the user@
  part of the transport address string in an implementation dependent
  way.  This is how current ssh implementations mostly work so I think
  it matches common current practice better than a separate mapping
  table.
  - It's possible the whole table could be removed, but leaving it in
    allows for deletion of active sessions and session activity
    monitoring.
  - But if we leave it, it should be noted that the current MIB has a
    sshtmLCDSessionID specified in the entry sequence, but the column
    doesn't actually exist in the table currently!

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