[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Part One: Background
Throughout these notes, I am assuming that we are not dealing with
fragments. Fragment processing creates wrinkles that have been discussed
previously, and I think that omitting the special case of fragmentation will
help to keep things on-track. In a nutshell, fragments cannot be subject to
intermediate network authentication unless they are passively re-assembled
(which I believe is not a good thing) because authentication processing happens
before fragmentation and after reassembly (think of AH as an ULP instead of a
network option for fragmentation/reassembly purposes).
First, I have some background architectural points to make. I view the
IP Authentication Header as being able to provide two different types of
security assurances. The first of these is what I will call "intermediate
authenticity", which I define as having guarantees that a packet must have come
from a finite set of senders because of authentic tunnels and network
design. This is not the same as "intermediate network authentication," which I
define as a specific mid-point in a network processing the Authentication
Header in a packet to determine whether or not the packet-in-transit is
currently authentic. The second of these is guaranteed authenticity end-to-end
(i.e., at the sender and receiver). You might think of the former as implicit
security and the latter as explicit security.
First assertion: End-to-end authenticity assurances imply intermediate
authenticity, but the reverse is not true.
This all seems fairly obvious, but I think that some of the
subtleties might turn into "gotchas" that people need to consider. Several
of Steve Bellovin's attacks are cases where I believe these two assurance
levels have been confused.
My first example is a simple use of the "AH Tunnel", where virtual
links between gateways are built by taking the packet in transit, encapsulating
it using IP-IP tunneling, and doing normal AH processing on the resulting
packet. This case supports both assurances of security for A and B. It
supports end-to-end security between A and B if they use an explicit
Authentication Header in their packets. It provides intermediate authenticity
assurances for A and B because there is a finite set of possible senders. It
also supports intermediate network authentication at C and D of packets between
A and B. Consider this fictitious network:
A------| |------ B
|----- C ===== D -----|
I------| |------ J
(Legend for this note: '=' is a configured AH tunnel, '-' is a link,
and '|' is a network)
B has received a packet that claims to be from A to B that carries no
Authentication Header. B has no guarantee that A really sent the packet -- any
other machine in this diagram could have forged it. If C and D have the
security policy that they only allow packets from the tunnel (and won't forward
other packets onto the nets), then, without doing any AH processing itself, B
has an intermediate authenticity guarantee: If the packet is forged, there is a
finite set of possible forgers: I, C, D, J, and B. Random machines on the
Internet, which is where we can envision the tunnel from C to D traversing,
cannot forge a packet from A to B. If D receives a packet from the tunnel, from
the end-to-end authenticity, it has a stronger guarantee: the packet presumably
from A to B that it received from the tunnel must have been sent to D by C.
This is because C and D are sending packets that carry the Authentication
Header, which gets C and D end-to-end (tunnel-end to tunnel-end, really)
assurances.
If B wants to be guaranteed that the packet could only have come from
A, it must require that there be an authentication header on the packet as sent
by A. In this case, B will get both assurances and you will actually have two
authentication headers (as well as two IP headers) between C and D. This is,
however, the only way to provide end-to-end security in this configuration.
My second example is more complex. Consider this fictitious network:
A------| |------ B
|----- C ===== D ===== E ===== F -----|
I------| |------ J
For extra fun, A is source-routing its packet to B through C, D, E, and
F. The packet goes from A to C without an Authentication Header. C encapsulates
the packet in a new IP packet and authenticates it with a C->D key. D verifies
the auth header, decapsulates the packet, processes the source route to find
the next destination E, encapsulates the packet in a new IP packet, and
authenticates it with D->E key. E does the same thing as D, though shifted
along the chain. F checks the auth header against the E->F key, decapsulates
the packet, and sends it to B without an Authentication Header.
When B gets a packet claiming to be from A, it knows that it can only
have come from a finite set of senders because of the intermediate
authenticity: A, C, D, E, F, I, J, and B. The packet could not have been forged
between C and D, D and E, or E and F, thanks to the authenticated tunnels
between those hosts. Again, A could explicitly add an Authentication Header to
its packet to B to provide end-to-end protection, which would result in the
tunnels carrying a total of two IP headers and two AH headers on the lines
between them (one for the tunnel and one end-to-end).
Now, let's say that B gets a packet claiming to be from E. The
set of senders who could forge that packet is F, J, and B. A, J, C, and
D cannot forge the packet assuming reasonable security policy because E
will find that its source address is on a packet it received from D and
is forwarding, which is not correct. This has the nifty property of helping
to drop packets caught in a routing loop. F, however, can guarantee using
end-to-end authentication that the packet it is receiving is from E because
it verifies it in the E->F key.
Let's say that A sends an end-to-end authenticated packet to B over
this network. C and F can add and remove, respectively, any options it
wants from this packet so long as the packet from F->B is the same (except
for obviously variant fields that are exempt from AH processing) as the
packet from A->C. In this case, while you have end-to-end authenticity,
your packet will fail intermediate network authentication. This property has
implications for people doing real intermediate network authentication
are is beyond the scope of our current worries.
Second assertion: Intermediate changes will not
affect end-to-end authenticity so long as they are reversed.
This is important for routers with a reputation of mucking with packets
in transit. As long as a router puts things back the way they were before the
packet gets to the receiver, end-to-end authenticity is preserved. If a router
does not, the packet at the receiver MUST fail authentication, because it is
not end-to-end authentic -- the sender didn't send the packet that way. More
on this later.
My third example is a recent attack scenario from Steve Bellovin:
A-----|
|------B
C-----|
Steve's attack goes something like this: C sends B an IP-in-IP
tunneled packet (not from a configured tunnel) where the outside is
authenticated using the C->B key and the inside header claims to be from A.
B verifies the packet, marks it as authentic, decapsulates the inside packet,
and processes it, thinking that it came from A. My belief here is that
this is a case of B confusing the two assurances of authentication.
B is getting intermediate authenticity -- B knows that the "tunneled" C->B
packet is authentic, but B is not getting end-to-end authenticity -- B
doesn't know that the inside packet (that claims to be from A->B) is
authentic. This is a costly mistake.
Third assertion: When processing a tunneled packet, outside
header authenticity is an issue of intermediate security and inside
header authenticity is an issue of end-to-end security. If you take my
second example and make F and B one system, this might become clearer.
Fourth assertion: If your system or network policy is FUBAR, so
are your security guarantees. If your system or network policy does something
obviously drain bamaged such as depending on intermediate security to provide
end-to-end security, then your security assurances are going to be very weak.
Some sites will want to use intermediate security for performance reasons or
because they believe that only "outside" machines are a risk. These sites must
be careful not to fall into the trap of believing that they have a higher
level of authenticity assurance than they really have.