On Thu, 21 Jun 2012, Markus Moeller wrote:
> Do you have the token you received as base64 encoded in the log
> or better in a wireshark capture ? This could help identifying if
> the un-encrypted elements in the tokebn are correct.
Well I've had the token before but hadn't worked out a way to pull it
apart and up until today hadn't managed to get a matching wireshark
capture but I now have so I think I now understand things a bit better
(though don't have a fix as yet).
Here is the token from a fail:
2012/06/21 14:06:41| squid_kerb_auth: DEBUG: Got 'YR
YIICyAYGKwYBBQUCoIICvDCCArigGDAWBgkqhkiC9xIBAgIGCSqGSIb3EgECAqKCApoEggKWYIICkgYJKoZIhvcSAQICAQBuggKBMIICfaADAgEFoQMCAQ6iBwMFAAAAAACjggFmYYIBYjCCAV6gAwIBBaEPGw1FQ1MuVlVXLkFDLk5aoiswKaADAgEBoSIwIBsESFRUUBsYd3d3LWNhY2hlMi5lY3MudnV3LmFjLm56o4IBFzCCAROgAwIBEqEDAgEBooIBBQSCAQHPjG8lCnGsCUUzvzF5R0WMoOI1cQXyZE7jcXVGTptHCww18sHxjFlR5uCBMubTqbqy8OrhOwOZkNlJ6vkQesG199bttwDhViLgr62AGqS7bXww336Bye1UjgGOrbtgxkIRlckgZkhwO8aOYGzbbVMiwwUl9XFvI8hpCPD1LlG/TiD47tSUdut7AvQ8GsCfb/wNgcm2BOt5Li9CjforhaElvCJqwpbPV6ht54yuNXeLjjL5TIKd2Lz36RL7w30cwkXoLgSw2dcdtjSu15nHHDyqlIaVe4F4vyeCUJYePveK8I8zTBT9vZjbu/Lv22qVEe/BilBg6ZY6++bAf5E/MO440qSB/TCB+qADAgESooHyBIHvRa9wiAOgMvzrkJi9QbirH51Gc6K9mdOVxrOB5R0O4JFsPGyixyYZzdyLUxu297Gp6lN+yiGw14v2vDqx3oiNAw+KjKsoPYEkj6P+i3CR9X+wtnlftgLmYAIOxYP285GWmXktnyEjFrDvhWuLibspFlY7US3lvtIJvzxLyqUxBsXmuAPlRInNgmbH7VGbrTwg58JzOVwnmXYP+IoAoDHsXm6p0RWOLxosDhHC//lGzhMPYUjtNpAy344EPCmltJCWPazMP11rMeEGeyP4S1CurQSOBnqPtIiFMDnhqonhJMtYJJeAB16RSFDB9pb6r2k='
from squid (length: 959).
2012/06/21 14:06:41| squid_kerb_auth: INFO: continuation needed
2012/06/21 14:06:41| squid_kerb_auth: DEBUG: Got 'KK
YIICyAYGKwYBBQUCoIICvDCCArigGDAWBgkqhkiC9xIBAgIGCSqGSIb3EgECAqKCApoEggKWYIICkgYJKoZIhvcSAQICAQBuggKBMIICfaADAgEFoQMCAQ6iBwMFAAAAAACjggFmYYIBYjCCAV6gAwIBBaEPGw1FQ1MuVlVXLkFDLk5aoiswKaADAgEBoSIwIBsESFRUUBsYd3d3LWNhY2hlMi5lY3MudnV3LmFjLm56o4IBFzCCAROgAwIBEqEDAgEBooIBBQSCAQHPjG8lCnGsCUUzvzF5R0WMoOI1cQXyZE7jcXVGTptHCww18sHxjFlR5uCBMubTqbqy8OrhOwOZkNlJ6vkQesG199bttwDhViLgr62AGqS7bXww336Bye1UjgGOrbtgxkIRlckgZkhwO8aOYGzbbVMiwwUl9XFvI8hpCPD1LlG/TiD47tSUdut7AvQ8GsCfb/wNgcm2BOt5Li9CjforhaElvCJqwpbPV6ht54yuNXeLjjL5TIKd2Lz36RL7w30cwkXoLgSw2dcdtjSu15nHHDyqlIaVe4F4vyeCUJYePveK8I8zTBT9vZjbu/Lv22qVEe/BilBg6ZY6++bAf5E/MO440qSB/TCB+qADAgESooHyBIHvHPaawYzgkC67x/LP8OM72fiDvqj5fq/qXSHOWZjfZIRIR+H2FsbjrC5qcymo+Qh7u/pwHur3ZlY/SiPUC+tQlY41NEFmcmrLpNfQW21gsABa2podl1P/lSaQE4KgXYtp8sxZwKUX5/4a44XzWOo2PETgF7C+qKDLnyjripE5gWRYKt/WVH2dXYBJ3Lf/8tIqbTzOp0DvJ3XvjpROlLRpaBF9oUVXCcrqVjPKlQfrsN8kNZUWDubaUuSme1ZJvZek2QdH/gAe7ziXmHuLRiqe4b9aIolIJ6qCMa7Nu6XzPoIvAU8gFb3gjhKr1dKPGT0='
from squid (length: 959).
2012/06/21 14:06:41| squid_kerb_auth: ERROR: gss_accept_sec_context()
failed: A token was invalid. unknown mech-code 1859794441 for mech
unknown
The failures have always this additional step of requesting
continuation then sending the error response.
This token equates to a packet from a Safari on a Mac trying to
connect to facebook and wireshark tells me the token breaks down to
GSS-API Generic Security Service Application Program Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
Simple Protected Negotiation
negTokenInit
mechTypes: 2 items
MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
mechToken: 6082029206092a864886f71201020201006e820281308202...
krb5_blob: 6082029206092a864886f71201020201006e820281308202...
KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_tok_id: KRB5_AP_REQ (0x0001)
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 00000000
Ticket
Tkt-vno: 5
Realm: ECS.VUW.AC.NZ
Server Name (Principal): HTTP/www-cache2.ecs.vuw.ac.nz
enc-part aes256-cts-hmac-sha1-96
[...]
The interesting thing about this is that we have our browsers and
caches's set up so that a proxy.pac controls which cache our machines
would normally talk to but with failover to the other cache. This
particular Mac would normally talk to the other cache and that ticket
is for the _other cache_. So for some reason its decided to fail over
to this cache but present a ticket for the other.
Having got the "unknown mech-code" error back from squid_kerb_auth,
squid sends back another Proxy Auth Required error to the Mac which
then retries with another token that this time has a ticket for the
correct cache and everything succeeds.
Why the Mac has decided to fail over, I dont know.
Why it sends the wrong ticket, I don't know.
Probably wouldn't be an issue at all except for the error messages in
the logs AND for the fact that there seems to be a file descriptor
leak in this particular error case in the heimdal libraries.
cheers
mark
