Re: [Isms] TBD secshell

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

Hi,

That would seem correct. Regardess of operation, if the connection is
initiated by the sender, the sender is a client. And that means the
application MUST provide the port in the transportAddress. If it is an
incoming request, the correct port is stored the securityStateRef. If
it is a response or report, the correct port is extracted from the
securityStateRef.

There may still be some work TBD to clarify EOP on incoming versus
outgoing processing for SSH support. On 11/27, Pasi raised some
specific questions about the EOP in revision 13 that need to be
addressed. Here are a couple, but not all the points he raised: 

- 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).

- 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.

- 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. 


dbh

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu] 
> Sent: Wednesday, January 28, 2009 6:10 PM
> To: David B Harrington; j.schoenwaelder at jacobs-university.de; 
> isms at ietf.org
> Cc: jhutz at cmu.edu
> Subject: Re: [Isms] TBD secshell
> 
> --On Wednesday, January 28, 2009 05:57:58 PM -0500 David B
Harrington 
> <dbharrington at comcast.net> wrote:
> 
> > Hi,
> >
> > The EOP need to be updated to deal with two ports.
> >
> > There is a potential issue I have not yet researched; the
transport
> > model establishes the
> > connection. But the transport model does not know the 
> operation type.
> > So how will it know which port to use? Of course, we have 
> the port in
> > the transport address, so it can just work from that basis, but I
am
> > not sure it knows what it needs to know to do that. In one case it
> > needs to act as an ssh client; in the other it needs to act as a
> > server
> 
> No.  The entity that is establishing a new ssh session is 
> always the ssh 
> client.
> 
> The more interesting question is which default port to use if 
> one is not 
> specified in the transport address, as this depends upon 
> whether one is 
> sending a command or notification.  How do the existing 
> transports do this?
> 
> -- Jeff
> 

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