GSS MIC problems between Unix and Windows

[Richard Evans]

Well the context is established fine, and wrap/unwrap also work.  It is just MIC verification which fails.  I have a client/server test which established a context and then sends five messages + mic for verification at the server.

In case it helps, here's the log from the server side; the hex dump is the MIC received with each of the five messages.  The server is running on Linux using the Java GSS implementation, the client is running on Windows 7 using SSPI functions.

[KRB_AP_REQ:
    pvno=5
    msg-type=14
    ap-options={2}
    ticket=[Ticket
               tkt-vno=5
               realm=DATANOMIC.LOCAL
               sname=[2] [host, dn-dt-0507.datanomic.local]
               enc-part=[etype=23 kvno=2 cipher=[1215] af 84 38 92 0b 86 27 74 88 26 da ac a1 1b 61 e2 ...]
           ]
     authenticator=[etype=23 kvno=0 cipher=[340] e9 ef fe 56 df ae 78 7a b7 17 e5 ab a7 82 1c 98 ...]
]
[KRB_AP_REP:
    pvno=5
    msg-type=15
    encPart=[etype=23 kvno=0 cipher=[61] a6 9c 58 fc e2 1d f4 44 a9 39 3f ac f8 8a 41 62 ...]
]
Server [richard.evans at DATANOMIC.LOCAL] 1.2.840.113554.1.2.2 established after 1 in, 1 out
  [anon=false conf=false deleg=false integ=true mutual=true replay=false sequence=false]
0000: 6023 0609 2a86 4886 f712 0102 0201 0111  `#..*.H.........
0010: 00ff ffff ff75 1c5d ebd4 edf4 9696 cb0f  .....u.]........
0020: 7f3d f5f4 14                             .=...
Got [46+37 (GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum or sequence number in MIC token)) -> 46] sent [16 -> 16]
0000: 6023 0609 2a86 4886 f712 0102 0201 0111  `#..*.H.........
0010: 00ff ffff ff75 1c5d ebd4 edf4 9696 cb0f  .....u.]........
0020: 7f3d f5f4 14                             .=...
Got [46+37 (GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum or sequence number in MIC token)) -> 46] sent [16 -> 16]
0000: 6023 0609 2a86 4886 f712 0102 0201 0111  `#..*.H.........
0010: 00ff ffff ff75 1c5d ebd4 edf4 9696 cb0f  .....u.]........
0020: 7f3d f5f4 14                             .=...
Got [43+37 (GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum or sequence number in MIC token)) -> 43] sent [16 -> 16]
0000: 6023 0609 2a86 4886 f712 0102 0201 0111  `#..*.H.........
0010: 00ff ffff ff75 1c5d ebd4 edf4 9696 cb0f  .....u.]........
0020: 7f3d f5f4 14                             .=...
Got [38+37 (GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum or sequence number in MIC token)) -> 38] sent [16 -> 16]
0000: 6023 0609 2a86 4886 f712 0102 0201 0111  `#..*.H.........
0010: 00ff ffff ff75 1c5d ebd4 edf4 9696 cb0f  .....u.]........
0020: 7f3d f5f4 14                             .=...
Got [46+37 (GSSException: Token had invalid integrity check (Mechanism level: Corrupt checksum or sequence number in MIC token)) -> 46] sent [16 -> 16]

-----Original Message-----
From: Derrick Brashear [mailto:shadow at gmail.com] 
Sent: 03 May 2011 11:45
To: Richard Evans
Subject: Re: GSS MIC problems between Unix and Windows

On Tue, May 3, 2011 at 5:07 AM, Richard Evans
<richard.evans at datanomic.com> wrote:
> I'm still having problems with this?  Does anyone have any clues, or is this just a fundamental problem with Kerberos/Windows interaction?  Further tests indicate that signature verification also fails with Windows 2000 so it is not specific to Windows 7.
>
> Richard
>
> -----Original Message-----
> Sent: 06 April 2011 17:00
> To: krbdev at mit.edu
> Subject: GSS MIC problems between Unix and Windows
>
> I'm using the gss APIs on a Linux box to establish a context with a
> Windows 7 system using SSPI.  The context is established fine at both
> ends in one handshake, as expected.  The 'supports integrity checking'
> flag is correctly set on both contexts.
>
> However I'm then trying to verify a message by generating a MIC at the
> Unix end, using gss_get_mic, and verifying at the Windows end using
> VerifySignature.  I can never get the verification to succeed.  I get
> similar problems if I generate the MIC on Windows using MakeSignature
> and verify it on Unix, using gss_verify_mic.
>
> At the Unix end I've tried both the implementation in Java 1.6u24, and
> native Kerberos libraries (1.7.1 on Fedora 12). The MIC generated when
> the client or server uses the Java APIs is 37 bytes long and looks like
> the format described in RFC 1964; the MIC when native Kerberos is used
> is 28 bytes long and seems to match RFC 4121.

You've probably hit the key here. What etypes are being used in each case?
4121 specifies that it applies with the following (below) etypes, or
when both sides
are known to accept 4121 MICs. Given what you see, it sounds as though
each (SSPI, MIT, Java)
implementation is choosing first an implementation which is not
acceptable to the other end,
but that no fallback is attempted.


> I can get the test to work if both ends are Windows or both ends are
> Unix, but not with a mixture.
>
> Are there any special tricks or problems with using VerifySignature and
> gss_get_mic?
>
> The background is that I'm testing gssapi-with-mic support in Apache
> SSHD - the final MIC verification is failing.
>
> Richard
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>



-- 
Derrick