Subject: pkinit and cname optionality

From: [email-masked] (Sam Hartman)
Date: Fri, 19 Mar 2004 14:11:52 -0500 (EST)

I'm sorry it has taken me so long to send this out.  At IETF 59 I
indicated I'd need to think about whether having the cname field be
optional in the pkinit request was a good idea or not.

The main thing I've noticed while thinking about this is that the
security implications of having a way to have the KDC select the
client's cname in pkinit are exactly the same as the security
implications of name canonicalization in the referals draft.

At first I wasn't sure of this.  When we have discussed security for
referals in the past, the main issue with client name canonicalization
has been the fact that the KDC is not trustable.  That means that the
client cannot trust the mapping from the alias to the canonical name.

But there's an additional attack against pkinit.  If one certificate
maps to multiple client names then an attacker can influence which
name is chosen potentially by inserting a cname in a request that did
not have a cname.  If the client does not mandate that the cname not
change, then the client  cannot currently detect this attack.

But it turns out the same attack exists against regular name
canonicalization.  Consider if [email-masked] and
[email-masked] have the same credentials (password).  This might be
a reasonable thing for me to do if I always log into workstations that
have a trust level high enough to use [email-masked]
credentials, and the existence of two accounts is simply for me to
select how much privilege I want at a given time.  An attacker can
replace the cname in my outgoing request and with the NC bit set, my
client will hapilly accept the difference.

Both accounts are authorized to log in.  I just may end up with more
or less privilege than I expected.

So I wonder if the pkinit issue isn't better left to the referals
draft so we can make forward progress on pkinit?

We've committed to having a solution to the referals problem.  It
seems clear that no matter what we do in that space, Microsoft is
going to implement the name canonicalization they already do.  It also
seems likely that any name canonicalization we implement will look
very similar to the referals draft.  Would relying on name
canonicalization be sufficient to allow Microsoft to not specify the
name in the AS request for pkinit when desired?  There's still the
issue of what string (if any) goes in the cname field, but it should
avoid the protocol issue for pkinit.

Thoughts?

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Mar 2004 18:05:14 -0600

> implications of name canonicalization in the referals draft.

This is my analysis as well.

> draft so we can make forward progress on pkinit?

I think so.

> avoid the protocol issue for pkinit.

This reminds me, if we're to do this we need to cover the Martin Rex
name-based authorization problems.  That's kinda tough since it means
being able to canon user principal names as TGS-REQ target principals
and it means having to have Kerberos initiator credentials in order to
do GSS_Canonicalize_name() (perhaps that API should have had an input
credential handle for this).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sat, 20 Mar 2004 02:17:37 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> This reminds me, if we're to do this we need to cover the
    Nicolas> Martin Rex name-based authorization problems.  

Agreed.

    Nicolas> That's
    Nicolas> kinda tough since it means being able to canon user
    Nicolas> principal names as TGS-REQ target principals and it means
    Nicolas> having to have Kerberos initiator credentials in order to
    Nicolas> do GSS_Canonicalize_name() (perhaps that API should have
    Nicolas> had an input credential handle for this).

Disagree on both counts.  We need to handle Martin's objections
somehow, but I don't think this is the only solution and it's not the
solution I prefer.

I do not wish to confuse this issue with pkinit so I'll wait until
pkinit is resolved to discuss name based authorization.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 20 Mar 2004 12:10:22 -0600

> somehow, but I don't think this is the only solution and it's not the

It isn't the solution I prefer either.

> pkinit is resolved to discuss name based authorization.

Fair enough.

---

From: Brian Tung <[email-masked]>
Date: Mon, 22 Mar 2004 10:13:53 -0800

> avoid the protocol issue for pkinit.

I think that is an acceptable course of action.  I'll wait a bit to
see if MS has anything to add.

b