Suggestions for changes/improvements for the CIPE protocol|
Alan Stern <stern,AT,rowland,DOT,harvard,DOT,edu>|
Mon, 21 Oct 2002 15:59:46 +0200|
Suggestions for changes/improvements for the CIPE protocol
Here are some ideas for ways to improve the security of the CIPE
protocol. These are things that occurred to me after reading the
description of the protocol used in CIPE 1.5.4. They involve fairly
small changes, but unfortunately they are not backward compatible with
the current protocol.
These ideas are just suggestions, things to think about or to consider
for implementation. They do not imply any criticism of CIPE as it
stands; they are only meant to provoke thought and comment. You may
feel some of the ideas are good; you may believe some of them are
excessive or not needed (in fact, I even think that some of them go
too far). That's okay, and I won't mind if you say so.
The two most notable security weaknesses of the CIPE protocol are
potentially lengthy use of the static key and limited protection
against replay attacks. This proposal addresses both these issues.
Any comments or discussion regarding the proposal are welcome.
PROTECTION OF STATIC KEYS
With the use of PKCIPE a new static key is computed for each session,
so exposure of static keys is not as big a problem as before.
However, PKCIPE isn't used everywhere, and in any event the proposed
solution is so simple that there is no reason not to use it.
The static key is normally used during key negotiation, both during
the initial setup and later in the session if an NK_IND or NK_ACK
packet is lost. In fact, since the dynamic key is invalidated as soon
as a key exchange starts, if there is any problem with the exchange
the static key will be used for all further transmissions -- in-band
and out-of-band -- until a new dynamic key is agreed upon.
The proposed solution is this: All data (in-band) packets _must_ be
encrypted using the dynamic key; if there is no dynamic key then data
packets will be silently dropped and not transmitted. To allow data
packets to continue to be sent during key exchange, we must declare
that the sender does _not_ invalidate its dynamic key when sending an
NK_IND message. Instead it will continue using the old dynamic key
until it receives an NK_ACK from the peer or until the old key
This leaves the problem of handling the situation where an NK_ACK
reply is lost. The receiver is expecting to see the new dynamic key,
but the sender doesn't realize that and continues using the old one.
To solve this problem, the receiver must store two dynamic keys,
both the old one and the new one. Each incoming packet must be
decrypted first with the new key; if the CRC check fails then it must
be decrypted using the old key. Receipt of a packet that uses the new
dynamic key is the indication that the old key can be erased. If the
NK_ACK truly was lost, soon enough the sender will time out and send
another NK_IND with another new key. This can simply overwrite the
previous value for the new key, and the negotiation proceeds as before.
With this mechanism, the static key is only used at the start of a
session. After that all communications will be encrypted using a
PROTECTION AGAINST REPLAY ATTACKS
Replay of data packets is not really an issue. Because of the limited
lifetime of dynamic keys, the replay must occur within a short
window. Furthermore, even with normal unencrypted Internet
communications, there is no guarantee that an IP datagram won't get
delivered more than once.
Replays mainly cause problems for key-exchange (out-of-band) packets.
The standard means of protection is to use timestamps, but the
current protocol makes them optional because of the difficulty of
insuring that the system clocks of the two hosts are synchronized.
The proposed solution is to make timestamps mandatory for out-of-band
packets, and perhaps even decrease the recommended window of agreement
to 10 seconds, and to do this in a way that does not require the
system clocks to be synchronized. This is easily accomplished by
having each host keep track of the offset between its clock and its
peer's. The timestamp fields in the packets are then set by adding
the offset to the current system time.
Here is the simplest way to do this. The originator generates an
unencrypted echo-request (CT_PING) with timestamp A. The receiver
transmits an unencrypted echo-reply (CT_PONG) with timestamp B. These
packets are allowed to be unencrypted since they contain no secret
information. And in fact, during session setup they must be
unencrypted, because the two hosts do not know the proper timestamp
offsets needed to create valid encrypted packets.
The sender of the original request receives the reply back at time C.