Subject: Principal for setclientid

From: [email-masked]
Date: Mon, 15 Jul 2002 10:50:43 -0400 (EDT)

Hi,

> I think your solution doesn't account for the case of auth-sys, which
> while deprecated, will continue to exist in some environments.  In those
> environments, there won't be any real principal to match and so there 
> is a choice of having no check for misconfiguration (multiple clients
> with the same client id), if you don't check on IP address.

The above suggests that, for Kerberos, the principal will be unique. I
have no problem with that, but I would have used "[email-masked]"
from all the clients in my domain, by default. Is this requirement that
a Kerberos principal be unique per client for setclientid stated anywhere
in the RFC? (I've currently got bis03 and will download bis04 soon, but
admit I haven't read it all.)

So, it sounds like it is still an open issue and I won't worry about it
until it gets resolved.

Thanks, rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 15 Jul 2002 08:42:31 -0700

> Spencer wrote: 
> On Mon, Noveck, Dave wrote:
> > I don't know of such a requirement, but I think people who are assuming
> > that the principal be used for this check are assuming that's the way
> > that clients will be configured.  Maybe they will and maybe they won't,
> > but the auth-sys case is clearer, using principal alone won't work.
> 
> The purpose of the principal check is to offer a minor check for
> denial of service.  Therefore, I don't see a problem with having all
> clients in a kerberos environment use the same principal.  This will
> prevent a regular kerberos authenticated user from running a user
> level client and sending a matching clientid to the server and
> interfering with a traditional client-kernel implementation.  The
> server will use the principal to verify that the request is "valid"
> for a previously registered clientid.

I see what you're saying.  I had concluded that this assumption was
operative from Peter who seemed to be saying the the CLID_INUSE error
would only be based on principal, in which case there would be no 
way to detect this kind of client-name misconfiguration at all.  However, 
maybe I've misunderstood his intentions as well.