[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WG Last Call: draft-ietf-sasl-gs2-02.txt



Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> On Wed, Sep 06, 2006 at 10:55:35AM +0200, Simon Josefsson wrote:
>> For interoperability, I believe this problem should be noted, because
>> it may make it impossible to use a negotiated security layer.
>> 
>> Can we use the following and move on?
>> 
>>       <t>The "client_maxbuf" field indicate the maximum protected
>> 	buffer size the client can receive.  It MUST be 0 if the
>> 	client doesn't advertise support for any security layer, the
>> 	server MUST verify this.  Small values can make it impossible
>> 	for the server to send any protected message to the client,
>> 	due to the overhead added by GSS_Wrap, and the server MAY
>> 	reject the authentication if it detects this situation.</t>
>
> s/, the server MUST verify this//
>
> I see no value in the server verifying that client_maxbuf == 0 when the
> client doesn't ask for any security layers.
>
> Also, even with no security layers the application may benefit from the
> SASL mechanism maxbuf negotiation (again, think of small devices).
>
> So I think the entire second sentence should be removed.

How is this the buffer size value relevant when there is no security
layer?  The value is not used in any way in that case, as far as I can
tell.

Note that GSSAPI -09 contains:

   client fails the negotiation.  The client verifies that the server
   maximum buffer is 0 if the server doesn't advertise support for any
   security layer.  The client then constructs data, with the first
...
   The server verifies that the client has selected a security layer
   that was offered, and that the client maximum buffer is 0 if no
   security layer was chosen.  The server must verify that the src_name

/Simon