Commit | Line | Data |
---|---|---|
a50a1fa9 | 1 | .\" -*-nroff-*- |
2 | .so tmac.rfc | |
3 | . | |
e04c2d50 MW |
4 | .TL "Straylight/Edgeware" "Mark Wooding" |
5 | .TL "Request for Comments: XXXX" "Straylight/Edgeware" | |
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 | |
e04c2d50 | 55 | protocol. This enables them to agree a |
a50a1fa9 | 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'' \{\ | |
e04c2d50 | 94 | : |
620078f9 | 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 |
e04c2d50 | 109 | We need to deal with a number of data items during the protocol. |
620078f9 | 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 |
e04c2d50 | 120 | protocol messages. Type names are given in |
620078f9 | 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 |
e04c2d50 | 147 | .I n |
3cdc3f3a | 148 | = 0 |
e04c2d50 | 149 | then |
620078f9 | 150 | .I z |
3cdc3f3a | 151 | = 1; in other cases, |
e04c2d50 | 152 | .I z |
620078f9 | 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 |