-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTPSPNEGOAuth does not use advertised mechanism in class name as GSS-API mech #41
Labels
Comments
michael-o
added a commit
to michael-o/requests-gssapi
that referenced
this issue
Dec 22, 2021
Use the correct mechanism as described by * RFC 4559, section 4: The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens that the specific mechanism type specifies. * RFC 4178, section 3.2: The GSS-API initiator invokes GSS_Init_sec_context() as normal, but requests that SPNEGO be used. SPNEGO can either be explicitly requested or accepted as the default mechanism. Since both MIT Kerberos and Heimdal use Kerberos 5 as their default mechanism we must explicitly request SPNEGO. Passing raw Kerberos tokens to the acceptor is a violation of these RFCs and some implementations complain about, thus they always need to be wrapped. This closes pythongssapi#41 Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
Sample exception from a JGSS acceptor:
|
michael-o
added a commit
to michael-o/requests-gssapi
that referenced
this issue
Dec 22, 2021
Use the correct mechanism as described by * RFC 4559, section 4: The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens that the specific mechanism type specifies. * RFC 4178, section 3.2: The GSS-API initiator invokes GSS_Init_sec_context() as normal, but requests that SPNEGO be used. SPNEGO can either be explicitly requested or accepted as the default mechanism. Since both MIT Kerberos and Heimdal use Kerberos 5 as their default mechanism we must explicitly request SPNEGO. Passing raw Kerberos tokens to the acceptor is a violation of these RFCs and some implementations complain about, thus they always need to be wrapped. This closes pythongssapi#41 Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
michael-o
added a commit
to michael-o/requests-gssapi
that referenced
this issue
Jan 14, 2022
Use the correct mechanism as described by * RFC 4559, section 4: The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens that the specific mechanism type specifies. * RFC 4178, section 3.2: The GSS-API initiator invokes GSS_Init_sec_context() as normal, but requests that SPNEGO be used. SPNEGO can either be explicitly requested or accepted as the default mechanism. Since both MIT Kerberos and Heimdal use Kerberos 5 as their default mechanism we must explicitly request SPNEGO. Passing raw Kerberos tokens to the acceptor is a violation of these RFCs and some implementations complain about, thus they always need to be wrapped. This closes pythongssapi#41 Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
michael-o
added a commit
to michael-o/requests-gssapi
that referenced
this issue
Jan 16, 2022
Use the correct mechanism as described by * RFC 4559, section 4: The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens that the specific mechanism type specifies. * RFC 4178, section 3.2: The GSS-API initiator invokes GSS_Init_sec_context() as normal, but requests that SPNEGO be used. SPNEGO can either be explicitly requested or accepted as the default mechanism. Since both MIT Kerberos and Heimdal use Kerberos 5 as their default mechanism we must explicitly request SPNEGO. Passing raw Kerberos tokens to the acceptor is a violation of these RFCs and some implementations complain about, thus they always need to be wrapped. This closes pythongssapi#41 Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
jborean93
pushed a commit
that referenced
this issue
Jan 16, 2022
Use the correct mechanism as described by * RFC 4559, section 4: The "Negotiate" auth-scheme calls for the use of SPNEGO GSSAPI tokens that the specific mechanism type specifies. * RFC 4178, section 3.2: The GSS-API initiator invokes GSS_Init_sec_context() as normal, but requests that SPNEGO be used. SPNEGO can either be explicitly requested or accepted as the default mechanism. Since both MIT Kerberos and Heimdal use Kerberos 5 as their default mechanism we must explicitly request SPNEGO. Passing raw Kerberos tokens to the acceptor is a violation of these RFCs and some implementations complain about, thus they always need to be wrapped. This closes #41 Signed-off-by: Michael Osipov <michael.osipov@siemens.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the init method:
requests-gssapi/requests_gssapi/gssapi_.py
Lines 110 to 112 in 74766a6
None
is passed to the mech which means MIT Kerberos/Heimdal decide which will be almost always Kerberos 5 and not SPNEGO.This causes two problems:
a) The GSS-API initiator invokes GSS_Init_sec_context() as normal,
but requests that SPNEGO be used. SPNEGO can either be explicitly
requested or accepted as the default mechanism.
Since SPNEGO isn't the default mech in both GSS-API implementation nor is SPNEGO passed as OID it does not comply with this RFC.
If using Java GSS on the target server it always requires to provide custom value to this auth class to meet the above which is expected to be default. Other OSS implementations correctly pass a SPNEGO OID w/o a ctor param to modify it and work flawlessly, e.g., browsers, libcurl, libserf.
Willing to provide a PR for this. I am currently using this as an unnecessary workaround.
Question on SO: https://stackoverflow.com/q/57729499/696632 and there are numerous other reports on the internet.
The text was updated successfully, but these errors were encountered: