Using Smartcard with PK-INIT does not respond

[Loren M. Lang]

On Wed, 2009-03-04 at 06:33 -0800, Loren M. Lang wrote:
> On Wed, 2009-03-04 at 08:46 -0500, Kevin Coffman wrote:
> > On Wed, Mar 4, 2009 at 1:49 AM, Loren M. Lang <lorenl at north-winds.org> wrote:
> > > I am trying to enable smartcard logins to a MIT Kerberos domain using
> > > the recent PK-INIT preauth plugin.  I am using Ubuntu 8.10 with it's
> > > stock Kerberos 1.6.4 packages except for pkinit.so recompiled with
> > > -DDEBUG.  I have a server certificate installed on the KDC with the
> > > extended key usage id_pkinit_KPKdc and an appropriate subjectAltName.
> > > There is one intermediate certificate between it and the root CA.
> > > Client certificates were generated similarly only with the
> > > id_pkinit_KPClientAuth key usage and have two intermediates between it
> > > and the same root CA.  The client certificates are installed on a smart
> > > card using opensc and are also enabled for the clientAuth key usage for
> > > SSL client authentication.  I also have intermediate CAs and the root CA
> > > installed on the smart card as well.  Firefox is able to see the smart
> > > card including all intermediates and root CAs and is able to use it to
> > > authenticate against a SSL website.  Running kinit with debugging output
> > > I was able see that is was complaining that the smart card had four
> > > matching certs.  It did not filter out certificates missing the
> > > appropriable key usages or missing subjectAltName, maybe that's typical.
> > > I setup a pkinit_cert_match to filter out the other certificates and now
> > > kinit reports finding exactly one match, but bails out later due to
> > > missing intermediate certificates so I setup pkinit_pool to point
> > > to /etc/ssl/certs with appropriate certificates.  It did not seem to use
> > > the intermediates already on the smart card, is this normal?
> > 
> > Normal is subjective ;-)   There is no code to deal with intermediates
> > or root CAs that might be found on the smartcard.
> 
> Bad choice of words, I meant, how MIT's PK-INIT code is supposed to
> behave.  I was assuming that this functionality was supported by
> OpenSSL/OpenSC and not MIT specifically.
> 
> > 
> > > Now kinit
> > > was complaining about some broken symlinks that exist
> > > under /etc/ssl/certs and it bails out.  Shouldn't these just be ignored?
> > 
> > I thought anything that wasn't a cert was ignored w/o bailing, but
> > this might have been missed.
> > 
> > > This symlinks point to missing certificates that have nothing to do with
> > > the pki infrastructure I am using, but once I moved the symlinks out of
> > > the way, kinit continued and finally sent out an AS-REQ with the PK-INIT
> > > preauth data, but received no response.  According to Wireshark,
> > > following the initial AS-REQ with no preauth, the server responds with a
> > > NEEDED_PREAUTH error listing six preauth types including PA-PK-AS-REQ
> > > and PA-PK-AS-REP.  The client then sends a single IP fragment response.
> > > The fragment has a payload of 1480 bytes with flag more fragments, but
> > > no further fragments are sent.  I have no firewall rules installed and
> > > am at a loss as to why there are no more fragments.
> > 
> > I'm not sure what might be happening here.  This would just be a
> > work-around, but is it possible for you to try using TCP rather than
> > UDP?
> 
> I enabled TCP support on my KDCs and netstat confirms they are listening
> on them.  I tried setting udp_preference_limit to 1480, 1000, and 50,
> but kinit never uses TCP.  I put udp_preference_limit both at the very
> beginning and very end of my libdefaults section in krb5.conf and even
> tried using copy/paste to double check that I typed it correctly.

Never mind, I was using SRV records and only install _udp types.
Specifying the server in krb5.conf resolved that.  Now, the error I am
getting is KRB5KRB_ERR_GENERIC: KDC_RETURN_PADATA.

> 
> Also, kdc_tcp_ports is not documented in my kdc.conf man page.  I had to
> look in the info pages for it.
>
> > 
> > K.C.
> > 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
-- 
Loren M. Lang
lorenl at alzatex.com
http://www.alzatex.com/


Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: 10A0 7AE2 DAF5 4780 888A  3FA4 DCEE BB39 7654 DE5B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7539 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20090304/015e7455/attachment.bin