Subject: Re: Section 1 Kerberos Revisions for comment

From: [email-masked]
Date: Sun, 6 Aug 2000 07:39:35 -0500

On 2000/08/05 at 20:08:45, Sam Hartmann wrote:

>I agree that the WG has reached consensus that name cannonicalization
>can be used to look up what principal corresponds to a particular
>service on a particular host.  I read the text to say that in
>addition, I could look up the name of a fileserver in the
>ATHENA.MIT.EDU domain simply by asking the KDC to cannonicalize
>[email-masked] and getting something back like
>fileserver/[email-masked].  If you do not read the text
as
>allowing this, perhaps you could help me by showing what forbids this
style of lookup.
>
>
>Thanks for the clarification,
>
>--Sam

You're right that nothing, AFAIK, prevents this sort of abuse.
However, do you think the misuse of this service outweighs the
benefit/value of its intended use?  Would explicit language in the
Kerberos-Revisions RFC saying "don't do this" suffice?  Perhaps an
implementation of the KDC could detect a pattern of such misuse and
log it and/or raise an alert.

- --Dave Hemsath

---

From: Sam Hartman <[email-masked]>
Date: 06 Aug 2000 14:02:47 -0400

>>>>> "David" == David Hemsath <[email-masked]> writes:

    David> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

    David> On 2000/08/05 at 20:08:45, Sam Hartmann wrote:

    >> I agree that the WG has reached consensus that name
    >> cannonicalization can be used to look up what principal
    >> corresponds to a particular service on a particular host.  I
    >> read the text to say that in addition, I could look up the name
    >> of a fileserver in the ATHENA.MIT.EDU domain simply by asking
    >> the KDC to cannonicalize [email-masked] and getting
    >> something back like fileserver/[email-masked].  If
    >> you do not read the text
    David> as
    >> allowing this, perhaps you could help me by showing what
    David> style of lookup.
    >> Thanks for the clarification,

    David> You're right that nothing, AFAIK, prevents this 
    David> sort of
    David> abuse.  However, do you think the misuse of this service
    David> outweighs the benefit/value of its intended use?  

I'm not sure what I think about name canonicalization, but it doesn't
really matter as the WG has reached the consensus that it is useful.
I was part of that consensus, so it would be doubly annoying to change
my mind now.

    David> Would
    David> explicit language in the Kerberos-Revisions RFC saying
    David> "don't do this" suffice?  

Yes, that's all I ever wanted on this issue.  I should have proposed a
rewording.      The problem appears to have  krept in between
revisions-07 and the current text  beind discussed.  I propose the
following  rewording:

 When utilizing the name canonicalization function provided by the
 Kerberos server, the client can make a request providing just the
 service principal name (which may be one of several used by a
 service) along with the part of the hostname supplied by the user and
 requesting name canonicalization from the Kerberos server. The
 Kerberos server will attempt to locate a service principal in its
 database that best matches the request principal or provide a
 referral to another Kerberos realm that may be contain the requested
 service principal.

Here is the original text from  the email:

 When utilizing the name canonicalization function provided by the
 Kerberos server, the client can make a request providing just the
 service principal name (which may be one of several used by a service)
 and requesting name canonicalization from the Kerberos server. The
 Kerberos server will attempt to locate a service principal in its
 database that best matches the request principal or provide a referral
 to another Kerberos realm that may be contain the requested service
 principal.

And here is the text from revisions-07:

      The client may not immediately know what realm a particular service
      principal is in. There are 2 basic mechanisms that can be used to
      determine the realm of a service. The first requires that the client
      fully specify the service principal including the realm in the
      Kerberos protocol request. If the Kerberos server for the specified
      realm does not have a principal that exactly matches the service in
      the request, the Kerberos server will return an error indicating that
      the service principal was not found. Alternatively the client can make
      a request providing just the service principal name and requesting
      name canonicalization from the Kerberos server. The Kerberos server
      will attempt to locate a service principal in its database that best
      matches the request principal or provide a referral to another
      Kerberos realm that may be contain the requested service principal.

I suspect my proposed rewording is too strict, but I leav it to those
who have thought more about name canonicalization to loosen it without
being too broad.