| 1 | .\" -*-nroff-*- |
| 2 | .\". |
| 3 | .\" Overview of the whole system |
| 4 | .\" |
| 5 | .\" (c) 2008 Straylight/Edgeware |
| 6 | .\" |
| 7 | . |
| 8 | .\"----- Licensing notice --------------------------------------------------- |
| 9 | .\" |
| 10 | .\" This file is part of Trivial IP Encryption (TrIPE). |
| 11 | .\" |
| 12 | .\" TrIPE is free software; you can redistribute it and/or modify |
| 13 | .\" it under the terms of the GNU General Public License as published by |
| 14 | .\" the Free Software Foundation; either version 2 of the License, or |
| 15 | .\" (at your option) any later version. |
| 16 | .\" |
| 17 | .\" TrIPE is distributed in the hope that it will be useful, |
| 18 | .\" but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 19 | .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 20 | .\" GNU General Public License for more details. |
| 21 | .\" |
| 22 | .\" You should have received a copy of the GNU General Public License |
| 23 | .\" along with TrIPE; if not, write to the Free Software Foundation, |
| 24 | .\" Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
| 25 | . |
| 26 | .so common/defs.man \" @@@PRE@@@ |
| 27 | . |
| 28 | .\"-------------------------------------------------------------------------- |
| 29 | .TH tripe 7 "28 March 2008" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption" |
| 30 | . |
| 31 | .\"-------------------------------------------------------------------------- |
| 32 | .SH "NAME" |
| 33 | tripe \- overview of the TrIPE suite |
| 34 | . |
| 35 | .\"-------------------------------------------------------------------------- |
| 36 | .SH "NOTES TO THE AUTHOR" |
| 37 | . |
| 38 | .SS "What do we actually need to cover?" |
| 39 | .hP \*o |
| 40 | Key management. |
| 41 | .hP \*o |
| 42 | Setting up peer connections. |
| 43 | .hP \*o |
| 44 | Choosing algorithm suites? |
| 45 | . |
| 46 | .\"-------------------------------------------------------------------------- |
| 47 | .SH "DESCRIPTION" |
| 48 | . |
| 49 | TrIPE is a Virtual Private Network (VPN) implementation. It uses |
| 50 | cryptography to protect network packets from being read or tampered with |
| 51 | as they travel over hostile networks (e.g., the Internet). The effect |
| 52 | of this is that you can connect together geographically-separated |
| 53 | networks of machines and use network protocols which would be unsafe to |
| 54 | use over public networks. |
| 55 | .PP |
| 56 | The name `TrIPE' stands for `Trivial IP Encryption'. Unfortunately, |
| 57 | while the TrIPE network protocol is still fairly simple (and this is one |
| 58 | of TrIPE's conspicuous advantages over other VPN systems), the software |
| 59 | suite which implements it is not. Over time, the original single server |
| 60 | has acquired various strangely-shaped extensions and add-on-services in |
| 61 | order to solve various problems, and even given fairly detailed |
| 62 | descriptions of all of the individual pieces it can be difficult to see |
| 63 | how to fit them together in order to actually do anything useful. |
| 64 | .PP |
| 65 | This manual page provides an overview of the TrIPE software suite. The |
| 66 | individual components are described in their respective reference manual |
| 67 | pages. This page exists to provide a picture for how the various pieces |
| 68 | fit together and how to use them effectively. It presents a number of |
| 69 | worked examples, but it's not intended to be used as a `cookbook'; TrIPE |
| 70 | is a complicated system, and the author believes that you're less likely |
| 71 | to become confused by it if you understand how its various bits fit |
| 72 | together rather than following canned recipes which don't quite match |
| 73 | your particular circumstances. |
| 74 | .PP |
| 75 | The TrIPE software runs entirely in user mode. It does not require any |
| 76 | kernel modifications. |
| 77 | . |
| 78 | .SS "Who this documentation is for" |
| 79 | This document is intended for network administrators who are comfortable |
| 80 | with the fundamentals of IP networking and routing. It assumes |
| 81 | knowledge of how to configure network interfaces and routing. It |
| 82 | doesn't assume a strong background in cryptography, though a good |
| 83 | grounding won't hurt; the author recommends the |
| 84 | .I "Handbook of Applied Cryptography" |
| 85 | by Alfred Menezes, Paul van Oorschott and Scott Vanstone, which is |
| 86 | published by CRC Press, or available online. |
| 87 | . |
| 88 | .\"-------------------------------------------------------------------------- |
| 89 | .SH "HOW TrIPE WORKS" |
| 90 | . |
| 91 | The TrIPE protocol is a simple packet-based protocol transmitted over |
| 92 | UDP (RFC768). TrIPE has been allocated port 4070 by the IANA, but you |
| 93 | can use other ports if you like. |
| 94 | . |
| 95 | .SS "Network structure and addressing" |
| 96 | In TrIPE's model, a virtual network consists of a number of physical |
| 97 | networks joined together. Each physical network needs a |
| 98 | .I representative |
| 99 | (at least one, though more may be useful) which actually speaks the |
| 100 | TrIPE protocol. The representative establishes secure point-to-point |
| 101 | links with representatives of other physical networks over the Internet |
| 102 | (or at least over some larger physical network). These links are |
| 103 | strictly pairwise: they carry packets back and forth between precisely |
| 104 | two endpoints. The two endpoints of such a link are |
| 105 | .IR peers : |
| 106 | the link is, as far as TrIPE is concerned, utterly symmetrical. |
| 107 | .PP |
| 108 | Most of the hosts in the physical networks only need `internal' |
| 109 | addresses, i.e., their addresses need only be unique |
| 110 | .I within |
| 111 | the virtual network \(en and, if NAT is in use, even that needn't hold, |
| 112 | though NAT is at best a necessary evil and not to be used lightly. |
| 113 | Obviously, in order to be useful, the representatives need |
| 114 | .I external |
| 115 | addresses, so that they can send each other IP packets over the wider |
| 116 | Internet. |
| 117 | .TP |
| 118 | .B Example |
| 119 | .RS |
| 120 | Alice is the administrator of |
| 121 | .BR alice.net . |
| 122 | Internally, she has allocated IP addresses from the private address |
| 123 | range 10.0.1.0/24. She has an externally facing server |
| 124 | .BR anubis.alice.net , |
| 125 | which has an internal address of 10.0.1.1 and an external address of |
| 126 | 192.0.2.1. |
| 127 | .PP |
| 128 | Bob is an administrator at |
| 129 | .BR bob.com . |
| 130 | Internally, he's allocated IP addresses from the private address range |
| 131 | 10.0.2.0/24. He has an externally facing server |
| 132 | .BR bast.bob.com , |
| 133 | which has an internal address of 10.0.2.1 and an external address of |
| 134 | 192.0.2.129. |
| 135 | .PP |
| 136 | (At this point, the author would like to apologize for the unrealistic |
| 137 | nature of the external IP addresses in this example. Unfortunately, |
| 138 | allocating the addresses from the private-use space, e.g., 10.0.0.0/8, |
| 139 | would be confusing, since these are normally |
| 140 | .I internal |
| 141 | addresses only; the network 192.0.2.0/24 is allocated by IANA for use in |
| 142 | examples such as this, but is rather too small to divide into realistic |
| 143 | subnets, as I've tried to do here.) |
| 144 | .PP |
| 145 | It would be reasonable for Alice and Bob to choose |
| 146 | .B anubis |
| 147 | and |
| 148 | .B bast |
| 149 | as their respective TrIPE representatives. If, say, |
| 150 | .B amaterasu.alice.net |
| 151 | was an internal host with address 10.0.1.42, it would not be a suitable |
| 152 | representative, since this is an internal address and (presumably) the |
| 153 | routers between |
| 154 | .B alice.net |
| 155 | and |
| 156 | .B bob.com |
| 157 | don't know how to send packets there. |
| 158 | .PP |
| 159 | We'll return to Alice and Bob in other examples later. |
| 160 | .RE |
| 161 | . |
| 162 | .SS "Tunnels and routing" |
| 163 | A |
| 164 | .I tunnel |
| 165 | is a network interface, usually configured as a point-to-point link, |
| 166 | except that rather than sending network packets through some physical |
| 167 | interface, it makes them available to a user-mode process through a |
| 168 | character device; similarly, packets written to the character device |
| 169 | appear to the kernel to have originated in the tunnel interface. |
| 170 | .PP |
| 171 | A cheesy hack for implementing a `tunnel' interface like this is to |
| 172 | open a |
| 173 | .BR pty (7) |
| 174 | and configure the slave side of the pty to use the SLIP line discipline. |
| 175 | A user-mode process can now use the master side of the pty to read and |
| 176 | write SLIP-encoded network packets. Linux's TUN/TAP and BSD's |
| 177 | .BR tun (4) |
| 178 | interfaces provide a more convenient and efficient means of achieving |
| 179 | the same goal. TrIPE prefers to use these more refined tunnel |
| 180 | interfaces, but is willing to use the cheesy SLIP hack if necessary. |
| 181 | .PP |
| 182 | For each peer with which it is exchanging secured packets, a TrIPE |
| 183 | representative creates a tunnel interface. Packets being sent through |
| 184 | the interface are encrypted, authenticated, and retransmitted to the |
| 185 | peer's UDP port; packets arriving from a peer are verified, decrypted, |
| 186 | and inserted into the tunnel. |
| 187 | .PP |
| 188 | For this to work, the representative needs to have at least two routes |
| 189 | established: |
| 190 | .hP \*o |
| 191 | a route to its peer's external address, so that it can send it encrypted |
| 192 | packets encapsulated in UDP; |
| 193 | .hP \*o |
| 194 | a route to the peer's |
| 195 | .I internal |
| 196 | address, directed over the tunnel interface; and possibly |
| 197 | .hP \*o |
| 198 | if the peer is acting as a representative for a network of other hosts, |
| 199 | a route to that network also over the tunnel. |
| 200 | .PP |
| 201 | .TP |
| 202 | .B Example |
| 203 | .RS |
| 204 | Continuing the earlier example, |
| 205 | .B anubis.alice.net |
| 206 | needs to have one route to |
| 207 | .BR bast.bob.com 's |
| 208 | external address 192.0.2.129. We'll assume that |
| 209 | .B anubis |
| 210 | has a direct connection to the Internet, and that therefore no special |
| 211 | action needs to be taken here. In order to tunnel traffic to |
| 212 | .BR bast.bob.com , |
| 213 | .B anubis |
| 214 | has its |
| 215 | .B tripe-bob |
| 216 | interface configured as follows. |
| 217 | .IP |
| 218 | .B "ifconfig tripe-bob 10.0.1.1 pointopoint 10.0.2.1 mtu 1435" |
| 219 | .PP |
| 220 | (Network configuration commands are system-specific. This manual page |
| 221 | assumes a Linux system because that's the author's primary operating |
| 222 | system; consult your system's manual to find out what the equivalent |
| 223 | commands are. Network interface names are also system-specific; Linux |
| 224 | lets us rename network interfaces to make their names meaningful, and |
| 225 | these examples reflect this. Finally, don't worry about the MTU |
| 226 | setting. Usually, TrIPE's ancillary services will work out the correct |
| 227 | MTU automatically.) |
| 228 | .PP |
| 229 | Further, in order to communicate with the larger |
| 230 | .B bob.com |
| 231 | internal network, |
| 232 | .B anubis |
| 233 | has set up an additional route |
| 234 | .IP |
| 235 | .B "route add -net 10.0.2.0/24 gw 10.0.2.1 dev tripe-bob metric 2" |
| 236 | .PP |
| 237 | Other hosts in Alice's network might need to be told |
| 238 | .IP |
| 239 | .B "route add -net 10.0.2.0/24 gw 10.0.1.1 metric 3" |
| 240 | .PP |
| 241 | (spot the difference between this and |
| 242 | .BR anubis 's |
| 243 | route), though in many cases it's useful to choose the TrIPE |
| 244 | representative as a router anyway. |
| 245 | .RE |
| 246 | . |
| 247 | .SS "Connection styles" |
| 248 | There are essentially two kinds of connections possible between TrIPE |
| 249 | peers.b |
| 250 | .hP 1. |
| 251 | .B "Always up." |
| 252 | Each of the two peers expects to find the other up and running all of |
| 253 | the time. This works well, and is easy to set up and maintain, if the |
| 254 | two peers have stable external IP addresses, have network connectivity, |
| 255 | and are almost always turned on. If one is frequently down, or the |
| 256 | network between them is not always available (e.g., it's a dial-up link) |
| 257 | then the servers will be wasting their time trying to contact each |
| 258 | other: maybe one of the other options will be better. Either or both of |
| 259 | the peers may be providing VPN services for a network of other machines. |
| 260 | .hP 2. |
| 261 | .B "Dynamically established." |
| 262 | One of the peers explicitly establishes a connection with the other when |
| 263 | it wants to communicate. The |
| 264 | .I active |
| 265 | peer \(en the one making the connection \(en doesn't need a stable |
| 266 | static IP address. The |
| 267 | .I passive |
| 268 | peer \(en the one connected to \(en does need a stable external IP |
| 269 | address, to have reasonable network connectivity, and to be up most of |
| 270 | the time. Dynamic connections are more complicated to configure and |
| 271 | support, but much more flexible. |
| 272 | .PP |
| 273 | (In principle, it might be possible for two hosts, both behind NAT |
| 274 | routers, to make use of, say, STUN to establish a connection; but this |
| 275 | doesn't seem sufficiently useful.) |
| 276 | . |
| 277 | |
| 278 | |
| 279 | |
| 280 | |
| 281 | |
| 282 | |
| 283 | |
| 284 | |
| 285 | |
| 286 | |
| 287 | |
| 288 | |
| 289 | |
| 290 | |
| 291 | |
| 292 | |
| 293 | |
| 294 | .\"-------------------------------------------------------------------------- |
| 295 | .SH "CRYPTOGRAPHY AND KEY MANAGEMENT" |
| 296 | . |
| 297 | .SS "A very quick introduction to modern cryptography" |
| 298 | This isn't really the place for a full survey of modern cryptography, |
| 299 | but I'll try to provide a little background. |
| 300 | .PP |
| 301 | Cryptography is the use of mathematics in order to achieve security |
| 302 | objectives. There are two main objectives of modern cryptography. |
| 303 | .TP |
| 304 | .I Secrecy |
| 305 | Preventing an adversary from learning anything about a message (except |
| 306 | its length), even though the adversary is responsible for delivering |
| 307 | it. The original message is called the |
| 308 | .IR plaintext ; |
| 309 | an |
| 310 | .I encryption |
| 311 | process converts the plaintext into a |
| 312 | .IR ciphertext ; |
| 313 | a recipient |
| 314 | .I decrypts |
| 315 | the ciphertext in order to recover the original plaintext. |
| 316 | .TP |
| 317 | .IR Integrity " or " authenticity |
| 318 | Preventing an adversary from creating |
| 319 | .IR forgeries : |
| 320 | i.e., messages which appear to have been sent by a particular person or |
| 321 | group of people. The sender |
| 322 | .I tags |
| 323 | or |
| 324 | .I signs |
| 325 | a message (tags are symmetric, signatures asymmetric, as explained |
| 326 | below); the recipient |
| 327 | .I verifies |
| 328 | the tag or signature. |
| 329 | .PP |
| 330 | In order to be able to do this, the recipient (in the case of secrecy) |
| 331 | or the sender (for integrity) need to know a |
| 332 | .I key |
| 333 | unknown to the adversary. We can now distinguish two important cases. |
| 334 | .TP |
| 335 | .IR "Symmetric" " or " "secret-key cryptography" |
| 336 | Both participants know the same key (or at least they can easily compute |
| 337 | each others' keys). Somehow, the two participants must agree on the |
| 338 | same key without letting it fall into the hands of the adversary. |
| 339 | Before 1976, all publicly-known cryptographic schemes were symmetric. |
| 340 | .TP |
| 341 | .IR "Asymmetric" " or " "public-key cryptography" |
| 342 | In the case of secrecy, the sender knows only a |
| 343 | .I public key |
| 344 | which is sufficient to encrypt a message so that it can only be |
| 345 | decrypted by the holder of the corresponding |
| 346 | .IR private key , |
| 347 | but insufficient to decrypt messages sent by others using the same |
| 348 | public key. In the case of integrity, the sender holds a secret key |
| 349 | with which he can make signatures; the public key allows others to |
| 350 | verify existing signatures but not to make new signatures. The holder |
| 351 | of the private key needs to convey an |
| 352 | .I authentic |
| 353 | copy of the corresponding public key to other participants, but the |
| 354 | public key doesn't need to be kept secret. Asymmetric cryptography was |
| 355 | first described to the public in 1976 by Whitfield Diffie and Martin |
| 356 | Hellman, though it had been known to governments (e.g., the British |
| 357 | CESG) for a number of years. |
| 358 | .PP |
| 359 | The advantage of symmetric cryptography is efficiency: symmetric |
| 360 | techniques for secrecy and integrity require smaller keys, less memory, |
| 361 | and much less time, than asymmetric techniques. The disadvantage is |
| 362 | that key distribution is much harder: symmetric keys must be known to |
| 363 | all participants, but kept secret from adversaries; public keys need not |
| 364 | be kept secret. It's therefore common to use asymmetric methods to |
| 365 | distribute short symmetric keys, and use the latter for ensuring the |
| 366 | secrecy and integrity of longer messages. |
| 367 | .PP |
| 368 | Asymmetric cryptography makes key distribution easier, but doesn't |
| 369 | eliminate the problem entirely. In particular, the problem of ensuring |
| 370 | that the participants have a correct copy of each others' keys remains. |
| 371 | There are a number of (partial) solutions to this problem, but they all |
| 372 | use the same basic idea: if (say) Alice knows Bob's public key, and Bob |
| 373 | knows Carol's public key, then Bob can send Alice a message saying |
| 374 | `Carol's public key is |
| 375 | .IR mumble ': |
| 376 | now, if Alice is willing to take Bob's word for this, then she now knows |
| 377 | Carol's key. |
| 378 | .PP |
| 379 | A signed message binding together a public key and some facts about the |
| 380 | corresponding private key is often called a |
| 381 | .IR certificate , |
| 382 | and a |
| 383 | .I certificate authority |
| 384 | (or CA) is an organization which issues certificates. Internet |
| 385 | certificate authorities are organizations whose public keys are well |
| 386 | known (e.g., included with web browsers) and which are generally |
| 387 | believed to be careful to issue only correct certificates. However, the |
| 388 | economics of this arrangement are strange: CAs are usually paid by the |
| 389 | holders of private keys, so they get their money whether or not the |
| 390 | certificates are actually true. |
| 391 | .PP |
| 392 | The famous |
| 393 | .BR pgp (1) |
| 394 | program and its successors (e.g., |
| 395 | .BR gpg (1)) |
| 396 | use a more sophisticated approach called the |
| 397 | .IR "web of trust" , |
| 398 | which allows Alice to collect certificates from a number of different |
| 399 | signers, compare them, and decide based on how much she trusts each of |
| 400 | them how likely their claims are. This can be complicated to manage. |
| 401 | . |
| 402 | .SS "Cryptography in TrIPE" |
| 403 | The long-term keys in TrIPE are all asymmetric. There are no |
| 404 | `pre-shared keys'. If two peers are to establish a link between them, |
| 405 | it is essential that each has a correct copy of the other's public key. |
| 406 | In principle, this ought to be easier than arranging for each to know a |
| 407 | common secret; pre-shared keys are easier to deal with only if they're |
| 408 | memorable, and memorable keys are not likely to be difficult to guess. |
| 409 | .PP |
| 410 | The TrIPE server, and its ancillary services, simply assume that you've |
| 411 | already acquired genuine copies of other peers' public keys and put them |
| 412 | in the right place; exactly how you go about this is up to you, and |
| 413 | tools such as CAs or PGP can help. However, the TrIPE distribution |
| 414 | contains a simple tool |
| 415 | .BR tripe-keys (8) |
| 416 | for dealing with public key distribution. This is described in more |
| 417 | detail below. |
| 418 | .PP |
| 419 | The TrIPE suite's primary author is a cryptographer, and he enjoys |
| 420 | having fine control over the cryptographic primitives involved. |
| 421 | Fortunately it's not that difficult to |
| 422 | |
| 423 | |
| 424 | |
| 425 | |
| 426 | |
| 427 | |
| 428 | |
| 429 | |
| 430 | .\"-------------------------------------------------------------------------- |
| 431 | .SH "SECURITY" |
| 432 | . |
| 433 | .SS "Host security" |
| 434 | TrIPE runs entirely in user mode, unlike many IPsec implementations. |
| 435 | The main server, which is written in C, mostly runs as an unprivileged |
| 436 | user. However, a small part of the server runs with |
| 437 | .B root |
| 438 | privileges because it needs to be able to open new tunnel devices |
| 439 | dynamically. Even this can be avoided, for example by using SLIP |
| 440 | tunnels, allocated by a GNU |
| 441 | .BR userv (1) |
| 442 | service. If the server is compromised, an attacker can use it to inject |
| 443 | arbitrary network packets, but little else. |
| 444 | .PP |
| 445 | The ancillary service |
| 446 | .BR watch (8) |
| 447 | needs root privileges in order to configure new network interfaces. It |
| 448 | is written in Python, a safe interpreted language. In turn, this |
| 449 | invokes an external program, again as |
| 450 | .BR root , |
| 451 | to do the actual network interface configuration. This program is |
| 452 | user-selectable, but the default program is a simple shell script; it |
| 453 | does not process untrusted input. |
| 454 | . |
| 455 | .SS "Cryptographic security" |
| 456 | The TrIPE protocol is not standards-based. However, it has been |
| 457 | designed by an experienced cryptographer, and has a formal `security |
| 458 | proof' showing that an attack against the protocol can be transformed |
| 459 | into an attack against one of its primitive components. Other VPN |
| 460 | protocols are too complicated to admit such proofs. The guarantees |
| 461 | afforded by security proofs of this kind are |
| 462 | .I contingent |
| 463 | on the security of the primitive components rather than absolute, but |
| 464 | even such a contingent proof is much better than no proof at all. |
| 465 | .PP |
| 466 | The software allows users a wide selection of primitive components, some |
| 467 | standardized and some not; the author recommends the widely standardized |
| 468 | and well-respected Rijndael (AES) for encryption and SHA256 for hashing |
| 469 | and authentication. |
| 470 | . |
| 471 | .SS "Why TrIPE doesn't use X.509" |
| 472 | The TrIPE protocol does not use X.509 certificates, as deployed in TLS and |
| 473 | IPsec. X.509 certificates are hard to parse: software which processes |
| 474 | them has a history of vulnerabilities. The certification model used by |
| 475 | TLS, where the holder of a key pays a certification authority for his or |
| 476 | her certificate, is economically backwards: the direct beneficiaries of |
| 477 | the certificate are those who rely on it to establish the validity of |
| 478 | the public key. The author does not understand why an external |
| 479 | certificate authority is needed in order to construct a VPN anyway: if |
| 480 | Alice has no idea who Bob is, she's unlikely to want to allow him access |
| 481 | to her private network! |
| 482 | .PP |
| 483 | The main TrIPE software does not assume any particular certification |
| 484 | model: rather, it considers the issue of establish authenticity of |
| 485 | public keys to be out-of-scope. The supplied |
| 486 | .BR tripe-keys (8) |
| 487 | program implements a very simple key-distribution system which avoids |
| 488 | the complexity inherent in X.509. Of course, because public key |
| 489 | distribution is separated from the main system, nothing prevents |
| 490 | swapping in a more sophisticated system where necessary. |
| 491 | . |
| 492 | .SS "Comparison with other systems" |
| 493 | This section compares TrIPE with other VPN protocols. |
| 494 | .TP |
| 495 | .B IPsec |
| 496 | .RS |
| 497 | IPsec is an IETF standard. It defines two protocols for handling bulk |
| 498 | data. The Authentication Header (AH) simply adds cryptographic |
| 499 | authentication to an IP packet, including the header; this causes |
| 500 | trouble with NAT firewalls. The Encapsulating Security Payload (ESP) |
| 501 | provides both encryption and authenticity, and operates in one of two |
| 502 | modes: |
| 503 | .I transport |
| 504 | mode simply processes the payload data, but not the header; the |
| 505 | .I tunnel |
| 506 | mode encapsulates an entire IP packet. Of these, AH and ESP transport |
| 507 | mode need to be supported by all participating hosts. ESP tunnel mode |
| 508 | only needs to be supported by a single representative (`security |
| 509 | gateway') of each network, and provides header security which works |
| 510 | properly with NAT. TrIPE works very similarly to ESP tunnel mode. |
| 511 | The IPsec AH and ESP protocols work directly over IP, rather than using |
| 512 | UDP as TrIPE does. This reduces the per-packet overhead, but means that |
| 513 | implementations need to be highly privileged, either running as part of |
| 514 | the kernel or at least with |
| 515 | .B root |
| 516 | privileges. |
| 517 | .PP |
| 518 | Key exchange in IPsec (IKE) is very complicated, with many options. The |
| 519 | protocol can use a number of different certificate formats, or none at |
| 520 | all. Partly this is due to the fact that IPsec has more ambitious goals |
| 521 | than TrIPE: IPsec aims to allow `opportunistic' security between |
| 522 | previously unrelated entities, whereas TrIPE assumes that all the |
| 523 | participants in its virtual network are administrated in a coordinated |
| 524 | fashion. This means that TrIPE's usefulness is comparatively limited; |
| 525 | of course, it also means that TrIPE is much simpler. |
| 526 | .RE |
| 527 | .TP |
| 528 | .B OpenVPN |
| 529 | .RS |
| 530 | In many respects, OpenVPN is very similar to TrIPE: it runs in userland, |
| 531 | and operates over UDP. OpenVPN uses a variant of the TLS protocol for |
| 532 | its key-exchange. TLS is very complex, and uses X.509 certificates |
| 533 | which bring their own problems. (OpenVPN provides a |
| 534 | .B tls-auth |
| 535 | option to mitigate this, though it partially defeats the point of |
| 536 | public key cryptography.) |
| 537 | .PP |
| 538 | OpenVPN can use TAP interfaces in order to simulate an Ethernet rather |
| 539 | than a point-to-point link, which allows Ethernet bridging across the |
| 540 | VPN. TrIPE could do this relatively easily (it's just a matter of |
| 541 | configuring the tunnel interface differently) but it hasn't seemed |
| 542 | useful yet. |
| 543 | .RE |
| 544 | .TP |
| 545 | .B "SSH- and SSL-based VPNs" |
| 546 | .RS |
| 547 | OpenSSH can implement a simple VPN, by opening tunnel devices at each |
| 548 | end and forwarding packets over the SSH connection. This causes |
| 549 | problems: SSH is already running over TCP, and TCP provides congestion |
| 550 | control and reliability. TCP over this tunnel will therefore have two |
| 551 | layers of congestion control and reliability, and the two have a |
| 552 | tendency to interfere. When there is little or no packet loss, |
| 553 | everything will be fine; if the underlying connection becomes flaky, the |
| 554 | VPN will suffer greatly. |
| 555 | .PP |
| 556 | SSL-based VPNs (simply forwarding packets over an SSL or TLS connection) |
| 557 | have the same problem, and all of the problems associated with SSL's use |
| 558 | of X.509 certificates. |
| 559 | .RE |
| 560 | . |
| 561 | .SS "Firewall considerations" |
| 562 | You should be able to write firewall rules for packets travelling over |
| 563 | TrIPE's tunnel interfaces just as for any other interfaces. |
| 564 | Unfortunately, it is hard to predict the name of the tunnel interface |
| 565 | that TrIPE will allocate for any particular peer. There are two basic |
| 566 | solutions to this problem. |
| 567 | .hP \*o |
| 568 | Some operating systems allow you to rename network interfaces. You can |
| 569 | use this feature to assign the interface a more useful name, which may |
| 570 | already be known to your firewall. |
| 571 | .hP \*o |
| 572 | You can dynamically modify the firewall rules once you know which |
| 573 | interface has been assigned to the peer. This is probably more |
| 574 | complicated. |
| 575 | |
| 576 | |
| 577 | |
| 578 | |
| 579 | |
| 580 | |
| 581 | |
| 582 | |
| 583 | |
| 584 | |
| 585 | |
| 586 | |
| 587 | |
| 588 | |
| 589 | |
| 590 | |
| 591 | . |
| 592 | .SS "Structure of the system" |
| 593 | The TrIPE system consists of a number of components. |
| 594 | .hP \*o |
| 595 | The |
| 596 | .BR tripe (8) |
| 597 | daemon itself. The daemon runs continually in the background. At any |
| 598 | given moment, the daemon knows of a number of |
| 599 | .IR peers : |
| 600 | other servers with which it is meant to interact. It accepts network |
| 601 | packets from the kernel, encrypts them, and sends them to appropriate |
| 602 | peers; it also receives encrypted packets from peers, decrypts them, and |
| 603 | hands them to the kernel. It also provides an administration interface |
| 604 | through which the daemon can be told about new peers, and old ones |
| 605 | removed. |
| 606 | .hP \*o |
| 607 | A number of ancillary services which run alongside the daemon and |
| 608 | provide additional functionality. The |
| 609 | .BR connect (8) |
| 610 | service accepts requests to attach new peers and makes the necessary |
| 611 | arrangements. The |
| 612 | .BR watch (8) |
| 613 | service notices peers being added and removed; it configures network |
| 614 | interfaces; when necessary it attempts to `wake up' remote peers to |
| 615 | inform them of its presence; and it can time out old peers which aren't |
| 616 | responding. This is useful in environments where peers appear and |
| 617 | disappear dynamically. |
| 618 | .hP \*o |
| 619 | The |
| 620 | .BR tripe-keys (8) |
| 621 | utility. The TrIPE system uses asymmetric (`public-key') cryptography. |
| 622 | Therefore it's necessary to ensure that the participants in the VPN have |
| 623 | authentic copies of each others' public keys. This is nontrivial, but |
| 624 | easier than the traditional key-distribution problem, which additionally |
| 625 | involves keeping all of the keys secret. The |
| 626 | .BR tripe-keys (8) |
| 627 | program helps maintain a |
| 628 | .I "certificate authority" |
| 629 | (CA) which can distribute public keys in a secure way. |
| 630 | . |
| 631 | .SS "The basic model" |
| 632 | As far as the TrIPE protocol goes, there is no distinction between |
| 633 | clients and servers, or between initiators and responders. The protocol |
| 634 | treats all participants equally; we call them peers. Each peer knows |
| 635 | about a number of other peers. It establishes point-to-point |
| 636 | communications separately with each peer it knows about. |
| 637 | .PP |
| 638 | Each peer refers to the other peers with whom it communicates by name. |
| 639 | Theoretically, these names are only for the individual peer's (and its |
| 640 | administrator's) convenience, and a single peer may be assigned |
| 641 | completely different names by all of the other peers with which it |
| 642 | communicates. In practise, this would be very confusing, and all peers |
| 643 | use the same, or very similar, names for each other. |
| 644 | .PP |
| 645 | When a daemon is informed about a new peer \(en its name, and an IP |
| 646 | address and port number \(en it creates a new network interface for the |
| 647 | peer and attempts to initiate a key-exchange. If both ends have been |
| 648 | informed of each other's presence, and they have each other's correct |
| 649 | public keys, they will successfully negotiate symmetric keys and be able |
| 650 | to transmit and receive network packets. |
| 651 | .PP |
| 652 | By this point, the daemon has indeed created a network interface, but no |
| 653 | network traffic will actually be carried because the interface is not |
| 654 | configured. The |
| 655 | .BR tripe (8) |
| 656 | daemon leaves the messy details of configuring interfaces to other |
| 657 | programs. If the |
| 658 | .BR watch (8) |
| 659 | service is running, it will notice the new peer, look up its details in |
| 660 | a database, and invoke a script, usually |
| 661 | .BR tripe-ifup (8), |
| 662 | to configure the interface correctly. |
| 663 | . |
| 664 | .SS "Addressing concepts" |
| 665 | Virtual private networks make addressing complicated. This |
| 666 | documentation isn't going to make that complexity go away, but it might |
| 667 | shed some light on it. In particular, each peer involved needs at least |
| 668 | two distinct addresses. |
| 669 | .PP |
| 670 | |
| 671 | |
| 672 | |
| 673 | |
| 674 | |
| 675 | |
| 676 | |
| 677 | .PP |
| 678 | The TrIPE VPN isn't magic. It runs over standard IP, so the machines |
| 679 | you want to participate in the VPN need to be able to send each other IP |
| 680 | packets. |
| 681 | |
| 682 | |
| 683 | |
| 684 | |
| 685 | |
| 686 | In particular, each needs to have an address and port number |
| 687 | \(en its |
| 688 | .I "external address" |
| 689 | (and port) \(en on which it can send and receive packets to/from the |
| 690 | others. |
| 691 | .PP |
| 692 | Additionally, each needs to be able to send packets to the others |
| 693 | .I through |
| 694 | the VPN. The addresses which are routed over the VPN are |
| 695 | .IR "internal addresses" . |
| 696 | Clearly, the internal addresses need to be distinct from the external |
| 697 | addresses if the machines involved are to be able |
| 698 | |
| 699 | |
| 700 | .I "external addresses" |
| 701 | .P |
| 702 | TrIPE has the port number 4070 allocated to it by IANA, so it shouldn't |
| 703 | interfere with anything else. But some firewalls may block TrIPE |
| 704 | traffic, or you may just not want to advertise your use of TrIPE, so you |
| 705 | can use any port you like. |
| 706 | |
| 707 | |
| 708 | |
| 709 | . |
| 710 | .SS "Establishing connections" |
| 711 | |
| 712 | |
| 713 | |
| 714 | |
| 715 | .PP |
| 716 | .PP |
| 717 | The server itself maintains no persistent configuration other than a |
| 718 | simple database of public keys for its various peers. |
| 719 | |
| 720 | .\"-------------------------------------------------------------------------- |
| 721 | .SH "EXAMPLES" |
| 722 | . |
| 723 | This section contains a number of worked examples for configuring and |
| 724 | running TrIPE. |
| 725 | .PP |
| 726 | We'll start with the case of Alice and Bob, who both administer |
| 727 | networks |
| 728 | .B alice.net |
| 729 | and |
| 730 | .B bob.com |
| 731 | respectively, and want them to be able to communicate with each other |
| 732 | securely over the wild Internet. Later we'll deal with Carol, who has a |
| 733 | laptop and wants to be able to connect to the VPN from fleapit hotels |
| 734 | all around the world. |
| 735 | . |
| 736 | .SS "Alice sets herself up as a certificate authority" |
| 737 | Everyone participating in a TrIPE network needs to have a private key |
| 738 | and an |
| 739 | .I authentic |
| 740 | copy of everyone else's public keys. If Bob's copy of Alice's public |
| 741 | key is wrong, then someone else, say Dave, might be able to pretend to |
| 742 | Bob that he's really Alice. |
| 743 | .PP |
| 744 | The easiest way to cope, at least in small networks, is for one person |
| 745 | to be designated as a |
| 746 | .IR "certificate authority" . |
| 747 | The certificate authority's job is to collect authentic copies of |
| 748 | everyone's public keys and make them available to the participants, |
| 749 | signed by the CA's master key. Now all people need to get them started |
| 750 | is a copy of the CA's public key. |
| 751 | .PP |
| 752 | A simple version of this model is supported by the |
| 753 | .BR tripe-keys (8) |
| 754 | program. If you have a large network then the simple single-CA model |
| 755 | won't work for you: see the manual pages for |
| 756 | .BR tripe (8) |
| 757 | and |
| 758 | .BR key (1) |
| 759 | for the details on what you need to do. |
| 760 | .PP |
| 761 | Alice will be the certificate authority in our example. The CA's files |
| 762 | will be stored on |
| 763 | .BR thoth.alice.net , |
| 764 | owned by a dedicated user |
| 765 | .BR tripe-ca , |
| 766 | and stored in |
| 767 | .BR /home/tripe-ca . |
| 768 | To set up the CA, she first creates a configuration file |
| 769 | .B tripe-keys.master |
| 770 | with the contents |
| 771 | .VS |
| 772 | ## File locations. |
| 773 | base-url = http://www.alice.net/tripe-keys/ |
| 774 | base-dir = /home/tripe-ca/dist/ |
| 775 | upload-hook = rsync \-az ${base-dir} www.alice.com:/var/www/tripe-keys/ |
| 776 | |
| 777 | ## Cryptographic parameters. |
| 778 | kx-expire = now + 1 year |
| 779 | sig-fresh = 1 month ago |
| 780 | sig-expire now + 1 year |
| 781 | |
| 782 | ## Master key integrity. |
| 783 | master-sequence = @MASTER-SEQUENCE@ |
| 784 | hk-master = @HK-MASTER@ |
| 785 | .VE |
| 786 | She then runs |
| 787 | .B tripe-keys setup |
| 788 | which runs for a fair while, printing lots of dots to keep her amused. |
| 789 | Eventually it asks her for a passphrase, so she types in a good, strong |
| 790 | passphrase that'll be hard for anyone to guess. It'll ask her to verify |
| 791 | the passphrase, so she types it in again: |
| 792 | .IS |
| 793 | .IC $ "tripe-keys setup" |
| 794 | + key \-krepos/param add \-adh-param \-LS \-b2048 \-B256 \-eforever |
| 795 | \h'8n'\-tparam tripe-dh-param cipher=blowfish-cbc hash=sha256 |
| 796 | \h'8n'mac=sha256-hmac/128 mgf=sha256-mgf |
| 797 | Searching for p: ...........++ ok |
| 798 | Searching for g: + ok |
| 799 | + key -kmaster add \-adsa \-b2048 \-B256 \-enow + 1 year \-l |
| 800 | \h'8n'\-tmaster-0 tripe-keys-master sig=dsa hash=sha256 |
| 801 | Searching for q: ..++++++++++++ ok |
| 802 | Searching for p: .................................++ ok |
| 803 | Searching for g: + ok |
| 804 | .IC "New passphrase e3f32b86:tripe-keys-master:master-0.private:" good-passphrase |
| 805 | .IC "Verify passphrase e3f32b86:tripe-keys-master:master-0.private:" good-passphrase |
| 806 | + key \-kmaster extract \-f\-secret repos/master.pub |
| 807 | .IE |
| 808 | (The lines beginning with |
| 809 | .RB ` + ' |
| 810 | indicate commands that Alice could have run by hand. The |
| 811 | .B tripe-keys |
| 812 | program does a lot of work figuring out sensible defaults to apply.) |
| 813 | .PP |
| 814 | She now has an empty |
| 815 | .I key repository |
| 816 | in the directory |
| 817 | .BR repos , |
| 818 | and a master CA key in the file |
| 819 | .BR master . |
| 820 | (There are also a bunch of |
| 821 | .B .old |
| 822 | files lying around for the sake of paranoia. You can ignore these, or |
| 823 | even delete them if you like.) |
| 824 | .PP |
| 825 | She publishes the empty repository on her webserver by running |
| 826 | .BR "tripe-keys upload" . |
| 827 | This will create a signed copy of her repository and install it on her |
| 828 | webserver. It will need to ask her for her passphrase again. (If she's |
| 829 | running the passphrase pixie |
| 830 | .BR pixie (8) |
| 831 | and she's fairly quick about this, then the pixie will remember the |
| 832 | passphrase and she won't need to type it again.) |
| 833 | .IS |
| 834 | .IC $ "tripe-keys upload" |
| 835 | + tar chozf /tmp/mdw/tripe-ca/dist/tripe-keys.tar.gz.new . |
| 836 | + catsign \-kmaster sign \-abdC \-kmaster-0 |
| 837 | \h'8n'\-o/home/tripe-ca/dist/tripe-keys.sig-0.new |
| 838 | \h'8n'/home/tripe-ca/dist/tripe-keys.tar.gz.new |
| 839 | .IC "Passphrase e3f32b86:tripe-keys-master:master-0.private:" good-passphrase |
| 840 | + sh \-c rsync \-az /tmp/mdw/tripe-ca/dist/ www.alice.net:/var/www/tripe-keys/ |
| 841 | .IE |
| 842 | Alice's CA is now ready! |
| 843 | . |
| 844 | .SS "Alice generates a server key" |
| 845 | She'll need a key for herself, obviously, so she generates one. This |
| 846 | also serves as a sanity check that she's set up the CA properly. |
| 847 | .PP |
| 848 | She's going to run her |
| 849 | .BR tripe (8) |
| 850 | server on a machine called |
| 851 | .BR anubis.alice.net . |
| 852 | She creates |
| 853 | .BR tripe 's |
| 854 | configuration directory |
| 855 | .B \*(c/ |
| 856 | if it doesn't already exist, and makes it current. |
| 857 | .IS |
| 858 | .IC $ "mkdir -p \*(/c" |
| 859 | .IC $ "cd \*(/c" |
| 860 | .IE |
| 861 | The first thing she needs to do is to get a copy of |
| 862 | .B tripe-keys.conf |
| 863 | from her webserver: |
| 864 | .IS |
| 865 | .IC $ "curl \-sS \-O http://www.alice.net/tripe-keys/tripe-keys.conf" |
| 866 | .IE |
| 867 | She must ensure that the copy is authentic. Since she can log into |
| 868 | .B thoth |
| 869 | directly using |
| 870 | .BR ssh (1) |
| 871 | she can use that to check. (She could just have fetched the file from |
| 872 | .B thoth |
| 873 | directly, but that wouldn't test that the webserver was set up properly.) |
| 874 | .IS |
| 875 | .IC $ "hashsum \-armd160 tripe-keys.conf" |
| 876 | #hash rmd160 |
| 877 | 0033d67c45027643c43577ff6bd188deb15fa65a tripe-keys.conf |
| 878 | .IC $ "ssh thoth cat /home/tripe-ca/dist/tripe-keys.conf | hashsum \-armd160" |
| 879 | 0033d67c45027643c43577ff6bd188deb15fa65a |
| 880 | .IE |
| 881 | Good! Now she can fetch the copy of the empty repository. |
| 882 | .IS |
| 883 | .IC $ "tripe-keys update" |
| 884 | + curl \-s \-o tripe-keys.tar.gz http://www.alice.net/tripe-keys/tripe-keys.tar.gz |
| 885 | + curl \-s \-o tripe-keys.sig http://www.alice.net/tripe-keys/tripe-keys.sig-0 |
| 886 | + tar xfz tripe-keys.tar.gz |
| 887 | + catsign \-krepos/master.pub verify \-avC \-kmaster-0 \-t1 month ago |
| 888 | \h'8n'tripe-keys.sig tripe-keys.tar.gz |
| 889 | INFO good-signature e3f32b86:tripe-keys-master:master-0 |
| 890 | INFO date 2008-04-09 18:25:39 BST |
| 891 | OK verified successfully |
| 892 | .IE |
| 893 | Joy. Now Alice can actually generate her key. |
| 894 | .IS |
| 895 | .IC $ "tripe-keys generate alice" |
| 896 | + key \-kkeyring merge repos/param |
| 897 | + key \-kkeyring add \-adh \-pparam -enow + 1 year \-talice tripe-dh |
| 898 | + key \-kkeyring extract \-f\-secret peer-alice.pub alice |
| 899 | .IE |
| 900 | At this point, Alice must get her public key, conveniently placed in |
| 901 | .BR peer-alice.pub , |
| 902 | back to her master repository on |
| 903 | .BR thoth . |
| 904 | The easiest way is to log back into |
| 905 | .B thoth |
| 906 | and run |
| 907 | .IS |
| 908 | .IC $ "scp anubis:\*(/c/peer-alice.pub repos/" |
| 909 | .IE |
| 910 | Then all she needs to do is republish the change |
| 911 | .RB ( "tripe-keys upload" |
| 912 | on |
| 913 | .BR thoth ) |
| 914 | and fetch the new version |
| 915 | .RB ( "tripe-keys update" |
| 916 | on |
| 917 | .BR anubis ). |
| 918 | . |
| 919 | .SS "Bob generates his key" |
| 920 | If Alice's and Bob's networks are going to communicate then Bob needs to |
| 921 | generate a key too. The first thing he needs is an |
| 922 | .I authentic |
| 923 | copy of Alice's |
| 924 | .BR tripe-keys.conf . |
| 925 | Fetching it from |
| 926 | .B www.alice.net |
| 927 | using |
| 928 | .BR curl (1) |
| 929 | won't cut it. (Well, maybe if he uses HTTPS and already knows that he |
| 930 | has an authentic copy of the webserver's public key certificate he can |
| 931 | use that.) |
| 932 | .PP |
| 933 | Bob has several options. |
| 934 | .hP \*o |
| 935 | If he knows Alice's voice he can phone her up and get her to |
| 936 | read out the |
| 937 | .BR hashsum (1) |
| 938 | of the file to him. He can compare this to the hash he computed on the |
| 939 | file he got with |
| 940 | .BR curl (1). |
| 941 | .hP \*o |
| 942 | If Alice is geographically close, he can just meet her and she can hand |
| 943 | him either a copy of the hash or the file itself (on some suitable |
| 944 | read-only medium like a CD-R). |
| 945 | .hP \*o |
| 946 | Alternatively, they can use |
| 947 | .BR gnupg (1): |
| 948 | Alice signs her copy of the file and sends it to Bob who verifies it. |
| 949 | Of course, this assumes that he's somehow managed to get an authentic |
| 950 | copy of Alice's OpenPGP key. |
| 951 | .PP |
| 952 | Bob's going to run |
| 953 | .BR tripe (8) |
| 954 | on |
| 955 | .BR bast.bob.com . |
| 956 | He makes |
| 957 | .B \*(/c |
| 958 | be his current directory, and puts his copy of |
| 959 | .B tripe-keys.conf |
| 960 | there. Once he's done that, he runs |
| 961 | .B "tripe-keys update" |
| 962 | to fetch the repository (now with Alice's public key in it), and then |
| 963 | generates his key. |
| 964 | .IC $ "tripe-keys generate bob" |
| 965 | + key \-kkeyring merge repos/param |
| 966 | + key \-kkeyring add \-adh \-pparam -enow + 1 year \-tbob tripe-dh |
| 967 | + key \-kkeyring extract \-f\-secret peer-bob.pub bob |
| 968 | .IE |
| 969 | He now needs to send the file |
| 970 | .B peer-bob.pub |
| 971 | back to Alice, and again they need to ensure the authenticity of the |
| 972 | file that Alice receives. They can use the same methods as they did |
| 973 | before for the configuration file. |
| 974 | .PP |
| 975 | However they manage it, Alice puts her authentic copy of Bob's public |
| 976 | key in |
| 977 | .B /home/tripe-ca/repos/ |
| 978 | on |
| 979 | .B thoth |
| 980 | and runs |
| 981 | .B "tripe-keys upload" |
| 982 | again. |
| 983 | .PP |
| 984 | Finally, both she and Bob need to run |
| 985 | .B "tripe-keys update" |
| 986 | on |
| 987 | .B anubis |
| 988 | and |
| 989 | .B bast |
| 990 | respectively, to install the new collection of public keys. (Actually, |
| 991 | Bob probably needn't bother, but it means that he can check that his |
| 992 | public key is included.) |
| 993 | . |
| 994 | .SS "Alice and Bob set up their servers" |
| 995 | The crypto setup is now done: we move on to the network administration |
| 996 | part. The two networks in question are: |
| 997 | .TP |
| 998 | .B alice.net |
| 999 | uses IP addresses 10.1.0.0/16. The main gateway to the outside world is |
| 1000 | .B apophis.alice.net |
| 1001 | (10.1.0.1 and 192.0.2.1). |
| 1002 | .TP |
| 1003 | .B bob.com |
| 1004 | uses IP addresses 10.2.0.0/16. The main gateway to the outside world is |
| 1005 | .B bast.bob.com |
| 1006 | (10.2.0.1 and 192.0.2.65). |
| 1007 | .PP |
| 1008 | (The internal addresses can, but don't need, to be allocated from the |
| 1009 | RFC1918 space. The addresses of the gateway machines, on which |
| 1010 | .BR tripe (8) |
| 1011 | is running, and which the example has drawn from 192.0.2.0/24, need to |
| 1012 | be publicly routable \(en or at least, routable with respect to whatever |
| 1013 | networks physically connect them.) |
| 1014 | .PP |
| 1015 | |
| 1016 | |
| 1017 | . |
| 1018 | .\"-------------------------------------------------------------------------- |
| 1019 | .SH "GLOSSARY" |
| 1020 | . |
| 1021 | In the following entries, terms which are themselves defined in the |
| 1022 | glossary are written in |
| 1023 | .BR "bold face" . |
| 1024 | . |
| 1025 | .TP |
| 1026 | .B "External address" |
| 1027 | The IP address (and port number) used to contact a |
| 1028 | .BR peer 's |
| 1029 | instance of the |
| 1030 | .BR tripe (8) |
| 1031 | server. External addresses must usually be proper, publically routable |
| 1032 | IP address, i.e., not RFC1918 address. Compare with |
| 1033 | .BR "tunnel address" . |
| 1034 | .TP |
| 1035 | .B "Key exchange" |
| 1036 | The process by which two |
| 1037 | .BR peer s |
| 1038 | verify each other's identity and agree cryptographic keys for securing |
| 1039 | the |
| 1040 | .B tunnel |
| 1041 | between them. |
| 1042 | .TP |
| 1043 | .B "Peer" |
| 1044 | An instance of the |
| 1045 | .BR tripe (8) |
| 1046 | server running on a remote host. The local server maintains secure |
| 1047 | .BR tunnel s |
| 1048 | with each of the peers it knows about. |
| 1049 | .TP |
| 1050 | .B "Private key" |
| 1051 | A secret, used by a |
| 1052 | .BR tripe (8) |
| 1053 | server to prove its identity to its |
| 1054 | .BR peer s, |
| 1055 | who know the corresponding |
| 1056 | .BR "public key" . |
| 1057 | .TP |
| 1058 | .B "Public key" |
| 1059 | A value used by the |
| 1060 | .BR tripe (8) |
| 1061 | server to verify the identity of its |
| 1062 | .BR peer s. |
| 1063 | See also |
| 1064 | .BR "private key" . |
| 1065 | .TP |
| 1066 | .B "Tunnel" |
| 1067 | The secure virtual network link between two |
| 1068 | .BR peer s. |
| 1069 | .TP |
| 1070 | .B "Tunnel address" |
| 1071 | The (possibly private) IP address associated with a particular |
| 1072 | .BR peer 's |
| 1073 | end of a |
| 1074 | .BR tunnel . |
| 1075 | Tunnel addresses need not be publically routable, and might reasonably |
| 1076 | be allocated from the private-use space defined in RFC1918. Compare |
| 1077 | with |
| 1078 | .BR "external address" . |
| 1079 | . |
| 1080 | .\"-------------------------------------------------------------------------- |
| 1081 | .SH "SEE ALSO" |
| 1082 | . |
| 1083 | .SS "Documents provided in the distribution" |
| 1084 | .TP |
| 1085 | .BR tripe (8) |
| 1086 | The main TrIPE server. |
| 1087 | .TP |
| 1088 | .BR tripectl (1) |
| 1089 | Client program for administering the server. |
| 1090 | .TP |
| 1091 | .BR tripe-admin (5) |
| 1092 | Description of the server administration protocol. |
| 1093 | .TP |
| 1094 | .BR tripe-keys "(8), " tripe-keys.conf (5) |
| 1095 | Tool for managing TrIPE public keys. |
| 1096 | .TP |
| 1097 | .BR tripemon (1) |
| 1098 | Graphical monitor program for the TrIPE server. |
| 1099 | . |
| 1100 | .SS "Other documents" |
| 1101 | .TP |
| 1102 | .I "The Wrestlers Protocol: A simple, practical, secure, deniable protocol for key-exchange" |
| 1103 | Research paper on the protocol TrIPE uses for key exchange. Available |
| 1104 | electronically as |
| 1105 | .BR http://eprint.iacr.org/2006/386/ . |
| 1106 | . |
| 1107 | .\"-------------------------------------------------------------------------- |
| 1108 | .SH "AUTHOR" |
| 1109 | Mark Wooding, <mdw@distorted.org.uk> |
| 1110 | . |
| 1111 | .\"----- That's all, folks -------------------------------------------------- |