Subject: [Isms] Proposed SSHTM document modifications: take 2

From: Wes Hardaker <[email-masked]>
Date: Wed, 04 Mar 2009 17:32:13 -0800

I've again modified the SSH document to take into account more of the
discussion from the last 24 hours or so.  The user@ text is discussed in
section 3 now, with more information about the motivations and usage
model.  The step wording has been cleaned up a bit more since my last
post.  And finally, there is some new text in the security
considerations to discuss the issues as well (which I rewrote at least 3
times trying to make it sound ok).

Diff Comparison:
  http://www.hardakers.net/temp/isms-ssh.html

Full draft:
  http://www.hardakers.net/temp/draft-ietf-isms-secshell-15wes.2.txt

-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2009 19:12:39 +0100

> times trying to make it sound ok).

Looks good. One small thing:

   Since outgoing messages may need to be sent to a different SSH
   principal name that does not or can not directly match the SNMPv3
   security name, the SnmpSSHAddress Textual Convention specifies an
   optional SSH principal identity field to this mapping to occur.

I suggest to replace "sent to" with "using" since the principal is
really used to authenticate the NO to the NR and not the other way
round.

/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: Wes Hardaker <[email-masked]>
Date: Thu, 05 Mar 2009 12:09:07 -0800

>>>>> On Thu, 5 Mar 2009 19:12:39 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> I suggest to replace "sent to" with "using" since the principal is
JS> really used to authenticate the NO to the NR and not the other way
JS> round.

Changed.  Thanks!
-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 6 Mar 2009 14:00:13 +0100

Wes

I think that dbh's text is better for section 3 but ....
I do see it as too late.  I want it at the end of 3.1.4 under SSH Subsystems,
you place it under Notifications.

I see this as a symptom of an unresolved issue.  Jeff sees the address format as
about NOs; dbh, and I agree with him, sees it as a general feature which CGs can
also. I am unclear where you stand, but for me, this means that it must be in
3.1.4 not buried under Notifications.  We need a good reason to say it must not
be used by a CG, whether that is done explicitly or implicitly

3.3 has a reference to notification generators, should be Notification
Originators

4.1.1 uses 'consistent' which to me is the wrong word.  Consistent with what?
the first law of Thermodynamics? sorry, facetiousness:-(  What I think that this
passage must convey is that it must not change, that once supplied to open a
session then
a) for outbound messages, client or server, the same value will invoke the same
session (pace transportAddress) and a different value will invoke a different
session
b) for inbound messages, client or server, this will be the only value ever
supplied as part of the session identifier.

We may not need to say all of this - well I would - but 'consistent' does not
convey enough of it.

5.1 I have the same comment; 'consistent' is not the right word.

The rest of section 5 is a struggle for me.  5.3 7) looks spot on but I think
that this is gainsayed by 5.1 2) and that 5.1 needs a rethink as a consequence.

5.1 1) should cover the client case, the problematic one, saying in essence
that, as per 5.3 7), the value of tmSecurityName that was used when the session
was opened MUST be inserted into tmSecurityName in the cache entry now being
created; this value is obtianed in an implementation-dependent way.  And then
scrap 5.1 2).

And if implementers cannot work out how to design a cache to do that, they
should not be implementing:-)  No more details needed.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 05, 2009 2:32 AM
Subject: [Isms] Proposed SSHTM document modifications: take 2

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Mar 2009 06:59:01 -0800

>>>>> On Fri, 6 Mar 2009 14:00:13 +0100, "tom.petch" <[email-masked]> said:

tp> I think that dbh's text is better for section 3 but ....  I do see
tp> it as too late.

Well, dbh is free to rewrite it.  He generally does that with everyones
text before he publishes it ;-)

tp> I see this as a symptom of an unresolved issue.  Jeff sees the
tp> address format as about NOs; dbh, and I agree with him, sees it as a
tp> general feature which CGs can also.

I'd be more than happy to make it generic.  CGs shouldn't be prohibited
from using it.

We were talking about multiple things:

1) information about it, which is generic.
2) motivations for it, which primarily has been from the NO perspective

So splitting it up would be fine with me to meet both needs.

tp> 3.3 has a reference to notification generators, should be Notification
tp> Originators

Good point

tp> 4.1.1 uses 'consistent' which to me is the wrong word.  Consistent
tp>       with what?

I don't find it unclear, but adding a few words wouldn't hurt.  Constant
may be a better word.  It has to be constant based on when the session
was opened, regardless from which side it was opened from.

I'll talk to David about whether he wants to take the next pass at
incorporating the comments from you and Jeff.

-- 
Wes Hardaker
Sparta, Inc.