Ticket History #2641: KRB5_KDB_DISALLOW_SVR flag unnecessarily prevents User2User

From krb5-bugs-incoming-bounces@mit.edu Mon Jul 19 21:22:31 2004
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.9.3p2) with ESMTP
id VAA24577; Mon, 19 Jul 2004 21:22:31 -0400 (EDT)
Received: from pch.mit.edu (localhost [127.0.0.1])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6K1MUl1027239
for <krb5-send-pr@krbdev.mit.edu>; Mon, 19 Jul 2004 21:22:30 -0400 (EDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6FNR8l1007521
for <krb5-bugs-incoming@PCH.mit.edu>;
Thu, 15 Jul 2004 19:27:08 -0400 (EDT)
Received: from MM01SNLNTO.son.sandia.gov (mm01snlnto.sandia.gov
[132.175.109.20])i6FNR7cZ029555
for <krb5-bugs@mit.edu>; Thu, 15 Jul 2004 19:27:07 -0400 (EDT)
Received: from 132.175.109.1 by mm02snlnto.son.sandia.gov with ESMTP (
Tumbleweed MMS SMTP Relay 01 (MMS v5.6.1)); Thu, 15 Jul 2004 17:26:58
-0600
X-Server-Uuid: 8A37177F-35F9-47CF-80CF-3627B2E578DE
Received: from es08snlnt.sandia.gov (smtp-in.sandia.gov [134.253.130.11]
) by sass165.sandia.gov (8.12.10/8.12.10) with ESMTP id i6FNQuYH024869
for <krb5-bugs@mit.edu>; Thu, 15 Jul 2004 17:26:56 -0600 (MDT)
Received: by es08snlnt.sandia.gov with Internet Mail Service (
5.5.2653.19) id <3C9NAKS8>; Thu, 15 Jul 2004 17:26:55 -0600
Message-ID: <AC89BDA1E3CCBC42B9CA5B50FE7934D3067819FC@es10snlnt.sandia.gov>
From: "Moore, Patrick" <pcmoore@sandia.gov>
To: "'krb5-bugs@mit.edu'" <krb5-bugs@mit.edu>
Date: Thu, 15 Jul 2004 17:26:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-PMX-Version: 4.6.0.99824, Antispam-Core: 4.6.1.104326, Antispam-Data:
2004.7.15.107631
X-WSS-ID: 6CE9CD481D868866-01-01
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 19 Jul 2004 21:22:28 -0400
Subject: KRB5_KDB_DISALLOW_SVR flag prevents User2User authentication
X-BeenThere: krb5-bugs-incoming@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Sender: krb5-bugs-incoming-bounces@mit.edu
Errors-To: krb5-bugs-incoming-bounces@mit.edu


authentication
N/A


Reviving an old issue . . .
With MIT KDC, there is no way to allow user2user authentication unless you
also allow conventional service tickets for that user, which some sites
consider an unacceptable security risk.

A couple years back, Nico Williams suggested (to the kerbdev list) a
potential fix via a simple patch to kdc/kdc_util.c. My fix below is
essentially Nico's suggestion.

Note: I know that DCE KDC's allow user2user without allowing conventional
service tickets (they use a special flag.) I understand that Msoft can allow
user2user without allowing conventional service tickets.


If you set "+allow svr" and "+allow dup skey", then you can get a
user2user ticket for that principal, but unfortunately you can also get a
conventional ticket. If you set "-allow svr" and "allow dup skey", you
cannot get a user2user ticket for that principal.




Seems sensible that if a principal was set "-allow svr" AND "+allow dup
skey" that user2user tickets should work, and conventional service tickets
should not work. The patch below would provide that functionality.

*** kdc_util.orig.c Thu Jul 15 13:42:01 2004
--- kdc_util.new.c Thu Jul 15 13:44:51 2004
***************
*** 1271,1277 ****
}

/* Server must be allowed to be a service */
! if (isflagset(server.attributes, KRB5_KDB_DISALLOW_SVR)) {
*status = "SERVER NOT ALLOWED";
return(KDC_ERR_S_PRINCIPAL_UNKNOWN);
}
--- 1271,1278 ----
}

/* Server must be allowed to be a service */
! if (isflagset(server.attributes, KRB5_KDB_DISALLOW_SVR) &&
! !isflagset(request->kdc_options, KDC_OPT_ENC_TKT_IN_SKEY)) {
*status = "SERVER NOT ALLOWED";
return(KDC_ERR_S_PRINCIPAL_UNKNOWN);
}

I'm a bit concerned because I believe that allow dup skey is the
default. I'm not sure that the behavior people expect when they turn
off allow_svr is to enable user2user.

I'd be interested in other comments on this.

kenh@cmf> FWIW, I think people expect U2U to work all of the time
kenh@cmf> (while I think that there may be some reason I can't
kenh@cmf> imagine for people to want to turn it off, all of the
kenh@cmf> ones I'm aware of are inadvertent because they turned
kenh@cmf> off allow_svr on user principals). And as I read
kenh@cmf> things, allow_svr is off by default.

I'm thinking of cases where the principal is partially or fully
disabled.

I agree that the proposed fix would cause a
subtle change of KDC behavior, but like Ken,
I can't imagine that it would catch anyone
by surprise. And the fix is a really
important security feature to any site that needs
to allow user2user, and to require preauthentication.

Text could be added to the
release notes that this fix allows user2user
tickets for principals that are set
-allow_svr (which was not the case in
previous KDCs)

I also think the documentation could be
made more clear.


Below are four suggested changes
to doc/admin.texinfo

1)---------------------------
OLD admin.texinfo:
@itemx dup-skey
Enabling this flag allows the principal
to obtain a session key for
another user, permitting user-to-user
authentication for this principal.

NEW admin.texinfo:
@itemx dup-skey
Enabling this flag allows the KDC to
issue a user-to-user service ticket
for this principal.

2)--------------------
OLD admin.texinfo:
@itemx service
Enabling this flag allows the KDC
to issue service tickets for this
principal.

NEW admin.texinfo:
Enabling this flag allows the KDC
to issue service tickets for this
principal that contain text encrypted
in the principal's key, which may
be a security issue.

3) -------------------------
OLD admin.texinfo:
@item @{-|+@}allow_dup_skey
The ``-allow_dup_skey'' option disables
user-to-user authentication for
this principal by prohibiting this
principal from obtaining a session
key for another user.
``+allow_dup_skey'' clears this flag.
In effect,``-allow_dup_skey'' sets
the @* KRB5_KDB_DISALLOW_DUP_SKEY flag on the
principal in the database.

NEW admin.texinfo:
@item @{-|+@}allow_dup_skey
The ``-allow_dup_skey'' option disables
user-to-user authentication for
this principal by prohibiting others
from obtaining a service ticket encrypted
in this principal's TGT session key.
``+allow_dup_skey'' clears this flag.
In effect,``-allow_dup_skey'' sets the
@* KRB5_KDB_DISALLOW_DUP_SKEY flag on the
principal in the database.


4) -------------------------------------
OLD admin.texinfo:
@item @{-|+@}allow_svr
The ``-allow_svr'' flag prohibits the issuance
of service tickets for this principal.
``+allow_svr'' clears this flag. In effect,
``-allow_svr'' sets the
@* KRB5_KDB_DISALLOW_SVR flag on the
principal in the database.

NEW admin.texinfo:
@item @{-|+@}allow_svr
The ``-allow_svr'' flag prohibits the issuance
of service tickets for this principal
that contain text encrypted in the
principal's key. Failing to set ``-allow_svr``
on user principals may be a security issue.
``+allow_svr'' clears this flag. In effect,
``-allow_svr'' sets the
@* KRB5_KDB_DISALLOW_SVR flag on the
principal in the database.

This was fixed by commit 23dc2efc6419c7abbac183a46ed89a16be33a48a which first appeared in release 1.17.  I apparently didn't format the commit message quite right, so the usual RT processing wasn't performed at the time.