NCSAM/2011–Post 14–An IP address as an authenticator?
So we’ve talked a little about names as claims of identities and passwords as proofs of those identities, continuing on to describe a fingerprint as a reasonable proof of identity, but perhaps not so useful when it has to be a claim and proof of identity at the same time.
So, how about an IP address?
A number of applications offer you the ability to accept or deny connections / requests from outsiders, based on their IP address. Good connections / requests from IP addresses that you know are allowed; bad connections / requests from IP addresses that you don’t know (or from IP addresses that you know are bad) are blocked.
Since this looks rather like an authentication scheme, let’s ask the question:
What is the claim of identity, and what is the proof?
UDP – User Datagram Protocol (or “Unreliable”)
Well, for UDP, the claim appears to be the IP address in the “source address” component.
Is this IP address also a proof of identity?
Since I can forge a UDP datagram for any source IP address, I think that means that it can’t possibly be a proof of identity.
So, for UDP traffic, using the source IP address as any kind of authenticator is clearly a bad idea.
TCP – Transmission Control Protocol
TCP is a little stronger of a case, because there’s a connection to be made, and some protections to be had. One of the protections to be had is that the handshake at the beginning of the connection exchanges a couple of random numbers – known as initial sequence numbers (ISNs) – one from the client, and one from the server. The client then has to send packets with a sequence number starting at the ISN the server sent, and the server has to send packets with a sequence number starting at the ISN the client sent. This means that it’s harder to forge TCP connections than UDP requests, because the client has to see the ISN from the server, and vice versa.
Are these ISNs and subsequent sequence numbers a proof of identity?
Not really, because of a number of factors.
- In early days of TCP implementations, the ISN was easily guessed by a spoofing client, who didn’t actually have to see their connection handshake. It’s always possible that a flawed TCP implementation in the future will also generate predictable ISNs.
- The ISN is essentially echoed back, rather than being a secret held by the owner of the identity (IP address) being claimed as the source identity.
All that the ISNs really do is provide a reasonable protection against massive floods of forged connection attempts, by requiring that the client be able to receive and respond to the server’s messages. Some schemes even make use of this further, and don’t create the actual connection object until receiving the first packet with the correct sequence number.
If they aren’t a proof of identity, how can someone spoof me?
There is always the possibility of a third party who can listen to your conversations, and spoof portions of your communications. They can know your ISN, and use it to initiate or continue connections you make to other servers.
This usually requires the attacker to be a “man in the middle” (MITM), and remember, an attacker can do that through a wireless connection.
The only protection you have is if you also are a part of this conversation and can send a quick message along the lines of “stop, don’t trust him, he’s not really me”.
This would be the RST, or reset, message, that aborts a TCP connection, usually because inappropriate (out-of-standard) traffic has been detected. We’ll touch on that more in the next post.
Bottom line: IP address is not an authenticator
So, while it might be a good filter for convenience and traffic reduction, filtering by source IP address is not something you can consider as a security measure, because there is no authentication involved.
Rather like the “TCP evil flag”, it does require that someone be truthful when attacking you, so that you can repel them.