Subject: RE: Feedback from PKINIT Review...

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 20 Apr 2004 09:32:55 -0700

Douglas E. Engert wrote:
> This is to strong. This gives the CA complete access to any principal
in the realm.
> The KDC MUST be able to reject any certificate for any reason. 

I agree. The KDC should have complete control. How about changing the
word "MUST" here to "MAY"?

Larry
-----Original Message-----
From: Douglas E. Engert [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2004 8:05 AM
To: Liqiang(Larry) Zhu
Cc: Eric Rosenfeld; Sam Hartman; [email-masked]
Subject: Re: Feedback from PKINIT Review...

"Liqiang(Larry) Zhu" wrote:
> 
> >  Perhaps Larry can propose the exact change that he'd like to see, 
> > as
> well as indicate whether he is OK with not
> > specifying the name type in PKINIT.
> 
> I am fine if we do not specify the name type in PKINIT. Here is the 
> description of the client name mapping that I came up with. The 
> difference might be rather small essentially, and mainly it is 
> emphasized in my version that the cname mapping is based on mostly the

> certificate, not the client name.
> 
> ======================================================================
> ==
> 3.2.2.  Validation of Client Request
> 
> << cut >>
> 
> KDC MUST map the client certificate in the signedAuthPack to a client 
> principal name as follows:
>     1.  If the KDC has its own unique mapping from the
>         certificate to a Kerberos name, it MUST use that name.
>     2.  Otherwise, if the KDC has its own mapping where the
certificate
>         is mapped to multiple Kerberos client names, the client name 
> in the
>         request MUST match with one of these names, and the KDC MUST
>         use the client name in the request.
>     3.  Otherwise, if the KDC does not have its own mapping from the
>         certificate to a Kerberos name, and if the certificate
contains a
>         SubjectAltName extension with a Kerberos name in the otherName
field,
>         the KDC MUST use that name.

This is to strong. This gives the CA complete access to any principal in
the realm.
The KDC MUST be able to reject any certificate for any reason. 

>         The otherName field (of type
>         AnotherName) in the SubjectAltName extension MUST contain the
>         following:
>               << krb5PrincipalName definition goes here >>
> 
> If the KDC is not able to map the client certificate to a client 
> principal name, it MUST return the KDC_ERR_C_PRINCIPAL_UNKOWN error 
> with no cname in the KRB_ERROR message.
> 
> When the client certificate is mapped successfully to a Kerberos name,

> the client name in the request MUST match this Kerberos name, or the 
> KDC MUST return the KDC_ERR_CLIENT_NAME_MISMATCH error. This error 
> message MAY contain the mapped Kerberos name in the cname field, and 
> there is no accompanying e-data.  The KDC MAY consider two Kerberos 
> names match if they are equivalent as determined by its local policy.
> ======================================================================
> ==
> 
> Thanks,
> 
> Larry
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Eric 
> Rosenfeld
> Sent: Friday, April 16, 2004 11:16 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: RE: Feedback from PKINIT Review...
> 
> Thanks for the response, Sam. It has been a while since we discussed 
> the need to require AD-INITIAL-VERIFIED-CAS. Would you please explain 
> why you believe it should be required?
> 
> Regarding Microsoft's cname issue, I agree that the name and name type

> don't need to be in PKINIT. Also, I don't quite understand how Larry's

> proposed text would actually be inserted into the current PKINIT-19 
> draft. Perhaps Larry can propose the exact change that he'd like to 
> see, as well as indicate whether he is OK with not specifying the name

> type in PKINIT.
> 
> Thanks,
> Eric
> 
> Eric S. Rosenfeld
> Project Director, PacketCable Security CableLabs
> 858 Coal Creek Circle
> Louisville, CO  80027-9750
> 
> Email: [email-masked]
> Phone: 303-661-3841
> Fax: 303-661-9199
> 
> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, April 16, 2004 11:55 AM
> To: Eric Rosenfeld
> Cc: [email-masked]
> Subject: Re: Feedback from PKINIT Review...
> 
> >>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:
> 
>     Eric> 3) Make the AD-INITIAL-VERIFIED-CAS optional.
> 
> I continue to object to this.
> 
>     Eric> 4) Address Microsoft's "blank" cname issue. Larry has
>     Eric> proposed the addition of a new name type
>     Eric> "NT-ENTERPRISE-X500-PRINCIPAL" to force name
>     Eric> canonicalization.
> 
> I continue to believe that removing this entirely and addressing in 
> referals is correct.  Larry proposed text that would allow for this.
> He also proposed discussing the specific name and name type in pkinit;

> I believe that is unnecessary.
> 
> In practice I wonder whether just sending a empty string as a single 
> component, or sending a name with no components is appropriate for 
> pkinit clients who don't know the mapping and are using the referals 
> draft.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 20 Apr 2004 17:27:19 -0400

This is getting a little silly.  You have already given the KDC complete 
control.
The KDC can do whatever it wants in case (1).  In case (2), it is 
limited only by
selecting from one of its choices.  In case (3), the KDC must use the name
specified by the CA assuming of course the certificate is accepted by 
the KDC.
If the certificate is not accepted by the KDC, then the KDC must not 
issue a
TGT.

As for whether or not the KDC should be trusting the CA, that is site 
policy.
If you cannot trust the administrator of the CA to issue certificates to 
your
clients which do not meet your local site policy, you should not be 
accepting
any certificates from the CA.

Jeffrey Altman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 20 Apr 2004 17:48:50 -0400

On Tuesday, April 20, 2004 17:27:19 -0400 Jeffrey Altman 
<[email-masked]> wrote:

> control. The KDC can do whatever it wants in case (1).  In case (2), it
> is limited only by selecting from one of its choices.  In case (3), the
> KDC must use the name specified by the CA assuming of course the
> certificate is accepted by the KDC. If the certificate is not accepted by
> the KDC, then the KDC must not issue a TGT.
>
> policy. If you cannot trust the administrator of the CA to issue
> certificates to your clients which do not meet your local site policy,
> you should not be accepting any certificates from the CA.

Note also that there is nothing in the text which prevents the KDC from 
choosing to issue TGT's for only a subset of valid principals.  It doesn't 
say a KDC must issue a ticket for a valid certificate, only that if it 
does, the cname must match the name in the cert.

---

From: Love <[email-masked]>
Date: Wed, 21 Apr 2004 00:55:10 +0200

Jeffrey Altman <[email-masked]> writes:

> As for whether or not the KDC should be trusting the CA, that is site policy.
> If you cannot trust the administrator of the CA to issue certificates to your
> clients which do not meet your local site policy, you should not be accepting

I may have to trust the CA to authenticate a user
 "this is Love Hörnquist Åstrand with SSN NNNNNN-XXXX from gov approved CA"
I may not trust the CA to give me authorization.
 "Love should be allowed to get initial ticket for lha/[email-masked]"

OtherName is authorization. I trust the CA because I have to, but they
shouldn't be allowed to do things agaist site policy.

MUST is too strong.

Love

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Apr 2004 20:36:04 -0400

I believe these three cases are distinct in practice.

I agree that case 1 and 2 could be combined.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Apr 2004 01:39:01 -0400

>shouldn't be allowed to do things agaist site policy.
Love:

I disagree with you in two respects.  First of all, give the fact
that the first two cases both provide for the KDC to pretty much
do anything it wants to based upon local policy; how can you say
that MUST is too strong.

Second, how is "OtherName" authorization data?  That is like saying
that an e-mail address provided in a subjectAltName is authorization
data.  Its not.  There is nothing in these certificates which are
providing authorization data.   "OtherName" is just that, a name.
In this case its a name which happens to be a Kerberos 5 Principal.
The fact that I authenticate as a principal name does not mean that
I am authorized to do anything. 

The question at hand is not whether the UNITED.NATIONS KDC MUST issue a
TGT in response to the presentation of a certificate with the name
[email-masked].  The question is "if the UNITED.NATIONS KDC" is
going to issue a TGT for a certificate which is bound to the principal
name "[email-masked]", what principal name should be issued to
the client.  Cases 1 and 2 state that the UNITED.NATIONS KDC may issue
any principal it likes based upon site policy.  Case 3 states that
if there is no local site policy and there is a Kerberos Principal
bound to the certificate that the bound name must be used if a TGT is
issued.  If the KDC does not want to issue a TGT with that name,
it must return an error.

How is this a problem?

Jeffrey Altman

---

From: Love <[email-masked]>
Date: Wed, 21 Apr 2004 11:27:15 +0200

> do anything it wants to based upon local policy; how can you say

see [1]

> I am authorized to do anything. 

But is authorization. take the example of dNSName and how https uses it.

> How is this a problem?

[1] You are assuming that mapping and apply acl is two diffrent steps.

But if there acl, how isn't there a mapping. I agree that the reverse isn't
true.

Love

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Apr 2004 11:44:45 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> Second, how is "OtherName" authorization data?  That is
    Jeffrey> like saying that an e-mail address provided in a
    Jeffrey> subjectAltName is authorization data.  Its not.  There is
    Jeffrey> nothing in these certificates which are providing
    Jeffrey> authorization data.  "OtherName" is just that, a name.
    Jeffrey> In this case its a name which happens to be a Kerberos 5
    Jeffrey> Principal.  The fact that I authenticate as a principal
    Jeffrey> name does not mean that I am authorized to do anything.

It's an assertion of a mapping from a name in the X.509 space to a
name in the Kerberos space.  Put another way, the certificate is a
capability authorizing anyone who can sign messages with the private
key associated with the cert to use that name in the Kerberos space.
Such a capability is an authorization instrument.