chiark / gitweb /
Don't make scary messages just because one key didn't work on a message:
[tripe] / doc / protocol.ms
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