Re: [Isms] wg last call followup - sshtm

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

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: "'Wes Hardaker'" <wjhns1 at hardakers.net>
Cc: <isms at ietf.org>
Sent: Friday, March 06, 2009 6:52 AM
Subject: Re: [Isms] wg last call followup - sshtm


> > DH> Should we add a version of this last paragraph in the security
> > DH> considerations? in the SSH introduction? maybe section 3.3 for
> > DH> notifications and proxy?
> >
> > I tried to put something like that in the security considerations
> > section for the document I posted yesterday.  Does it meet your
> needs?
>
> section 3.3:
> s/perform proxy/receive proxied messages/
>
> local access control is only done for the NO. It is not done for a
> proxied message, even if that proxied message is a notification.
>
> /connection can succeed/connection is available or can be opened/
>
> I recommend replacing the paragraph "Since outgoing messages may need"
> with a paragraph explaining a common use case, another describing
> client session establishment, and a third that discusses lifetime of
> the association.
>
> <old>
>    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  specifies an [...]
> </old>
> <new>
> Because naming policies might differ between administrative domains,
> many SSH client software packages support a user at hostname:port
> addressing syntax that operators can use to align non-equivalent
> account names. The  SnmpSSHAddress Textual Convention supports this
> common SSH notation.
>
> When this notation is used in an SnmpSSHAddress, the SSH client uses
> the "user" portion of the notation as the principal when establishing
> a session with the remote SSH server. The "user" portion may or may
> not match the tmSecurityName parameter passed from the security model.
> If no "user@" portion is specified in the SnmpSSHAddress, then the SSH
> client uses the tmSecurityName as the principal when establishing a
> session with the remote SSH server.
>
> The SnmpSSHAddress and tmSecurityName associated with an SSH session
> MUST remain constant during the life of the session. Different
> SnmpSSHAddress values (with different hostnames, "user@" prefix names
> and/or port numbers) will each result in individual SSH sessions.
> </new>
>
David

That looks excellent.

History tells me that I also need to see it in context since I sometimes then
find other sentences which need tweaking to bring them in line, and as I have
said, that takes me a bit longer to do; so agreement pro tem.

Tom Petch

> section 4.1.1
> I moved the lifetime association of session vs tmSecurityName into
> section 3.3, where the lifetime associaiton of SnmpSSHAddress is
> discussed, so the second sentence in section 4.1.1 is not necessary.
>
> possibly more later.
>
> >
> > DH> should we separate the notification case from the proxy
> > case, since
> > DH> proxy does not do access control?
> >
> > There are two separate cases:
> >
> > Clients that does access control before sending (NOs only)
> > Those that don't                                (everything else)
> >
> > I wouldn't spell out proxies generically since they're already
> lumped
> > into the other case.
>
> But in section 3.3, the NO and proxy are lumped together.
>
> > --
> > Wes Hardaker
> > Sparta, Inc.
> >
>
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms