Subject: No response versa an empty response in the last leg of a SASL exchange

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Mar 2004 14:47:03 +0000

I am forwarding this message from the LDAPbis mailing list as suggested 
by Kurt.
Does this message have enough context to start a discussion of the issue?

-------- Original Message --------
Subject: 	Re: SASL mechanisms that return no data in last leg
Date: 	Thu, 11 Mar 2004 19:26:50 -0800
From: 	Kurt D. Zeilenga <[email-masked]>
To: 	Alexey Melnikov <[email-masked]>
CC: 	[email-masked], [email-masked]
References: 	<[email-masked]> 
<[email-masked]> <[email-masked]> 
<[email-masked]>

At 07:14 PM 3/9/2004, Alexey Melnikov wrote:
>Kurt D. Zeilenga wrote:
>
>>I'd have to agree with Alexey.  The mechanism for provide data
>>with the last leg of the exchange is optional.  That is, if there
>>is data to be sent AND the server chooses not to require
>>another roundtrip, the server can attach the data to last
>>message.
>>
>>Another point is that SASL allows the mechanism data
>>in any message of the exchange to be any octet string,
>>including a zero length string.  Hence, it seems that
>>no string and a zero length string are not necessarily
>>semantically equivalent here.
>This is correct, however LDAP is the first SASL profile I've seen that is able to represent them differently.
>Do you think that we should say something about this in the base SASL document?

I suggest we take this one to the SASL WG list.  I suspect they
will have to say something about this, such as they had to do
for zero-length v. absent authorization identity strings.  Once
they reach consensus as to what to say, we'll adapt as needed.

I suspect they will have to be declared equivalent and a
recommendation made that applications support one or the
other but not both.

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 12 Mar 2004 10:52:04 -0500 (EST)

> recommendation made that applications support one or the

Except they aren't semanticly equivilent -- just like zero length and
absent initial responses aren't equivilent.

For, example, let's have an IMAP-like protocol with an initial response
(well, SASL-IR extension) and server-last capability:

C: x AUTHENTICATE EXTERNAL

is not at all equivilent to

C: x AUTHENTICATE EXTERNAL ""

The first requires that the server send an empty initial challenge,
whereas the second means that the entire exchange is complete.

In a server-last case, with a mechanism that is server-last:

....

C: (blob)
S: x OK ""

is not equivilent to

C: (blob)
S: x OK

The first is a valid conclusion, the second is an *error* according to the
client, because it cannot tell if the server omitted the final response
(it is, after all, optional), or if it was an empty string.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Mar 2004 15:55:12 +0000

>(it is, after all, optional), or if it was an empty string.
The message wasn't talking about initial response, it was talking about 
"additional data with success".

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 12 Mar 2004 10:59:34 -0500 (EST)

> "additional data with success".

Yes, obviously.  But the situation is very similar.

As in the example above -- the client is unable to tell if the server
omitted the response (since it is, after all optional) and thus is facing
an error, or if the server actually intended there to be data there.

Maybe, though, the client can assume the server is playing on the level if
it was expecting data with success, and got neither the extra round trip
*nor* the data, implying that the data was an empty string.  But this
seems very poor.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 12 Mar 2004 10:52:04 -0500 (EST)

....

C: (blob)
S: x OK ""

is not equivilent to

C: (blob)
S: x OK

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Mar 2004 15:55:12 +0000

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 12 Mar 2004 10:59:34 -0500 (EST)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----