[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cookies only make you fat
I just read Radia and Charlie's paper on IPSEC. I agree with the points they
make there against the IPSEC cookies. I now believe that cookies do nothing
but make the clients fat.
First consider the reason for having the cookies, to avoid the need to
maintain state in the server during the negotiation. But the negotiation
only takes multiple round trips because it overloads the protocol with
multiple functions (credential exchange) and attempts to conceal the
identities of the participants (poorly as it happens).
If the key agreement was a single round trip we would not require cookies.
Mutual agreement of a key is possible in one round trip.
Key agreement is not mutual authentication. It is slightly less. The
criteria for a mutual key agreement is that at the end of the protocol the
two parties have knowledge of the same shared token bound to the same
context data if and only if they are the parties that authenticated
themselves with the specified credentials. In mutual authentication there is
the additional requirement that the two parties know the status of the
other. But that is not our requirement here, all that is required is that
Alice only gets the correct token if and only if she is Alice.
In XKASS we use a single round trip, I hope to get the paper out by the end
of the week.
The other reason the key agreement is so long is because there is a half
baked attempt at concealling the identity of the principals. I use the term
'half-baked' in the technical sense, the scheme conceals some but not all of
the characteristics of the parties. Some observations:
1) True anonymous/anonymous contact in which neither party has any knowledge
of the other in advance is impossible (unless someone implements randomcast
routing in which your packets are sent off to a randomly chosen Internet
address). One party is going to have to be listening on a specific port of a
specific IP address somewhere.
2) If we assume that it is the responder whose credentials are 'known' in
some sense then the people who really, really want to have unobservable
communications can achieve them by simply issuing the clients with books of
disposable, one time use credentials [note that OnSite is sold on a 'per
seat basis' not 'per certificacte' any more so please don't ascribe unfair
reasons to the suggestion].
3) Alternatively assume that when Alice reauthenticates that she uses her
old expired SA (or similar data thrown up for the purpose during the
exchange) to encrypt the exchange. That would limit the identity leakage gap
to the first contact. I strongly suspect that is sufficient for many
purposes, or at least enough to serve.
4) The same information leaks out in the IP address in any case, so unless
we are going across a true Chaumian network or we are using the Starbucks
coffee house 802.11b alternative...
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
Phillip