Subject: kerb-rev 2.9.1 Name canonicalization

From: Martin Rex <[email-masked]>
Date: Wed, 9 Aug 2000 11:56:21 +0200 (MET DST)

>
> <h3>2.9.1 Name canonicalization [JBrezak]</h3>
> 
> The NAME-CANONICALIZATION option allows the KDC to replace the name of
> the server requested by the client with the canonical form of the
> server's name, if known, or to refer the client to a KDC for the realm
> with which the requested server principal is registered.

Although I can see where the proposed Name canonicalization
seems to be useful *at first glance*, it has *significant* problems
with gssapi level operations:

1) A portable gssapi-based application will establish a (network)
   communication channel independent of the target name that is
   fed into gss_init_sec_context().
   The KDC does not know to which host the application already has
   (or is going to) established the communication, so it is not in
   the position to "canonicalize" to a particular host-specific
   instance of a "generic" target.

2) Several (non-portable) gssapi-based applications will establish the
   network communication channel based on a hostname and port number
   and derive a host-based service name as target name to pass into
   gss_init_sec_context().  The canonicalization of the destination
   hostname by the application will be performed by (insecure) DNS,
   so the only "canonicalization" the KDC should allowed to do is
   DNS-based -- preferably based on secure DNS.

3) Servers in a distributed application may want to populate their
   ACLs with the principal names of other servers.  Any "canonicalization"
   of the servers names by the KDC *must* also be performed during
   gss_canonicalize_name(), or the ACL entries will not be usable.
   This affects both, finding of the correct REALM as well as
   canonicalizing host-specific parts of the name.

Because of (3), I think that any service name canonicalization should
be done out-of-band (i.e. independent of context establishment).
Optimizing it into the ticket request will definitely break distributed
systems.

My concern is primarily GSS-API, I'm not really intimate with
Kerberos itself.  I think there should be a new call in GSS-API
to perform service name resolution, resolving a printable "generic name"
into a host-specific service instance with accompanying network address
info.   This lookup should be seperated from the "context establishment"
(i.e. ticket request) in the underlying (Kerberos 5) mechanism.

   OM_uint32 gss_resolve_service_name(
            OM_uint32               * minor_status,              /* out */
            gss_buffer_t              generic_service_name,      /* in  */
            gss_name_t              * service_instance_name,     /* out */
            gss_channel_bindings_t    service_channel_bindings,  /* out */
    );

The other issue was about the caching of KDC-based canonicalzation
of a service name.  My KDC logs seem to indicate that W2K pro (build2195)
doesn't do service ticket caching.  I see it requesting 50 tickets
for the same service within 2 minutes.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: 09 Aug 2000 17:41:30 -0400

>    instance of a "generic" target.

I think this is a clinching argument for using the generic target name
when the service may be provided by multiple hosts at any given time.
There's nothing that says multiple canonical names can't refer to the
same address(es).  The current MIT code is Just Wrong, and using name
canonicalization to select one of the individual hostnames is also
wrong.

In such cases, I'd also expect the generic hostname to be the
canonical form, with multiple addresses (A/AAAA/A6 records) that might
incidentally have PTR records that point to other names.

> Optimizing it into the ticket request will definitely break distributed

I was starting to give in a bit on the "separate service vs ticket
request" point, until you brought this up. :-)

In the Kerberos client-server case, the server could use its own
service key to communicate with the KDC securely.  In a user2user
setup (which the MIT GSSAPI code doesn't support, but plain krb5
does), the server could still do it if it already had the "server"
user's credentials available.

But if the name being canonicalized is for a user and not a service,
the KDC might quite reasonably refuse to issue tickets for that
"service", so as to prevent attacks against the user's key.  Thus you
get no info about the canonical form.

> for the same service within 2 minutes.

Wow.

Some of us around MIT had been talking about possible countermeasures
for certain kinds of denial-of-service attacks against the KDC.  I
guess it's a good thing we haven't implemented any yet.