[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Human I&A, IPsec, and their non-relationship
Back in Toronto we had some pretty heavy off-line debates over
per-user vs per-host keying.
I basically took your position: a single key per host pair was enough,
and we didn't need a big SAID. Several others, notably Ran Atkinson
and Steve Bellovin, argued strongly for at least supporting the
facility.
I think I also heard the chosen-plaintext argument (at least it
doesn't sound new) and it didn't convince me either. Any cipher that
can't resist a chosen plaintext attack is certainly not one to use in
this day and age.
A somewhat better argument is that not all traffic between a pair of
hosts is equally sensitive. One could respond that you just pick a
cipher that's strong enough for the most sensitive traffic and then
use it for everything, but this might be considered prohibitive on
slower machines.
But the argument that finally persuaded me to concede was the
possibility of one user decrypting the traffic of another user on the
same host by playing it back with the SAID changed. It does seem that
you could prevent this with some sort of user ID buried inside the
packet, as long as it's protected against modification. The closest we
come to user IDs are the TCP and UDP port numbers, but it's obvious
that this isn't a particularly strong mechanism on, say, BSD. I just
wait for my victim to finish with his socket. Then I bind to it, play
back the traffic (easier with UDP than TCP) and have the kernel
decrypt it for me.
So some sort of "real" IPSP user ID would be needed. Essentially, it
would be a protected SAID. Although there are some advantages to this
(e.g., preventing traffic analysis at per-user granularity) it would
still have to be in addition to the existing clear SAID mechanism
which is needed to handle host-to-host keying issues (e.g., multiple
levels of security vs performance). And then you'd have to show that
there is no way for one OS user to read another's traffic even though
they share the same keys.
It does seem on the surface that simply giving each user his own
session key is the most effective way to enforce user-user separation,
as well as adapting to different security/performance tradeoffs.
Phil
References: