Subject: name canonicalization review

From: Ken Raeburn <[email-masked]>
Date: Mon, 20 Nov 2000 19:54:32 -0500

After looking over some of the email that's gone around in the last
few weeks, I've found five sets of things that haven't been completely
dealt with.  Some minor, some may still need discussion.

The big one I see that still needs discussion is the first item.

1. GSSAPI:

Martin Rex has pointed out a number of problems that as far as I
noticed haven't been addressed properly.  In particular, I don't think
the Microsoft folks, who are using something GSSAPI-like, and
contributed the name canonicalization stuff in the first place, have
responded.

2. when to use:

I need to write the revised text for section 2 I promised, indicating
that canonicalization needs to be used almost always, but as a SHOULD
and not a MUST, and better combined with the other text.

3. what can change and when:

In AS_REQ, text should be added to permit the server name to change;
not all AS_REQs are for TGTs.

In TGS_REQ, can the client name change (e.g., in inter-realm name
mapping cases)?  Discussed briefly but not really resolved.  I'm
weakly in favor of it, but any such implementation needs to be
administered with great caution.  (E.g., if a person gets my TGT, can
they use it to map their account in another realm to mine when talking
to MIT services, thus creating a compromise of my account that long
outlives the TGT that was stolen?)

4. ambiguities:

This can be dealt with by not allowing krbtgt to be on either side of
a canonicalization mapping.  (E.g., if I ask for credentials to talk
to service foo and get back a TGT, is that the canonicalization, or a
pointer to a different realm?)  Need text saying so.

5. lifetime:

Need text describing the bounding of the usefulness of the principal
name aliasing info by the lifetime of the ticket.

---

From: Ken Raeburn <[email-masked]>
Date: 24 Nov 2000 01:23:29 -0500

Okay, here's some possible replacement texts.  Feel free to cut them
down a bit.  (What's the old quote about writing a long message for
lack of sufficient time to write a short one?)

> and not a MUST, and better combined with the other text.

Replace the paragraph:

   Where name cannonicalization is supported a client who can....

with something like:

	Depending on a realm's configuration, name canonicalization
	may allow a non-canonical form of a hostname or other name to
	be used in a constructed service principal name, and it may
	allow multiple services to share a single service principal
	name.  Use of name canonicalization can be used to support
	(but is not limited to) the cases where a server host has
	multiple common names (names typed by a user<A
	HREF="#fn2.1">[2.2]</A>), all of which are known to the KDC,
	but only one Kerberos identity (the canonical name is the
	Kerberos principal name), or multiple services are provided by
	a single Kerberos identity.  (For example,
	"ldap/[email-masked]" may be an alias for
	"ftp/bar/[email-masked]".)  Thus, unless a client has
	special knowledge that a principal name it is about to use is
	already the canonical version of the name, it SHOULD request
	name canonicalization when sending requests to a KDC.  In
	particular, instructions given for constructing a service
	principal name in, for example, RFC1964, yield a name that may
	still be subject to canonicalization unless otherwise
	indicated.

        Name canonicalization is intended solely to provide a secure
        mapping from the name known by a user to its principal
        identifier.  It is not intended for use as a general purpose
        nameserver or to identify instances of a service.

	(N.B.: Since RFC1510 did not include this flag, principal
	sharing between different services or unusual canonical
	principal name forms will not be compatible with the use of
	RFC1510-based clients.)

Of course, if we suggest that support may not be supported in a KDC,
then optimum compatibility between implementations would require not
only that the KDC support it, but also that clients not require it
(i.e., they determine the canonical form themselves, or require that
they be provided with the canonical form, or at least have that
ability and don't rely on being able to canonicalize short names)
because it might not be available.

Also, related to Doug's suggestion that I use "SHOULD" above, I think
paragraph 2 of 3.3.1 should use "SHOULD" or "should" instead of "must"
in the first sentence.

> not all AS_REQs are for TGTs.

In 3.1.3, after the second or third paragraph, drop in this slightly
modified text from 3.3.1:

    If the desired service is not the TGS, and
    if the client does not know the realm of the service or the true
    service principal name, then the CANONICALIZE option should be used in
    the request. This will cause the AS to locate the service principal
    based on the target service name in the ticket and return the service
    principal name in the response.  This function allows the KDC to
    inform the user of the registered Kerberos principal name and
    registered KDC for a server that may have more than one host name or
    whose registered realm can not be determined from the name of the
    host, but it is not to be used to locate the application server.

(See above for "should" vs "must" in first sentence.)

> outlives the TGT that was stolen?)

Some possible text, to insert probably before the second or after the
third paragraph of 3.3.1:

	If the CANONICALIZE flag is set, the KDC may also change the
	name of the client principal if appropriate.  For example, if
	a user has principals in two realms and wishes them to be
	considered equivalent for access to services in both realms,
	the KDC for one realm may replace the user's principal name
	from the other realm with her local identity when issuing
	tickets based on a cross-realm TGT.

I'm still not sure if it's a good idea.  I'd like to be able to map
[email-masked] to [email-masked] and have things just
work, but the possibility of long-term compromises if the
administration is poorly thought out makes me uncomfortable.

We could alternatively say:

        Unlike in AS requests, the client principal name MUST NOT be
        changed by the TGS.

> pointer to a different realm?)  Need text saying so.

Here's some sample text; it might best be added in the section where
"krbtgt" is described as special (the second section that's labeled
"8.2.3", though it should perhaps be 8.3 and the current 8.3 bumped to
8.4).

        Because of potential ambiguities resulting from the use of
        "krbtgt" principals when name canonicalization and referrals
        are requested, the "krbtgt" principals must always be their
        own canonical forms, and may not be the canonical forms of any
        other principal names.

> name aliasing info by the lifetime of the ticket.

Not sure where to put this, maybe in section 2 at the end of the three
paragraphs I gave above:

	The client MAY make some use of the principal name "mapping"
	information it receives by asking for name canonicalization
	for its own purposes, but that information SHOULD NOT be
	considered valid beyond the expiration time of the acquired
	tickets (which may be inter-realm ticket-granting tickets)
	carrying that information, even if other tickets for the same
	canonical service principal name have been issued with longer
	lifetimes when requested under other names.  Conversely, if a
	lifetime is indicated for the information in the KDC's
	databases, that lifetime MUST be used as an upper bound on the
	lifetime of the issued tickets.

And in the AS_REP/TGS_REP generation description and sample
pseudocode, add lifetime of alias information as yet another bound on
the ticket expiration time.

Comments?

Ken

---

From: Ken Raeburn <[email-masked]>
Date: 28 Nov 2000 22:02:25 -0500

Martin Rex pointed out a number of problems with name
canonicalization.  Many of them were simply ways in which it couldn't
be used (e.g., generic hostnames mapping to multiple machines, when
you don't know which you'll connect to), or how it really ought to
work parallel to and in conjunction with DNS aliases to avoid
surprising the end user.

The main omission Martin brought up, I believe, is the lack of the
ability to do secure name canonicalization anywhere outside of an
AS_REQ or TGS_REQ.

 * gss_canonicalize_name needs this service, to permit (pre)populating
   ACLs (and I could imagine some Kerberos situations where this might
   be the case too); the specification of the GSS_Canonicalize_name
   function specifically says it's for use with ACL entries

 * You can't set up ACLs with "whatever ldap/host.dom.ain@FOO maps to
   at run time", since the mapping can't be performed.

These could be addressed by a KDC service which did *only* name
canonicalization, securely; this should IMNSHO be as integral to the
Kerberos service as name canonicalization itself.  (Or reverse it: If
this canonicalization service isn't integral to the Kerberos spec, the
optimization of name canonicalization as part of KDC_REQ processing
shouldn't be either.)  Using the TGS isn't good enough -- the
principal name you want to canonicalize may be one for which service
tickets are prohibited by site policy.

But no one has suggested anything.
Well, I keep suggesting removing name canonicalization, but no one
seems interested. :-)

Even if we add such a service, gss_canonicalize_name will require a
round-trip to the KDC, while text in RFC 2744 suggests that
gss_canonicalize_name is supposed to be much more efficient than
actually going through the authentication steps.  (Granted, that's
just the C bindings document, and such things should be a matter for
the generic GSSAPI spec.)

How does gss_canonicalize_name work in the Microsoft implementation?

Adding such a service might also permit more flexibility in name
canonicalization, for example, making "ftp/[email-masked]" an
alias for "ftp/[email-masked]", which I believe is impossible
with the current mechanism, so I can't just type "ftp gnuftp" and have
the right magic happen, as I can with normal DNS canonicalization.
(For that to fully work, name canonicalization as part of the AS and
TGS would have to change.  But the right thing, IMNSHO, would've been
to design name canonicalization well, and *then* look at optimizing
the combination with AS and TGS exchanges.)

Do people think we need such a service?
Should it be in kerberos-revisions?
Should kerberos-revisions be finalized without any such facility?

Ken

P.S.  RFC 2743 specifies the use of DNS to canonicalize a supplied
hostname for GSS_C_NT_HOSTBASED_SERVICE.  Perhaps a future Update 2
should address the security issues here somehow, and perhaps change
that specification.