chiark / gitweb /
changelog: start 0.6.8
[secnet.git] / secnet.8
index 0b0afda6be773c0a8d5e2b236d1b12b64e1d44c7..c92a0e3a8d90f8220055f2f104621decfc0ea69b 100644 (file)
--- a/secnet.8
+++ b/secnet.8
@@ -63,6 +63,36 @@ Check configuration and exit.
 Configuration file key defining active sites.
 The default is \fBsites\fR.
 
+.SH "CAPABILITY NEGOTIATION"
+Sites negotiate with each other during key exchange
+in order to determine which cryptographic algorithms and other features
+\(en termed
+.I capabilities
+\(en
+they each support.
+Capabilities are assigned small integer numbers.
+In many cases,
+capability numbers can be assigned in the configuration file,
+as described below;
+but secnet's default assignments will often be satisfactory.
+.PP
+Capability numbers between 0 and 7 inclusive
+are reserved for local use:
+secnet will never make use of them without explicit configuration.
+This may be useful to migrate from one set of parameters
+for a particular cryptographic algorithm
+to different, incompatible, parameters for the same algorithm.
+Other capability numbers are assigned by default
+by various kinds of closures.
+See the descriptions below for details.
+.PP
+It is essential that a capability number mean the same thing
+to each of a pair of peers.
+It's possible to configure a site
+so that it uses different capability numbers for the same feature
+when it communicates with different peer sites,
+but this is likely to be more confusing than useful.
+
 .SH "CONFIGURATION FILE"
 .SS Overview
 The default configuration file is \fI/etc/secnet/secnet.conf\fR.
@@ -284,7 +314,6 @@ Boolean.
 If \fBtrue\fR (the default) then check if \fIp\fR is prime.
 .PP
 A \fIdh closure\fR defines a group to be used for key exchange.
-The same group must be used by all sites in the VPN.
 
 .SS logfile
 \fBlogfile(\fIDICT\fB)\fR => \fIlog closure\fR
@@ -454,15 +483,8 @@ Messages are padded to a multiple of this many bytes.  This
 serves to obscure the exact length of messages.  The default is 16,
 .TP
 .B capab-num
-The transform capability number to use when advertising this
-transform.  Both ends must have the same meaning (or, at least, a
-compatible transform) for each transform capability number they have
-in common.  The default for serpent-eax is 9.
-.IP
-Transform capability numbers in the range 8..15 are intended for
-allocation by the implementation, and may be assigned as the default
-for new transforms in the future.  Transform capability numbers in the
-range 0..7 are reserved for definition by the user.
+The capability number to use when advertising this
+transform.  The default for serpent-eax is 9.
 .PP
 A \fItransform closure\fR is a reversible means of transforming
 messages for transmission over a (presumably) insecure network.
@@ -486,7 +508,7 @@ As above.
 Note that this uses a big-endian variant of the Serpent block cipher
 (which is not compatible with most other Serpent implementations).
 .SS rsa-private
-\fBrsa-private(\fIPATH\fB\fR[, \fICHECK\fR]\fB)\fR => \fIrsaprivkey closure\fR
+\fBrsa-private(\fIPATH\fB\fR[, \fICHECK\fR]\fB)\fR => \fIsigprivkey closure\fR
 .TP
 .I PATH
 String.
@@ -499,7 +521,7 @@ Boolean.
 If \fBtrue\fR (the default) then check that the key is valid.
 
 .SS rsa-public
-\fBrsa-public(\fIKEY\fB, \fIMODULUS\fB)\fR => \fIrsapubkey closure\fR
+\fBrsa-public(\fIKEY\fB, \fIMODULUS\fB)\fR => \fIsigpubkey closure\fR
 .TP
 .I KEY
 String.
@@ -538,7 +560,7 @@ A \fIresolver closure\fR.
 A \fIrandomsource closure\fR.
 .TP
 .B local-key
-An \fIrsaprivkey closure\fR.
+An \fIsigprivkey closure\fR.
 The key used to prove our identity to the peer.
 .TP
 .B address
@@ -552,14 +574,14 @@ Number.
 The port to contact the peer.
 .TP
 .B key
-An \fIrsapubkey closure\fR.
+An \fIsigpubkey closure\fR.
 The key used to verify the peer's identity.
 .TP
 .B transform
 One or more \fItransform closures\fR.
 Used to protect packets exchanged with the peer.  These should
 all have distinct \fBcapab-num\fR values, and the same \fBcapab-num\fR
-value should refer to the same (or a compatible) transform at both
+value should have the same (or a compatible) meaning at both
 ends.  The list should be in order of preference, most preferred
 first.  (The end which sends MSG1,MSG3 ends up choosing; the ordering
 at the other end is irrelevant.)