Re: pkinit as_rep

["Matthew N. Andrews" <matt@slackers.net>]

on closer inspection this seems to be a win2k vs. -19 vs. -25 issue.



from include/krb5_asn1.h:
typedef enum PADATA_TYPE {
... members cut for brevity ...
   KRB5_PADATA_PK_AS_REQ_19 = 14,
   KRB5_PADATA_PK_AS_REP_19 = 15,
   KRB5_PADATA_PK_AS_REQ_WIN = 15,
   KRB5_PADATA_PK_AS_REQ = 16,
   KRB5_PADATA_PK_AS_REP = 17,
... members cut for brevity ...
} PADATA_TYPE;

it would seem that kinit is defaulting to assuming that the kdc is 
win2k, and setting "win2k_pkinit = false" in my realm's stanza of the 
[realms] section of the krb5.conf causes it to follow the -19 fork of 
the code as seen in lib/krb5/pkinit.c:_krb5_pk_mk_padata(). the kdc on 
the other hand seems to use the ietf draft-25 values. as of the 20050425 
snapshot the -25 fork of _krb5_pk_mk_padata() was commented out with an 
"#if 0" clause.

Love, is this code just not done yet? do you plan on adding a krb5.conf 
config option like the one for win2k to control wether a realm is -19 
based, or -25 based? does anything other than heimdal snapshots do -19 
style PKINIT?

If I knew what the desired behavior was, i could submit a patch.

-Matt


Matthew N. Andrews wrote:
> oops... meant to send this to the list:
> 
> 
> 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).
> 
> 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)
> 
> should kinit be sending a packet with a padata type of
> KRB5_PADATA_PK_AS_REQ?
> 
> 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
>>>
>>>
>>>
>>
> 
> 
>