EIGRP authentication

[NetworkingGeek1]

Hello community,

I have a question about EIGRP authentication. We don’t use plain text authentication, because anyone who can launch “man-in-the-middle attack” can easily steal password which is travelling through the network as a plain text.

Please correct me, if I’m wrong: That’s why use MD5 authentication or SHA authentication, which make hash function from password and send it to the another router as hash and another router just compare it with its hash of the same password and if they’re the same, then everything is ok.

But there is something, I don’t understand: Why someone who is the man in the middle, can’t just steal hash function, in the same as  he / she can do with password in plain text? What I mean, someone can just steal hash function, put it in update packets and that’s it. It’s not an encryption, it’s just hash function, which must be the same at both ends and malicious user doesn’t need to know actual password, he / she can just use hash function, put it inside update packets and that’s it. Could you please explain this, how hash function really protects communication between routers?

[David Ruess · Accepted solution]

I supposed it IS possible but much harder than plaintext for obvious reasons. Check out this EIGRP documentation that explains a bit about the hashing process.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_eigrp/configuration/15-mt/ire-15-mt-book/ire-sha-256.html

Under the HMAC-SHA-256 Authentication section there is a list of steps on how the hash is calculated:

Typically, the shared secret key is configured to be identical between the sender and the receiver. To protect against packet replay attacks because of a spoofed source address, the shared secret key for a packet is defined as the concatenation of the user-configured shared secret (identical across all devices participating in the authenticated domain) with the IPv4 or IPv6 address (which is unique for each device) from which the packet is sent.

The device sending a packet calculates the hash to be sent based on the following:
Key part 1—the configured shared secret.
Key part 2—the local interface address from which the packet will be sent.
Data—the EIGRP packet to be sent (prior to the addition of the IP header).
The device receiving the packet calculates the hash for verification based on the following:
Key part 1—the configured shared secret.
Key part 2—the IPv4 or IPv6 source address in the IPv4 or IPv6 packet header.
Data—the EIGRP packet received (after removing the IP header).

For successful authentication, all of the following must be true:

The sender and receiver must have the same shared secret.
The source address chosen by the sender must match the source address in the IP header that the receiver receives.
The EIGRP packet data that the sender transmits must match the EIGRP packet data that the receiver receives.

Authentication cannot succeed if any of the following is true:

The sender does not know the shared secret expected by the receiver.
The IP source address in the IP header is modified in transit.
Any of the EIGRP packet data is modified in transit.

Again, not saying its impossible but even MD5 is crackable now so if someone is in your network replaying EIGRP packets I would worry about how they got in in the first place and not how they sniffed some EIGRP traffic

-David

[NetworkingGeek1]

@David Ruess  Hello. Thank you for the helpful reply. I wasn't speaking about cracking hashing algorithm, I was just saying why it's not possible just to capture hash function and craft a new packet: put there this function, put a malicious EIGRP update and send it to the victim router. But after your post, I think it started to make sense to me. If there are 3 components: 1. Shared secret; 2. Source IP and 3. EIGRP packet. In that case, even though attacker can spoof source IP address, if he / she will change EIGRP update, then receiver router will know it, because receiver will put shared secret, source IP and Data to the hash algorithm and will get different results. From my point of view, if attacker, can launch man in the middle attack, he / she can still without any issue see source IP, EIGRP update and hash function, but attacker can't modify EIGRP update without knowing pre-shared key, because in that case router which receives updates will find out that update packet is not valid. 

"Again, not saying its impossible but even MD5 is crackable now so if someone is in your network replaying EIGRP packets I would worry about how they got in in the first place and not how they sniffed some EIGRP traffic" - I agree, but this is the reason for EIGRP authentication, this is for the situation when attacker could get to the network, that's why my questions is for the situation, when we assume that attacker is already inside the network. otherwise we don't even need EIGRP authentication.

[Martin L]

I am not security guy (expect when breaking it) but My understanding is that MD5 hash cannot be reversed engineered (unencrypted) in order to get the original file.  However, hackers can make a malicious file to generate the same hash.  For that reason, MD5 is not being used to encrypt text (data encryption) but only for authentication. 

You need 2 items to create hash. While one item is being known, the other one stays secret.  Hash itself is sent instead of the authenticating key. When you get this hash, you compare it to one you do yourself on your end (with secret key we share).  Since the same input  produces the same output, the validation is OK.

Regards, ML
**Please Rate All Helpful Responses **

[David Ruess]

I think you're right. I was thinking of another hashing type. I am also not a security guy

[Martin L]

my reply was meant to be to OP, original poster. for some reason, it went under you. this happens often here.

[David Ruess]

All good. My statement of not being a security guy still stands haha.

[Joseph W. Doherty · Accepted solution]

You misunderstand what the hash is.

Perhaps the best way I might compare a hash function, are you familiar with CRC usage for unexpected data modification checks?

When I send a frame or packet, I might do a CRC computation across the whole frame or packet.  The result of this computation, the computed CRC value, is sent along with the data.  When the destination receives the frame or packet, it too computes the CRC and compares its CRC value against the CRC result sent with the data.  If the newly computed CRC doesn't match the sent CRC, it's assumed the data was corrupted.

If you were a man-in-the-middle, you could change data being sent, re-compute the CRC and the destination would not be able to tell the data was modified.

Suppose every time we compute the CRC, we also include some additional data in the computation, but that additional data is NOT sent.  It's only known to be used by both the sender and receiver for their CRC computation.

Now, if you were a man-in-the-middle, you could change data being sent, but without the "secret" additional data, known only by the sender and receiver, how to you correctly re-compute the CRC?  You cannot!

An issue with the forgoing, if you know the CRC algorithm, and you have the data and the provided CRC, you might be able to work backwards and figured out what the "secret" additional data is.  If you can do that, you can now easily be a man-in-the-middle.

Basically, "breaking" a hashing function, is computing the original "secret".

BTW, with hashing function, you don't often need the true original secret, other secret values will create the same CRC.  I.e. any of equivalent "secrets" will work.

Also BTW, in the field of cryptology, any algorithm is considered breakable, it's just a question of how much effort it takes to break it.

Also, if you're wondering, there's one form of crypto that is considered totally unbreakable, but it's not based on any algorithm, and has a major operational usage issue.  (See "one-time pad", for details.)