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

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 20 May 2005 18:33:26 +0100

All,

I confirm that I have posted the 00 draft named
draft-santesson-pkix-srvrr-00.txt and sent a follow-up mail to the PKIX
work group asking them to accept this as a WG item.

It would be helpful if people on this list, who have an interest of
seeing this work progress in PKIX in support of PKINIT, would post a
message to the PKIX list or alternatively the PKIX chairs (Stephen Kent
<[email-masked]> and
Tim Polk <[email-masked]>), expressing your support for defining this
new name form.

The proposed definition in the draft is:

2.  SRV RR otherName

   This section defines the SRVRRName as a form of otherName from the
   GeneralName structure in SubjectAltName.

   The SRVRRName if present MUST contain a Service Resource Record (SRV
   RR) formed according to RFC 2782 [N3].

   The use of a SRVRRName is OPTIONAL. The SRVRRName is defined as
   follows:

      id-on-sRVRRName   OBJECT IDENTIFIER ::= { id-on ? }

      SRVRRName ::= IA5String

I have however got several suggestions to change this to 

      SRVRRName ::= UTF8String

So my intention is to change this in the next draft.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 20 maj 2005 04:43
> To: [email-masked]
> Cc: Stefan Santesson
> Subject: PKINIT-26 changes: identifying the kdc certificates
> 
> Recently Stefan has proposed to define a Subject Alternative Name
> extension contains the DNS SRV records. Using this extension the
client
> can bind the KDC certificate to the KDC of the target realm.
> 
> Stefan is expected to publish his proposal shortly and request the
PKIX
> working group to accept his ID as a working group document.
> 
> Based on this development, we would like to withdraw our proposal of
using
> _Kerberos._tcp dNS name to identify KDC certificates.
> 
> Here is the updated section 3.2.4.
> 
> 
> 3.2.4  Receipt of KDC Reply
> 
> << cut >>
> 
>    In either case, the client MUST verify the signature in the
>    SignedData according to [RFC3852].  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 be validated
>    according to [RFC3280] and it MUST satisfy at least one of the
>    following requirements:
> 
>    1.  The client checks to see if the KDC's X.509 certificate
contains
>        a Subject Alternative Name extension [RFC3280] carrying an
>        AnotherName whose type-id is id-pksan (as defined in
>        Section 3.2.2) and whose value is a KRB5PrincipalName that
>        matches the name of the TGS of the target realm.
>    2.  If the client has a priori knowledge of the KDC's name or IP
>        address, it checks to see if the KDC's X.509 certificate
contains
>        a Subject Alternative Name extension [RFC3280] carrying a
dNSName
>        or an iPAddress.  If so, it checks to see if that name value
>        matches that of the KDC it believes it is communicating with,
>        with matching rules specified in [RFC3280].
> 
>    Future work within the PKIX working group is expected to define an
>    X.509 certificate extension that allows a certificate subject to be
>    associated with a DNS Service Resource Record.  This extension can
be
>    used to identify the KDC certificate when the KDC is discovered via
DNS
>    based on the domain style realm name, as specified in Section
7.2.3.2
>    of [CLAR].
> 
>    Based on local policy, the client MAY require that the KDC
>    certificate contains the EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:
> 
> << cut >>
> 
> 
> And in the security consideration section, I would propose to add the
> following text:
> 
> 
>    If the KDC certificate is identified using a dNS name or iPAddress,
>    and the same KDC host could provide services more than the KDC of
the
>    target realm, the client MUST ensure the KDC certificate is
intended
>    for the KDC of the target realm, for example by requiring the
>    presence of id-pkkdcekuoid KDC EKU.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 20 May 2005 12:28:30 -0700

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: "Stefan Santesson" <[email-masked]>
Date: Fri, 20 May 2005 21:52:49 +0100

Just clarifying that the DNS SRV RR name work in PKIX, if accepted, will
not be a new extension, just a new OtherName form in the existing SAN
extension.

Stefan Santesson

> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] On Behalf Of Sam Hartman
> Sent: den 20 maj 2005 12:21
> To: Liqiang(Larry) Zhu
<[email-masked]>
> writes:
is
> located via DNS SRV records.
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 23 May 2005 17:34:15 +0100

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

> [email-masked]] On Behalf Of Liqiang(Larry) Zhu
> Sent: den 20 maj 2005 12:29
> To: Sam Hartman
> Subject: RE: PKINIT-26 changes: identifying the kdc certificates
> 
>

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 May 2005 09:39:30 -0700

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

Stefan Santesson

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 23 May 2005 13:25:32 -0700

Shall we be explicit that the KDC is referred as the principal of AS,
not the server name in the AS-REQ?  

The name of TGS and the semantic of the TGS principal are well defined
but not for AS. Do we need to be explicit what is the principal
representing AS? Perhaps only in PKINIT we need to make this
distinction.

Is the text I just sent sufficient, or do you want to propose additional
changes?

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, May 23, 2005 1:16 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; Stefan Santesson; [email-masked]
Subject: Re: PKINIT-26 changes: identifying the kdc certificates

On Mon, May 23, 2005 at 01:12:11PM -0700, Liqiang(Larry) Zhu wrote:
> I do not understand then. PKINIT clients only talk to the AS, why you
> want TGS instead?

There's no such thing as an AS name.  The KRB5PrincipalName defined in
the PKINIT I-D has a principal name and a realm name, neither being
optional, so, what to use as the name for the KDC?  The TGS name is
natural (and anyways, it's the server name used in most AS-REQs).

> In any case, can you double check if the updated text (after the
removal
> of dNSName/IPAdress, and _kerberos._tcp, and DNS SRV othername etc)
> looks good to you?

I thought you proposed getting rid of the _kerberos._tcp text.

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 25 May 2005 09:40:32 -0700

I'd like to see the text below contain an example of what the value of
the AnotherName with type-id ip-pksan should be. (In addition to the
reference to section 7.3 of [CLAR].) 

> [mailto:[email-masked]] On Behalf Of 
> Jeffrey Altman
> Sent: Tuesday, May 24, 2005 1:23 PM
> To: [email-masked]
[snip]
> >    the KDC's X.509
> >    certificate MUST contain a Subject Alternative Name extension
> >    [RFC3280] carrying an AnotherName whose type-id is id-pksan (as
> >    defined in Section 3.2.2) and whose value is a 
> >    KRB5PrincipalName that
> >    matches the name of the TGS of the target realm (as defined in
> >    Section 7.3 of [CLAR]).

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 25 May 2005 09:45:09 -0700

> Larry:
> I think this text is fine as it stands provided that the 
> working group agrees that the purpose of this text is to 
> provide a loophole such that individual vendors can choose to 
> implement their own verification mechanisms.
[Paul Leach] Isn't the main purpose to make the mechanism described for
authenticating the KDC be mandatory-to-implement? Secondarily, to allow
for standardized extensions later? And third in priority to allow vendor
specific extensions as long as the requirement that "the public key used
to verify the KDC's signature is bound to the KDC of the target realm"
is met?

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 25 May 2005 13:25:43 -0700

The current draft calls for option 1 but it based on local policy.

If option 1 is not required, it is interpreted as option 2.

We have been talking about option 3 at Minneapolis, but we would prefer
the new PKIX othername format Stefan recently proposed.  We would like
to drop option 3 as the result.

I agree it is problematic to say "EKU may be present.  If present it
must contain the pkinit KeyPurposeId", this is not inline with RFC3280.

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 11:57 AM
To: [email-masked]
Cc: Paul Leach; Liqiang(Larry) Zhu; [email-masked]; Stefan
Santesson

I think I'm in agreement with Martin mostly.  I tend to believe
mandating the presence of the pkinit KeyPurposId in the EKU is
probably undesirable even if we define such anKeyPurposeId.  (Larry
disagrees
here I believe; he wants to do something kind of complicated.)

One area where I disagree with Martin is that I don't believe the
presence or absence of the EKU should influence the success or failure
of the verification except as provided for by 3280.

Restating to be more concrete, here are things I think would be
reasonable:

* EKU must be present and must contain pkinit KeyPurposeId (Martin and I
both think this creates interoperability challenges, but I at least
think it would be reasonable for the WG to go down this path).

* EKU may be present.  If it is present then it must either contain
  the pkinit KeyPurposeId or the any purpose ID.  If it is not present
  then it is not a problem for the verification.

* EKU may be present.  If dnsname is used then EKU must be present and
  must contain the pkinit KeyPurposeId.  I think this is what Larry
  wants.  I consider it overly complicated but think it is something
  the WG may want to adopt.

What I think would be problematic is:

* EKU may be present.  If present it must contain the pkinit
    KeyPurposeId.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 25 May 2005 16:24:44 -0700

The current text says if you have already verified the binding, you can
skip the check for the Kerberos TGS name; otherwise, it is REQUIRED to
process the Kerberos TGS name. 

IMO, the current text in -26 is sufficient.

-- Larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 3:12 PM
To: Sam Hartman; [email-masked]
Cc: Paul Leach; Liqiang(Larry) Zhu; [email-masked]; Stefan
Santesson

On Wednesday, May 25, 2005 02:57:12 PM -0400 Sam Hartman 
<[email-masked]> wrote:

> disagrees here I believe; he wants to do something kind of
complicated.)
> both think this creates interoperability challenges, but I at least
think
> it would be reasonable for the WG to go down this path).
>

For the moment, I'll speak not as chair, but as an individual network 
operator using Kerberos and planning to eventually deploy PKINIT.  From 
that viewpoint, my concern is pretty simple:

It is common for the same name to be used for several services, managed
by 
different groups.  For example, the name 'CS.CMU.EDU' names a DNS
domain, 
and a Kerberos realm, and a mail domain, and may name a web server.  All
of 
these are managed by different people, with varying levels of 
communication, trust, and accountability to each other.  Particularly,
the 
people who run web servers, the people who run the mail servers, and the

people who manage DNS contents are all _not_ trusted to manage Kerberos.

They don't get to log in to the KDC's, and they certainly don't get to 
issue tickets.  I don't want any of those people to be able to
impersonate 
the KDC, and I don't want any insecurities in the services they run to 
compromise Kerberos.

What that means, I think, is that it MUST NOT be possible for any
Kerberos 
client - particularly one I do not control - to become confused into 
thinking that a certificate issued for one of those other services
belongs 
to an entity which is allowed to act as a KDC.  It's not good enough to
say 
"configure your Kerberos clients to require the EKU", because I don't 
control all the clients that might want to talk to my realm.  And, it's
not 
good enough to say "don't give those other services certs without a 
restrictive EKU", because I don't control the well-known CA's and I may
not 
have any ability to prevent such a cert from being requested or issued. 
This is especially true since the default policy of many CA's is to
issue 
certs with no EKU.

To accomplish that, I think we need to REQUIRE that clients accept a
KDC's 
certificate only there is some indication that it is intended for use
with 
Kerberos.  I can think of several possible such indications:

- Presence of the pkinit KDC keyPurposeId
- Presence of the pkinit KDC keyPurposeId or the any purpose ID
- Presence of an appropriate KerberosPrincipalName SAN
- Presence of stefan's proposed SRV SAN, with appropriate contents
- Client has been pre-configured with the KDC's cert or public key
- Some vendor-specific extension

I think we need to pick at least one mechanism (one of these or some
other 
proposal) to REQUIRE clients to implement.  We can specify more than
one, 
but there needs to be at least one required-to-implement method, and I 
think there needs to be a requirement that certificates not satisfying
any 
method known to the client be rejected.

-- Jeff

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 25 May 2005 20:18:50 -0700

> Sent: Wednesday, May 25, 2005 11:02 PM
> To: Paul Leach
> Cc: Jeffrey Hutzelman; [email-masked]; Liqiang(Larry) 
> Zhu; [email-masked]; Stefan Santesson
>
[snip]
> 
> This isn't something I feel strongly about though.  I'd just 
> like the WG to carefully consider what it is doing and not be 
> different than other PK applications unless it needs to.

Your point is well taken. It is best to be conservative in such matters
-- the well-trod path often avoids dangers because the first passers-by
created it so as to do precisely that -- and later ones may be unaware
of the dangers of wandering off it.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 26 May 2005 08:21:04 -0700

For the interop requirements we need to make sure that a KDC certificate
that contains the Kerberos TGS name encoded as the KerberosPrincipal
otherName MUST work with *all* compliant clients.

The current text in draft -26 accomplishes that. Do you agree with me on
that?

-- Larry

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 7:03 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; Paul Leach; [email-masked];
Stefan Santesson

    Liqiang(Larry)> If I already pre-shared the KDC's public key with
    Liqiang(Larry)> the client, why am I required to process the
    Liqiang(Larry)> Kerberos TGS otherName? 

I don't think you should be required to do so.  Who is saying you
should?

Or worse, if it is not
    Liqiang(Larry)> present, do I have to require the Kerb TGS name be
    Liqiang(Larry)> present?

No I don't think so.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 27 May 2005 07:41:36 -0700

Martin Rex wrote:
> If some clients are required to verify field, they will fail if the 
> contained information is incorrect.

-26 guarantees that a KDC certificate that contains a correct TGS
Kerberos name MUST work with *all* clients.

I would interpret what you need is that a KDC certificate that contains
an *incorrect* TGS Kerberos name MUST NOT work on *all* clients.

Can you confirm this is your intention?

> Probably Nico's suggestion to make two verification procedures
mandatory
> to implement is the way to go: 

I would not object to mentioning that one can pre-configure KDC
certificates with the client, but perhaps that can go into the security
consideration section?

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, May 27, 2005 7:24 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]; Paul
Leach; [email-masked]; Stefan Santesson
Subject: Re: PKINIT-26 changes: identifying the kdc certificates

Liqiang\ wrote:
> 
> If I already pre-shared the KDC's public key with the client, why am I
> required to process the Kerberos TGS otherName? Or worse, if it is not
> present, do I have to require the Kerb TGS name be present?
> 
> I am ok to say if the TGS Kerberos other name is present in the KDC's
> x.509 certificate, and then it must match with the TGS of the target
> realm, but not more than that. 

The latter is what I have been asking for.

As I outlined, the issue is interoperability.  If some clients are
required to verify field, they will fail if the contained information
is incorrect.  For consistency, all compliant clients should be
required to fail in this situation.  Effectively I want clients to
process the information as "critical" whenever a cert contains them.

The "Kerb TGS name not present" case is different, as I described
in a previous Email.  The verification can not be performed at all.
This should cause clients to consider the certificate invalid for
this purpose, unless there is either there is a local verification
procedure available that confirms the pupose of the certificate
or a future verification procedure based on other certificate
attributes becomes available (and is standardized).

Probably Nico's suggestion to make two verification procedures mandatory
to implement is the way to go:  (1) based on (a) particular attribute(s)
of the certificate and (2) based on locally pre-configurable KDC
certificates.

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 27 May 2005 12:29:23 -0700

Martin Rex wrote:
> Confirmed, but I would write it as "MUST FAIL on *all* clients".

Ok, I would need to ask this working group if it is reasonable to
specify what MUST fail, in addition to specifying what MUST work.

I would also ask the working group if it is reasonable to require all
compliant clients to support pre-shared KDC certificates. I wonder if
this is an unnecessary burden for vendors who do not need to do this.

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, May 27, 2005 8:00 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]; Paul

> Can you confirm this is your intention?

Confirmed, but I would write it as "MUST FAIL on *all* clients".

> certificates with the client, but perhaps that can go into the
security

As indicated, the possibility to preconfigure KDC client certs as
trusted on the clients was intended to be a required to implement
feature, and as such it would need to appear in the spec where
it actually applies, not just in the security considerations section.

The underlying question was whether, for the sake of interoperability,
we care about the problems that some sysadmins are going to run into
if they try to get the new certificate attributes (EKU, Kerberos
Principal
Name, whatever) into their KDC certificate(s):
 - some CA software may not support it
 - some commercial CAs may have issues adding these attributes
 - installed base PKI software which chokes on the attributes or
   is unable to retrieve/check it.

-Martin