Re: Request for Comments: Nping Echo Protocol

["Luis M." <luis.mgarc () gmail com>]

Hi Brandon,


Thanks a lot for taking the time to read the RFC.


Brandon Enright wrote:
> 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).
Well I know they are not the same but the way I see it, a regular hash
that is
encrypted with a PSK acts just like a MAC, doesn't it?


> 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.
I like the challenge-response idea but I wouldn't go for the IP based
ACL because in many situations we will not know which IP address
client packets will be coming from (e.g. there is a NAT device we
don't know of) so, creating AC lists of IPs does not seem the best
option.


> 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.
Well, the fact that an attacker is in a position to record our traffic
at some point shouldn't make us think we lost the battle because
the attacker may be capable of capturing our packets only in one
occasion but use the data many times in the future.

Imagine Alice is in a wi-fi cafe with her laptop, connects to Bob's server
and specifies a custom BPF filter that says "(tcp or udp)". Mallory
is in the same place sniffing our non-encrypted traffic. If we don't
do authentication right, Mallory captures some of the initial
packets. Then he goes somewhere else, replays the packets and
gets to receive all the traffic. If the session is unencrypted this means
the guy actually has an inside sniffer on Bob's network.


The challenge-response auth sounds good. Let me know how you
think we should do I. Personally I would go simple like make the server
generate some random number N (128 bits should be enough), encrypt
it using the PSK C=Ek(N) and make the client decrypt it N=Dk(C),
compute N'=N+1, and then do C'=Ek(N'), and send it back to the server.
What would you do?

So with this challenge-response auth it is true that we don't need
encryption,
however, in the future we may extend the protocol to transmit some
more sensitive information so I don't think using encryption by default is
a bad choice because nowadays we don't have to worry about the computation
overhead added by crypto. Moreover, we need a PSK anyway so we already
need to set up the same key on both ends, so not using crypto doesn't make
it more user friendly either.


> Ultimately, even with an encrypted Echo protocol, all the  probes that
> you are going to send have to be unencrypted; their just IP afterall.
The problem is that under some circumstances, the server may capture
other traffic, not only our probes.


> 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.  
Yes, that will always be possible. However, that's not a big problem because
it just affects the client, who would see some weird packets being echoed.
No information leakage, there.


Regards,


Luis




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