[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkinit as_rep
OK, I will send an answer to the list as well.
Matthew N. Andrews wrote:
> Ok, after remembering that gcc defaults to -O2 I was able to get a -O0
> build, and see what's going on.
>
> if I look at the authentication exchange with ethereal, I see that the
> AS-REQ message has a padata section with a type of PA-PK-AS-REP(15).
You mean the response to the request has type 15? The request should be 14.
>
> if I run gdb on the kdc, and break at find_padata() I see that it's only
> ever being called with type arguments of 2(KRB5_PADATA_ENC_TIMESTAMP),
> and 16(KRB5_PADATA_PK_AS_REQ)
This may have to do with what versions of the PKINIT draft are being used
bu the client and server. The older versions and the krb5 clarifications
used PA-PK-AS-REQ = 14 and PA-PK-AS-REP = 15. The newer PKINIT draft 25
uses 16 and 17. See the Heimdal-dev lib/asn1/k5.ans1
So I am confused, as the client should send either 14 or 16 and the
server should return 15 or 17. I am assuming the server returned 15.
This sounds like the problem I had with Windows KDC, which returns a 15.
The client did not find this.
Try something like this patch which says if no padata (17) found, try
again looking for the older version (15). I think I sent this one in,
if not I will send it in with some others shortly.
--- ,init_creds_pw.c Wed Feb 2 01:30:25 2005
+++ init_creds_pw.c Thu Apr 21 10:09:20 2005
@@ -1135,11 +1136,22 @@
}
pa = NULL;
- if (rep->kdc_rep.padata)
+ if (rep->kdc_rep.padata) {
+fprintf(stderr,"DEE %s:%d ret=%d\n",__FUNCTION__,__LINE__,ret);
pa = krb5_find_padata(rep->kdc_rep.padata->val,
rep->kdc_rep.padata->len,
KRB5_PADATA_PK_AS_REP,
&index);
+fprintf(stderr,"DEE %s:%d ret=%d\n",__FUNCTION__,__LINE__,ret);
+ if (!pa) {
+ index = 0;
+ pa = krb5_find_padata(rep->kdc_rep.padata->val,
+ rep->kdc_rep.padata->len,
+ KRB5_PADATA_PK_AS_REP_19, /* Also Win2K */
+ &index);
+fprintf(stderr,"DEE %s:%d ret=%d\n",__FUNCTION__,__LINE__,ret);
+ }
+ }
if (pa && ctx->pk_init_ctx) {
#ifdef PKINIT
ret = _krb5_pk_rd_pa_reply(context,
>
> should kinit be sending a packet with a padata type of
> KRB5_PADATA_PK_AS_REQ?
Yes.
>
> I haven't looked at the relevant kinit code, but will do so if someone
> doesn't see what's going wrong here.
>
> -Matt Andrews
>
> Douglas E. Engert wrote:
>
>>
>>
>> Matthew N. Andrews wrote:
>>
>>>
>>> I've set up an install of the snapshot from the 14th with pkinit
>>> enabled. when I try and kinit with an x509 cert, I see the following
>>> in the kdc log:
>>>
>>> 2005-04-22T16:37:19 AS-REQ ma3d@TEST.PDSF.NERSC.GOV from
>>> IPv4:128.55.27.106 for krbtgt/TEST.PDSF.NERSC.GOV@TEST.PDSF.NERSC.GOV
>>> 2005-04-22T16:37:19 Looking for PKINIT pa-data --
>>> ma3d@TEST.PDSF.NERSC.GOV
>>> 2005-04-22T16:37:19 Looking for ENC-TS pa-data --
>>> ma3d@TEST.PDSF.NERSC.GOV
>>> 2005-04-22T16:37:19 Using
>>> aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96
>>> 2005-04-22T16:37:19 sending 669 bytes to IPv4:128.55.27.106
>>>
>>>
>>> and the following output from kinit:
>>>
>>> $ kinit -C FILE:/auto/u/ma3d/foo.crt,/auto/u/ma3d/foo.key
>>> ma3d@TEST.PDSF.NERSC.GOV
>>> kinit: krb5_get_init_creds: unable to reach any KDC in realm
>>> TEST.PDSF.NERSC.GOV
>>>
>>
>> Do you have a network trace, like ethereal, to see the as_req and
>> response?
>> A response of 669 bytes sounds like a AS_REP rather then a KRB_ERROR
>> packet.
>>
>>> if seems that it's not actually finding the pkinit pre-auth data.
>>> running gdb on the kdc I see the following in as_rep():
>>>
>>> (gdb) c
>>> Continuing.
>>>
>>> Breakpoint 2, as_rep (req=0xbfffccb0, reply=0xbfffcd38,
>>> from=0x82521c0 "IPv4:128.55.27.106", from_addr=0x8252138)
>>> at kerberos5.c:737
>>> 737 int i = 0;
>>> (gdb) l
>>> 732
>>> 733 memset(&et, 0, sizeof(et));
>>> 734 memset(&ek, 0, sizeof(ek));
>>> 735
>>> 736 if(req->padata){
>>> 737 int i = 0;
>>> 738 PA_DATA *pa;
>>> 739 int found_pa = 0;
>>> 740
>>> 741 #ifdef PKINIT
>>> (gdb) n
>>> 739 int found_pa = 0;
>>> (gdb) n
>>> 742 kdc_log(5, "Looking for PKINIT pa-data -- %s",
>>> client_name);
>>> (gdb) n
>>> 744 i = 0;
>>> (gdb) n
>>> 745 e_text = "No PKINIT PA found";
>>> (gdb) n
>>> 755 continue;
>>> (gdb) c
>>>
>>
>> Can you set a breakpoint at find_padata, and pk_rd_padata?
>> How about a fre printf statments?
>>
>>>
>>> I'm expecially confused about the jump from line 745 to line 755. I
>>> rebuilt by re-running configure with CFLAGS set to just -g thinking I
>>> might just be looking at optimization weirdness, but that didn't seem
>>> to make a difference.
>>>
>>> any ideas?
>>>
>>> any more info that's needed?
>>
>>
>>
>> I have not tried the KDC, but have 20050405 client working to a
>> Windows AD.
>>
>>>
>>> -Matt Andrews
>>>
>>>
>>>
>>
>
>
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444