Subject: RE: PKINIT-26 changes: identifying the kdc certificates

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 23 May 2005 18:03:14 +0100

I would suggest that the following change would make the requirement
more clear and testable:

Old text:
   Unless the client can otherwise
   prove that the public key used to verify the KDC's signature is bound
   to the target KDC,  the KDC's X.509 certificate MUST satisfy at least
   one of the following two requirements:

Proposed new text:
   The client MUST determine that the public key used to verify the
KDC's
   signature is bound to the target KDC. As means of determining this
   property the client MAY check that the KDC's X.509 certificate
satisfies
   one of the following conditions:

... and then provide the list of explicit examples.

/Stefan

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 23 maj 2005 09:40
> To: Stefan Santesson; Sam Hartman
> Cc: [email-masked]
> Subject: RE: PKINIT-26 changes: identifying the kdc certificates
> 
> The -25 text says "Unless the client can otherwise
>    prove that the public key used to verify the KDC's signature is
bound
>    to the target KDC," this certainly implies if the client can use
the
> binding comes from x.509 certificate itself.
> 
> Do you think the current text is strong enough to allow SRV RR name
> format? I think Sam pointed out you might want to add some text to
define
> the pkinit use explicitly.
> 
> In any case, text change suggestions/proposals are more than welcome.
I
> myself do not feel the need of additional changes.
> 
> -- larry
> 
> 
> -----Original Message-----
> From: Stefan Santesson
> Sent: Monday, May 23, 2005 9:34 AM
> To: Liqiang(Larry) Zhu; Sam Hartman
> Cc: [email-masked]
> Subject: RE: PKINIT-26 changes: identifying the kdc certificates
> 
> I think the current text needs to be updated to allow binding to any
name
> of the kdc which can be supported by the kdc certificate and accepted
by
> the client.
> 
> Use of SRV RR should automatically be allowed but it doesn't need to
be
> explicitly stated.
> 
> 
> Stefan Santesson
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:owner-ietf-krb-
> > [email-masked]] On Behalf Of Liqiang(Larry) Zhu
> > Sent: den 20 maj 2005 12:29
> > To: Sam Hartman
> > Cc: [email-masked]; Stefan Santesson
> > Subject: RE: PKINIT-26 changes: identifying the kdc certificates
> >
> >
> > I can drop the PKIX paragraph unless Stefan proposes text acceptable
by
> > this working group. The current text in PKINIT already allows future
> > extensions provided by PKIX or other IETF working groups.
> >
> >
> > For the dNSName and iPAddress extension, I would be happy to drop it
> > completely as well.
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Sam Hartman
> > Sent: Friday, May 20, 2005 12:21 PM
> > To: Liqiang(Larry) Zhu
> > Cc: [email-masked]; Stefan Santesson
> > Subject: Re: PKINIT-26 changes: identifying the kdc certificates
> >
> > >>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu
> > <[email-masked]> writes:
> >
> >     Liqiang(Larry)>    In either case, the client MUST verify the
> >     Liqiang(Larry)> signature in the SignedData according to
> >     Liqiang(Larry)> [RFC3852].  Unless the client can otherwise
prove
> >     Liqiang(Larry)> that the public key used to verify the KDC's
> >     Liqiang(Larry)> signature is bound to the target KDC, the KDC's
> >     Liqiang(Larry)> X.509 certificate MUST be validated according to
> >     Liqiang(Larry)> [RFC3280] and it MUST satisfy at least one of
the
> >     Liqiang(Larry)> following requirements:
> >
> >     Liqiang(Larry)>    1.  The client checks to see if the KDC's
X.509
> >     Liqiang(Larry)> certificate contains a Subject Alternative Name
> >     Liqiang(Larry)> extension [RFC3280] carrying an AnotherName
whose
> >     Liqiang(Larry)> type-id is id-pksan (as defined in Section
3.2.2)
> >     Liqiang(Larry)> and whose value is a KRB5PrincipalName that
> >     Liqiang(Larry)> matches the name of the TGS of the target realm.
> >
> >
> >     Liqiang(Larry)> 2.  If the client has a priori knowledge of the
> >     Liqiang(Larry)> KDC's name or IP address, it checks to see if
the
> >     Liqiang(Larry)> KDC's X.509 certificate contains a Subject
> >     Liqiang(Larry)> Alternative Name extension [RFC3280] carrying a
> >     Liqiang(Larry)> dNSName or an iPAddress.  If so, it checks to
see
> >     Liqiang(Larry)> if that name value matches that of the KDC it
> >     Liqiang(Larry)> believes it is communicating with, with matching
> >     Liqiang(Larry)> rules specified in [RFC3280].
> >
> > My preference is that this option be dropped.  If it is retained I
think
> > we need explicit text mentioning that it should not be used if the
KDC
> > is located via DNS SRV records.
> >
> >     Liqiang(Larry)>    Future work within the PKIX working group is
> >     Liqiang(Larry)> expected to define an X.509 certificate
extension
> >     Liqiang(Larry)> that allows a certificate subject to be
associated
> >     Liqiang(Larry)> with a DNS Service Resource Record.  This
> >     Liqiang(Larry)> extension can be used to identify the KDC
> >     Liqiang(Larry)> certificate when the KDC is discovered via DNS
> >     Liqiang(Larry)> based on the domain style realm name, as
specified
> >     Liqiang(Larry)> in Section 7.2.3.2 of [CLAR].
> >
> > This text requires a normative reference to that extension.
> > Personally I think that it is premature to mention the PKIX work at
> > all.  If you plan to mention the pkix work and have it be useful for
> > pkinit you must either:
> >
> > 1) normatively reference it in the pkinit spec
> >
> > 2) Define the pkinit use in another document--possibly the document
that
> > defines the name form in pkix.
> >
> >
> >
> >

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 May 2005 12:11:32 -0500

>    signature is bound to the target KDC. As means of determining this
                                      ^^^
				      s/KDC/realm name/ or TGS name.

> ... and then provide the list of explicit examples.

There must be at least one REQUIRED, practical method.  The use of SRV
RR othernames can't be part of this unless we wish to delay PKINIT, and
I don't.  Besides, will CAs will support SRV RR othernames soon?  If
not, forget about it -- let the use of SRV RR othernames for this be
specified in a separate document.

Nico
--