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

[Wes Hardaker <[e-mail]>]

>>>>> On Tue, 27 Sep 2005 23:52:10 +0200, Juergen Schoenwaelder <[e-mail]> said:

Juergen> On Tue, Sep 27, 2005 at 02:44:56PM -0700, Wes Hardaker wrote:
>> I promise you that user/pass credentials are not sent until after the
>> user verifies that it's talking to a server it trusts.  Asymmetric
>> cryptography (X.509, eg) can be used independent of ordering but
>> tacking on raw username and password through a negotiated tunnel can
>> not.  To do anything else would allow for man in the middle.

Juergen> Can you translate that into something I can understand? How
Juergen> can I mount a man in the middle attack if the client/server
Juergen> roles are not determined by who sent the first SYN?

Big if here, that you need to make sure is what I'm talking about:
authentication of one half using a username/password that is not
transformed via some puzzle and hashing function.  EG, sending the
password in the clear through the tunnel (the tunnel may be protecting
the password from eavesdropping but it doesn't protect the other side
from learning it if they didn't know it yet...  more in a sec).

Consider the case where a standard ssh client (user) connects to a ssh
server.  The first thing the ssh client does is check the information
sent by the server, which includes the public key and related
information (*):

  1) sees if the public key sent by the server for:
     a) indeed matches a known host key previously seen
     b) and if that host key was seen from that particular address before
     c) and if that host key matches the transport you gave it (IE, if
        you have connected to host1 with address w.x.y.z before and
        now you're connecting to host2 with the same address (via
        a CNAME or renaming) ssh will still prompt you with the prompt
        of "you've never had this combination before because "host2" is
        new to me even though the transport address and key I've seen before)".

  2) checks to see if the host can *prove* that it has the private
     side of the key by some computational puzzle.  To put it in terms
     of SNMPv3/USM, something I know you grok, it's a similar process
     to how the agent verifies that the management side has the
     correct localized key because of how the authentication field is
     encoded using a hash of the message, the localized engine, and
     other data that changes from message to message.  The protocol
     doesn't matter here.  What matters is that the server has given
     proof to the client that it not only sent the public half of the
     key (IE, the identity) but it has also sent proof that it knows
     the secret half (IE, a cryptographic proof that it has the hidden
     parts of the material).

Only *after* this point is a ssh client willing to ask the user for
their password and send it to the server.  This of course, assumes as
mentioned above, that the password will be sent in the clear
(unmodified/hashed/transformed) within the tunnel so that the agent
side can look up the credentials via a local password store (a crypted
/etc/passwd or md5 sum list or ...) or via a AAA scheme such as radius
that requires the server to know the real unmodified password in order
to answer the radius challenge.

Again, for the third time, this only matters in cases where the
password is indeed sent unmodified through the tunnel.  But it's
important to know that this happens a lot in todays world.  Many
people still use passwords and don't distribute ssh public keys to all
the servers they use.


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.

What this means for callhome is that public/private keys will need to
be used on both sides of the connection anytime call home is used.
Or, we'll have to convince the transport (such as ssh) to allow
authentication the connecting agent first before the manager sends
a username/password.

Ideally, we'd always be using asymmetric cryptography (public/private
keys) on both sides of every connection.  Unfortunately, the world
doesn't do the exclusively yet today.  We will either have to mandate
that it will for CH or modify behavior of the transports today.

-- 
"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
[e-mail]
https://www1.ietf.org/mailman/listinfo/call-home