PKINIT support in MIT Kerberos : are enhancements planned ?

[Matthieu Hautreux]

Hi,

I discussed this topic on the krbdev mailing list last month but did
not get feedback from the main developpers of MIT kerberos. So, I try
again on the general mailing list in case it could be a better place
to put such a message.

I am currently working on a way to bind gsi-ssh and kerberos using
PKINIT in order to offer a seamless access to a kerberized remote
environment using the X509 material of the client.

I am facing two problems that prevent me from having something working
properly with MIT kerberos implementations :

  1/ GSI-SSH uses proxy-certificates to provide single sign-on on the
remote side. To get a kerberos token out of the x509 material on the
server, I need to have a kerberos implementation supporting
proxy-certificates.

  2/ We are using multiple PKIs that were defined prior to any
consideration of doing PKINIT stuff and can not be modified. We can
not rely on a simple DN<->principal mapping as this feature is not
supported in current MIT implementation.


The problem 1/ correspond to the support of RFC 3820 in PKINIT
implementation. It is lacking in current MIT implementations.

The problem 2/ correspond to the support of a simple mapping between
certificates and principals. In the PKINIT RFC (RFC 4556), the
sentence "If the KDC has its own binding between either the client's
signature-verification public key or the client's certificate and the
client's Kerberos principal name, it uses that binding." suggests that
such a basic mapping methodology should be proposed as the default
mechanism. Below, the part of the RFC about that point :

---
[...]

3.2.2.  Receipt of Client Request

[...]

1. If the KDC has its own binding between either the client's
   signature-verification public key or the client's certificate and
   the client's Kerberos principal name, it uses that binding.

2. Otherwise, if the client's X.509 certificate contains a Subject
   Alternative Name (SAN) extension carrying a KRB5PrincipalName
   (defined below) in the otherName field of the type GeneralName
   [RFC3280], it binds the client's X.509 certificate to that name.

[...]

The KDC MAY require the presence of an Extended Key Usage (EKU)
KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
of the client's X.509 certificate:

      id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
        { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
          pkinit(3) keyPurposeClientAuth(4) }
             -- PKINIT client authentication.
             -- Key usage bits that MUST be consistent:
             -- digitalSignature.

The digitalSignature key usage bit [RFC3280] MUST be asserted when
the intended purpose of the client's X.509 certificate is restricted
with the id-pkinit-KPClientAuth EKU.
---

I would like to know if these 2 features are planned in a future
version of MIT kerberos. If it is not the case, I would be pleased to
know how I could participate in such an addition and the person I must
contact for that purpose.
I have seen that it exists a "MIT kerberos consortium", perhaps I
should try to contact them to discuss such an evolution ?

Thanks in advance for your feedback.

Best regards,
Matthieu Hautreux