|
with a pfs=no statement in ipsec.conf(5).
Several types of notification message may be sent by either side during either phase, or later. FreeS/WAN does not currently support these, but they are a likely addition in future releases.
A new group exchange may take place after phase one but before phase two, defining up an additional group for use in the Diffie-Hellman key agreement part of phase two. FreeS/WAN does not currently support this.
There is a commit flag which may optionally be set on some messages. The errata page for the RFCs includes two changes related to this, one to clarify the description of its use and one to block a denial of service attack which uses it. We currently do not implement this feature.
These complications can of course lead to problems, particularly when two different implementations attempt to interoperate. For example, we have seen problems such as:
Some implememtations (often products crippled by export laws) have the insecure DES algorithm as their only supported encryption method. See our DES insecurity comments for the reasons we do not implement single DES, and our FAQ for a discussion of how to cope with crippled products.
Windows 2000 IPSEC tries to negotiate with FreeS/WAN using Aggressive Mode, which we don''''t support. Later on, it uses the commit bit, which we also don''''t support.
FreeS/WAN''''s interaction with PGPnet is complicated by their use of notification messages we do not yet support.
Despite this, we do interoperate successfully with many implementations, including both Windows 2000 and PGPnet. Details are in our interoperability document.
2.Structure of IKE messages
Here is our Pluto developer explaining some of this on the mailing list:
When one IKE system (for example, Pluto) is negotiating with another
to create an SA, the Initiator proposes a bunch of choices and the
Responder replies with one that it has selected.
The structure of the choices is fairly complicated. An SA payload
contains a list of lists of "Proposals". The outer list is a set of
choices: the selection must be from one element of this list.
Each of these elements is a list of Proposals. A selection must be
made from each of the elements of the inner list. In other words,
*all* of them apply (that is how, for example, both AH and ESP can
apply at once).
Within each of these Proposals is a list of Transforms. For each
Proposal selected, one Transform must be selected (in other words,
each Proposal provides a choice of Transforms).
Each Transform is made up of a list of Attributes describing, well,
attributes. Such as lifetime of the SA. Such as algorithm to be
used. All the Attributes apply to a Transform.
You will have noticed a pattern here: layers alternate between being
disjunctions ("or") and conjunctions ("and").
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
cut back. There must be exactly one Proposal. So this degenerates to
a list of Transforms, one of which must be chosen.
IPSEC Services, AH and ESP
IPSEC offers two services, authentication and encryption . These can be used separately but are often used together.
Authentication
Packet-level authentication allows you to be confident that a packet came from a particular machine and that its contents were not altered en route to you. No attempt is made to conceal or protect the contents, only to assure their integrity.
Packet authentication can be provided separately using an Authentication Header, described just below, or it can be included as part of the ESP (Encapsulated Security Payload) service, described in the following section. That service offers encryption as well as authentication.
Encryption
Encryption allows you to conceal the contents of a message from eavesdroppers.
In IPSEC this is done using a block cipher (normally Triple DES for Linux). In the most used setup, keys are automatically negotiated, and periodically re-negotiated, using the IKE (Internet Key Exchange) protocol. In Linux FreeS/WAN this is handled by the Pluto Daemon.
The IPSEC protocol offering encryption is ESP, Encapsulated Security Payload. It can also include a packet authentication service.
Note that encryption should always be used with some packet authentication service. Unauthenticated encryption is vulnerable to man-in-the-middle attacks . Also note that encryption does not necessarily prevent traffic analysis.
The Authentication Header (AH)
Packet authentication can be provided separately from encryption by adding an authentication header (AH) after the IP header but before the other headers on the packet. This is the subject of this section. Details are in RFC 2402.
Each of the several headers on a packet header contains a "next protocol" field telling the system what header to look for next. IP headers generally have either TCP or UDP in this field. When IPSEC authentication is used, the packet IP header has AH in this field, saying that an Authentication Header comes next. The AH header then has the next header type -- usually TCP, UDP or encapsulated IP.
IPSEC packet authentication can be added in transport mode, as a modification of standard IP transport. This is shown in this diagram from the RFC: BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
||
except for mutable fields
Athentication can also be used in tunnel mode, encapsulating the underlying IP packet beneath AH and an additional IP header. ||
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
||
| in the new IP hdr |
This would normally be used in a gateway-to-gateway tunnel. The receiving gateway then strips the outer IP header and the AH header and forwards the inner IP packet.
The mutable fields referred to are things like the time-to-live field in the IP header. These cannot be included in authentication calculations because they change as the packet travels.
Keyed MD5 and Keyed SHA
The actual authentication data in the header is typically 96 bits and depends both on a secret shared between sender and receiver and on every byte of the data being authenticated.
The algorithms involved are the MD5 Message Digest Algorithm or SHA, the Secure Hash Algorithm. For details on their use in this application, see RFCs 2403 and 2404 respectively.
For descriptions of the algorithms themselves, see RFC 1321 for MD5 and FIPS (Federal Information Processing Standard) number 186 from NIST , the US National Institute of Standards and Technology for SHA. Applied Cryptography covers both in some detail, MD5 starting on page 436 and SHA on 442.
These algorithms are intended to make it nearly impossible for anyone to alter the authenticated data in transit. The sender calculates a digest or hash value from that data and includes the result in the authentication header. The recipient does the same calculation and compares results. For unchanged data, the results will be identical. The hash algorithms are designed to make it extremely difficult to change the data in any way and still get the correct hash.
Since the shared secret key is also used in both calculations, an interceptor cannot simply alter the authenticated data and change the hash value to match. Without the key, he or she (or even the dreaded They) cannot produce a usable hash.
+Sequence numbers
The authentication header includes a sequence number field which the sender is required to increment for each packet. The receiver can ignore it or use it to check that packets are indeed arriving in the expected sequence.
This provides partial protection against replay attacks in which an attacker resends intercepted packets in an effort to confuse or subvert the receiver. Complete protection is not possible since it is necessary to handle legitmate packets which are lost, duplicated, or delivered out of order, but use of sequence numbers makes the attack much more difficult.
The RFCs require that sequence numbers never cycle, that a new key always be negotiated before the sequence number reaches 2^32-1. This protects both against replays attacks using packets from a previous cyclce and against birthday attacks on the the packet authentication algorithm.
In Linux FreeS/WAN, the sequence number is ignored for manually keyed connections and checked for automatically keyed ones. In automatic mode, we do that. In manual mode, there is no way to negotiate a new key, or to recover from a sequence number problem, so we don''''t use sequence numbers.
Encapsulated Security Payload (ESP)
The ESP protocol is defined in RFC 2406. It provides one or both of encryption and packet authentication. It may be used with or without AH packet authentication.
Note that some form of packet authentication should always be used whenever data is encrypted. Without authentication, the encryption is vulnerable to active attacks which may allow an enemy to break the encryption. ESP should always either include its own authentication or be used with AH authentication.
The RFCs require support for only two mandatory encryp
上一页 [1] [2] [3] [4] [5] 下一页
[C语言系列]C# 和 Linux 时间戳转换 [Web开发]PHP flock文件锁介绍
[Web开发]flock() Linux下的文件锁 [电脑应用]Linux下的六个免费的虚拟主机管理系统介绍
[电脑应用]Linux数据库大比拚 [操作系统]在Windows中玩转Linux操作系统
[办公软件]批量删除Office文档(word,excle,powerpoint)中的超… [办公软件]如何删除PowerPoint幻灯片中的页脚信息
[办公软件]如何旋转插入到PowerPoint中的图形图片对象 [办公软件]提取PPT文件中的GIF动画(也可提取各种素材对象)
|
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
