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

Wes Hardaker <> Tue, 27 September 2005 13:33 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1EKFaY-0000sF-Ok; Tue, 27 Sep 2005 09:33:42 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1EKFaX-0000rm-Rz for; Tue, 27 Sep 2005 09:33:41 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id JAA07606 for <>; Tue, 27 Sep 2005 09:33:40 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.43) id 1EKFhl-0005LT-11 for; Tue, 27 Sep 2005 09:41:12 -0400
Received: by (Postfix, from userid 274) id 9CAA111D5D1; Tue, 27 Sep 2005 06:33:36 -0700 (PDT)
From: Wes Hardaker <>
To: Eliot Lear <>
Subject: Re: [Call-home] draft now posted; BoF?
Organization: Sparta
References: <> <20050926210654.GA3067@boskop.local> <>
Date: Tue, 27 Sep 2005 06:33:35 -0700
In-Reply-To: <> (Eliot Lear's message of "Tue, 27 Sep 2005 11:33:52 +0200")
Message-ID: <>
User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>>>>> On Tue, 27 Sep 2005 11:33:52 +0200, Eliot Lear <> said:

Eliot> In a practical sense, a service provider already provides a
Eliot> username and password to an end user.  It would seem
Eliot> impractical for the user to provide a username and password
Eliot> back to the service provider when an X.509 certificate would do
Eliot> the job.

The general issue with reversing a connection is that the order in
which you present credentials to the end other side often doesn't
work.  EG, if in a normal connection via netconf or snmp/isms you'd
get this:

    manager                 agent
    opens connection  -->                             [possibly negs encryption]
                      <--   sends host id cert
    verifies agent ID
    sends users/pass  -->    
                            verifies user/pass
                      <--   finishes open with a protocol ack

That, of course, is just an example.  The problem comes when you
reverse the connection you need to do things in the same order.  A
manager can't send their side of the credentials first when it's a
username/password since you'd be disclosing information before
verifying the other side can receive it.  Ok, you say, then just make
sure it happens in the same order and that the agent opens the
connection and immediately sends his own credentials?  Great in
theory, but the current protocols (SSH, TLS) don't do this.  They are
designed with a particular order of sending the credentials and they
all expect the model above.  Whether you can trigger them to do the
reverse is subject to a huge debate with their authors I'd think.

"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Call-home mailing list