[SERVER-27252] Relax constraint on client's maximum size output message in SSPI implementation of SASL GSSAPI mechanism Created: 01/Dec/16  Updated: 01/Feb/18  Resolved: 02/Dec/16

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Issue Links:
Related
related to JAVA-2385 GSSAPI authentication fails against W... Closed
Participants:

 Description   

The RFC states that:

The client then constructs data, with the first octet containing the
bit-mask specifying the selected security layer, the second through
fourth octets containing in network byte order the maximum size
output_message the client is able to receive (which MUST be 0 if the
client does not support any security layer)

There is a bug in the JDK where by default it does not send 0 for the maximum size output_message, even though it indicates no support for any security layer.

The SSPI implementation in the server correctly checks this: https://github.com/mongodb-labs/winkerberos/blob/master/src/kerberos_sspi.c#L461-L464
(Note that this link reflects code that is similar to what the server does, but is not the actual code. The actual code is in the closed-source enterprise module.)

This request is to relax that check and instead only check the first byte, ignoring the last three entirely. That's what Cyrus SASL does.

Note that this issue prevents any Java client from authenticating via GSSAPI to a MongoDB server running on Windows.



 Comments   
Comment by Jeffrey Yemin [ 02/Dec/16 ]

I've now determined that this can instead be worked around in the Java driver, so this can be closed.

Generated at Thu Feb 08 04:14:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.