Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
IPSEC.SECRETS(5)		  strongSwan		      IPSEC.SECRETS(5)

NAME
       ipsec.secrets - secrets for IKE/IPsec authentication

DESCRIPTION
       The  file  ipsec.secrets	 holds	a table	of secrets.  These secrets are
       used by the  strongSwan	Internet  Key  Exchange	 (IKE)	daemons	 pluto
       (IKEv1) and charon (IKEv2) to authenticate other	hosts.

       It  is vital that these secrets be protected.  The file should be owned
       by the super-user, and its permissions  should  be  set	to  block  all
       access by others.

       The  file  is a sequence	of entries and include directives.  Here is an
       example.

	      #	/etc/ipsec.secrets - strongSwan	IPsec secrets file
	      192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"

	      :	RSA moonKey.pem

	      alice@strongswan.org : EAP "x3.dEhgN"

	      carol : XAUTH "4iChxLT3"

	      dave  : XAUTH "ryftzG4A"

	      #	get secrets from other files
	      include ipsec.*.secrets

       Each entry in the file is a list	of optional ID selectors, followed  by
       a  secret.   The	 two  parts  are separated by a	colon (:) that is sur-
       rounded by whitespace. If no ID selectors are specified the  line  must
       start with a colon.

       A  selector is an IP address, a Fully Qualified Domain Name, user@FQDN,
       %any or %any6 (other kinds may come).

       Matching	IDs with selectors is fairly straightforward: they have	to  be
       equal.  In the case of a	``Road Warrior'' connection, if	an equal match
       is not found for	the Peer's ID, and it is in the	form of	an IP address,
       a  selector  of %any will match the peer's IP address if	IPV4 and %any6
       will match a the	peer's IP address if IPV6.   Currently,	 the  obsolete
       notation	0.0.0.0	may be used in place of	%any.

       In  IKEv1 an additional complexity arises in the	case of	authentication
       by preshared secret: the	responder will need  to	 look  up  the	secret
       before  the  Peer's ID payload has been decoded,	so the ID used will be
       the IP address.

       To authenticate a connection between two	hosts,	the  entry  that  most
       specifically  matches  the host and peer	IDs is used.  An entry with no
       selectors will match any	host and peer.	More  specifically,  an	 entry
       with  one  selector  will match a host and peer if the selector matches
       the host's ID (the peer isn't considered).  Still more specifically, an
       entry with multiple selectors will match	a host and peer	if the host ID
       and peer	ID each	match one of the selectors.  If	 the  key  is  for  an
       asymmetric  authentication  technique (i.e. a public key	system such as
       RSA), an	entry with multiple selectors will match a host	and peer  even
       if  only	the host ID matches a selector (it is presumed that the	selec-
       tors are	all identities of the host).  It is acceptable for two entries
       to  be the best match as	long as	they agree about the secret or private
       key.

       Authentication by preshared secret requires that	both systems find  the
       identical  secret  (the	secret	is not actually	transmitted by the IKE
       protocol).  If both the host and	peer appear in the selector list,  the
       same  entry  will  be  suitable	for  both  systems so verbatim copying
       between systems can be used.  This naturally extends to	larger	groups
       sharing	the  same secret.  Thus	multiple-selector entries are best for
       PSK authentication.

       Authentication by public	key systems such as  RSA  requires  that  each
       host have its own private key.  A host could reasonably use a different
       private keys for	different interfaces and for different peers.  But  it
       would  not  be  normal to share entries between systems.	 Thus thus no-
       selector	and one-selector forms of entry	often make  sense  for	public
       key authentication.

       The key part of an entry	must start with	a token	indicating the kind of
       key.  The following types of secrets are	currently supported:

       PSK    defines a	pre-shared key

       RSA    defines an RSA private key

       ECDSA  defines an ECDSA private key

       P12    defines a	PKCS#12	container

       EAP    defines EAP credentials

       NTLM   defines NTLM credentials

       XAUTH  defines XAUTH credentials

       PIN    defines a	smartcard PIN

       Details on each type of secret are given	below.

       Whitespace at the end of	a line is ignored. At the start	of a  line  or
       after whitespace, # and the following text up to	the end	of the line is
       treated as a comment.

       An include directive causes the contents	of the named file to  be  pro-
       cessed  before  continuing with the current file.  The filename is sub-
       ject to ``globbing'' as in sh(1), so every file with a matching name is
       processed.   Includes  may be nested to a modest	depth (10, currently).
       If the filename doesn't start with a /, the  directory  containing  the
       current file is prepended to the	name.  The include directive is	a line
       that starts with	the word include, followed by whitespace, followed  by
       the filename (which must	not contain whitespace).

   TYPES OF SECRETS
       [ <selectors> ] : PSK <secret>
	      A	 preshared  secret  is	most  conveniently  represented	 as  a
	      sequence of characters, which is delimited by double-quote char-
	      acters (").  The sequence	cannot contain newline or double-quote
	      characters.
	      Alternatively, preshared secrets can be represented as hexadeci-
	      mal or Base64 encoded binary values. A character sequence	begin-
	      ning with	0x is interpreted as sequence of  hexadecimal  digits.
	      Similarly, a character sequence beginning	with 0s	is interpreted
	      as Base64	encoded	binary data.

       : RSA <private key file>	[ <passphrase> | %prompt ]
       : ECDSA <private	key file> [ <passphrase> | %prompt ]
	      For the private key file both absolute paths or  paths  relative
	      to /etc/ipsec.d/private are accepted. If the private key file is
	      encrypted,  the  passphrase  must	 be  defined.  Instead	of   a
	      passphrase  %prompt  can be used which then causes the daemon to
	      ask the user for the password whenever it	is required to decrypt
	      the key.

       : P12 <PKCS#12 file> [ <passphrase> | %prompt ]
	      For  the	PKCS#12	 file both absolute paths or paths relative to
	      /etc/ipsec.d/private  are	 accepted.   If	  the	container   is
	      encrypted,   the	passphrase  must  be  defined.	Instead	 of  a
	      passphrase %prompt can be	used which then	causes the  daemon  to
	      ask the user for the password whenever it	is required to decrypt
	      the container. Private keys,  client  and	 CA  certificates  are
	      extracted	 from  the container. To use such a client certificate
	      in a connection set leftid to one	of the subjects	 of  the  cer-
	      tificate.

       <user id> : EAP <secret>
	      The format of secret is the same as that of PSK secrets.
	      EAP secrets are IKEv2 only.

       <user id> : NTLM	<secret>
	      The format of secret is the same as that of PSK secrets, but the
	      secret is	stored as NTLM hash, which  is	MD4(UTF-16LE(secret)),
	      instead of as cleartext.
	      NTLM secrets can only be used with the eap-mschapv2 plugin.

       [ <servername> ]	<username> : XAUTH <password>
	      The  format  of  password	 is  the  same as that of PSK secrets.
	      XAUTH secrets are	IKEv1 only.

       : PIN %smartcard[<slot nr>[@<module>]]:<keyid> <pin code> | %prompt
	      The smartcard selector  always  requires	a  keyid  to  uniquely
	      select  the correct key. The slot	number defines the slot	on the
	      token, the module	name refers to	the  module  name  defined  in
	      strongswan.conf(5).   Instead  of	specifying the pin code	stati-
	      cally, %prompt can be specified, which causes the	daemon to  ask
	      the user for the pin code.

FILES
       /etc/ipsec.secrets

SEE ALSO
       ipsec.conf(5), strongswan.conf(5), ipsec(8)

HISTORY
       Originally  written  for	 the  FreeS/WAN	project	by D. Hugh Redelmeier.
       Updated	   and	   extended	for	the	strongSwan     project
       <http://www.strongswan.org> by Tobias Brunner and Andreas Steffen.

BUGS
       If  an  ID is 0.0.0.0, it will match %any; if it	is 0::0, it will match
       %any6.

5.5.2				  2011-12-14		      IPSEC.SECRETS(5)

NAME | DESCRIPTION | FILES | SEE ALSO | HISTORY | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=ipsec.secrets&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help