Re: [Isms] Notes on an SSH Document Review
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] Notes on an SSH Document Review
--On Friday, August 29, 2008 09:24:28 AM -0700 Wes Hardaker
<wjhns1 at hardakers.net> wrote:
\> - Section 3.1.2, paragraph startingc "The SSH Transport Model"
> * I'm not sure of the reasoning behind such strong
> wording to say that transport level protections
> offered to the packets "SHOULD NOT be exposed to the
> SSH Transport Model". I'm not sure how this helps
> interoperability and I think some implementations may
> benefit from exposing that detail so they could
> provide a configuration system at the TM level. I
> think MAY NOT would be more appropriate.
I don't object to your intent, but I think the phrase MAY NOT should be
avoided at all costs. It is logically equivalent to MAY, but many people
will read it as meaning the same thing as MUST NOT. Let's just rewrite
"SHOULD NOT be" as "are not" or even "normally are not". In any case, I
think the purpose of this text is not so much to promote interoperability
but to prevent people down the line from second-guessing our decision to
leave the details of SSH to SSH and not get SNMP involved in them.
> - Section 3.1.3, DISCUSS in 2nd paragraph
> * The question is: is this paragraph needed. I don't
> think it is. I think it's beyond scope to discuss the
> details of how SSH needs to do it's authentication. The
> first paragraph nicely states that we're relying on SSH
> authentication and tFrom isms-bounces at ietf.org Fri Aug 29 11:09:04 2008
Return-Path: <isms-bounces at ietf.org>
X-Original-To: isms-archive at megatron.ietf.org
Delivered-To: ietfarch-isms-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 2F0693A6A7B;
Fri, 29 Aug 2008 11:09:04 -0700 (PDT)
X-Original-To: isms at core3.amsl.com
Delivered-To: isms at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 604BC3A6A53
for <isms at core3.amsl.com>; Fri, 29 Aug 2008 11:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.274
X-Spam-Level:
X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kb9sLIUWThqo for <isms at core3.amsl.com>;
Fri, 29 Aug 2008 11:09:01 -0700 (PDT)
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU
[128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 2D3443A6A7B
for <isms at ietf.org>; Fri, 29 Aug 2008 11:09:01 -0700 (PDT)
Received: from atlantis.pc.cs.cmu.edu (host-66-202-66-11.har.choiceone.net
[66.202.66.11]) (authenticated bits=0)
by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id
m7TI8ujC001308
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 29 Aug 2008 14:09:00 -0400 (EDT)
Date: Fri, 29 Aug 2008 13:35:08 -0400
From: Jeffrey Hutzelman <jhutz at cmu.edu>
To: Wes Hardaker <wjhns1 at hardakers.net>, ISMS WG <isms at ietf.org>
Message-ID: <4AA78285207D926E04B40286 at atlantis.pc.cs.cmu.edu>
In-Reply-To: <200808291624.m7TGOZ5d028512 at toasties.srv.cs.cmu.edu>
References: <200808291624.m7TGOZ5d028512 at toasties.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Disposition: inline
Cc: jhutz at cmu.edu
Subject: Re: [Isms] Notes on an SSH Document Review
X-BeenThere: isms at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>,
<mailto:isms-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/isms>
List-Post: <mailto:isms at ietf.org>
List-Help: <mailto:isms-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>,
<mailto:isms-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: isms-bounces at ietf.org
Errors-To: isms-bounces at ietf.org
--On Friday, August 29, 2008 09:24:28 AM -0700 Wes Hardaker
<wjhns1 at hardakers.net> wrote:
\> - Section 3.1.2, paragraph startingc "The SSH Transport Model"
> * I'm not sure of the reasoning behind such strong
> wording to say that transport level protections
> offered to the packets "SHOULD NOT be exposed to the
> SSH Transport Model". I'm not sure how this helps
> interoperability and I think some implementations may
> benefit from exposing that detail so they could
> provide a configuration system at the TM level. I
> think MAY NOT would be more appropriate.
I don't object to your intent, but I think the phrase MAY NOT should be
avoided at all costs. It is logically equivalent to MAY, but many people
will read it as meaning the same thing as MUST NOT. Let's just rewrite
"SHOULD NOT be" as "are not" or even "normally are not". In any case, I
think the purpose of this text is not so much to promote interoperability
but to prevent people down the line from second-guessing our decision to
leave the details of SSH to SSH and not get SNMP involved in them.
> - Section 3.1.3, DISCUSS in 2nd paragraph
> * The question is: is this paragraph needed. I don't
> think it is. I think it's beyond scope to discuss the
> details of how SSH needs to do it's authentication. The
> first paragraph nicely states that we're relying on SSH
> authentication and the next he next 2 are really just examples
> of stuff that may or may not be used. That being said,
> I don't mind if it stays either. But to answer the
> DISCUSS: no I don't think it's needed.
Agree. These paragraphs don't need to be here.
> - Section 3.1.4: DISCUSS
> * I don't think we need to go into gory detail here
> either.
I don't think we need this section at all. The SSH TM doesn't support or
not support any particular SSH encryption or integrity methods. SSH
supports what it supports, and SSHTM supports SSH. This is equivalent to
an application that runs over TCP saying it supports PMTU discovery, slow
start, fast recovery, and so on. Those things are transparent to anything
that runs above the layer boundary.
I'm almost inclined to say the same thing about section 3.1.3, but not
quite. The difference is that authentication methods _are_ visible above
the layer boundary, because you have to provide credentials. And so, the
set of authentication methods that can be used with SSHTM is limited by the
kinds of credentials it can provide.
> - Section 3.1.6: Subsystem naming
> 2. Re: DISCUSS: I do think we need two different
> subsystem names though. For management stations that
> are running an agent, it's highly likely that they
> are also running a notification receiver and the ssh
> subsystem destination shouldn't be the same. If we
> end up assigning SNMP-over-SSH specific ports for
> these services, then the susbsystem name really
> doesn't matter. If, however, we end up reusing 22 we
> certainly need one ssh subsystem name for an agent
> ("commandresponder") and another for notifications
> ("notificationreceiver"). I doubt either of those
> two are in use today!
I'm not convinced we need separate subsystem names, but I also don't see
any harm in having them. But, let's remember that the namespace is
universal and not specific to the context of SNMP. "snmp-commandresponder"
or even "snmp-command" is a fine subsystem name; "commandresponder" is too
vague.
> - Uniquely Identifying Sessions
> * I don't think that the quadruple of addrType, Addr,
> securityName and securityLevel serve as a good unique
> identifier combination. At least section 3.1.6
> specifies this as "unique". It's certainly the case
> that the architecture may require this because the
> architecture doesn't have session pointers to pass
> around. But I think that most real-world
> implementations may support more than one connection
> with identical values for these 4 variables. I've
> certainly seen some that (if modified to support SSH)
> will end up with non-unique combinations. This isn't a
> problem for the implementation as they're already
> passing around other references. So there are two
> things here that fall out of this:
> + Should the text be modified to add "implementations
> MAY have an alternative implementation-dependent
> method of identifying SSHTM sessions"
I'm pretty sure we've been over this elsewhere, and that in fact sessions
are uniquely identified by being distinct sessions, and not by looking up
some combination of parameters in a table. If you get two sessions, they
have different handles or file descriptors or whatever, and for the purpose
of directing outgoing responses (which AFAIK is the only reason we need to
"identify" sessions), you need to remember which one you use. We even
provided a means for this, in the form of tmStateReference.
> * Section 5.4: the closeSession() ASI won't actually work
> for similar stacks and only offers two identifiers for
> uniqueness when pointing at a session to close.
Why do we need this at all? Isn't session management the TM's job?
> - Section 4.2: tmSecurityName
> * I'm not sure how pulling the SSH identity from the SSH
> layer is implementation dependent. If two 2 are really just examples
> of stuff that may or may not be used. That being said,
> I don't mind if it stays either. But to answer the
> DISCUSS: no I don't think it's needed.
Agree. These paragraphs don't need to be here.
> - Section 3.1.4: DISCUSS
> * I don't think we need to go into gory detail here
> either.
I don't think we need this section at all. The SSH TM doesn't support or
not support any particular SSH encryption or integrity methods. SSH
supports what it supports, and SSHTM supports SSH. This is equivalent to
an application that runs over TCP saying it supports PMTU discovery, slow
start, fast recovery, and so on. Those things are transparent to anything
that runs above the layer boundary.
I'm almost inclined to say the same thing about section 3.1.3, but not
quite. The difference is that authentication methods _are_ visible above
the layer boundary, because you have to provide credentials. And so, the
set of authentication methods that can be used with SSHTM is limited by the
kinds of credentials it can provide.
> - Section 3.1.6: Subsystem naming
> 2. Re: DISCUSS: I do think we need two different
> subsystem names though. For management stations that
> are running an agent, it's highly likely that they
> are also running a notification receiver and the ssh
> subsystem destination shouldn't be the same. If we
> end up assigning SNMP-over-SSH specific ports for
> these services, then the susbsystem name really
> doesn't matter. If, however, we end up reusing 22 we
> certainly need one ssh subsystem name for an agent
> ("commandresponder") and another for notifications
> ("notificationreceiver"). I doubt either of those
> two are in use today!
I'm not convinced we need separate subsystem names, but I also don't see
any harm in having them. But, let's remember that the namespace is
universal and not specific to the context of SNMP. "snmp-commandresponder"
or even "snmp-command" is a fine subsystem name; "commandresponder" is too
vague.
> - Uniquely Identifying Sessions
> * I don't think that the quadruple of addrType, Addr,
> securityName and securityLevel serve as a good unique
> identifier combination. At least section 3.1.6
> specifies this as "unique". It's certainly the case
> that the architecture may require this because the
> architecture doesn't have session pointers to pass
> around. But I think that most real-world
> implementations may support more than one connection
> with identical values for these 4 variables. I've
> certainly seen some that (if modified to support SSH)
> will end up with non-unique combinations. This isn't a
> problem for the implementation as they're already
> passing around other references. So there are two
> things here that fall out of this:
> + Should the text be modified to add "implementations
> MAY have an alternative implementation-dependent
> method of identifying SSHTM sessions"
I'm pretty sure we've been over this elsewhere, and that in fact sessions
are uniquely identified by being distinct sessions, and not by looking up
some combination of parameters in a table. If you get two sessions, they
have different handles or file descriptors or whatever, and for the purpose
of directing outgoing responses (which AFAIK is the only reason we need to
"identify" sessions), you need to remember which one you use. We even
provided a means for this, in the form of tmStateReference.
> * Section 5.4: the closeSession() ASI won't actually work
> for similar stacks and only offers two identifiers for
> uniqueness when pointing at a session to close.
Why do we need this at all? Isn't session management the TM's job?
> - Section 4.2: tmSecurityName
> * I'm not sure how pulling the SSH identity from the SSH
> layer is implementation dependent. If two differendifferent
> implementations are expecting it to be pulled from two
> different portions of the packet then they won't
> interoperate at all!
No, it's not about pulling things from the packet. You don't even get to
_think_ about ssh packets. But the means by which an SSH server passes
username information to a subsystem is not specified; it is specific to the
SSH implementation.
> But "by default,
> tmSecurityName is determined from the value of the
> user name field of the SSH_MSG_USERAUTH_REQUEST
> message" isn't wise interoperable wording.
To my mind, any reference in this document to SSH_MSG_* indicates a
layering violation. The details of the operation of the SSH protocol are
below the abstraction level at which SSHTM gets to interface with SSH.
Again, this is like talking about the details of TCP packets, payload
lengths, etc.
> I'd say it
> *is* determined from that or else implementations that
> pick otherwise won't interoperate.
Of course it's determined from that. SSH says so. It's not up to us.
-- Jeff
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms
t
> implementations are expecting it to be pulled from two
> different portions of the packet then they won't
> interoperate at all!
No, it's not about pulling things from the packet. You don't even get to
_think_ about ssh packets. But the means by which an SSH server passes
username information to a subsystem is not specified; it is specific to the
SSH implementation.
> But "by default,
> tmSecurityName is determined from the value of the
> user name field of the SSH_MSG_USERAUTH_REQUEST
> message" isn't wise interoperable wording.
To my mind, any reference in this document to SSH_MSG_* indicates a
layering violation. The details of the operation of the SSH protocol are
below the abstraction level at which SSHTM gets to interface with SSH.
Again, this is like talking about the details of TCP packets, payload
lengths, etc.
> I'd say it
> *is* determined from that or else implementations that
> pick otherwise won't interoperate.
Of course it's determined from that. SSH says so. It's not up to us.
-- Jeff
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
