Hi Tom,
I'm very happy you can set up the MIT KDC and found the next things we can do
for PKINIT.
>>>To focus my efforts on the server
It's good that you can focus on server side, and I would like to focus on
client side.
>>>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
As far as I know, a) is Four-Pass Authentication, in this mode, the client
sends an initial AS-REQ to the KDC that does not contain a PK_AS_REQ and the
KDC responds with a KRB-ERROR containing the supported preauth list.
b) is Two-Pass Authentication, in this mode, the client includes a PK_AS_REQ
padata of the initial AS-REQ sent to the KDC.
I think a) is supported by MIT client from the MIT KDC logs:
Aug 17 11:33:02 plusplus-desktop krb5kdc[17304](info): AS_REQ (6 etypes {18 17
16 23 25 26}) 127.0.0.1: NEEDED_PREAUTH: [email protected] for
krbtgt/[email protected], Additional pre-authentication required Aug 17
11:33:02 plusplus-desktop krb5kdc[17304](info): AS_REQ (6 etypes {18 17 16 23
25 26}) 127.0.0.1: ISSUE: authtime 1439782382, etypes {rep=18 tkt=18 ses=18},
[email protected] for krbtgt/[email protected] and I'm also not sure b)
is supported by MIT client&KDC, I would like to make it clear through reading
the krb5 source code and test.
>>>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).
As you said, the "no key" is a good choice to indicate the certificate preauth.
And whether preauth is enabled by kdc can be the other condition:
1. the "no key" value in the principal's indentity entry
2. the preauth plugin is enabled(pkinitpreauth, tokenpreauth and so on).
In the Four-Pass authentication, Kerby KDC will return the enabled preauth list
to client. And client will choose one of them to retry.
>>>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.
I think you are right.
When KDC needs certificate preauth it will throw the KdcRecoverableException,
then after the client receive the KRB-ERROR, it retry with the new AS_REQ
including certificate preauth info.
Kerby will support both a) and b), and I think b) is more easy to be
implemented, so I think we can do the following things first:
1) Client side todo: get the certificate and send the PK_AS_REQ to kdc.
2) KDC side todo: get the PK_AS_REQ and verify the certificate, return the
PK_AS_REP.
How do you think?
Thanks
Jiajia
-----Original Message-----
From: Tom Mueller [mailto:[email protected]]
Sent: Saturday, August 15, 2015 3:55 AM
To: [email protected]
Subject: Re: pkinit
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
