Skip Menu |
 

Download (untitled) / with headers
text/plain 9.1KiB
From krb5-bugs-incoming-bounces@PCH.MIT.EDU Tue Jul 17 15:00:15 2007
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.12.9) with ESMTP
id l6HJ0FHW022702; Tue, 17 Jul 2007 15:00:15 -0400 (EDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6HJ09cN006344;
Tue, 17 Jul 2007 15:00:09 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
[18.7.7.76])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id l6HGNunr004112
for <krb5-bugs-incoming@PCH.mit.edu>; Tue, 17 Jul 2007 12:23:56 -0400
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223])
by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
l6HGNp47012748
for <krb5-bugs@mit.edu>; Tue, 17 Jul 2007 12:23:51 -0400 (EDT)
Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
by mit.edu (Spam Firewall) with ESMTP id 564293DAFF5
for <krb5-bugs@mit.edu>; Tue, 17 Jul 2007 12:23:48 -0400 (EDT)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6HGNlhb001828
for <krb5-bugs@mit.edu>; Tue, 17 Jul 2007 12:23:47 -0400
Received: from rapier.boston.redhat.com (rapier.boston.redhat.com
[172.16.80.53])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6HGNk03019623
for <krb5-bugs@mit.edu>; Tue, 17 Jul 2007 12:23:47 -0400
Received: from rapier.boston.redhat.com (localhost.localdomain [127.0.0.1])
by rapier.boston.redhat.com (8.14.1/8.14.0) with ESMTP id
l6HGNkTY006275
for <krb5-bugs@mit.edu>; Tue, 17 Jul 2007 12:23:46 -0400
Received: (from nalin@localhost)
by rapier.boston.redhat.com (8.14.1/8.14.1/Submit) id l6HGNkxS006274;
Tue, 17 Jul 2007 12:23:46 -0400
Date: Tue, 17 Jul 2007 12:23:46 -0400
Message-Id: <200707171623.l6HGNkxS006274@rapier.boston.redhat.com>
To: krb5-bugs@mit.edu
Subject: patch to allow setting ok-as-delegate flag in database
From: nalin@redhat.com
X-send-pr-version: 3.99
X-Spam-Score: 0.55
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 17 Jul 2007 15:00:08 -0400
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: nalin@redhat.com
Sender: krb5-bugs-incoming-bounces@PCH.MIT.EDU
Errors-To: krb5-bugs-incoming-bounces@PCH.MIT.EDU

Show quoted text
>Submitter-Id: net
>Originator:
>Organization:
>Confidential: no
>Synopsis: patch for providing a way to set the ok-as-delegate flag
>Severity: non-critical
>Priority: low
>Category: krb5-admin
>Class: change-request
>Release: 1.6.1
>Environment:

System: Linux rapier.boston.redhat.com 2.6.21-1.3230.fc8 #1 SMP Wed Jun 20 15:59:23 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64

Show quoted text
>Description:
Currently, the KDC doesn't issue credentials with the ok-as-delegate
flag set, and the realm database doesn't have a means of indicating
to the KDC that it should.
Show quoted text
>Fix:
Here's a patch which allows me to set the flag with kadmin, store it as
an attribute bit in the KDB database, and get credentials with the bit
set from the KDC, which I think is all that's required here. There's
no logic added to the client libraries to actually *do* anything with
that bit, though, because that'd be more complicated.

Index: doc/admin.texinfo
===================================================================
--- doc/admin.texinfo (revision 19714)
+++ doc/admin.texinfo (working copy)
@@ -2758,6 +2758,13 @@
@samp{KRB5_KDB_REQURES_HW_AUTH} flag.) @code{-requires_hwauth} clears
this flag.

+@itemx @{-|+@}ok_as_delegate
+@code{+ok_as_delegate} sets the OK-AS-DELEGATE flag on tickets issued for use
+with this principal as the service, which clients may use as a hint that
+credentials can and should be delegated when authenticating to the service.
+(Sets the @samp{KRB5_KDB_OK_AS_DELEGATE} flag.) @code{-ok_as_delegate} clears
+this flag.
+
@itemx @{-|+@}allow_svr
@code{-allow_svr} prohibits the issuance of service tickets for principals. (Sets the @samp{KRB5_KDB_DISALLOW_SVR} flag.) @code{+allow_svr} clears this flag.

Index: src/include/kdb.h
===================================================================
--- src/include/kdb.h (revision 19714)
+++ src/include/kdb.h (working copy)
@@ -79,6 +79,7 @@
#define KRB5_KDB_PWCHANGE_SERVICE 0x00002000
#define KRB5_KDB_SUPPORT_DESMD5 0x00004000
#define KRB5_KDB_NEW_PRINC 0x00008000
+#define KRB5_KDB_OK_AS_DELEGATE 0x00010000

/* Creation flags */
#define KRB5_KDB_CREATE_BTREE 0x00000001
Index: src/kdc/do_tgs_req.c
===================================================================
--- src/kdc/do_tgs_req.c (revision 19714)
+++ src/kdc/do_tgs_req.c (working copy)
@@ -533,6 +533,10 @@
goto cleanup;
}

+ if (isflagset(server.attributes, KRB5_KDB_OK_AS_DELEGATE)) {
+ setflag(enc_tkt_reply.flags, TKT_FLG_OK_AS_DELEGATE);
+ }
+
ticket_reply.enc_part2 = &enc_tkt_reply;

/*
Index: src/kdc/do_as_req.c
===================================================================
--- src/kdc/do_as_req.c (revision 19714)
+++ src/kdc/do_as_req.c (working copy) @@ -257,6 +257,10 @@ enc_tkt_reply.caddrs = request->addresses;
enc_tkt_reply.authorization_data = 0;

+ if (isflagset(server.attributes, KRB5_KDB_OK_AS_DELEGATE)) {
+ setflag(enc_tkt_reply.flags, TKT_FLG_OK_AS_DELEGATE);
+ }
+
/*
* Check the preauthentication if it is there.
*/
Index: src/kadmin/cli/kadmin.c
===================================================================
--- src/kadmin/cli/kadmin.c (revision 19714)
+++ src/kadmin/cli/kadmin.c (working copy)
@@ -65,7 +65,8 @@
{"needchange", 10, KRB5_KDB_REQUIRES_PWCHANGE, 0},
{"allow_svr", 9, KRB5_KDB_DISALLOW_SVR, 1},
{"password_changing_service", 25, KRB5_KDB_PWCHANGE_SERVICE, 0 },
-{"support_desmd5", 14, KRB5_KDB_SUPPORT_DESMD5, 0 }
+{"support_desmd5", 14, KRB5_KDB_SUPPORT_DESMD5, 0 },
+{"ok_as_delegate", 14, KRB5_KDB_OK_AS_DELEGATE, 0 }
};

static char *prflags[] = {
@@ -85,6 +86,7 @@
"PWCHANGE_SERVICE", /* 0x00002000 */
"SUPPORT_DESMD5", /* 0x00004000 */
"NEW_PRINC", /* 0x00008000 */
+ "OK_AS_DELEGATE", /* 0x00010000 */
};

char *getenv();
@@ -1101,6 +1103,7 @@
"\t\tallow_postdated allow_forwardable allow_tgs_req allow_renewable\n",
"\t\tallow_proxiable allow_dup_skey allow_tix requires_preauth\n",
"\t\trequires_hwauth needchange allow_svr password_changing_service\n"
+ "\t\tok_as_delegate\n"
"\nwhere,\n\t[-x db_princ_args]* - any number of database specific arguments.\n"
"\t\t\tLook at each database documentation for supported arguments\n");
}
@@ -1117,6 +1120,7 @@
"\t\tallow_postdated allow_forwardable allow_tgs_req allow_renewable\n",
"\t\tallow_proxiable allow_dup_skey allow_tix requires_preauth\n",
"\t\trequires_hwauth needchange allow_svr password_changing_service\n"
+ "\t\tok_as_delegate\n"
"\nwhere,\n\t[-x db_princ_args]* - any number of database specific arguments.\n"
"\t\t\tLook at each database documentation for supported arguments\n"
);
Index: src/kadmin/cli/kadmin.M
===================================================================
--- src/kadmin/cli/kadmin.M (revision 19714)
+++ src/kadmin/cli/kadmin.M (working copy)
@@ -327,6 +327,16 @@
.B -requires_hwauth
clears this flag.
.TP
+{\fB\-\fP|\fB+\fP}\fBok_as_delegate\fP
+.B +ok_as_delegate
+sets the OK-AS-DELEGATE flag on tickets issued for use with this principal
+as the service, which clients may use as a hint that credentials can and
+should be delegated when authenticating to the service. (Sets the
+.SM KRB5_KDB_OK_AS_DELEGATE
+flag.)
+.B -ok_as_delegate
+clears this flag.
+.TP
{\fB\-\fP|\fB+\fP}\fBallow_svr\fP
.B -allow_svr
prohibits the issuance of service tickets for this principal. (Sets the
Index: src/lib/kadm5/str_conv.c
===================================================================
--- src/lib/kadm5/str_conv.c (revision 19714)
+++ src/lib/kadm5/str_conv.c (working copy)
@@ -73,6 +73,7 @@
static const char flags_tickets_in[] = "allow-tickets";
static const char flags_preauth_in[] = "preauth";
static const char flags_hwauth_in[] = "hwauth";
+static const char flags_ok_as_delegate_in[] = "ok-as-delegate";
static const char flags_pwchange_in[] = "pwchange";
static const char flags_service_in[] = "service";
static const char flags_pwsvc_in[] = "pwservice";
@@ -86,6 +87,7 @@
static const char flags_tickets_out[] = "All Tickets Disallowed";
static const char flags_preauth_out[] = "Preauthorization required";
static const char flags_hwauth_out[] = "HW Authorization required";
+static const char flags_ok_as_delegate_out[] = "OK as Delegate";
static const char flags_pwchange_out[] = "Password Change required";
static const char flags_service_out[] = "Service Disabled";
static const char flags_pwsvc_out[] = "Password Changing Service";
@@ -109,6 +111,7 @@
{ KRB5_KDB_DISALLOW_ALL_TIX, 0, flags_tickets_in, flags_tickets_out },
{ KRB5_KDB_REQUIRES_PRE_AUTH, 1, flags_preauth_in, flags_preauth_out },
{ KRB5_KDB_REQUIRES_HW_AUTH, 1, flags_hwauth_in, flags_hwauth_out },
+{ KRB5_KDB_OK_AS_DELEGATE, 1, flags_ok_as_delegate_in, flags_ok_as_delegate_out },
{ KRB5_KDB_REQUIRES_PWCHANGE, 1, flags_pwchange_in, flags_pwchange_out},
{ KRB5_KDB_DISALLOW_SVR, 0, flags_service_in, flags_service_out },
{ KRB5_KDB_PWCHANGE_SERVICE, 1, flags_pwsvc_in, flags_pwsvc_out },
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Date: Tue, 17 Jul 2007 16:11:21 -0400
RT-Send-Cc:
Note that this is related to a similar issue that we've received from
Sandia. We should look at both in conjunction and should try to deal
with both soon.
Date: Tue, 17 Jul 2007 16:27:08 -0400
From: Nalin Dahyabhai <nalin@redhat.com>
To: Sam Hartman via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
On Tue, Jul 17, 2007 at 04:11:28PM -0400, Sam Hartman via RT wrote:
Show quoted text
> Note that this is related to a similar issue that we've received from
> Sandia. We should look at both in conjunction and should try to deal
> with both soon.

I have to confess that I'm not really familiar with using RT. Do you
mean #2940? I steered clear of touching client libraries because I
didn't think that always delegating credentials when the flag was set
would be a popular idea.

At first glance, though, it looks pretty easy to hack in. If it's
useful, I can try to put something together, possibly with a
configuration setting to allow disabling the new behavior.

Thanks,

Nalin
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Date: Tue, 17 Jul 2007 16:51:09 -0400
RT-Send-Cc:
Show quoted text
>>>>> "nalin@redhat" == nalin@redhat com via RT <rt-comment@krbdev.mit.edu> writes:

nalin@redhat> On Tue, Jul 17, 2007 at 04:11:28PM -0400, Sam
nalin@redhat> Hartman via RT wrote:
Show quoted text
>> Note that this is related to a similar issue that we've
>> received from Sandia. We should look at both in conjunction
>> and should try to deal with both soon.

nalin@redhat> I have to confess that I'm not really familiar with
nalin@redhat> using RT. Do you mean #2940? I steered clear of
nalin@redhat> touching client libraries because I didn't think
nalin@redhat> that always delegating credentials when the flag was
nalin@redhat> set would be a popular idea.

IT would not. I think I have something more recent than 2940 outside
of rt. Will attemmpt to attach it here.
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Date: Wed, 18 Jul 2007 10:50:36 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 12.7KiB
Here's the current Sandia patch. I'm sorry for sitting on this so
long.

My recommendation is that if possible you use the same flag and kadmin
option that they do. I'm a bit confused by the client support. As
far as I can tell the new function they add is static so I'm not sure
how you'd ever use it.

In terms of a way forward, I think it is reasonable to commit your
server side patches if we end up using the same flag names and kadmin
options or you explain why that would be a bad idea.

I think it would be good to have a client side API that works similar
to the Sandia proposal, but I think it needs another round of work and
I don't think your patches should be blocked on it.


diff -Naur krb5-1.4.3/src/include/krb5/kdb.h krb5-1.4.3.ok_as_del/src/include/krb5/kdb.h
--- krb5-1.4.3/src/include/krb5/kdb.h 2004-06-22 12:14:15.000000000 -0600
+++ krb5-1.4.3.ok_as_del/src/include/krb5/kdb.h 2006-04-12 11:19:10.000000000 -0600
@@ -79,6 +79,7 @@
#define KRB5_KDB_PWCHANGE_SERVICE 0x00002000
#define KRB5_KDB_SUPPORT_DESMD5 0x00004000
#define KRB5_KDB_NEW_PRINC 0x00008000
+#define KRB5_KDB_ALLOW_OK_AS_DELEGATE 0x00010000

/* Creation flags */
#define KRB5_KDB_CREATE_BTREE 0x00000001
diff -Naur krb5-1.4.3/src/include/krb5.hin krb5-1.4.3.ok_as_del/src/include/krb5.hin
--- krb5-1.4.3/src/include/krb5.hin 2005-10-26 16:00:27.000000000 -0600
+++ krb5-1.4.3.ok_as_del/src/include/krb5.hin 2006-04-12 15:06:33.000000000 -0600
@@ -900,6 +900,11 @@
#define KRB5_KPASSWD_BAD_VERSION 6
#define KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 /* unused */

+/* flags for forwarding tickets */
+#define KRB5_FWD_TKT_MUST 0
+#define KRB5_FWD_TKT_MAY 1
+#define KRB5_FWD_TKT_NO 2
+
/*
* end "proto.h"
*/
diff -Naur krb5-1.4.3/src/kadmin/cli/kadmin.c krb5-1.4.3.ok_as_del/src/kadmin/cli/kadmin.c
--- krb5-1.4.3/src/kadmin/cli/kadmin.c 2005-03-22 16:53:59.000000000 -0700
+++ krb5-1.4.3.ok_as_del/src/kadmin/cli/kadmin.c 2006-04-12 11:22:14.000000000 -0600
@@ -59,6 +59,7 @@
{"requires_hwauth", 15, KRB5_KDB_REQUIRES_HW_AUTH, 0},
{"needchange", 10, KRB5_KDB_REQUIRES_PWCHANGE, 0},
{"allow_svr", 9, KRB5_KDB_DISALLOW_SVR, 1},
+{"allow_ok_to_delegate", 20, KRB5_KDB_ALLOW_OK_AS_DELEGATE, 0 },
{"password_changing_service", 25, KRB5_KDB_PWCHANGE_SERVICE, 0 },
{"support_desmd5", 14, KRB5_KDB_SUPPORT_DESMD5, 0 }
};
@@ -80,6 +81,8 @@
"PWCHANGE_SERVICE", /* 0x00002000 */
"SUPPORT_DESMD5", /* 0x00004000 */
"NEW_PRINC", /* 0x00008000 */
+ "ALLOW_OK_AS_DELEGATE", /* 0x00010000 */
+
};

char *getenv();
diff -Naur krb5-1.4.3/src/kdc/do_as_req.c krb5-1.4.3.ok_as_del/src/kdc/do_as_req.c
--- krb5-1.4.3/src/kdc/do_as_req.c 2005-07-12 14:59:52.000000000 -0600
+++ krb5-1.4.3.ok_as_del/src/kdc/do_as_req.c 2006-04-12 13:53:39.000000000 -0600
@@ -192,6 +192,8 @@
/* It should be noted that local policy may affect the */
/* processing of any of these flags. For example, some */
/* realms may refuse to issue renewable tickets */
+ if (isflagset(server.attributes, KRB5_KDB_ALLOW_OK_AS_DELEGATE ))
+ setflag(enc_tkt_reply.flags, TKT_FLG_OK_AS_DELEGATE);

if (isflagset(request->kdc_options, KDC_OPT_FORWARDABLE))
setflag(enc_tkt_reply.flags, TKT_FLG_FORWARDABLE);
diff -Naur krb5-1.4.3/src/lib/kadm5/str_conv.c krb5-1.4.3.ok_as_del/src/lib/kadm5/str_conv.c
--- krb5-1.4.3/src/lib/kadm5/str_conv.c 2001-06-26 13:59:45.000000000 -0600
+++ krb5-1.4.3.ok_as_del/src/lib/kadm5/str_conv.c 2006-04-12 11:31:55.000000000 -0600
@@ -76,6 +76,7 @@
static const char flags_pwchange_in[] = "pwchange";
static const char flags_service_in[] = "service";
static const char flags_pwsvc_in[] = "pwservice";
+static const char flags_delegate_in[] = "ok-to-delegate";
static const char flags_md5_in[] = "md5";
static const char flags_pdate_out[] = "Not Postdateable";
static const char flags_fwd_out[] = "Not Forwardable";
@@ -89,6 +90,7 @@
static const char flags_pwchange_out[] = "Password Change required";
static const char flags_service_out[] = "Service Disabled";
static const char flags_pwsvc_out[] = "Password Changing Service";
+static const char flags_delegate_out[] = "OK To Delegate";
static const char flags_md5_out[] = "RSA-MD5 supported";
static const char flags_default_neg[] = "-";
static const char flags_default_sep[] = " ";
@@ -112,6 +114,7 @@
{ KRB5_KDB_REQUIRES_PWCHANGE, 1, flags_pwchange_in, flags_pwchange_out},
{ KRB5_KDB_DISALLOW_SVR, 0, flags_service_in, flags_service_out },
{ KRB5_KDB_PWCHANGE_SERVICE, 1, flags_pwsvc_in, flags_pwsvc_out },
+{ KRB5_KDB_ALLOW_OK_AS_DELEGATE,1, flags_delegate_in, flags_delegate_out},
{ KRB5_KDB_SUPPORT_DESMD5, 1, flags_md5_in, flags_md5_out }
};
static const int flags_table_nents = sizeof(flags_table)/
diff -Naur krb5-1.4.3/src/lib/krb5/krb/fwd_tgt.c krb5-1.4.3.ok_as_del/src/lib/krb5/krb/fwd_tgt.c
--- krb5-1.4.3/src/lib/krb5/krb/fwd_tgt.c 2003-06-16 16:34:50.000000000 -0600
+++ krb5-1.4.3.ok_as_del/src/lib/krb5/krb/fwd_tgt.c 2006-05-02 10:02:07.000000000 -0600
@@ -33,15 +33,23 @@
/* helper function: convert flags to necessary KDC options */
#define flags2options(flags) (flags & KDC_TKT_COMMON_MASK)

-/* Get a TGT for use at the remote host */
+/* local functions */
+static int str_match(const char *pattern, const char *str);
+static krb5_error_code profile_check_deleg(krb5_context context, krb5_principal server, int * result);
+
+static krb5_error_code krb5_fwd_tgt_creds_flag(krb5_context context, krb5_auth_context auth_context, char *rhost, krb5_principal client, krb5_principal server, krb5_ccache cc, int forwardable, int do_fwd_flag, krb5_data *outbuf);
+
+/* We now use this as a wrapper */
krb5_error_code KRB5_CALLCONV
-krb5_fwd_tgt_creds(krb5_context context, krb5_auth_context auth_context, char *rhost, krb5_principal client, krb5_principal server, krb5_ccache cc, int forwardable, krb5_data *outbuf)
-
-
-
-
-
-
+krb5_fwd_tgt_creds(krb5_context context, krb5_auth_context auth_context, char *rhost, krb5_principal client, krb5_principal server, krb5_ccache cc, int forwardable, krb5_data *outbuf){
+
+ return krb5_fwd_tgt_creds_flag(context, auth_context, rhost, client, server, cc, forwardable, KRB5_FWD_TKT_MUST, krb5_data *outbuf);
+}
+
+
+/* this now supports do_fwd_flag */
+static krb5_fwd_tgt_creds_flag(krb5_context context, krb5_auth_context auth_context, char *rhost, krb5_principal client, krb5_principal server, krb5_ccache cc, int forwardable, int do_fwd_flag, krb5_data *outbuf){
+
/* Should forwarded TGT also be forwardable? */

{
@@ -61,6 +69,12 @@
memset((char *)&creds, 0, sizeof(creds));
memset((char *)&tgt, 0, sizeof(creds));

+ /* i don't know why you would do this */
+ if (do_fwd_flag == KRB5_FWD_TKT_NO){
+ retval = KRB5_TKT_NOT_FORWARDABLE_HERE;
+ goto errout;
+ }
+
if (cc == 0) {
if ((retval = krb5int_cc_default(context, &cc)))
goto errout;
@@ -73,27 +87,54 @@
enctype = session_key->enctype;
krb5_free_keyblock (context, session_key);
session_key = NULL;
- } else if (server) { /* must server be non-NULL when rhost is given? */
- /* Try getting credentials to see what the remote side supports.
- Not bulletproof, just a heuristic. */
- krb5_creds in, *out = 0;
- memset (&in, 0, sizeof(in));
+ }
+
+ if (!server){
+
+ /* there must be a principal name to check for delegation */
+ retval = KRB5_TKT_NOT_FORWARDABLE_HERE;
+ goto errout;
+ }
+ else {
+
+ int match = 0;
+ /* Try getting credentials to see what the remote side supports.
+ Not bulletproof, just a heuristic. */
+ krb5_creds in, *out = 0;
+ memset (&in, 0, sizeof(in));
+
+ retval = krb5_copy_principal (context, server, &in.server);
+ if (retval)
+ goto punt;
+ retval = krb5_copy_principal (context, client, &in.client);
+ if (retval)
+ goto punt;
+ retval = krb5_get_credentials (context, 0, cc, &in, &out);
+ if (retval)
+ goto punt;
+
+ /* if the do_fwd_flag KRB5_FWD_TKT_MUST or
+ * if the do_fwd_flag KRB5_FWD_TKT_MAY && TKT_FLG_OK_AS_DELEGE we delegate */
+ if (((out->ticket_flags & TKT_FLG_OK_AS_DELEGATE) && do_fwd_flag == KRB5_FWD_TKT_MAY)
+ || (do_fwd_flag == KRB5_FWD_TKT_MUST))
+ match = 1;
+
+ /* Got the credentials. Record the enctype if we didn't get one from the session key*/
+ if (!enctype)
+ enctype = out->keyblock.enctype;
+ krb5_free_creds (context, out);
+ punt:
+ krb5_free_cred_contents (context, &in);
+
+ if (!match)
+ profile_check_deleg(context, server, &match);
+
+ if (!match)
+ {
+ retval = KRB5_TKT_NOT_FORWARDABLE_HERE;
+ goto errout;
+ }

- retval = krb5_copy_principal (context, server, &in.server);
- if (retval)
- goto punt;
- retval = krb5_copy_principal (context, client, &in.client);
- if (retval)
- goto punt;
- retval = krb5_get_credentials (context, 0, cc, &in, &out);
- if (retval)
- goto punt;
- /* Got the credentials. Okay, now record the enctype and
- throw them away. */
- enctype = out->keyblock.enctype;
- krb5_free_creds (context, out);
- punt:
- krb5_free_cred_contents (context, &in);
}

if ((retval = krb5_copy_principal(context, client, &creds.client)))
@@ -196,3 +237,166 @@
krb5_free_cred_contents(context, &tgt);
return retval;
}
+
+/* str_match
+ * matches a string against a pattern.
+ *
+ * pattern - pattern to match against
+ * str - string to match
+ *
+ * returns 1 if there is a match
+ * returns 0 if there is not a match
+ *
+ * Pattern can contain any number of
+ * asterisks as wild cards. Use backslash before a
+ * control character (asterisk and backslash) to
+ * use it's actual character value.
+ *
+ * The str value has no control characters.
+ */
+
+static int str_match(pattern, str)
+ const char *pattern;
+ const char *str;
+{
+ int special = 0;
+
+ /* was the function called correctly? */
+
+ if (!pattern || !str)
+ return 0;
+
+ /* a pattern ends with a non-escaped
+ * backslash this makes no sense
+ */
+ if (*pattern == '\\' && !*(pattern + 1))
+ return 0;
+
+ /* allow asterisks and backslash to be
+ * processed normally */
+
+ if (*pattern == '\\')
+ {
+ special = 1;
+ pattern++;
+ }
+
+ /* try every possible way that
+ * the wildcard character can
+ * eat the characters in the str */
+
+ if (*pattern == '*')
+ {
+ while (*str)
+ {
+ if (str_match(pattern+1, str))
+ return 1;
+
+ str++;
+ }
+
+ /* check to see if the wildcard
+ * matches of the end of string character */
+
+ return str_match(pattern+1, str);
+ }
+
+ /* the end of both strings was reached
+ * successfully */
+
+ if (!*pattern && !*str)
+ return 1;
+
+ /* the strings match so far ... */
+
+ if (*pattern == *str)
+ return (str_match(pattern+1, str+1));
+
+ /* the strings don't match */
+
+ return 0;
+}
+
+/* profile_check_deleg
+ *
+ * determines whether a service can
+ * delegate to particular service principal
+ * by checking the ok_to_delegate item
+ * in the configuration file.
+ *
+ * context - kerberos context
+ * server - server principal
+ * result - 1 (true) or 0 (false)
+ *
+ * returns error code
+ *
+ * There can be any number of ok_to_delegate
+ * items under a particular realm.
+ *
+ * See the str_match function to determine
+ * what is considered a match.
+ */
+
+static krb5_error_code
+profile_check_deleg(context, server, result)
+ const krb5_context context;
+ const krb5_principal server;
+ int * result;
+{
+
+ int len = 0;
+ void * data = NULL;
+ char * realm = NULL;
+ char * princ_name = NULL;
+ const char * names[4];
+ char ** values = NULL;
+ char ** item = NULL;
+ int retval = 0;
+
+ *result = 0;
+ retval = krb5_unparse_name(context, server, &princ_name);
+
+ if (retval)
+ return retval;
+
+ len = krb5_princ_realm(context, server)->length;
+ data = krb5_princ_realm(context, server)->data;
+
+ realm = malloc(len + 1);
+ strncpy(realm, data, len);
+
+ realm[len] = '\0';
+
+ names[0] = "realms";
+ names[1] = realm;
+ names[2] = DELEGATION_CONFIG;
+ names[3] = 0;
+
+ retval = profile_get_values(context->profile, names, &values);
+
+ if (retval)
+ goto cleanup;
+
+ item = values;
+
+ while(*item && !*result)
+ {
+ *result = str_match(*item, princ_name);
+
+ item++;
+ }
+
+cleanup:
+
+ if (realm)
+ free(realm);
+
+ if (princ_name)
+ free(princ_name);
+
+ if (values)
+ profile_free_list(values);
+
+ return retval;
+}
+
Date: Wed, 18 Jul 2007 12:55:49 -0400
From: Nalin Dahyabhai <nalin@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
On Wed, Jul 18, 2007 at 10:50:43AM -0400, Sam Hartman via RT wrote:
Show quoted text
> Here's the current Sandia patch. I'm sorry for sitting on this so
> long.

No worries.

Show quoted text
> My recommendation is that if possible you use the same flag and kadmin
> option that they do. I'm a bit confused by the client support. As
> far as I can tell the new function they add is static so I'm not sure
> how you'd ever use it.

Both patches toggle the same bit in the kdb entry, and as far as the
kadmin-specific changes go, the only real difference is the user-visible
strings. I'm not wedded to the values I used there.

But I think there's a meaningful difference in how the flag (which is
the same attribute bit in both versions) is used in the two patches.

If I'm reading it right, the Sandia patch appears to use the flag to
control whether or not the client library actually attempts to obtain a
forwardable TGT when the application calls krb5_fwd_tgt_creds(). That
doesn't match my reading of how the flag is expected to be used. FWIW,
I don't see a way to call the new static function with different flags,
either.

In the case I've been looking at (gss_init_sec_context() called with
GSS_C_DELEG_FLAG unset, but the realm admin wants credentials to be
delegated), I don't think we get as far as calling krb5_fwd_tgt_creds().

My reading of the spec is that if the flag is set in the credentials we
use for authenticating to a service, we should delegate credentials to
that service. For example, in krb5_gss_init_sec_context(), if the
credential which get_credentials() returns has the
TKT_FLG_OK_AS_DELEGATE bit set, we should force GSS_C_DELEG_FLAG to be
on. (For completeness, I guess similar changes would be desirable in
the telnet/rsh/rlogin clients, though I haven't looked at the sources
for those with this in mind.)

We could use some of the matching code in the patch to fine-tune that
behavior, but when I think about it some more, I can't come up with a
really good reason that I shouldn't just be trusting the KDC's (and by
extension the realm admin's) judgement.
Date: Wed, 18 Jul 2007 13:01:21 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
Download (untitled) / with headers
text/plain 3.2KiB


nalin@redhat.com via RT wrote:
Show quoted text
> On Wed, Jul 18, 2007 at 10:50:43AM -0400, Sam Hartman via RT wrote:
>> Here's the current Sandia patch. I'm sorry for sitting on this so
>> long.
>
> No worries.
>
>> My recommendation is that if possible you use the same flag and kadmin
>> option that they do. I'm a bit confused by the client support. As
>> far as I can tell the new function they add is static so I'm not sure
>> how you'd ever use it.
>
> Both patches toggle the same bit in the kdb entry, and as far as the
> kadmin-specific changes go, the only real difference is the user-visible
> strings. I'm not wedded to the values I used there.
>
> But I think there's a meaningful difference in how the flag (which is
> the same attribute bit in both versions) is used in the two patches.
>
> If I'm reading it right, the Sandia patch appears to use the flag to
> control whether or not the client library actually attempts to obtain a
> forwardable TGT when the application calls krb5_fwd_tgt_creds(). That
> doesn't match my reading of how the flag is expected to be used. FWIW,
> I don't see a way to call the new static function with different flags,
> either.
>
> In the case I've been looking at (gss_init_sec_context() called with
> GSS_C_DELEG_FLAG unset, but the realm admin wants credentials to be
> delegated), I don't think we get as far as calling krb5_fwd_tgt_creds().
>
> My reading of the spec is that if the flag is set in the credentials we
> use for authenticating to a service, we should delegate credentials to
> that service.

Thats not the way I read it. It is advisory information from the KDC
to the client. RFC 4120 section 2.8 says:
"The OK-AS-DELEGATE provides a way for the KDC to communicate local realm
policy to a client regarding whether an intermediate server is trusted
to accept such credentials."

It does not require the client to delegate! The Sandia mods are enforcing
a local policy that will only delegate if the KDC says the server is trusted,
and the client requests delagation, i.e. called krb5_fwd_tgt_creds() In effect
doing what Windows clients and AD do by default.

Even in Windows the "ksetup /SetRealmFlags <realm> Delegate" can be used
to tell the client assume the OK-AS-DELAGATE is always on. In effect
overriding the local client policy. I thing this only applies to non-AD
realms, as not all KDC have this feature, so this command can be used
until they do.


For example, in krb5_gss_init_sec_context(), if the
Show quoted text
> credential which get_credentials() returns has the
> TKT_FLG_OK_AS_DELEGATE bit set, we should force GSS_C_DELEG_FLAG to be
> on. (For completeness, I guess similar changes would be desirable in
> the telnet/rsh/rlogin clients, though I haven't looked at the sources
> for those with this in mind.)
>
> We could use some of the matching code in the patch to fine-tune that
> behavior, but when I think about it some more, I can't come up with a
> really good reason that I shouldn't just be trusting the KDC's (and by
> extension the realm admin's) judgement.
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
>

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Subject: RE: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Date: Wed, 18 Jul 2007 12:46:24 -0600
From: "Machin, Glenn D" <GMachin@sandia.gov>
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 4.5KiB
Show quoted text
> It does not require the client to delegate! The Sandia mods
> are enforcing a local policy that will only delegate if the
> KDC says the server is trusted, and the client requests
> delagation, i.e. called krb5_fwd_tgt_creds()

Doug is correct. We do have an override for those realms who cannot set
the OK-AS-DELEGATE flag in the service ticket. This is done through
the krb5.conf file, using the ok_to_delegate attribute, which set on a
per realm basis.

[realms]
REALM = {
ok_to_delegate = host/clustersystem*@REALM
}


Glenn





Show quoted text
> -----Original Message-----
> From: krb5-bugs-bounces@mit.edu
> [mailto:krb5-bugs-bounces@mit.edu] On Behalf Of
> DEEngert@anl.gov via RT
> Sent: Wednesday, July 18, 2007 12:02 PM
> Subject: Re: [krbdev.mit.edu #5596] patch for providing a way
> to set the ok-as-delegate flag
>
>
>
> nalin@redhat.com via RT wrote:
> > On Wed, Jul 18, 2007 at 10:50:43AM -0400, Sam Hartman via RT wrote:
> >> Here's the current Sandia patch. I'm sorry for sitting on this so
> >> long.
> >
> > No worries.
> >
> >> My recommendation is that if possible you use the same flag and
> >> kadmin option that they do. I'm a bit confused by the client
> >> support. As far as I can tell the new function they add
> is static so
> >> I'm not sure how you'd ever use it.
> >
> > Both patches toggle the same bit in the kdb entry, and as
> far as the
> > kadmin-specific changes go, the only real difference is the
> > user-visible strings. I'm not wedded to the values I used there.
> >
> > But I think there's a meaningful difference in how the flag
> (which is
> > the same attribute bit in both versions) is used in the two patches.
> >
> > If I'm reading it right, the Sandia patch appears to use
> the flag to
> > control whether or not the client library actually attempts
> to obtain
> > a forwardable TGT when the application calls krb5_fwd_tgt_creds().
> > That doesn't match my reading of how the flag is expected
> to be used.
> > FWIW, I don't see a way to call the new static function
> with different
> > flags, either.
> >
> > In the case I've been looking at (gss_init_sec_context()
> called with
> > GSS_C_DELEG_FLAG unset, but the realm admin wants credentials to be
> > delegated), I don't think we get as far as calling
> krb5_fwd_tgt_creds().
> >
> > My reading of the spec is that if the flag is set in the
> credentials
> > we use for authenticating to a service, we should delegate
> credentials
> > to that service.
>
> Thats not the way I read it. It is advisory information from
> the KDC to the client. RFC 4120 section 2.8 says:
> "The OK-AS-DELEGATE provides a way for the KDC to communicate
> local realm policy to a client regarding whether an
> intermediate server is trusted to accept such credentials."
>
> It does not require the client to delegate! The Sandia mods
> are enforcing a local policy that will only delegate if the
> KDC says the server is trusted, and the client requests
> delagation, i.e. called krb5_fwd_tgt_creds() In effect doing
> what Windows clients and AD do by default.
>
> Even in Windows the "ksetup /SetRealmFlags <realm> Delegate"
> can be used to tell the client assume the OK-AS-DELAGATE is
> always on. In effect overriding the local client policy. I
> thing this only applies to non-AD realms, as not all KDC have
> this feature, so this command can be used until they do.
>
>
> For example, in krb5_gss_init_sec_context(), if the
> > credential which get_credentials() returns has the
> > TKT_FLG_OK_AS_DELEGATE bit set, we should force
> GSS_C_DELEG_FLAG to be
> > on. (For completeness, I guess similar changes would be
> desirable in
> > the telnet/rsh/rlogin clients, though I haven't looked at
> the sources
> > for those with this in mind.)
> >
> > We could use some of the matching code in the patch to
> fine-tune that
> > behavior, but when I think about it some more, I can't come
> up with a
> > really good reason that I shouldn't just be trusting the
> KDC's (and by
> > extension the realm admin's) judgement.
> >
> > _______________________________________________
> > krb5-bugs mailing list
> > krb5-bugs@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/krb5-bugs
> >
> >
>
> --
>
> Douglas E. Engert <DEEngert@anl.gov>
> Argonne National Laboratory
> 9700 South Cass Avenue
> Argonne, Illinois 60439
> (630) 252-5444
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
>
Date: Wed, 18 Jul 2007 14:59:51 -0400
From: Nalin Dahyabhai <nalin@redhat.com>
To: "DEEngert@anl.gov via RT" <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
On Wed, Jul 18, 2007 at 02:01:31PM -0400, DEEngert@anl.gov via RT wrote:
Show quoted text
> It does not require the client to delegate! The Sandia mods are enforcing
> a local policy that will only delegate if the KDC says the server is trusted,
> and the client requests delagation, i.e. called krb5_fwd_tgt_creds() In effect
> doing what Windows clients and AD do by default.

Maybe I'm coming at this from the wrong direction. Is the intent to be
able to disallow credential delegation in cases when the application is
specifically requesting it?
Date: Wed, 18 Jul 2007 15:20:01 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.4KiB


nalin@redhat.com via RT wrote:
Show quoted text
> On Wed, Jul 18, 2007 at 02:01:31PM -0400, DEEngert@anl.gov via RT wrote:
>> It does not require the client to delegate! The Sandia mods are enforcing
>> a local policy that will only delegate if the KDC says the server is trusted,
>> and the client requests delagation, i.e. called krb5_fwd_tgt_creds() In effect
>> doing what Windows clients and AD do by default.
>
> Maybe I'm coming at this from the wrong direction. Is the intent to be
> able to disallow credential delegation in cases when the application is
> specifically requesting it?


The intent was to not allow users to setup rogue servers on their workstations
in order to entice other users to forward credentials so they can be misused.

In a Windows environment, the only windows servers are controlled by the AD
admins, such as CIFS and LDAP, and they set the OK_TO_DELEGATE bits on these
"trusted" servers. So the client will only delegate if the AD say it is OK.

There is a discussion going on in the mod_auth_kerb about OK_TO_DELEGATE
so the problem of rouge web servers obtaining credentials is a problem.
Java 1.7(?) will have some ok-to-delegate checks as well.

Unfortunately in a unix environment, many time you want to forward to a
workstation, like to get AFS tokens, or to run a ssh or scp and thus almost
any workstation could be considered a "server".


So it might depend on the application as to whether it should take the KDC's
advice. For example: SSH in the ssh_config with the Host sections containing
GSSAPIDelegateCredentials yes
could be considered as a "local policy" rule to ignore the OK_TO_DELEGATE

But with mod_auth_kerb and SPNEGO you always want check the OK_TO_DELEGATE
flag, you don't want users giving away credentials to the wrong servers.

So it is not obvious to me how to have GSSAPI decide if the OK_TO_DELEGATE
bit should be checked. Another GSS_ flag to gs_init_sec_context?
an option in the krb5.conf saying which service names should check it?
like:

check_ok_to_delegate = HTTP, LDAP; (but not host)

Meaning if the service is HTTP or LDAP only forward if the KDC says OK,
and the application requests delegation otherwise ignore the KDC's advice.





Show quoted text
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
>

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Date: Wed, 18 Jul 2007 15:24:52 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
Download (untitled) / with headers
text/plain 4.9KiB


Machin@mit.edu wrote:
Show quoted text
>> It does not require the client to delegate! The Sandia mods
>> are enforcing a local policy that will only delegate if the
>> KDC says the server is trusted, and the client requests
>> delagation, i.e. called krb5_fwd_tgt_creds()
>
> Doug is correct. We do have an override for those realms who cannot set
> the OK-AS-DELEGATE flag in the service ticket. This is done through
> the krb5.conf file, using the ok_to_delegate attribute, which set on a
> per realm basis.
>
> [realms]
> REALM = {
> ok_to_delegate = host/clustersystem*@REALM
> }
>

I like this better then the check_ok_to_delegate I proposed
in the last e-mail.

Show quoted text
>
> Glenn
>
>
>
>
>
>> -----Original Message-----
>> From: krb5-bugs-bounces@mit.edu
>> [mailto:krb5-bugs-bounces@mit.edu] On Behalf Of
>> DEEngert@anl.gov via RT
>> Sent: Wednesday, July 18, 2007 12:02 PM
>> Subject: Re: [krbdev.mit.edu #5596] patch for providing a way
>> to set the ok-as-delegate flag
>>
>>
>>
>> nalin@redhat.com via RT wrote:
>>> On Wed, Jul 18, 2007 at 10:50:43AM -0400, Sam Hartman via RT wrote:
>>>> Here's the current Sandia patch. I'm sorry for sitting on this so
>>>> long.
>>> No worries.
>>>
>>>> My recommendation is that if possible you use the same flag and
>>>> kadmin option that they do. I'm a bit confused by the client
>>>> support. As far as I can tell the new function they add
>> is static so
>>>> I'm not sure how you'd ever use it.
>>> Both patches toggle the same bit in the kdb entry, and as
>> far as the
>>> kadmin-specific changes go, the only real difference is the
>>> user-visible strings. I'm not wedded to the values I used there.
>>>
>>> But I think there's a meaningful difference in how the flag
>> (which is
>>> the same attribute bit in both versions) is used in the two patches.
>>>
>>> If I'm reading it right, the Sandia patch appears to use
>> the flag to
>>> control whether or not the client library actually attempts
>> to obtain
>>> a forwardable TGT when the application calls krb5_fwd_tgt_creds().
>>> That doesn't match my reading of how the flag is expected
>> to be used.
>>> FWIW, I don't see a way to call the new static function
>> with different
>>> flags, either.
>>>
>>> In the case I've been looking at (gss_init_sec_context()
>> called with
>>> GSS_C_DELEG_FLAG unset, but the realm admin wants credentials to be
>>> delegated), I don't think we get as far as calling
>> krb5_fwd_tgt_creds().
>>> My reading of the spec is that if the flag is set in the
>> credentials
>>> we use for authenticating to a service, we should delegate
>> credentials
>>> to that service.
>> Thats not the way I read it. It is advisory information from
>> the KDC to the client. RFC 4120 section 2.8 says:
>> "The OK-AS-DELEGATE provides a way for the KDC to communicate
>> local realm policy to a client regarding whether an
>> intermediate server is trusted to accept such credentials."
>>
>> It does not require the client to delegate! The Sandia mods
>> are enforcing a local policy that will only delegate if the
>> KDC says the server is trusted, and the client requests
>> delagation, i.e. called krb5_fwd_tgt_creds() In effect doing
>> what Windows clients and AD do by default.
>>
>> Even in Windows the "ksetup /SetRealmFlags <realm> Delegate"
>> can be used to tell the client assume the OK-AS-DELAGATE is
>> always on. In effect overriding the local client policy. I
>> thing this only applies to non-AD realms, as not all KDC have
>> this feature, so this command can be used until they do.
>>
>>
>> For example, in krb5_gss_init_sec_context(), if the
>>> credential which get_credentials() returns has the
>>> TKT_FLG_OK_AS_DELEGATE bit set, we should force
>> GSS_C_DELEG_FLAG to be
>>> on. (For completeness, I guess similar changes would be
>> desirable in
>>> the telnet/rsh/rlogin clients, though I haven't looked at
>> the sources
>>> for those with this in mind.)
>>>
>>> We could use some of the matching code in the patch to
>> fine-tune that
>>> behavior, but when I think about it some more, I can't come
>> up with a
>>> really good reason that I shouldn't just be trusting the
>> KDC's (and by
>>> extension the realm admin's) judgement.
>>>
>>> _______________________________________________
>>> krb5-bugs mailing list
>>> krb5-bugs@mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>>>
>>>
>> --
>>
>> Douglas E. Engert <DEEngert@anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>>
>> _______________________________________________
>> krb5-bugs mailing list
>> krb5-bugs@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>>
>>
>
>
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>
>

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Date: Wed, 18 Jul 2007 17:13:02 -0400
RT-Send-Cc:
OUr position is that changing current behavior is inappropriate.
However we'd like to add a new behavior that says "only delegate if
the flag is set on the ticket."
From: Sam Hartman <hartmans@mit.edu>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
Date: Wed, 18 Jul 2007 17:18:57 -0400
RT-Send-Cc:
I think it would be inappropriate to change the behavior for existing
applications with regard to the ok-as-delegate flag.

Allowing the realm to override and prevent delegation would violate
the software engineering principle of designing for your user.


However adding a new mechanism in the krb5 library and in the GSS-API
so that an application can say "Please delegate if the local realm
thinks it is a good idea," is a reasonable goal. It would require a
new GSS flag and new APIs at the krb5 layer.
Date: Wed, 18 Jul 2007 16:57:44 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
On Wed, Jul 18, 2007 at 05:13:08PM -0400, Sam Hartman via RT wrote:
Show quoted text
> OUr position is that changing current behavior is inappropriate.
> However we'd like to add a new behavior that says "only delegate if
> the flag is set on the ticket."

I agree with this. But note that it effectively means additional
client-side knobs for telnet, ftp, rlogin, rsh, ssh, etcetera, and/or in
krb5.conf. Painful.

Nico
--
I've been handed this ticket.

The client side behavior will be handled using GSS_C_DELEG_POLICY_FLAG
as specified in
http://tools.ietf.org/html/draft-lha-gssapi-delegate-policy-04 . Code
from Apple has already been committed to handle the flag, and I am
working on the cross-realm handling now. I don't yet have specific
plans to use the flag in any client program.

That leaves the KDC support. Sam wanted us to use the same user-visible
flag name as the Sandia patch, but I honestly think it will be less
confusing if we remain consistent with the RFC (ok-as-delegate) than if
we use the redundant-seeming "allow-ok-as-delegate" name. What do the
people from Sandia think? Will it be particularly traumatic to switch
to a different name for setting the flag in kadmin?
During the time this patch has waited, Luke's work added KDC support for
OK_AS_DELEGATE (but no kadmin support for setting the flag).
Unfortunately, he used a value of 0x00100000 (five zeros after the 1)
while both Red Hat's and Sandia's patch used 0x00010000 (four zeros
after the 1). I am guessing Luke's chosen value came from Novell. This
presents a big transition issue for anyone using Red Hat's or Sandia's
code in production.
Date: Wed, 22 Apr 2009 14:39:13 -0400
From: Nalin Dahyabhai <nalin@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5596] patch for providing a way to set the ok-as-delegate flag
RT-Send-Cc:
On Wed, Apr 22, 2009 at 06:12:00PM +0000, Greg Hudson via RT wrote:
Show quoted text
> During the time this patch has waited, Luke's work added KDC support for
> OK_AS_DELEGATE (but no kadmin support for setting the flag).
> Unfortunately, he used a value of 0x00100000 (five zeros after the 1)
> while both Red Hat's and Sandia's patch used 0x00010000 (four zeros
> after the 1). I am guessing Luke's chosen value came from Novell. This
> presents a big transition issue for anyone using Red Hat's or Sandia's
> code in production.

We haven't shipped anything with this patch applied, so there shouldn't
be an issue on our end.

Cheers,

Nalin
From: ghudson@mit.edu
Subject: SVN Commit

Move KRB5_KDB_OK_AS_DELEGATE from kdb_ext.h to kdb.h. Add kadmin
support for the flag. In the KDC, remove the restriction on returning
the flag on cross-realm TGTs since there is now a defined meaning for
that (it allows ok-as-delegate to be honored on the foreign realm's
service tickets).


https://github.com/krb5/krb5/commit/55d0fcac60b575123e997abf583bc8cd501e8fae
Commit By: ghudson
Revision: 22281
Changed Files:
U trunk/src/include/kdb.h
U trunk/src/include/kdb_ext.h
U trunk/src/kadmin/cli/kadmin.M
U trunk/src/kadmin/cli/kadmin.c
U trunk/src/kdc/do_tgs_req.c
U trunk/src/lib/kadm5/str_conv.c
From: tlyu@mit.edu
Subject: SVN Commit

pull up r22281 from trunk
------------------------------------------------------------------------
r22281 | ghudson | 2009-04-27 11:42:23 -0400 (Mon, 27 Apr 2009) | 8 lines
Changed paths:
M /trunk/src/include/kdb.h
M /trunk/src/include/kdb_ext.h
M /trunk/src/kadmin/cli/kadmin.M
M /trunk/src/kadmin/cli/kadmin.c
M /trunk/src/kdc/do_tgs_req.c
M /trunk/src/lib/kadm5/str_conv.c

ticket: 5596

Move KRB5_KDB_OK_AS_DELEGATE from kdb_ext.h to kdb.h. Add kadmin
support for the flag. In the KDC, remove the restriction on returning
the flag on cross-realm TGTs since there is now a defined meaning for
that (it allows ok-as-delegate to be honored on the foreign realm's
service tickets).

https://github.com/krb5/krb5/commit/3a78a891b671fc2e7f2848b6944e5a0a9e54320f
Commit By: tlyu
Revision: 22330
Changed Files:
U branches/krb5-1-7/src/include/kdb.h
U branches/krb5-1-7/src/include/kdb_ext.h
U branches/krb5-1-7/src/kadmin/cli/kadmin.M
U branches/krb5-1-7/src/kadmin/cli/kadmin.c
U branches/krb5-1-7/src/kdc/do_tgs_req.c
U branches/krb5-1-7/src/lib/kadm5/str_conv.c