Subject: RE: Feedback from PKINIT Review...

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 19 Apr 2004 16:14:38 -0700

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Apr 2004 15:59:37 +0200 (MET DST)

Liqiang wrote:
> 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.

The last sentence sounds extremely broken and should be entirely removed.

To combine a "MUST match" with a "the KDC may do whatever it wants"
is a contradiction and absolutely unsuitable for an IETF spec.

I thought the "MUST match" is there because Kerberos clients are
used to compare request and response and should continue to do so.
A "MUST match" is a promise that clients may continue to compare
request and response and fail if there is no match.

If the KDC should be free to reply whatever it feels like as the
last sentence suggests, then the client can not compare anything
and must blindly believe whatever the KDC says (which probably
opens vulnerability with rogue KDCs).  However in that case the
MUST match is misleading, because nobody else besides the KDC
that does the match can verify the match.

If this part of the spec is supposed to support
 (a) case-insensitive principal name matching
and
 (b) name-canonicalization

then the spec should (1) clearly spell that out and (2) indicate
when either one happened in contrast to traditional EXACT principal
name matching in the existing Kerberos standards.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 20 Apr 2004 10:04:39 -0500

"Liqiang(Larry) Zhu" wrote:
>         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

-- 

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Apr 2004 14:24:55 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Liqiang wrote:
    >>  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.

    Martin> The last sentence sounds extremely broken and should be
    Martin> entirely removed.

    Martin> To combine a "MUST match" with a "the KDC may do whatever
    Martin> it wants" is a contradiction and absolutely unsuitable for
    Martin> an IETF spec.

I agree with Martin that this text needs work.  However I think I see
what Larry is trying to do.

For example the Microsoft KDC considers names differing only in case
to be the same.

Similarly he wants to enable extensions such as referals to allow
broader matching.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Apr 2004 14:19:12 -0400

Larry, I mostly agree with this proposal, although it seems nothing
like your previous proposal.  My understanding is that your previous
proposal was to use text similar to that in clarifications.  The KDC
MUST match unless some protocol extension allows it to do otherwise.

--Sam