Deserializing a Kerberos Token

Question

while fetching a Kerberos token from Server (most likely, some kind of MS software), I am getting the response below.

As you can see, there is nothing like an expiration time, or the like, like we get with JWT. So I wondered, whether the token contains that information, and considered to deserialize it. However, if that is possible, I fail to identify the algorithm, that was used to serialize the information. (I would expect Base64, or the like, but it's not.)

So, question: Any ideas on how to do that?

Thanks,

Jochen

<?xml version="1.0" encoding="utf-16"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <GetKerberosTokenResponse xmlns="http://tempuri.org/">
      <GetKerberosTokenResult>YIIOcQYJKoZIhvcSAQICAQBugg5gMIIOXKADAgEFoQMCAQ6iBwMFAAAAAACjggy8YY
... Lots of lines removed for brevity ...
IWRzKQKdEnG9mT3U2qIKeS/Mhp+sif9O9212sEFgwH1WGI=</GetKerberosTokenResult>
    </GetKerberosTokenResponse>
  </soap:Body>
</soap:Envelope>

Answer 1

Kerberos version 5 uses ASN.1 DER as its serialization format. The result you have is Base64-encoded DER data representing an ASN.1 object; you can feed it through "ASN.1 decoder" tools such as dumpasn1 or openssl asn1parse or asn1js.

You can find the Kerberos ASN.1 modules in RFC 4120, Section 5.3 as well as Appendix A, although what you actually have in the SOAP response is a SPNEGO NegTokenInit object from RFC 4178 Appendix A (containing a Kerberos AP-REQ object, which then contains the actual Ticket as well as a one-time authenticator).

The expiry time of a Kerberos ticket, as well as its other metadata, is found within the EncTicketPart field of the ticket, which is encrypted using the service key (the one that's found in the service's keytab or derived from service account password). This is because Kerberos does not use digital signatures – it is based around pre-shared keys and symmetric encryption.

Normally, if you were the Kerberos client requesting the actual tickets, you would receive another copy of the ticket metadata decryptable with your own (client) key; then you would use the ticket and its session key to generate the authenticator and produce the token. But in you case, you don't have any of that – the SOAP web­app gets tickets on your behalf and directly produces the one-time auth token – so all data you'll find inside is encrypted with the service's key (so that the client could not tamper with it, of course).

So in other words, you won't be able to decrypt the contents of the ticket unless you have the service keys.