.TH IPSEC.SECRETS 5 "28 March 1999".SH NAMEipsec.secrets \- secrets for IKE/IPsec authentication.SH DESCRIPTIONThe file \fIipsec.secrets\fP holds a table of secrets.These secrets are used by \fIipsec_pluto\fP(8), the Open Internet KeyExchange daemon, to authenticate other hosts.Currently there are two kinds of secrets: preshared secrets and.\" the private part of DSS keys.RSA private keys..LPIt is vital that these secrets be protected.  The file should be ownedby the super-user,and its permissions should be set to block all access by others..LPThe file is a sequence of entries and include directives.Here is an example.  Each entry or directive must start at theleft margin, but if it continues beyond a single line, each continuationline must be indented..LP.RS.nf# sample /etc/ipsec.secrets file for 10.1.0.110.1.0.1 10.2.0.1: PSK "secret shared by two hosts"# an entry may be split across lines,# but indentation matterswww.xs4all.nl @www.kremvax.ru\ \ \ \ 10.6.0.1 10.7.0.1 1.8.0.1: PSK "secret shared by 5".\" # Private part of our DSS key, in base 64,.\" # as generated by BIND 8.2.1's dnskeygen..\" # Since this is the default key for this host,.\" # there is no need to specify indices..\" : DSS 0siMs0N/hfRoCBMXA6plPtuv58/+c=# an RSA private key.# note that the lines are too wide for a# man page, so ... has been substituted for# the truncated part@my.com: rsa {\ \ \ \ Modulus:\ 0syXpo/6waam+ZhSs8Lt6jnBzu3C4grtt...\ \ \ \ PublicExponent:\ 0sAw==\ \ \ \ PrivateExponent:\ 0shlGbVR1m8Z+7rhzSyenCaBN...\ \ \ \ Prime1:\ 0s8njV7WTxzVzRz7AP+0OraDxmEAt1BL5l...\ \ \ \ Prime2:\ 0s1LgR7/oUMo9BvfU8yRFNos1s211KX5K0...\ \ \ \ Exponent1:\ 0soaXj85ihM5M2inVf/NfHmtLutVz4r...\ \ \ \ Exponent2:\ 0sjdAL9VFizF+BKU4ohguJFzOd55OG6...\ \ \ \ Coefficient:\ 0sK1LWwgnNrNFGZsS/2GuMBg9nYVZ...\ \ \ \ }include ipsec.*.secrets	# get secrets from other files.fi.RE.LPEach entry in the file is a list of indices, followed by a secret.The two parts are separated by a colon (\fB:\fP) that isfollowed by whitespace or a newline.  For compatabilitywith the previous form of this file, if the key part is just adouble-quoted string the colon may be left out..LPAn index is an IP address, or a Fully Qualified Domain Name, user@FQDN,\fB%any\fP or \fB%any6\fP (other kinds may come).  An IP address may be writtenin the familiar dotted quad form or as a domain name to be looked upwhen the file is loaded(or in any of the forms supported by the Openswan \fIipsec_ttoaddr\fP(3)routine).  In many cases it is a bad idea to use domain names becausethe name server may not be running or may be insecure.  To denote aFully Qualified Domain Name (as opposed to an IP address denoted byits domain name), precede the name with an at sign (\fB@\fP)..LPMatching IDs with indices is fairly straightforward: they have to beequal.  In the case of a ``Road Warrior'' connection, if an equalmatch is not found for the Peer's ID, and it is in the form of an IPaddress, an index of \fB%any\fP will match the peer's IP address if IPV4and \fB%any6\fP will match a the peer's IP address if IPV6.Currently, the obsolete notation \fB0.0.0.0\fP may be used in place of\fB%any\fP..LPAn additional complexityarises in the case of authentication by preshared secret: theresponder will need to look up the secret before the Peer's ID payload hasbeen decoded, so the ID used will be the IP address..LPTo authenticate a connection between two hosts, the entry that mostspecifically matches the host and peer IDs is used.  An entry with noindex will match any host and peer.  More specifically, an entry with one index willmatch a host and peer if the index matches the host's ID (the peer isn'tconsidered).  Still more specifically, an entry with multiple indices will match a host andpeer if the host ID and peer ID each match one of the indices.  If the keyis for an asymmetric authentication technique (i.e. a public keysystem such as RSA), an entry with multiple indices will match a hostand peer even if only the host ID matches an index (it is presumed that themultiple indices are all identities of the host).It is acceptable for two entries to be the best match aslong as they agree about the secret or private key..LPAuthentication by preshared secret requires that both systems find theidentical secret (the secret is not actually transmitted by the IKEprotocol).  If both the host and peer appear in the index list, thesame entry will be suitable for both systems so verbatim copyingbetween systems can be used.  This naturally extends to larger groupssharing the same secret.  Thus multiple-index entries are best for PSKauthentication..LPAuthentication by RSA Signatures requires that each host have its own privatekey.  A host could reasonably use a different private keysfor different interfaces and for different peers.  But it would notbe normal to share entries between systems.  Thus thus no-index andone-index forms of entry often make sense for RSA Signature authentication..LPThe key part of an entry may start with a token indicating the kind ofkey.  ``RSA'' signifies RSA private key and ``PSK'' signifiesPreShared Key (case is ignored).  For compatability with previousforms of this file, PSK is the default..LPA preshared secret is most conveniently represented as a sequence ofcharacters, delimited by the double-quotecharacter (\fB"\fP).  The sequence cannot contain a newline ordouble-quote.  Strictly speaking, the secret is actually the sequenceof bytes that is used in the file to represent the sequence ofcharacters (excluding the delimiters).A preshared secret may also be represented, without quotes, in any form supported by\fIipsec_ttodata\fP(3)..LPAn RSA private key is a composite of eight generally large numbers.  The notationused is a brace-enclosed list of field name and value pairs (see the example above).A suitable key, in a suitable format, may be generated by \fIipsec_rsasigkey\fP(8).The structure is very similar to that used by BIND 8.2.2 or later, but note thatthe numbers must have a ``0s'' prefix if they are in base 64.  The order ofthe fields is fixed..LPThe first token an entry must start inthe first column of its line.  Subsequent tokens must beseparated by whitespace,except for a colon token, which only needs to be followed by whitespace.A newline is taken as whitespace, but everyline of an entry after the first must be indented..LPWhitespace at the end of a line is ignored (except in the 0tnotation for a key).  At the start of line orafter whitespace, \fB#\fP and the following text up to the end of theline is treated as a comment.  Within entries, all lines must beindented (except for lines with no tokens).Outside entries, no line may be indented (this is to make sure thatthe file layout reflects its structure)..LPAn include directive causes the contents of the named file to be processedbefore continuing with the current file.  The filename is subject to``globbing'' as in \fIsh\fP(1), so every file with a matching nameis processed.  Includes may be nested to a modestdepth (10, currently).  If the filename doesn't start with a \fB/\fP, thedirectory containing the current file is prepended to the name.  Theinclude directive is a line that starts with the word \fBinclude\fP,followed by whitespace, followed by the filename (which must not containwhitespace)..SH FILES/etc/ipsec.secrets.SH SEE ALSOThe rest of the Openswan distribution, in particular\fIipsec.conf\fP(5),\fIipsec\fP(8),\fIipsec_newhostkey\fP(8),\fIipsec_rsasigkey\fP(8),\fIipsec_showhostkey\fP(8),\fIipsec_auto\fP(8) \fB\-\-rereadsecrets\fP,and \fIipsec_pluto\fP(8) \fB\-\-listen\fP,..brBIND 8.2.2 or later, ftp://ftp.isc.org/isc/bind/src/.SH HISTORYOriginally designed for the FreeS/WAN project<http://www.freeswan.org>by D. Hugh Redelmeier..SH BUGSIf an ID is \fB0.0.0.0\fP, it will match \fB%any\fP;if it is \fB0::0\fP, it will match \fB%any6\fP.