Nmap Development mailing list archives
Re: Request for Comments: Nping Echo Protocol
From: Brandon Enright <bmenrigh () ucsd edu>
Date: Thu, 23 Jul 2009 10:10:58 +0000
Luis, I'll give you a more detailed response tomorrow whet it isn't 3am but I think this response of yours boils down to: * Depending on the BPF filter, the Echo server may inadvertently capture more traffic than it should and therefore would leak information if it isn't encrypted. * We don't know all the features we may want to add in the future so adding encryption now prevents us from worrying about it later. I can't argue with either of these. If you feel up to the task of weaving SHA-xxx with HMAC with AES-CBC or AES-CTR, etc then by all means... I'm certainly not an expert on the subject but I have a few opinions on how I think it should be done that I'll try to highlight in a later response. Brandon On Thu, 23 Jul 2009 11:11:22 +0200 or thereabouts "Luis M." <luis.mgarc () gmail com> wrote:
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
Current thread:
- Request for Comments: Nping Echo Protocol Luis M. (Jul 22)
- Re: Request for Comments: Nping Echo Protocol DePriest, Jason R. (Jul 22)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 22)
- Re: Request for Comments: Nping Echo Protocol David Fifield (Jul 22)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol David Fifield (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 22)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 26)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 27)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 27)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 27)
- Re: Request for Comments: Nping Echo Protocol DePriest, Jason R. (Jul 22)