| 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 |