chiark - git - mdw - tripe/blob - 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 ""                                  "11 April 2003"
   7
   8
   9 .TT XXXX Wooding "April 2003" \
  10   "TrIPE: The Trivial IP Encryption Protocol"
  11
  12 .T0 "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 .LE
  80
  81 .T1 "Key exchange"
  82
  83
  84
  85 .T0 "Data representation and notation"
  86 .de SD
  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
 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
 119 Data objects are given types which determine their representation in
 120 protocol messages.  Type names are given in
 121 .B UPPERCASE .
 122
 123 .T1 "Atomic data items"
 124
 125 .DL
 126 .DI OCTET
 127 A single octet, representing a value between 0 and 255.
 128
 129 .DI U16
 130 A pair of octets, representing a value between 0 and 65535.  The more
 131 significant octet appears first.
 132
 133 .DI U32
 134 Four octets, representing a value between 0 and 4294967295.  More
 135 significant octets appear first.
 136
 137 .DI "STRING \fIn\fR\fB"
 138 A string of
 139 .I n
 140 octets.  A
 141 .B STRING
 142 does not have a numeric value.
 143
 144 .DI MP
 145 A nonnegative multiprecision integer.  Let
 146 .I n
 147 be the integer to be represented, and let
 148 .I z
 149 be the number of octets required to represent
 150 .I n
 151 in base-256 format with no leading zeroes; i.e., if
 152 .I n
 153 = 0, then
 154 .I z
 155 = 0; otherwise
 156 .I z
 157 is the unique integer such that
 158 .ie t 256\*(^(\fIz\fP\-1\*(^) \(<= \fIn\fP < 256\*(^(\fIz\fP\*(^).
 159 .el 256^{z-1} <= n < 256^z.
 160 The encoding for
 161 .I n
 162 then consists of two octets encoding
 163 .I z
 164 as a
 165 .B U16
 166 followed by the
 167 .I z
 168 octets which are the base-256 digits of
 169 .I n ,
 170 most significant first.
 171 .LE
 172
 173 .T1 "Structured data items"
 174
 175 A
 176 .I structure
 177 is a compound object which is simply the concatenation of a number of
 178 its component objects.  Structures are used directly as messages, and
 179 indirectly as things to be hashed or encrypted.
 180
 181 The notation
 182
 183 .SD
 184 .  ST STRUCT . kx-cookie
 185 .    SR OCTET . 0x11
 186 .    SM MP . c
 187 .    SM STRING 20 hash
 188 .  LE
 189 .LE
 190
 191 indicates that
 192 .I msg-cookie
 193 consists of the two items
 194
 195
 196
 197
 198 .SD
 199 .  ST STRUCT . kx-prechal
 200 .    SR OCTET . 0x10
 201 .    SM MP . c
 202 .  LE
 203 .LE
 204
 205 .SD
 206 .  ST STRUCT . kx-cookie
 207 .    SR OCTET . 0x11
 208 .    SM MP . c
 209 .    ST HASH .
 210 .      SR TEXT . "tripe-cookie"
 211 .      SM MP . c'
 212 .    LE
 213 .  LE
 214 .LE
 215
 216 .T0 "Security considerations"
 217
 218 This memo describes a cryptographic protocol for ensuring secrecy and
 219 integrity of communications between network hosts.  From this point of
 220 view, it is entirely about security.
 221
 222 Before deploying TrIPE on their own systems, administrators ought to
 223 satisfy themselves that the cryptographic algorithms used are
 224 sufficiently strong for their purposes, and that their implementation of
 225 the TrIPE software has come from a trustworthy source.  They should also
 226 ensure that they have adequate procedures in place for transporting
 227 public keys without a risk of them being modified by adversaries.
 228
 229 .T0 "References"
 230
 231 .BS IPSEC-EVAL
 232 .BR IPSEC
 233 Kent, S., Atkinson, R., `Security Architecture for the Internet
 234 Protocol', RFC 2401, November 1998.
 235
 236 .BR IPSEC-EVAL
 237 Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec',
 238 December 1999.
 239
 240 .BR REQ
 241 Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels',
 242 BCP 14, RFC 2119, March 1997.
 243 .BE