Subject: [Isms] Proposed text changes for the secshell draft

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 Mar 2009 09:26:29 -0800

I've hacked up the secshell draft to fix the issue with respect to the
need for a consistent tmSecurtyName.  If nothing else, I think this
discussion has been a good one because it's highlighted that the
tmSecurityName must be consistent for the life of the session and we
didn't state that clearly in the -14 draft.  It was roughly stated in
the text in some obscure ways that I'm not at all sure that
implementations would have gotten it right.

Here's a URL for the diffs (obviously: ignore the not-relevant changes
introduced by date changes, etc):

http://tools.ietf.org//rfcdiff?url1=http://www.hardakers.net/temp/draft-ietf-isms-secshell-14.txt&url2=http://www.hardakers.net/temp/draft-ietf-isms-secshell-15wes.txt
-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 11:13:38 +0100

Wes

I tried the URL and got http 404.  Something of a relief as I do not relish the
prospect of another day spent reverse engineering EOPs:-)   What I would prefer
is rough consensus from everyone on the issues we have discussed, to whit:

1) the securityName used for a transaction in the local SNMP engine may not be
the same as that used in the remote engine; this may occur when e-mail format
addresses ([email-masked]:port) are used

2) the securityName remains the same for the duration of a transaction (message
sent and message(s) received) within a single engine

3) the securityName is not authenticated within a Notification Originator

4) the transportAddress used in the ASIs to establish a session must appear
unchanged in the ASIs for all subsequent messages over that session

5) the tmTransportAddress as passed in tmState may vary between the outgoing and
incoming messages of a transaction; this may occur when e-mail format addresses
are used

6) tmSessionID uniquely identifies an SSH session within an engine both for
current sessions and for sessions that have existed recently or may be setup in
the near future, remains unchanged for the duration of that session and may be
used anywhere in the engine where it is necessary to identify a session

7) when an application uses securityName+e-mail format transportAddress with
transportDomain snmpSSHDomain, then
[email-masked]:request
[email-masked]:notify
[email-masked]:request
bob+example.com:request
will result in four separate SSH sessions

8) the transportAddress MUST include a port; omitting the port is an error

Agreeing points in this format makes it much easier for me to verify that EOPs
do what we want, and to propose amended text as and when they do not eg all
references to example.com MUST be changed to example.com:port:-)

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 03, 2009 6:26 PM
Subject: [Isms] Proposed text changes for the secshell draft

> introduced by date changes, etc):
http://tools.ietf.org//rfcdiff?url1=http://www.hardakers.net/temp/draft-ietf-ism
s-secshell-14.txt&url2=http://www.hardakers.net/temp/draft-ietf-isms-secshell-15
wes.txt
> --
> Wes Hardaker
> Sparta, Inc.
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 04 Mar 2009 07:35:19 -0800

>>>>> On Wed, 4 Mar 2009 11:13:38 +0100, "tom.petch" <[email-masked]> said:

tp> I tried the URL and got http 404.

Arg!  but I can get to them directly and it worked yesterday.

Try this one instead:

  http://www.hardakers.net/temp/ismsdiff.html

and if that fails (probably due to DNS changes) try:

  http://www.ws6z.com/ismsdiff.html

tp> 1) the securityName used for a transaction in the local SNMP engine
tp> may not be the same as that used in the remote engine; this may
tp> occur when e-mail format addresses ([email-masked]:port) are used

This has already been well discussed and consensus was agreed upon.

tp> 2) the securityName remains the same for the duration of a
tp> transaction (message sent and message(s) received) within a single
tp> engine

The changes I proposed should make this more clear.

tp> 3) the securityName is not authenticated within a Notification Originator

It never was in any SM.  The V3 architecture never allows it to be.  The
VACM is checked before it's authenticated.  The connection, however, has
to operate as expected with the expected keys being used on the other
side (be it the keys are USM secret keys or SSH/DTLS public/private
keys).  If the other side doesn't have the right keys based on your
configured transport address, the notification won't get delivered
because the connection will fail.

tp> 4) the transportAddress used in the ASIs to establish a session must appear
tp> unchanged in the ASIs for all subsequent messages over that session

True and documented.  And probably even more clear in my proposed text.

tp> 5) the tmTransportAddress as passed in tmState may vary between the
tp>    outgoing and
tp> incoming messages of a transaction; this may occur when e-mail
tp> format addresses are used

tp> 6) tmSessionID uniquely identifies an SSH session within an engine both for
tp> current sessions and for sessions that have existed recently or may
tp> be setup in the near future, remains unchanged for the duration of
tp> that session and may be used anywhere in the engine where it is
tp> necessary to identify a session

session ID's are unique, I agree.  In the DTLS draft I actually tried to
put very careful wording describing their usage.

Time doesn't matter too much in an implementation.  The important thing
is that at any given time a session ID must be unique.  That means that
even if the session closed but a reference exists elsewhere in the
software to it, it can't be reused.  So I disagree with the fuzzy
wording "or maybe be set up in the near future".  The issue is with
existing references.  Once all references have been cleared, the session
ID can be safely reused.

tp> 7) when an application uses securityName+e-mail format transportAddress with
tp> transportDomain snmpSSHDomain, then
tp> [email-masked]:request
tp> [email-masked]:notify
tp> [email-masked]:request
tp> bob+example.com:request
tp> will result in four separate SSH sessions

Correct, and I believe the document already specifies this.  The
modified one hopefully makes it more clear.

You might add just example.com:request to your list to make it more
complete if you like.

tp> 8) the transportAddress MUST include a port; omitting the port is an error

That's already documented in the TC, but I agree.

tp> Agreeing points in this format makes it much easier for me to verify
tp> that EOPs do what we want, and to propose amended text as and when
tp> they do not eg all references to example.com MUST be changed to
tp> example.com:port:-)

That's a good point.  The examples need to include a port number.

Other than that, though, I think you're re-iterating what the working
group has already agreed upon.  So, with your new found consistency in
place do you see any issues with the text in my proposed modifications?
-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 04 Mar 2009 13:08:43 -0500

--On Wednesday, March 04, 2009 11:13:38 AM +0100 "tom.petch" 
<[email-masked]> wrote:

> 5) the tmTransportAddress as passed in tmState may vary between the
> outgoing and incoming messages of a transaction; this may occur when
> e-mail format addresses are used

Why would this ever happen?  On an incoming SSH connection, the 
tmTransportAddress is constructed from the actual IP address and port of 
the remote peer and will never include a username part.  The transport 
address used for sending a reply, if any, will always be the same as the 
one from which the incoming message was received.

On an outgoing SSH connection, the transport address is provided by the 
application.  Any incoming messages received on that connection should be 
given the same tmTransportAddress that was used to establish the 
connection.  There is no magic here -- when you open a TCP connection, you 
assume any data received on it came from the peer to whom you opened the 
connection; you don't violate layering and examine the IP packets carrying 
every octet.

As for the test, I fully agree with Wes's replies.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Wed, 4 Mar 2009 20:28:35 +0100

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "tom.petch" <[email-masked]>; "Wes Hardaker" <[email-masked]>;
<[email-masked]>
Subject: Re: [Isms] Proposed text changes for the secshell draft

> connection; you don't violate layering and examine the IP packets carrying

Jeff

It happens because EOPs say it happens, and I do not see a problem with it.

In a Command Generator, securityName alice, transportAddress
[email-masked]:port, application sends a request.

As per sshtm EOP 5.1.2)
" If
      the session is a client session, and openSession used a
      tmTransportAddress of the "[email-masked]" format, the
      transportAddress passed in the receiveMessage ASI MUST match the
      "[email-masked]" tmTransportAddress used to open the session;
      this will be different than the address reported by SSH for the
      incoming message.)

and

"tmTransportAddress = the address the message originated from,
         determined in an implementation-dependent way from SSH."

which together tell me that [email-masked]:port is passed as transportAddress
in the ASI while example.com:port sans bob goes in tmTransportAddress and the
cache off to tsm.

That is what the wording tells me; I do not have a problem with this - tsm s.5
makes no use of tmTransportAddress - but wanted to check that this was everyone
else's expectation, that this is not another surprise.

Thanks for checking them all

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 04 Mar 2009 16:45:43 -0500

--On Wednesday, March 04, 2009 08:28:35 PM +0100 "tom.petch" 
<[email-masked]> wrote:

> To: "tom.petch" <[email-masked]>; "Wes Hardaker"
> <[email-masked]>; <[email-masked]>
>> connection.  There is no magic here -- when you open a TCP connection,
>> you assume any data received on it came from the peer to whom you opened
>> the connection; you don't violate layering and examine the IP packets
>> carrying every octet.
>>
>
> Jeff
>

This is nonsensical, and so needs to be fixed.  SSH does not report an 
address for an incoming message; it doesn't even deal in messages at the 
layer at which we talk to it.  On an incoming connection, SSH can generally 
tell you the address the client connected from.  This is generally reported 
once, not every time you read a byte.  On an outgoing connection, it's 
generally your problem to keep track of what you connected to.  Again, SSH 
doesn't tell you every time you read a byte that it came from the server 
you connected to; remembering that is your problem.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2009 10:50:35 +0100

> will result in four separate SSH sessions

I do not know what you mean with the notations
[email-masked]:request so I can't tell I agree.
 
> 8) the transportAddress MUST include a port; omitting the port is an error

Why?

/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: "David Harrington" <[email-masked]>
Date: Thu, 5 Mar 2009 08:54:03 -0500

Hi,

> > will result in four separate SSH sessions

Not neccessarily.

> > [email-masked]:notify

The transport model does not know the difference between a request and
a notification. If the two addresses you provide are [email-masked]
and [email-masked], then it will presumably use the same session, not
create a new one.

However, if addresses require ports, and if the addresses provided are
[email-masked]:161 and [email-masked]:162, then yes, these would be
different addresses and require different sessions. Maybe your use of
":request" and ":notify" was meant to indicate the appropriate port#,
not the message type.

Have you checked the EOP that [email-masked]:request and
bob+example.com:request would result in different sessions? I haven't
looked yet, and this one might not be clear.

dbh

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 Mar 2009 06:34:50 -0800

>>>>> On Thu, 5 Mar 2009 08:54:03 -0500, "David Harrington" <[email-masked]> said:

DH> Have you checked the EOP that [email-masked]:request and
DH> bob+example.com:request would result in different sessions? I haven't
DH> looked yet, and this one might not be clear.

Can you please check the modified copies I posted late yesterday instead?
-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 Mar 2009 06:40:31 -0800

>>>>> On Wed, 04 Mar 2009 16:45:43 -0500, Jeffrey Hutzelman <[email-masked]> said:

>> this will be different than the address reported by SSH for the

JH> This is nonsensical, and so needs to be fixed.  SSH does not report an
JH> address for an incoming message; it doesn't even deal in messages at
JH> the layer at which we talk to it.

The lower level stack will report the address.  You're right that the
SSH protocol doesn't but the APIs do...  The question is, what is the
wording that it should be changed to.

  "...reported by the API for the incoming message."

  "...reported by the networking infrastructure for the incoming message."

  "...reported by the protocol stack for the incoming message."

...

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 5 Mar 2009 11:25:58 -0500

Hi,

"...reported by the protocol stack for the session carrying the
incoming message." ?

"the remote address for the SSH session carrying the incoming
message." ?

When we act as the server and accept SSH session creation from a
client, we would want to know the address of the client. But once
established, the address of the session would not change. In an
implementation-dependent manner, we need to get that, presumably from
the SSH implementation, since it is SSH that negotiates the transport
session.

For incoming messages, regardless of SNMP message type, SSHTM should
lookup the remote address for the SSH session and report that up the
"SNMP stack". For a remote client, that address would presumably never
be in the "bob@" format. 

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Thursday, March 05, 2009 9:41 AM
> To: Jeffrey Hutzelman
> Cc: [email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Mar 2009 21:22:01 +0100

---- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'tom.petch'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 05, 2009 2:54 PM
Subject: RE: [Isms] Proposed text changes for the secshell draft

> looked yet, and this one might not be clear.

David,

Yes, my reading of the EOPs in sshtm-14 is that this last with the bobs will
result in two sessions.  I wanted to check that this is what is intended since
for me it slightly surprising.

On the question of port, I assume, as in my other e-mail to Juergen, that ports
are required, basically because he, Juergen said so to you, David, so you could
write the EOPs in February.  And given two ports, I do not see any other way.

Hence, assuming :request and :notify are different numeric values, then the EOPs
say there will be two sessions.  I was going to say x161 and x162 except that
one of my outstanding comments is that IANA may take your request to be
specifying hexadecimal so I used English but that is even less clear:-(

Again, not quite what might be expected, especially that notifications and
requests will always use different sessions so I want to check that this is what
is wanted from the EOPs before I read the latest version from Wes(which  takes
me a good half day and so will be on Friday).

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Thu, 5 Mar 2009 21:20:19 +0100

Juergen

Top posting on both your points.

'Omitting the port is an error' comes from last month, when,  after we had
agreed that sshtm would use two ports, dbh said he could not write the EOPs
because he did not know how sshtm knew which one to use whereat you, Juergen,
replied
"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."
and indeed that is how I read the TC, user@ is optional, port is not, in sshtm

And I see nothing about using a default port if one is not specified.

So, I think from this that transportAddress will always include a port even
though this is not specified in the body of the I-Ds, only implicit in the TC.

If it does not, then I do not know how sshtm/ssh know which port to use.

On the other point, my notation is securityName + transportAddress so I am
saying that if an CG application uses
securityName bob transportAddress  [email-masked]:request
and later
securityName bob transportAddress  example.com:request
then this will send traffic over two separate ssh sessions.

This is what I read in the EOPs and indeed, it is quite hard to do anything else
assuming that responses must come back over the same session as the request with
the same parameters to the application.  But I wanted to check that this was not
a surprise to some of us.  If this is not intended, then what is?  because we
have
more work to do.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 Mar 2009 13:49:49 -0800

>>>>> On Thu, 5 Mar 2009 21:20:19 +0100, "tom.petch" <[email-masked]> said:

tp> Top posting on both your points.

I'm inline-posting in yours :-)

tp> indeed that is how I read the TC, user@ is optional, port is not, in
tp> sshtm

That's definitely how the current TC is worded (and should be).  They're
a hostname followed by a ':' and a decimal port number.

I think we are all in agreement about this at this point.

tp> So, I think from this that transportAddress will always include a port
tp> even though this is not specified in the body of the I-Ds, only
tp> implicit in the TC.

I actually think (whether it was intentional or not) this is a good
thing.  The EOPs should generically say "get the addressing information
from the passed tmTransportAddress so that future TCs can be written to
support IPv16 without rewriting the EOPs.

tp> On the other point, my notation is securityName + transportAddress so
tp> I am saying that if an CG application uses securityName bob
tp> transportAddress [email-masked]:request and later securityName bob
tp> transportAddress example.com:request then this will send traffic over
tp> two separate ssh sessions.

That is true.  It could be rewritten to check for string matches, but
honestly I think that would only make the wording even more confusing to
account for that case.  All other cases where tmSecurityName != user[@]
MUST result in a different sessions for each (for security assurances).

It'd be a pain to write not just because of the string comparison, but
also because the transportAddress that gets handed back up would need to
match the request that went out so you didn't confuse the application.
It'd be easier, implementation and documentation-wise, to mandate that
the transportAddress is always identical or else a new session is created.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Mar 2009 17:00:08 -0500

> looked yet, and this one might not be clear.

I believe the notation tom is using here is "securityname+transportaddress" 
with the transport address written as "[user@]host:port", as specified.  In 
this model, yes, the tour examples given result in distinct sessions, 
because none of them have both the same securityName and the same 
transportAddress.

The fact that "[email-masked]:request" and "bob+example.com:request" 
will result in making SSH connections to the same host and port and using 
the same SSH username does _not_ make the SNMP transport addresses the same 
-- "[email-masked]:request" and "example.com:request" are still different.

I believe the EOP are clear on this point.  Particularly, section 5.2, step 
4 says the following:

   4.  If there is no existing session corresponding to the
       tmTransportAddress and tmSecurityName, then call openSession()
       with the tmStateReference as a parameter.

I do believe there are some ambiguities in that section, however.  Wes's 
recent proposed changes address some of these, but not all:

- The EOP are quite clear on what happens if there is _not_ an
  existing session, in steps 3 and 4, but nowhere is it stated
  that if there _is_ an existing session, it should be used.
  Particularly...

  + There does not appear to be any step which verifies that
    destTransportDomain and destTransportAddress are the same
    as the tmTransportDomain and tmTransportAddress obtained
    via the tmStateReference.

  + There does not appear to be any step which verifies that
    the destTransportDomain and tmTransportDomain are SSHTM.
    Is such a check required?

  + In step 3, if tmSameSecurity is true, we should search for
    a session which matches tmSessionID.  If no such session is
    found, we should fail as currently described.  If a session
    _is_ found, and does not match the tmTransportAddress and
    tmSecurityName, then we should also fail.  If a session is
    found and matches, then we skip to step 5.  Wes's changes
    check tmSecurityName, but not tmTransportAddress.

  + In step 4, if tmSameSecurity is not true, we should search
    for a session which matches the tmTransportAddress and
    tmSecurityName, and if one is found, use it.  If no session
    is found, openSession is called as currently described.

  + Step 4(2) records the destTransportDomain, destTransportAddress,
    and tmsessionID, but not the tmSecurityName.  We really should
    be recording this in the session cache if we're going to look
    at it later, and additionally, we need it if we're going to
    use it to populate a tmStateReference cache as described in
    the EOP in section 5.1.  The new step 7 added by Wes's changes
    may be sufficient to address this.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2009 23:01:41 +0100

> If it does not, then I do not know how sshtm/ssh know which port to use.

Good. So I got things right back then when I wrote my response to dbh.
 
> This is what I read in the EOPs and indeed, it is quite hard to do
> anything else assuming that responses must come back over the same
> session as the request with the same parameters to the application.
> But I wanted to check that this was not a surprise to some of us.
> If this is not intended, then what is?  because we have more work to
> do.

So are you saying we are in agreement?

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 6 Mar 2009 10:30:39 +0100

---- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Juergen Schoenwaelder" <[email-masked]>; "Wes
Hardaker" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 05, 2009 10:49 PM
Subject: Re: Proposed text changes for the secshell draft

> the transportAddress is always identical or else a new session is created.

Yes, I believe we are in agreement:-)

I am not lookng for any changes to the written text EXCEPT that whereever we
give an example of a (tm)transportAddtress we always include the port which most
if not all of the current text does not do.  This was why I raised it; a less
experienced reader might see all those addresses with no port and think that no
port was an option and struggle with the TC which says otherwise (don't know
why, SMIv2 is a superb modelling language:-)

And including the port is something you said you would do in your first response
to my list of eight points.  So yes, all looks good on that.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Fri, 6 Mar 2009 10:34:11 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Wes Hardaker" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 05, 2009 11:01 PM
Subject: Re: [Isms] Proposed text changes for the secshell draft

> So are you saying we are in agreement?

Yes, but as I say to Wes, I want all our examples of (tm)transportAddress to
include a port lest this mislead; and Wes has already agreed to do this.  I was
not seeing any great need to add explicit text about the port being required but
would not object if it was there.

Tom

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Mar 2009 15:40:14 -0800

>>>>> On Thu, 05 Mar 2009 17:00:08 -0500, Jeffrey Hutzelman <[email-masked]> said:

JH> - The EOP are quite clear on what happens if there is _not_ an
JH> existing session, in steps 3 and 4, but nowhere is it stated
JH> that if there _is_ an existing session, it should be used.
JH> Particularly...

Your issues have been fixed in my next set of text...

JH> + There does not appear to be any step which verifies that
JH> the destTransportDomain and tmTransportDomain are SSHTM.
JH> Is such a check required?

No, we sort of decided it would be an implementation issue if code had
even gotten that far and such trivialities didn't need to be documented
in the EOP (you likely have bigger problems).
-- 
Wes Hardaker
Sparta, Inc.