[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkinit as_rep
Matthew N. Andrews wrote:
> 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.
That sounds strange, as all the old documents have PA-PK-AS-REQ as 14,
and PA-PK-AS-REP as 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.
>
I am using heimdal-20050405 against a Win2K kdc, with win2k_pkinit = yes
set in the krb5.conf with the mod I told you about in a previous note.
The PA-PK_AS_REP is 15.
> -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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444