Support KRB5 tokens in Negotiate headers

[shanmugh]

As was discussed in this issue (#278) it is currently not possible to authenticate using a KRB5 token. After some investigating of the token formats, it looks like the KRB5 data can be embedded into a SPNEGOToken to complete the authentication. This will be a huge benefit for clients which are still generating tokens with KRB5 MechType OID.

@jcmturner Please let me know if this a viable solution for supporting KRB5 token in the library.

[shanmugh]

Had to close and re-open the PR since the previous CI timed out.

[jcmturner]

Hi @shanmugh, thanks for your contribution, however I don't think this is the right approach. I think when unmarshalling bytes into an SPNEGOToken those bytes should be of that type rather then taking the bytes of a KRB5Token and converting them into an SPNEGOToken.

I'm not sure that this is the root cause of the issue in #278. You mention in #278 that curl sends a KRB5Token. Can you send me the command you are using. When I have looked at curl before it is still wrapping the KRB5Token in an SPNEGOToken on the client side before sending to the server so this should work. If it is sending a KRB5Token without wrapping in SPNEGO then it is not doing SPNEGO auth but something else.

Thanks.

[shanmugh]

You are correct, I misquoted the issue in #278.

Here is some additional information regarding the curl interaction that appears to be sending a KRB5 token. I am afraid the default Centos7 curl version does not support SPNEGO token out of the box.

$ curl -v --negotiate -u : https://service.example.biz/api
* About to connect() to service.example.biz port 443 (#0)
*   Trying 10.248.X.X...
* Connected to service.example.biz (10.248.X.X) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*     subject: CN=service.example.biz,OU=Example Security,O="Example, Inc.",L=San Francisco,ST=California,C=US
*     start date: Feb 25 00:00:00 2019 GMT
*     expire date: Mar 04 12:00:00 2020 GMT
*     common name: service.example.biz
*     issuer: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US
> GET /api HTTP/1.1
> User-Agent: curl/7.29.0
> Host: service.example.biz
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Content-Type: text/plain; charset=utf-8
< Www-Authenticate: Negotiate
< X-Content-Type-Options: nosniff
< Date: Wed, 15 May 2019 23:54:10 GMT
< Content-Length: 15
<
* Ignoring the response-body
* Connection #0 to host service.example.biz left intact
* Issue another request to this URL: 'https://service.example.biz/api'
* Found bundle for host service.example.biz: 0x1403ee0
* Re-using existing connection! (#0) with host service.example.biz
* Connected to service.example.biz (10.248.X.X) port 443 (#0)
* Server auth using GSS-Negotiate with user ''
> GET /api HTTP/1.1
> Authorization: Negotiate YIICaQYJKoZIhvcSAQICAQBuggJYMIICVKADAgEFoQMCAQ6iBwMFACAAAACjggFmYYIBYjCCAV6gAwIBBaENGwtUV0lUVEVSLkJJWqIqMCigAwIBA6EhMB8bBEhUVFAbF2NvbXB1dGUtZ2tlLnR3aXR0ZXIuYml6o4IBGjCCARagAwIBEqEDAgEBooIBCASCAQQKtx45kYkoFmFJGWW6HReRjjwKlS/nv9owLY8EnpZsN0LPB+qNu2khYhCgvqURRObrbyIV1D21BiQKsOBb5vd0AUQNBXSyu+vkV0rELyj6CJfUG61FcSv3fHH+8lMSF/iuBkj4KK2ckr70vkPAfdZ12Fpv7QXoOaoeYu8qCg+3ymc8dxjY5oybM7RiD2fIikEaV7mLGYcQPCxbba/zIvunfWXfxBSLQ6C26VOn9366MBdeF5dEPtrLJutMTCsWLhq1VBbYeUV2T07VpfmsffsZZNEgZsMBiocF0OGVCCFktzxWjWPJiwZfZm/Pn4WMxw/TlDNlqFIE14IYrbX0ufdgKUe0EKSB1DCB0aADAgESooHJBIHG2uTsWs6nBxK92cYHwx8OfS2GWmrjIK5oZdZBgTgazVARkq1Q52jgToBZP/eK6ytZQbHVZUAhxuxmPRImjzUYiWvjoxB+LhZkgNJ4+06HkWKTUzp43xJQwCg9QuE4oU72o212WjltOJE5T2SMloG6Y9/cbpkBKcHRsxIyVAprodU04yeuE89eeAOUHBWuojsDehb6A23SNgyJdqCO90DvFKHRFPvxNU81WFFr+LRx/MyecE2tSe4T3Ng5ln4M6JB9aIGeBCTJ
> User-Agent: curl/7.29.0
> Host: service.example.biz
> Accept: */*
>
< HTTP/1.1 200 OK
< Audit-Id: 3df8a3bd-dd4b-46de-8fda-736ba64ff8d1
< Content-Length: 183
< Content-Type: application/json
< Date: Wed, 15 May 2019 23:54:10 GMT
< Www-Authenticate: Negotiate oRQwEqADCgEAoQsGCSqGSIb3EgECAg==
<
Hello
* Closing connection 0

$ curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.36 zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets

I am happy to redo the patch if you can point out the correct approach. Thanks for the feedback.

[BryceDFisher]

I think you need to check for both the OIDKRB5 and the OIDLegacyKRB5. These seem to be interchangeable with Windows Server 2016

[jcmturner]

@shanmugh thank you for the contribution.

This should now be addressed through PR #366. It uses a slightly different approach to the one you have provided here. I will be looking to release this shortly as an enhancement to the new v8 major version.