Re: [Isms] TBD secshell

[Jeffrey Hutzelman <jhutz at cmu.edu>]

--On Wednesday, January 28, 2009 06:44:50 PM -0500 David B Harrington 
<dbharrington at comcast.net> wrote:

> That would seem correct.

Top-posting makes it really hard to understand what you are replying to.

> - Section 5.1, we should say what the tmTransportAddress for incoming
> messages looks on the SSH server side: it's "address:port" form (not
> user at address:port).

Right.


> - Section 5.1: we need a better description of how tmSecurityName
> works on the SSH client side; IMHO the current behavior isn't quite
> right: Suppose a command generator sends a command with
> tmSecurityName="alice" and
> destTransportAddress="ahopkins at router1.example.net:1234". An SSH
> connection is opened and so on. When the command response is received,
> the current text in Section 5.1 would lead to having
> tmSecurityName="ahopkins" in the response -- a slightly unexpected
> response.

As I understand it, the request and response don't carry tmSecurityName, 
which is information passed between the TM and the upper layers.  The 
request carries a securityName, and if that is "alice" then the 
securityName in the response should also be "alice".

If a request is sent with securityName="alice" via an SSH transport using 
transport address "ahopkins at router1.example.net:1234", then what happens 
next depends on whether tsm or some other security model is used.  At the 
receiver, tmSecurityName is going to be "ahopkins", derived from the SSH 
user name.  If the security model in use is TSM, then TSM is going to look 
at that value, compare it to the securityName in the message, and reject 
the request because they do not match.  So, there will never be a response. 
If the security model in use is _not_ TSM, then the value of tmSecurityName 
is irrelevant.


> - Section 5.3, step 1: it would be *really* useful to add a note
> that to authenticate the server, the client usually stores
> (destTransportAddress, server host public key) pairs in
> implementation-dependent manner.

That depends on the key exchange method.  There's not always a host key 
involved, which is one of the reasons we declined to standardize this in 
detail.  Certainly a client needs to know, given a transport address, how 
to verify that an ssh connection opened to that address is actually 
connected to the correct peer.

-- Jeff
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms