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:[email protected]]
Sent: Tuesday, August 11, 2015 4:36 AM
To: [email protected]
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
