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" |
3cdc3f3a |
7 | . |
620078f9 |
8 | .TT XXXX Wooding "April 2003" \ |
a50a1fa9 |
9 | "TrIPE: The Trivial IP Encryption Protocol" |
3cdc3f3a |
10 | . |
11 | .TI 0 "Status of this Memo" |
12 | .P |
a50a1fa9 |
13 | This memo defines an Experimental Protocol for the Internet community. |
14 | This memo does not specify an Internet standard of any kind. Discussion |
15 | and suggestions for improvement are requested. Distribution of this |
16 | memo is unlimited. |
3cdc3f3a |
17 | .P |
a50a1fa9 |
18 | .T0 "Introduction" |
3cdc3f3a |
19 | .P |
a50a1fa9 |
20 | TrIPE is a simple protocol which enables IP datagrams (or other data) to |
21 | be exchanged between a pair of hosts over a hostile network while |
22 | maintaining the properties of secrecy and authenticity; i.e., that the |
23 | content of the datagrams cannot be determined by eavesdroppers on the |
24 | network, and that either endpoint can determine whether a datagram |
25 | received is an unaltered copy of one that was sent by the other. |
3cdc3f3a |
26 | .P |
a50a1fa9 |
27 | While similar services are provided by other protocols (e.g., [IPSEC]), |
28 | they tend to be very complicated and difficult to analyze (see, for |
29 | example, [IPSEC-EVAL]). By contrast, TrIPE attempts to get away with |
30 | doing as little as possible. There are no negotiations to decide which |
31 | ciphers are to be used: these things are defined in the protocol |
32 | specification. There is only one key-exchange algorithm defined. |
3cdc3f3a |
33 | .P |
a50a1fa9 |
34 | In addition to making analysis easier, a simpler protocol also helps |
35 | reduce the complexity of implementations: this makes implementation |
36 | errors less likely, and makes auditing an implementation for security |
37 | holes a more realistic proposition. |
3cdc3f3a |
38 | .P |
a50a1fa9 |
39 | .T0 "Interpretation" |
3cdc3f3a |
40 | .P |
a50a1fa9 |
41 | The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', |
42 | `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this |
43 | document are to be interpreted as described in [REQ]. |
3cdc3f3a |
44 | .P |
a50a1fa9 |
45 | .T0 "Protocol overview" |
3cdc3f3a |
46 | .P |
a50a1fa9 |
47 | The TrIPE protocol sets up a secure point-to-point channel between two |
48 | peer hosts, through which IP datagrams may be passed securely. |
3cdc3f3a |
49 | .P |
a50a1fa9 |
50 | All TrIPE messages are sent as UDP datagrams. No UDP port has been |
51 | registered for TrIPE yet. |
3cdc3f3a |
52 | .P |
a50a1fa9 |
53 | When a pair of peer hosts are made aware of each other, they begin a key |
54 | negotiation, using an authenticated Diffie-Hellman key exchange |
55 | protocol. This enables them to agree a |
56 | .I keyset : |
57 | a collection of short-term symmetric keys and other parameters (such as |
58 | sequence numbering spaces). Keysets expire after a fixed amount of |
59 | time, or after they have been used to encrypt a given amount of data, |
60 | whichever happens first. Before the current keyset expires, a new key |
61 | negotation is started, so that the peers can seamlessly start using the |
62 | new keys before the old ones become invalid. |
3cdc3f3a |
63 | .P |
a50a1fa9 |
64 | .T1 "Keysets" |
3cdc3f3a |
65 | .P |
a50a1fa9 |
66 | A |
67 | .I keyset |
68 | is a collection of symmetric keys and associated state information. The |
69 | items required, and the symbolic names by which they are described in |
70 | this document are: |
a50a1fa9 |
71 | .UL |
72 | .LI |
73 | .B "Incoming and outgoing encryption keys" |
74 | .K c ( |
75 | and |
76 | .K' c "" ) |
620078f9 |
77 | .LE |
3cdc3f3a |
78 | .P |
a50a1fa9 |
79 | .T1 "Key exchange" |
3cdc3f3a |
80 | . |
81 | . |
82 | .P |
620078f9 |
83 | .T0 "Data representation and notation" |
3cdc3f3a |
84 | . |
620078f9 |
85 | .de SD |
3cdc3f3a |
86 | .P |
620078f9 |
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 | .. |
3cdc3f3a |
108 | .P |
620078f9 |
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. |
3cdc3f3a |
118 | .P |
620078f9 |
119 | Data objects are given types which determine their representation in |
120 | protocol messages. Type names are given in |
121 | .B UPPERCASE . |
3cdc3f3a |
122 | .P |
620078f9 |
123 | .T1 "Atomic data items" |
a50a1fa9 |
124 | .DL |
620078f9 |
125 | .DI OCTET |
126 | A single octet, representing a value between 0 and 255. |
620078f9 |
127 | .DI U16 |
128 | A pair of octets, representing a value between 0 and 65535. The more |
129 | significant octet appears first. |
620078f9 |
130 | .DI U32 |
131 | Four octets, representing a value between 0 and 4294967295. More |
132 | significant octets appear first. |
620078f9 |
133 | .DI "STRING \fIn\fR\fB" |
134 | A string of |
135 | .I n |
136 | octets. A |
137 | .B STRING |
138 | does not have a numeric value. |
620078f9 |
139 | .DI MP |
140 | A nonnegative multiprecision integer. Let |
141 | .I n |
142 | be the integer to be represented, and let |
143 | .I z |
144 | be the number of octets required to represent |
145 | .I n |
3cdc3f3a |
146 | in base-256 format with no leading zeroes, except that if |
147 | .I n |
148 | = 0 |
149 | then |
620078f9 |
150 | .I z |
3cdc3f3a |
151 | = 1; in other cases, |
620078f9 |
152 | .I z |
153 | is the unique integer such that |
154 | .ie t 256\*(^(\fIz\fP\-1\*(^) \(<= \fIn\fP < 256\*(^(\fIz\fP\*(^). |
155 | .el 256^{z-1} <= n < 256^z. |
156 | The encoding for |
157 | .I n |
158 | then consists of two octets encoding |
159 | .I z |
160 | as a |
161 | .B U16 |
162 | followed by the |
163 | .I z |
164 | octets which are the base-256 digits of |
165 | .I n , |
166 | most significant first. |
167 | .LE |
3cdc3f3a |
168 | .P |
620078f9 |
169 | .T1 "Structured data items" |
3cdc3f3a |
170 | .P |
620078f9 |
171 | A |
172 | .I structure |
173 | is a compound object which is simply the concatenation of a number of |
174 | its component objects. Structures are used directly as messages, and |
175 | indirectly as things to be hashed or encrypted. |
3cdc3f3a |
176 | .P |
620078f9 |
177 | The notation |
620078f9 |
178 | .SD |
179 | . ST STRUCT . kx-cookie |
180 | . SR OCTET . 0x11 |
181 | . SM MP . c |
182 | . SM STRING 20 hash |
183 | . LE |
184 | .LE |
3cdc3f3a |
185 | .P |
620078f9 |
186 | indicates that |
187 | .I msg-cookie |
188 | consists of the two items |
3cdc3f3a |
189 | . |
190 | .f |
191 | . |
192 | .SD |
193 | . ST STRUCT . msg-packet |
194 | . SR OCTET . 0x00 |
195 | . br |
196 | payload |
197 | . LE |
198 | .LE |
199 | . |
620078f9 |
200 | .SD |
201 | . ST STRUCT . kx-prechal |
202 | . SR OCTET . 0x10 |
203 | . SM MP . c |
204 | . LE |
205 | .LE |
3cdc3f3a |
206 | . |
620078f9 |
207 | .SD |
208 | . ST STRUCT . kx-cookie |
209 | . SR OCTET . 0x11 |
210 | . SM MP . c |
211 | . ST HASH . |
212 | . SR TEXT . "tripe-cookie" |
213 | . SM MP . c' |
214 | . LE |
215 | . LE |
a50a1fa9 |
216 | .LE |
3cdc3f3a |
217 | .P |
a50a1fa9 |
218 | .T0 "Security considerations" |
3cdc3f3a |
219 | .P |
a50a1fa9 |
220 | This memo describes a cryptographic protocol for ensuring secrecy and |
221 | integrity of communications between network hosts. From this point of |
222 | view, it is entirely about security. |
3cdc3f3a |
223 | .P |
a50a1fa9 |
224 | Before deploying TrIPE on their own systems, administrators ought to |
225 | satisfy themselves that the cryptographic algorithms used are |
226 | sufficiently strong for their purposes, and that their implementation of |
620078f9 |
227 | the TrIPE software has come from a trustworthy source. They should also |
a50a1fa9 |
228 | ensure that they have adequate procedures in place for transporting |
229 | public keys without a risk of them being modified by adversaries. |
3cdc3f3a |
230 | .P |
a50a1fa9 |
231 | .T0 "References" |
a50a1fa9 |
232 | .BS IPSEC-EVAL |
233 | .BR IPSEC |
234 | Kent, S., Atkinson, R., `Security Architecture for the Internet |
235 | Protocol', RFC 2401, November 1998. |
3cdc3f3a |
236 | . |
a50a1fa9 |
237 | .BR IPSEC-EVAL |
238 | Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec', |
239 | December 1999. |
3cdc3f3a |
240 | . |
a50a1fa9 |
241 | .BR REQ |
242 | Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels', |
243 | BCP 14, RFC 2119, March 1997. |
244 | .BE |