Subject: draft-ietf-cat-krb5-firewalls.txt

From: [email-masked] (Johan Danielsson)
Date: 01 Dec 1997 02:29:08 +0100

Here is a preview of a submitted kerberos-firewall draft.

/Johan

Network Working Group                                   Assar Westerlund
<draft-ietf-cat-krb5-firewalls.txt>                                 SICS
Internet-Draft                                          Johan Danielsson
November, 1997                                                  PDC, KTH
Expire in six months

                         Kerberos vs firewalls

Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.  Please send comments to the
   <[email-masked]> mailing list.

Abstract

Introduction

   Kerberos[RFC1510] is a protocol for authenticating parties
   communicating over insecure networks.

   Firewalling is a technique for achieving an illusion of security by
   putting restrictions on what kinds of packets and how these are sent
   between the internal (so called "secure") network and the global (or
   "insecure") Internet.

Definitions

   client: the user, process, and host acquiring tickets from the KDC
   and authenticating itself to the kerberised server.

   KDC: the Kerberos Key Distribution Center

Westerlund, Danielsson                                          [Page 1]

Internet Draft           Kerberos vs firewalls            November, 1997

   Kerberised server: the server using Kerberos to authenticate the
   client, for example telnetd.

Firewalls

   A firewall is usually placed between the "inside" and the "outside"
   networks, and is supposed to protect the inside from the evils on the
   outside.  There are different kinds of firewalls.  The main
   differences are in the way they forward packets.

   +  The most straight forward type is the one that just imposes
      restrictions on incoming packets. Such a firewall could be
      described as a router that filters packets that match some
      criteria.

   +  They may also "hide" some or all addresses on the inside of the
      firewall, replacing the addresses in the outgoing packets with the
      address of the firewall (aka network address translation, or NAT).
      NAT can also be used without any packet filtering, for instance
      when you have more than one host sharing a single address (for
      example, with a dialed-in PPP connection).

   There are also firewalls that does NAT both on the inside and the
   outside (a server on the inside will see this as a connection from
   the firewall).

   +  A third type is the proxy type firewall, that parses the contents
      of the packets, basically acting as a server to the client, and as
      a client to the server (man-in-the-middle). If Kerberos is to be
      used with this kind of firewall, a protocol module that handles
      KDC requests has to be written.

   This type of firewall might also cause extra trouble when used with
   kerberised versions of protocols that the proxy understands, in
   addition to the ones mentioned below. This is the case with the FTP
   Security Extensions [RFC2228], that adds a new set of commands to the
   FTP protocol [RFC959], for integrity, confidentiality, and privacy
   protecting commands. When transferring data, the FTP protocol uses a
   separate data channel, and an FTP proxy will have to look out for
   commands that start a data transfer. If all commands are encrypted,
   this is impossible. A protocol that doesn't suffer from this is the
   Telnet Authentication Option [RFC1416] that does all authentication
   and encryption in-bound.

Scenarios

   Here the different scenarios we have considered are described, the
   problems they introduce and the proposed ways of solving them.

Westerlund, Danielsson                                          [Page 2]

Internet Draft           Kerberos vs firewalls            November, 1997

   Combinations of these can also occur.

 Client behind firewall

   This is the most typical and common scenario.  First of all the
   client needs some way of communicating with the KDC.  This can be
   done with whatever means and is usually much simpler when the KDC is
   able to communicate over TCP.

   Apart from that, the client needs to be sure that the ticket it will
   acquire from the KDC can be used to authenticate to a server outside
   its firewall.  For this, it needs to add the address(es) of potential
   firewalls between itself and the KDC/server, to the list of its own
   addresses when requesting the ticket.  We are not aware of any
   protocol for determining this set of addresses, thus this will have
   to be manually configured in the client.

   The client could also request a ticket with no addresses, but some
   KDCs and servers might not accept such a ticket.

   With the ticket in possession, communication with the kerberised
   server will not need to be any different from communicating between a
   non-kerberised client and server.

 Kerberised server behind firewall

   The kerberised server does not talk to the KDC at all so nothing
   beyond normal firewall-traversal techniques for reaching the server
   itself needs to be applied.

   The kerberised server needs to be able to retrieve the original
   address (before its firewall) that the request was sent for.  If this
   is done via some out-of-band mechanism or it's directly able to see
   it doesn't matter.

 KDC behind firewall

   The same restrictions applies for a KDC as for any other server.

Specification

Security considerations

   This memo does not introduce any known security considerations in
   addition to those mentioned in [RFC1510].

References

Westerlund, Danielsson                                          [Page 3]

Internet Draft           Kerberos vs firewalls            November, 1997

   [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)",
   RFC 969, October 1985

   [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416,
   February 1993.

   [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
   Authentication Service (V5)", RFC 1510, September 1993.

   [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions",
   RFC2228, October 1997.

Authors' Addresses

   Assar Westerlund
   Swedish Institute of Computer Science
   Box 1263
   S-164 29  KISTA
   Sweden

   Phone: +46-8-7521526
   Fax:   +46-8-7517230
   EMail: [email-masked]

   Johan Danielsson
   PDC, KTH
   S-100 44  STOCKHOLM
   Sweden

   Phone: +46-8-7907885
   Fax:   +46-8-247784
   EMail: [email-masked]

Westerlund, Danielsson                                          [Page 4]

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Dec 1997 14:25:27 +0100 (MEZ)

>    between the internal (so called "secure") network and the global (or

I consider this definition of firewalling partly wrong and very offensive.

Firewalling is a means of risk managing and access control when
interconnecting independent networks of differing trust relationships,
i.e. like LANs of different companies or a company LAN and the Internet.

Simple packet filters have very limited value, since security-wise they
mostly take the approach "deny what one knows to be dangerous".  Many
simple firewalls are *ONLY* used to limit exposure of certain legacy
protocols with known security shortcomings. 

More complex scenarios that involve at least two routers and a
proxying machine in between, and that does not permit *ANY* datagram
to pass through, can provide very effective protection.  This is not
limited to protocols with known weaknesses, but also for exploitation
of bugs and almost all of the DoS attacks (ping-o-death, land, ...).
Since each protocol that is to be proxied requires extra configuration
work, complex firewalls tend to be configured "permit only what is
absolutely necessary".

Kerberos will *NEVER* be able to protect you from DoS attacks like
ping-o-death, land, etc. that exploit bugs in your code.
Complex firewall setups have been protecting peoples machines for
several years, long before the bugs became public knowledge and
were being used as DoS.

-Martin

---

From: Assar Westerlund <[email-masked]>
Date: 01 Dec 1997 17:04:46 +0100

> I consider this definition of firewalling partly wrong and very offensive.

Sorry if you have been offended.

What is your suggested defintion of firewalling, then?

> Kerberos will *NEVER* be able to protect you from DoS attacks like

I don't believe we wrote that in the draft.  And in (son-of)RFC1510 it
says:

+    "Denial of service" attacks are not  solved  with  Ker-
     beros.   There  are  places in these protocols where an

Moreover, I don't think we should be discussion pros and cons of
firewalling.  They're here and we'll have to live with the
consequences.  Now the question was how to make them interoperate with
Kerberos.

/assar

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 1 Dec 1997 11:02:28 -0500

From: Martin Rex <[email-masked]>
   Date: Mon, 1 Dec 1997 14:25:27 +0100 (MEZ)

Unfortunately, both you and I know that there *far* too many sites which
think that a firewall solves all of their security problems, and *far*
too many vendors who claim that "security isn't a problem; that's what
your firewall is for".  Fortunately not all companies do this, but they
are by far the exception rather than rule.  Even at Microsoft, where
with NT 5.0 they are finally starting to deploy real cryptographic
solutions, looking at some of their other products, it seems very
apparent that the majority of their applications programmers still
believe in the firewall-is-the-solution religion.

Actually, firewalls do not protect you from DoS attacks; indeed, if your
application-level gateway's kernel is vulnerable to a particular DoS
attack (ping of death, land, teardrop, etc.), it represents a
single-point-of-failure, which will cut off your entire company from the
internet at one stroke, if the DoS attack succeeds.

It does mean that if you can harden your firewall machine, you can be
lax about the security inside your firewall domain (and therefore be
subject to insider attacks, attacks where outsiders gain access via a
modem connected to a machine inside the firewall, etc.).  While adding a
firewall can help improve the security in some scenarios, it is also
true that it is often used to provide the illusion of security in far
too many places on the Internet.

							- Ted

---

From: Tim Bass (IETF) <[email-masked]>
Date: Mon, 1 Dec 1997 12:58:57 -0500 (EST)

A few comments:

I thought the 'illusion of security' statement concerning
firewalls was technically correct.  However, I'm also not sure
if it is the best choice of words.  

Agreed, it is a breath of fresh air to read someone discuss firewalls
in more realistic terms.  Firewalls are conceptual architectural
pieces, and Kerberos can be a integral part of a firewall architecture.
This applies to any access-control configuration.

The point the author was making (correct me if i'm wrong) is
that firewalls are architectual concepts, not 'point-platform'
solutions.    Point-platform solutions are 'illusions of security';
comprehensive architectures are not.

IHMO, both of the comments have relevant technical points. 

-Tim

-- 
Tim Bass  	[email-masked]

---

From: Assar Westerlund <[email-masked]>
Date: 01 Dec 1997 21:12:27 +0100

> too many places on the Internet.

So you think the definition in the draft is correct? :-)

Seriously, can we skip the firewalls debate and concentrate on how to
make them interoperate with Kerberos?

Any comments/additions/corrections/whatever to the draft?

/assar

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Dec 1997 20:40:20 +0100 (MEZ)

> believe in the firewall-is-the-solution religion.

I agree that firewalls are quite often being sold and used based on
an illusion.  The generic term "security" is very hard to define, but
I think that risk management is part of the game.  Firewalls are
adequate tools for managing very specific risks/threats -- and they're
utterly useless for many other threats.

Firewalls can make weak protocols and bugs completely inaccessible or
unexploitable, and they're usually quite good at doing so.

BUT firewalls will not remove any weakness in protocols that run across
the firewall.  Firewalls don't add value (there are a few exemptions
of protocol-filtering proxies with some limited value).  Several
approaches exist to restrict the access to protocol weaknesses by
adding an initial authentication or tunneling, but again, in general
those do not remove any of the weaknesses of the original protocol(s)
which they proxy.

> internet at one stroke, if the DoS attack succeeds.

Firewalls reliably protect us from Internet-DoS attacks.  At the very
minimum they can limit the amount of damage.  Ping-of-Death will
cause some platforms to panic, and there is a significant difference
between a panic+unavailability of a firewall proxy machine and the 
panic of an application server that runs a database.

If one can alternatively or does always use private network connections
for running one's vital business functions, then using a complex firewall
will limit the damage to a mere "inconvenience" (i.e. repetetive temporary
unavailability of the firewall proxy).  Leaving one's application servers
accessible to nastygrams like PoD from the Internet is a significant risk.

> too many places on the Internet.

As I said, firewalls are useful for risk management, especially for
limiting the effects of many unkown risks.

The common misconception is that firewalls offer security.  
I must agree with you that this is wrong.  Firewalls only hide 
vulnerabilities.  Simple packet filters are mostly configured to hide
known vulnerabilities.  Complex firewalls are often configured to
additionally hide many unknown vulnerabilities, especially DoS attacks.

-Martin

---

From: [email-masked] (Johan Danielsson)
Date: 02 Dec 1997 02:31:14 +0100

Martin Rex <[email-masked]> writes:

> BUT firewalls will not remove any weakness in protocols that run
> across the firewall.

BUT they do make it more difficult to use secure (non-standard if you
like) protocols, like Kerberos. This will actually lower the level
security, possibly for someone else than the firewall owner. In this
context, I don't think it's wrong to label firewalls as evil. With or
without offensive language.

Now, can we stick to the real subject?

/Johan