Hi Jiajia, Thanks for the overview on PKINIT. Here's what I've been trying to help understand this more.
To focus my efforts on the server, I wanted to start with a client that works. So I set up MIT KDC to do PKINIT and got that working. The MIT kinit command that I used to get the TGT is: kinit -V -X X509_user_identity=FILE:/root/client.pem,/root/clientkey.pem [email protected] Next, I changed the kdc address in the /etc/krb5.conf file to point to the Kerby KDC and have been looking at what happens. The KDC receives an AS_REQ with a single paEntry with data type ENCPADATA_REQ_ENC_PA_REP (149). The Kerby KDC doesn't recognize this. I tried adding the PkinitPreauth to the PreauthHandler class but that doesn't change anything because it only recognizes PK_AS_REQ and PK_AS_REP. As I understand it, the PKINIT protocol is supposed to allow either of the following: a) the client sends an AS-REQ with nothing, server sends back AS-REP with certificate pre-auth required, then client sends AS-REQ with certificate b) the client sends the certificate right away, knowing that the server wants certificate pre-auth At this point, I'm not sure if the MIT client is doing (a) or (b). It appears to be doing (a) based on the absence of PA entries, which means that the Kerby KDC has to send back an AS-REP that requests certificate pre-auth. Presumably the decision to do this would be based on some configuration data, such as a "no key" value in the principal's identity entry or maybe a realm-wide config value (MIT KDC does the former). What I don't see at this point is something in the Kerby KDC that will send back the AS-REP that says pre-auth required rather than just issuing the ticket. This would seem to mean that the KdcRequest.process() method has to be changed or there needs to be an AsRequest.process method in the server that handles this case. Is this on the right track? Thanks. Tom
