PKINIT support in MIT Kerberos : are enhancements planned ?

[Douglas E. Engert]

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.)

>
>>    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.

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.

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