Re: [Call-home] draft now posted; BoF?

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Thu, 29 September 2005 20:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL54n-0002mt-D6; Thu, 29 Sep 2005 16:32:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL54m-0002mo-OS for call-home@megatron.ietf.org; Thu, 29 Sep 2005 16:32:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12195 for <call-home@ietf.org>; Thu, 29 Sep 2005 16:32:18 -0400 (EDT)
Resent-From: j.schoenwaelder@iu-bremen.de
Received: from i956f.i.pppool.de ([85.73.149.111] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL5CS-0007RY-0f for call-home@ietf.org; Thu, 29 Sep 2005 16:40:20 -0400
Received: by boskop.local (Postfix, from userid 501) id E9DD04474C6; Thu, 29 Sep 2005 22:32:06 +0200 (CEST)
Resent-Date: Thu, 29 Sep 2005 22:32:06 +0200
Resent-Message-ID: <20050929203206.GC3638@boskop.local>
Resent-To: wjhns1@hardakers.net, lear@cisco.com, call-home@ietf.org
Received: from merkur.iu-bremen.de ([unix socket]) by merkur (Cyrus v2.2.12) with LMTPA; Thu, 29 Sep 2005 21:41:08 +0200
X-Sieve: CMU Sieve 2.2
Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by merkur.iu-bremen.de (Postfix) with ESMTP id B8DBD79EAA3A3 for <j.schoenwaelder@iu-bremen.de>; Thu, 29 Sep 2005 21:41:08 +0200 (CEST)
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B4BA73AD07 for <j.schoenwaelder@iu-bremen.de>; Thu, 29 Sep 2005 21:41:08 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11242-06 for <j.schoenwaelder@iu-bremen.de>; Thu, 29 Sep 2005 21:41:07 +0200 (CEST)
Received: from boskop.local (I956f.i.pppool.de [85.73.149.111]) by hermes.iu-bremen.de (Postfix) with ESMTP id 957793AD41 for <j.schoenwaelder@iu-bremen.de>; Thu, 29 Sep 2005 21:41:05 +0200 (CEST)
Received: by boskop.local (Postfix, from userid 501) id 842AC44739A; Thu, 29 Sep 2005 21:05:23 +0200 (CEST)
Date: Thu, 29 Sep 2005 21:05:23 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Wes Hardaker <wjhns1@hardakers.net>
Subject: Re: [Call-home] draft now posted; BoF?
Message-ID: <20050929190523.GB3085@boskop.local>
References: <4337FBB5.4010701@cisco.com> <20050926210654.GA3067@boskop.local> <43391200.1020806@cisco.com> <sdy85iocsw.fsf@wes.hardakers.net> <20050927143210.GB1586@boskop.local> <sdirwmgp7r.fsf@wes.hardakers.net> <20050927215210.GA4997@boskop.local> <sdmzlvairp.fsf@wes.hardakers.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <sdmzlvairp.fsf@wes.hardakers.net>
User-Agent: Mutt/1.5.10i
X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de
X-Spam-Status: No, hits=-4.9 tagged_above=-30.0 required=5.0 tests=AWL, BAYES_00
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: call-home@ietf.org
X-BeenThere: call-home@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@iu-bremen.de
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <call-home.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/call-home>
List-Post: <mailto:call-home@ietf.org>
List-Help: <mailto:call-home-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=subscribe>
Sender: call-home-bounces@ietf.org
Errors-To: call-home-bounces@ietf.org

On Thu, Sep 29, 2005 at 10:25:14AM -0700, Wes Hardaker wrote:

[...]

> Ok, back to call home.  Let's reverse the situation.  Let's assume
> that the server is now initiating the ssh connection.  ssh and many
> other protocols *currently* mandate that the receiving side of the
> connection present their credentials first.  If we truly reverse the
> connection above this means the management app will have to send the
> username/password to the agent before the agent has given proof that
> it's a trusted source to receive that password.  What's to prevent any
> random joe from connecting to the call back transport address and
> saying "give me your password"?  This setup isn't, of course, allowed
> in SSH or other protocols (TLS/SASL, IKE with EAP, ...) for this
> reason.  The receiving side of that SYN you mentioned must always
> present their identity and proof of identity first before the
> connecting side will send user/password information.  This is how it
> should be.

Thanks for your effort to explain things to me. I still think we do
not talk about the same thing. My understanding is that both endpoints
of an ssh connection first send a greeting message. Afterwards, they
start the keyex procedure (and the connection setup has determined who
is taking the client and server role). Once the keyex is complete and
an encrypted tunnel is available, you run one of the user
authentication methods.

I never suggested to run the user authentication before establishing
the encrypted tunnel or something like that. My question was whether
it is possible to establish the TCP connection, exchange the greeting
and then run the keyex procedure (and everything that follows) just
with the roles of client/server reversed. That is change

  active open  <-- tcp connection establishment --> passive open
               <-- ssh greeting exchange        -->
  client       <-- keyex procedure              --> server

to the following:

  passive open <-- tcp connection establishment   --> active open
               <-- ssh greeting exchange + "turn" -->
  client       <-- keyex procedure                --> server

Note that the greeting exchange does not seem to assume a client or a
server role. The only obvious danger I see is that call-home allows to
do denial-of-service attacks on the manager, but this is most likely a
general problem with call-home in the context of management protocols
(and also nothing really new in the SNMP world since you can simply
flood managers with traps if you want to).

Note that I am not proposing to change anything in the security
elements of procedure - I am just asking whether the role can be
isolated from the TCP establishment. (In theory, one could even ask
what happens with SSH is both TCP endpoints to a simultaneous active
open - but I guess this is practically irrelevant.)

So again: What breaks if one would turn client/server roles before the
endpoints engage in the keyex procedure?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Call-home mailing list
Call-home@ietf.org
https://www1.ietf.org/mailman/listinfo/call-home