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

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Sep 2005 15:46:29 +0200

Hi all,

A draft is now posted - draft-lear-callhome-description-00.txt.  It
doesn't yet have much in the way of SNMP specifics but I am working on
that now.

Bert has suggested that to move forward this functionality I request a
BoF.  I think the agenda should look something like this:

Agenda bashing - 1 minute
What is Call Home - 10 minutes
Application to SNMP - 10 minutes
Discussion including architectural issues - 30 minutes
Moving Forward Options  - 10 minutes
  1. Merge back with ISMS
  2. Separate working group

What do people think?

Did I miss architectural issues in the draft?

Eliot

_______________________________________________
Call-home mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/call-home

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Sep 2005 23:06:54 +0200

> doesn't yet have much in the way of SNMP specifics but I am working on

I am not sure what the scope of your efforts here are. Do you limit
this in scope to the management domain (which is somewhat implied by
talking about managers and agents) or do you want to address the more
general question of how to reverse connection establishment from the
inside to the outside. In any case, I would like to discuss this issue
not only in the context of SNMP, but at least also consider netconf,
where the required to implement transport mapping also does not
provide call home at the moment.

Personally, I am concerned about the security considerations. I would
very much prefer a solution where the authenticated identities and the
way they are authenticated remain the same, regardless whether I am
using call-home or not. Now, it may turn out that this is not feasible
to achieve. If that is the case, these findings need to be documented
somewhere.

> Did I miss architectural issues in the draft?

I only had a very quick read. For me, the really interesting issue is
to figure out how much security protocols like SSH or TLS actually
reply on the connection initiation procedure or whether the
client/server roles can be "turned" before the security protocols do
their work. In other words, I would like to know whether some
extensions to say SSH can solve most of the issues with call home
support in ISMS and NETCONF.

To answer this question, one might have to dive into the details of
the security mechanisms in order to figure out whether there is an
architectural reasons why this can or cannot work.

/js

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Sep 2005 11:33:52 +0200

Juergen Schoenwaelder wrote:
> inside to the outside. 

I've been asked to consider the broader architectural issues (if any),
but my interest is in network management as well.  It would be good if
someone could flag issues they see as broader than the area of
management if I miss them.

> In any case, I would like to discuss this issue

I am not sure this is a problem with the notion call home, but perhaps
with mechanisms used to achieve it.  For instance, BEEP today supports
either side initiating a connection as well as mutual authentication via
TLS.  In the case of SNMP, therefore, there would be a mapping from
securityName to X.509 subject (amongst other things), either directly or
via SASL EXTERNAL.

But I wonder whether we should mandate such a requirement.  Also if we
are making use of substrates such as SSH, BEEP, or for that matter HTTP,
how we structure those interfaces.

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

> [rely] on the connection initiation procedure or whether the

I'm not quite sure what you're asking for.  Are you suggesting, for
instance, that the initiator have a host key and the listener make use
of a user key?

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Sep 2005 06:33:35 -0700

>>>>> On Tue, 27 Sep 2005 11:33:52 +0200, Eliot Lear <[email-masked]> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2005 16:32:10 +0200

On Tue, Sep 27, 2005 at 06:33:35AM -0700, Wes Hardaker wrote:

> [...] but the current protocols (SSH, TLS) don't do this.  They are

My understanding of SSH is that both parties send an identification
string after connection establishment. Once that has happened, both
parties start the key exchange process by sending SSH_MSG_KEXINIT and
they both know their client/server role due to the way the TCP
connection was established. What I like to know is whether something
would break (and what) if the client/server role was not necessarily
bound to the TCP connection setup.

I am not saying SSH people will like this or that this whole idea is
worth anything at this point in time - I am just trying to explore the
solution space. On the other hand, if the call home feature could be
supported by a rather small change to SSH, then all SSH based
management interfaces could benefit from this and the only thing to be
dealt with is to identify the transport enpoints to which to call home.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2005 11:58:33 +0200

> instance, that the initiator have a host key and the listener make use

I am asking for a solution which gives me the same authenticated
identities regardless how the connection was established. In SNMP
terms, I assume that an engine hosting a command generator identifies
itself as a user on the engine hosting the command responder and I
like to leverage this user identity which does exist on the device
across multiple management interfaces, whether that is a CLI, NETCONF
or even an HTTP interface.

Looking at the real-world networking devices I have access to, they
all have a notion of a user identity and they all are able to talk
RADIUS to outsource the authentication decision, which is typically
then password based. I like to leverage that and if call home can be
made to work without changing the premise I am operating on, I am
fine.

/js

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 27 Sep 2005 10:21:53 -0700 (PDT)

HI Eliot,

The key issue, which I have said in previous email on the ISMS list,
and you have touched on below, is what credentials are being
used by each end of the connection, followed by what autorization
rules are in being used and where they are applied.

I didn't feel like you answered my previous question about
this on the ISMS list. That is, you did provide a response,
but I could not understand it.

Once it is clear what credentials are available, then the
next step is to show the mechanisms that would be used to
verify the identities.

> instance, that the initiator have a host key and the listener make use

Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 27 Sep 2005 11:14:23 -0700 (PDT)

HI,

I too would like to see the same objectives achieved as
specified below by Juergen. And in addition, let's not
forget about authorization!

Regards,
/david t. perkins

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Sep 2005 23:52:10 +0200

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.

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

/js

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Sep 2005 18:33:54 +0200

Dave,

> but I could not understand it.

Can you help me with what you didn't understand?  I presume you are
referring to the following text:

>>1) What identities and credentials are being used?
> 
> 
> Borrowing from BEEP terminology for the moment, the initiator and
> listener will use any authentication mechanism supported by the
> underlying mapping protocol.  That is to say, for SSH, the responder is
> configured to authenticate to the command generator via an appropriate
> SSH mechanism such as a user name and password.  The generator would
> authenticate via a host key or other mechanism defined with SSH.

What I'm specifically trying NOT to do is to limit SSH from adding
mechanisms that ISMS could then not take advantage of.  The case and
point would be X.509 certs.

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 29 Sep 2005 10:25:14 -0700

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

>> 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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Sep 2005 21:05:23 +0200

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

[...]

> connecting side will send user/password information.  This is how it

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