Fwd: pkinit SAN and EKU checking

[Douglas E. Engert]

Kevin Coffman wrote:
> Sam suggested I forward this here.  Comments/suggestions welcome.


What about mixed environments where some certs (may be issued by
a local CA) and some others are issued by some external CA.
So are you sans and eku checking based on the issuer CA?

Examples could be using PIV smart cards issued by federal
government for a small number of outside users, with most
users using soft certs issued by local site.

It looks like external could always be used if needed.
but then all uses would have to be handled that way.

> 
> K.C.
> 
> ---------- Forwarded message ----------
> From: Kevin Coffman <kwc at citi.umich.edu>
> Date: May 14, 2007 4:28 PM
> Subject: pkinit SAN and EKU checking
> To: Sam Hartman <hartmans at mit.edu>
> Cc: pkinit at citi.umich.edu
> 
> 
> Hi Sam,
> Our SAN/EKU checking currently has ties to the pa_type involved.  I'm
> going to change this.  Olga also ran into an issue we did not
> anticipate at Connectathon with a certificate with multiple SANs.
> 
> These are my notes on configuration changes to be made based on a
> discussion with Olga this morning.  Does this look reasonable to you?
> I plan to code these changes this week.  So if you have objections,
> please let me know ASAP.
> 
> Thanks,
> K.C.
> 
> 
> SAN Checking
> ===========
> 
> Client verification of KDC certificate
> --------------------------------------------------
> 
> pkinit_san_checking = [pkinit | dns | external]
> 
> The default is "pkinit", which says that the KDC's certificate must
> have the id-pkinit-san SAN.  If "dns" is specified, then the dNSName
> SAN will be accepted.  (The pkinit_kdc_hostname configuration
> parameter specifies which name(s) will be accepted.)  If "external",
> is specified, then some external name mapping must be configured to
> verify the KDC certificate.
> 
> KDC verification of client certificates
> ----------------------------------------------------
> 
> pkinit_san_checking = [pkinit | upn | external]
> 
> The default is "pkinit", which says that the client certificate must
> have the id-pkinit-san SAN.  If "upn" is specified, then a client
> certificate containing the id-ms-san-sc-logon-upn SAN is accepted.  If
> "external" is specified, then some external name mapping must be
> configured to associate the certificate to a specific Kerberos
> principal.
> 
> 
> EKU checking
> ===========
> 
> Client verification of KDC certificate
> ---------------------------------------------------
> 
> pkinit_eku_checking = [kpKDC | kpServerAuth | none]
> 
> The default is "kpKDC", which means the client insists that the KDC
> certificate contains the kpKDC EKU.  If "kpServerAuth" is specified,
> the client will accept a KDC certificate with either the kpKDC EKU or
> the serverAuth EKU.  If "none" is specified, the client does not
> require that the KDC's certificate have either EKU (not recommended).
> 
> (Note that according to section 3.2.4 of rfc4556, if the KDC
> certificate has the id-pkinit-san SAN corresponding to the Kerberos
> TGS name, the kpKDC EKU is not required.)
> 
> KDC verification of client certificates
> ----------------------------------------------------
> 
> pkinit_eku_checking = [kpClientAuth | scLogin | none]
> 
> The default is to accept client certificates with either the
> id-pkinit-KPClientAuth or id-ms-kp-sc-login EKU.  If "kpClientAuth" is
> specified, then the client certificate must have the
> id-pkinit-KPClientAuth EKU.  If "scLogin" is specified, then the
> client certificate must have the id-ms-kp-sc-login EKU.  If "none" is
> specified, then no EKU will be required in client certificates.
> _______________________________________________
> 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