Skip Menu |
 

To: krb5-bugs@mit.edu
RT-Send-CC: rafael@mail.ufsm.br
Subject: Hierarchical cross-realm seems broken
From: Sam Hartman <hartmans@MIT.EDU>
Date: Sun, 27 Oct 2002 15:24:56 -0500

The behavior described here should work as I understand the code. I'm able to reproduce in a test setup as follows:

* FOO.SUCHDAMAGE.ORG shares a key with SUCHDAMAGE.ORG

* I get FOO.SUCHDAMAGE.ORG tickets and ask for tickets in the Athena realm.

* Since SUCHDAMAGE.ORG and ATHENA share tickets, and since the step
from foo.suchdamage.org to suchdamage.org is hierarchical, this
should be allowed.

However here is what I see:

hartmans@tir-na-nogth:bar-test(1414)> ./kinit hartmans
Password for hartmans@FOO.SUCHDAMAGE.ORG:
hartmans@tir-na-nogth:bar-test(1415)> ./kvno host/luminous.mit.edu@ATHENA.MIT.EDU
host/luminous.mit.edu@ATHENA.MIT.EDU: Invalid message type while getting credentials
hartmans@tir-na-nogth:bar-test(1416)> ./kvno host/luminous.mit.edu@ATHENA.MIT.EDU
host/luminous.mit.edu@ATHENA.MIT.EDU: KDC policy rejects request while getting credentials
hartmans@tir-na-nogth:bar-test(1417)>
So, I think this is broken.
Download (untitled)
message/rfc822 3.9KiB
Return-Path: <kerberos-admin@MIT.EDU>
Received: from solipsist-nation ([unix socket])
by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Fri, 25 Oct
2002 16:47:32 -0400
X-Sieve: CMU Sieve 2.2
Return-Path: <kerberos-admin@MIT.EDU>
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by suchdamage.org (Postfix) with ESMTP id 853F41315E
for <hartmans@suchdamage.org>; Fri, 25 Oct 2002 16:47:32 -0400 (EDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA26990;
Fri, 25 Oct 2002 16:47:26 -0400 (EDT)
Received: from pch.mit.edu (localhost [127.0.0.1])
by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA04772;
Fri, 25 Oct 2002 16:47:05 -0400 (EDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by pch.mit.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA04765
for <kerberos@PCH.mit.edu>; Fri, 25 Oct 2002 16:46:47 -0400 (EDT)
Received: from hostmail.ufsm.br (hostmail.ufsm.br [200.18.33.122])
by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA26549
for <kerberos@mit.edu>; Fri, 25 Oct 2002 16:46:33 -0400 (EDT)
Received: from www-data by hostmail.ufsm.br with local (Exim 3.35 #1)
id 185BMM-0003F2-00
for kerberos@mit.edu; Fri, 25 Oct 2002 17:47:10 -0300
To: kerberos@mit.edu
Subject: Problem with Cross REALM authentication hierarchly
From: Rafael da Rosa Righi <rafael@mail.ufsm.br>
Message-Id: <E185BMM-0003F2-00@hostmail.ufsm.br>
Sender: kerberos-admin@MIT.EDU
Errors-To: kerberos-admin@MIT.EDU
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Post: <mailto:kerberos@mit.edu>
List-Subscribe: <http://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=subscribe>
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <http://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
Date: Fri, 25 Oct 2002 17:47:10 -0300
X-Spam-Status: No, hits=0.6 required=5.0 tests=PORN_10,LINES_OF_YELLING
version=2.20
X-Spam-Level:
MIME-Version: 1.0

Hello all,

I tried to configure a cross realm auth. with 3 REALMS .
I am going to show my problem with examples:

First REALM: XXXX.BR
Second REALM: YYY.XXXX.BR
Third REALM: ZZZ.XXXX.BR

XXXX.BR
/ \
/ \
YYY.XXX.BR ZZZ.XXXX.BR

This is the same organization of DNS.
I constructed cross realm authentication between XXXX.BR and
YYY.XXXX.BR and this is OK. I constructed too, another cross realm
authentication between XXXX.BR and ZZZ.XXXX.BR and this is OK.

The problem is:

When I try an authentication between YYY.XXXX.BR and ZZZ.XXXX.BR I
recept a error. I configured the .k5login, krb5.keytab, the enctypes, the
enc-salt, key version.

************************************************************************************
KDC register: (Before I get TGT ticket for rafaelr@YYY.XXXX.BR)

Oct 25 17:05:53 r.ufm.br krb5kdc[30473](info): TGS_REQ (3 etypes {16 3 1})
200.xx.xx.xx ( 88): ISSUE: authtime 1035572747, etypes {rep=16 tkt=16
ses=16}, rafaelr@YYY.XXXX.BR for krbtgt /ZZZ.XXXX.BR@XXXX.BR

Oct 25 17:05:53 r.ufsm.br krb5kdc[30473](info): bad realm transit path from
'rafaelr@YYY.XXXX.BR to 'host/rmachine.AT.ZZZ.XXXX.BR@ZZZ.XXXX.BR via
'XXXX.BR'

Oct 25 17:05:53 re.ufm.br krb5kdc[30473](info): TGS_REQ (3 etypes {16 3 1})
200.xx.xx.xx(88): BAD_TRANSIT: authtime 1035572747, rafaelr@YYY.XXXX.BR for
host/ machine.AT.ZZZ.XXXX.BR@ZZZ.XXXX.BR KDC policy rejects request
****************************************************************************************

Thank you for help.

Rafael Righi. Brazil
Show quoted text
________________________________________________
Kerberos mailing list Kerberos@mit.edu
http://mailman.mit.edu/mailman/listinfo/kerberos
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1230] Hierarchical cross-realm seems broken
Date: Sun, 27 Oct 2002 16:10:39 -0500
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Show quoted text
>The behavior described here should work as I understand the code. I'm able
>to reproduce in a test setup as follows:
>[...]

A co-worker of mine told me he discovered a bug regarding transitive
cross-realm in the 1.2.6 code (which might apply to this case).
I'll bug him and see if I can get a more exact report to see if
this is the issue.

--Ken
To: rt-comment@krbdev.mit.edu
Subject: [krbdev.mit.edu #1230] Confirmed broken but test tools all seem to indicate it should work
Date: Sun, 27 Oct 2002 17:52:18 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


I tried the test again with a setup where I controlled all the KDCs
involved. I still get denied by KDC policy.


However,
hartmans@tir-na-nogth:kdc(1512)> ./rtest "" SUCHDAMAGE.ORG FOO.SUCHDAMAGE.ORG ATHENA.MIT.EDU
SUCHDAMAGE.ORG

hartmans@tir-na-nogth:krb(1514)> ./t_expand -v FOO.SUCHDAMAGE.ORG ATHENA.MIT.EDU SUCHDAMAGE.ORG
krb5_check_transited_list(trans="SUCHDAMAGE.ORG", crealm="FOO.SUCHDAMAGE.ORG", srealm="ATHENA.MIT.EDU")
tgs list = {
'krbtgt/FOO.SUCHDAMAGE.ORG@FOO.SUCHDAMAGE.ORG'
'krbtgt/SUCHDAMAGE.ORG@FOO.SUCHDAMAGE.ORG'
'krbtgt/ORG@SUCHDAMAGE.ORG'
'krbtgt/EDU@ORG'
'krbtgt/MIT.EDU@EDU'
'krbtgt/ATHENA.MIT.EDU@MIT.EDU'
}
client realm: FOO.SUCHDAMAGE.ORG
server realm: ATHENA.MIT.EDU
transit enc.: SUCHDAMAGE.ORG
.. checking 'SUCHDAMAGE.ORG'
YES

And looking at the KDC code in do_tgs_req.c I do not see obvious problems.
From: hartmans@mit.edu
Subject: CVS Commit
Don't include trailing null in the transited encoding produced by the KDC.
Other routines do not expect the null to be included in the length so
policy checks fail. Also, sending the null over the wire is wrong.


To generate a diff of this commit:



cvs diff -r5.237 -r5.238 krb5/src/kdc/ChangeLog
cvs diff -r5.105 -r5.106 krb5/src/kdc/kdc_util.c
To: krbdev@mit.edu
Cc: rt-comment@krbdev.mit.edu
Subject: [krbdev.mit.edu #1230] Transited realm handling
Date: Sun, 27 Oct 2002 21:34:13 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


Bug 1230 notes that we were included a trailing null in transited
realm encodings that we send over the wire and check against KDC
policy.


I have fixed this code but not yet closed out the bug. We could
include an additional fix to better deal with encodings that include a
trailing null received from other KDCs.

The disadvantage is that we would consider realms differing only in a
trailing null character the same for trust comparisons. Also, it is
not clear how useful the fix will be since I think our current KDC
code will always force a non-null transited encoding to fail the
cross-realm policy check.


Thoughts?
To: hartmans@MIT.EDU (Sam Hartman)
Cc: krbdev@mit.edu, rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1230] Transited realm handling
From: Tom Yu <tlyu@mit.edu>
Date: Tue, 29 Oct 2002 18:23:01 -0500
RT-Send-Cc:
Show quoted text
>>>>> "hartmans" == Sam Hartman <hartmans@MIT.EDU> writes:

Show quoted text
hartmans> We could include an additional fix to better deal with
hartmans> encodings that include a trailing null received from other
hartmans> KDCs.

I would support ignoring of NULs in the transited field.

Show quoted text
hartmans> The disadvantage is that we would consider realms differing
hartmans> only in a trailing null character the same for trust
hartmans> comparisons. Also, it is not clear how useful the fix will
hartmans> be since I think our current KDC code will always force a
hartmans> non-null transited encoding to fail the cross-realm policy
hartmans> check.

RFC 1510 forbade NULs in realm names, so this shouldn't create a
security issue. Failing to ignore NULs in transited fields basically
forces all realms involved in a transitive cross-realm authentication
to be running code that doesn't insert the NUL characters.

---Tom
From: hartmans@mit.edu
Subject: CVS Commit
Ignore trailing nulls on incoming tr encoding to be compatible
with bug in previous versions of krb5


To generate a diff of this commit:



cvs diff -r5.354 -r5.355 krb5/src/lib/krb5/krb/ChangeLog
cvs diff -r5.17 -r5.18 krb5/src/lib/krb5/krb/chk_trans.c
From: tlyu@mit.edu
Subject: CVS Commit
pull up fix for NUL termination of transited field


To generate a diff of this commit:



cvs diff -r5.176.2.6.2.9 -r5.176.2.6.2.10 krb5/src/kdc/ChangeLog
cvs diff -r5.96.2.2.2.2 -r5.96.2.2.2.3 krb5/src/kdc/kdc_util.c
cvs diff -r5.265.2.27.2.13 -r5.265.2.27.2.14
krb5/src/lib/krb5/krb/ChangeLog
cvs diff -r5.11.6.1.2.1 -r5.11.6.1.2.2
krb5/src/lib/krb5/krb/chk_trans.c