[OTR-dev] OTR encryption state

Greg Troxel gdt at ir.bbn.com
Thu Jan 27 10:27:47 EST 2005


> Removing autorenogiation 
> solves this, as you stop the OTR session and OTR won't begin again with 
> that contact until you ask it to.  Unfortunately, now that it's put 
> that way, it becomes clear that -this- opens up a problem with initial 
> OTR sessions... there's no way to distinguish:
> a) a conversation I ended (i.e. we were talking, i told it to stop, and 
> therefore we should not be automatically reconnected) from
> b) an initial conversation with someone with whom I have a confirmed 
> fingerprint and therefore should automatically be connected to

Exactly - the ambiguity between 'discard context' and 'don't try
again'.

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.

> > So I restart racoon,
> > which deletes all the SAs and then tries to negotiate on the next
> > packet because it gets an ACQUIRE.
> > That's the sense of 'nuke this context' that I'm talking about.
> >
> > The other action would be "change the SPD so that crypt is no longer
> > required".
> >
> I see. Do the session IDs change in the state situation we've been 
> discussing, that is if I hit 'cancel' and then you message me twice 
> (once and receive the error message, at which point we autorenegotiate 
> and have a secure sesion, and then a second time which is an encrypted 
> message which goes through succesfully)?

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.

Also, when you kill racoon, it sends authenticated delete messages to
the peer, which removes the SAs it has with the killed racoon.
This isn't the sort of security problem that Ian is (rightfully) so
worried about, because removing the context doesn't allow cleartext
messages - that's control by the policy database.  And, the delete is
authenticated.

So really I'm arguing for an IPsec-like separation of policy and SA
databases.  In PFKEY_v2 (specifies kernel/IKE interaction for SA/SPD
manipulation), SPD entries match traffic and can have multiple values:

  discard: bit-bucket the traffic.
  require: SA required.  If none, send acquire and drop packet.
  use: SA preferred.  if none, send acquire, but send packet anyway
  none: don't use SA.  send packet in clear.  don't send acquire

These work on receive, too, so you can drop packets that aren't
protected by IPsec if the incoming policy says require.

Right now OTR always has an implicit policy setting of 'use'.
I'm suggesting to add required and none, orthogonal to a 'delete
context' operation.




More information about the OTR-dev mailing list