Subject: Re: Feedback from PKINIT Review...

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Apr 2004 16:40:39 -0500

>>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:
    Eric> 1) OCSP - The latest draft defines a tunneling mechanism for
    Eric> OCSP. OCSP could be used in different ways, so the use of
    Eric> OCSP really should be separate from OCSP, especially a
    Eric> tunneling mechanism as defined in the draft. We are
    Eric> concerned that brand new functionality is being added to a
    Eric> draft that we are trying to move to last call. OCSP support
    Eric> was not agreed upon at the interim meeting (it was only
    Eric> decided that Microsoft would provide OCSP feedback), and
It was my understanding that this feedback would take the form of suggestions on how to add this support  to the draft.

    Eric> 
    Eric> certainly a tunneling mechanism was not discussed. It seems
    Eric> like the right way to approach this issue would be to remove
    Eric> OCSP from PKINIT, and turn it into a separate draft.
What do we lose by doing that?  How much time pressure is Microsoft
under?  Do we have parties interested in handling the text as a
separate draft?

    Eric> 3) There is no need to make the AD-INITIAL-VERIFIED-CAS data
    Eric> type (and the InitialVerifiedCAs ASN.1 object) a MUST. This
    Eric> was an issue that I objected to at the interim meeting, but
    Eric> shelved my objections in order to make progress at the
    Eric> meeting. The proposed text has confirmed my original
    Eric> concern. I would really like to see this data type be made
    Eric> optional.

Your concern was that this data type would be hard to implement for
servers?  It seems that your implementation could have a constant
string for this data.

I disagree that there is no need for this data type to be a must.
Without this information provided to clients, clients cannot determine
what trust to place in the authentication.  This is also true for
application servers.

Given that transited realms are a MUST, this should also be a MUST.

    Eric> 4) Still need to define the "blank" cname that Microsoft
    Eric> requested. It is currently defined as [special "blank"
    Eric> name], and this needs to be resolved before the draft can be
    Eric> posted.

I still consider the issue of whether this is allowed open.
I'm waiting for Larry to reply to my comment about moving this to referals.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 2 Apr 2004 18:27:05 -0800

Sam Hartman wrote:
> I'm waiting for Larry to reply to my comment about moving this to
referrals. 

We are fine with moving it to referrals.

Douglas E. Engert wrote:

>      Client name canonicalization problems (Nico Williams)
>          Resolved recently. Believe there is consensus. Yes; clients
need to include 
>          a name in PKINIT AS requests. Name returned by the KDC must
match. 

We would also like to request the authors not to add restrictions that
explicitly prohibit NC, if such restrictions do not improve security.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Thursday, April 01, 2004 1:41 PM
To: Eric Rosenfeld
Cc: [email-masked]
Subject: Re: Feedback from PKINIT Review...

    Eric> 1) OCSP - The latest draft defines a tunneling mechanism for
    Eric> OCSP. OCSP could be used in different ways, so the use of
    Eric> OCSP really should be separate from OCSP, especially a
    Eric> tunneling mechanism as defined in the draft. We are
    Eric> concerned that brand new functionality is being added to a
    Eric> draft that we are trying to move to last call. OCSP support
    Eric> was not agreed upon at the interim meeting (it was only
    Eric> decided that Microsoft would provide OCSP feedback), and It
was my understanding that this feedback would take the form of
suggestions on how to add this support  to the draft.

    Eric> 
under?  Do we have parties interested in handling the text as a separate
draft?

Your concern was that this data type would be hard to implement for
servers?  It seems that your implementation could have a constant string
for this data.

I still consider the issue of whether this is allowed open.
I'm waiting for Larry to reply to my comment about moving this to
referals.

---

From: "Eric Rosenfeld" <[email-masked]>
Date: Fri, 16 Apr 2004 12:16:09 -0600

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: Sam Hartman <[email-masked]>
Date: Fri, 16 Apr 2004 14:24:54 -0400

Here are my previous comments.  Most of these are still outstanding.

Subject: Re: Feedback from PKINIT Review...
From: Sam Hartman <[email-masked]>
To: "Eric Rosenfeld" <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 01 Apr 2004 16:40:39 -0500

    Eric>

---

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

Note that under the current framework and using my proposed text, an
empty client name in the request would cause a
KDC_ERR_CLIENT_NAME_MISMATCH to be returned and the client should retry.
This might be less efficient, but it enables the client to get the
mapped client principal name securely. It is possible that we can
improve the efficiency problem in the referral draft.

Larry	
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Liqiang(Larry) Zhu
Sent: Monday, April 19, 2004 4:15 PM
To: Eric Rosenfeld; Sam Hartman
Cc: [email-masked]
Subject: RE: Feedback from PKINIT Review...

>  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,
Eric

Eric S. Rosenfeld

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

 

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.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 20 Apr 2004 11:08:24 -0700

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

I think you are right; we can remove the last sentence completely.  My
clause #2 already covers NC and case-insensitive name matching
(therefore it allows the referral draft); The last sentence was added
for clarification.

This is because you can consider, for example, account names that differ
only in case are automatically-duplicated equivalent accounts, and a MS
KDC will map the client certificate to all the corresponding accounts
that differ only in case. The same thing is applicable to NC. 

BTW, I really think case-insensitivity is just a special case of NC,
although this has not been established before.

Thanks,

Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, April 20, 2004 7:00 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Feedback from PKINIT Review...

> 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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 20 Apr 2004 11:33:20 -0700

Sam Hartman wrote:
> The KDC MUST match unless some protocol extension allows it to do
otherwise.

this works too or it is perhaps more explicit therefore better. 

Larry

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

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