a50a1fa9 |
1 | .\" -*-nroff-*- |
2 | .so tmac.rfc |
3 | . |
4 | .TL "Straylight/Edgeware" "Mark Wooding" |
5 | .TL "Request for Comments: XXXX" "Straylight/Edgeware" |
6 | .TL "" "21 February 2001" |
7 | |
8 | |
9 | .TT XXXX Wooding "February 2001" \ |
10 | "TrIPE: The Trivial IP Encryption Protocol" |
11 | |
12 | .TI 0 "Status of this Memo" |
13 | |
14 | This memo defines an Experimental Protocol for the Internet community. |
15 | This memo does not specify an Internet standard of any kind. Discussion |
16 | and suggestions for improvement are requested. Distribution of this |
17 | memo is unlimited. |
18 | |
19 | .T0 "Introduction" |
20 | |
21 | TrIPE is a simple protocol which enables IP datagrams (or other data) to |
22 | be exchanged between a pair of hosts over a hostile network while |
23 | maintaining the properties of secrecy and authenticity; i.e., that the |
24 | content of the datagrams cannot be determined by eavesdroppers on the |
25 | network, and that either endpoint can determine whether a datagram |
26 | received is an unaltered copy of one that was sent by the other. |
27 | |
28 | While similar services are provided by other protocols (e.g., [IPSEC]), |
29 | they tend to be very complicated and difficult to analyze (see, for |
30 | example, [IPSEC-EVAL]). By contrast, TrIPE attempts to get away with |
31 | doing as little as possible. There are no negotiations to decide which |
32 | ciphers are to be used: these things are defined in the protocol |
33 | specification. There is only one key-exchange algorithm defined. |
34 | |
35 | In addition to making analysis easier, a simpler protocol also helps |
36 | reduce the complexity of implementations: this makes implementation |
37 | errors less likely, and makes auditing an implementation for security |
38 | holes a more realistic proposition. |
39 | |
40 | .T0 "Interpretation" |
41 | |
42 | The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', |
43 | `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this |
44 | document are to be interpreted as described in [REQ]. |
45 | |
46 | .T0 "Protocol overview" |
47 | |
48 | The TrIPE protocol sets up a secure point-to-point channel between two |
49 | peer hosts, through which IP datagrams may be passed securely. |
50 | |
51 | All TrIPE messages are sent as UDP datagrams. No UDP port has been |
52 | registered for TrIPE yet. |
53 | |
54 | When a pair of peer hosts are made aware of each other, they begin a key |
55 | negotiation, using an authenticated Diffie-Hellman key exchange |
56 | protocol. This enables them to agree a |
57 | .I keyset : |
58 | a collection of short-term symmetric keys and other parameters (such as |
59 | sequence numbering spaces). Keysets expire after a fixed amount of |
60 | time, or after they have been used to encrypt a given amount of data, |
61 | whichever happens first. Before the current keyset expires, a new key |
62 | negotation is started, so that the peers can seamlessly start using the |
63 | new keys before the old ones become invalid. |
64 | |
65 | .T1 "Keysets" |
66 | |
67 | A |
68 | .I keyset |
69 | is a collection of symmetric keys and associated state information. The |
70 | items required, and the symbolic names by which they are described in |
71 | this document are: |
72 | |
73 | .UL |
74 | .LI |
75 | .B "Incoming and outgoing encryption keys" |
76 | .K c ( |
77 | and |
78 | .K' c "" ) |
79 | |
80 | |
81 | .T1 "Key exchange" |
82 | |
83 | |
84 | |
85 | .T0 "Data representation" |
86 | |
87 | The following data types are used in the protocol: |
88 | |
89 | .DL |
90 | .DI "32-bit" |
91 | Some guff I haven't written yet. |
92 | |
93 | .DI "Rather longer name" |
94 | Some more guff. |
95 | .LE |
96 | |
97 | .T0 "Security considerations" |
98 | |
99 | This memo describes a cryptographic protocol for ensuring secrecy and |
100 | integrity of communications between network hosts. From this point of |
101 | view, it is entirely about security. |
102 | |
103 | Before deploying TrIPE on their own systems, administrators ought to |
104 | satisfy themselves that the cryptographic algorithms used are |
105 | sufficiently strong for their purposes, and that their implementation of |
106 | the TrIPE software has come from a trusted source. They should also |
107 | ensure that they have adequate procedures in place for transporting |
108 | public keys without a risk of them being modified by adversaries. |
109 | |
110 | .T0 "References" |
111 | |
112 | .BS IPSEC-EVAL |
113 | .BR IPSEC |
114 | Kent, S., Atkinson, R., `Security Architecture for the Internet |
115 | Protocol', RFC 2401, November 1998. |
116 | |
117 | .BR IPSEC-EVAL |
118 | Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec', |
119 | December 1999. |
120 | |
121 | .BR REQ |
122 | Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels', |
123 | BCP 14, RFC 2119, March 1997. |
124 | .BE |