Subject: RE: Proposed inclusion of TGS referrals in Kerberos-revisions

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 17:51:02 -0700

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 5:37 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Proposed inclusion of TGS referrals in Kerberos-revisions
> 
> 
> "John Brezak" <[email-masked]> writes:
> > d) If the KDC gets a request with the "allow-referrals" set in a 
> > TGS-REQ, it will use the server realm as a "hint" in locating the 
> > specificed cname in its KDB. If a principal is found, it 
> will produce 
> > a ticket for that principal and return it in a TGS-REP. If the 
> > principal is not found, it will return a referral TGT to a "closer" 
> > realm for the client to retry the TGS-REQ. The client will 
> then retry 
> > the TGS-REQ to the realm of the referral TGT using the cross-realm 
> > referral TGT in the PA-AP-REQ and the original sname.
> 
> And I'll bring up my "gnuftp" example again. :-)

Isn't this relevant to name-canonicalization? The proposal for referrals
discards
the notion of canonical names or aliases for principals.

> 
> To recap: What if the name in the remote realm's database 
> isn't the same as in the local realm, because of convenience 
> aliases like "gnuftp.mydomain.com"->"ftp.gnu.org", that are 
> easy and handy to implement in DNS, and IMHO shouldn't be 
> incompatible with authentication?  ("You lose" isn't a 
> desirable answer.)
> 
> We could probably solve that one later, but if the basic 
> referral mechanism makes it difficult to do in a way that 
> assures the client that no man-in-the-middle altered or 
> removed the alternate principal name we tack on later in some 
> unprotected field, it's going to be a hassle.
> 
> On the other hand, if we're going to use an additional flag 
> to enable referrals, and describe how clients wanting 
> referrals should deal with servers not implementing them, we 
> could do the whole thing, including a protected alternate 
> principal name, without big backward-compatibility issues....

If the local realm (MYDOMAIN.COM) gets a sname of "gnuftp.mydomain.com"
it
could find a special principal entry in its KDB that says to go to
"GNU.ORG" and
ask for "ftp.gnu.org".

This is a derivative of name-canonicalization and is separate from
referrals as
proposed. The KDC would return the alternate principal name in a ticket
extension (TE)
in the referral ticket. Then the client would use the name in the TE to
ask the
realm (also in the TE). The TE needs to be bound to the ticket.

This would use the referral TGT to convey the alternate principal name
in the TE.

> Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 May 2001 23:22:36 -0400

> the notion of canonical names or aliases for principals.

If I understand correctly, what you're proposing is a trimmed down
version of the name canonicalization stuff that had been in the
revisions. I think this whittled down TGS referrals proposal is related
to name canonicalization.

I also think all of it (the proposal that had been in the revisions)
should be included in the revisions, but I'm not an implementor. I
promised to summarize my case that GSS is not affected by Kerberos name
canonicalization, and failed to deliver -- time constraints. If there's
still time... But then, this should be your (John Brezak's) job :) -- I
should probably stay out of it.

Referrals are a form of name canonicalization.

And there is a certain symmetry between name canonicalization in
AS_REPs and TGS_REPs. You'll want it all in time :)

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: 21 May 2001 17:42:12 -0400

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

    Nicolas> On Wed, May 16, 2001 at 05:51:02PM -0700, John Brezak
    Nicolas> wrote:
    >> Isn't this relevant to name-canonicalization? The proposal for
    >> referrals discards the notion of canonical names or aliases for
    >> principals.

    Nicolas> If I understand correctly, what you're proposing is a
    Nicolas> trimmed down version of the name canonicalization stuff
    Nicolas> that had been in the revisions. I think this whittled
    Nicolas> down TGS referrals proposal is related to name
    Nicolas> canonicalization.

No, I think what we were trying to do is split this into bite-sized
chunks that we can all understand.

The referals independent of canonicalization are likely something that
we can all agree to.  I thought we had convinced Ken that his gnuftp
concern was independent of referals but apparently I am confused.

I believe we decided that TGS canonicalization could mostly be
supported with aliases in the KDC database and there was no reason
that the KDC couldn't return a ticket for the same alias the user
asked for.  

I believe AS canonicalization (client canonicalization) is still an
open issue.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 May 2001 10:33:53 -0400

> concern was independent of referals but apparently I am confused.

TGS referrals are a form of name canonicalization. If you allow TGS
referrals, you might as well allow name canonicalization in TGS
exchanges that do not involve referrals.

> that the KDC couldn't return a ticket for the same alias the user

Yes, of course. That is how ActiveDirectory does it, at least when DNS
is run inside AD anyways. In fact, if I understand how AD works in this
area, AD will canonicalize service princ names in TGS REQs if the client
requested canonicalization (the AD service princ name canonical form is
just the fully qualified hostname@REALM, with no service instance, I
think); for clients that do not request canonicalization then, IF the
service principal name in the request is not canonical AND it is a
known alias of a canonical name, THEN AD returns a ticket for the
service princ name requested using the key of the canonical service
principal.

> I believe AS canonicalization (client canonicalization) is still an

Well, the only bit of principal name canonicalization in AS exchanges
that has been argued and argued is the bit about AS referrals, the issue
being that the referral, like all AS errors, cannot be validated
directly.

So you could even accept principal name canonicalization in AS
exchanges... as long as you leave AS referrals out of the spec there
may be no argument.

I think that having a [secure] canonicalization service for service
principal names, being used primarily as targets in TGS requests, would
be a very useful thing to users generally. Whereas user principal name
canonicalization is not as useful because users (and services, when they
act as clients) can be expected to *know* their own names.

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Tue, 22 May 2001 12:29:57 -0700 (PDT)

> act as clients) can be expected to *know* their own names.

- Actually, this very issue came up in a meeting at work today.
We would very much like to allow users not to need to know their
own principals. Ideally, we'd like the kerberos principal name
to be a char string version of the unix user id. You can do
a lot in unix without ever knowing your numeric unix userid.
Basically we are running out of usable 8 char unix usernames,
since we have a policy of no username reuse.

- Booker C. Bense

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 May 2001 16:06:28 -0400

> since we have a policy of no username reuse.

Eh, well, how do they log in? As firstname.lastname?, which is then
mapped to a Unix username? Yes, principal name canonicalization in
AS_REQs can help with that :)

I can certainly see the value of being able to do such aliasing, but,
you'd need your system software (/bin/login, xdm, PAM, NT GINA, ...) to
support that. Windows [2000] certainly supports that, and so do several
Unix-type OSs (Solaris, FreeBSD are two that do).

> - Booker C. Bense

Cheers,

Nico
--

---

From: Russ Allbery <[email-masked]>
Date: 22 May 2001 16:36:53 -0700

>> - Actually, this very issue came up in a meeting at work today.  We
>> would very much like to allow users not to need to know their own
>> principals. Ideally, we'd like the kerberos principal name to be a char
>> string version of the unix user id. You can do a lot in unix without
>> ever knowing your numeric unix userid.  Basically we are running out of
>> usable 8 char unix usernames, since we have a policy of no username
>> reuse.

> Eh, well, how do they log in? As firstname.lastname?,

Correct.

> which is then mapped to a Unix username?

Correct.  That's the proposal.  We're kicking around various different
proposals; an alternative is to just start handing out Unix usernames
longer than eight characters.  But I'm leery of the OS support for this.

> Yes, principal name canonicalization in AS_REQs can help with that :)

And yeah, that's the idea.  :)

> you'd need your system software (/bin/login, xdm, PAM, NT GINA, ...)

*nod*  This is a solveable problem, though.  (Well, possibly apart from NT
GINA, but I'm not sure how much we care.)

> to support that. Windows [2000] certainly supports that,

That's where a lot of the push is coming from.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>