[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

Hi,

I found the required definitions in rfc1964


I have added support for current SVN to decode these "checksums" and also the KRB_CRED contained therein.


However,  I have not had time to add handling of
EncKrbCredPart     so there will be a BER error in
the decode towards the end of the KRB_CRED
expansion.

Since I will be travelling this week I can not fix the EncKrbCredPart
until next week    but the support in SVN  
17272 is better than nothing.


Please try SVN 17272

On 2/12/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:

Interesting capture.

I  have looked at the checksum   and it is a HUGE checksum   and ethereal does decode it properly.


However.
Eventhough it is one single checksum blob as per rfc4210     they have clearly added some extensions.
Forexample, in both traces  the checksum starts with 0x10000000000...    which looks very nonrandom to me.

In the example with the HUGE checksum   they have stored a KRB_CRED blob (not a tgt)  starting at offset 28 in the checksum.


Do you know of any documentation available that explains how and what they store inside the checksum blob?

On 2/12/06, Xiaoguang Liu <syslxg@xxxxxxxxx > wrote:

recently I managed to make the Ethereal decrept kerberos. It is so cool. Thanks the team to delivery such a wonderful feature.

this week I studied kerberos delegation. Ethereal helped a lot on this. But  I found it could not parse the Kerberos delegation packet very well.

here I attached trace files and keytab file as an example.

in delegation.cap, user administrator@xxxxxxxxxx accessed a website, fc4.denydc.com. Since fc4 is set to trusted for delegation, administrater will send his TGT to fc4 when he sends HTTP/fc4 ticket in HTTP-get request. Please check frame 18 in delegation.cap:
-------
Frame 18 (746 bytes on wire, 746 bytes captured)
Ethernet II, Src: Microsof_a7:ab:0c (00:03:ff:a7:ab:0c), Dst: Microsof_b2:ab:0c (00:03:ff:b2:ab:0c)
Internet Protocol, Src: 10.5.12.5 (10.5.12.5), Dst: 10.5.15.5 (10.5.15.5 )
Transmission Control Protocol, Src Port: 1104 (1104), Dst Port: http (80), Seq: 2921, Ack: 1, Len: 692
Reassembled TCP Segments (3612 bytes): #14(1460), #16(1460), #18(692)
Hypertext Transfer Protocol
    GET /lxgdoc/ HTTP/1.1\r\n
        Request Method: GET
        Request URI: /lxgdoc/
        Request Version: HTTP/1.1
    Accept: */*\r\n
    Accept-Language: en-us\r\n
    Accept-Encoding: gzip, deflate\r\n
    User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)\r\n
    Host: fc4\r\n
    Connection: Keep-Alive\r\n
    Authorization: Negotiate YIIJ2gYGKwYBBQUCoIIJzjCCCcqgJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCCaAEggmcYIIJmAYJKoZIhvcSAQICAQBuggmHMIIJg6ADAgEFoQMCAQ6iBwMFACAAAACjggPIYYIDxDCCA8CgAwIBBaEMGwpERU5ZREMuQ09NoiEwH6ADAgECoRgwFhsESFRUUB
        GSS-API Generic Security Service Application Program Interface
            OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
            SPNEGO
                negTokenInit
                    mechTypes: 3 items
                    mechToken: 6082099806092A864886F71201020201006E820987308209...
                    krb5_blob: 6082099806092A864886F71201020201006E820987308209...
                        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: 20000000 (Mutual required)
                            Ticket
                            Authenticator rc4-hmac
                                Encryption type: rc4-hmac (23)
                                Authenticator data: 2288B57C98476E136E0D3CD3EAFACB7DE41A6A1F5DC36D33...
                                    [Decrypted using: key learnt from frame 18]
                                    Authenticator
                                        Authenticator vno: 5
                                        Client Realm: DENYDC.COM
                                        Client Name (Principal): Administrator
                                        Checksum
                                            Type: gssapi-8003 (32771)
                                            checksum: 100000000000000000000000000000000000000003000000... <---------a really big checksum-------->
               <------------ a TGT is missing here-------------------->
                                       cusec: 27
                                        ctime: 2006-02-09 12:48:06 (Z)
                                        Subkey rc4-hmac
                                        Seq Number: 323625080
    \r\n
---------
we don't see the TGT in this frame, but we see a huge checksum. a normal checksum is only 24Byte(in nodelegation.cap).

If we check the big checksum on packet type column, we see a TGT is there. So I think Ethereal does not know a TGT is

attached behide the checksum here.
 

if it is confirmed as a problem, hope it can be fixed.