oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

Some more introduction. Switch to me.

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@4376 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Johan Danielsson
1998-02-03 06:33:27 +00:00
parent 1a3ded01ed
commit 6e9d984304
2 changed files with 394 additions and 340 deletions
Download Patch File Download Diff File Expand all files Collapse all files

367
doc/draft-foo3.ms
View File

@@ -1,146 +1,201 @@
.pl 10.0i .\" even if this file is called .ms, it's using the me macros.
.po 0 .\" to format try something like `nroff -me'
.ll 7.2i .\" level 2 heading
.lt 7.2i .de HH
.nr LL 7.2i .$p "\\$2" "" "\\$1"
.nr LT 7.2i .$0 "\\$2"
.ds LF Westerlund, Danielsson
.ds RF [Page %]
.ds CF
.ds LH Internet Draft
.ds RH November, 1997
.ds CH Kerberos vs firewalls
.de Ip
.in 6
.ta 3
.ti -3
\\$1\t\c
.. ..
.\" make sure footnotes produce the right thing with nroff
.ie t \
\{\
.ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
.ds } \s0\v'0.4m'
.\}
.el \
\{\
.ds { [
.ds } ]
.\}
.ds * \\*{\\n($f\\*}\k*
.\" page footer
.fo 'Westerlund, Danielsson''[Page %]'
.\" date
.ds RH \*(mo, 19\n(yr
.\" left margin
.nr lm 6
.\" heading indent per level
.nr si 3n
.\" footnote indent
.nr fi 0
.\" paragraph indent
.nr po 0
.\" don't hyphenate
.hy 0 .hy 0
.\" left adjustment
.ad l .ad l
.\" indent 0
.in 0 .in 0
.\" line length 16cm and page length 25cm (~10 inches)
.ll 16c
.pl 25c
.ta \n(.luR .ta \n(.luR
.nf .nf
Network Working Group Assar Westerlund Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-firewalls.txt> SICS <draft-ietf-cat-krb5-firewalls.txt> SICS
Internet-Draft Johan Danielsson Internet-Draft Johan Danielsson
November, 1997 PDC, KTH \*(RH PDC, KTH
Expire in six months Expire in six months
.fi .fi
.\" page header, has to be set here so it won't appear on page 1
.he 'Internet Draft'Kerberos vs firewalls'\*(RH'
.ce .ce
Kerberos vs firewalls .b "Kerberos vs firewalls"
.ti 0 .HH 1 "Status of this Memo"
Status of this Memo .lp
.in 3
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its areas,
areas, and its working groups. Note that other groups may also and its working groups. Note that other groups may also distribute
distribute working documents as Internet-Drafts. working documents as Internet-Drafts.
.lp
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet- Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as \*(lqwork in progress.\*(rq
\*Qwork in progress.\*U .lp
To view the entire list of current Internet-Drafts, please check the
To view the entire list of current Internet-Drafts, please check \*(lq1id-abstracts.txt\*(rq listing contained in the Internet-Drafts
the \*Q1id-abstracts.txt\*U listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East ftp.isi.edu (US West Coast).
Coast), or ftp.isi.edu (US West Coast). .lp
Distribution of this memo is unlimited. Please send comments to the Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list. <cat-ietf@mit.edu> mailing list.
.HH 1 "Abstract"
.ti 0 .lp
Abstract Kerberos and firewalls both deal with security, but because of the
anti-social nature of firewalls, they don't get along very well. This
.ti 0 memo discusses ways to use Kerberos in a firewalled environment.
Introduction .HH 1 "Introduction"
.lp
Kerberos[RFC1510] is a protocol for authenticating parties Kerberos[RFC1510]
communicating over insecure networks. .(d
[RFC1510]
Firewalling is a technique for achieving an illusion of security by Kohl, J. and Neuman, C., \*(lqThe Kerberos Network Authentication
putting restrictions on what kinds of packets and how these are sent Service (V5)\*(rq, RFC 1510, September 1993.
between the internal (so called \*Qsecure\*U) network and the global (or .)d
\*Qinsecure\*U) Internet. is a protocol for authenticating parties communicating over insecure
networks. Firewalling is a technique for achieving an illusion of
.ti 0 security by putting restrictions on what kinds of packets and how
Definitions these are sent between the internal (so called \*(lqsecure\*(rq)
network and the global (or \*(lqinsecure\*(rq) Internet. The problems
client: the user, process, and host acquiring tickets from the KDC and with firewalls are many, but to name a few:
authenticating itself to the kerberised server. .np
Firewalls usually doesn't allow people to use UDP. The reason for this
KDC: the Kerberos Key Distribution Center is that UDP is (by firewall advocates) considered insecure. This
belief is probably based on the fact that many \(*lqinsecure\*(rq
Kerberised server: the server using Kerberos to authenticate the protocols (like NFS) use UDP. UDP packets are also considered easy to
client, for example telnetd. fake.
.np
.ti 0 Firewalls usually doesn't allow people to connect to arbitrary ports,
Firewalls such as the ports used when talking to the KDC.
.np
A firewall is usually placed between the \*Qinside\*U and the In many non-computer organisations, the computer staff isn't what you
\*Qoutside\*U networks, and is supposed to protect the inside from the would call a \(*lqwizards\*(rq; a typical case an academic
institution, where someone is taking care of the computers part time,
and is doing research the rest of the time. Adding a complex device
like a firewall to an environment like this, often leads to poorly run
systems that is more a hindrance for the legitimate users than to
possible crackers.
.lp
The easiest way to deal with firewalls is to ignore them, however in
some cases this just isn't possible. You might have users that are
stuck behind a firewall, but also has to access your system, or you
might find yourself behind a firewall, for instance when out
travelling.
.lp
To make it possible for people to use Kerberos from behind a firewall,
there are several things to consider.
.(q
.i
Add things to do when stuck behind a firewall, like talking about the
problem with local staff, making them open some port in the firewall,
using some other port, or proxy.
.r
.)q
.HH 1 "Firewalls"
.lp
A firewall is usually placed between the \*(lqinside\*(rq and the
\*(lqoutside\*(rq networks, and is supposed to protect the inside from the
evils on the outside. There are different kinds of firewalls. The evils on the outside. There are different kinds of firewalls. The
main differences are in the way they forward packets. main differences are in the way they forward (or doesn't) packets.
.ip \(bu
.Ip \(bu
The most straight forward type is the one that just imposes The most straight forward type is the one that just imposes
restrictions on incoming packets. Such a firewall could be described restrictions on incoming packets. Such a firewall could be described
as a router that filters packets that match some criteria. as a router that filters packets that match some criteria.
.ip \(bu
.Ip \(bu They may also \*(lqhide\*(rq some or all addresses on the inside of the
They may also \*Qhide\*U some or all addresses on the inside of the
firewall, replacing the addresses in the outgoing packets with the firewall, replacing the addresses in the outgoing packets with the
address of the firewall (aka network address translation, or NAT). NAT address of the firewall (aka network address translation, or NAT). NAT
can also be used without any packet filtering, for instance when you 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 have more than one host sharing a single address (e.g with a dialed-in
dialed-in PPP connection). PPP connection).
.ip
.in 3
There are also firewalls that does NAT both on the inside and the 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 outside (a server on the inside will see this as a connection from the
firewall). firewall).
.ip \(bu
.Ip \(bu
A third type is the proxy type firewall, that parses the contents of 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 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 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 with this kind of firewall, a protocol module that handles KDC
requests has to be written. requests has to be written\**.
.(f
.in 3 \**Instead of writing a new module for Kerberos, it can be possible to
hitch a ride on some other protocol, that's already beeing handled by
the proxy.
.)f
.lp
This type of firewall might also cause extra trouble when used with This type of firewall might also cause extra trouble when used with
kerberised versions of protocols that the proxy understands, in kerberised versions of protocols that the proxy understands, in
addition to the ones mentioned below. This is the case with the FTP 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 Security Extensions [RFC2228],
FTP protocol [RFC959], for integrity, confidentiality, and privacy .(d
protecting commands. When transferring data, the FTP protocol uses a [RFC2228]
separate data channel, and an FTP proxy will have to look out for Horowitz, M. and Lunt, S., \*(lqFTP Security Extensions\*(rq, RFC2228,
commands that start a data transfer. If all commands are encrypted, October 1997.
this is impossible. A protocol that doesn't suffer from this is the .)d
Telnet Authentication Option [RFC1416] that does all authentication that adds a new set of commands to the FTP protocol [RFC959],
and encryption in-bound. .(d
[RFC959] Postel, J. and Reynolds, J., \*(lqFile Transfer Protocol
.ti 0 (FTP)\*(rq, RFC 969, October 1985
Scenarios .)d
for integrity, confidentiality, and privacy protecting commands, and
data. 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]
.(d
[RFC1416]
Borman, D., \*(lqTelnet Authentication Option\*(rq, RFC 1416, February
1993.
.)d
that does all
authentication and encryption in-bound.
.HH 1 "Scenarios"
.lp
Here the different scenarios we have considered are described, the Here the different scenarios we have considered are described, the
problems they introduce and the proposed ways of solving them. problems they introduce and the proposed ways of solving them.
Combinations of these can also occur. Combinations of these can also occur.
.HH 2 "Client behind firewall"
.ti 1 .lp
Client behind firewall
This is the most typical and common scenario. First of all the client 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 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 whatever means and is usually much simpler when the KDC is able to
communicate over TCP. communicate over TCP.
.lp
Apart from that, the client needs to be sure that the ticket it will 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 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 its firewall. For this, it needs to add the address(es) of potential
@@ -148,86 +203,58 @@ firewalls between itself and the KDC/server, to the list of its own
addresses when requesting the ticket. We are not aware of any addresses when requesting the ticket. We are not aware of any
protocol for determining this set of addresses, thus this will have to protocol for determining this set of addresses, thus this will have to
be manually configured in the client. be manually configured in the client.
.lp
The client could also request a ticket with no addresses, but some The client could also request a ticket with no addresses. This is not
KDCs and servers might not accept such a ticket. a recommended way to solve this problem. The address was put into the
ticket to make it harder to use a stolen ticket. A ticket without
addresses will therefore be less \*(lqsecure.\*(rq RFC1510 also says that
the KDC may refuse to issue, and the server may refuse to accept an
address-less ticket.
.lp
With the ticket in possession, communication with the kerberised With the ticket in possession, communication with the kerberised
server will not need to be any different from communicating between a server will not need to be any different from communicating between a
non-kerberised client and server. non-kerberised client and server.
.HH 2 "Kerberised server behind firewall"
.ti 1 .lp
Kerberised server behind firewall The kerberised server does not talk to the KDC at all, so nothing
The kerberised server does not talk to the KDC at all so nothing
beyond normal firewall-traversal techniques for reaching the server beyond normal firewall-traversal techniques for reaching the server
itself needs to be applied. itself needs to be applied.
.lp
The kerberised server needs to be able to retrieve the original If the firewall rewrites the clients address, the server will have to
address (before its firewall) that the request was sent for. If this use some other (possibly firewall specific) protocol to retrieve the
is done via some out-of-band mechanism or it's directly able to see it original address. If this is not possible, the address field will have
doesn't matter. to be ignored. This has the same effect as if there were no addresses
in the ticket (see the discussion above).
.ti 1 .HH 2 "KDC behind firewall"
KDC behind firewall .lp
The KDC is in this respect basically just like any other server.
The same restrictions applies for a KDC as for any other server. .\" .uh "Specification"
.HH 1 "Security considerations"
.ti 0 .lp
Specification
.ti 0
Security considerations
.in 3
Since the whole network behind a NAT-type firewall looks like one Since the whole network behind a NAT-type firewall looks like one
computer from the outside, any security added by the addresses in the computer from the outside, any security added by the addresses in the
ticket will be lost. ticket will be lost.
.HH 1 "References"
.ti 0 .lp
References .pd
.HH 1 "Authors' Addresses"
[RFC959] Postel, J. and Reynolds, J., \*QFile Transfer Protocol .lp
(FTP)\*U, RFC 969, October 1985 .nf
[RFC1416] Borman, D., \*QTelnet Authentication Option\*U, RFC 1416,
February 1993.
[RFC1510] Kohl, J. and Neuman, C., \*QThe Kerberos Network
Authentication Service (V5)\*U, RFC 1510, September 1993.
[RFC2228] Horowitz, M. and Lunt, S., \*QFTP Security Extensions\*U,
RFC2228, October 1997.
.ti 0
Authors' Addresses
Assar Westerlund Assar Westerlund
.br
Swedish Institute of Computer Science Swedish Institute of Computer Science
.br
Box 1263 Box 1263
.br S-164 29 KISTA
S-164 29 KISTA .sp
.br
Sweden
Phone: +46-8-7521526 Phone: +46-8-7521526
.br Fax: +46-8-7517230
Fax: +46-8-7517230
.br
EMail: assar@sics.se EMail: assar@sics.se
.sp 2
Johan Danielsson Johan Danielsson
.br Center for Parallel Computers
PDC, KTH KTH
.br S-100 44 STOCKHOLM
S-100 44 STOCKHOLM .sp
.br Phone: +46-8-7906356
Sweden Fax: +46-8-247784
Phone: +46-8-7907885
.br
Fax: +46-8-247784
.br
EMail: joda@pdc.kth.se EMail: joda@pdc.kth.se
.fi

367
doc/standardisation/draft-foo3.ms
View File

@@ -1,146 +1,201 @@
.pl 10.0i .\" even if this file is called .ms, it's using the me macros.
.po 0 .\" to format try something like `nroff -me'
.ll 7.2i .\" level 2 heading
.lt 7.2i .de HH
.nr LL 7.2i .$p "\\$2" "" "\\$1"
.nr LT 7.2i .$0 "\\$2"
.ds LF Westerlund, Danielsson
.ds RF [Page %]
.ds CF
.ds LH Internet Draft
.ds RH November, 1997
.ds CH Kerberos vs firewalls
.de Ip
.in 6
.ta 3
.ti -3
\\$1\t\c
.. ..
.\" make sure footnotes produce the right thing with nroff
.ie t \
\{\
.ds { \v'-0.4m'\x'\\n(0x=0*-0.2m'\s-3
.ds } \s0\v'0.4m'
.\}
.el \
\{\
.ds { [
.ds } ]
.\}
.ds * \\*{\\n($f\\*}\k*
.\" page footer
.fo 'Westerlund, Danielsson''[Page %]'
.\" date
.ds RH \*(mo, 19\n(yr
.\" left margin
.nr lm 6
.\" heading indent per level
.nr si 3n
.\" footnote indent
.nr fi 0
.\" paragraph indent
.nr po 0
.\" don't hyphenate
.hy 0 .hy 0
.\" left adjustment
.ad l .ad l
.\" indent 0
.in 0 .in 0
.\" line length 16cm and page length 25cm (~10 inches)
.ll 16c
.pl 25c
.ta \n(.luR .ta \n(.luR
.nf .nf
Network Working Group Assar Westerlund Network Working Group Assar Westerlund
<draft-ietf-cat-krb5-firewalls.txt> SICS <draft-ietf-cat-krb5-firewalls.txt> SICS
Internet-Draft Johan Danielsson Internet-Draft Johan Danielsson
November, 1997 PDC, KTH \*(RH PDC, KTH
Expire in six months Expire in six months
.fi .fi
.\" page header, has to be set here so it won't appear on page 1
.he 'Internet Draft'Kerberos vs firewalls'\*(RH'
.ce .ce
Kerberos vs firewalls .b "Kerberos vs firewalls"
.ti 0 .HH 1 "Status of this Memo"
Status of this Memo .lp
.in 3
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its areas,
areas, and its working groups. Note that other groups may also and its working groups. Note that other groups may also distribute
distribute working documents as Internet-Drafts. working documents as Internet-Drafts.
.lp
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet- Drafts as reference
Drafts as reference material or to cite them other than as material or to cite them other than as \*(lqwork in progress.\*(rq
\*Qwork in progress.\*U .lp
To view the entire list of current Internet-Drafts, please check the
To view the entire list of current Internet-Drafts, please check \*(lq1id-abstracts.txt\*(rq listing contained in the Internet-Drafts
the \*Q1id-abstracts.txt\*U listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East ftp.isi.edu (US West Coast).
Coast), or ftp.isi.edu (US West Coast). .lp
Distribution of this memo is unlimited. Please send comments to the Distribution of this memo is unlimited. Please send comments to the
<cat-ietf@mit.edu> mailing list. <cat-ietf@mit.edu> mailing list.
.HH 1 "Abstract"
.ti 0 .lp
Abstract Kerberos and firewalls both deal with security, but because of the
anti-social nature of firewalls, they don't get along very well. This
.ti 0 memo discusses ways to use Kerberos in a firewalled environment.
Introduction .HH 1 "Introduction"
.lp
Kerberos[RFC1510] is a protocol for authenticating parties Kerberos[RFC1510]
communicating over insecure networks. .(d
[RFC1510]
Firewalling is a technique for achieving an illusion of security by Kohl, J. and Neuman, C., \*(lqThe Kerberos Network Authentication
putting restrictions on what kinds of packets and how these are sent Service (V5)\*(rq, RFC 1510, September 1993.
between the internal (so called \*Qsecure\*U) network and the global (or .)d
\*Qinsecure\*U) Internet. is a protocol for authenticating parties communicating over insecure
networks. Firewalling is a technique for achieving an illusion of
.ti 0 security by putting restrictions on what kinds of packets and how
Definitions these are sent between the internal (so called \*(lqsecure\*(rq)
network and the global (or \*(lqinsecure\*(rq) Internet. The problems
client: the user, process, and host acquiring tickets from the KDC and with firewalls are many, but to name a few:
authenticating itself to the kerberised server. .np
Firewalls usually doesn't allow people to use UDP. The reason for this
KDC: the Kerberos Key Distribution Center is that UDP is (by firewall advocates) considered insecure. This
belief is probably based on the fact that many \(*lqinsecure\*(rq
Kerberised server: the server using Kerberos to authenticate the protocols (like NFS) use UDP. UDP packets are also considered easy to
client, for example telnetd. fake.
.np
.ti 0 Firewalls usually doesn't allow people to connect to arbitrary ports,
Firewalls such as the ports used when talking to the KDC.
.np
A firewall is usually placed between the \*Qinside\*U and the In many non-computer organisations, the computer staff isn't what you
\*Qoutside\*U networks, and is supposed to protect the inside from the would call a \(*lqwizards\*(rq; a typical case an academic
institution, where someone is taking care of the computers part time,
and is doing research the rest of the time. Adding a complex device
like a firewall to an environment like this, often leads to poorly run
systems that is more a hindrance for the legitimate users than to
possible crackers.
.lp
The easiest way to deal with firewalls is to ignore them, however in
some cases this just isn't possible. You might have users that are
stuck behind a firewall, but also has to access your system, or you
might find yourself behind a firewall, for instance when out
travelling.
.lp
To make it possible for people to use Kerberos from behind a firewall,
there are several things to consider.
.(q
.i
Add things to do when stuck behind a firewall, like talking about the
problem with local staff, making them open some port in the firewall,
using some other port, or proxy.
.r
.)q
.HH 1 "Firewalls"
.lp
A firewall is usually placed between the \*(lqinside\*(rq and the
\*(lqoutside\*(rq networks, and is supposed to protect the inside from the
evils on the outside. There are different kinds of firewalls. The evils on the outside. There are different kinds of firewalls. The
main differences are in the way they forward packets. main differences are in the way they forward (or doesn't) packets.
.ip \(bu
.Ip \(bu
The most straight forward type is the one that just imposes The most straight forward type is the one that just imposes
restrictions on incoming packets. Such a firewall could be described restrictions on incoming packets. Such a firewall could be described
as a router that filters packets that match some criteria. as a router that filters packets that match some criteria.
.ip \(bu
.Ip \(bu They may also \*(lqhide\*(rq some or all addresses on the inside of the
They may also \*Qhide\*U some or all addresses on the inside of the
firewall, replacing the addresses in the outgoing packets with the firewall, replacing the addresses in the outgoing packets with the
address of the firewall (aka network address translation, or NAT). NAT address of the firewall (aka network address translation, or NAT). NAT
can also be used without any packet filtering, for instance when you 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 have more than one host sharing a single address (e.g with a dialed-in
dialed-in PPP connection). PPP connection).
.ip
.in 3
There are also firewalls that does NAT both on the inside and the 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 outside (a server on the inside will see this as a connection from the
firewall). firewall).
.ip \(bu
.Ip \(bu
A third type is the proxy type firewall, that parses the contents of 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 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 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 with this kind of firewall, a protocol module that handles KDC
requests has to be written. requests has to be written\**.
.(f
.in 3 \**Instead of writing a new module for Kerberos, it can be possible to
hitch a ride on some other protocol, that's already beeing handled by
the proxy.
.)f
.lp
This type of firewall might also cause extra trouble when used with This type of firewall might also cause extra trouble when used with
kerberised versions of protocols that the proxy understands, in kerberised versions of protocols that the proxy understands, in
addition to the ones mentioned below. This is the case with the FTP 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 Security Extensions [RFC2228],
FTP protocol [RFC959], for integrity, confidentiality, and privacy .(d
protecting commands. When transferring data, the FTP protocol uses a [RFC2228]
separate data channel, and an FTP proxy will have to look out for Horowitz, M. and Lunt, S., \*(lqFTP Security Extensions\*(rq, RFC2228,
commands that start a data transfer. If all commands are encrypted, October 1997.
this is impossible. A protocol that doesn't suffer from this is the .)d
Telnet Authentication Option [RFC1416] that does all authentication that adds a new set of commands to the FTP protocol [RFC959],
and encryption in-bound. .(d
[RFC959] Postel, J. and Reynolds, J., \*(lqFile Transfer Protocol
.ti 0 (FTP)\*(rq, RFC 969, October 1985
Scenarios .)d
for integrity, confidentiality, and privacy protecting commands, and
data. 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]
.(d
[RFC1416]
Borman, D., \*(lqTelnet Authentication Option\*(rq, RFC 1416, February
1993.
.)d
that does all
authentication and encryption in-bound.
.HH 1 "Scenarios"
.lp
Here the different scenarios we have considered are described, the Here the different scenarios we have considered are described, the
problems they introduce and the proposed ways of solving them. problems they introduce and the proposed ways of solving them.
Combinations of these can also occur. Combinations of these can also occur.
.HH 2 "Client behind firewall"
.ti 1 .lp
Client behind firewall
This is the most typical and common scenario. First of all the client 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 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 whatever means and is usually much simpler when the KDC is able to
communicate over TCP. communicate over TCP.
.lp
Apart from that, the client needs to be sure that the ticket it will 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 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 its firewall. For this, it needs to add the address(es) of potential
@@ -148,86 +203,58 @@ firewalls between itself and the KDC/server, to the list of its own
addresses when requesting the ticket. We are not aware of any addresses when requesting the ticket. We are not aware of any
protocol for determining this set of addresses, thus this will have to protocol for determining this set of addresses, thus this will have to
be manually configured in the client. be manually configured in the client.
.lp
The client could also request a ticket with no addresses, but some The client could also request a ticket with no addresses. This is not
KDCs and servers might not accept such a ticket. a recommended way to solve this problem. The address was put into the
ticket to make it harder to use a stolen ticket. A ticket without
addresses will therefore be less \*(lqsecure.\*(rq RFC1510 also says that
the KDC may refuse to issue, and the server may refuse to accept an
address-less ticket.
.lp
With the ticket in possession, communication with the kerberised With the ticket in possession, communication with the kerberised
server will not need to be any different from communicating between a server will not need to be any different from communicating between a
non-kerberised client and server. non-kerberised client and server.
.HH 2 "Kerberised server behind firewall"
.ti 1 .lp
Kerberised server behind firewall The kerberised server does not talk to the KDC at all, so nothing
The kerberised server does not talk to the KDC at all so nothing
beyond normal firewall-traversal techniques for reaching the server beyond normal firewall-traversal techniques for reaching the server
itself needs to be applied. itself needs to be applied.
.lp
The kerberised server needs to be able to retrieve the original If the firewall rewrites the clients address, the server will have to
address (before its firewall) that the request was sent for. If this use some other (possibly firewall specific) protocol to retrieve the
is done via some out-of-band mechanism or it's directly able to see it original address. If this is not possible, the address field will have
doesn't matter. to be ignored. This has the same effect as if there were no addresses
in the ticket (see the discussion above).
.ti 1 .HH 2 "KDC behind firewall"
KDC behind firewall .lp
The KDC is in this respect basically just like any other server.
The same restrictions applies for a KDC as for any other server. .\" .uh "Specification"
.HH 1 "Security considerations"
.ti 0 .lp
Specification
.ti 0
Security considerations
.in 3
Since the whole network behind a NAT-type firewall looks like one Since the whole network behind a NAT-type firewall looks like one
computer from the outside, any security added by the addresses in the computer from the outside, any security added by the addresses in the
ticket will be lost. ticket will be lost.
.HH 1 "References"
.ti 0 .lp
References .pd
.HH 1 "Authors' Addresses"
[RFC959] Postel, J. and Reynolds, J., \*QFile Transfer Protocol .lp
(FTP)\*U, RFC 969, October 1985 .nf
[RFC1416] Borman, D., \*QTelnet Authentication Option\*U, RFC 1416,
February 1993.
[RFC1510] Kohl, J. and Neuman, C., \*QThe Kerberos Network
Authentication Service (V5)\*U, RFC 1510, September 1993.
[RFC2228] Horowitz, M. and Lunt, S., \*QFTP Security Extensions\*U,
RFC2228, October 1997.
.ti 0
Authors' Addresses
Assar Westerlund Assar Westerlund
.br
Swedish Institute of Computer Science Swedish Institute of Computer Science
.br
Box 1263 Box 1263
.br S-164 29 KISTA
S-164 29 KISTA .sp
.br
Sweden
Phone: +46-8-7521526 Phone: +46-8-7521526
.br Fax: +46-8-7517230
Fax: +46-8-7517230
.br
EMail: assar@sics.se EMail: assar@sics.se
.sp 2
Johan Danielsson Johan Danielsson
.br Center for Parallel Computers
PDC, KTH KTH
.br S-100 44 STOCKHOLM
S-100 44 STOCKHOLM .sp
.br Phone: +46-8-7906356
Sweden Fax: +46-8-247784
Phone: +46-8-7907885
.br
Fax: +46-8-247784
.br
EMail: joda@pdc.kth.se EMail: joda@pdc.kth.se
.fi