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 .TT XXXX Wooding "April 2003" \
   9   "TrIPE: The Trivial IP Encryption Protocol"
  10 .
  11 .TI 0 "Status of this Memo"
  12 .P
  13 This memo defines an Experimental Protocol for the Internet community.
  14 This memo does not specify an Internet standard of any kind.  Discussion
  15 and suggestions for improvement are requested.  Distribution of this
  16 memo is unlimited.
  17 .P
  18 .T0 "Introduction"
  19 .P
  20 TrIPE is a simple protocol which enables IP datagrams (or other data) to
  21 be exchanged between a pair of hosts over a hostile network while
  22 maintaining the properties of secrecy and authenticity; i.e., that the
  23 content of the datagrams cannot be determined by eavesdroppers on the
  24 network, and that either endpoint can determine whether a datagram
  25 received is an unaltered copy of one that was sent by the other.
  26 .P
  27 While similar services are provided by other protocols (e.g., [IPSEC]),
  28 they tend to be very complicated and difficult to analyze (see, for
  29 example, [IPSEC-EVAL]).  By contrast, TrIPE attempts to get away with
  30 doing as little as possible.  There are no negotiations to decide which
  31 ciphers are to be used: these things are defined in the protocol
  32 specification.  There is only one key-exchange algorithm defined.
  33 .P
  34 In addition to making analysis easier, a simpler protocol also helps
  35 reduce the complexity of implementations: this makes implementation
  36 errors less likely, and makes auditing an implementation for security
  37 holes a more realistic proposition.
  38 .P
  39 .T0 "Interpretation"
  40 .P
  41 The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
  42 `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
  43 document are to be interpreted as described in [REQ].
  44 .P
  45 .T0 "Protocol overview"
  46 .P
  47 The TrIPE protocol sets up a secure point-to-point channel between two
  48 peer hosts, through which IP datagrams may be passed securely.
  49 .P
  50 All TrIPE messages are sent as UDP datagrams.  No UDP port has been
  51 registered for TrIPE yet.
  52 .P
  53 When a pair of peer hosts are made aware of each other, they begin a key
  54 negotiation, using an authenticated Diffie-Hellman key exchange
  55 protocol.  This enables them to agree a
  56 .I keyset :
  57 a collection of short-term symmetric keys and other parameters (such as
  58 sequence numbering spaces).  Keysets expire after a fixed amount of
  59 time, or after they have been used to encrypt a given amount of data,
  60 whichever happens first.  Before the current keyset expires, a new key
  61 negotation is started, so that the peers can seamlessly start using the
  62 new keys before the old ones become invalid.
  63 .P
  64 .T1 "Keysets"
  65 .P
  66 A
  67 .I keyset
  68 is a collection of symmetric keys and associated state information.  The
  69 items required, and the symbolic names by which they are described in
  70 this document are:
  71 .UL
  72 .LI
  73 .B "Incoming and outgoing encryption keys"
  74 .K c (
  75 and
  76 .K' c "" )
  77 .LE
  78 .P
  79 .T1 "Key exchange"
  80 .
  81 .
  82 .P
  83 .T0 "Data representation and notation"
  84 .
  85 .de SD
  86 .P
  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 .P
 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 .P
 119 Data objects are given types which determine their representation in
 120 protocol messages.  Type names are given in
 121 .B UPPERCASE .
 122 .P
 123 .T1 "Atomic data items"
 124 .DL
 125 .DI OCTET
 126 A single octet, representing a value between 0 and 255.
 127 .DI U16
 128 A pair of octets, representing a value between 0 and 65535.  The more
 129 significant octet appears first.
 130 .DI U32
 131 Four octets, representing a value between 0 and 4294967295.  More
 132 significant octets appear first.
 133 .DI "STRING \fIn\fR\fB"
 134 A string of
 135 .I n
 136 octets.  A
 137 .B STRING
 138 does not have a numeric value.
 139 .DI MP
 140 A nonnegative multiprecision integer.  Let
 141 .I n
 142 be the integer to be represented, and let
 143 .I z
 144 be the number of octets required to represent
 145 .I n
 146 in base-256 format with no leading zeroes, except that if
 147 .I n
 148 = 0
 149 then
 150 .I z
 151 = 1; in other cases,
 152 .I z
 153 is the unique integer such that
 154 .ie t 256\*(^(\fIz\fP\-1\*(^) \(<= \fIn\fP < 256\*(^(\fIz\fP\*(^).
 155 .el 256^{z-1} <= n < 256^z.
 156 The encoding for
 157 .I n
 158 then consists of two octets encoding
 159 .I z
 160 as a
 161 .B U16
 162 followed by the
 163 .I z
 164 octets which are the base-256 digits of
 165 .I n ,
 166 most significant first.
 167 .LE
 168 .P
 169 .T1 "Structured data items"
 170 .P
 171 A
 172 .I structure
 173 is a compound object which is simply the concatenation of a number of
 174 its component objects.  Structures are used directly as messages, and
 175 indirectly as things to be hashed or encrypted.
 176 .P
 177 The notation
 178 .SD
 179 .  ST STRUCT . kx-cookie
 180 .    SR OCTET . 0x11
 181 .    SM MP . c
 182 .    SM STRING 20 hash
 183 .  LE
 184 .LE
 185 .P
 186 indicates that
 187 .I msg-cookie
 188 consists of the two items
 189 .
 190 .f
 191 .
 192 .SD
 193 .  ST STRUCT . msg-packet
 194 .    SR OCTET . 0x00
 195 .    br
 196 payload
 197 .  LE
 198 .LE
 199 .
 200 .SD
 201 .  ST STRUCT . kx-prechal
 202 .    SR OCTET . 0x10
 203 .    SM MP . c
 204 .  LE
 205 .LE
 206 .
 207 .SD
 208 .  ST STRUCT . kx-cookie
 209 .    SR OCTET . 0x11
 210 .    SM MP . c
 211 .    ST HASH .
 212 .      SR TEXT . "tripe-cookie"
 213 .      SM MP . c'
 214 .    LE
 215 .  LE
 216 .LE
 217 .P
 218 .T0 "Security considerations"
 219 .P
 220 This memo describes a cryptographic protocol for ensuring secrecy and
 221 integrity of communications between network hosts.  From this point of
 222 view, it is entirely about security.
 223 .P
 224 Before deploying TrIPE on their own systems, administrators ought to
 225 satisfy themselves that the cryptographic algorithms used are
 226 sufficiently strong for their purposes, and that their implementation of
 227 the TrIPE software has come from a trustworthy source.  They should also
 228 ensure that they have adequate procedures in place for transporting
 229 public keys without a risk of them being modified by adversaries.
 230 .P
 231 .T0 "References"
 232 .BS IPSEC-EVAL
 233 .BR IPSEC
 234 Kent, S., Atkinson, R., `Security Architecture for the Internet
 235 Protocol', RFC 2401, November 1998.
 236 .
 237 .BR IPSEC-EVAL
 238 Ferguson, N., Schneier, B., `A Cryptographic Evaluation of IPsec',
 239 December 1999.
 240 .
 241 .BR REQ
 242 Bradner, S., `Key words for use in RFCs to Indicate Requirement Levels',
 243 BCP 14, RFC 2119, March 1997.
 244 .BE