Subject: Re: comments on krb-dns-locate draft

From: Martin Rex <[email-masked]>
Date: Tue, 21 Dec 1999 15:58:24 +0100 (MET)

I don't remeber having seen any further reference to the original
question that started this thread:

If the "name canonicalization" is performed by the KDC instead of
the client, then the client can not reuse tickets from the ticket
cache without a round-trip to the server to check whether the
previous name translation still applies.  Probably the KDC returns
a new service-ticket along with the answer ...

I assume that this will considerably affect context establishment
performance.

-Martin

PS: I would appreciate if users of M$ Outlook (hi Paul&John)
    no longer send HTML "enriched" messages to the CAT mailing list.
    It does not add value, but increases bandwidth and
    storage/archive requirements considerably.
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Paul B. Hill" <[email-masked]>
Date: Tue, 21 Dec 1999 12:01:21 -0500

Hi,

At 03:58 PM 12/21/1999 +0100, Martin Rex wrote:
>the client,

I don't think that the current draft adequately explain the intent of the 
name-cannonicalization bit.[ BTW, both drafts state that this is bit 12, 
Microsoft has implemented it as bit 15, and 
draft-ietf-cat-kerberos-revisions-04.txt states that bit 12 is TRANSITED 
POLICY-CHECKED. ] My current understanding of Microsoft's intent is that 
the name-canonnicalization bit is used to ease Microsoft users from a 
Netbios-name-centric world to the world of DNS and RFC822 style names.

Many of the Windows 2000 applications do not perform a DNS lookup of a name 
before forming the ticket request. [You can see this with a sniffer.] 
Microsoft service principals generally have two registered names within the 
Windows 2000 realm, one with the short (Netbios) name and one with the 
FQDN. [You see this by looking at the computer object within the directory. 
An LDIF dump of a specific computer object will provide you with a pretty 
good view of the details.]

This results in a change in how anyone familiar with Kerberos would expect 
a client to operate.

For example, a user tries typing "dir \\foo\share" which the Microsoft 
client turns into an initial TGS-REQ of "HOST/FOO" with the 
name-cannonicalizaton bit set. The Microsoft KDC would then return a ticket 
for "FOO$". (Think NT administrative share naming conventions.)

If this is really the intent of the Swift draft I can now see why Microsoft 
needs a new option flag, and why it needs to preserved when the initial 
TGS-REQ really needs to be referred to another Kerberos realm.

>then the client can not reuse tickets from the ticket
>previous name translation still applies.

I don't think this is the intent. But since I haven't gotten the 
cross-realm operations to work smoothly I can't verify this by watching the 
traffic. I don't notice any text in the Swift draft that would indicate 
that the name translations change more frequently than the ticket lifetime. 
The Trostle draft doesn't appear to address the issue at all.

>Probably the KDC returns