--- /dev/null
+.\" -*-nroff-*-
+.so tmac.rfc
+.
+.TL "Straylight/Edgeware" "Mark Wooding"
+.TL "Request for Comments: XXXX" "Straylight/Edgeware"
+.TL "" "21 February 2001"
+
+
+.TT XXXX Wooding "February 2001" \
+ "TrIPE: The Trivial IP Encryption Protocol"
+
+.TI 0 "Status of this Memo"
+
+This memo defines an Experimental Protocol for the Internet community.
+This memo does not specify an Internet standard of any kind. Discussion
+and suggestions for improvement are requested. Distribution of this
+memo is unlimited.
+
+.T0 "Introduction"
+
+TrIPE is a simple protocol which enables IP datagrams (or other data) to
+be exchanged between a pair of hosts over a hostile network while
+maintaining the properties of secrecy and authenticity; i.e., that the
+content of the datagrams cannot be determined by eavesdroppers on the
+network, and that either endpoint can determine whether a datagram
+received is an unaltered copy of one that was sent by the other.
+
+While similar services are provided by other protocols (e.g., [IPSEC]),
+they tend to be very complicated and difficult to analyze (see, for
+example, [IPSEC-EVAL]). By contrast, TrIPE attempts to get away with
+doing as little as possible. There are no negotiations to decide which
+ciphers are to be used: these things are defined in the protocol
+specification. There is only one key-exchange algorithm defined.
+
+In addition to making analysis easier, a simpler protocol also helps
+reduce the complexity of implementations: this makes implementation
+errors less likely, and makes auditing an implementation for security
+holes a more realistic proposition.
+
+.T0 "Interpretation"
+
+The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
+`SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
+document are to be interpreted as described in [REQ].
+
+.T0 "Protocol overview"
+
+The TrIPE protocol sets up a secure point-to-point channel between two
+peer hosts, through which IP datagrams may be passed securely.
+
+All TrIPE messages are sent as UDP datagrams. No UDP port has been
+registered for TrIPE yet.
+
+When a pair of peer hosts are made aware of each other, they begin a key
+negotiation, using an authenticated Diffie-Hellman key exchange
+protocol. This enables them to agree a
+.I keyset :
+a collection of short-term symmetric keys and other parameters (such as
+sequence numbering spaces). Keysets expire after a fixed amount of
+time, or after they have been used to encrypt a given amount of data,
+whichever happens first. Before the current keyset expires, a new key
+negotation is started, so that the peers can seamlessly start using the
+new keys before the old ones become invalid.
+
+.T1 "Keysets"
+
+A
+.I keyset
+is a collection of symmetric keys and associated state information. The
+items required, and the symbolic names by which they are described in
+this document are:
+
+.UL
+.LI
+.B "Incoming and outgoing encryption keys"
+.K c (
+and
+.K' c "" )
+
+
+.T1 "Key exchange"
+
+
+
+.T0 "Data representation"
+
+The following data types are used in the protocol:
+
+.DL
+.DI "32-bit"
+Some guff I haven't written yet.
+
+.DI "Rather longer name"
+Some more guff.
+.LE
+
+.T0 "Security considerations"
+
+This memo describes a cryptographic protocol for ensuring secrecy and
+integrity of communications between network hosts. From this point of
+view, it is entirely about security.
+
+Before deploying TrIPE on their own systems, administrators ought to
+satisfy themselves that the cryptographic algorithms used are
+sufficiently strong for their purposes, and that their implementation of
+the TrIPE software has come from a trusted source. They should also
+ensure that they have adequate procedures in place for transporting
+public keys without a risk of them being modified by adversaries.
+
+.T0 "References"
+
+.BS IPSEC-EVAL
+.BR IPSEC
+Kent, S., Atkinson, R., `Security Architecture for the Internet
+Protocol', RFC 2401, November 1998.
+
+.BR IPSEC-EVAL
+Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec',
+December 1999.
+
+.BR REQ
+Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels',
+BCP 14, RFC 2119, March 1997.
+.BE
~mdw / tripe / blobdiff