Help using PKINIT (MIT)

Kevin Coffman kwc at umich.edu
Mon Apr 4 12:15:19 EDT 2011


It sounds like something might be missing.  I don't recall the exact
build requirements, but it expects openssl to be available.  I'm not
sure what other failure [to build] scenarios there might be...

On Mon, Apr 4, 2011 at 12:07 PM, JAKOBI Pascal
<pascal.jakobi at thalesgroup.com> wrote:
> OOOps...
>
> There is one thing I don't understand : normally, pkinit is generated
> automatically when you run configure (only disable-pkinit is offered as an
> option)....
> In my case, the sources are here, but no object file is generated by
> Makefiles.
> Isn't some piece missing (I run krb 1.8.3).
>
> Thxs
> P
>
>
> On 04/04/2011 17:52, Kevin Coffman wrote:
>
> I don't see any attempt at initializing pkinit.  Is the plugin there?
>
> On Mon, Apr 4, 2011 at 11:39 AM, JAKOBI Pascal
> <pascal.jakobi at thalesgroup.com> wrote:
>> Here you go...
>>
>>
>> [root at serveur sbin]# ./krb5kdc -n
>> stat(/usr/local/lib/krb5/plugins/kdb/db2): No such file or directory
>> get_plugin_data_sym(kdb_function_table)
>> get_plugin_data_sym(preauthentication_server_1)
>> get_plugin_data_sym(authdata_server_2)
>> get_plugin_data_sym(authdata_server_0)
>> 0x9375ff0={
>>     name=lo
>>     flags=10049<UP,LOOPBACK,RUNNING>
>>     addr=0x937600c <getnameinfo error -6: ai_family not supported>
>> family=17
>>     broadaddr=0x9376054 <getnameinfo error -6: ai_family not supported>
>> family=17
>>     dstaddr=0x9376054 <getnameinfo error -6: ai_family not supported>
>> family=17
>>     data=0x9376434
>> }
>> 0x937608c={
>>     name=eth0
>>     flags=11043<UP,BROADCAST,RUNNING,MULTICAST>
>>     addr=0x93760a8 <getnameinfo error -6: ai_family not supported>
>> family=17
>>     broadaddr=0x93760f0 <getnameinfo error -6: ai_family not supported>
>> family=17
>>     dstaddr=0x93760f0 <getnameinfo error -6: ai_family not supported>
>> family=17
>>     data=0x9376490
>> }
>> 0x9376128={
>>     name=wlan0
>>     flags=1003<UP,BROADCAST,MULTICAST>
>>     addr=0x9376144 <getnameinfo error -6: ai_family not supported>
>> family=17
>>     broadaddr=0x937618c <getnameinfo error -6: ai_family not supported>
>> family=17
>>     dstaddr=0x937618c <getnameinfo error -6: ai_family not supported>
>> family=17
>>     data=0x93764ec
>> }
>> 0x93761c4={
>>     name=lo
>>     flags=10049<UP,LOOPBACK,RUNNING>
>>     addr=0x93761e0 127.0.0.1
>>     netmask=0x9376204 255.0.0.0
>>     broadaddr=0x9376228 127.0.0.1
>>     dstaddr=0x9376228 127.0.0.1
>> }
>> 0x9376260={
>>     name=eth0
>>     flags=11043<UP,BROADCAST,RUNNING,MULTICAST>
>>     addr=0x937627c 10.222.144.38
>>     netmask=0x93762a0 255.255.254.0
>>     broadaddr=0x93762c4 10.222.145.255
>>     dstaddr=0x93762c4 10.222.145.255
>> }
>> 0x93762fc={
>>     name=lo
>>     flags=10049<UP,LOOPBACK,RUNNING>
>>     addr=0x9376318 ::1
>>     netmask=0x937633c ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
>> }
>> 0x9376398={
>>     name=eth0
>>     flags=11043<UP,BROADCAST,RUNNING,MULTICAST>
>>     addr=0x93763b4 fe80::20f:1fff:feba:2e13%eth0
>>     netmask=0x93763d8 ffff:ffff:ffff:ffff::
>> }
>> krb5kdc: starting...
>>
>>
>> On 04/04/2011 17:34, Kevin Coffman wrote:
>>
>> It doesn't appear that the KDC is offering PKINIT as a
>> pre-authentication option (pa_types 15,16,17,18).  I believe the KDC's
>> certificate looks OK, but there are other things required in the KDC's
>> configuration before it will offer PKINIT.  (i.e. the plugin must be
>> available, and initialize properly.)  Do you have debug output from
>> the KDC's [plugin] initialization?
>>
>>
>> On Mon, Apr 4, 2011 at 11:14 AM, JAKOBI Pascal
>> <pascal.jakobi at thalesgroup.com> wrote:
>>> Kevin
>>>
>>> It took me a while to get back to the issue. Apologies for this.
>>> Essentially, here is what I get when running kinit with "DEBUG" set.
>>>
>>> ./kinit -X X509_user_identity='/C=FR/O=BioNet/CN=user/' user at BIONET.FR
>>> get_plugin_data_sym(preauthentication_client_1)
>>> init module "Encrypted Challenge", pa_type 138, flag 1
>>> get_plugin_data_sym(service_locator)
>>> get_plugin_data_sym(service_locator)
>>> get_plugin_data_sym(service_locator)
>>> preauth data types before sorting: 2 136 19 13 133
>>> preauth data types after sorting: 2 136 19 13 133
>>> salt len=-1; preauth data types: 2 136 19 13 133
>>> trying modules for pa_type 2, flag 2
>>> trying modules for pa_type 136, flag 2
>>> etype info 0: etype 18 salt len=-1
>>> etype info 1: etype 17 salt len=-1
>>> etype info 2: etype 16 salt len=-1
>>> etype info 3: etype 23 salt len=-1
>>> trying modules for pa_type 19, flag 2
>>> trying modules for pa_type 13, flag 2
>>> calling internal function for pa_type 133, flag 2
>>> trying modules for pa_type 133, flag 2
>>> calling internal function for pa_type 2, flag 1
>>> preauth2.c:708: salt len=-1; *etype=18 request->ktype[0]=18
>>> Password for user at BIONET.FR:
>>> key type 18 bytes a3 27 ...
>>> enc data { type=18 kvno=0 data=fd 91 ... }
>>> get_plugin_data_sym(service_locator)
>>> get_plugin_data_sym(service_locator)
>>> get_plugin_data_sym(service_locator)
>>> preauth data types before sorting: 19
>>> preauth data types after sorting: 19
>>> salt len=-1; preauth data types: 19
>>> etype info 0: etype 18 salt len=-1
>>> trying modules for pa_type 19, flag 2
>>> [root at client bin]#
>>>
>>> Attached are a bunch of information that may help.
>>>
>>> Thanks again for your help.
>>> P
>>>
>>>
>>>
>>> On 31/03/2011 16:44, Kevin Coffman wrote:
>>>
>>> On Thu, Mar 31, 2011 at 7:28 AM, JAKOBI Pascal
>>> <pascal.jakobi at thalesgroup.com> wrote:
>>>> Hi there
>>>>
>>>> I need help in order to get PKINIT working on Fedora 14.
>>>> I have a running kerberos server with krb-server, krb-server-ldap and so
>>>> on (1.8.2).
>>>> I also have installed krb5-pkinit-openssl.
>>>>
>>>> The stuff works like a charm when running in "standard" kerberos, i.e.
>>>> w/o pkinit.
>>>>
>>>> Then we tried to set up pkinit according to the instructions found at
>>>> http://k5wiki.kerberos.org. In particular, we checked carefully, our
>>>> certs.
>>>
>>> Perhaps you could list your certificate information here for both the
>>> user and KDC certificates (the output of "openssl x509 -noout -text
>>> -in YOUR.CRT").
>>>
>>>> However, the behaviour does not seem correct.
>>>>
>>>> We issue a kinit -X x509_user_identity=<DN found in the client cert>
>>>> <principal> on the client side (another Fedora instance with software
>>>> certs).
>>>> With Wireshark, we see that an AS-REQ is sent to the server. However, it
>>>> does not seem to convey any certificate (pa-data type = 149).
>>>>
>>>> Then the server replies with ERR_PREAUTH_REQUIRED (the principal that is
>>>> used has its preauth option set).  Is this normal ?
>>>
>>> This is normal.   If the KDC's pkinit preauth plugin is properly
>>> configured (valid certificate and kdc.conf configuration options), one
>>> of the preauth options it should return is PKINIT.  (14,15,16, or 17)
>>> The client should then send the PKINIT preauth information in its
>>> subsequent request.  If it is accepted by the KDC, there shouldn't be
>>> a pasword prompt.
>>>
>>>> As a result of this, the standard AS_REQ/REP procedure seems to be
>>>> played (as a password is requested on the client side).
>>>>
>>>> The problem is that even when recompiling pkinit with DEBUG set, we
>>>> cannot see anything....
>>>
>>> Are you running your KDC in the foreground?  Debug output will go to
>>> stderr or stdout.  Verify that the PKINIT preauth plugin is
>>> successfully loaded and properly initialized.
>>>
>>>> Any help (very) greatly appreciated.
>>>>
>>>> Thanks
>>>> Pascal
>>>>
>>>> --
>>>> Pascal Jakobi
>>>> Sr. Architect, Thales
>>>> 1  av. A. Fresnel
>>>> 91767 Palaiseau, France
>>>> Tel. : +33 1 69 41 60 51
>>>> Mob.: + 33 6 87 47 58 19
>>>>
>>>> ________________________________________________
>>>> Kerberos mailing list           Kerberos at mit.edu
>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>
>>>
>>> .
>>>
>>> --
>>> Pascal Jakobi
>>> Sr. Architect, Thales
>>> 1  av. A. Fresnel
>>> 91767 Palaiseau, France
>>> Tel. : +33 1 69 41 60 51
>>> Mob.: + 33 6 87 47 58 19
>>>
>>
>> .
>>
>> --
>> Pascal Jakobi
>> Sr. Architect, Thales
>> 1  av. A. Fresnel
>> 91767 Palaiseau, France
>> Tel. : +33 1 69 41 60 51
>> Mob.: + 33 6 87 47 58 19
>>
>
> .
>
> --
> Pascal Jakobi
> Sr. Architect, Thales
> 1  av. A. Fresnel
> 91767 Palaiseau, France
> Tel. : +33 1 69 41 60 51
> Mob.: + 33 6 87 47 58 19
>




More information about the Kerberos mailing list