a50a1fa9 |
1 | .\" -*-nroff-*- |
2 | .so tmac.rfc |
3 | . |
4 | .TL "Straylight/Edgeware" "Mark Wooding" |
5 | .TL "Request for Comments: XXXX" "Straylight/Edgeware" |
620078f9 |
6 | .TL "" "11 April 2003" |
a50a1fa9 |
7 | |
8 | |
620078f9 |
9 | .TT XXXX Wooding "April 2003" \ |
a50a1fa9 |
10 | "TrIPE: The Trivial IP Encryption Protocol" |
11 | |
620078f9 |
12 | .T0 "Status of this Memo" |
a50a1fa9 |
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 "" ) |
620078f9 |
79 | .LE |
a50a1fa9 |
80 | |
81 | .T1 "Key exchange" |
82 | |
83 | |
84 | |
620078f9 |
85 | .T0 "Data representation and notation" |
86 | .de SD |
87 | .LS |
88 | .. |
89 | .de SM |
90 | .br |
91 | .B "\\$1" \c |
92 | .if !'\\$2'.' \ \\$2\c |
93 | .if !'\\$3'' \{\ |
94 | : |
95 | .I "\\$3" \c |
96 | .\} |
97 | .. |
98 | .de SR |
99 | .br |
100 | .B "\\$1" \c |
101 | .if !'\\$2'.' \ \\$2\c |
102 | .if !'\\$3'' : \\$3 |
103 | .. |
104 | .de ST |
105 | .SM "\\$1" "\\$2" "\\$3" |
106 | .LS 2n |
107 | .. |
108 | |
109 | We need to deal with a number of data items during the protocol. |
110 | .if t \{\ |
111 | Object names are given in |
112 | .I italics . |
113 | .\} |
114 | A plain name indicates `our' value; a `primed' name (e.g., |
115 | .I alpha' ) |
116 | indicates the peer's corresponding value. If a compound data item name |
117 | is primed, toggle the primed-ness of the components. |
118 | |
119 | Data objects are given types which determine their representation in |
120 | protocol messages. Type names are given in |
121 | .B UPPERCASE . |
122 | |
123 | .T1 "Atomic data items" |
a50a1fa9 |
124 | |
125 | .DL |
620078f9 |
126 | .DI OCTET |
127 | A single octet, representing a value between 0 and 255. |
128 | |
129 | .DI U16 |
130 | A pair of octets, representing a value between 0 and 65535. The more |
131 | significant octet appears first. |
132 | |
133 | .DI U32 |
134 | Four octets, representing a value between 0 and 4294967295. More |
135 | significant octets appear first. |
136 | |
137 | .DI "STRING \fIn\fR\fB" |
138 | A string of |
139 | .I n |
140 | octets. A |
141 | .B STRING |
142 | does not have a numeric value. |
143 | |
144 | .DI MP |
145 | A nonnegative multiprecision integer. Let |
146 | .I n |
147 | be the integer to be represented, and let |
148 | .I z |
149 | be the number of octets required to represent |
150 | .I n |
151 | in base-256 format with no leading zeroes; i.e., if |
152 | .I n |
153 | = 0, then |
154 | .I z |
155 | = 0; otherwise |
156 | .I z |
157 | is the unique integer such that |
158 | .ie t 256\*(^(\fIz\fP\-1\*(^) \(<= \fIn\fP < 256\*(^(\fIz\fP\*(^). |
159 | .el 256^{z-1} <= n < 256^z. |
160 | The encoding for |
161 | .I n |
162 | then consists of two octets encoding |
163 | .I z |
164 | as a |
165 | .B U16 |
166 | followed by the |
167 | .I z |
168 | octets which are the base-256 digits of |
169 | .I n , |
170 | most significant first. |
171 | .LE |
172 | |
173 | .T1 "Structured data items" |
174 | |
175 | A |
176 | .I structure |
177 | is a compound object which is simply the concatenation of a number of |
178 | its component objects. Structures are used directly as messages, and |
179 | indirectly as things to be hashed or encrypted. |
180 | |
181 | The notation |
182 | |
183 | .SD |
184 | . ST STRUCT . kx-cookie |
185 | . SR OCTET . 0x11 |
186 | . SM MP . c |
187 | . SM STRING 20 hash |
188 | . LE |
189 | .LE |
190 | |
191 | indicates that |
192 | .I msg-cookie |
193 | consists of the two items |
194 | |
195 | |
196 | |
197 | |
198 | .SD |
199 | . ST STRUCT . kx-prechal |
200 | . SR OCTET . 0x10 |
201 | . SM MP . c |
202 | . LE |
203 | .LE |
a50a1fa9 |
204 | |
620078f9 |
205 | .SD |
206 | . ST STRUCT . kx-cookie |
207 | . SR OCTET . 0x11 |
208 | . SM MP . c |
209 | . ST HASH . |
210 | . SR TEXT . "tripe-cookie" |
211 | . SM MP . c' |
212 | . LE |
213 | . LE |
a50a1fa9 |
214 | .LE |
215 | |
216 | .T0 "Security considerations" |
217 | |
218 | This memo describes a cryptographic protocol for ensuring secrecy and |
219 | integrity of communications between network hosts. From this point of |
220 | view, it is entirely about security. |
221 | |
222 | Before deploying TrIPE on their own systems, administrators ought to |
223 | satisfy themselves that the cryptographic algorithms used are |
224 | sufficiently strong for their purposes, and that their implementation of |
620078f9 |
225 | the TrIPE software has come from a trustworthy source. They should also |
a50a1fa9 |
226 | ensure that they have adequate procedures in place for transporting |
227 | public keys without a risk of them being modified by adversaries. |
228 | |
229 | .T0 "References" |
230 | |
231 | .BS IPSEC-EVAL |
232 | .BR IPSEC |
233 | Kent, S., Atkinson, R., `Security Architecture for the Internet |
234 | Protocol', RFC 2401, November 1998. |
235 | |
236 | .BR IPSEC-EVAL |
237 | Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec', |
238 | December 1999. |
239 | |
240 | .BR REQ |
241 | Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels', |
242 | BCP 14, RFC 2119, March 1997. |
243 | .BE |