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

["tom.petch" <cfinss at dial.pipex.com>]

On LCD, this is architected in RFC3411.

The LCD is defined as sets of configuration information needed by models and
applications (s3.4.2).

The cache is introduced so that if the LCD is changed, then the same security
information is still available for a Response as was used in the Request (s
A.1.5).

So no, the (securityStateReference at least) cache is quite separate from the
LCD.  tmsm likens the tmStateReference to the existing RFC3411 cache so by
implication, it too should be distinct from the LCD.

Tom Petch

----- Original Message -----
From: <Pasi.Eronen at nokia.com>
To: <isms at ietf.org>
Sent: Thursday, November 27, 2008 12:56 PM
Subject: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5

> 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

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