none
[MS-KILE] Please tell me how to calculate the Bnd field in the checksum of authenticator to TLS channel bind in LDAPS gssapi bind. RRS feed

  • Question

  • Even if I set LdapEnforceChannelBinding = 2 of Windows LDAP server on LINUX system, I am trying to support LDAPS gssapi bind, but I do not understand how to calculate the following Bnd field.

                bindRequest
                    version: 3
                    name:
                    authentication: sasl (3)
                        sasl
                            mechanism: GSS-SPNEGO
                            credentials: 6082061006062b0601050502a082060430820600a030302e...
                            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: 4 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)
                                            MechType: 1.3.6.1.4.1.311.2.2.30 (NEGOEX - SPNEGO Extended Negotiation Security Mechanism)
                                            MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                                        mechToken: 608205c206092a864886f71201020201006e8205b1308205...
                                        krb5_blob: 608205c206092a864886f71201020201006e8205b1308205...
                                            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: krb-ap-req (14)
                                                    Padding: 0
                                                    ap-options: 20000000 (mutual-required)
                                                        0... .... = reserved: False
                                                        .0.. .... = use-session-key: False
                                                        ..1. .... = mutual-required: True
                                                    ticket
                                                    authenticator
                                                        etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                                                        cipher: cea77cbab92b7177ae97244867e82b357f0eb11b238603bb...
                                                            authenticator
                                                                authenticator-vno: 5
                                                                crealm: NIKU.LOCAL
                                                                cname
                                                                    name-type: kRB5-NT-PRINCIPAL (1)
                                                                    cname-string: 1 item
                                                                        CNameString: user001
                                                                cksum
                                                                    cksumtype: cKSUMTYPE-GSSAPI (32771)
                                                                    checksum: 1000000004f964f4f61e2e4136ffd35d4257c1ea02400000
                                                                    Length: 16
                                                                    Bnd: 04f964f4f61e2e4136ffd35d4257c1ea
                                                                    .... .... .... .... ...0 .... .... .... = DCE-style: Not using DCE-STYLE
                                                                    .... .... .... .... .... .... ..0. .... = Integ: Do NOT use integrity protection
                                                                    .... .... .... .... .... .... ...0 .... = Conf: Do NOT use Confidentiality (sealing)
                                                                    .... .... .... .... .... .... .... 0... = Sequence: Do NOT enable out-of-sequence detection
                                                                    .... .... .... .... .... .... .... .0.. = Replay: Do NOT enable replay protection
                                                                    .... .... .... .... .... .... .... ..1. = Mutual: Request that remote peer authenticates itself
                                                                    .... .... .... .... .... .... .... ...0 = Deleg: Do NOT delegate

    Bnd: Aiming at 04f964f4f61e2e4136ffd35d4257c1ea,

    https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication

    I tried to calculate from the server certificate with the calculation method of

    kosyo> sha256sum eu-domain.cer 9e82e381657192423ac23e4616218740176dceae47d815d940d05c6259eff92e eu-domain.cer kosyo> hexdump -C sum256 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 35 00 00 00 74 6c 73 2d 73 65 72 76 65 72 2d 65 |5...tls-server-e| 00000020 6e 64 2d 70 6f 69 6e 74 3a ea 9e 82 e3 81 65 71 |nd-point:.....eq| 00000030 92 42 3a c2 3e 46 16 21 87 40 17 6d ce ae 47 d8 |.B:.>F.!.@.m..G.| 00000040 15 d9 40 d0 5c 62 59 ef f9 2e |..@.\bY...| kosyo> sha384sum eu-domain.cer f0cb5b505e8a6feca34643427a5c10598d70779602d1fe14d4dae72c23672c420eb71c0de12ceaa28cb2977e1ac31f08 eu-domain.cer kosyo> hexdump -C sum384 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 46 00 00 00 74 6c 73 2d 73 65 72 76 65 72 2d 65 |F...tls-server-e| 00000020 6e 64 2d 70 6f 69 6e 74 3a ea f0 cb 5b 50 5e 8a |nd-point:...[P^.| 00000030 6f ec a3 46 43 42 7a 5c 10 59 8d 70 77 96 02 d1 |o..FCBz\.Y.pw...| 00000040 fe 14 d4 da e7 2c 23 67 2c 42 0e b7 1c 0d e1 2c |.....,#g,B.....,| 00000050 ea a2 8c b2 97 7e 1a c3 1f 08 |.....~....| kosyo> sha512sum eu-domain.cer ee8abb790daa1e5b463cb39d407202e08eaa798eb455848f32ec73af53bf9b47a538e10b8fde487a0f16b06da19fceee45e2535e35f6d9c347551892efc19d05 eu-domain.cer kosyo> hexdump -C sum512 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 56 00 00 00 74 6c 73 2d 73 65 72 76 65 72 2d 65 |V...tls-server-e| 00000020 6e 64 2d 70 6f 69 6e 74 3a ea ee 8a bb 79 0d aa |nd-point:....y..| 00000030 1e 5b 46 3c b3 9d 40 72 02 e0 8e aa 79 8e b4 55 |.[F<..@r....y..U| 00000040 84 8f 32 ec 73 af 53 bf 9b 47 a5 38 e1 0b 8f de |..2.s.S..G.8....| 00000050 48 7a 0f 16 b0 6d a1 9f ce ee 45 e2 53 5e 35 f6 |Hz...m....E.S^5.| 00000060 d9 c3 47 55 18 92 ef c1 9d 05 |..GU......| kosyo> md5sum sum* 3a4e73ef959b40808c8ffcafb6cebeb7 sum256 1425cde7de3f0dc7fc1ef60a3bb6fcd9 sum384 88d8fbc4bd506fdfda48364ca55b5060 sum512

    As mentioned above, Bnd: 04f964f4f61e2e4136ffd35d4257c1ea does not.
    The value is always the same regardless of the client PC and bind user.
    The value changes when you change the TLS server certificate. This also changes when the server certificate is updated with the same certificate key. So I think the TLS server certificate is the calculation source.
    Even if the bind method was set to NTLM, the value was the same.

    Attribute: Channel Bindings
        NTLMV2 Response Item Type: Channel Bindings (0x000a)
        NTLMV2 Response Item Length: 16
        Channel Bindings: 04f964f4f61e2e4136ffd35d4257c1ea

    I searched for related RFCs and information on the Internet, but could not find them. Please tell me the calculation method.
    Thank you.






    • Edited by soenos Saturday, February 22, 2020 1:33 AM
    Thursday, February 20, 2020 7:40 AM

Answers

  • Hi Soeno:

    The data I presented above is not correct. Here is the correct data:

     0x00 ,0x00 ,0x00 ,0x00 , //initiator  address type

     0x00 ,0x00 ,0x00 ,0x00 , //initiator length

     0x00 ,0x00 ,0x00 ,0x00 , //acceptor  address type

     0x00 ,0x00 ,0x00 ,0x00  //Acceptor Length

     0x55 ,0x00 ,0x00 ,0x00  //Application data length

     ,0x74 ,0x6c ,0x73 ,0x2d ,0x73 ,0x65 ,0x72 ,0x76 ,0x65 ,0x72 ,0x2d ,0x65 ,0x6e ,0x64 ,0x2d ,0x70
    ,0x6f ,0x69 ,0x6e ,0x74 ,0x3a ,0xee ,0x8a ,0xbb ,0x79 ,0x0d ,0xaa ,0x1e ,0x5b ,0x46 ,0x3c ,0xb3
    ,0x9d ,0x40 ,0x72 ,0x02 ,0xe0 ,0x8e ,0xaa ,0x79 ,0x8e ,0xb4 ,0x55 ,0x84 ,0x8f ,0x32 ,0xec ,0x73
    ,0xaf ,0x53 ,0xbf ,0x9b ,0x47 ,0xa5 ,0x38 ,0xe1 ,0x0b ,0x8f ,0xde ,0x48 ,0x7a ,0x0f ,0x16 ,0xb0
    ,0x6d ,0xa1 ,0x9f ,0xce ,0xee ,0x45 ,0xe2 ,0x53 ,0x5e ,0x35 ,0xf6 ,0xd9 ,0xc3 ,0x47 ,0x55 ,0x18
    ,0x92 ,0xef ,0xc1 ,0x9d ,0x05

    I verified this results in the following MD5 hash:

    04 f9 64 f4 f6 1e 2e 41 36 ff d3 5d 42 57 c1 ea

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    • Marked as answer by soenos Friday, February 28, 2020 1:02 AM
    Friday, February 28, 2020 12:48 AM
    Owner

All replies

  • Hi Soenos:

    I have alerted the open specifications team regarding your inquiry. A member of the team will be i touch soon.


    Regards, Obaid Farooqi

    Thursday, February 20, 2020 6:27 PM
    Owner
  • Hi Soenos:

    I'll help you with this issue and will be in touch as soon as I have an answer.


    Regards, Obaid Farooqi

    Thursday, February 20, 2020 6:36 PM
    Owner
  • Hello Obaid:

    Thank you very much.

    The LDAP server is Windows2012r2, and the client is using ldp.exe of Windows10 to capture.

    The TLS server certificate is as follows.

    -----BEGIN CERTIFICATE-----
    MIIHOzCCBiOgAwIBAgIKFZ4J/AADAAAG2zANBgkqhkiG9w0BAQ0FADBeMRUwEwYK
    CZImiZPyLGQBGRYFbG9jYWwxHDAaBgoJkiaJk/IsZAEZFgx0ZXN0eGVyb3hjYWMx
    EjAQBgoJkiaJk/IsZAEZFgJldTETMBEGA1UEAxMKZXUtR09NQS1DQTAeFw0xODEw
    MTAwMTM1MjRaFw0zMjAyMjQwMjM5NDRaMBoxGDAWBgNVBAMTD2JlZWYubmlrdS5s
    b2NhbDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIQE4ML6HrLpGYht
    VSNzAygeOd7Q/LP6vFDHEpa13Xm40758vqXHZViKMeAmfvFV0av5ZsR5+CCoiVro
    gBSB8Iq2OGINh2Js3E9pDCVEH3ey4TMEExcU3AmVBGCkoIjKnRlwP+V9gsk1nLTi
    GtKL2Fl8TVtgsVkEVRRj1mY7cjbQaIqTki67rlgiPKwA1ADuRx612pulSd64r1GW
    PsqH6sQYRw6efs5sIYcQ2ByE9eAHklpms71w2Hd5cnB43bCz2mcdupXVmglhn9EZ
    VINm/uMlEE/Y9iJNONd9Wd4HxZ8/InzHcHZs43qpX3NmbBFo33seIYt7O3z4fnpa
    fHhmz34sM53hRtYQnGWXFT+Wv8I8M7HwWEyW2JUjekva3XyEA923DUuXqs0jIFP7
    eruqnTotESuJVJyVMhShAaCli46CKKzAxrg/wYBI3KM83vVShrzub9BZ2kpQtSrm
    qrc6Sv4oQ+ZCRoxx+PG9qRVblnWQ5RQb+IG4o2dfsbCnb184cMKWKk7fzp77B/zR
    M2jHavA+6gXd8Mhk2PLchIme3gbFJLHf0oWhZEkQEvD8TpOyeiXm7h1N0t6qtw1A
    AOzjnntDS68pzEa4NcWRBijpAftLQ8rJ+LKmFuF3LrrOZaRyWyE92jNmGQHeLYM5
    lrcTAAq0R3HP91TY5NrLGyy1fjG1AgMBAAGjggM9MIIDOTALBgNVHQ8EBAMCBaAw
    PgYJKwYBBAGCNxUHBDEwLwYnKwYBBAGCNxUIhtSnLYL4oFKHmYU5hoLDYIaE8XWB
    e4Httm2B+MltAgFkAgECMB0GA1UdDgQWBBTW+Udp0qtuyuYNPtdSh3aI55BQ3zAf
    BgNVHSMEGDAWgBSUbBLzLklhkaYdiZUTJLDLe4/6QDCCARIGA1UdHwSCAQkwggEF
    MIIBAaCB/qCB+4aBuGxkYXA6Ly8vQ049ZXUtR09NQS1DQSgzKSxDTj1nb21hLENO
    PUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1D
    b25maWd1cmF0aW9uLERDPXRlc3R4ZXJveGNhYyxEQz1sb2NhbD9jZXJ0aWZpY2F0
    ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9u
    UG9pbnSGPmh0dHA6Ly9nb21hLmV1LnRlc3R4ZXJveGNhYy5sb2NhbC9DZXJ0RW5y
    b2xsL2V1LUdPTUEtQ0EoMykuY3JsMIIBYAYIKwYBBQUHAQEEggFSMIIBTjCBsAYI
    KwYBBQUHMAKGgaNsZGFwOi8vL0NOPWV1LUdPTUEtQ0EsQ049QUlBLENOPVB1Ymxp
    YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s
    REM9dGVzdHhlcm94Y2FjLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl
    Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MGUGCCsGAQUFBzAChllodHRw
    Oi8vZ29tYS5ldS50ZXN0eGVyb3hjYWMubG9jYWwvQ2VydEVucm9sbC9nb21hLmV1
    LnRlc3R4ZXJveGNhYy5sb2NhbF9ldS1HT01BLUNBKDMpLmNydDAyBggrBgEFBQcw
    AYYmaHR0cDovL2dvbWEuZXUudGVzdHhlcm94Y2FjLmxvY2FsL29jc3AwEwYDVR0l
    BAwwCgYIKwYBBQUHAwEwGwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDATANBgkq
    hkiG9w0BAQ0FAAOCAQEACXIM9lLxuOg1T7eFFQzbeBNwp50F4DLjrlss9r0wJqDc
    46eMIfxXQ/26V7ZIhFF4ol8Cc5OHw6JIE7OKUq5kQtgUCcrJSMdwGFRrWxK/CVwW
    Ty0eee6+jahDsEZVLxTNj61fgalUiz6Mr+lPdLJXRPWla7CqAhXVB2VRy11drTxv
    JohlcgGrAA7PbEBQ7ZS/ybzmjasm62sG4s6mMLFG0IxHywBVl48pgtPT+4XzGOGN
    m091RhWY7UHInxAfTYWtRILWd1MaffdqqzwlZCrGjUmsUkhgL2+6w+P/rSLyatji
    pk0dj0UVSZNMKi9Bx4JsG0qzKUGIq1OzN0PwGZQMQQ==
    -----END CERTIFICATE-----

    Friday, February 21, 2020 1:54 AM
  • Hi Soenos:

    What was the input of the SHA-256 for certificate? The Base64 value you posted above or the binary value of the certificate? the binary value of the certificate is a byte stream of ASN.1 encoding of the certificate.


    Regards, Obaid Farooqi

    Friday, February 21, 2020 8:34 AM
    Owner
  • Hi Obaid:

    The source of SHA-256 is the binary value of the certificate.
    The binary was converted to Base64 with the following command.
    openssl x509 -inform der -in eu-domain.cer
    Please restore below.
    openssl x509 -in <base64 file> -outform der -out eu-domain.cer
    Alternatively, save it to eu-domain.crt, open the certificate by double-clicking, copy it to a file, and save it as eu-domain.cer in DER encoded binary X.509.

    • Edited by soenos Friday, February 21, 2020 9:31 AM
    Friday, February 21, 2020 9:25 AM
  • Hi Obaid:

    Since February 24 is a public holiday, it will be after the 25th, but for the convenience of the company, the verification environment has been completely shifted to the local network. It is a post-migration story during the transition, but it is possible to send a capture.
    I can send the recaptured capture and TLS server certificate pfx and user001 key, but please tell me how to send it if necessary.
    Can be decoded with wireshark. Please refer to the following.

    https://www.veritas.com/support/en_US/article.100044199
    https://docs.axway.com/bundle/APIGateway_762_IntegrationKerberos_allOS_en_HTML5/page/Content/KerberosIntegration/Wireshark/wireshark_tracing_for_spnego_kerberos_auth_between.htm

    Friday, February 21, 2020 2:49 PM
  • Hi Soenos:

    Please an email to dochelp <at> microsoft <dot> com. before sending convert <at> to @ and <dot> to .

    I'll respond to that email with links where you can upload the traces.


    Regards, Obaid Farooqi

    Friday, February 21, 2020 5:08 PM
    Owner
  • Hi Obaid:

    Set KERB_AP_OPTIONS_CBT and send hardcoded capture of bnd value.
    git clone https://github.com/krb5/krb5.git is modified as follows.

    git diff --src-prefix=krb5/ --dst-prefix=krb5/
    diff --git krb5/src/lib/gssapi/krb5/init_sec_context.c krb5/src/lib/gssapi/krb5/init_sec_context.c
    index 3f77157c9..b3f072cca 100644
    --- krb5/src/lib/gssapi/krb5/init_sec_context.c
    +++ krb5/src/lib/gssapi/krb5/init_sec_context.c
    @@ -374,6 +374,11 @@ make_gss_checksum (krb5_context context, krb5_auth_context auth_context,
         }
         if (junk)
             memset(ptr, 'i', junk);
    +    {
    +    unsigned char bnd[] = "\x04\xf9\x64\xf4\xf6\x1e\x2e\x41\x36\xff\xd3\x5d\x42\x57\xc1\xea";
    +//    unsigned char bnd[] = "\x88\xd8\xfb\xc4\xbd\x50\x6f\xdf\xda\x48\x36\x4c\xa5\x5b\x50\x60";
    +    memcpy(data->checksum_data.data + 4, bnd, sizeof(bnd) - 1);
    +    }
         *out = &data->checksum_data;
         code = 0;
     cleanup:
    diff --git krb5/src/lib/krb5/krb/mk_req_ext.c krb5/src/lib/krb5/krb/mk_req_ext.c
    index 9fc6a0e52..7d28c0538 100644
    --- krb5/src/lib/krb5/krb/mk_req_ext.c
    +++ krb5/src/lib/krb5/krb/mk_req_ext.c
    @@ -67,6 +67,63 @@
       returns system errors
     */
    
    +static krb5_error_code
    +make_ap_options_cbt(krb5_context context,
    +                krb5_authdata ***authdata)
    +{
    +    krb5_error_code code;
    +    krb5_data *ad_if_relevant;
    +    krb5_authdata *cbt_adata[3], cbt_adatum1, **adata;
    +    unsigned char cbt[] = "\x00\x40\x00\x00";
    +    int i;
    +
    +    cbt_adatum1.magic = KV5M_AUTHDATA;
    +    cbt_adatum1.ad_type = 143; /* AD-AUTH-DATA-AP-OPTIONS */
    +    cbt_adatum1.length = sizeof(cbt) - 1;
    +    cbt_adatum1.contents = (krb5_octet *)cbt;
    +
    +    cbt_adata[0] = &cbt_adatum1;
    +    cbt_adata[1] = NULL;
    +
    +    /* Wrap in AD-IF-RELEVANT container */
    +    code = encode_krb5_authdata(cbt_adata, &ad_if_relevant);
    +    if (code) {
    +        return code;
    +    }
    +
    +    adata = *authdata;
    +    if (adata == NULL) {
    +        adata = (krb5_authdata **)calloc(2, sizeof(krb5_authdata *));
    +        i = 0;
    +    } else {
    +        for (i = 0; adata[i] != NULL; i++)
    +            ;
    +
    +        adata = (krb5_authdata **)realloc(*authdata,
    +                                          (i + 2) * sizeof(krb5_authdata *));
    +    }
    +    if (adata == NULL) {
    +        krb5_free_data(context, ad_if_relevant);
    +        return ENOMEM;
    +    }
    +    *authdata = adata;
    +
    +    adata[i] = (krb5_authdata *)malloc(sizeof(krb5_authdata));
    +    if (adata[i] == NULL) {
    +        krb5_free_data(context, ad_if_relevant);
    +        return ENOMEM;
    +    }
    +    adata[i]->magic = KV5M_AUTHDATA;
    +    adata[i]->ad_type = KRB5_AUTHDATA_IF_RELEVANT;
    +    adata[i]->length = ad_if_relevant->length;
    +    adata[i]->contents = (krb5_octet *)ad_if_relevant->data;
    +    free(ad_if_relevant); /* contents owned by adata[i] */
    +
    +    adata[i + 1] = NULL;
    +
    +    return 0;
    +}
    +
     static krb5_error_code
     make_etype_list(krb5_context context,
                     krb5_enctype *desired_etypes,
    @@ -297,6 +354,11 @@ generate_authenticator(krb5_context context, krb5_authenticator *authent,
             krb5_free_authdata(context, ext_authdata);
         }
    
    +    retval = make_ap_options_cbt(context, &authent->authorization_data);
    +    if (retval) {
    +        return retval;
    +    }
    +
         /* Only send EtypeList if we prefer another enctype to tkt_enctype */
         if (desired_etypes != NULL && desired_etypes[0] != tkt_enctype) {
             TRACE_MK_REQ_ETYPES(context, desired_etypes);
    
    

    Compiling with CentOS7. LDAP-> SASL-> Handing over the Bnd value calculation source to KRB5 can be done in any way, so the only issue is the Bnd value calculation method.
    The difference from the RFC5929 method can be understood from the TLS server certificate and Bnd value of the capture.

    Regards, Shinichiro Soeno

    Tuesday, February 25, 2020 2:58 AM
  • Hi Shinichiro:

    As described in the RFC5929 section 4.1, the selection of hashing function for certificate is as follows:

    The hash function is to be selected as follows:
    
       o  if the certificate's signatureAlgorithm uses a single hash
          function, and that hash function is either MD5 [RFC1321] or SHA-1
          [RFC3174], then use SHA-256 [FIPS-180-3];
    
       o  if the certificate's signatureAlgorithm uses a single hash
          function and that hash function neither MD5 nor SHA-1, then use
          the hash function associated with the certificate's
          signatureAlgorithm;
    

    So the hashing function would be SHA-512 since that is the hashing function of your certificate.

    Now the hash of the cert is as you shown in your calculation i.e:

    ee8abb790daa1e5b463cb39d407202e0

    8eaa798eb455848f32ec73af53bf9b47

    a538e10b8fde487a0f16b06da19fceee

    45e2535e35f6d9c347551892efc19d05

    Prepend the tls-server-end-point: to it to get

    74 6c 73 2d 73 65 72 76-65 72 2d 65 6e 64 2d 70 
    6f 69 6e 74 3a ee 8a bb-79 0d aa 1e 5b 46 3c b3
    9d 40 72 02 e0 8e aa 79-8e b4 55 84 8f 32 ec 73
    af 53 bf 9b 47 a5 38 e1-0b 8f de 48 7a 0f 16 b0
    6d a1 9f ce ee 45 e2 53-5e 35 f6 d9 c3 47 55 18
    92 ef c1 9d 05   

    The length of this is 0x55   

    Now creating the channel binding, we get

    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    00 00 00 00 00 00 00 00 55 00 00 00 20 00 00 00

    74 6c 73 2d 73 65 72 76-65 72 2d 65 6e 64 2d 70 
    6f 69 6e 74 3a ee 8a bb-79 0d aa 1e 5b 46 3c b3
    9d 40 72 02 e0 8e aa 79-8e b4 55 84 8f 32 ec 73
    af 53 bf 9b 47 a5 38 e1-0b 8f de 48 7a 0f 16 b0
    6d a1 9f ce ee 45 e2 53-5e 35 f6 d9 c3 47 55 18
    92 ef c1 9d 05   

    Calculating the MD5 hash of this will give you:

    04 f9 64 f4 f6 1e 2e 41-36 ff d3 5d 42 57 c1 ea

    Please note that after the length (55 00 00 00) you also need to include the

    offset of the application data from beginning of the structure including offset it self.

    The 4 bytes of offset make the start of application data at 0x20 so offset becomes (20 00 00 00).

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    Thursday, February 27, 2020 8:19 AM
    Owner
  • Hi Obaid:

    Thank you for your investigation. I am very grateful.
    I've tried a lot and what's wrong?
    Please point out.

    Corrected the length to be 0x56-> 0x55 because the length was incorrect (sum384 was also incorrect in length)
    kosyo> hexdump -C sum512
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  55 00 00 00 74 6c 73 2d  73 65 72 76 65 72 2d 65  |U...tls-server-e|
    00000020  6e 64 2d 70 6f 69 6e 74  3a ea ee 8a bb 79 0d aa  |nd-point:....y..|
    00000030  1e 5b 46 3c b3 9d 40 72  02 e0 8e aa 79 8e b4 55  |.[F<..@r....y..U|
    00000040  84 8f 32 ec 73 af 53 bf  9b 47 a5 38 e1 0b 8f de  |..2.s.S..G.8....|
    00000050  48 7a 0f 16 b0 6d a1 9f  ce ee 45 e2 53 5e 35 f6  |Hz...m....E.S^5.|
    00000060  d9 c3 47 55 18 92 ef c1  9d 05                    |..GU......|

    The format taught
    kosyo> hexdump -C sum512-2
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  00 00 00 00 00 00 00 00  55 00 00 00 20 00 00 00  |........U... ...|
    00000020  74 6c 73 2d 73 65 72 76  65 72 2d 65 6e 64 2d 70  |tls-server-end-p|
    00000030  6f 69 6e 74 3a ee 8a bb  79 0d aa 1e 5b 46 3c b3  |oint:...y...[F<.|
    00000040  9d 40 72 02 e0 8e aa 79  8e b4 55 84 8f 32 ec 73  |.@r....y..U..2.s|
    00000050  af 53 bf 9b 47 a5 38 e1  0b 8f de 48 7a 0f 16 b0  |.S..G.8....Hz...|
    00000060  6d a1 9f ce ee 45 e2 53  5e 35 f6 d9 c3 47 55 18  |m....E.S^5...GU.|
    00000070  92 ef c1 9d 05                                    |.....|

    gss_channel_bindings_t format in RFC2744 3.11
    kosyo> hexdump -C sum512-3
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  55 00 00 00 18 00 00 00  74 6c 73 2d 73 65 72 76  |U.......tls-serv|
    00000020  65 72 2d 65 6e 64 2d 70  6f 69 6e 74 3a ee 8a bb  |er-end-point:...|
    00000030  79 0d aa 1e 5b 46 3c b3  9d 40 72 02 e0 8e aa 79  |y...[F<..@r....y|
    00000040  8e b4 55 84 8f 32 ec 73  af 53 bf 9b 47 a5 38 e1  |..U..2.s.S..G.8.|
    00000050  0b 8f de 48 7a 0f 16 b0  6d a1 9f ce ee 45 e2 53  |...Hz...m....E.S|
    00000060  5e 35 f6 d9 c3 47 55 18  92 ef c1 9d 05           |^5...GU......|

    Not including offset field length in the format taught
    kosyo> hexdump -C sum512-4
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  00 00 00 00 00 00 00 00  55 00 00 00 1c 00 00 00  |........U.......|
    00000020  74 6c 73 2d 73 65 72 76  65 72 2d 65 6e 64 2d 70  |tls-server-end-p|
    00000030  6f 69 6e 74 3a ee 8a bb  79 0d aa 1e 5b 46 3c b3  |oint:...y...[F<.|
    00000040  9d 40 72 02 e0 8e aa 79  8e b4 55 84 8f 32 ec 73  |.@r....y..U..2.s|
    00000050  af 53 bf 9b 47 a5 38 e1  0b 8f de 48 7a 0f 16 b0  |.S..G.8....Hz...|
    00000060  6d a1 9f ce ee 45 e2 53  5e 35 f6 d9 c3 47 55 18  |m....E.S^5...GU.|
    00000070  92 ef c1 9d 05                                    |.....|

    the gss_buffer_desc application_data is NULL
    kosyo> hexdump -C sum512-5
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  00 00 00 00 55 00 00 00  1c 00 00 00 74 6c 73 2d  |....U.......tls-|
    00000020  73 65 72 76 65 72 2d 65  6e 64 2d 70 6f 69 6e 74  |server-end-point|
    00000030  3a ee 8a bb 79 0d aa 1e  5b 46 3c b3 9d 40 72 02  |:...y...[F<..@r.|
    00000040  e0 8e aa 79 8e b4 55 84  8f 32 ec 73 af 53 bf 9b  |...y..U..2.s.S..|
    00000050  47 a5 38 e1 0b 8f de 48  7a 0f 16 b0 6d a1 9f ce  |G.8....Hz...m...|
    00000060  ee 45 e2 53 5e 35 f6 d9  c3 47 55 18 92 ef c1 9d  |.E.S^5...GU.....|
    00000070  05                                                |.|

    Not including offset field length in the gss_buffer_desc application_data is NULL
    kosyo> hexdump -C sum512-6
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  00 00 00 00 55 00 00 00  18 00 00 00 74 6c 73 2d  |....U.......tls-|
    00000020  73 65 72 76 65 72 2d 65  6e 64 2d 70 6f 69 6e 74  |server-end-point|
    00000030  3a ee 8a bb 79 0d aa 1e  5b 46 3c b3 9d 40 72 02  |:...y...[F<..@r.|
    00000040  e0 8e aa 79 8e b4 55 84  8f 32 ec 73 af 53 bf 9b  |...y..U..2.s.S..|
    00000050  47 a5 38 e1 0b 8f de 48  7a 0f 16 b0 6d a1 9f ce  |G.8....Hz...m...|
    00000060  ee 45 e2 53 5e 35 f6 d9  c3 47 55 18 92 ef c1 9d  |.E.S^5...GU.....|
    00000070  05                                                |.|

    kosyo> md5sum sum512*
    0019f47ede3ad78108afdc4f539ecdbb  sum512
    83c0aa6b4c140590fe71424276fdb554  sum512-2
    db7beb08ebf04d809be89b05c3b21c9c  sum512-3
    57e4a3f4a29af1550eac4ffd5f37a994  sum512-4
    5b25feed8bc719827a41d5fba1f16e36  sum512-5
    af440ba3ceeddbdf9d96509e34e09f1e  sum512-6

    Regards, Shinichiro Soeno
    Thursday, February 27, 2020 10:26 AM
  • Hi Obaid:

    I'm sorry, Looking closely, the data contained garbage.It is data of sum512.

    6e 64 2d 70 6f 69 6e 74  3a ea ee 8a bb 79 0d aa

    0xea was superfluous.So it seems that the length was wrong by 1 byte.

    I can't verify it at home now, so I'll try it tomorrow.really sorry. The calculation may be based on RFC5929.

    Regards, Shinichiro Soeno


    • Edited by soenos Thursday, February 27, 2020 2:48 PM
    Thursday, February 27, 2020 1:20 PM
  • Hi Soeno:

    The data I presented above is not correct. Here is the correct data:

     0x00 ,0x00 ,0x00 ,0x00 , //initiator  address type

     0x00 ,0x00 ,0x00 ,0x00 , //initiator length

     0x00 ,0x00 ,0x00 ,0x00 , //acceptor  address type

     0x00 ,0x00 ,0x00 ,0x00  //Acceptor Length

     0x55 ,0x00 ,0x00 ,0x00  //Application data length

     ,0x74 ,0x6c ,0x73 ,0x2d ,0x73 ,0x65 ,0x72 ,0x76 ,0x65 ,0x72 ,0x2d ,0x65 ,0x6e ,0x64 ,0x2d ,0x70
    ,0x6f ,0x69 ,0x6e ,0x74 ,0x3a ,0xee ,0x8a ,0xbb ,0x79 ,0x0d ,0xaa ,0x1e ,0x5b ,0x46 ,0x3c ,0xb3
    ,0x9d ,0x40 ,0x72 ,0x02 ,0xe0 ,0x8e ,0xaa ,0x79 ,0x8e ,0xb4 ,0x55 ,0x84 ,0x8f ,0x32 ,0xec ,0x73
    ,0xaf ,0x53 ,0xbf ,0x9b ,0x47 ,0xa5 ,0x38 ,0xe1 ,0x0b ,0x8f ,0xde ,0x48 ,0x7a ,0x0f ,0x16 ,0xb0
    ,0x6d ,0xa1 ,0x9f ,0xce ,0xee ,0x45 ,0xe2 ,0x53 ,0x5e ,0x35 ,0xf6 ,0xd9 ,0xc3 ,0x47 ,0x55 ,0x18
    ,0x92 ,0xef ,0xc1 ,0x9d ,0x05

    I verified this results in the following MD5 hash:

    04 f9 64 f4 f6 1e 2e 41 36 ff d3 5d 42 57 c1 ea

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    • Marked as answer by soenos Friday, February 28, 2020 1:02 AM
    Friday, February 28, 2020 12:48 AM
    Owner
  • Hi Obaid:

    Thank you very much. Thanks for the great support. Also, the data presented was incorrect and I was sorry.

    Regards, Shinichiro Soeno

    Friday, February 28, 2020 1:10 AM