Subject: Addition for Section 11

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 04 Oct 2002 10:35:39 -0500

On the way home, after thinking about the cross realm trust discussion we 
had at the meeting, we should consider adding a consideration about determining
the realm of a host as well. Suggested wording is:

Implementations of Kerberos must not use untrusted DNS to determine the 
realm of a host. Such use would allow a compromise of the DNS to result 
in a client obtaining the wrong realm and the wrong address for the host. 
Thus allowing one to steer the user to a trojan host in the wrong realm.

A possible exploit: Consider realms A and B with B being the high school.
Cross realm is setup between them. User U@A visits high school with laptop 
and uses High school DNS maybe via DHCP. U wants to contact host H which is 
officially in realm A, but B's DNS says its in realm B at a new address.
User then gets ticket for H@B, and logs on, and forwards ticket. The 
students now have Users ticket. Students could even make H@B a 
man-in-the-middle using forwarded ticket to log user in to real H@A.
User may not notice the realm is wrong in the cache. (If there are many
realms participating, it would be even harder for the user to notice
the wrong realm.)

<draft-ietf-krb-wg-krb-dns-locate-03.txt> does state this as an attack:

   However, when cross-realm
   trusts are used it is possible to redirect a client to use a comprom-
   ised realm.

   What this implies is that it is possible to cause a client to be
   authenticated to a host other than the one desired by the end user.
   In a single realm scenario a spoofed DNS response can cause a client
   to be redirected to an attacker's host, but the authentication would
   fail.  However, in the cross-realm scenario an attacker who has
   administrative control over a realm that has a cross-realm trust
   established with the local realm, the attacker can redirect the
   client to a host for which valid credentials would be issued by the
   attacker's KDC.  Since the credentials are valid there are no authen-
   tication failures and the client believes they are connected to the
   desired host.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 7 Oct 2002 16:47:09 EDT

> 
> 
> Jeffrey Altman wrote:
> > 
> > > >In my opinion, we have an obligation, both as security protocol designers
> > > >and under the IESG mandate that all standards-track documents discuss
> > > >security considerations, to point out this fact so that potential users of
> > > >the protocol do not inadvertently leave themselves vulnerable to this
> > > >attack.
> > >
> > > We're in violent agreement here, aren't we?  I mean, I was one of the
> > > people who thought up this crazy scheme, and _I_ think we should include
> > > a detailed warning explaining the vulnerabilies you can encounter when
> > > using this protocol.  Is anyone saying that we shouldn't?
> > >
> > > --Ken
> > >
> > 
> > My only objection was to the use of "MUST NOT" along with the
> > explanation.
> 
> Should it be should not?

I am fine with SHOULD NOT.  

A note stating that the risk can be mitigated (but not eliminated) by
policy should also be added.