Subject: RE: validating KDC certificates

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 17 Oct 2005 20:43:43 -0700

It seemed to us that we can do better. Here is the new text we would
like to propose:

---------------------------------

Appendix C.  Miscellaneous Information about Microsoft Windows PKINIT
             Implementations

   Earlier versions of the PKINIT I-D were implemented in various
   releases of Microsoft Windows and deployed in fairly large numbers.
   To enable the community to better interoperate with systems running
   those releases, the following information may be useful.

   KDC certificates issued by Windows 2000 Enterprise CAs contain a
   dNSName SAN with the DNS name of the host running the KDC, and the
   id-kp-serverAuth EKU [RFC3280].

   KDC certificates issued by Windows 2003 Enterprise CAs contain a
   dNSName SAN with the DNS name of the host running the KDC, the id-kp-
   serverAuth EKU and the id-ms-kp-sc-logon EKU.

   It is anticipated that the next release of Windows is already too far
   along to allow it to support the issuing KDC certificates with id-
   pkinit-san SAN as specified in this RFC.  Instead, they will have a
   dNSName SAN containing the domain name of the KDC and the intended
   purpose of these KDC certificates be restricted by the presence of
   the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.

   In addition to checking that the above are present in a KDC
   certificate, Windows clients verify that the issuer of the KDC
   certificate is one of a set of allowed issuers of such certificates,
   so those wishing to issue KDC certificates need to configure their
   Windows clients appropriately.

   Client certificates accepted by Windows 2000 and Windows 2003 Server
   KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
   SAN and the id-ms-kp-sc-logon EKU.  The id-ms-san-sc-logon-upn SAN
   contains a UTF8 encoded string whose value is that of the Directory
   Service attribute UserPrincipalName of the client account object, and
   the purpose of including the id-ms-san-sc-logon-upn SAN in the client
   certificate is to validate the client mapping (in other words, the
   client's public key is bound to the account that has this
   UserPrincipalName value).

   It should be noted that all Microsoft Kerberos realm names are domain
   style realm names and strictly in upper case.  In addition, the
   UserPrincipalName attribute is globally unique in Windows 2000 and
   Windows 2003.
----------------------

We would appreciate any comment if this text is helpful.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Liqiang(Larry)
Zhu
Sent: Monday, October 17, 2005 2:22 AM
To: [email-masked]
Cc: Paul Leach; Stefan Santesson
Subject: validating KDC certificates

Paul and at least another person from the list suggested that we need to
specify at least one way how to securely deploy PKINIT. Here we propose
to add an appendix describes just how this is done in windows vista.

---------------------------------------------------------------

Appendix C.  How to Securely Interoperate with Windows Vista

   Due to various constraints, CAs shipped with Windows Vista do not
   automatically issue KDC certificates with id-pksan SAN.  This section
   describes how to validate these KDC certificates.

   o  All PKINIT clients MUST verify that the issuer of the KDC
      certificate is authorized to issue KDC certificates for the target
      realm.  To accomplish this, for domain-joined machines, Windows
      Vista PKINIT clients verify that the issuer of the KDC certificate
      is present in the "NTAuth" system registry store (the NTAuth store
      is managed via the group policy mechansim for domain joined
      machines); For un-joined machines, Windows Vista PKINIT clients
      verify that the KDC certificate is path-validated to a trust
      anchor on the smartcard device itself.

   o  All PKINIT clients MUST verify that the KDC certificate is
      intended for the KDC of the target realm.  KDC certificates issued
      by Windows Vista CAs have the dNSName SAN containing only the
      domain name of the KDC and the intended purpose of these KDC
      certificates is restricted by the presence of the following two
      EKUs: id-pkkdcekuoid EKU and id-kp-serverAuth [RFC3280].  Note
      that all Microsoft Kerberos realm names are domain style realm
      names and they are strictly in upper case.  PKINIT clients can
      verify these KDC certificates as follows: the target realm name
      must match the value of the dNSName SAN in the KDC
      certificate and the id-pkkdcekuoid EKU must be present.
---------------------------------------------------------------

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 18 Oct 2005 22:27:36 +0200

This text is most useful for us other implementors. I somewhat dislike its
placement, but can live with it.

Its not better for the text to live in a diffrent document, in something
that can change. You might find that you want to add more stuff that you
need do to interroperat with windows vista ?

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Oct 2005 10:57:38 -0500

> placement, but can live with it.

I agree.

> need do to interroperat with windows vista ?

I suspect that this text will remain relevant for a few years, so at
least some of it belongs here and can be removed when PKINIT progresses.
A URL to a Microsoft document on implementation notes for PKINIT seems
like a good idea.