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

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 20 Dec 1999 14:27:22 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Saturday, December 18, 1999 12:40 AM
> To: [email-masked]
> Subject: Re: comments on krb-dns-locate draft
> 
> 
> "Paul Leach (Exchange)" <[email-masked]> writes:
> 
> > > And, I keep coming back to: *Why* can't we simply insist 
> on DNSSEC if
> > > sites want security?
> > 
> > Science: Because fundamental security principles say one 
> should not insist
> > on an extra mechanism that isn't needed.
> 
> You also shouldn't add complexity to a system that isn't needed. 

I guess some people don't realize that the MIT KDC already has this stuff
implemented. Check out [capaths] in the krb5.conf file, for example, and the
behavior where a KDC generates a referral to its parent if the server
principal ID isn't found in its KDB. 

I guess some people didn't look at appendex section A.6 when I referred them
to it, to see that it's already in the spec.

> (I'd
> be much happier with a Kerberos-based referral proposal that wasn't
> making changes to the core Kerberos protocol itself.

It doesn't change anything on the wire, as the MIT implementation shows.

> It can use
> Kerberos for security, sure, and maybe even be processed by the KDCs.
> The data being exchanged already has one well-understood wire
> representation in use that we could just re-use, namely domain system
> resource records....  DNSSEC is just a bit further down that road, and
> a little off to the side.)
> 
> > Engineering: because DNSSEC isn't deployed.
> 
> I was under the impression that some sites were using it.  And for
> those that aren't, BIND 8 already has the code, doesn't it? 

What about the client side? In order to be secure, the client side needs to
understand the DNSSEC signatures.

> Neither of these can be said for kerberos-refer.

???

MIT KDCs and MS KDCs already generate referrals when the server principal
IDs are not found in the local KDB. And MIT and MS clients already follow
referrals returned from TGS requests.

Paul

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 20 Dec 1999 19:28:50 -0500

>referrals returned from TGS requests.

MIT clients definately don't _follow_ referrals, because I found that
the client library code completely chokes if it gets a cross-realm TGT
that wasn't what it asked for; I believe the error returned is "Wrong
server principal in request". (I ended up disabling the cross-realm
TGT code on the KDC I run to eliminate that problem).

--Ken
==========================================================================
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]