1 2 3 4 5 6 7Network Working Group Assar Westerlund 8<draft-ietf-cat-krb5-firewalls.txt> SICS 9Internet-Draft Johan Danielsson 10November, 1997 PDC, KTH 11Expire in six months 12 13 Kerberos vs firewalls 14 15Status of this Memo 16 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 21 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 26 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 32 33 Distribution of this memo is unlimited. Please send comments to the 34 <cat-ietf@mit.edu> mailing list. 35 36Abstract 37 38Introduction 39 40 Kerberos[RFC1510] is a protocol for authenticating parties 41 communicating over insecure networks. 42 43 Firewalling is a technique for achieving an illusion of security by 44 putting restrictions on what kinds of packets and how these are sent 45 between the internal (so called "secure") network and the global (or 46 "insecure") Internet. 47 48Definitions 49 50 client: the user, process, and host acquiring tickets from the KDC 51 and authenticating itself to the kerberised server. 52 53 KDC: the Kerberos Key Distribution Center 54 55 56 57 58Westerlund, Danielsson [Page 1] 59 60Internet Draft Kerberos vs firewalls November, 1997 61 62 63 Kerberised server: the server using Kerberos to authenticate the 64 client, for example telnetd. 65 66Firewalls 67 68 A firewall is usually placed between the "inside" and the "outside" 69 networks, and is supposed to protect the inside from the evils on the 70 outside. There are different kinds of firewalls. The main 71 differences are in the way they forward packets. 72 73 o+ The most straight forward type is the one that just imposes 74 restrictions on incoming packets. Such a firewall could be 75 described as a router that filters packets that match some 76 criteria. 77 78 o+ They may also "hide" some or all addresses on the inside of the 79 firewall, replacing the addresses in the outgoing packets with the 80 address of the firewall (aka network address translation, or NAT). 81 NAT can also be used without any packet filtering, for instance 82 when you have more than one host sharing a single address (for 83 example, with a dialed-in PPP connection). 84 85 There are also firewalls that does NAT both on the inside and the 86 outside (a server on the inside will see this as a connection from 87 the firewall). 88 89 o+ A third type is the proxy type firewall, that parses the contents 90 of the packets, basically acting as a server to the client, and as 91 a client to the server (man-in-the-middle). If Kerberos is to be 92 used with this kind of firewall, a protocol module that handles 93 KDC requests has to be written. 94 95 This type of firewall might also cause extra trouble when used with 96 kerberised versions of protocols that the proxy understands, in 97 addition to the ones mentioned below. This is the case with the FTP 98 Security Extensions [RFC2228], that adds a new set of commands to the 99 FTP protocol [RFC959], for integrity, confidentiality, and privacy 100 protecting commands. When transferring data, the FTP protocol uses a 101 separate data channel, and an FTP proxy will have to look out for 102 commands that start a data transfer. If all commands are encrypted, 103 this is impossible. A protocol that doesn't suffer from this is the 104 Telnet Authentication Option [RFC1416] that does all authentication 105 and encryption in-bound. 106 107Scenarios 108 109 Here the different scenarios we have considered are described, the 110 problems they introduce and the proposed ways of solving them. 111 112 113 114Westerlund, Danielsson [Page 2] 115 116Internet Draft Kerberos vs firewalls November, 1997 117 118 119 Combinations of these can also occur. 120 121 Client behind firewall 122 123 This is the most typical and common scenario. First of all the 124 client needs some way of communicating with the KDC. This can be 125 done with whatever means and is usually much simpler when the KDC is 126 able to communicate over TCP. 127 128 Apart from that, the client needs to be sure that the ticket it will 129 acquire from the KDC can be used to authenticate to a server outside 130 its firewall. For this, it needs to add the address(es) of potential 131 firewalls between itself and the KDC/server, to the list of its own 132 addresses when requesting the ticket. We are not aware of any 133 protocol for determining this set of addresses, thus this will have 134 to be manually configured in the client. 135 136 The client could also request a ticket with no addresses, but some 137 KDCs and servers might not accept such a ticket. 138 139 With the ticket in possession, communication with the kerberised 140 server will not need to be any different from communicating between a 141 non-kerberised client and server. 142 143 Kerberised server behind firewall 144 145 The kerberised server does not talk to the KDC at all so nothing 146 beyond normal firewall-traversal techniques for reaching the server 147 itself needs to be applied. 148 149 The kerberised server needs to be able to retrieve the original 150 address (before its firewall) that the request was sent for. If this 151 is done via some out-of-band mechanism or it's directly able to see 152 it doesn't matter. 153 154 KDC behind firewall 155 156 The same restrictions applies for a KDC as for any other server. 157 158Specification 159 160Security considerations 161 162 This memo does not introduce any known security considerations in 163 addition to those mentioned in [RFC1510]. 164 165References 166 167 168 169 170Westerlund, Danielsson [Page 3] 171 172Internet Draft Kerberos vs firewalls November, 1997 173 174 175 [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)", 176 RFC 969, October 1985 177 178 [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416, 179 February 1993. 180 181 [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network 182 Authentication Service (V5)", RFC 1510, September 1993. 183 184 [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions", 185 RFC2228, October 1997. 186 187Authors' Addresses 188 189 Assar Westerlund 190 Swedish Institute of Computer Science 191 Box 1263 192 S-164 29 KISTA 193 Sweden 194 195 Phone: +46-8-7521526 196 Fax: +46-8-7517230 197 EMail: assar@sics.se 198 199 Johan Danielsson 200 PDC, KTH 201 S-100 44 STOCKHOLM 202 Sweden 203 204 Phone: +46-8-7907885 205 Fax: +46-8-247784 206 EMail: joda@pdc.kth.se 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226Westerlund, Danielsson [Page 4] 227 228