Subject: Re: Section 2 (take 2) Kerberos Revisions for comment

From: Ken Raeburn <[email-masked]>
Date: 12 Oct 2000 15:50:43 -0400

Jonathan Trostle <[email-masked]> writes:
> Here is the text I would like to see added in section 2.9.1:
> 
> In order to ensure interrealm interoperability, clients MUST
> implement secure canonicalization of short names. In particular, a
> client that receives a server principal not found error from the
> KDC, in response to its TGS request with a short name in the sname
> field, MUST obtain the corresponding long DNS name (without using
> reverse DNS lookups) and retry the TGS request with the long name.
> 
> Jonathan

Actually, I think it's more extreme than that.  To ensure
interoperability, a client needs to turn on the canonicalization flag
*almost always*.  Doesn't matter whether you've got a "short name".

For example:

We want to talk to an LDAP server on host.dom.ain.

LDAP spec says to use GSSAPI name "[email-masked]".

GSSAPI/krb5 spec says use principal "ldap/host.dom.ain@REALM".

Kerberos draft says use the official hostname (too vague, but let's
assume for the moment we know there are no aliases, or we've got
secure DNS, whatever).

But, because of the possibility of name canonicalization, as the
Microsoft folks are proposing it, with the possibility of multiple
services sharing a principal, it may be that "ldap/host.dom.ain@REALM"
isn't the server principal at all, only an alias for
"foobar/host/platypus@REALM".  Unless we have special knowledge that a
particular principal name is the canonical one, name canonicalization
must be requested.

This of course implies that when such aliasing is done on the server
principal (e.g., principal sharing between services), no
pre-canonicalization client can be interoperable.  (Do we want a
subsection in section 9 which lists changes from RFC1510 and
interoperability issues between versions?)

It could allow manual specification of the principal name, but having
a "normal" server setup require manual configuration of clients for
authentication despite having specs on how to construct the principal
name is broken IMHO.

So I think the text of section 2 does need changing.  Currently it
says:

    Where name cannonicalization is supported a client who can identify a
    principal but does not know the full principal name can request that
    the Kerberos server attempt to lookup the name in its database and use
    the canonical name of the requested principal or return a referral to
    a realm that has the requested principal in its namespace.  Use of....

This gives the impression that if you can work out the full official
hostname and construct a principal name according to specifications
like I indicated above, you don't need name canonicalization.  This is
not true.  I'd suggest something like this instead:

	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.  (For example, "ldap/foo" may be an alias for
	"ftp/bar.example.com".)  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 MUST request name
	canonicalization when sending requests to a KDC.

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

I'll work on a version that better integrates the rest of the original
paragraph later, but you get the gist of it...

Ken

P.S.  Cliff, Doug, please don't close discussion on the name
canonicalization bits just yet, even in the early sections ... I want
to review a lot of the mail that's gone by on the topic to make sure
we've got all the issues nailed down in a way that nearly everyone
agrees with, because I don't think we do, unless it's in messages I
haven't seen.  ("Nearly" because I'm still opposed to it being part of
the Kerberos protocol in the first place.  But if it stays in, then
I'm eventually going to have to support an implementation of it, and
it had better be specified well.)  That's going to take more time...

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 12 Oct 2000 16:07:03 -0500

Nice note. It gives new wording, and an explaination of why
you would like it changed. I see your P.S.  comment about 
keeping the discusion open on name canonicalization, and I agree
that this part should stay open, especially since it spans multiple
sections, some of which are being revised. 

>         canonicalization when sending requests to a KDC.

I see your point, but I would say "MUST" be replaced with "SHOULD".
The reason being it it up to the client to decied if it wants to
attempt to use name canononicalization. If it does not, then it can 
chose to only work in realms or with principals where canonicalization
is not used. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Oct 2000 13:09:37 +0200 (METDST)

Here we go again...  :)

> GSSAPI/krb5 spec says use principal "ldap/host.dom.ain@REALM".

The GSS-API v2 issue is much more difficult.  GSS-API v2 defines
a call named "gss_canonicalize_name() which can be used to (pre-)populate
ACLs.  If you allow "name canonicalization" during the ticket request
to turn "[email-masked]" into "foobar/host/platypus@REALM",
then this transformation must be made available for gss_canonicalize_name()
as well in -- i.e. outside of a ticket request.

If you permit name canonicalization for the ticket request and
not provide it within gss_canonicalize_name(), you will seriously
break rfc1964 and its successor!  Secure mutual authentication
in a real distributed environment requires more consistent operations
than a simple client-only authentication.

> it had better be specified well.)  That's going to take more time...
 
Although the KDC-based name canonicalization looks like a good idea
in simple scenarios, it doesn't scale to real distributed environments,
where two communication peers may want to establish future or further
authenticated communication channels in either direction.

What the current name canonicalization proposal means is that
a server announces:

'When you want to talk to me, use "[email-masked]",
 and in case I feel like talking to you, I will show up
 as "foobar/host/platypus@REALM" today, and maybe somebody
 else tomorrow.'

That way it is not possible for the client to set up a GSS-API style
ACL by using gss_canonicalize_name() for "push" operations
of the server; only "poll" operations will work.  But if you're doing
mutual authentication, it really shouldn't matter who initiates the
communication.

Rather than canonicalizing the name for/in the ticket, the server
should configured and permitted to use the name that everyone else
will be using and it should be able to authenticate with that
name when initiating communication.

-Martin