[OTR-dev] OTR encryption state

Paul Wouters paul at cypherpunks.ca
Thu Jan 27 13:00:04 EST 2005


On Thu, 27 Jan 2005, Greg Troxel wrote:

> I don't see why 'discard context' shouldn't send an authenticated
> message to the other side saying that, similar to an IKE Delete notify
> message.

Actually, there are problems involved with that approach. What if that
happens to be the packet you miss due to packet loss (or an active attacker).
IKE solves this by always allowing a renegotiation of IKE in plaintext from
the IP it has an ISAKMP SA for. Unfortunately, we don't have that in OTR,
since we are re-using the only channel we have between the two parties.

> IPsec is at the level of IP packets, not messages.  But if I remove an
> SA, then the new SA that gets created will have the same peer
> identifiers, but a different SPI (Security Parameters Index), and
> different keys.  SPI is a random/arbitrary value chosen by the
> receiver, used to look up the SA on receiving a packet.  It isn't a
> hash.

Yes, but again, you have the luxury of being able to communicate both
encrypted and plaintext to the same machine (where for plaintext only IKE
messages are accepted).

In fact, Openswan gives you additional protection here with the uniqueids=
option, which you can use to decide whether or not to ignore these new
plaintext IKE packets or not. If you decide to ignore them (eg to twart
spoofed IKE packets interfering with your established ISAKMP connection)
you also condemning yourself when you or your remote partner crashes or
receives a new IP address. You will have to wait the remainder of the SA
keylife before you can negotiate a new SA. Needless to say, uniqueids=
is on per default, meaning that if a known party appears on a new IP or
suddenly starts sending new plaintext IKE packets, you allow these packets
and when you have a new SA, you kill the old one.

> Also, when you kill racoon, it sends authenticated delete messages to
> the peer, which removes the SAs it has with the killed racoon.

Assuming th epacket makes it. You'll be suprised how often Notify Delete's get
lost, especially on roadwarrior type setups. (or worse, someone losing their
access point or just closing the lid on their laptop, causing no Delete/Notify
message to be sent at all).

> This isn't the sort of security problem that Ian is (rightfully) so
> worried about, because removing the context doesn't allow cleartext
> messages 

The real potential information leak is at the restarted client. That user
might accidently send a cleartext message, forgetting his client or
connection got restarted. One way to resolve this would be to initiate OTR
for all buddies you had an OTR connect with when shutting down that are
currently listed as online, but I fear that would only add to the amount
of fingerprint windows I need to click away in the morning that I already
have.

Paul 




More information about the OTR-dev mailing list