Network Working Group Michael Richardson mcr@sandelman.ottawa.on.ca
INTERNET-DRAFT SSH Communications Security
draft-richardson-ipsec-traversal-00.txt v1.1, 11 June 1997
Expires in six months
Firewall Traversal authorization system
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 learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).
Abstract
This document describes a public key certificate mechanism to authorize
traversal of multiple security gateways (firewalls). This work is inde-
pendant of transport layer in concept, and could apply to IPsec, TLS, or
SecSH. It is applied here to IPsec. The SPKI certificate format is used
here.
Michael Richardson mcr@sandelman.ottawa.on.ca [page 1]
INTERNET-DRAFT v1.1, 11 June 1997
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definition of terminology . . . . . . . . . . . . . . . . . 2
2. Introduction to the problem . . . . . . . . . . . . . . . . . . 3
2.1. Key Sharing methods . . . . . . . . . . . . . . . . . . . . 3
2.2. Stacked or tunnelled solutions . . . . . . . . . . . . . . . 4
2.3. Virtual Circuit solutions . . . . . . . . . . . . . . . . . 5
2.4. Issues raised . . . . . . . . . . . . . . . . . . . . . . . 6
3. Firewall traversal certificates . . . . . . . . . . . . . . . . 6
3.1. The IP-Gateway Certificate . . . . . . . . . . . . . . . . . 7
3.2. Definition of certificate . . . . . . . . . . . . . . . . . 7
3.3. An example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Completing the certificate loop . . . . . . . . . . . . . . 8
4. Security Considerations: . . . . . . . . . . . . . . . . . . . . 8
5. References: . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Expiration and File Name . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document is a result of recent discussions in the IETF ipsec, IETF
secsh and IETF mobileip working groups about how to trust security
gateways (aka firewalls) with end-to-end (host to host) encryption and
authentication keys.
This document describes the problem, some solutions which have been
suggested in the past, and then goes on to describe a system of public
key signed certificates that would allow a series of appropriate
connections to automatically be setup.
Gupta97-1 gives an expanded view of the problems, and other solutions.
Unlike Gupta97-1, this document does not limit itself to firewalls that
are known apriori, or under the same administrative control.
For a solution to be scalable to the entire internet, the policy must
either be learnt dynamically from correspondant nodes (e.g. arrived at
through negotiation), or must be available in some pre-existing global
database such as the domain name system.
1.1. Definition of terminology
Here is a network of two security gateways, a client node and a server
node.
C---{G1}---{G2}---S
C is the client.
G1/G1 are gateways.
S is the server.
Michael Richardson mcr@sandelman.ottawa.on.ca [page 2]
INTERNET-DRAFT v1.1, 11 June 1997
Since there are potentially more than one transport or network layer
connection, we define some terms to describe the different end points.
C is the transport layer originator. TLO
S is the transport layer target. TLT
C/G1
is a network layer originator/target pair. NLO/NLT/
G1/G2
is a network layer originator/target pair.
G2/S
is a network layer originator/target pair.
If discussing application layer protocols (e.g. SSH, TLS) through
security gateways, then the transport layer designations above should be
replaced with the session layer designations (e.g. URL, hostname), and
the network layer designations with transport layer designations (e.g.
TCP endpoints, SSH/TLS host keys).
The end points of the different types of connections will be denoted
with a subscript. So, when C is used in an TLO context, the symbol C_s
will be used (s for Server) . When C is used in a NLO context, the
symbol C_g1 or C_g2 will be used.
2. Introduction to the problem
The problem is not as some say, merely a question of allowing security
protocols to pass unexamined through a security gateway. Many
environments have very strong auditing requirements, and encrypted
traffic is by design, intended to thwart attempts for third parties to
eavesdrop.
Further, this policy relies on the security of target hosts being
perfect. Were this the case in practice, for all vendors, for all
releases, both new and old, the firewall might not be required at all.
2.1. Key Sharing methods
It has been suggested by several people XXX that a key sharing protocol
will solve the problem. The firewall(s) would be provided with the
encryption keys in order to examine the traffic. Alternately, a copy of
the authentication keys would allow the firewall to verify the origin of
the packets, thus allowing it to apply its access policy.
C <------+----------+------> S
G1 G2
This solution is not appropriate because the problem is more
complicated. In general there will be a combination of network address
translating firewall, topology hiding firewalls, and particularities of
Michael Richardson mcr@sandelman.ottawa.on.ca [page 3]
INTERNET-DRAFT v1.1, 11 June 1997
various protocols.
A host behind a network address translation may have an address that is
not available, or worse: illegal, to its correspondant node. The
firewall must therefore be involved during all the key exchange protocol
because the firewall (or the address that the ALT/ALO is translated to)
is the logical end point for the encryption, not the actual ALT/ALO.
When topology is hided by a firewall, there must be some mechanism to
map the connection to intended application layer target. That is,
despite the topology hiding, there is a need to name selected pieces of
the internal topology, and communicate that name to the firewall.
The difficulty of doing this in general for all protocols in first
generation application layer firewalls, even for outbound connections,
is what caused the development of protocols like SOCKS.
A firewall that supports protocols that use more than a single logical
connection also has a requirement to see the contents of the "control"
or "nameserver" connection. The typical example is FTP, but CuSeeMe,
RealAudio, SunRPC (portmap is the nameserver connection), and most
multicast protocols have this problem.
2.2. Stacked or tunnelled solutions
A second proposal is to stack algorithms. This is being proposed by
Gupta97-2 for the mobileIP group. This is best illustrated by a diagram.
C_s <------+----------+------> S_c
C_g2 <------+--------> G2_c***>
C_g1 <----> G1_c*****>
Each arrow represents a secure connection, the upper connections being
transported in the lower connections. Stars represent unencrypted (from
that layer's point of view) connections.
Note: there is n+1 layers when n gateways are involved. Two gateways are
typical (one at each location), but should two higher security networks
(e.g. research or finance) inside the lower security organizational
network need to communicate, this number rises to 4. Future topologies
could further increase n.
Some systems which have implemented this method include SOCKS: one runs
SOCKS inside SOCKS.
The most glaring problem, however, is that the data, if encrypted, is
opaque to both gateways! The traversal problem has been solved, but the
auditing and protocol requirements remain.
There is some difficulty with dealing with ICMP messages, since the
gateway may not be able to do anything with them.
The repeated encapsulation (tunnelling) of one packet inside another
increases the overhead, and for packet protocols, decreasing the amount
Michael Richardson mcr@sandelman.ottawa.on.ca [page 4]
INTERNET-DRAFT v1.1, 11 June 1997
of payload per packet.
This has serious efficiency and reliability implications. Node C may
have difficulty getting accurate ICMP messages back, and may not be able
to set its TCP MSS properly leading to excessive fragmentation. This
problem is not unique to this topology.
2.3. Virtual Circuit solutions
An alternate way to set up the associations is a series of adjacent
tunnels rather than a stack of tunnells. This is similar to what happens
in ATM networks with virtual circuits are setup. The ATM switches
negotiation frame ids between themselves and act as stateful routers.
There may still be a need for strong end to end security in this
situation, so the tunnels may be used to transport an end to end
security association. At most, there are two layers of security
associations with this method.
End to end C_s <--------+----------+--------> S_c
Hop by hop C_g1 <------>G1_c
G1_g2<---->G2_g1
G2_s<-----> S_g2
There are three ways to arrange the two sets of security associations:
1. Delegated traversal
the gateways may provide sufficient trust in identity that an
internal tunnel is not required. In that case, an upper protocol
may appear immediately inside the hop-by-hop security header. The
hop-by-hop SA's may provide authentication alone, or encryption
and integrity. On-the-wire IPsec packets might look like:
IP[C_g1->X] AH[C_g1->G1_c TCP/UDP/ICMP]
or
IP[C_g1->X] ESP[C_g1->G1_c TCP/UDP/ICMP]
2. Audited Traversal
If the gateways do not permit unexamined (i.e. encrypted) data to
pass through, then the end to end (C_s/S_c) SA must be
authentication only. The hop-by-hop SA's would have to provide the
privacy features. On-the-wire IPsec packets might look like:
IP[C_g1->X] ESP[C_g1->G1_c
IP[C_s->S_c] AH[C_s->S_c] TCP/UDP/IP/ICMP]
3. Authenticated traversal
If the gateways do allow encrypted data to pass through, then the
end to end SA's can include privacy features. The hop-by-hop SA
could be authentication only, or might include additional privacy
features to thwart traffic analysis. On-the-wire IPsec packets
Michael Richardson mcr@sandelman.ottawa.on.ca [page 5]
INTERNET-DRAFT v1.1, 11 June 1997
might look like:
IP[C_g1->X] AH[C_g1->G1_c
ESP[C_s->S_c] <whatever>]
or
IP[C_g1->X] ESP[C_g1->G1_c
ESP[C_s->S_c] <whatever>]
Some notes on above:
1. In the audited case (1) it is possible for the gateways to control
what kind of data can flow through by looking at the next protocol
header in the AH packet. Thus the gateway can prevent authorized
tunnels from being formed. The gateway could allow IP without
necessarily giving up the ability to audit. This is not the case for
the authenticate case, because once any ESP is allowed through, the
gateway gives up control of what protocols get transmitted through
the gateway.
2. At all times a single SA's could be used for different streams of
traffic (at the same sensitivity), or multiple SA's could be used for
a single stream of traffic.
3. in case 2, where there is an outer AH or integrity protected ESP, the
inner ESP need is NOT REQUIRED to also provide integrity protection,
but may do so.
4. the X above could be either S_c or it could be G1_c. It is not clear
which is more appropriate. In the NAT situation, there are reduced
choices, in the absense of NAT, either is possible. (ISSUE)
2.4. Issues raised
The following questions are posed, which this document will attempt to
resolve:
1. how does the client know that it can trust gateway g1 or g2?
2. how does the server know that it can trust gateway g1 or g2?
3. how to tell the real server who the real client is?
Problems #1 and #2 are related, and are solved by the same mechanism.
The information as to the real client is also passed by this proceedure.
3. Firewall traversal certificates
If one makes an analogy between security perimeters and altitudes, then
the end nodes can be thought of as being on plateaus, possibly with
several ledges on the way up, with large amounts of plain between
plateaus.
Michael Richardson mcr@sandelman.ottawa.on.ca [page 6]
INTERNET-DRAFT v1.1, 11 June 1997
Virtual private network tunnels are then bridges that span between
ledges/plateaus. Prior to building a bridge, some guide wires (symmetric
keys) must be established. To establish the guide wires requires sending
an ambassador out with appropriate proof of origin. The ambassador meets
up with a representative of the distant plateau, and they exchange
credentials. The meeting place, which occurs on the plain, at zero
altitude will be referred to as "security zone 0".
The wide open Internet is a good example of such a zone and it is
probably equivalent to sea level. In general, the security zone 0 is
just the lowest point on the path between the two security plateaus.
The remainder of this document is therefore a description of the
credentials that are provided by non-zero security zones to lower
altitude security levels.
3.1. The IP-Gateway Certificate
At each downward hop, a certificate is used to delegate the identity of
the ALO node to an lower security level gateway. At security level 0,
the ambassador meets with their counterpart. The counterpart also has a
set of certificates. Once proof of identify has been exchanged, the
ambassador needs to bring that proof back up to the security plateau.
The ambassador does this by using their own certificates.
The certificates are SPKI format. The issuer of the certificate is
ultimately the ALO or ALT node. The subject of the certificate is the
node to which authority is being delegated. The authentication being
delegated the list of hosts for which the gateway is authorized to speak
for.
In the simplest case, there is only one certificate issued by the
ALO/ALT nodes, and it can only delegate authority for itself. A more
complicated system would have an organizational CA or ISP based CA
signing a certificate that delegated a particular portion of the IP
address space to a particular key.
3.2. Definition of certificate
v4-network
this is followed by the v4 network prefix and the length of the
prefix. Hosts are indicated by a prefix length of 32.
v6-network
this is followed by the v6 network prefix and the length of the
prefix. Hosts are indicated by a prefix length of 128.
host
this is followed by a DNS name, or by a SDSI name
3.3. An example
For example, Somecompany.com used to use the class C subnet:
Michael Richardson mcr@sandelman.ottawa.on.ca [page 7]
INTERNET-DRAFT v1.1, 11 June 1997
192.1.2.128/26. This is further divided into several 16 address subnet
that exist behind a packet filter. Further firewalls inside did network
address translation as well. The network topology would look like:
X14---fw1----pf1---<INTERNET>
where X14 has a private network address, fw1 provides network address
translation, and pf1 provides filtering only. Also assume that this
organization had a IPv6 prefix of c0:ff:ee:04:ba:be::
Given that, DNSSEC would delegate authority for 192.1.2.128/26 and for
somecompany.com to the key SC1, then the following statements might be
made:
(cert (issuer SC1)
(subject pf1)
(auth (ip-gateway
(v4-network 205.233.54.128 26)
(v6-network c0:ff:ee:04:ba:be:: 48))))
(cert (issuer (ref SC1 xterm14.somecompany.com))
(subject fw1)
(auth (ip-gateway (host
(ref SC1 xterm14.somecompany.com)))))
We have to use a host name here because there is no IP address that can
be legitimately used.
ISSUE: I'm not sure how the (stop-at-key) etc. stuff of SPKI applies
here yet, but I KNOW that it does
ISSUE: a wildcard for the hostname might also be desirable, but perhaps
SDSI groups would also work here
3.4. Completing the certificate loop
Since all certificates chains must be rooted with a self-signed
certificate, the verifier of the ip-gateway chain (for instance, the ALT
node) must determine the origin of the ALO's authority to speak for that
address/hostname. The origin of its authority would come from either
DNSSEC or X.500 servers that it trusts.
This initial trust relationship would appear in this node via a
preconfigured root CA key, or cross certification of DNSSEC servers...
the technology for doing this is not described here.
4. Security Considerations:
This entire document discussed a security protocol.
5. References:
RFC-1825
Michael Richardson mcr@sandelman.ottawa.on.ca [page 8]
INTERNET-DRAFT v1.1, 11 June 1997
R. Atkinson, "Security Architecture for the Internet Protocol",
RFC-1825, August 1995.
RFC-1826
R. Atkinson, "IP Authentication Header", RFC-1826, August 1995.
RFC-1828
P. Metzger, W. A. Simpson, "IP Authentication using Keyed
MD5",RFC-1828, August 1995.
KSM-AH
New AH draft.
Maughan97
D. Maughan, M. Schertler, "Internet Security Association and Key
Management Protocol (ISAKMP)", version 7, draft-ietf-ipsec-
isakmp-07.txt, work in progress: February 21, 1997
Harkins97
D. Harkins, D. Carrel, "The resolution of ISAKMP with Oakley",
draft-ietf-ipsec-isakmp-oakley-03.txt, version 3, work in
progress: February 1997
Ylo97-1
T. Ylonen, "SSH Transport Layer Protocol", draft-ietf-secsh-
transport-00.txt, version 0, work in progress: March 22, 1997
Ellison97
C. Ellison, B. Frantz, B.M. Thomas, "Simple Public Key
Certificate", draft-ietf-spki-cert-structure-01.txt, version 1,
work in progress: March 25, 1997
SDSI
R. Rivest, B. Lampson, "SDSI - A Simple Distributed Security
Infrastructure SDSI",
%lt;URL:http://theory.lcs.mit.edu/ rivest/sdsi11.html>, October 2,
1996
Monte96
G. Montenegro, V. Gupta, "Firewall Support for Mobile IP", draft-
montenegro-firewall-mobileip-00.txt,
%lt;URL:http://skip.incog.com/drafts/draft-montenegro-firewall-
mobileip-00.txt%gt;, work in progress: Sept. 14, 1996
Gupta97-1
V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Goals and
Requirements", draft-ietf-mobileip-ft-req-00.txt, work in
progress: Jan. 20, 1997
Gupta97-2
V. Gupta, S. Glass, "Firewall Traversal for Mobile IP: Guidelines
for Firewalls and Mobile IP entities", draft-ietf-mobileip-
firewall-trav-00.txt, work in progress: March 17, 1997
Michael Richardson mcr@sandelman.ottawa.on.ca [page 9]
INTERNET-DRAFT v1.1, 11 June 1997
5.1. Author's Address
Michael C. Richardson
Sandelman Software Works Corp.
152 Rochester Street
Ottawa, ON K1R 7M4
Canada
Telephone: +1 613 233-6809
EMail: mcr@sandelman.ottawa.on.ca
5.2. Expiration and File Name
This draft expires December 15, 1997
Its file name is draft-richardson-ipsec-traversal-cert-01.txt
Michael Richardson mcr@sandelman.ottawa.on.ca [page 10]