Subject: [Isms] TBD secshell

From: "David B Harrington" <[email-masked]>
Date: Wed, 28 Jan 2009 17:57:58 -0500

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 - and that means the transport model needs to know which type
of operation. This violates the RFC3411 architecture established by
the SNMPv3 WG, and it has serious ramifications on other potential
models for various subsystems; it is not in scope to modify how those
other subsystems work.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, January 27, 2009 3:40 AM
> To: Dave Harrington
> Subject: [[email-masked]: Re: [Isms] 
> secshell-pre14]
> 
> David,
> 
> can you quickly explain the issues? I would like to move forward
with
> resolving them and push for a second last call.
> 
> /js
> 
> ----- Forwarded message from Juergen Schoenwaelder 
> <[email-masked]> -----
> 
> Date: Fri, 23 Jan 2009 17:01:30 +0100
> From: Juergen Schoenwaelder <[email-masked]>
> To: David Harrington <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Isms] secshell-pre14
> Message-ID: <[email-masked]>
> 
> On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote:
> 
> > This is an updated draft for secshell.
> > 
> > We still need work on 
> > 1) the processes for client versus server
> > 2) two ports
> > 
> > otherwise I think I have covered all the WGLC comments 
> 
> Thanks David for getting the edits done. Can you elaborate on the
open
> issues you see?
> 
>   - I think we reached consensus that we need two port 
> numbers - does this
>     address 2)?
> 
>   - I am not sure what "two processes for client versus server"
means.
> 
> Can the WG members please review the changes? It would be nice to
see
> feedback posted to the list (and feedback might very well be that
you
> are happy with the changes).
> 
> /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/>
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
> 
> ----- End forwarded message -----
> 
> -- 
> 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/>
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Jan 2009 18:10:08 -0500

--On Wednesday, January 28, 2009 05:57:58 PM -0500 David B Harrington 
<[email-masked]> wrote:

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Jan 2009 00:36:01 +0100

> sending a command or notification.  How do the existing transports do 

The SnmpUDPAddress always contains a port number and the same is true
for the formats defined in RFC 3419. So once you have an TAddress,
everything should be fine.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 28 Jan 2009 18:44:50 -0500

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@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="[email-masked]: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

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, January 28, 2009 6:10 PM
> To: David B Harrington; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] TBD secshell
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Jan 2009 18:59:30 -0500

--On Wednesday, January 28, 2009 06:44:50 PM -0500 David B Harrington 
<[email-masked]> wrote:

> That would seem correct.

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

> messages looks on the SSH server side: it's "address:port" form (not

Right.

> tmSecurityName="ahopkins" in the response -- a slightly unexpected

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 "[email-masked]: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.

> 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

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 28 Jan 2009 20:08:23 -0500

> Top-posting makes it really hard to understand what you are 
(sorry. I intended a really short reply.)

> at that value, compare it to the securityName in the message, 

I think there is no securityName in the message. 
Per TSM 4.2 3)
   3) Set securityParameters to a zero-length OCTET STRING ('0400').

> and reject 
> the request because they do not match.  

Per rfc3412, matching is done by message processing models, in the
prepareDataElements EOP. prepareDataElements takes only a
transportDomain, transportAddress, a wholeMsg and a message length as
input. It returns the sendPDUHandle that identifies the matching
request, which is used to direct the response to the appropriate
application.

The user@ feature is an SSHTM-specific feature, not a TSM feature. I
think SSHTM needs to pass a transportAddress for the response that
will match the one used in the request. This is symmetrical - it is
the SSHTM that takes the requested ahopkins@... transportAddress and
splits it into an address and a user name. SSHTM should put
"ahopkins@" and the address back together into a corresponding
transportAddress. Then the appropriate MPM can find the sendPDUHandle.

tmSecurityName is set to "alice" by TSM. SSHTM is the place where the
requested tmSecurityName "alice" is overridden, and ahopkins is chosen
as the user name. For an incoming response, SSHTM should determine
that the matching tmSecurityName for the response should be "alice",
not "ahopkins". This would seem to require an internal mapping table
that keeps track of all the alice-to-"ahopkins@" conversions done
going outward, and back-converting them on the way in. This might
require some type of transport-mapping-specific sendPDUHandle for
matching specific requests and responses.

dbh

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Jan 2009 22:08:24 -0500

> matching specific requests and responses.

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

The purpose of the username part of the transport address is to supply a 
value for the ssh username when we are originating an ssh connection in a 
situation where just using the security name won't work.  It shouldn't ever 
be compared or copied to anything else.  Most especially, the ssh username 
used to authenticate an incoming connection should _not_ make its way into 
the transport address, because that would cause it to be used when trying 
to send a message back, which would be the wrong thing.

This user@ thing is deliberately asymmetric, to accommodate an asymmetry in 
the SSH protocol.

Sorry, that's about all I can think about this for now; I haven't slept in 
a while and am not likely to be coherent for much longer, if I even still 
am.

-- Jeff