[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkinit as_rep
Douglas E. Engert wrote:
> 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.
>
no, I mean the request itself has type 15.
if I place "win2k_pkinit = false" in my realm's stanza of the [realms]
section of the krb5.conf then the request has type 14, but the default
is type 15. presumably for win2k brokenness compatability.
-Matt Andrews
>>
>> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>