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

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