Subject: Re: Proposed draft on name referrals in Kerberos

From: Matt Hur <[email-masked]>
Date: Tue, 27 Jan 1998 10:29:55 -0800

At 01:48 PM 1/26/98 -0800, you wrote:

>Here is the initial draft of a proposal on handling name referrals in

>Kerberos. I haven't decided yet whether this should be put through the CAT

>group or simply published as an information draft about the Microsoft

>implementation of Kerberos. However, I'm interested in people's feedback on

>the mechanism in general.

 ...

>6.   Cross Realm Routing

>The current Kerberos protocol requires the client libraries

>to explicitly request a cross-realm TGT for each pair of

>realms on a referral chain. As a result, the client machines

>need to be aware of the trust hierarchy and of any short-cut

>trusts (those that arent parent-child trusts). This

>requires a lot of configuration on the client. Instead, the

>client should be able to request a TGT to the target realm

>from each realm on the route. The KDC will determine the

>best path for the client and return a cross-realm TGT. The

>client software has to be aware that a request for a cross-

>realm TGT may return a TGT for a realm different from the

>one requested.

 ...

PKCROSS specifies the following:

    Optionally, the local KDC may add another TicketExtention where

       te-type equals 5 for TE-TYPE-DEST-HOST

    and

       te-data is ASN.1 encoding of DestHost.

    A client could then rely on the local KDC to provide a referral to

    the remote KDC, thus removing the need for the client to maintain

    local host/realm mapping information.

    DestHost ::= SEQUENCE {

           DNSHostname [0]    OCTET STRING,

                              -- authoritative DNS hostname

           HostAddr    [1]    HostAddress OPTIONAL

                              -- as defined by RFC 1510

    }

I think that it would be preferable for your implementation to use this mechanism.

--Matt

<italic><color><param>0000,0000,ffff</param>---------------------------------------------------------------

Matt Hur                      CyberSafe

[email-masked]        1605 NW Sammamish Road, Suite 310

(425) 391-6000 x154 voice     Issaquah, WA 98027-5378

(425) 391-0508 fax            http://www.cybersafe.com

</color></italic>

---

From: "Mike Swift (NT)" <[email-masked]>
Date: Tue, 27 Jan 1998 10:41:02 -0800

It seemed to me that the suggestion from PK-CROSS was a starting point but
not sufficient. It let the client know what server to talk to but not what
realm, and as a result the client can't take advantage of existing
cross-realm TGTs in its cache. In addition, I'm not convinced that the KDC
is the best service to be returning the address of a KDC to the client. In
the case where you have a multiple widely distributed realm, it may be that
there is another KDC closer that could be looked up in DNS. 
 
- Mike

 -----Original Message-----
From: Matt Hur [mailto:[email-masked]]
Sent: Tuesday, January 27, 1998 10:30 AM
To: Mike Swift (NT); [email-masked]
Subject: Re: Proposed draft on name referrals in Kerberos

... 

... 

DestHost ::= SEQUENCE { 

I think that it would be preferable for your implementation to use this
mechanism. 

--Matt 

--------------------------------------------------------------- 
Matt Hur CyberSafe 
[email-masked] 1605 NW Sammamish Road, Suite 310 
(425) 391-6000 x154 voice Issaquah, WA 98027-5378 
(425) 391-0508 fax http://www.cybersafe.com

---

From: Matt Hur <[email-masked]>
Date: Thu, 29 Jan 1998 15:00:04 -0800

I believe that the PKCROSS specification is sufficient.  Please see embedded comments.

>realm, and as a result the client can't take advantage of existing

The realm is in the message returned from the KDC.

>cross-realm TGTs in its cache. In addition, I'm not convinced that the KDC

I'm not sure what you mean about taking advantage of existing cross realm tickets.  You want the client, upon receiving a cross realm TGT from the KDC, to then take advantage of a cross realm ticket that it has cached?

>there is another KDC closer that could be looked up in DNS. 

There is no guarantee that DNS will map accordingly.

--Matt

Matt Hur                      CyberSafe

</color></italic>

---

From: "Mike Swift (NT)" <[email-masked]>
Date: Sat, 7 Feb 1998 18:31:51 -0800

Thanks for reviewing the document. 
The reason I added a new name type is so that the KDC knows when the name is
not expected to be in the local Kerberos database, and to aid in parsing it.

For example, the name "host/[email-masked]" is normally
transmitted as:
sname = host ftp.microsoft.com
realm = MICROSOFT.COM

However, in the case of enterprise names, the name would be transmitted as:
sname = host/[email-masked]
realm = <realm to which the request was sent>

The reason for this is that the name should really be treated as flat name
within a global name space. The realm portion of the name (everything after
the '@') does not refer to a realm, so it doesn't make sense to send it in
the realm portion. In addition, as splitting the name into portions based on
the '/' character doesn't add too much value, because in the KDC those
characters will be replaced before looking up the name

The reason that the KDC returns the realm name of a service in
pre-authentication data is so that the client can make better use of cached
tickets. For example, if the "host/[email-masked]" service
is really in the OFFICE.MICROSOFT.COM realm, which is two hops away by trust
relationships from the KDC which was processed the original request, that
KDC would return a cross-realm TGT to the next realm on the trust path.
However, the client may already have a cached TGT to the
OFFICE.MICROSOFT.COM realm, removing the need to talk to every KDC on the
trust path. In addition, because the client knows which realm contains the
service it can just request a normal cross-realm ticket to that realm rather
than to the particular service, allowing the KDCs in the other realms to
avoid needing to consult the global directory.

I will update the document to be more explicit about the differences between
the model it proposes and the model described in RFC1510.

As an aside, I am interested in feedback on whether this should be submitted
as a draft to the CAT working group or should be published as a purely
informational draft on how Microsoft plans on extending Kerberos.

Any thoughts?

- Mike Swift
-----Original Message-----
From: Theodore Y. Ts'o [mailto:[email-masked]]
Sent: Friday, February 06, 1998 7:04 PM
To: Mike Swift (NT)
Cc: [email-masked]
Subject: Re: Proposed draft on name referrals in Kerberos

I've finally gotten a chance to read through your proposed draft about
name referrals, and I have some comments...

In section 3, you specify that you use a special name type,
KRB_NT_ENTERPRISE_PRINCIPAL.  I don't see the end for a separate name
type.  If the KDC is one that's playing the "enterprise" game (which is
not defined in the specification, BTW), it knows this.  It doesn't need
a special name type to tell the KDC that.  

The comment in section 3 about "the entire name is transmitted rather
than separated it into name parts" is not clear.  What does this mean?

In general, the Microsoft architecture about names and realms is not
clear, and needs to be defined in the specification.  It sounds like the
realm in a particular principal name is not necessarily specify the
true realm in which that principal resides.  

For example, the text gives the example of a user "[email-masked]", but
the KDC may refer the client to another realm which is truely the realm
to which "[email-masked]", notwithstanding the realm name of "ms.com" in
the principal name.

As another example, the TGS referal mechanism needs a preauthentication
data type to specify the serveral realm which must be used.  Why is this
necessary, given that normally the server name can be inferred from the
form of the ticket-granting-ticket?  (i.e., if you get a TGT with the
service name krbtgt/[email-masked], you know the next realm
you need to go to is LCS.MIT.EDU).

So unless I'm missing something, this document is presuming some very
different assumptions about how principals and realms are named than
what is documented in RFC-1510.  Or, I could be wrong; if that's the
case, could you clarify what's going on the document?  Thanks!!

The other comment I have with the document is the comment in section six
about cross realm routing.  There's a comment made that the client
should trust the Kerberos KDC's to be able to find the trusted path for
doing cross-realm authentication.  However, there's something else going
on here which also deserves mention, as it's much more serious.  

In the classical Krb5/RFC-1510 cross-realm model, the application server
was responsible for determining whether the trust path used was
acceptable.  This was admittedly problematical, since it meant the realm
trust relationships needed to be configured at each application server.
So another change which must be going on is that the KDC's much also be
checking and enforcing acceptable trust paths before honoring
cross-realm TGT's.  This should be explicitly mentioned in the document,
since it is a change from the RFC-1510 model.

						- Ted

---

From: Rich Salz <[email-masked]>
Date: Mon, 9 Feb 1998 09:13:23 -0500 (EST)

>informational draft on how Microsoft plans on extending Kerberos.

I strongly think the latter.

I appreciate that you're doing this, but it really is documenting a
Microsoft product...
	/r$

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 9 Feb 1998 10:54:10 -0800

>I appreciate that you're doing this, but it really is documenting a

Since many IETF standards are, in fact, product documentation, I think that
that is pretty much immaterial.  For example, Kerberos itself is an MIT
"product"; the GSSAPI began its life as a DEC product, TLS is just
Netscape's SSL warmed over, etc.  IMO, the only real questions are:
    Is the proposal reasonable and generally useful?
and
    Is the proposer willing to cede change control to the IETF?

Note I haven't read the document in question and so am in no position to
comment on either of the questions.

---

From: Rich Salz <[email-masked]>
Date: Mon, 9 Feb 1998 14:12:19 -0500 (EST)

Glen writes:
>IMO, the only real questions are:

Perhaps I was reading too much into the excerpt from Mike, above,
when I assumed the answer to Glen's #2 would be "sure, except that
we're about to ship what we documented" (i.e., essentially answering
no.) If my assessment is wrong I'd be glad to hear it.
	/r$

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 9 Feb 1998 12:30:54 -0800

Rich Salz <[email-masked]> writes:

>no.)

Even if this were true, there's always another release, right?  Neither
Netscape nor Microsoft stopped shipping SSL while the TLS effort was going
on...

>If my assessment is wrong I'd be glad to hear it.
> /r$
>
>