| 1 | .\" -*-nroff-*- |
| 2 | .so tmac.rfc |
| 3 | . |
| 4 | .TL "Straylight/Edgeware" "Mark Wooding" |
| 5 | .TL "Request for Comments: XXXX" "Straylight/Edgeware" |
| 6 | .TL "" "11 April 2003" |
| 7 | . |
| 8 | .TT XXXX Wooding "April 2003" \ |
| 9 | "TrIPE: The Trivial IP Encryption Protocol" |
| 10 | . |
| 11 | .TI 0 "Status of this Memo" |
| 12 | .P |
| 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. |
| 17 | .P |
| 18 | .T0 "Introduction" |
| 19 | .P |
| 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. |
| 26 | .P |
| 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. |
| 33 | .P |
| 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. |
| 38 | .P |
| 39 | .T0 "Interpretation" |
| 40 | .P |
| 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]. |
| 44 | .P |
| 45 | .T0 "Protocol overview" |
| 46 | .P |
| 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. |
| 49 | .P |
| 50 | All TrIPE messages are sent as UDP datagrams. No UDP port has been |
| 51 | registered for TrIPE yet. |
| 52 | .P |
| 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. |
| 63 | .P |
| 64 | .T1 "Keysets" |
| 65 | .P |
| 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: |
| 71 | .UL |
| 72 | .LI |
| 73 | .B "Incoming and outgoing encryption keys" |
| 74 | .K c ( |
| 75 | and |
| 76 | .K' c "" ) |
| 77 | .LE |
| 78 | .P |
| 79 | .T1 "Key exchange" |
| 80 | . |
| 81 | . |
| 82 | .P |
| 83 | .T0 "Data representation and notation" |
| 84 | . |
| 85 | .de SD |
| 86 | .P |
| 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 | .P |
| 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 | .P |
| 119 | Data objects are given types which determine their representation in |
| 120 | protocol messages. Type names are given in |
| 121 | .B UPPERCASE . |
| 122 | .P |
| 123 | .T1 "Atomic data items" |
| 124 | .DL |
| 125 | .DI OCTET |
| 126 | A single octet, representing a value between 0 and 255. |
| 127 | .DI U16 |
| 128 | A pair of octets, representing a value between 0 and 65535. The more |
| 129 | significant octet appears first. |
| 130 | .DI U32 |
| 131 | Four octets, representing a value between 0 and 4294967295. More |
| 132 | significant octets appear first. |
| 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. |
| 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 |
| 146 | in base-256 format with no leading zeroes, except that if |
| 147 | .I n |
| 148 | = 0 |
| 149 | then |
| 150 | .I z |
| 151 | = 1; in other cases, |
| 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 |
| 168 | .P |
| 169 | .T1 "Structured data items" |
| 170 | .P |
| 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. |
| 176 | .P |
| 177 | The notation |
| 178 | .SD |
| 179 | . ST STRUCT . kx-cookie |
| 180 | . SR OCTET . 0x11 |
| 181 | . SM MP . c |
| 182 | . SM STRING 20 hash |
| 183 | . LE |
| 184 | .LE |
| 185 | .P |
| 186 | indicates that |
| 187 | .I msg-cookie |
| 188 | consists of the two items |
| 189 | . |
| 190 | .f |
| 191 | . |
| 192 | .SD |
| 193 | . ST STRUCT . msg-packet |
| 194 | . SR OCTET . 0x00 |
| 195 | . br |
| 196 | payload |
| 197 | . LE |
| 198 | .LE |
| 199 | . |
| 200 | .SD |
| 201 | . ST STRUCT . kx-prechal |
| 202 | . SR OCTET . 0x10 |
| 203 | . SM MP . c |
| 204 | . LE |
| 205 | .LE |
| 206 | . |
| 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 |
| 216 | .LE |
| 217 | .P |
| 218 | .T0 "Security considerations" |
| 219 | .P |
| 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. |
| 223 | .P |
| 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 |
| 227 | the TrIPE software has come from a trustworthy source. They should also |
| 228 | ensure that they have adequate procedures in place for transporting |
| 229 | public keys without a risk of them being modified by adversaries. |
| 230 | .P |
| 231 | .T0 "References" |
| 232 | .BS IPSEC-EVAL |
| 233 | .BR IPSEC |
| 234 | Kent, S., Atkinson, R., `Security Architecture for the Internet |
| 235 | Protocol', RFC 2401, November 1998. |
| 236 | . |
| 237 | .BR IPSEC-EVAL |
| 238 | Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec', |
| 239 | December 1999. |
| 240 | . |
| 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 |