1IPSEC.SECRETS(5)                [FIXME: manual]               IPSEC.SECRETS(5)
2
3
4

NAME

6       ipsec.secrets - secrets for IKE/IPsec authentication
7

DESCRIPTION

9       The file ipsec.secrets contains a list of secrets, aka preshared
10       secrets, RSA signatures, or pointers to X.509 Digital Certificates.
11       These secrets are used by ipsec_pluto(8) , the Openswan Internet Key
12       Exchange daemon, to authenticate other hosts. Currently there are five
13       kinds of secrets: preshared secrets, RSA private keys, passphrases for
14       X.509 certificates and if compiled with USE_XAUTH=true there is support
15       for XAUTH static passwords. Smartcard support has been moved to the NSS
16       framework.
17
18       It is vital that these secrets be protected. The file should be owned
19       by root, and permissions should be set to block all access by others.
20       (eg: chmod 600)
21
22       The file is a sequence of entries and include directives. Here is an
23       example - each entry or directive must start at the left margin, but if
24       it continues beyond a single line, each continuation line must be
25       indented.
26
27           # sample /etc/ipsec.secrets file for 10.1.0.1
28           10.1.0.1 10.2.0.1: PSK "secret shared by two hosts"
29           # sample roadwarrior
30           %any gateway.corp.com: PSK "shared secret with many roadwarriors"
31           # sample server for roadwarriors
32           myip %any : PSK "shared secret with many roadwarriors"
33
34           # an entry may be split across lines,
35           # but indentation matters
36           www.xs4all.nl @www.kremvax.ru
37               10.6.0.1 10.7.0.1 1.8.0.1: PSK "secret shared by 5 systems"
38
39           # an RSA private key.
40           # note that the lines are too wide for a
41           # man page, so ... has been substituted for
42           # the truncated part
43           @my.com: rsa {
44               Modulus: 0syXpo/6waam+ZhSs8Lt6jnBzu3C4grtt...
45               PublicExponent: 0sAw==
46               PrivateExponent: 0shlGbVR1m8Z+7rhzSyenCaBN...
47               Prime1: 0s8njV7WTxzVzRz7AP+0OraDxmEAt1BL5l...
48               Prime2: 0s1LgR7/oUMo9BvfU8yRFNos1s211KX5K0...
49               Exponent1: 0soaXj85ihM5M2inVf/NfHmtLutVz4r...
50               Exponent2: 0sjdAL9VFizF+BKU4ohguJFzOd55OG6...
51               Coefficient: 0sK1LWwgnNrNFGZsS/2GuMBg9nYVZ...
52               }
53
54           # An X.509 pem encoded private key file with (optional) passphrase
55           : RSA vpnserverKey.pem "<optional passphrase>"
56           # An X.509 pem encoded private key file locked with a passphrase
57           # Note: the %prompt keyword means someone has to actually enter the passphrase
58           # at load time - usually via ipsec_whack(8)
59           :  RSA vpnserverKey.pem %prompt
60
61           # XAUTH password, used with leftxauthusername=username
62           @username : XAUTH "password"
63
64           include ipsec.*.secrets  # get secrets from other files
65
66
67       Each entry in the file is a list of indices, followed by a secret. The
68       two parts are separated by a colon (:) that is followed by whitespace
69       or a newline. For compatibility with the previous form of this file, if
70       the key part is just a double-quoted string the colon may be left out.
71       If filenames are not absolute paths, they are relative to the
72       ipsec.d/private/ directory.
73
74       An index is an IP address, or a Fully Qualified Domain Name, user@FQDN,
75       %any or %any6 (other kinds may come). An IP address may be written in
76       the familiar dotted quad form or as a domain name to be looked up when
77       the file is loaded (or in any of the forms supported by the Openswan
78       ipsec_ttoaddr(3) routine). In many cases it is a bad idea to use domain
79       names because the name server may not be running or may be insecure. To
80       denote a Fully Qualified Domain Name (as opposed to an IP address
81       denoted by its domain name), precede the name with an at sign (@).
82
83       Matching IDs with indices is fairly straightforward: they have to be
84       equal. In the case of a “Road Warrior” connection, if an equal match is
85       not found for the Peer´s ID, and it is in the form of an IP address, an
86       index of %any will match the peer´s IP address if IPV4 and %any6 will
87       match a the peer´s IP address if IPV6. Currently, the obsolete notation
88       0.0.0.0 may be used in place of %any, but please stop doing this, as it
89       will likely stop working around Openswan v3.0.
90
91       This file is only read at startup time. If any changes are made to this
92       file, the pluto daemon should be told to re-read this file using the
93       command ipsec secrets or ipsec auto --rereadsecrets. If there are any
94       keyfiles protected by a passphrase using %prompt, you will be prompted
95       again to enter these passphrases. To skip the prompting, just hit
96       return to skip unlocking that particular private key. Note that
97       currently there is no way to add a specific new entry - it´s all or
98       nothing.
99
100       Smartcard support has been moved from Openswan to NSS. Please see the
101       NSS documentation on how to configure smartcards.
102
103       An additional complexity arises in the case of authentication by
104       preshared secret: the responder will need to look up the secret before
105       the Peer´s ID payload has been decoded, so the ID used will be the IP
106       address.
107
108       To authenticate a connection between two hosts, the entry that most
109       specifically matches the host and peer IDs is used. An entry with no
110       index will match any host and peer. More specifically, an entry with
111       one index will match a host and peer if the index matches the host´s ID
112       (the peer isn´t considered). Still more specifically, an entry with
113       multiple indices will match a host and peer if the host ID and peer ID
114       each match one of the indices. If the key is for an asymmetric
115       authentication technique (i.e. a public key system such as RSA), an
116       entry with multiple indices will match a host and peer even if only the
117       host ID matches an index (it is presumed that the multiple indices are
118       all identities of the host). It is acceptable for two entries to be the
119       best match as long as they agree about the secret or private key.
120
121       Authentication by preshared secret requires that both systems find the
122       identical secret (the secret is not actually transmitted by the IKE
123       protocol). If both the host and peer appear in the index list, the same
124       entry will be suitable for both systems so verbatim copying between
125       systems can be used. This naturally extends to larger groups sharing
126       the same secret. Thus multiple-index entries are best for PSK
127       authentication.
128
129       Authentication by RSA Signatures requires that each host have its own
130       private key. A host could reasonably use a different private keys for
131       different interfaces and for different peers. But it would not be
132       normal to share entries between systems. Thus no-index and one-index
133       forms of entry often make sense for RSA Signature authentication.
134
135       The key part of an entry may start with a token indicating the kind of
136       key. “RSA” signifies RSA private key and “PSK” signifies PreShared Key
137       (case is ignored). For compatibility with previous forms of this file,
138       PSK is the default.
139
140       The token “XAUTH” indicates a eXtended Authentication password. There
141       should be one indice, and it should be in the @FQDN format. The file
142       will be searched with the XAUTH username, which is usually provided in
143       the configuration file. XAUTH is otherwise identical to PSK in syntax.
144
145       If the RSA points to a filename, this is assumed to be a PEM (or DER?)
146       encoded X.509 private key. The private key may be protected by a 3DES
147       encryption. 1DES encrypted key files will be rejected. If the private
148       key is protected by a passphrase and this passphrase is not specified
149       in ipsec.secrets, the connection cannot be automatically started using
150       auto=start, but instead must be brought up using ipsec auto --up
151       connname, upon which the user will be prompted for the passphrase to
152       unlock the private key belonging to the X.509 certificate. PKCS#12
153       files, which include the private key file, cannot be specified in
154       ipsec.secrets. Private keys can be extracted from PKCS#12 files using
155       the following command: openssl pkcs12 -nocerts -in clientCert.p12 -out
156       clientKey.pem
157
158       A preshared secret is most conveniently represented as a sequence of
159       characters, delimited by the double-quote character ("). The sequence
160       cannot contain a newline or double-quote. Strictly speaking, the secret
161       is actually the sequence of bytes that is used in the file to represent
162       the sequence of characters (excluding the delimiters). A preshared
163       secret may also be represented, without quotes, in any form supported
164       by ipsec_ttodata(3).
165
166       An RSA private key is a composite of eight generally large numbers. The
167       notation used is a brace-enclosed list of field name and value pairs
168       (see the example above). A suitable key, in a suitable format, may be
169       generated by ipsec_rsasigkey(8). The structure is very similar to that
170       used by BIND 8.2.2 or later, but note that the numbers must have a “0s”
171       prefix if they are in base 64. The order of the fields is fixed.
172
173       The first token an entry must start in the first column of its line.
174       Subsequent tokens must be separated by whitespace, except for a colon
175       token, which only needs to be followed by whitespace. A newline is
176       taken as whitespace, but every line of an entry after the first must be
177       indented.
178
179       Whitespace at the end of a line is ignored (except in the 0t notation
180       for a key). At the start of line or after whitespace, # and the
181       following text up to the end of the line is treated as a comment.
182       Within entries, all lines must be indented (except for lines with no
183       tokens). Outside entries, no line may be indented (this is to make sure
184       that the file layout reflects its structure).
185
186       An include directive causes the contents of the named file to be
187       processed before continuing with the current file. The filename is
188       subject to “globbing” as in sh(1), so every file with a matching name
189       is processed. Includes may be nested to a modest depth (10, currently).
190       If the filename doesn´t start with a /, the directory containing the
191       current file is prepended to the name. The include directive is a line
192       that starts with the word include, followed by whitespace, followed by
193       the filename (which must not contain whitespace).
194

FILES

196       /etc/ipsec.secrets
197

SEE ALSO

199       The rest of the Openswan distribution, in particular ipsec.conf(5),
200       ipsec(8), ipsec_newhostkey(8), ipsec_rsasigkey(8),
201       ipsec_showhostkey(8), ipsec_auto(8) --rereadsecrets, and ipsec_pluto(8)
202       --listen,.  BIND 8.2.2 or later, ftp://ftp.isc.org/isc/bind/src/
203

HISTORY

205       Originally designed for the FreeS/WAN project <http://www.freeswan.org>
206       by D. Hugh Redelmeier. Updated for Openswan by Ken Bantoft.
207

BUGS

209       If an ID is 0.0.0.0, it will match %any; if it is 0::0, it will match
210       %any6.
211
212
213
214[FIXME: source]                   10/06/2010                  IPSEC.SECRETS(5)
Impressum