Subject: [Fwd: Keeping/dropping existing SASL security layer]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 11 Nov 2003 20:35:01 +0000

Hopefully this clarifies things.

-------- Original Message --------
Subject: 	Keeping/dropping existing SASL security layer
Date: 	Tue, 11 Nov 2003 11:52:48 +0000
From: 	Alexey Melnikov <[email-masked]>
To: 	Rob Siemborski <[email-masked]>

The order of events is as follows (I will reference "Encryption endpoint 
box" as CC server):

1) The client connects to CC in order to request a resource FOO.
2) CC looks up its database to figure which server is managing FOO. It 
turns out to be server AA.
3). The client authenticates to AA (traffic is passing through CC).
The client and AA negotiate a security layer. Upon successful 
negotiation both ends have pointers to two function (encode/decode) and 
associated keys.
After that there might be 2 variations:
a). AA does encoding/decoding itself
or
b). AA passes encode/decode functions and associated state to CC. (CC is 
trusted)
4). The client exchanges some information with AA (regarding resource 
FOO), the exchange is recorded by BB (but at this stage BB can't decode it)

Than in case a):
5). The client requests access to resource BAR. Server AA decodes 
request and notifies CC about request to BAR.
6). CC looks up its database and determines that resource BAR is managed 
by BB.
7). The client reauthenticates to BB (encrypted traffic is going to AA 
through CC, than cleartext traffic is going from AA to BB through CC),
it negotiates no security layer. When the reauthentication is complete, 
the old layer is used.
8). The client requests access to resource BAR on the server BB (traffic 
flow is the same as in 7).
9). Evil server BB instead of responding to request BAR returns 
specially crafted response in order to verify some guesses about 
previously recorded data exchange between the client and AA. The 
response is traveling in clear from BB to AA (through CC), server AA 
encrypts the response and sends it to the client (through CC). The evil 
BB records the encrypted version of its response and by analyzing it, BB 
can try to break the previously recorded exchange between the client and AA.

or in case b):
5). The client requests access to resource BAR. Server CC decodes request.
6). CC looks up its database and determines that resource BAR is managed 
by BB.
7). The client reauthenticates to BB (encrypted traffic is going to CC, 
than cleartext traffic is going from CC to BB),
it negotiates no security layer. When the reauthentication is complete, 
the old layer is used.
8). The client requests access to resource BAR on the server BB (traffic 
flow is the same as in 7).
9). Evil server BB instead of responding to request BAR returns 
specially crafted response in order to verify some guesses about 
previously recorded data exchange between the client and AA. The 
response is traveling in clear from BB to CC, server CC encrypts the 
response and sends it to the client. The evil BB records the encrypted 
version of its response and by analyzing it, BB can try to break the 
previously recorded exchange between the client and AA.

(I think both cases are equivalent).

I am not a security export, but I think this attack allows for "CBC mode 
attack". TLS is being revised (TLS 1.1) to deal with this issue.

Alexey

-- 
Alexey Melnikov
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________