Skip Menu |
 

To: krb5-bugs@mit.edu
Subject: MIT KDC fails to handle unknown padata
Date: Fri, 9 Jan 2004 17:28:15 -0500 (EST)
From: hartmans@MIT.EDU (Sam Hartman)


If you send pdata in a request and the MIT KDC doesn't understand any
of the padata types at all then it returns failure. It should only
return failure in this case if the principal requires preatuh. Thanks
to Doug for discovering this.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Tom Yu <tlyu@mit.edu>
Date: Sun, 01 Feb 2004 20:04:30 -0500
RT-Send-Cc:
kdc_preauth.c on the 1.3 branch has the following, which should
prevent the problem.

/* pa system was not found, but principal doesn't require preauth */
if (!pa_found &&
!isflagset(client->attributes, KRB5_KDB_REQUIRES_PRE_AUTH) &&
!isflagset(client->attributes, KRB5_KDB_REQUIRES_HW_AUTH))
return 0;

The code has been there since 1999. Is this a case of the request
containing preauth the that fails to verify, rather than being a case
of preauth being submitted that the KDC does not understand?

---Tom
To: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Sam Hartman <hartmans@mit.edu>
Date: Mon, 02 Feb 2004 09:26:01 -0500
RT-Send-Cc:
No, it sounds like a case of me failing to find this when I checked to
see if the bug still exists. Let's ask Doug to try and reproduce
against 1.3.
Date: Mon, 02 Feb 2004 14:30:09 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:


Sam Hartman via RT wrote:
Show quoted text
>
> No, it sounds like a case of me failing to find this when I checked to
> see if the bug still exists. Let's ask Doug to try and reproduce
> against 1.3.

I don't have a 1.3 KDC so it would take awhile. I am headed to the
ISOC NDISS meeitng on Wednesday. I could look at testing this
next week.


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
To: "Douglas E. Engert" <deengert@anl.gov>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Tom Yu <tlyu@mit.edu>
Date: Mon, 09 Feb 2004 22:01:25 -0500
RT-Send-Cc:
Show quoted text
>>>>> "deengert" == Douglas E Engert <deengert@anl.gov> writes:

Show quoted text
deengert> I don't have a 1.3 KDC so it would take awhile. I am headed
deengert> to the ISOC NDISS meeitng on Wednesday. I could look at
deengert> testing this next week.

Ok, I've looked at the 1.2 release branch; the relevant code was in
place prior to the 1.2 branch cut, so should be in all 1.2.x releases.
For that matter, the code should be in all 1.1.x releaes. Which
release was KDC were you having the trouble with?

---Tom
Date: Tue, 10 Feb 2004 07:53:08 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: Tom Yu <tlyu@mit.edu>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:


Tom Yu wrote:
Show quoted text
>
> >>>>> "deengert" == Douglas E Engert <deengert@anl.gov> writes:
>
> deengert> I don't have a 1.3 KDC so it would take awhile. I am headed
> deengert> to the ISOC NDISS meeitng on Wednesday. I could look at
> deengert> testing this next week.
>
> Ok, I've looked at the 1.2 release branch; the relevant code was in
> place prior to the 1.2 branch cut, so should be in all 1.2.x releases.
> For that matter, the code should be in all 1.1.x releaes. Which
> release was KDC were you having the trouble with?

1.2.8 I will check today when I get to work.


Show quoted text
>
> ---Tom

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Date: Tue, 10 Feb 2004 07:54:36 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: Tom Yu <tlyu@mit.edu>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:


Tom Yu wrote:
Show quoted text
>
> >>>>> "deengert" == Douglas E Engert <deengert@anl.gov> writes:
>
> deengert> I don't have a 1.3 KDC so it would take awhile. I am headed
> deengert> to the ISOC NDISS meeitng on Wednesday. I could look at
> deengert> testing this next week.
>
> Ok, I've looked at the 1.2 release branch; the relevant code was in
> place prior to the 1.2 branch cut, so should be in all 1.2.x releases.
> For that matter, the code should be in all 1.1.x releaes. Which
> release was KDC were you having the trouble with?
>


Wait a minute. If the code was in the KDC, and it failed, then
it would still failed. I will look at the problem when I get to
work.

Show quoted text
> ---Tom

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Date: Tue, 10 Feb 2004 17:04:24 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: Sam Hartman <hartmans@mit.edu>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:
Sam,
Attached are the mods to 1.3.2 to try the PA_PAC_REQUEST in the AS-REQ
I ported the changes to 1.3.2 from 1.3.1 but never tried them.

There are changes in
kinit.c
krb5.hin
gic_opt.c
get_in_tkt.c

They are controlled by #ifdef NOMSPAC

Note that the kinit.c also has some change for getting a password from stdin.


You can also find these in AFS at /afs/anl.gov/usr/ctd/b17783/pub/NOMSPAC.diff



--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Download NOMSPAC.diff
text/plain 7.1KiB
--- ./clients/kinit/,kinit.c Tue Feb 3 10:35:37 2004
+++ ./clients/kinit/kinit.c Tue Feb 3 10:35:37 2004
@@ -127,6 +127,7 @@
int forwardable;
int proxiable;
int addresses;
+ int pstdin;

int not_forwardable;
int not_proxiable;
@@ -141,6 +142,9 @@
char* k4_cache_name;

action_type action;
+#ifdef NOMSPAC
+ int nomspac;
+#endif
};

struct k5_data
@@ -211,10 +215,12 @@
USAGE_BREAK_LONG
"[-A" USAGE_LONG_ADDRESSES "] "
USAGE_BREAK
+ "[-m] "
"[-v] [-R] "
"[-k [-t keytab_file]] "
USAGE_BREAK
"[-c cachename] "
+ "[-Z] "
"[-S service_name] [principal]"
"\n\n",
progname);
@@ -257,10 +263,14 @@
ULINE("\t", "-p proxiable", OPTTYPE_KRB5);
ULINE("\t", "-P not proxiable", OPTTYPE_KRB5);
ULINE("\t", "-A do not include addresses", OPTTYPE_KRB5);
+#ifdef NOMSPAC
+ ULINE("\t", "-m No PAC in ticket", OPTTYPE_KRB5);
+#endif
ULINE("\t", "-v validate", OPTTYPE_KRB5);
ULINE("\t", "-R renew", OPTTYPE_BOTH);
ULINE("\t", "-k use keytab", OPTTYPE_BOTH);
ULINE("\t", "-t filename of keytab to use", OPTTYPE_BOTH);
+ ULINE("\t", "-Z get password from stdin", OPTTYPE_KRB5);
ULINE("\t", "-c Kerberos 5 cache name", OPTTYPE_KRB5);
/* This options is not yet available: */
/* ULINE("\t", "-C Kerberos 4 cache name", OPTTYPE_KRB4); */
@@ -281,9 +291,14 @@
int use_k5 = 0;
int i;

- while ((i = GETOPT(argc, argv, "r:fpFP54AVl:s:c:kt:RS:v"))
+ while ((i = GETOPT(argc, argv, "r:fpFP54AVl:s:c:kt:RS:vZm"))
!= -1) {
switch (i) {
+#ifdef NOMSPAC
+ case 'm':
+ opts->nomspac = 1;
+ break;
+#endif
case 'V':
opts->verbose = 1;
break;
@@ -401,6 +416,9 @@
}
use_k5 = 1;
break;
+ case 'Z':
+ opts->pstdin++;
+ break;
default:
errflg++;
break;
@@ -737,6 +755,8 @@
krb5_creds my_creds;
krb5_error_code code = 0;
krb5_get_init_creds_opt options;
+ char pstdin_pw[1024];
+ int pstdin_pw_size = 0;

if (!got_k5)
return 0;
@@ -749,6 +769,10 @@
initialized.
*/

+#ifdef NOMSPAC
+ if (opts->nomspac)
+ krb5_get_init_creds_opt_set_pa_pac_request(&options);
+#endif
if (opts->lifetime)
krb5_get_init_creds_opt_set_tkt_life(&options, opts->lifetime);
if (opts->rlife)
@@ -787,8 +811,21 @@

switch (opts->action) {
case INIT_PW:
+ if (opts->pstdin) {
+ pstdin_pw_size = read(0,pstdin_pw,sizeof(pstdin_pw)-1);
+ if (pstdin_pw_size > 0) {
+ if (pstdin_pw[pstdin_pw_size-1] == '\n') {
+ pstdin_pw_size--;
+ }
+ pstdin_pw[pstdin_pw_size] = '\0';
+ } else {
+ pstdin_pw_size = 0;
+ }
+ }
+
code = krb5_get_init_creds_password(k5->ctx, &my_creds, k5->me,
- 0, kinit_prompter, 0,
+ (pstdin_pw_size > 0)? pstdin_pw: 0,
+ kinit_prompter, 0,
opts->starttime,
opts->service_name,
&options);
--- ./include/,krb5.hin Tue Feb 3 10:38:08 2004
+++ ./include/krb5.hin Tue Feb 3 10:38:09 2004
@@ -876,6 +876,9 @@
#define KRB5_PADATA_SAM_CHALLENGE_2 30 /* draft challenge system, updated */
#define KRB5_PADATA_SAM_RESPONSE_2 31 /* draft challenge system, updated */

+#ifdef NOMSPAC
+#define KRB5_PADATA_PAC_REQUEST 128
+#endif
#define KRB5_SAM_USE_SAD_AS_KEY 0x80000000
#define KRB5_SAM_SEND_ENCRYPTED_SAD 0x40000000
#define KRB5_SAM_MUST_PK_ENCRYPT_SAD 0x20000000 /* currently must be zero */
@@ -2415,6 +2418,9 @@
#define KRB5_GET_INIT_CREDS_OPT_ADDRESS_LIST 0x0020
#define KRB5_GET_INIT_CREDS_OPT_PREAUTH_LIST 0x0040
#define KRB5_GET_INIT_CREDS_OPT_SALT 0x0080
+#ifdef NOMSPAC
+#define KRB5_GET_INIT_CREDS_OPT_PA_PAC_REQUEST 0x0100
+#endif


void KRB5_CALLCONV
@@ -2462,6 +2468,13 @@
krb5_get_init_creds_opt_set_salt
(krb5_get_init_creds_opt *opt,
krb5_data *salt);
+
+#ifdef NOMSPAC
+void KRB5_CALLCONV
+krb5_get_init_creds_opt_set_pa_pac_request
+(krb5_get_init_creds_opt *opt);
+#endif
+

krb5_error_code KRB5_CALLCONV
krb5_get_init_creds_password
--- ./lib/krb5/krb/,gic_opt.c Tue Feb 3 11:02:10 2004
+++ ./lib/krb5/krb/gic_opt.c Tue Feb 3 11:02:10 2004
@@ -63,3 +63,11 @@
opt->flags |= KRB5_GET_INIT_CREDS_OPT_SALT;
opt->salt = salt;
}
+
+#ifdef NOMSPAC
+void KRB5_CALLCONV
+krb5_get_init_creds_opt_set_pa_pac_request(krb5_get_init_creds_opt *opt)
+{
+ opt->flags |= KRB5_GET_INIT_CREDS_OPT_PA_PAC_REQUEST;
+}
+#endif
--- ./lib/krb5/krb/,get_in_tkt.c Tue Feb 3 11:02:25 2004
+++ ./lib/krb5/krb/get_in_tkt.c Tue Feb 3 11:02:26 2004
@@ -78,6 +78,70 @@
static krb5_error_code make_preauth_list (krb5_context,
krb5_preauthtype *,
int, krb5_pa_data ***);
+#ifdef NOMSPAC
+ /* Add the Microsoft PA_PAC_REQUEST to the AS
+ * request. Since this needs to be sent on each AS_REQ
+ * the krb5_preauth routines can not be used, as they
+ * add a list the first time, but then only respond to the
+ * pa-data in the error response.
+ * See draft-brezak-win2k-krb-authz-01.txt section 6
+ * Also see MSDN for SEC_WINNT_AUTH_IDENTITY_ONLY
+ */
+static krb5_error_code add_ms_pac_req(krb5_context context,
+ krb5_pa_data *** padata)
+{
+ int i;
+ /* ASN1 for:
+ * KERB-PA-PAC-REQUEST ::= SEQUENCE {
+ * include-pac[0] BOOLEAN
+ * }
+ * where the value is false
+ */
+ static krb5_octet booldata[] = {"\x30\x05\xa0\x03\x01\x01\x00"};
+ void * tmp;
+ krb5_pa_data * pa;
+ krb5_pa_data * * new_padata;
+
+ if ((tmp = (void *)malloc(sizeof(booldata)-1)) == NULL)
+ return(ENOMEM);
+ memcpy(tmp, booldata, sizeof(booldata)-1);
+
+ if ((pa = (krb5_pa_data *)malloc(sizeof(krb5_pa_data))) == NULL) {
+ krb5_xfree(tmp);
+ return(ENOMEM);
+ }
+
+ pa->magic = KV5M_PA_DATA;
+ pa->pa_type = KRB5_PADATA_PAC_REQUEST;
+ pa->length = sizeof(booldata)-1;
+ pa->contents = tmp;
+
+ if (*padata == NULL) {
+ new_padata = (krb5_pa_data **)
+ malloc(2 * sizeof(krb5_pa_data *));
+ i = 0;
+ } else {
+ for (i=0; (*padata)[i]; i++); /* count */
+
+ new_padata = *padata;
+ new_padata = (krb5_pa_data **)
+ realloc(new_padata, (i+2) * sizeof(krb5_pa_data *));
+ }
+ if (new_padata == NULL) {
+ krb5_xfree(pa->contents);
+ krb5_xfree(pa);
+ return(ENOMEM);
+ }
+
+ new_padata[i++] = pa;
+ new_padata[i] = NULL;
+
+ *padata = new_padata;
+
+ return(0);
+}
+#endif
+
/*
* This function sends a request to the KDC, and gets back a response;
* the response is parsed into ret_err_reply or ret_as_reply if the
@@ -951,6 +1015,15 @@
prompter_data, gak_fct, gak_data)))
goto cleanup;

+#ifdef NOMSPAC
+ if (options && (options->flags &
+ KRB5_GET_INIT_CREDS_OPT_PA_PAC_REQUEST)) {
+ if (ret = add_ms_pac_req(context, &request.padata)) {
+ goto cleanup;
+ }
+ }
+#endif
+
if (padata) {
krb5_free_pa_data(context, padata);
padata = 0;
@@ -996,6 +1069,14 @@
&salt, &s2kparams, &etype, &as_key, prompter,
prompter_data, gak_fct, gak_data)))
goto cleanup;
+#ifdef NOMSPAC
+ if (options && (options->flags &
+ KRB5_GET_INIT_CREDS_OPT_PA_PAC_REQUEST)) {
+ if (ret = add_ms_pac_req(context, &padata)) {
+ goto cleanup;
+ }
+ }
+#endif

/* XXX if there's padata on output, something is wrong, but it's
not obviously an error */
To: rt@krbdev.mit.edu
Subject: [krbdev.mit.edu #2110] Cannot reproduce
Date: Tue, 10 Feb 2004 21:04:30 -0500 (EST)
From: hartmans@mit.edu (Sam Hartman)
RT-Send-Cc:


I was able to reproduce against 1.0.7, but not against 1.2.0, 1.2.8 or
1.3.1.

As such I don't think we consider this a blocker for 1.3.2.

I believe I used the same patches as Doug to try and reproduce.

--Sam
To: "Douglas E. Engert" <deengert@anl.gov>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Sam Hartman <hartmans@mit.edu>
Date: Tue, 10 Feb 2004 21:06:56 -0500
RT-Send-Cc:
Hi, Doug. I applied your patches and they seemed to work.

However I was unable to reproduce the error you got against a 1.2.x or
1.3.x KDC. I was able to reproduce this problem against a 1.0.7 KDC.
Date: Wed, 11 Feb 2004 09:23:46 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: Sam Hartman <hartmans@mit.edu>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:


Sam Hartman wrote:
Show quoted text
>
> Hi, Doug. I applied your patches and they seemed to work.
>
> However I was unable to reproduce the error you got against a 1.2.x or
> 1.3.x KDC. I was able to reproduce this problem against a 1.0.7 KDC.


OK. Since I can't get Microsoft code does to send a PA-PAC-REQUEST to a
non-MS KDC and the code patch to let MIT kinit send a PA-PAC-REQUEST
will not be needed once Todd gets the hotfix for the AD finished it is
very unlikely the problem will show up.

But I will see if I can do some additional testing when 1.3.2 comes out.


--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
To: "Douglas E. Engert" <deengert@anl.gov>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Sam Hartman <hartmans@mit.edu>
Date: Wed, 11 Feb 2004 11:28:46 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Douglas" == Douglas E Engert <deengert@anl.gov> writes:

Show quoted text
Douglas> Sam Hartman wrote:
Show quoted text
>> Hi, Doug. I applied your patches and they seemed to work.
>>
>> However I was unable to reproduce the error you got against a
>> 1.2.x or 1.3.x KDC. I was able to reproduce this problem
>> against a 1.0.7 KDC.


Show quoted text
Douglas> OK. Since I can't get Microsoft code does to send a
Douglas> PA-PAC-REQUEST to a non-MS KDC and the code patch to let
Douglas> MIT kinit send a PA-PAC-REQUEST will not be needed once
Douglas> Todd gets the hotfix for the AD finished it is very
Douglas> unlikely the problem will show up.

Consider how extensions works. If this problem actually happens it
will be a critical problem for MIT trying to implement extensions.
Date: Wed, 11 Feb 2004 15:39:33 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: Sam Hartman <hartmans@mit.edu>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:



Sam Hartman wrote:
Show quoted text
>
> Hi, Doug. I applied your patches and they seemed to work.
>
> However I was unable to reproduce the error you got against a 1.2.x or
> 1.3.x KDC. I was able to reproduce this problem against a 1.0.7 KDC.

Using a modified 1.3.2 kinit:

kinit -m b17783@KRB5.ANL.GOV

to a 1.2.8 KDC, I can get it to fail if the user principal has
the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works.

Have you tried this combination?

kinit output:

orleans.ctd.anl.gov% kinit -m b17783@KRB5.ANL.GOV
kinit(v5): Preauthentication failed while getting initial credentials


KDC log:

Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0
Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783@KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV@KRB5.ANL.GOV, Preauthentication failed



--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 11 Feb 2004 16:47:34 -0500
RT-Send-Cc:
Show quoted text
>>>>> "DEEngert" == DEEngert@anl gov via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
DEEngert> to a 1.2.8 KDC, I can get it to fail if the user principal has
DEEngert> the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works.

Show quoted text
DEEngert> Have you tried this combination?

Show quoted text
DEEngert> kinit output:

Show quoted text
DEEngert> orleans.ctd.anl.gov% kinit -m b17783@KRB5.ANL.GOV
DEEngert> kinit(v5): Preauthentication failed while getting initial credentials


Show quoted text
DEEngert> KDC log:

Show quoted text
DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0
DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783@KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV@KRB5.ANL.GOV, Preauthentication failed

I think the code is functioning as I expect it to, in this case.
After all, you require preauth, and you didn't provide any preauth
that it understood. Or are you saying that it should ask for
additional preauth rather than returning "preauth failed"?

---Tom
Date: Wed, 11 Feb 2004 17:30:34 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt-comment@krbdev.mit.edu
Cc: hartmans@mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.8KiB


Tom Yu via RT wrote:
Show quoted text
>
> >>>>> "DEEngert" == DEEngert@anl gov via RT <rt-comment@krbdev.mit.edu> writes:
>
> DEEngert> to a 1.2.8 KDC, I can get it to fail if the user principal has
> DEEngert> the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works.
>
> DEEngert> Have you tried this combination?
>
> DEEngert> kinit output:
>
> DEEngert> orleans.ctd.anl.gov% kinit -m b17783@KRB5.ANL.GOV
> DEEngert> kinit(v5): Preauthentication failed while getting initial credentials
>
> DEEngert> KDC log:
>
> DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0
> DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783@KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV@KRB5.ANL.GOV, Preauthentication failed
>
> I think the code is functioning as I expect it to, in this case.

No.

Show quoted text
> After all, you require preauth, and you didn't provide any preauth
> that it understood. Or are you saying that it should ask for
> additional preauth rather than returning "preauth failed"?

Yes, on the first AS-REQ the client does not know what preauth if any
is required. So it justs sends the PA-PAC-REQUEST. It has to do this on
the first request, as preauth may not be needed.

If preauth is not required the KDC ignores the PA-PAC-REQUEST and it works.

If preauth is required, a krb-error SHOULD be sent saying which preauths can be used.

I thing the KDC code sees some preauth data, (PA-PAC-REQEUST) but not any it
can use, and assumes that this must be a second AS-REQ request and it assumes it
has already sent the client a krb-error with the list of preauths.

So the KDC sends the failed message, and never sends the list or required preauths.


Show quoted text
>
> ---Tom

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 11 Feb 2004 19:02:52 -0500
RT-Send-Cc:
Show quoted text
>>>>> "DEEngert" == DEEngert@anl gov via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
DEEngert> Tom Yu via RT wrote:

Show quoted text
>> I think the code is functioning as I expect it to, in this case.

Show quoted text
DEEngert> No.

Let me rephrase: I think the code is functioning the way it was
intended to function when it was written. Whether that behavior is
correct in this case is debatable.

Show quoted text
>> After all, you require preauth, and you didn't provide any preauth
>> that it understood. Or are you saying that it should ask for
>> additional preauth rather than returning "preauth failed"?

Show quoted text
DEEngert> Yes, on the first AS-REQ the client does not know what
DEEngert> preauth if any is required. So it justs sends the
DEEngert> PA-PAC-REQUEST. It has to do this on the first request, as
DEEngert> preauth may not be needed.

Show quoted text
DEEngert> If preauth is not required the KDC ignores the
DEEngert> PA-PAC-REQUEST and it works.

Show quoted text
DEEngert> If preauth is required, a krb-error SHOULD be sent saying
DEEngert> which preauths can be used.

Show quoted text
DEEngert> I thing the KDC code sees some preauth data,
DEEngert> (PA-PAC-REQEUST) but not any it can use, and assumes that
DEEngert> this must be a second AS-REQ request and it assumes it has
DEEngert> already sent the client a krb-error with the list of
DEEngert> preauths.

This would appear to be the intent. The problem is, if the KDC sees
any AS-REQ containing padata, the most safe assumption to make is that
it is a "second" AS-REQ, i.e., one replying to a KRB-ERROR asking for
additional preauth.

Consider what happens when a client sends an AS-REQ containing padata
that the KDC do not understand. KDC sends KRB-ERROR with list of
supported padata. Client is broken in a way that causes it to send
a mostly identical AS-REQ, lacking the padata that the KDC require.
KDC again sends KRB-ERROR with list of supported padata. Looping
ensues. The main problem being that KRB-ERROR requesting additional
preauth isn't a hard failure, and the other errors are.

I'm not sure of the best way to get around this problem, without
somehow requiring the KDC to keep some state which it currently does
not.

---Tom
To: "Douglas E. Engert" <deengert@anl.gov>
Cc: rt-comment@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
From: Sam Hartman <hartmans@mit.edu>
Date: Wed, 11 Feb 2004 19:41:50 -0500
RT-Send-Cc:
Show quoted text
>>>>> "Douglas" == Douglas E Engert <deengert@anl.gov> writes:


Show quoted text
Douglas> If preauth is required, a krb-error SHOULD be sent saying
Douglas> which preauths can be used.

That's not how Kerberos works. Se section 2 of
draft-ietf-krb-wg-preauth-framework-00.txt for a discussion.
Date: Wed, 11 Feb 2004 19:29:59 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
To: rt-comment@krbdev.mit.edu
Cc: hartmans@mit.edu, krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.7KiB


Tom Yu via RT wrote:
Show quoted text
>
> >>>>> "DEEngert" == DEEngert@anl gov via RT <rt-comment@krbdev.mit.edu> writes:
>
> DEEngert> Tom Yu via RT wrote:
>
> >> I think the code is functioning as I expect it to, in this case.
>
> DEEngert> No.
>
> Let me rephrase: I think the code is functioning the way it was
> intended to function when it was written. Whether that behavior is
> correct in this case is debatable.

OK, I agree with that.

Show quoted text
>
> >> After all, you require preauth, and you didn't provide any preauth
> >> that it understood. Or are you saying that it should ask for
> >> additional preauth rather than returning "preauth failed"?
>
> DEEngert> Yes, on the first AS-REQ the client does not know what
> DEEngert> preauth if any is required. So it justs sends the
> DEEngert> PA-PAC-REQUEST. It has to do this on the first request, as
> DEEngert> preauth may not be needed.
>
> DEEngert> If preauth is not required the KDC ignores the
> DEEngert> PA-PAC-REQUEST and it works.
>
> DEEngert> If preauth is required, a krb-error SHOULD be sent saying
> DEEngert> which preauths can be used.
>
> DEEngert> I thing the KDC code sees some preauth data,
> DEEngert> (PA-PAC-REQEUST) but not any it can use, and assumes that
> DEEngert> this must be a second AS-REQ request and it assumes it has
> DEEngert> already sent the client a krb-error with the list of
> DEEngert> preauths.
>
> This would appear to be the intent. The problem is, if the KDC sees
> any AS-REQ containing padata, the most safe assumption to make is that
> it is a "second" AS-REQ, i.e., one replying to a KRB-ERROR asking for
> additional preauth.
>
> Consider what happens when a client sends an AS-REQ containing padata
> that the KDC do not understand. KDC sends KRB-ERROR with list of
> supported padata. Client is broken in a way that causes it to send
> a mostly identical AS-REQ, lacking the padata that the KDC require.
> KDC again sends KRB-ERROR with list of supported padata. Looping
> ensues. The main problem being that KRB-ERROR requesting additional
> preauth isn't a hard failure, and the other errors are.
>
> I'm not sure of the best way to get around this problem, without
> somehow requiring the KDC to keep some state which it currently does
> not.

The difference is that the PA-PAC-REQUEST is really a flag, not a preauth.

So maybe the KDC needs to recognize flag type entries (there may be others)
and not make the assumption that this is a second AS-REQ. But this requires
knowledge of all the possible pa-data types or at least the flag types.

Is this an issue for Sam's draft-ietf-krb-wg-preauth-framework-00.txt?


Show quoted text
>
> ---Tom

--

Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444