[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