Skip to content
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

Closed
michael-o opened this issue Aug 12, 2021 · 1 comment · Fixed by #46
Closed

HTTPSPNEGOAuth does not use advertised mechanism in class name as GSS-API mech #41

michael-o opened this issue Aug 12, 2021 · 1 comment · Fixed by #46
Labels

Comments

@michael-o
Copy link
Contributor

michael-o commented Aug 12, 2021

In the init method:

def __init__(self, mutual_authentication=DISABLED, target_name="HTTP",
delegate=False, opportunistic_auth=False, creds=None,
mech=None, sanitize_mutual_error_response=True):

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:

  1. I believe this violates RFC 4178 section 3.2
    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.
  2. Not a SPNEGO token is sent, but a Kerberos 5 one, some GSS-API implementations choke on this token, e.g, Java GSS rejects this token because it is not wrapped in a SPNEGO token as required by 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.

@stale stale bot added the stale label Sep 9, 2021
@stale stale bot closed this as completed Sep 23, 2021
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
Copy link
Contributor Author

Sample exception from a JGSS acceptor:

2021-12-22T17:06:02.350 WARNUNG [https-openssl-apr-8444-exec-43] net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate The Negotiate (SPNEGO) authentication token is invalid: YIIM2gYJKoZIhvcSAQICAQBuggzJMIIMxaADAgEFoQMCAQ6iBwMFAA...0WW16gS+vSg
        GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept
                at sun.security.jgss.GSSCredentialImpl.getElement(GSSCredentialImpl.java:600)
                at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:317)
                at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
                at net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate(SpnegoAuthenticator.java:148)
                at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:626)

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
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant