[Isms] Comments about draft-ietf-isms-secshell-13, Section 5

[<Pasi.Eronen at nokia.com>]

Comments about draft-ietf-isms-secshell-13, Section 5:

Overall: I think we're *almost* done -- I think we need to fill in
some minor details, but those shouldn't affect the overall processing.

- The distinction between tmStateReference cache and LCD is a bit
unclear -- do these actually mean the same thing? For example, Section
5.3 talks about creating an LCD entry when the SSH client has
established a connection (step 7), and Section 5.2 checks if the LCD
entry exists (step 2).

But there's no text saying that the SSH server ever creates any LCD
entries -- so step 2 of Section 5.2 would always fail when
e.g. sending command responses. That's clearly not the intention.
Section 5.1 does talk about creating a tmStateReference cache --
perhaps it should talk about creating a LCD cache entry? Or perhaps
Sections 5.2/5.3 should talk about tmStateReference cache? Or perhaps 
we need to describe opening a session also from SSH server's point 
of view? (Section 5.3 talks only about what the SSH client does, and 
says basically nothing about what the server does.)

- Section 5.2 (step 2) says the LCD entry is indexed by
(destTransportAddress,tmSecurityName) but 5.3 (step 7) says it's
(destTransportAddress,tmStateReference). Probably the former is
correct? (but in that case, there's no need to store tmSecurityName 
in the entry itself, so step 7 of 5.3 may need some editing)

- 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.  (Otherwise, this text gets difficult
to understand.)

- Section 5.1: we shouldneed 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.  Would it be better to extract the tmSecurityName from the
"LCD cache entry" (or whatever is the right term) that was created
when the client first established the session?

- Section 5.1, on related note, on SSH client side, the
tmTransportAddress in incoming messages should probably also be
extracted from the "LCD cache entry", so that it's exactly the same as
was used for the outgoing message (that triggered creating the SSH
connection).

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

- Typos:
Section 5.3, "tmSecurtityName"
Section 5.4, "sever"
Several sections (including the MIB): "sshtmSessionUnavaliableSubsystems"

Best regards,
Pasi
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms