FireBrick FB6402, Руководство пользователя

Страница: 83 / 196

Tunnels
66
IPsec provides two ways to encapsulate data - AH (Authentication Header) which integrity checks the packet
data and also some of the header fields (IP addresses), and ESP (Encapsulation Security Payload) - which both
encrypts and integrity checks the packet data.
11.1.1.3. Authentication
Authenticaion is a mechanism for ensuring that the two end users of a communication channel trust that they
are who they think they are. Neither encryption nor integrity checking alone can do this. To ensure that you are
talking to the correct person and not someone else masquerading as them, and to be sure nobody else can read
your communications, you need to be sure that keys used for integrity checking and encryption are only known
to the two (real) endpoints. Authentication can help prevent a "Man-in-the-Middle" attack, where someone who
knows the keys can set himself up between the two endpoints, and without their knowledge can masquerade
as the other endpoint to each end. Note that a Man in the Middle can both read the data and modify it, without
either of the endpoints being aware that this has happened.
Note
There is scope for confusion in the use of the term Authentication. It is sometimes also used to
mean integrity checking, and indeed the "Authentication Header" (AH) should really be known as the
Integrity Check Header!
11.1.1.4. IKE
Choosing and configuring the IPsec algorithms and keys, as well as any other required connection parameters
for a link is a complex task and also has its own security implications as compatible parameters, including
the keys, need to be established at both ends of the link while at the same time ensuring the keys remain
accessible only to the two ends. If you use any form of communication to do this and that communication
channel is not itself secure, you have potentially lost your link security. For this reason there is a protocol
known as IKE (Internet Key Exchange) which automatically negotiates and selects algorithms, keys and other
parameters, and installs them at each end of the link, using a secure channel between the two systems. The
FireBrick supports version 2 of the IKE protocol (IKEv2). IKE uses Public Key Cryptographic mechanisms to
select the keys to be used, using the Diffie-Hellman key exchange mechanism. IKE also performs authentication
between the two link endpoints using for example X.509 certificates, pre-shared secrets or other methods
such as those supported by EAP (Extensible Authentication Protocol). It is still necessary to install suitable
certificates, secrets or methods, obviously, but the configuration is simpler and more secure.
An IPsec IKE connection is established in two logical stages; first a secure control channel for the IKE
negotiation is set up, and the peers authenticate each other using this channel, and then algorithms and keys to
be used to secure the IPsec data are negotiated and exchanged using the secure channel. The control channel
remains open during the lifetime of the connection, and is used to test the connection status, to cleanly close the
link down, and also to periodically regenerate the algorithm key data (which mitigates the possibility that a third
party has managed to crack the keys currently in use). During the first stage, the peers agree on algorithms to
be used for integrity checking and encrypting the control channel, and additionally on algorithms to be used to
securely generate the required keying data. These are agreed by the originating peer making a proposal, referred
to below as the IKE proposal and the responding peer then selects the best algorithms which it supports. A
similar, separate, proposal (referred to below as the IPsec proposal) is used to select the algorithms to be used
for the IPsec data channel.
11.1.1.5. Manual Keying
IPsec can also be used in what is known as manual-keying mode. When used in this way, IKE is not used;
system administrators at each end of the link need to choose and agree on the integrity and encryption keys to be
used, using some private mechanism which they know to be secure, before the IPsec connection is configured.
For example, the system administrators may already know each other, and may arrange to meet in private
and exchange keying information (which they trust they will not divulge to anyone else), and then configure
their FireBricks to use the agreed keys. This is not a recommended approach as it it relies on the system
administrators choosing good (ie random and unguessable) keys and keeping them secure. It also provides no
way to automatically regenerate the keys regularly.