Annotation of embedaddon/strongswan/man/ipsec.secrets.5.in, revision 1.1
1.1 ! misho 1: .TH IPSEC.SECRETS 5 "2011-12-14" "@PACKAGE_VERSION@" "strongSwan"
! 2: .SH NAME
! 3: ipsec.secrets \- secrets for IKE/IPsec authentication
! 4: .SH DESCRIPTION
! 5: The file \fIipsec.secrets\fP holds a table of secrets.
! 6: These secrets are used by the strongSwan Internet Key Exchange (IKE) daemons
! 7: pluto (IKEv1) and charon (IKEv2) to authenticate other hosts.
! 8: .LP
! 9: It is vital that these secrets be protected. The file should be owned
! 10: by the super-user,
! 11: and its permissions should be set to block all access by others.
! 12: .LP
! 13: The file is a sequence of entries and include directives.
! 14: Here is an example.
! 15: .LP
! 16: .RS
! 17: .nf
! 18: # /etc/ipsec.secrets - strongSwan IPsec secrets file
! 19: 192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"
! 20:
! 21: : RSA moonKey.pem
! 22:
! 23: alice@strongswan.org : EAP "x3.dEhgN"
! 24:
! 25: carol : XAUTH "4iChxLT3"
! 26:
! 27: dave : XAUTH "ryftzG4A"
! 28:
! 29: # get secrets from other files
! 30: include ipsec.*.secrets
! 31: .fi
! 32: .RE
! 33: .LP
! 34: Each entry in the file is a list of optional ID selectors, followed by a secret.
! 35: The two parts are separated by a colon (\fB:\fP) that is surrounded
! 36: by whitespace. If no ID selectors are specified the line must start with a
! 37: colon.
! 38: .LP
! 39: A selector is an IP address, a Fully Qualified Domain Name, user@FQDN,
! 40: \fB%any\fP or \fB%any6\fP (other kinds may come).
! 41: .LP
! 42: Matching IDs with selectors is fairly straightforward: they have to be
! 43: equal. In the case of a ``Road Warrior'' connection, if an equal
! 44: match is not found for the Peer's ID, and it is in the form of an IP
! 45: address, a selector of \fB%any\fP will match the peer's IP address if IPV4
! 46: and \fB%any6\fP will match a the peer's IP address if IPV6.
! 47: Currently, the obsolete notation \fB0.0.0.0\fP may be used in place of
! 48: \fB%any\fP.
! 49: .LP
! 50: In IKEv1 an additional complexity
! 51: arises in the case of authentication by preshared secret: the
! 52: responder will need to look up the secret before the Peer's ID payload has
! 53: been decoded, so the ID used will be the IP address.
! 54: .LP
! 55: To authenticate a connection between two hosts, the entry that most
! 56: specifically matches the host and peer IDs is used. An entry with no
! 57: selectors will match any host and peer. More specifically, an entry with one
! 58: selector will match a host and peer if the selector matches the host's ID (the
! 59: peer isn't considered). Still more specifically, an entry with multiple
! 60: selectors will match a host and peer if the host ID and peer ID each match one
! 61: of the selectors. If the key is for an asymmetric authentication technique
! 62: (i.e. a public key system such as RSA), an entry with multiple selectors will
! 63: match a host and peer even if only the host ID matches a selector (it is
! 64: presumed that the selectors are all identities of the host).
! 65: It is acceptable for two entries to be the best match as
! 66: long as they agree about the secret or private key.
! 67: .LP
! 68: Authentication by preshared secret requires that both systems find the
! 69: identical secret (the secret is not actually transmitted by the IKE
! 70: protocol). If both the host and peer appear in the selector list, the
! 71: same entry will be suitable for both systems so verbatim copying
! 72: between systems can be used. This naturally extends to larger groups
! 73: sharing the same secret. Thus multiple-selector entries are best for PSK
! 74: authentication.
! 75: .LP
! 76: Authentication by public key systems such as RSA requires that each host
! 77: have its own private key. A host could reasonably use a different private keys
! 78: for different interfaces and for different peers. But it would not
! 79: be normal to share entries between systems. Thus thus no-selector and
! 80: one-selector forms of entry often make sense for public key authentication.
! 81: .LP
! 82: The key part of an entry must start with a token indicating the kind of
! 83: key. The following types of secrets are currently supported:
! 84: .TP
! 85: .B PSK
! 86: defines a pre-shared key
! 87: .TP
! 88: .B RSA
! 89: defines an RSA private key
! 90: .TP
! 91: .B ECDSA
! 92: defines an ECDSA private key
! 93: .TP
! 94: .B P12
! 95: defines a PKCS#12 container
! 96: .TP
! 97: .B EAP
! 98: defines EAP credentials
! 99: .TP
! 100: .B NTLM
! 101: defines NTLM credentials
! 102: .TP
! 103: .B XAUTH
! 104: defines XAUTH credentials
! 105: .TP
! 106: .B PIN
! 107: defines a smartcard PIN
! 108: .LP
! 109: Details on each type of secret are given below.
! 110: .LP
! 111: Whitespace at the end of a line is ignored. At the start of a line or
! 112: after whitespace, \fB#\fP and the following text up to the end of the
! 113: line is treated as a comment.
! 114: .LP
! 115: An include directive causes the contents of the named file to be processed
! 116: before continuing with the current file. The filename is subject to
! 117: ``globbing'' as in \fIsh\fP(1), so every file with a matching name
! 118: is processed. Includes may be nested to a modest
! 119: depth (10, currently). If the filename doesn't start with a \fB/\fP, the
! 120: directory containing the current file is prepended to the name. The
! 121: include directive is a line that starts with the word \fBinclude\fP,
! 122: followed by whitespace, followed by the filename (which must not contain
! 123: whitespace).
! 124: .SS TYPES OF SECRETS
! 125: .TP
! 126: .B [ <selectors> ] : PSK <secret>
! 127: A preshared \fIsecret\fP is most conveniently represented as a sequence of
! 128: characters, which is delimited by double-quote characters (\fB"\fP).
! 129: The sequence cannot contain newline or double-quote characters.
! 130: .br
! 131: Alternatively, preshared secrets can be represented as hexadecimal or Base64
! 132: encoded binary values. A character sequence beginning with
! 133: .B 0x
! 134: is interpreted as sequence of hexadecimal digits.
! 135: Similarly, a character sequence beginning with
! 136: .B 0s
! 137: is interpreted as Base64 encoded binary data.
! 138: .TP
! 139: .B : RSA <private key file> [ <passphrase> | %prompt ]
! 140: .TQ
! 141: .B : ECDSA <private key file> [ <passphrase> | %prompt ]
! 142: For the private key file both absolute paths or paths relative to
! 143: \fI/etc/ipsec.d/private\fP are accepted. If the private key file is
! 144: encrypted, the \fIpassphrase\fP must be defined. Instead of a passphrase
! 145: .B %prompt
! 146: can be used which then causes the daemon to ask the user for the password
! 147: whenever it is required to decrypt the key.
! 148: .TP
! 149: .B : P12 <PKCS#12 file> [ <passphrase> | %prompt ]
! 150: For the PKCS#12 file both absolute paths or paths relative to
! 151: \fI/etc/ipsec.d/private\fP are accepted. If the container is
! 152: encrypted, the \fIpassphrase\fP must be defined. Instead of a passphrase
! 153: .B %prompt
! 154: can be used which then causes the daemon to ask the user for the password
! 155: whenever it is required to decrypt the container. Private keys, client and CA
! 156: certificates are extracted from the container. To use such a client certificate
! 157: in a connection set leftid to one of the subjects of the certificate.
! 158: .TP
! 159: .B <user id> : EAP <secret>
! 160: The format of \fIsecret\fP is the same as that of \fBPSK\fP secrets.
! 161: .br
! 162: \fBEAP\fP secrets are IKEv2 only.
! 163: .TP
! 164: .B <user id> : NTLM <secret>
! 165: The format of \fIsecret\fP is the same as that of \fBPSK\fP secrets, but the
! 166: secret is stored as NTLM hash, which is MD4(UTF-16LE(secret)), instead of as
! 167: cleartext.
! 168: .br
! 169: \fBNTLM\fP secrets can only be used with the \fBeap-mschapv2\fP plugin.
! 170: .TP
! 171: .B [ <servername> ] <username> : XAUTH <password>
! 172: The format of \fIpassword\fP is the same as that of \fBPSK\fP secrets.
! 173: \fBXAUTH\fP secrets are IKEv1 only.
! 174: .TP
! 175: .B : PIN %smartcard[<slot nr>[@<module>]]:<keyid> <pin code> | %prompt
! 176: The smartcard selector always requires a keyid to uniquely select the correct
! 177: key. The slot number defines the slot on the token, the module name refers to
! 178: the module name defined in strongswan.conf(5).
! 179: Instead of specifying the pin code statically,
! 180: .B %prompt
! 181: can be specified, which causes the daemon to ask the user for the pin code.
! 182: .LP
! 183:
! 184: .SH FILES
! 185: /etc/ipsec.secrets
! 186: .SH SEE ALSO
! 187: ipsec.conf(5), strongswan.conf(5), ipsec(8)
! 188: .br
! 189: .SH HISTORY
! 190: Originally written for the FreeS/WAN project by D. Hugh Redelmeier.
! 191: Updated and extended for the strongSwan project <http://www.strongswan.org> by
! 192: Tobias Brunner and Andreas Steffen.
! 193: .SH BUGS
! 194: If an ID is \fB0.0.0.0\fP, it will match \fB%any\fP;
! 195: if it is \fB0::0\fP, it will match \fB%any6\fP.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to ipsec.secrets.5.in CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / strongswan / man