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

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


Simon Josefsson wrote:


Looking at specifications, RFC 2831 does not impose any limits on
maxbuf at all.  GSSAPI restricts maxbuf to be 0..0xFFFFFF because the
integer field is 3 bytes.  RFC 2831bis changes RFC 2831 and enforces
16 <= maxbuf <= 16777215.  I don't know where this minimum comes from?

Each SASL packet will have the 16byte long MAC.


There doesn't seem to be much consistency here.  The only consistent
value is in GSSAPI and RFC 2831bis, where the upper limit is 2^24.
That limit is not imposed by the core SASL specification, though,
which has 2^32.

For interoperability, I believe this problem should be noted, because
it may make it impossible to use a negotiated security layer.

Sure. Cyrus SASL had the check for minimum maxbuf for some time.


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>

     <t>The "server_maxbuf" field indicate the maximum protected data
	buffer size the server can receive.  It MUST be 0 if the
	server doesn't advertise support for any security layer, the
	client MUST verify this.  Small values can make it impossible
	for the client to send any protected message to the server,
	due to the overhead added by GSS_Wrap, and the client MAY
	reject the authentication if it detects this situation.</t>

That is fine by me. I would even change the last MAY to SHOULD.