idnits 2.17.1 draft-ietf-cat-krb5-firewalls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2228], [RFC1510], [RFC1416], [RFC959]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 969 (ref. 'RFC959') (Obsoleted by RFC 998) ** Obsolete normative reference: RFC 1416 (Obsoleted by RFC 2941) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Assar Westerlund 3 SICS 4 Internet-Draft Johan Danielsson 5 November, 1997 PDC, KTH 6 Expire in six months 8 Kerberos vs firewalls 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this memo is unlimited. Please send comments to the 29 mailing list. 31 Abstract 33 Introduction 35 Kerberos[RFC1510] is a protocol for authenticating parties 36 communicating over insecure networks. 38 Firewalling is a technique for achieving an illusion of security by 39 putting restrictions on what kinds of packets and how these are sent 40 between the internal (so called ''secure'') network and the global (or 41 ''insecure'') Internet. 43 Definitions 45 client: the user, process, and host acquiring tickets from the KDC 46 and authenticating itself to the kerberised server. 48 KDC: the Kerberos Key Distribution Center 49 Kerberised server: the server using Kerberos to authenticate the 50 client, for example telnetd. 52 Firewalls 54 A firewall is usually placed between the "inside" and the "outside" 55 networks, and is supposed to protect the inside from the evils on the 56 outside. There are different kinds of firewalls. The main 57 differences are in the way they forward packets. 59 o+ The most straight forward type is the one that just imposes 60 restrictions on incoming packets. Such a firewall could be 61 described as a router that filters packets that match some 62 criteria. 64 o+ They may also "hide" some or all addresses on the inside of the 65 firewall, replacing the addresses in the outgoing packets with the 66 address of the firewall (aka network address translation, or NAT). 67 NAT can also be used without any packet filtering, for instance 68 when you have more than one host sharing a single address (for 69 example, with a dialed-in PPP connection). 71 There are also firewalls that does NAT both on the inside and the 72 outside (a server on the inside will see this as a connection from 73 the firewall). 75 o+ A third type is the proxy type firewall, that parses the contents 76 of the packets, basically acting as a server to the client, and as 77 a client to the server (man-in-the-middle). If Kerberos is to be 78 used with this kind of firewall, a protocol module that handles 79 KDC requests has to be written. 81 This type of firewall might also cause extra trouble when used with 82 kerberised versions of protocols that the proxy understands, in 83 addition to the ones mentioned below. This is the case with the FTP 84 Security Extensions [RFC2228], that adds a new set of commands to the 85 FTP protocol [RFC959], for integrity, confidentiality, and privacy 86 protecting commands. When transferring data, the FTP protocol uses a 87 separate data channel, and an FTP proxy will have to look out for 88 commands that start a data transfer. If all commands are encrypted, 89 this is impossible. A protocol that doesn't suffer from this is the 90 Telnet Authentication Option [RFC1416] that does all authentication 91 and encryption in-bound. 93 Scenarios 95 Here the different scenarios we have considered are described, the 96 problems they introduce and the proposed ways of solving them. 98 Combinations of these can also occur. 100 Client behind firewall 102 This is the most typical and common scenario. First of all the 103 client needs some way of communicating with the KDC. This can be 104 done with whatever means and is usually much simpler when the KDC is 105 able to communicate over TCP. 107 Apart from that, the client needs to be sure that the ticket it will 108 acquire from the KDC can be used to authenticate to a server outside 109 its firewall. For this, it needs to add the address(es) of potential 110 firewalls between itself and the KDC/server, to the list of its own 111 addresses when requesting the ticket. We are not aware of any 112 protocol for determining this set of addresses, thus this will have 113 to be manually configured in the client. 115 The client could also request a ticket with no addresses, but some 116 KDCs and servers might not accept such a ticket. 118 With the ticket in possession, communication with the kerberised 119 server will not need to be any different from communicating between a 120 non-kerberised client and server. 122 Kerberised server behind firewall 124 The kerberised server does not talk to the KDC at all so nothing 125 beyond normal firewall-traversal techniques for reaching the server 126 itself needs to be applied. 128 The kerberised server needs to be able to retrieve the original 129 address (before its firewall) that the request was sent for. If this 130 is done via some out-of-band mechanism or it's directly able to see 131 it doesn't matter. 133 KDC behind firewall 135 The same restrictions applies for a KDC as for any other server. 137 Specification 139 Security considerations 141 This memo does not introduce any known security considerations in 142 addition to those mentioned in [RFC1510]. 144 References 146 [RFC959] Postel, J. and Reynolds, J., "File Transfer Protocol (FTP)", 147 RFC 969, October 1985 149 [RFC1416] Borman, D., "Telnet Authentication Option", RFC 1416, 150 February 1993. 152 [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network 153 Authentication Service (V5)", RFC 1510, September 1993. 155 [RFC2228] Horowitz, M. and Lunt, S., "FTP Security Extensions", 156 RFC2228, October 1997. 158 Authors' Addresses 160 Assar Westerlund 161 Swedish Institute of Computer Science 162 Box 1263 163 S-164 29 KISTA 164 Sweden 166 Phone: +46-8-7521526 167 Fax: +46-8-7517230 168 EMail: assar@sics.se 170 Johan Danielsson 171 PDC, KTH 172 S-100 44 STOCKHOLM 173 Sweden 175 Phone: +46-8-7907885 176 Fax: +46-8-247784 177 EMail: joda@pdc.kth.se