Subject: comments on krb-dns-locate draft

From: Jonathan Trostle <[email-masked]>
Date: Mon, 22 Nov 1999 16:40:06 -0800

The domain names to realm mapping portion of this draft allows an attacker
to spoof a TXT record which can result in server spoofing. Kerberos
shouldn't rely on the general security of DNS to be secure; in particular,
an attacker in one realm shouldn't be able to spoof servers in another
realm by modifying DNS replies.

We propose the following as a more secure alternative to the domain name to
realm mapping section of the krb-dns-locate draft. The basic idea is that
the client sends the server name and sets a new kdc-options bit
(name-canonicalize bit) in the TGS request if it needs help in determining
the realm of the requested server name. The KDC will lookup the name (could
be in some directory or DNS - this could be the subject of a separate
draft, the KDC name lookup must be secure) and returns the realm of the
target server with a checksum in padata fields, along with a crossrealm TGT
to the next realm on the path towards the target realm.

The client then obtains the realm for the requested service from the padata.

Jonathan

CAT Working Group
                               M. Swift

Document: draft-ietf-cat-kerberos-refer-00.txt
                        Microsoft
November 1999
                                 J. Trostle

                                 Cisco Systems

                       KDC referrals for securely locating Kerberos realms

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress." 
   
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   In "Generating KDC Referrals to locate Kerberos realms" [4], Swift 
   presents a new method for a Kerberos Key Distribution Center (KDC) 
   to respond to client requests for tickets. If the client sets the
   name-canonicalize bit in the kdc-options of a TGS_REQ message, the 
   KDC will handle the request by looking up the server name in a 
   global directory and then return a referral padata and a cross-realm 
   TGT to another realm on the referral path. This draft specifies two 
   additional padata fields that provide additional integrity protection 
   for the realm information that is sent to the client. The padata 
   value is a checksum over the KRB5-PADATA-SERVER-REFERRAL-INFO type 
   [4]. The second new padata type informs the client that it should set 
   the name-canonicalize bit again after obtaining a TGT to the realm in 
   the KRB5-PADATA-SERVER-REFERRAL-INFO type. 
    
2. Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [2]. 

3. Motivation

   This proposal extends RFC 1510 [3] and [4] and has two goals. The first 
   goal is to ensure the integrity of the referral padata [4] that the 
   KDC sends to a client. Secondly, the KDC will communicate to the client
   whether the name lookup in the global directory is successful or not.
   If not, the KDC refers the client to the root realm in the realm tree. 
   This referral will be communicated by the padata type that is sent in 
   the TGS_REP, and the realm name in the referral padata is set to the 
   root realm in the tree. The client can follow the crossrealm TGT chain 
   to the root realm, and then set the name-canonicalize bit again with 
   the original server name in the request. The root realm can check the 
   global directory for the appropriate cross organization trust tree 
   relationship, and return another referral if the server name is found. 
   The advantage of this approach is that knowledge of cross organization 
   relationships is localized to a single realm. 
    
4. The Protocol

   From Swift [4], the name-canonicalize bit (bit 12) is used by a client
   to request a lookup in the global directory for the server name in the 
   TGS_REQ message:

        KDCOptions ::=   BIT STRING { 
                          reserved(0), 
                          forwardable(1), 
                          forwarded(2), 
                          proxiable(3), 
                          proxy(4), 
                          allow-postdate(5), 
                          postdated(6), 
                          unused7(7), 
                          renewable(8), 
                          unused9(9), 
                          unused10(10), 
                          unused11(11), 
                          name-canonicalize(12), 
                          renewable-ok(27), 
                          enc-tkt-in-skey(28), 
                          renew(30), 
                          validate(31) 
         } 

   Also from Swift [4], the preauthentication data type KRB5-PADATA-
   SERVER-REFERRAL-INFO is defined:
   
        #define KRB5-PADATA-SERVER-REFERRAL-INFO                20
        
        KERB-PA-SERV-REFERRAL   ::= SEQUENCE {
                referred-server-name[1]   KERB-PRINCIPAL-NAME OPTIONAL,
                referred-server-realm[0]  KERB-REALM
        } 
   
   The new preauthentication data types are KRB5-PADATA-SERVER-CHKSUM-
   REFERRAL-INFO and KRB5-PADATA-SERVER-CHKSUM-REFERRAL-NONAUTHORITY-
   INFO:

   #define KRB5-PADATA-SERVER-CHKSUM-REFERRAL-INFO	        21

   KERB-PA-SERV-CHKSUM-REFERRAL  :: = SEQUENCE {
           checksum[0]		Checksum  -- RFC 1510 [3]
                               -- uses TGS_REP body encryption
                               -- key and checksum from the etype
   }

   #define KRB5-PADATA-SERVER-CHKSUM-NONAUTHORITY-REFERRAL-INFO	22
   KERB-PA-SERV-CHKSUM-NONAUTH-REFERRAL  :: = SEQUENCE {
           checksum[0]		Checksum  -- RFC 1510 [3]
                               -- uses TGS_REP body encryption
                               -- key and checksum from the etype
   }

   Both checksums are computed over the ASN.1 encoding of the
   KERB-PA-SERV-REFERRAL data. The KDC generates the checksum; the 
   client must validate it. The KDC will send only one of these
   newly defined padata types in the TGS_REP message. For a global 
   lookup that is successful, the KRB5-PADATA-SERVER-CHKSUM-REFERRAL
   -INFO padata type is sent. For an unsuccessful lookup, the 
   KRB5-PADATA-SERVER-CHKSUM-NONAUTHORITY-REFERRAL-INFO padata type
   is sent. In the first case, the client will follow the crossrealm
   referral chain in order to obtain a TGT and then service ticket
   to the referral realm. In the latter case, the client may follow 
   the crossrealm referral chain, obtain a TGT for the referral realm,
   and set the name-canonicalize bit again when sending the TGS_REQ 
   message to the realm. The client may receive another chain of 
   crossrealm referral TGT's that it should follow. When it reaches
   the final realm, it should obtain a valid service ticket. 
   
5. References 

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
    
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   3  Kohl, J., Neuman, C., "The Kerberos Network Authentication 
      Service (V5)", RFC 1510, September 1993 

   4  Swift M. "Generating KDC Referrals to locate Kerberos realms",
      draft-swift-win2k-krb-referrals-00.txt, October 1999.

6. Author's Addresses 
    
   Michael Swift 
   Microsoft 
   One Microsoft Way 
   Redmond, Washington 
   Email: [email-masked] 

   Jonathan Trostle
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134
    Email: [email-masked]

Full Copyright Statement 
 
   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this   
   document itself may not be modified in any way, such as by removing   
   the copyright notice or references to the Internet Society or other   
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 

==========================================================================
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: Ken Hornstein <[email-masked]>
Date: Mon, 22 Nov 1999 22:08:36 -0500

>realm by modifying DNS replies.

I know we talked about this off-line, but I still don't see how
this introduces any new vulnerabilities.  Today you can spoof a
CNAME record for any host you look up that will redirect you to
another domain, and presumably another realm; what you are describing
is simply a variation on this attack.  So I object to the notion
that this draft increases the reliance of Kerberos on a secure DNS.

(BTW, it seems to me that to properly exploit this you'd need to
either masquerade as the service host or insert a bogus A record,
_and_ have the cooperation of the administrator of a realm you
already cross-realm authenticate with)

--Ken

---

From: Ken Raeburn <[email-masked]>
Date: 22 Nov 1999 21:59:29 -0500

[ Apologies, but I haven't really examined the krb-referrals draft
  carefully yet. ]

Several problems come to mind.

First, you're trying to close one window of attack, but ignoring the
wind howling through the room. :-) I think you need to protect *all*
of the name lookups, including A/A6/PTR/SRV/TXT lookups and CNAME
processing, in order to close this method of attack.  Is there a
situation where using TXT records gives you a *new* attack, instead of
widening slightly an existing one?  And even if there is, why close
that one only, and not do anything about the existing problems?

The only such situation that comes to my mind is if you're not using
DNS for any other lookups, only for the realm TXT records.  But if
your environment is already set up with a secure way of looking up
host info, you can add host->realm mappings that way too, and keep
Kerberos out of it.

If I run "rlogin foo -x" a second time, do I talk to the KDC again to
do the mapping of foo to foobar.mit.edu again, or can that information
be cached?  If it's cached, how do I know when to expire that info?
Even if the KDC has a secure way of looking up the host name, that
database can't be assumed to be static.

If raeburn.org is before mit.edu in the domain search list on my
client workstation (not necessarily on the KDC), but foo.raeburn.org
doesn't exist, do I have to make two TGS_REQs to resolve foo?  How do
I get the lifetime for the negative answer for foo.raeburn.org?  Or
can I not cache it at all, thus forcing me to do another TGS_REQ next
time I ask for "foo"?  Or is the local domain search list simply
ignored?

How do you find the KDC to send the initial AS_REQ to?  What if it's
not for the local realm?  Remember, one goal of the krb-dns-locate
proposal is to do away with config files altogether for the case of
standalone applications like kermit.

How do you prevent address info for the local realm from being spoofed?

If I borrow an xterm window on someone's UNIX box at MIT, and run
"kinit [email-masked]" and then "rlogin cvs.gnu.org -x", what
happens?

>    The KDC will lookup the name (could

So, you're basically moving the problem of the insecure name lookup
from the client to the KDC, securely, without actually solving it.
Why can't the secure mechanism used by the KDC potentially be used by
the client?  "It might be an annoying administrative hassle" is a good
enough reason to want to be able to do all queries through a server,
but isn't a reason to not *permit* the client to use the same
mechanism.  Same idea as configuring a machine's local DNS server
process to talk only to a list of forwarding agents.

If we want to solve this problem within the Kerberos, er, domain,
maybe what we want is a Kerberos-based DNSSEC (or Kerberos-protected
versions of other name-lookup services).  Perhaps that means signing
the data using a private-key scheme, but that'd be computationally
intensive on the server; perhaps it means using Kerberos to talk to a
server to securely retrieve (and cache!) the necessary public keys.  I
don't know, I haven't thought it through.

In the simple case, a client may send all requests to a local server
(which may or may not be a KDC) for further processing, using Kerberos
for protection.

These might mean more or bigger packets being sent around, but it
would keep non-Kerberos-oriented services out of the KDC and out of
the Kerberos protocol.

Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 23 Nov 1999 11:58:03 -0800

>that this draft increases the reliance of Kerberos on a secure DNS.

We should distinguish between how any particular implementation solves
problems outside the spec with the specification itself. If an existing
practice, outside the scope of RFC 1510, is insecure then that's not reason
enough to specify insecure protocols in drafts.

If the client uses insecure DNS lookups to figure out the name or the realm
of the server that it wants to talk to, then it won't be able to
authenticate the server. Our proposal allows the client to not use DNS in
this way. What is the argument for having the client use DNS in this way,
and does it outweigh the loss in security? 

If DNS is used only to obtain the server's IP address, then you have at
most a denial of service attack.

>already cross-realm authenticate with)

If an attacker can modify the DNS reply to the TXT query, it can modify the
A RR reply. The attacker would need to masquerade as the service host. A
malicious administrator shouldn't be able to impersonate services in
another realm.

Jonathan

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 23 Nov 1999 17:04:59 -0500

>enough to specify insecure protocols in drafts.

RFC 1510 doesn't really talk about naming very much, and I assume this
was deliberate.  It does say that NT-SRV-HST principal names should use
"the host name" as the instance of the principal.  So far everyone has
interpreted this as DNS host name.  How do you canonicalize a DNS host
name?  Look it up in DNS.  One could argue that the use of DNS in this
way is already specified in RFC 1510, but I'd suspect that would be
pretty thin reasoning.  But nevertheless, I believe this has been
generally understood by everyone involved that you use DNS to
canonicalize service names (and if you happen to use a DNS domain name
to figure out what realm a particular service is in, then it also
controls what realm a service belongs to).  I'm just not sure where
the line between implementation and specification is in this case.

>authenticate the server.

You've said this several times, but somehow I have yet to see an
explanation of this sentence.

>Our proposal allows the client to not use DNS in

And here's the crux of my argument - there is no loss in security!
The same attacks can be played out already today with DNS spoofing.

The arguments _for_ using DNS in this way is that the current scheme
(config files) scales as well as the old ARPANET hosts.txt file (this
isn't conjecture, we're experiencing this today).  There needs to be a
way of getting this information via a distributed database.  Given the
way current schemes are done, I believe that what our draft specifies
is no worse than the current maybe-standardized schemes.

>most a denial of service attack.

And if you are only given an IP address?  Perhaps I missed this in your
draft, but are you going to also provide a substitute for PTR records?

>malicious administrator shouldn't be able to impersonate services in

But you'd still need the service key from the host you're masquerading
_as_ to do anything useful.  And at one level .... if an attacker as
access to a particular service key, then they _are_ that service
in terms of Kerberos, for all practical purposes.  If they can do that ...
then I think worse things are possible.

--Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Tue, 23 Nov 1999 15:10:17 -0800

>explanation of this sentence.

This is the key point, so I will elaborate. Suppose I have a server
principal name host/www.foo.com in my realm R1.FOO.COM. An attacker adds
the same server principal name into the realm R2.FOO.COM which has a trust
relationship with R1.FOO.COM. Furthermore, the attacker knows the key for
the principal in R2.FOO.COM. When a client in the R1.FOO.COM realm makes a
TGS request for host/www.foo.com, it first makes a DNS query but the
attacker changes the DNS TXT reply to R2.FOO.COM. The client requests realm
R2.FOO.COM in the TGS request and obtains a ticket to the attacker's
server. Everything seems fine to the client, mutual authentication works,
etc. But the client is not talking with the legitimate server, rather it is
talking with the attacker's server that it thinks is the legitimate server.
So the atttacker has defeated the mutual authentication.

>is no worse than the current maybe-standardized schemes.

Not comparing against config files, but comparing against the proposal that
we have made. Everyone agrees that config files don't scale. 

>then I think worse things are possible.

See the key point above.
Jonathan

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 23 Nov 1999 18:46:39 -0500

>principal name host/www.foo.com in my realm R1.FOO.COM. An attacker adds

Okay, yes, I believe this is a valid attack ... but you can _also_ do
the same thing when www.foo.com is canonicalized by returning a CNAME
record (in addition to the A record) changing this to be a host inside
of R2.FOO.COM, with current implementations today (which can be argued
are following RFC 1510).  So again, I don't believe a new attack is
added by the use of our draft.

>we have made. Everyone agrees that config files don't scale. 

Okay, since you asked ...

The theory is fine with your draft .... I'm just wondering how this
will be put into operation.

To do this right you need to perform all name canonicalization on the
KDC.  So when I do "telnet foo", that means the KDC will be required to
turn "foo" into "foo.bar.com".  This expansion has always been done in
the past by the resolver client library, and the mechanisms for doing
this have been well understood.  Now you're taking a task which has
always been done by the client and moving it to the KDC.  This means
you're going to potentially have different canonicalization semantics
between Kerberos and non-Kerberos applications (by that, I mean if you
configure your client to try the domains bar.com and blah.com, the KDC
won't necessarily know that), which I think in the long run can only be
bad (and I think this would totally screw travelling users).  I suppose
you could mandate that Kerberos applications can _only_ accept FQDNs,
but this doesn't allow for the possibilities of host aliases and I
don't think it's feasable anyway.

(I also think that this would only ever be implemented on a Microsoft
KDC, but I only mention this because I think _that_ fact would prevent
it from gaining wide acceptance).

I'd like to say that I have no problem with this draft going forward,
but I would want the behavior specified when the client talks to a
KDC that doesn't support the name-canonicalization option.

--Ken