Skip Menu |
 

Download (untitled) / with headers
text/plain 1.9KiB
From crawdad@gungnir.fnal.gov Thu Mar 28 10:25:34 2002
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id KAA06130
for <bugs@RT-11.mit.edu>; Thu, 28 Mar 2002 10:25:34 -0500 (EST)
Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20])
by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA09562
for <krb5-bugs@mit.edu>; Thu, 28 Mar 2002 10:25:33 -0500 (EST)
Received: from gungnir.fnal.gov ([131.225.80.1])
by smtp.fnal.gov (PMDF V6.0-24 #37519)
with ESMTP id <0GTO00EJ7W6LKT@smtp.fnal.gov> for krb5-bugs@mit.edu; Thu,
28 Mar 2002 09:25:33 -0600 (CST)
Received: (from crawdad@localhost) by gungnir.fnal.gov (8.10.2+Sun/8.10.2)
id g2SFPWM25016; Thu, 28 Mar 2002 09:25:32 -0600 (CST)
Message-Id: <200203281525.g2SFPWM25016@gungnir.fnal.gov>
Date: Thu, 28 Mar 2002 09:25:32 -0600 (CST)
From: Matt Crawford <crawdad@gungnir.fnal.gov>
Reply-To: crawdad@gungnir.fnal.gov
To: krb5-bugs@mit.edu
Cc: crawdad@gungnir.fnal.gov
Subject: Need a way to allow user-to-user but not other TGS-REQs
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 1081
>Category: krb5-kdc
>Synopsis: enhancement request: allow user2user only
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Thu Mar 28 10:26:00 EST 2002
>Last-Modified:
>Originator: Matt Crawford
>Organization:
Fermilab
Show quoted text
>Release: krb5-1.2.3
>Environment:
Sun Netra-1 Solaris 2.8
System: SunOS gungnir.fnal.gov 5.8 Generic_108528-08 sun4u sparc SUNW,Ultra-1
Architecture: sun4

Show quoted text
>Description:
KRB5_KDB_DISALLOW_SVR disallows all TGS requests for a given
service principal. There needs to be away to disallow all but
USER2USER.
Show quoted text
>How-To-Repeat:
Test with sample uuclient/uuserver
Show quoted text
>Fix:
Suggestions have appeared in krbdev list. I'm just being a good
boy by putting this into the bug queue to keep it on the radar.
Show quoted text
>Audit-Trail:
>Unformatted:
Download (untitled) / with headers
text/plain 4.1KiB
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


Show quoted text
>Submitter-Id: net
>Originator: Pat Moore, pcmoore@sandia.gov
>Organization: Sandia National Laboratories
>Confidential: no
>Synopsis: KRB5_KDB_DISALLOW_SVR flag unnecessarily prevents User2User
authentication
Show quoted text
>Severity: non-critical
>Priority: low
>Category: krb5-kdc
>Class: change-request
>Release: krb5-1.3.4
>Environment:
N/A


Show quoted text
>Description:
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.


Show quoted text
>How-To-Repeat:
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.


Show quoted text
>Fix:


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);
}
To: rt@krbdev.mit.edu
Cc:
Subject: Re: [krbdev.mit.edu #2641] KRB5_KDB_DISALLOW_SVR flag unnecessarily prevents User2User
From: Sam Hartman <hartmans@mit.edu>
Date: Tue, 20 Jul 2004 14:02:42 -0400
RT-Send-Cc:
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.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2641] KRB5_KDB_DISALLOW_SVR flag unnecessarily prevents User2User
Date: Tue, 20 Jul 2004 14:19:59 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Show quoted text
>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.

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

--Ken
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2641] KRB5_KDB_DISALLOW_SVR flag unnecessarily prevents User2User
From: Sam Hartman <hartmans@mit.edu>
Date: Tue, 20 Jul 2004 17:47:08 -0400
RT-Send-Cc:
Show quoted text
>>>>> "kenh@cmf" == kenh@cmf nrl navy mil via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
>> 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.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2641] KRB5_KDB_DISALLOW_SVR flag unnecessarily prevents User2User
Date: Wed, 21 Jul 2004 12:25:23 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
RT-Send-Cc:
Show quoted text
> 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.

By "fully" disabled, you mean they set DISALLOW_ALL_TIX, right? As
I read the patch, that wouldn't affect that; if you set it, it would
still disallow U2U for that principal. And I guess I don't know
what partially disabled is, exactly.

--Ken
From: "Moore, Patrick" <pcmoore@sandia.gov>
To: "'rt-comment@krbdev.mit.edu'" <rt-comment@krbdev.mit.edu>
Cc: "'kenh@cmf.nrl.navy.mil'" <kenh@cmf.nrl.navy.mil>, "'hartmans@mit.edu'" <hartmans@mit.edu>
Subject: RE: [krbdev.mit.edu #2641] KRB5_KDB_DISALLOW_SVR flag unnecessari ly prevents User2User
Date: Thu, 22 Jul 2004 14:11:25 -0600
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.6KiB
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.
To: rt@krbdev.mit.edu
Cc:
Subject: Re: [krbdev.mit.edu #2641] KRB5_KDB_DISALLOW_SVR flag unnecessari ly prevents User2User
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 22 Jul 2004 16:35:10 -0400
RT-Send-Cc:
Show quoted text
>>>>> "pcmoore@sandia" == pcmoore@sandia gov via RT <rt-comment@krbdev.mit.edu> writes:

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

I don't consider this a high priority for our implementation because
we don't really have a good implementation of U2U at the current time.

We'd need to have SPNEGO, so a client can determine whether it should
be using U2U or normal Kerberos. We'd also need to support the U2U
mechanism.

I'm not sure I see a problem taking the patch under than the change in
semantics.

So again, I continue to believe that the best course of action is to
solicit review of the change in semantics and if people don't complain
then adopt the patch.
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.