directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li, Jiajia" <jiajia...@intel.com>
Subject RE: pkinit
Date Mon, 17 Aug 2015 08:23:12 GMT
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: jiajia@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM, 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}, jiajia@EXAMPLE.COM for krbtgt/EXAMPLE.COM@EXAMPLE.COM 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:muellert@vmware.com] 
Sent: Saturday, August 15, 2015 3:55 AM
To: kerby@directory.apache.org
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
muellert@HWPERF.TRCINT.COM

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


Mime
View raw message