validating KDC certificates

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

validating KDC certificates

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

Reply | Threaded
Open this post in threaded view
|

RE: validating KDC certificates

Larry Zhu
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Liqiang(Larry)
Zhu
Sent: Monday, October 17, 2005 2:22 AM
To: [hidden email]
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.
---------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: validating KDC certificates

Love Hörnquist Åstrand

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


"Liqiang(Larry) Zhu" <[hidden email]> writes:

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Liqiang(Larry)
> Zhu
> Sent: Monday, October 17, 2005 2:22 AM
> To: [hidden email]
> 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.
> ---------------------------------------------------------------

attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: validating KDC certificates

Nicolas Williams
On Tue, Oct 18, 2005 at 10:27:36PM +0200, Love H?rnquist ?strand wrote:
> This text is most useful for us other implementors. I somewhat dislike its
> placement, but can live with it.

I agree.

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

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.

Reply | Threaded
Open this post in threaded view
|

Re: validating KDC certificates

Sam Hartman-5
In reply to this post by Larry Zhu
I find appendix c useful.