PKINIT support in MIT Kerberos : are enhancements planned ?

[Matthieu Hautreux]

Tom,

thank your very much for your feedback.

Douglas, thanks for reacting on it. You have a better view of all of
that than I can have.

You will find below my own comments.

2012/1/5, Douglas E. Engert <deengert at anl.gov>:
>
>
> On 1/4/2012 3:57 PM, Tom Yu wrote:
>> [redirecting to krbdev]
>>
>> Matthieu Hautreux<matthieu.hautreux at gmail.com>  writes:
>>
>>> 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.
>>
>> What level of support you need for RFC 3820 proxy certificates?  Do
>> restrictions in the proxy certificates need to somehow expressed in
>> the Kerberos ticket?  Is it sufficient to perform the RFC 3820 basic
>> validation procedure?  (I'm not too familiar with the details of RFC
>> 3820, so please correct me if I misunderstand something.)
>
> I have not been actively involved with Globus for a few years,
> but I would venture to say that the restrictions would not have to be
> expressed in the Kerberos ticket. (That could be some future project,
> long after I retire.)

I agree that proxy-certificate restrictions does not need to be
treated at first. The validation procedure as described in the RFC
should be sufficient.

In the current MIT code, it sounds that the pkinit client code does
not even try to do pkinit stuff when it receives a proxy certificate
(PC) as an input. It only works when I present the EEC of the PC.
(Note that the EEC is a certificate with a valid PKINIT SAN only build
for the validation of the PKINIT stack)

I have a working heimdal (1.5.1) slave configured for pkinit that let
me get a ticket with either the EEC or the PC.

>
>>
>>>    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.
>>
>> There are several ways we could do that, but there does seem to be an
>> existing unimplemented (and possibly undocumented) configuration
>> option to specify a DN mapping file.   It would be cleaner to use
>> per-principal information stored in the KDC database though.  Keeping
>> the DN mapping in a separate file seems like it would be more
>> troublesome for the day-to-day administration of a realm.
>
> The DN mapping was a simple way to map certificates to local users
> on servers for logon purposes where there were just a few users.
>
> Just as with other PKINIT certificates, the user would have to
> register the End Entity Certificate with the KDC ahead of time.
> The KDC could then use the EEC from the proxy chain to map to a
> principal, just as it does now for other PKINIT certificates.

With an external mapping (i.e. no SAN nor UPN usage), we plan to have
the description of the DN associated to each of our users added to the
LDAP and a tool to automatically update a mapping file when necessary
(working with heimdal).
Having the DN directly added in the DB could also be a good solution.
That design was proposed by Sam Hartman in a reply to one of my
previous email. My only concern with that solution is that as it
sounds heavier than a simple file it is harder to backport to current
RedHat 6.x MIT implementation (the OS that we are using in
production). But if you want to go into that direction, I am ok with
it.

By the way, it sounds like adding the DN mapping logic in the server
is not sufficient. When I use a basic x509 certificate as an input of
the MIT pkinit client implementation, it acts like for PC, that is to
say it did not even try to do pkinit stuff. If think that there is
some check that prevent from using a ticket not conforming to the
PKINIT certificate extensions (perhaps a SAN or the eku). I will have
to look at the code to confirm.

>
> One of the most common use cases for Proxy certificates and Kerberos
> would be for a Grid job to get a ticket from the site's KDC for use
> with AFS.

That is exactly the kind of scenario we are thinking about. I am
working at CEA in France, we are involved in a European project called
PRACE in which a grid is glueing multiple supercomputing centers of
different countries. The authentication of the users in the grid are
based on Globus GSI. I know at least two european sites involved in
PRACE that are looking at a way to glue x509 of GSI with kerberos for
site internal authentication.

For now, I have a working solution (basic PKIs support with no PKINIT
extensions and PC support) in which an heimdal slave is used for
PKINIT stuff on top of the MIT kerberos infrastructure. Having the
equivalent in MIT could be interesting but is not urgent. I am ready
to help on the code of the DN mapping as a start if you want.

Regards,
Matthieu

>
> OpenSSL and Heimdal have has support for RFC 3820 for some years,
> but I have not tried either.
>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>
>
> --
>
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>