|Summary:||tokxts bug in 1.4.5|
|Product:||[Retired] Red Hat Linux||Reporter:||Pekka Savola <pekkas>|
|Component:||cipe||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED DEFERRED||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2001-02-12 23:09:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Pekka Savola 2001-02-12 18:42:13 UTC
tokxts option is being disregarded, which may lead to only the static secret key being used under certain circumstances. This might become a (very limited) security problem. tokxts is not used by default, or listed in the default options file, so this isn't too critical..but probably worth updating before the final.. --- 8< ---- Date: Sun, 11 Feb 2001 02:43:38 +0100 From: Olaf Titz <email@example.com> To: firstname.lastname@example.org Subject: BUG: tokxts option Short summary: The tokxts option in all versions of CIPE up to and including 1.4.5 does not work. It is recommended not to use this option. Technical description: Starting with version 1.2.0, CIPE sends a timestamp mark in the key exchange control packets. The purpose is for the receiver to detect and reject old control packets. This facility in the receiver is turned off by default and has to be activated with the "tokxts" option. This option is not included in the sample configuration. Up to version 1.4.5, the ciped process does mis-interpret the timestamps in the received control packets. As a result, it discards all control packets when this option is used. This may result in no key exchange taking place and all data being inadvertently encrypted using the static key only. The problem is aggravated by an unrelated bug which causes ciped not to log the timestamp problem unless in debug mode. Workaround: Remove the tokxts option from the cipe option files. Fix: Upgrade to CIPE 1.4.6 or later.
Comment 1 Glen Foster 2001-02-12 23:09:54 UTC
This defect is considered MUST-FIX for Florence Gold release
Comment 2 Nalin Dahyabhai 2001-02-23 20:19:57 UTC
1.4.6 breaks on-the-wire compatibility with 1.4.5 because the packet format is different. Because we'd like to continue to interoperate with the version shipped in 7, we'll have to defer this.