chiark / gitweb /
Document the new `-b' option.
[tripe] / doc / protocol.ms
CommitLineData
a50a1fa9 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
14This memo defines an Experimental Protocol for the Internet community.
15This memo does not specify an Internet standard of any kind. Discussion
16and suggestions for improvement are requested. Distribution of this
17memo is unlimited.
18
19.T0 "Introduction"
20
21TrIPE is a simple protocol which enables IP datagrams (or other data) to
22be exchanged between a pair of hosts over a hostile network while
23maintaining the properties of secrecy and authenticity; i.e., that the
24content of the datagrams cannot be determined by eavesdroppers on the
25network, and that either endpoint can determine whether a datagram
26received is an unaltered copy of one that was sent by the other.
27
28While similar services are provided by other protocols (e.g., [IPSEC]),
29they tend to be very complicated and difficult to analyze (see, for
30example, [IPSEC-EVAL]). By contrast, TrIPE attempts to get away with
31doing as little as possible. There are no negotiations to decide which
32ciphers are to be used: these things are defined in the protocol
33specification. There is only one key-exchange algorithm defined.
34
35In addition to making analysis easier, a simpler protocol also helps
36reduce the complexity of implementations: this makes implementation
37errors less likely, and makes auditing an implementation for security
38holes a more realistic proposition.
39
40.T0 "Interpretation"
41
42The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
43`SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
44document are to be interpreted as described in [REQ].
45
46.T0 "Protocol overview"
47
48The TrIPE protocol sets up a secure point-to-point channel between two
49peer hosts, through which IP datagrams may be passed securely.
50
51All TrIPE messages are sent as UDP datagrams. No UDP port has been
52registered for TrIPE yet.
53
54When a pair of peer hosts are made aware of each other, they begin a key
55negotiation, using an authenticated Diffie-Hellman key exchange
56protocol. This enables them to agree a
57.I keyset :
58a collection of short-term symmetric keys and other parameters (such as
59sequence numbering spaces). Keysets expire after a fixed amount of
60time, or after they have been used to encrypt a given amount of data,
61whichever happens first. Before the current keyset expires, a new key
62negotation is started, so that the peers can seamlessly start using the
63new keys before the old ones become invalid.
64
65.T1 "Keysets"
66
67A
68.I keyset
69is a collection of symmetric keys and associated state information. The
70items required, and the symbolic names by which they are described in
71this document are:
72
73.UL
74.LI
75.B "Incoming and outgoing encryption keys"
76.K c (
77and
78.K' c "" )
79
80
81.T1 "Key exchange"
82
83
84
85.T0 "Data representation"
86
87The following data types are used in the protocol:
88
89.DL
90.DI "32-bit"
91Some guff I haven't written yet.
92
93.DI "Rather longer name"
94Some more guff.
95.LE
96
97.T0 "Security considerations"
98
99This memo describes a cryptographic protocol for ensuring secrecy and
100integrity of communications between network hosts. From this point of
101view, it is entirely about security.
102
103Before deploying TrIPE on their own systems, administrators ought to
104satisfy themselves that the cryptographic algorithms used are
105sufficiently strong for their purposes, and that their implementation of
106the TrIPE software has come from a trusted source. They should also
107ensure that they have adequate procedures in place for transporting
108public keys without a risk of them being modified by adversaries.
109
110.T0 "References"
111
112.BS IPSEC-EVAL
113.BR IPSEC
114Kent, S., Atkinson, R., `Security Architecture for the Internet
115Protocol', RFC 2401, November 1998.
116
117.BR IPSEC-EVAL
118Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec',
119December 1999.
120
121.BR REQ
122Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels',
123BCP 14, RFC 2119, March 1997.
124.BE