chiark / gitweb /
Allow admin clients to filter out async messages. Send notifications
[tripe] / doc / protocol.ms
index f02bb1c..849a662 100644 (file)
@@ -4,53 +4,52 @@
 .TL "Straylight/Edgeware"               "Mark Wooding"
 .TL "Request for Comments:  XXXX"       "Straylight/Edgeware"
 .TL ""                                  "11 April 2003"
-
-
+.
 .TT XXXX Wooding "April 2003" \
   "TrIPE: The Trivial IP Encryption Protocol"
-
-.T0 "Status of this Memo"
-
+.
+.T0 "Status of this Memo"
+.P
 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.
-
+.P
 .T0 "Introduction"
-
+.P
 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.
-
+.P
 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.
-
+.P
 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.
-
+.P
 .T0 "Interpretation"
-
+.P
 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].
-
+.P
 .T0 "Protocol overview"
-
+.P
 The TrIPE protocol sets up a secure point-to-point channel between two
 peer hosts, through which IP datagrams may be passed securely.
-
+.P
 All TrIPE messages are sent as UDP datagrams.  No UDP port has been
 registered for TrIPE yet.
-
+.P
 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 
@@ -61,15 +60,14 @@ 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.
-
+.P
 .T1 "Keysets"
-
+.P
 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"
@@ -77,13 +75,15 @@ this document are:
 and
 .K' c "" )
 .LE
-
+.P
 .T1 "Key exchange"
-
-
-
+.
+.
+.P
 .T0 "Data representation and notation"
+.
 .de SD
+.P
 .LS
 ..
 .de SM
@@ -105,7 +105,7 @@ and
 .SM "\\$1" "\\$2" "\\$3"
 .LS 2n
 ..
-
+.P
 We need to deal with a number of data items during the protocol.  
 .if t \{\
 Object names are given in
@@ -115,32 +115,27 @@ A plain name indicates `our' value; a `primed' name (e.g.,
 .I alpha' )
 indicates the peer's corresponding value.  If a compound data item name
 is primed, toggle the primed-ness of the components.
-
+.P
 Data objects are given types which determine their representation in
 protocol messages.  Type names are given in 
 .B UPPERCASE .
-
+.P
 .T1 "Atomic data items"
-
 .DL
 .DI OCTET
 A single octet, representing a value between 0 and 255.
-
 .DI U16
 A pair of octets, representing a value between 0 and 65535.  The more
 significant octet appears first.
-
 .DI U32
 Four octets, representing a value between 0 and 4294967295.  More
 significant octets appear first.
-
 .DI "STRING \fIn\fR\fB"
 A string of
 .I n
 octets.  A
 .B STRING
 does not have a numeric value.
-
 .DI MP
 A nonnegative multiprecision integer.  Let
 .I n
@@ -148,11 +143,12 @@ be the integer to be represented, and let
 .I z
 be the number of octets required to represent
 .I n
-in base-256 format with no leading zeroes; i.e., if
-.I n
-= 0, then
+in base-256 format with no leading zeroes, except that if
+.I n 
+= 0
+then 
 .I z
-= 0; otherwise
+= 1; in other cases,
 .I z 
 is the unique integer such that
 .ie t 256\*(^(\fIz\fP\-1\*(^) \(<= \fIn\fP < 256\*(^(\fIz\fP\*(^).
@@ -169,17 +165,16 @@ octets which are the base-256 digits of
 .I n ,
 most significant first.
 .LE
-
+.P
 .T1 "Structured data items"
-
+.P
 A
 .I structure
 is a compound object which is simply the concatenation of a number of
 its component objects.  Structures are used directly as messages, and
 indirectly as things to be hashed or encrypted.
-
+.P
 The notation
-
 .SD
 .  ST STRUCT . kx-cookie
 .    SR OCTET . 0x11
@@ -187,21 +182,28 @@ The notation
 .    SM STRING 20 hash
 .  LE
 .LE
-
+.P
 indicates that
 .I msg-cookie
 consists of the two items
-
-
-
-
+.
+.f
+.
+.SD
+.  ST STRUCT . msg-packet
+.    SR OCTET . 0x00
+.    br
+payload
+.  LE
+.LE
+.
 .SD
 .  ST STRUCT . kx-prechal
 .    SR OCTET . 0x10
 .    SM MP . c
 .  LE
 .LE
-
+.
 .SD
 .  ST STRUCT . kx-cookie
 .    SR OCTET . 0x11
@@ -212,31 +214,30 @@ consists of the two items
 .    LE
 .  LE
 .LE
-
+.P
 .T0 "Security considerations"
-
+.P
 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.
-
+.P
 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 trustworthy 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.
-
+.P
 .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.