Skip Menu |
 

History Show all quoted text — Show full headers
# Mon May 18 09:03:44 2009 Sam Hartman <hartmans@debian.org> - Ticket created
To: krb5-bugs@MIT.EDU
Subject: [Russ Allbery] Bug#528729: libkrb5-3: cannot obtain cross-realm tickets with Windows 2003 AD
From: Sam Hartman <hartmans@debian.org>
Date: Mon, 18 May 2009 09:03:30 -0400
Download (untitled) / with headers
text/plain 71B
There seems to be a problem with multi-hop cross-realm involving AD.
Download (untitled)
message/rfc822 8.7KiB
Return-Path: <debbugs@rietz.debian.org>
Received: from localhost ([unix socket])
by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA;
Thu, 14 May 2009 20:53:52 -0400
X-Sieve: CMU Sieve 2.2
Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU
[18.72.1.2])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.suchdamage.org (Postfix) with ESMTP id F1032202E8
for <hartmans@suchdamage.org>; Thu, 14 May 2009 20:53:42 -0400 (EDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
n4F0nFNa001693
for <hartmans@suchdamage.org>; Thu, 14 May 2009 20:49:15 -0400 (EDT)
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id
n4F0n5xE002955
for <hartmans@mit.edu>; Thu, 14 May 2009 20:49:06 -0400 (EDT)
Received: from rietz.debian.org (localhost [127.0.0.1])
by mit.edu (Spam Firewall) with ESMTP id 25A221B61A21
for <hartmans@mit.edu>; Thu, 14 May 2009 20:49:04 -0400 (EDT)
Received: from rietz.debian.org (rietz.debian.org [140.211.166.43]) by mit.edu
with ESMTP id RZHQDBHC8vfC9jYp for <hartmans@mit.edu>;
Thu, 14 May 2009 20:49:04 -0400 (EDT)
Received: from debbugs by rietz.debian.org with local (Exim 4.63)
(envelope-from <debbugs@rietz.debian.org>)
id 1M4lam-0001NX-1t; Fri, 15 May 2009 00:48:04 +0000
X-Loop: owner@bugs.debian.org
Subject: Bug#528729: libkrb5-3: cannot obtain cross-realm tickets with Windows
2003 AD
Reply-To: Russ Allbery <rra@debian.org>, 528729@bugs.debian.org
Resent-From: Russ Allbery <rra@debian.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-Cc: Sam Hartman <hartmans@debian.org>
Resent-Date: Fri, 15 May 2009 00:48:01 +0000
Resent-Message-ID: <handler.528729.B.12423483103716@bugs.debian.org>
X-Debian-PR-Message: report 528729
X-Debian-PR-Package: libkrb5-3
X-Debian-PR-Keywords:
X-Debian-PR-Source: krb5
Received: via spool by submit@bugs.debian.org id=B.12423483103716
(code B ref -1); Fri, 15 May 2009 00:48:01 +0000
Received: (at submit) by bugs.debian.org; 15 May 2009 00:45:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
(2007-08-08) on rietz.debian.org
X-Spam-Level: ***** (5.01)
X-Spam-Bayes: score:0.0000 Tokens: new, 77; hammy, 151; neutral, 158; spammy,
0. spammytokens: hammytokens:0.000-+--H*M:reportbug,
0.000-+--H*MI:reportbug,
0.000-+--H*x:reportbug, 0.000-+--H*UA:reportbug, 0.000-+--en_US.UTF-8
X-Spam-Status: No, score=-9.6 required=4.0 tests=AWL,BAYES_00,FOURLA,
FROMDEVELOPER, HAS_PACKAGE, IMPRONONCABLE_1, IMPRONONCABLE_2,
MURPHY_WRONG_WORD2,
RCVD_IN_DNSWL_MED,XMAILER_REPORTBUG autolearn=ham
version=3.2.3-bugs.debian.org_2005_01_02
Received: from smtp2.stanford.edu ([171.67.219.82])
by rietz.debian.org with esmtp (Exim 4.63)
(envelope-from <rra@debian.org>) id 1M4lXy-0000uL-7x
for submit@bugs.debian.org; Fri, 15 May 2009 00:45:10 +0000
Received: from smtp2.stanford.edu (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with SMTP id 9156F170379;
Thu, 14 May 2009 17:45:04 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134])
by smtp2.stanford.edu (Postfix) with ESMTP id 540DB17031E;
Thu, 14 May 2009 17:45:04 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000)
id EF1B4E7935; Thu, 14 May 2009 17:45:03 -0700 (PDT)
From: Russ Allbery <rra@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Message-ID: <20090515004503.23403.91684.reportbug@windlord.stanford.edu>
X-Mailer: reportbug 4.2
Date: Thu, 14 May 2009 17:45:03 -0700
Delivered-To: submit@bugs.debian.org
Resent-Sender: Debian BTS <debbugs@rietz.debian.org>
Resent-Date: Fri, 15 May 2009 00:48:04 +0000
X-Spam-Score: 5.01
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-DSPAM-Result: Whitelisted
X-DSPAM-Processed: Thu May 14 20:53:52 2009
X-DSPAM-Confidence: 0.5514
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 8042,4a0cbd20161561389219069
X-DSPAM-Factors: 27, From*Russ Allbery <rra@debian.org>, 0.00010,
Received*with+local, 0.00484, Received*local+(Exim, 0.00494,
Received*local, 0.00501, Received*2009+00, 0.99430,
Received*2009+00, 0.99430, Received*via, 0.00588,
Received*May+2009, 0.99247, Received*May+2009, 0.99247,
Received*[127.0.0.1]), 0.00769,
Received*[127.0.0.1]), 0.00769, Date*May+2009, 0.99126,
Received*esmtp+(Exim, 0.00920, Received*TLSv1, 0.00961,
Received*TLSv1+with, 0.00961, Received*(using+TLSv1, 0.00961,
Received*with+cipher, 0.00962, Received*(No+client, 0.00971,
Received*requested), 0.00971, Received*certificate, 0.00971,
Received*(No, 0.00971, Received*userid+1000), 0.00995,
With+a, 0.99000, Received*49+04, 0.99000,
relationship, 0.99000, rra, 0.99000, rra, 0.99000
MIME-Version: 1.0

Package: libkrb5-3
Version: 1.7dfsg~beta1-3
Severity: normal

Negotiate-Auth with SPNEGO via a cross-realm trust relationship to an IIS
server worked properly in 1.6.dfsg.4~beta1-13 but fails in 1.7dfsg~beta1-3
and later. (Unfortunately, it wasn't something that changed between
beta1 and beta2.)

With a successful authentication with 1.6.dfsg.4~beta1-13, I see the
following in my ticket cache after authentication:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: rra@stanford.edu

Valid starting Expires Service principal
05/14/09 17:35:01 05/15/09 17:34:57 krbtgt/stanford.edu@stanford.edu
05/14/09 17:35:06 05/15/09 17:34:57 krbtgt/WIN.STANFORD.EDU@stanford.edu
05/14/09 17:35:55 05/15/09 17:34:57 krbtgt/IT.WIN.STANFORD.EDU@WIN.STANFORD.EDU
05/14/09 17:36:44 05/15/09 17:34:57 HTTP/infraappprod.stanford.edu@IT.WIN.STANFORD.EDU

With the unsuccessful authentication with 1.7dfsg~beta1-3 and later, I
see:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: rra@stanford.edu

Valid starting Expires Service principal
05/14/09 17:36:46 05/15/09 17:36:44 krbtgt/stanford.edu@stanford.edu
05/14/09 17:36:51 05/15/09 17:36:44 krbtgt/WIN.STANFORD.EDU@stanford.edu
05/14/09 17:37:41 05/15/09 17:36:44 krbtgt/IT.WIN.STANFORD.EDU@WIN.STANFORD.EDU

so the obtaining of the last hop of the ticket doesn't work, or Firefox
somehow fails before that point. Indeed, it looks like the problem is
below the GSSAPI layer and has something to do with the cross-realm trust.
With 1.7beta2:

wanderer:~> kvno HTTP/infraappprod.stanford.edu@IT.WIN.STANFORD.EDU
kvno: Message stream modified while getting credentials for HTTP/ifraappprod.stanford.edu@IT.WIN.STANFORD.EDU

Note that I get this same error even if I request a ticket for a
principal that doesn't exist in IT.WIN.STANFORD.EDU.

Compare to 1.6.4beta1:

windlord:~> kvno HTTP/infraappprod.stanford.edu@IT.WIN.STANFORD.EDU
HTTP/infraappprod.stanford.edu@IT.WIN.STANFORD.EDU: kvno = 43

klist with encryption types:

Ticket cache: FILE:/tmp/krb5cc_1000_EGNcc23095
Default principal: rra@stanford.edu

Valid starting Expires Service principal
05/14/09 17:23:11 05/15/09 17:23:05 krbtgt/stanford.edu@stanford.edu
Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, Triple DES cbc mode with HMAC/sha1
05/14/09 17:23:11 05/15/09 17:23:05 afs/ir.stanford.edu@stanford.edu
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32
05/14/09 17:42:41 05/15/09 17:23:05 krbtgt/WIN.STANFORD.EDU@stanford.edu
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32
05/14/09 17:43:30 05/15/09 17:23:05 krbtgt/IT.WIN.STANFORD.EDU@WIN.STANFORD.EDU
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
05/14/09 17:43:37 05/15/09 17:23:05 HTTP/infraappprod.stanford.edu@IT.WIN.STANFORD.EDU
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5

-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libgssapi-krb5-2 depends on:
ii libc6 2.9-4 GNU C Library: Shared libraries
ii libcomerr2 1.41.3-1 common error description library
ii libk5crypto3 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - C
ii libkeyutils1 1.2-10 Linux Key Management Utilities (li
ii libkrb5-3 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries
ii libkrb5support0 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - S

libgssapi-krb5-2 recommends no packages.

Versions of packages libgssapi-krb5-2 suggests:
ii krb5-doc 1.6.dfsg.4~beta1-13 Documentation for MIT Kerberos
ii krb5-user 1.6.dfsg.4~beta1-13 Basic programs to authenticate usi

-- no debconf information
# Mon May 18 11:56:21 2009 tlyu (Taylor Yu) - Version_reported 1.7 added
# Mon May 18 11:56:21 2009 tlyu (Taylor Yu) - Target_Version 1.7 added
# Mon May 18 16:44:53 2009 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 670B
Findings so far, if I'm interpreting this all correctly:

1. It's probably a bug in the TGS path with rc4 keys against AD, not an
issue retrieving or storing the cross TGTs.

2. The immediate problem arises from using a keyed checksum in the TGS
request. Something about the way we are doing that causes AD to fail
the integrity check.

3. If we go back to using an unkeyed checksum (as we did in 1.6), we run
into a second problem: we get a reply back from AD that we can't
decrypt, even with the workaround of r22325. That problem dates back to
when we started using subkeys in TGS requests.

Sam can now reproduce at least the immediate problem against WIN.MIT.EDU.
# Mon May 18 19:28:54 2009 hartmans (Sam Hartman) - Given to hartmans (Sam Hartman)
# Mon May 18 19:28:54 2009 hartmans (Sam Hartman) - Status changed from 'new' to 'open'
# Mon May 18 19:28:54 2009 hartmans (Sam Hartman) - Correspondence added
From: hartmans@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 223B

In practice, key usage 9 requires no translation.

https://github.com/krb5/krb5/commit/29e1669d344682c8b44b60c1e299b4b59308e70c
Commit By: hartmans
Revision: 22355
Changed Files:
U trunk/src/lib/crypto/arcfour/arcfour.c
# Mon May 18 21:32:37 2009 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 1.3KiB
Here is what we know right now:

1. If you use a keyed checksum with RC4 keys and an authenticator subkey
in a TGS request, AD 2003 verifies the checksum using the subkey. It
turns out that RFC 4120 doesn't specify what key to use for AP-REQ
checksums, but Heimdal and MIT use the TGS session key. RFC 4757
(Microsoft's own informational RFC about RC4-HMAC) says to use the TGS
session key, so MS is in conflict with its own documentation if not with
the binding standards.

What we don't yet know for sure is whether this problem affects AES. We
need to find that out to know the appropriate scope of the fix. If the
problem affects only RC4, then the appropriate answer is probably "don't
use keyed checksums with RC4, it hurts." If the problem affects AES as
well, then it gets more involved.

2. RFC 4757 erroneously documents a key usage of 8 for a TGS-REP
encrypted part authenticated with a subkey; the value used by MS is
actually 9. Unfortunately, Heimdal and MIT both implement what is
documented. This means you can't interoperate with both {Heimdal or MIT
1.6} and AD with RC4 TGS subkeys using a single key usage value. It's
easy enough to try both when decrypting the response, however.

Sam has committed a change to switch from 8 to 9, fixing TGS RC4 subkey
interoperability with MS but breaking it with Heimdal and MIT 1.6. We
will need to amend this to try both usage values.
# Tue May 19 18:24:49 2009 tlyu (Taylor Yu) - Correspondence added
To: rt@krbdev.MIT.EDU
Subject: Re: [krbdev.mit.edu #6490] [Russ Allbery] Bug#528729: libkrb5-3: cannot obtain cross-realm tickets with Windows 2003 AD
From: Tom Yu <tlyu@MIT.EDU>
Date: Tue, 19 May 2009 18:24:46 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.9KiB
"Greg Hudson via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> Here is what we know right now:
>
> 1. If you use a keyed checksum with RC4 keys and an authenticator subkey
> in a TGS request, AD 2003 verifies the checksum using the subkey. It
> turns out that RFC 4120 doesn't specify what key to use for AP-REQ
> checksums, but Heimdal and MIT use the TGS session key. RFC 4757
> (Microsoft's own informational RFC about RC4-HMAC) says to use the TGS
> session key, so MS is in conflict with its own documentation if not with
> the binding standards.
>
> What we don't yet know for sure is whether this problem affects AES. We
> need to find that out to know the appropriate scope of the fix. If the
> problem affects only RC4, then the appropriate answer is probably "don't
> use keyed checksums with RC4, it hurts." If the problem affects AES as
> well, then it gets more involved.

Confirmed that the keyed checksum problem does not appear on Windows
Server 2008 SP1 with AES-256 keys.

Also, the RC4 keyed checksum failure does not occur on Windows Server
2008 SP1, so I can infer that Microsoft considered it to be a bug and
fixed it on Windows Server 2008 SP1 (or maybe even before SP1).

Show quoted text
> 2. RFC 4757 erroneously documents a key usage of 8 for a TGS-REP
> encrypted part authenticated with a subkey; the value used by MS is
> actually 9. Unfortunately, Heimdal and MIT both implement what is
> documented. This means you can't interoperate with both {Heimdal or MIT
> 1.6} and AD with RC4 TGS subkeys using a single key usage value. It's
> easy enough to try both when decrypting the response, however.
>
> Sam has committed a change to switch from 8 to 9, fixing TGS RC4 subkey
> interoperability with MS but breaking it with Heimdal and MIT 1.6. We
> will need to amend this to try both usage values.

Confirmed that Windows Server 2008 SP1 appears to use key usage 9 for
TGS-REP encrypted part with RC4. (Fails before r22355 change,
succeeds with r22355.)
# Tue May 19 19:17:51 2009 ghudson@mit.edu (Greg Hudson) - Tags pullup added
# Tue May 19 19:17:51 2009 ghudson@mit.edu (Greg Hudson) - Correspondence added
From: ghudson@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 678B

When using keyed checksum types with TGS subkeys, Microsoft AD 2003
verifies the checksum using the subkey, whereas MIT and Heimdal verify
it using the TGS session key. (RFC 4120 is actually silent on which
is correct; RFC 4757 specifies the TGS session key.) To sidestep this
interop issue, don't use keyed checksum types with RC4 keys without
explicit configuration in krb5.conf. Using keyed checksum types with
AES is fine since, experimentally, AD 2008 accepts checksums keyed
with the TGS session key.


https://github.com/krb5/krb5/commit/05c7822d0e5118df745685ab2f9b20fe07dcfb6c
Commit By: ghudson
Revision: 22356
Changed Files:
U trunk/src/lib/krb5/krb/send_tgs.c
# Tue May 19 22:05:53 2009 ghudson@mit.edu (Greg Hudson) - Status changed from 'open' to 'review'
# Tue May 19 22:05:53 2009 ghudson@mit.edu (Greg Hudson) - Correspondence added
From: ghudson@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 348B

Restore compatibility with KDCs using key usage 8 to encrypt TGS
replies in a subkey, by implementing a fallback in
krb5_arcfour_decrypt.


https://github.com/krb5/krb5/commit/689473cbbd1fc5a750e0edc8292ad8f6f51e0496
Commit By: ghudson
Revision: 22357
Changed Files:
U trunk/src/lib/crypto/arcfour/arcfour.c
U trunk/src/lib/crypto/t_encrypt.c
# Tue May 19 22:07:36 2009 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 80B
Both problems tracked here should now be fixed on trunk, and soon in 1.7
beta 3.
# Wed May 20 10:29:45 2009 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 262B
A correction, for posterity:

RFC 4120 does actually specify the key to be used for ap-req checksums,
including for TGS reqs, in the list of key usages (7.5.1), and I missed
that on my reading. (It should probably also be specified in the text,
but it's there.)
# Sun May 24 18:51:00 2009 tlyu (Taylor Yu) - Version_Fixed 1.7 added
# Sun May 24 18:51:00 2009 tlyu (Taylor Yu) - Correspondence added
From: tlyu@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 1.5KiB

pull up 22355, 22356, 22357 from trunk

------------------------------------------------------------------------
r22357 | ghudson | 2009-05-20 04:05:53 +0200 (Wed, 20 May 2009) | 6 lines

ticket: 6490

Restore compatibility with KDCs using key usage 8 to encrypt TGS
replies in a subkey, by implementing a fallback in
krb5_arcfour_decrypt.

------------------------------------------------------------------------
r22356 | ghudson | 2009-05-20 01:17:49 +0200 (Wed, 20 May 2009) | 13 lines

ticket: 6490
status: open
tags: pullup

When using keyed checksum types with TGS subkeys, Microsoft AD 2003
verifies the checksum using the subkey, whereas MIT and Heimdal verify
it using the TGS session key. (RFC 4120 is actually silent on which
is correct; RFC 4757 specifies the TGS session key.) To sidestep this
interop issue, don't use keyed checksum types with RC4 keys without
explicit configuration in krb5.conf. Using keyed checksum types with
AES is fine since, experimentally, AD 2008 accepts checksums keyed
with the TGS session key.

------------------------------------------------------------------------
r22355 | hartmans | 2009-05-19 01:28:53 +0200 (Tue, 19 May 2009) | 5 lines

ticket: 6490
status: open

In practice, key usage 9 requires no translation.

https://github.com/krb5/krb5/commit/f64ca62bda058a468025b4ed868534d93fc5fbde
Commit By: tlyu
Revision: 22374
Changed Files:
U branches/krb5-1-7/src/lib/crypto/arcfour/arcfour.c
U branches/krb5-1-7/src/lib/crypto/t_encrypt.c
U branches/krb5-1-7/src/lib/krb5/krb/send_tgs.c
# Tue May 26 05:23:10 2009 tlyu (Taylor Yu) - Subject changed from '[Russ Allbery] Bug#528729: libkrb5-3: cannot obtain cross-realm tickets with Windows 2003 AD' to 'Windows interop with RC4 TGS-REQ subkeys'
# Wed Dec 16 18:02:54 2015 tlyu (Taylor Yu) - CustomField pullup deleted
# Sun Sep 24 20:39:54 2017 ghudson@mit.edu (Greg Hudson) - Status changed from 'review' to 'resolved'