Re: [Isms] TBD secshell

["David B Harrington" <dbharrington at comcast.net>]

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

> -----Original Message-----
> From: Wes Hardaker [mailto:wjhns1 at hardakers.net] 
> Sent: Monday, February 09, 2009 7:40 PM
> To: Jeffrey Hutzelman
> Cc: David B Harrington; isms at ietf.org
> Subject: Re: TBD secshell
> 
> 
> 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 user at foo.com 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 
> user at foo.com 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.
>