Re: Request for Comments: Nping Echo Protocol

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 22 Jul 2009 14:18:28 +0200
"Luis M." <luis.mgarc () gmail com> wrote:

> It
> would be specially useful if those of you who are into cryptography
> and security had a look at section "2.11 Security" and make comments
> on the choices that have been made. 


Hi Luis.  You did a really excellent job with this RFC.  Your ASCII
diagrams are great.  I haven't read the whole RFC in enough detail to
really comment on your protocol design but I did read over your
security section.

Starting that section, you write:

    2.11 Security

        The Nping Echo functionality involves direct access to network traffic
        on the server side and that can easily involve information leakage 
        problems if no security measures are taken.

I agree with that statement.  Then you go on to design a systems using
AES for encryption and authentication with SHA-256.  If we decide to go
with good crypto for the protocol then I think your authentication
portion needs more work.  We should be using a message authentication
code (MAC) (like HMAC) rather than a straight-up hash which is just a
message integrity code (MIC).

*BUT*

I don't think we need any of this.  Don't get me wrong, I love good
crypto and designing a protocol can be fun.  I just don't think
encryption actually protects against the likely attack scenarios.

So what are the likely attacks?  I'd say scenario #1 is that you run
an echo server on machine A that you intend to use from machine B.
Some other user (not on your network) comes with machine C and connects
before you have a chance to use machine B.  This is bad and we need to
protect against it.

I see two solutions to scenario 1:

A IP based ACL, or, a challenge-response with a shared key.  Why?
Either of these will protect against the rogue machine from
connecting.  No encryption needed because they aren't anywhere where
they can record the Echo session between A and B.


Scenario #2 is that the attacker running machine C is on your network,
able to play monkey-in-the-middle or just record your traffic.  This is
bad too.  You're right that good authentication would prevent the MitM
attack and that good encryption would prevent decrypting the Echo
session.

But, encryption and authentication don't really help us in scenario 2:

Ultimately, even with an encrypted Echo protocol, all the  probes that
you are going to send have to be unencrypted; their just IP afterall.
If you get a response, it too will come back unencrypted.  Any
attacker in scenario 2 can just record those and not bother with
decrypting the Echo protocol.  They can also forge their own probing
frames with another Nping instance to look just like yours.  Sure they
can't use/abuse the Echo server but the Echo server doesn't really buy
them anything the don't already have by owning your network.


So, what do I think all this means?  All we need is access control.  We
can do that with a IP ACL, and/or, a shared key challenge-response.  We
don't need encryption and the like.  Any person close enough in on your
network to be observing your Echo session can do a lot of damage and
gather a lot of information regardless of the encryption.

I'm not arguing for less security, I'm arguing for sensible security.


If you think a challenge-response with a PSK is the way to go, I'd be
happy to share my thoughts on how I think that should be done.

Regards,

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpnY9MACgkQqaGPzAsl94LafgCggyj5ZYf/QoT0rzr0NRwlkUyW
I8oAmwRFJ0pL24A4Kw76OJoRGlKSEGSo
=l1Bl
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org