pkinit

[Tom Mueller <mu...@vmware.com>]

Hi Jiajia, 

Finally digging into the pkinit support in ernest. I've checked out the
pkinit-support branch and built it successfully.  Saw the
WithCertKdcTest.testKdc test method and uncommented out the @Test so I
could start running the test. This helped to show some of the pieces that
are missing. 

Do you have a list of what's working and what isn't?
Also, do you have any writeup on the intended design?

For example, on the client side I see subclasses for each preauth type
(AsRequestWithCert, AsRequestWithPassword, etc.) but on the server side
there is just the server.request.AsRequest class that appears to be
handling multiple preauth types. Also, I see the PkinitPreauth class that
isn't hooked into the default server. Is the intent that it eventually
will be?  Or is PKINIT support something that will need to be configured
in. 

Thanks. 
Tom

RE: pkinit

["Li, Jiajia" <ji...@intel.com>]

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

Re: pkinit

[Tom Mueller <mu...@vmware.com>]

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

RE: pkinit

["Li, Jiajia" <ji...@intel.com>]

Hi Tom,
I'm glad you would help with the PKINIT feature. Yes it's a good start to run the test and hope the test will pass finally.

>>>"Do you have a list of what's working and what isn't?
>>>Also, do you have any writeup on the intended design?"

We are now working for the 1st release, after it I'd like to focus on the pkinit feature.
We do not have design doc now, and maybe some time later I could help with it. Currently it looks like only the rough framework has been implemented for PKINIT, 
and we might have following things to be done:
1). Not sure all PKINIT related codecs are ready. Ref. kerby-kerb/kerb-core/src/main/java/org/apache/kerby/kerberos/kerb/spec/pa/pkinit.
2). PKINT in client side, could resolve and use the config like bellow:
  pkinit_anchors = FILE:/etc/krb5/cacert.pem
  pkinit_identities = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem		 
The clientkey.pem is private key and the cacert.pem is CA certificate.
3) We need to load the configured keys and then send perform relevant computation generating keys and send relevant messages to server side, which could be done in the client side PKINT preauth plugin.				
4) PKINIT anonymous. In simpler case, no client certificate is used.
5) PKINT in KDC side
We may have similar configurations like below:
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem
pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
The kdckey.pem is KDC private key  and the cacert.pem is CA certificate.
6) KDC then needs to perform the similar computation generating keys like client and relevant messages to client for response, which could be done in the server side PKINT preauth plugin.
These are just my quick thoughts for now. How would you like it? Guess in every item we'll need to further discussion and write some codes. New JIRAs for them?

>>>"For example, on the client side I see subclasses for each preauth type (AsRequestWithCert, AsRequestWithPassword, etc.) but on the server side there is just the server.request.AsRequest class that appears to be >>>handling multiple preauth types. Also, I see the PkinitPreauth class that isn't hooked into the default server. Is the intent that it eventually will be? "

In server side, the mechanism specific stuff is handled by the preauth framework and corresponding preauth plugin, thus we don't go as client. The PkinitPreauth isn't hooked into the default server because it has not been finished yet.
In case it's needed, the following could be the process of pkinit preauth:
There is the PkinitPreauth class in client and server respectively.
1. If we use AsRequestWithCert from client, the pkinit preauth will be set allowed.
2. Set the KrbOption(such as X509 user certificate) to KrbOptions.
3. The client KdcRequest will call the PkinitPreauth to add the pkinit preauth padata to the AsReq.
4. In the server side, after the KdcRequest receive the kdcrequest, the preauth function will get the padata from the KdcReq and get the preauth handler to call the PkinitPreatuh to verify.

Thanks
Jiajia

-----Original Message-----
From: Tom Mueller [mailto:muellert@vmware.com] 
Sent: Tuesday, August 11, 2015 4:36 AM
To: kerby@directory.apache.org
Subject: pkinit

Hi Jiajia, 

Finally digging into the pkinit support in ernest. I've checked out the pkinit-support branch and built it successfully.  Saw the WithCertKdcTest.testKdc test method and uncommented out the @Test so I could start running the test. This helped to show some of the pieces that are missing. 

Do you have a list of what's working and what isn't?
Also, do you have any writeup on the intended design?

For example, on the client side I see subclasses for each preauth type (AsRequestWithCert, AsRequestWithPassword, etc.) but on the server side there is just the server.request.AsRequest class that appears to be handling multiple preauth types. Also, I see the PkinitPreauth class that isn't hooked into the default server. Is the intent that it eventually will be?  Or is PKINIT support something that will need to be configured in. 

Thanks. 
Tom