Subject: Re: [Isms] [[email-masked]: Re: secshell-pre14]

From: "David B Harrington" <[email-masked]>
Date: Thu, 5 Feb 2009 10:15:45 -0500

Hi,

The two ports issue is resolved. We now use two ports; the document
now asks IANA for two ports; and I think the use of two ports has no
effect on the EOP, because the choice of ports is done strictly by the
applications. I will, of course double-check this.

I think the EOP needs to be updated somewhat to address Pasi's
comments. I have not gone through the EOP to see just what needs
changing yet.

I think the EOP needs to be modified to make sure the message
processing model can match the outgoing transportaddress for a request
and the incoming transportaddress from the response, which is how the
MPM determines which application is waiting for a response. If the
request was sent using a [email-masked] address, then SSHTM uses parses
the address into a foo.com address and uses foo instead of the
tmsecurityname specified by the security model. When we get a response
from user at foo.com, we need to make the TM pass the MPM a transport
address of the [email-masked] format, and set the tmsecurityname to
match what was requested by the security model. I don't think it will
be terribly difficult to update the EOP, but I am not sure where the
TM stores the request-state (tmsecurityname) that it must restore when
it gets the response.

I'll try to get a revision posted within the next week.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, February 05, 2009 3:01 AM
> To: Dave Harrington
> Subject: Re: [[email-masked]: Re: 
> [Isms]secshell-pre14]
> 
> On Tue, Jan 27, 2009 at 09:39:33AM +0100, Juergen Schoenwaelder
wrote:
> > David,
> > 
> > can you quickly explain the issues? I would like to move 
> forward with
> > resolving them and push for a second last call.
> 
> David,
> 
> where are we with the open issues. You once mentioned:
> 
> > We still need work on 
> > 1) the processes for client versus server
> > 2) two ports
> 
> Then there was some discussion around the SSH username embedded in
an
> SSH TAddress. So we might have three issues still to solve but I am
> not 100% sure what the issues are. Can you help us by stating the
> issue clearly? I want to get this ISMS thing done; and it needs to
be
> good enough not perfect for Proposed Standard.
> 
> /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/>
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Feb 2009 16:40:14 -0800

DH> tmSecurityName is set to "alice" by TSM. SSHTM is the place where the
DH> requested tmSecurityName "alice" is overridden, and ahopkins is chosen
DH> as the user name.
[...]

JH> You're making this all too complicated, I think.

I agree!

Your (David H's) original message on the subject stated:

DH> I think the EOP needs to be modified to make sure the message
DH> processing model can match the outgoing transportaddress for a
DH> request and the incoming transportaddress from the response, which
DH> is how the MPM determines which application is waiting for a
DH> response.  If the request was sent using a [email-masked] address,
DH> then SSHTM uses parses the address into a foo.com address and uses
DH> foo instead of the tmsecurityname specified by the security
DH> model. When we get a response from user at foo.com, we need to make
DH> the TM pass the MPM a transport address of the [email-masked] format,
DH> and set the tmsecurityname to match what was requested by the
DH> security model.

There is only two cases to consider when talking about the SSHTM:

1) The SSHTM is acting as an SSH server.  IE, it was invoked from afar
   and in this case the securityName used within the SNMP system will
   match exactly the SSH user name.  Nothing confusing to behold.  When
   the SSHTM creates a transportAddress for the connection in order to
   pass it upward through the SNMPv3 stack it doesn't need to be
   anything more complex than the remote host address, ':' and port
   number.  The prepended SSH user name and '@' is not needed because
   it's equal to the securityName.

2) The SSHTM is acting as a client.  IE, it is initialized from the
   upper SNMPv3 stack and is handed a transportAddress to talk to.  It
   either will contain a "user@" type string or it won't.

   a) If it does not, again there is nothing much to consider as complex
      because the SSH user name will be identical to the securityName.

   b) If it does contain a "user@" type prefix, it should use that
      within the SSH protocol for identifying itself
      SSH-user-name-wise.  This is where your problem comes in, and this
      is the only case that you think is confusing (right?), in
      particular when a response comes back.

      So, when a response comes back across the SSH connection, the
      SSHTM has to hand the message upward with a transportAddress.
      Your statement above indicates that you think the transportAddress
      passed upward should be prepended with "user@" also.  That's fine
      by me, but I'm not sure why you think it's complex to get the
      right address created.

      The easiest solution is to cache the transportAddress that created
      the session and always use it when passing messages upward to
      through the SNMPv3 stack.  done.  It also assures that the upper
      SNMPv3 stack (specifically, your concerns with decisions in the
      MPM) aren't affected by reverse name lookups not matching the
      outgoing name, or IP addresses not matching DNS names, or whatever.

DH> I don't think it will be terribly difficult to update the EOP, but I
DH> am not sure where the TM stores the request-state (tmsecurityname)
DH> that it must restore when it gets the response.

In the same place it caches all the other information it needs to about
a given SSH connection.
-- 
Wes Hardaker
Sparta, Inc.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 9 Feb 2009 23:19:25 -0500

Hi,

I just sent out updates to all three documents. 
This problem is not addressed.
Can you tell me how to change the text?
I am not sure I understand the edits.

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Monday, February 09, 2009 7:40 PM
> To: Jeffrey Hutzelman
> Cc: David B Harrington; [email-masked]
> Subject: Re: TBD secshell
> 
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Feb 2009 13:29:43 -0800

>>>>> On Mon, 9 Feb 2009 23:19:25 -0500, "David B Harrington" <[email-masked]> said:

DBH> I just sent out updates to all three documents. 
DBH> This problem is not addressed.
DBH> Can you tell me how to change the text?
DBH> I am not sure I understand the edits.

Sure.  The only thing that needs to be added, IMHO, is a note saying the
address should be consistent during the life of a session.  i.e.:

5.1.  Procedures for an Incoming Message

   1.  The SSH Transport Model queries the SSH engine, in an
       implementation-dependent manner, to determine the
       transportAddress, the principal name authenticated by SSH, and a
       session identifier.  {+The transportAddress must be consistent
       during the life of a SSH session.+}

... jump to text after bullet 2 of 5.1 ...

   Prepare the transport parameters for the ASI:

      transportDomain = snmpSSHDomain

      transportAddress = the address {+of the SSH session that+} the message
      originated from, determined in an implementation-dependent way

... jump to bullet 2 of section 5.3 ...

   2.  Using tmTransportAddress, the client will establish an SSH
       transport connection using the SSH transport protocol,
       authenticate the server, and exchange keys for message integrity
       and encryption.  {+The transportAddress associated with a session
       MUST remain constant during the lifetime of the SSH session.
       Implementations may need to cache the transportAddress passed to
       the openSession API for later use when performing incoming
       message processing (see section Section 5.1).+}

-- 
Wes Hardaker
Sparta, Inc.