ࡱ> jaKLqRoot Entry Fໄc @1Tabler9WordDocumentSummaryInformation( pzO  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Text CJOJQJ$/$List h*B* Body Textx<C"<Body Text Indent hx222 Normal Indent(U@A( Hyperlink>*B*!!!!!          N >&A4AkO^lm |2Root Entry F?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ont4Z@4 Plain Text CJOJQJ$/$List h*B* Body Textx<C"<Body Text Indent hx222 Normal Indent(U@A( Hyperlink>*B*K!!!!!          x<C"<Body Text Indent hx222 Normal Indent(U@A( Hyperlink>*B*!!!!!          N >&A4AkO^lm |2O4!Mnh  tN >&A4AkO^dm|*G-NKh  t   [.-.G[op%d[\ ; < M N D)E) *!*,,----//00U3V3555557778::Z?[?@@@@4B5BJBKBCCCCCFFJJ;P.txt}. As \cite{RFC2401} states: ``The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture.'' This evaluation only deals with the IPsec and ISAKMP specifications and is not directly concerned with any of the other factors. However, we do comment on aspects of the specifications that affect other security factors. IPsec and ISAKMP are highly complex systems. Unfortunately, we cannot give a sufficiently detailed description of these systems in this document to allow the reader to understand our comments without being familiar with IPsec and ISAKMP. Our comments frequently refer to specific places in the RFC documents for ease of reference. The rest of this report is structured as follows. Chapter~\ref{chap:general} gives some general comments. Chapter~\ref{chap:bulk} discusses the IPsec protocols that handle bulk data. Chapter~\ref{chap:ISAKMP} discusses the ISAKMP generic definitions. Chapter~\ref{chap:IPsecDOI} talks about the IPsec Domain of Interpretation which gives more details on how the generic ISAKMP structure applies to the IPsec protocols. Finally, chapter~\ref{chap:IKE} discusses the IKE protocol that is the default key management protocol used with ISAKMP. \chapter{General comments}\label{chap:general} \section{Complexity} Complexity is the biggest enemy of security. This might seem an odd statement in the light of the many fielded systems that exhibit critical security failures for very simple reasons. It is true nonetheless. The simple failures are simple to avoid, and often simple to fix. The problem is not that we do not know how to solve them; it is that this knowledge is often not applied. Complexity, however, is a different beast because we do not really know how to handle it. Designing any software system is always a matter of weighing various requirements. These include functionality, efficiency, political acceptability, security, backward compatibility, deadlines, flexibility, ease of use, and many more. The unspoken requirement is often the complexity. If the system gets too complex, it becomes too difficult, and therefore too expensive, to make. As fulfilling more of the requirements usually involves a more complex design, many systems end up with a design that is as complex as the designers and implementors can reasonably handle. Virtually all software is developed using a try-and-fix methodology. Small pieces are implemented, tested, fixed, and tested again.\footnote{Usually several iterations are required.} Several of these small pieces are combined into a larger module, and this module is tested, fixed, and tested again. The end result is software that more or less functions as expected, although we are all familiar with the high frequency of functional failures of software systems. This process of making fairly complex systems and implementing them with a try-and-fix methodology has a devastating effect on the security. The central reason is that you cannot test for security. Therefore, security bugs are not detected during the development process in the same way that functional bugs are. Suppose a reasonably sized program is developed without any testing at all during development and quality control. We feel confident in stating that the result will be a completely useless program; most likely it will not perform any of the desired functions correctly. Yet this is exactly what we get from the try-and-fix methodology when we look at security. The only reasonable way to ``test'' the security of a security product is to perform security reviews on it.\footnote{A cracking contest can be seen as a cheap way of getting other people to do a security analysis. The big problem is interpreting the results. If the prize is not claimed, it does not imply that any competent analysis was done and came up empty.} A security review is a manual process; it is relatively expensive in terms of time and effort and it will never be able to show that the product is in fact secure. [this seems to ignore the approaches usually employed for high assurance system design and implementation , i.e., careful design and review coupled with rigid development procedures, all prior to testing.] The more complex the system is, the harder a security evaluation becomes. A more complex system will have more security-related errors in the specification, design, and implementation. We claim that the number of errors and difficulty of the evaluation are not linear functions of the complexity, but in fact grow much faster. For the sake of simplicity, let us assume the system has $n$ different options, each with two possible choices.\footnote{We use $n$ as the measure of the complexity. This seems reasonable, as the length of the system specification and the implementation is proportional to $n$.} Then there are $n(n-1)/2 = O(n^2)$ different pairs of options that could interact in unexpected ways, and $2^n$ different configurations altogether. Each possible interaction can lead to a security weakness, and the number of possible complex interactions that involve several options is huge. As each interaction can produce a security weakness, we expect that the number of actual security weaknesses grows very rapidly with increasing complexity. The same holds for the security evaluation. For a system with a moderate number of options, checking all the interactions becomes a huge amount of work. Checking every possible configuration is effectively impossible. Thus the difficulty of performing security evaluations also grows very rapidly with increasing complexity. The combination of additional (potential) weaknesses and a more difficult security analysis unavoidably results in insecure systems. In actual systems, the situation is not quite so bad; there are often options that are ``orthogonal'' in that they have no relation or interaction with each other. This occurs, for example, if the options are on different layers in the communication system, and the layers are separated by a well-defined interface that does not ``show'' the options on either side. For this very reason, such a separation of a system into relatively independent modules with clearly defined interfaces is a hallmark of good design. Good modularization can dramatically reduce the ``effective'' complexity of a system without the need to eliminate important features. Options within a single module can of course still have interactions that need to be analyzed, so the number of options per module should be minimized. Modularization works well when used properly, but most actual systems still include cross-dependencies where options in different modules do affect each other. A more complex system loses on all fronts. It contains more weaknesses to start with, it is much harder to analyze, and it is much harder to implement without introducing security-critical errors in the implementation. Complexity not only makes it virtually impossible to create a secure implementation, it also makes the system extremely hard to manage. The people running the actual system typically do not have a thorough understanding of the security issues involved. Configuration options should therefore be kept to a minimum, and the options should provide a very simple model to the user. Complex combinations of options are very likely to be configured erroneously, which results in a loss of security. The stories in \cite{TheCodebreakers} and \cite{A:WhyFail} illustrate how management of complex systems is often the weakest link. Both IPsec and ISAKMP are too complex to be secure. The design obviously tries to support many different situations with different options. We feel very strongly that the resulting system is well beyond the level of complexity that can be implemented securely with current methodologies. \section{Stating what is achieved} A security analysis evaluates the security aspects of a system. To be able to give any sensible answer, it should be clear what properties the system claims to have. That is, the system documentation should clearly state what security properties are achieved. This can be seen as the functional specification of the security properties. This applies not only to the entire system, but also to the individual modules. At each module or function, the security properties should be specified. A good comparison is the testing of a product. The testing verifies that the product performs according to the functional specifications. Without specifications, the testers might have some interesting comments, but they can never give a real answer. Without security specifications, the first task of the security analysis is to create descriptions of the security properties achieved, based on the perceived intentions of the system designer. The subsequent evaluation might then turn up problems of the form ``this function does not achieve the properties that we think it should have.'' The obvious answer will be: ``but that is not the properties that I designed it to have.'' Very quickly the discussion moves away from the actual security into what was meant. The overall result is a security evaluation that might point out some potential weaknesses, but that will hardly help in improving the security. The IPsec and ISAKMP protocols do not specify clearly which security properties they claim to achieve. [RFCs 2401, 2402, and 2406 clearly state the security services offered by the AH and ESP protocols.] The same holds for the modules and functions. [modules are not specified by these standards; they are implementation artifacts.] We recommend that each function, module, and protocol be extended to include clear specifications regarding the security-related functionality they achieve. We feel that unless this is done, it will not be possible to perform an adequate security evaluation on a system of this complexity. \chapter{Bulk data handling}\label{chap:bulk} In this chapter we discuss the methods used to handle the encryption and authentication of the bulk data, as specified in \cite{RFC2401,RFC2402,RFC2403,RFC2404,RFC2405,RFC2406,RFC2451,RFC2410,RFC2411}. Together these documents specify the IPsec protocol. They specify the actual encryption and authentication of packets, assuming that symmetric keys have already been exchanged. We refer the reader to \cite{RFC2401} sections 1--4.2 for an overview of this part of IPsec and the relevant terminology. \section{Functionality} IPsec is capable of providing authentication and confidentiality services on a packet level. The security configuration of an IPsec implementation is done centrally, presumably by the system administrator. [In some environments, a single administrator might control the configuration of each IPsec implementation, or each user might have some control over it. The latter would tend to be characterized as a distributed management paradigm, not a central one. Also, two IPsec peers communicate ONLY if both agree on the security parameters for the SA, i.e., there is suitable overlap in the SPDs. In that sense too, security configuration is distributed.] IPsec is very suitable for creating a VPN over the Internet, improved security for dial-in connections to portables, restricting access to parts of a network, etc. These are very much network-level functions. IPsec by itself does not supply application-level security. Authentication links the packet to the security gateway of the originating network, the originating host, or possibly the originating user, but not to the application in question or the data the application was handling when it sent the packet. [true, but for many applications, application layer security is not needed, and its implementation might well be accorded less assurance than the network layer security provided by IPsec. This paragraph seems to suggest that there is some important benefit to linking data to an application, through an application-specific security mechanism. There are good examples of where this is true, e.g., e-mail and directories. However, unless there are application-specific security semantics that cannot be captured by use of an application security protocol, your own arguments about simplicity, as well as a number of arguments re assurance, argue against proliferation of application security protocols.] The IPsec functionality can significantly increase the security of the network. It is not a panacea for all security problems, and applications that require security services will typically have to use other security systems in addition to IPsec. [I might disagree with the term typically here. A lot depends on the application, where IPsec is implemented, etc.] \section{Complexity}\label{sec:complexity} Our biggest criticism is that IPsec is too complex. There are too many options that achieve the same or similar properties. [if they were completely equivalent this would be a good basis for simplifying IPsec. However, there are subtle differences that have resulted in the proliferation of options you address below.] \subsection{Options} IPsec suffers from an abundance of options. For example, two hosts that want to authenticate IP packets can use four different modes: transport/AH, tunnel/AH, transport/ESP with NULL encryption, and tunnel/ESP with NULL encryption. The differences between these options, both in functionality and performance, are minor. In particular, the following options seem to create a great deal of needless complexity: \begin{enumerate} \item There are two modes that can be used: transport mode and tunnel mode. In transport mode, the IP header of the packet is left untouched. AH authenticates both the IP header and the packet payload. ESP encrypts and authenticates the payload, but not the header. The lack of header authentication in transport/ESP is a real weakness, as it allows various manipulations to be performed. In tunnel mode, the full original IP packet (including headers) is used as the payload in a new IP packet with new headers. The same AH or ESP functions are used. As the original header is now included in the ESP authentication, the transport/ESP authentication weakness no longer exists. Transport mode provides a subset of the functionality of tunnel mode. The only advantage that we can see to transport mode is that it uses a somewhat smaller bandwidth. However, the tunnel mode could be extended in a straightforward way with a specialized header-compression scheme that we will explain shortly. This would achieve virtually the same performance as transport mode without introducing an entirely new mode. We therefore recommend that the transport mode be eliminated. [transport mode and tunnel mode address fundamentally different requirements, from a networking point of view. When security gateways are involved, the use of tunnel mode is an absolute requirement, whereas it is a minor (and rarely used) feature for communications between end systems. A proposal to make all traffic tunnel mode, and to try to offset the added overhead through compression, seems to ignore the IPCOMP facility that is already available to IPsec implementations.] \item There are two protocols: AH and ESP. AH provides authentication, and ESP provides encryption, authentication, or both. In transport mode, AH provides a stronger authentication than ESP can provide, as it also authenticates the IP header. One of the standard modes of operation would seem to be to use both AH and ESP in transport mode. [although this mode is required to be supported, it seems to be rarely used. Perhaps the best use case for this arises if there are options to be protected in the IP header that might be verified en route (using symmetric keys available to both the endpoints and the intermediate systems) while the ESP integrity/authenticity keys are available only to the end points.] In tunnel mode, the authentication that ESP provides is good enough (it includes the IP header), and AH is typically not combined with ESP \cite[section 4.5]{RFC2401}. [the example above shows why one might wish to use AH for the outer header, but most likely with ESP in transport mode.] (Implementations are not required to support nested tunnels that would allow ESP and AH to both be used.) The AH protocol \cite{RFC2402} authenticates the IP headers of the lower layers. [AH authenticates the IP header at the SAME layer, in many respects. AH was originally described as an IP (v4) option. In IPv6, AH is viewed as part of the AH header, and may appear before other header extensions (see section 4.1 of RFC 2401). I agree that AH represents ugly layering, but its not as bad as you suggest here.] This creates all kind of problems, as some header fields change in transit. As a result, the AH protocol needs to be aware of all data formats used at lower layers so that these mutable fields can be avoided. [this is an inaccurate characterization, especially given the status of AH re IPv6. Dont think of AH as a transport protocol. It isnt.] This is a very ugly construction, and one that will create more problems when future extensions to the IP protocol are made that create new fields that the AH protocol is not aware of. [RFC 2402 explains how to deal with new IP header fields in v6 (see section 3.3.3.1.2.2). The existence of a mutability flag in such extensions makes processing relatively straightforward.] Also, as some header fields are not authenticated, the receiving application still cannot rely on the entire packet. To fully understand the authentication provided by AH, an application needs to take into account the same complex IP header parsing rules that AH uses. The complex definition of the functionality that AH provides can easily lead to security-relevant errors. The tunnel/ESP authentication avoids this problem, but uses more bandwidth. [but it does not provide exactly the same features, as noted above, so the alternative is not quite equivalent.] The extra bandwidth requirement can be reduced by a simple specialized compression scheme: for some suitably chosen set of IP header fields $X$, a single bit in the ESP header indicates whether the $X$ fields in the inner IP header are identical to the corresponding fields in the outer header.\footnote{A trivial generalization is to have several flag bits, each controlling a set of IP header fields.} The fields in question are then removed to reduce the payload size. This compression should be applied after computing the authentication but before any encryption. The authentication is thus still computed on the entire original packet. The receiver reconstitutes the original packet using the outer header fields, and verifies the authentication. A suitable choice of the set of header fields $X$ allows tunnel/ESP to achieve virtually the same low message expansion as transport/AH. We conclude that eliminating transport mode allows the elimination of the AH protocol as well, without loss of functionality. [counter examples provided above suggest that this claim is a bit overstated.] \item The standard defines two categories of machines: hosts and security gateways. Hosts can use transport mode, but security gateways must always use tunnel mode. Eliminating transport mode would also allow this distinction to be eliminated. Various computers could of course still function as hosts or security gateways, but these different uses would no longer affect the protocol. \item The ESP protocol allows the payload to be encrypted without being authenticated. In virtually all cases, encryption without authentication is not useful. The only situation in which it makes sense not to use authentication in the ESP protocol is when the authentication is provided by a subsequent application of the AH protocol (as is done in transport mode because ESP authentication in transport mode is not strong enough). [this is one example of when one might not need authentication with ESP, but it is not the only one. In general, if there is a higher layer integrity and/or authentication function in place, providing integrity/authentication in IPsec is redundant, both in terms of space and processing. The authentication field for ESP or AH is 12 bytes. For applications where packet sizes are quite small, and for some environments where packet size is of critical importance, e.g., packet voice in a wireless environment, ESP w/o authentication may be appropriate. This is especially true if the application protocol embodies an authentication mechanism. This might happen if the application protocol wants to offer uniform protection irrespective of the lower layers. Admittedly, this might also cause the application to offer confidentiality as well, but depending on the application, the choices of what security services are being offered may vary.] Without the transport mode to worry about, ESP should always provide its own authentication. We recommend that ESP authentication always be used, and only encryption be made optional. [the question of authentication as an intrinsic part of ESP is independent of mode, i.e., whether one choose to provide authentication as a part of ESP is not determined by the choice of transport vs. tunnel mode.] \end{enumerate} We can thus remove three of the four operational modes without any significant loss of functionality. [sorry, cant agree, given the counter examples above.] \subsection{Undesirable options} There are existing combinations of options that are undesirable. These pose a problem when non-experts have to configure an IPsec installation. Given the fact that experts are rare and usually have better things to do, most IPsec installations will be configured by non-experts. [yes, we were aware of this concern. However, there is always a tradeoff between adopting the we know whats best for you approach, vs. the you can screw it up if you want to approach. We opted for a point somewhere along this spectrum, but not at either end.] \begin{enumerate} \item In transport mode, use of ESP provides authentication of the payload only. The authentication excludes the IP headers of the packet. The result is a data stream that is advertised as ``authenticated'' for which critical pieces of information (such as the source and destination IP number) are not authenticated. Unless the system administrator is intimately familiar with the different forms of authentication used by IPsec, it is quite likely that the administrator will assume that the authentication protects the entire packet. The combination of transport mode and the ESP protocol (without the AH protocol) should therefore not be allowed. [The IP source and destination address are covered by the TCP checksum, which is covered by the ESP integrity check, so this does limit (a tiny bit) the ability to change these values without detection. A more significant observation is that transport mode IPsec SAs will probably always use source and/or destination IP addresses as part of the selector set. In such cases, tampering with the either address will result in failed authentication.] \item The standard allows ESP to be used with the NULL encryption, such that it provides only authentication. The authentication provided by ESP in transport mode is less functional than the authentication provided by AH, at a similar cost. If transport mode is retained, either the EPS ESP authentication should be extended or the use of ESP with only authentication should be forbidden and replaced by the use of AH. [ESP authentication is more efficient to compute than AH, because of the selective IP header coverage provided by AH. Thus there is good reason to allow authentication-only ESP as an alternative to AH. This point was debated by the group and, with implementation experience, vendors came to agree that this is true.] \item The ESP protocol can provide encryption without authentication. This does not make much sense in an application. It protects the application against passive eavesdroppers, but provides no protection against active attacks that are often far more devastating. Again, this mode can lure non-expert users into using an unsafe configuration that they think is secure. Encryption without authentication should be forbidden. [as noted above, there are examples where this feature set for ESP is attractive.] \end{enumerate} \subsection{Orthogonality} IPsec also suffers from a lack of orthogonality. The AH and ESP protocols can be used together, but should only be used in one particular order. In transport mode, ESP by itself provides only partial authentication of the IP packet, and using AH too is advisable. [not in most cases, as noted above.] In tunnel mode the ESP protocol authenticates the inner headers, so use of AH is no longer required. These interdependencies between the choices demonstrate that these options are not independent of each other. [true, but who says that this is a critical criteria? TCP and IP are not orthogonal either, e.g., note the TCP checksum covering parts of the IP header.] \subsection{Compatibility} The IPsec protocols are also hampered by the compatibility requirements. A simple problem is the TOS field in the IP header \cite[p.\ 10]{RFC2402}. Although this is supposed to be unchanged during the transmission of a packet (according to the IP specifications), some routers are known to change this field. IPsec chose to exclude the TOS field from the authentication provided by the AH protocol to avoid errors introduced by such rogue routers. The result is that, in transport/AH packets that have an authenticated header, the TOS field is not authenticated. This is clearly unexpected from the application point of view, which might want to rely on the correct value of the TOS field. This problem does not occur in tunnel mode. [it is unfortunate that cisco chose to not follow the specs here, and in several other places. I agree that an unenlightened system administrator might be surprised in this case. But, in practice, the effect is minimal. Your example cites transport mode, which means that the TOS bits are being acted upon by the end system. If end systems really paid attention to these bits in the first place, cisco would not have been able to corrupt them with impunity! The reason that these bits are being re-used by the ECN folks is because hosts have never made use of them. Still, going forward, one should pay attention to this vulnerability.] A more complex compatibility problem is the interaction between fragmentation and IPsec \cite[appendix B]{RFC2401}. This is a complex area, but a typical IPsec implementation has to perform specialized processing to facilitate the proper behavior of higher-level protocols in relation to fragmentation. Strictly speaking, fragmentation is part of the communication layer below the IPsec layer, and in an ideal world it would be transparent to IPsec. Compatibility requirements with existing protocols (such as TCP) force IPsec to explicitly handle fragmentation issues, which adds significantly to the overall complexity. Unfortunately, there does not seem to be an elegant solution to this problem. [The requirement here is the same that arises whenever an intermediate system adds info to a packet, or when a smaller MTU intermediate system is traversed. IPsec in an SG is doing what a router along a path would do if the other side network were smaller. IPsec in a host is doing what the NIC would do if the LAN MTU changed. The real complexity arises when we wish to do this optimally, at a security gateway or a BITS or BITW implementation, in cases where different SAs use different combinations of AH and ESP, or different algorithms, etc.] \subsection{Conclusion} The overall result is that IPsec bulk data handing is overly complex. In our opinion it is possible to define an equivalent system that is far less complex. \section{Order of operations} \subsection{Introduction} When both encryption and authentication are provided, IPsec performs the encryption first, and authenticates the ciphertext. In our opinion, this is the wrong order. Going by the ``Horton principle'' \cite{WS:SSL30}, the protocol should authenticate what was meant, not what was said. The ``meaning'' of the ciphertext still depends on the decryption key used. Authentication should thus be applied to the plaintext (as it is in SSL \cite{SSLv3Nov96}), and not to the ciphertext.[The order of processing is intentional. It is explicitly designed to allow a receiver to discard a packet as quickly as possible, in the event of DoS attacks, as you acknowledge below. The suggestion that this concern be addressed by the addition of a secondary MAC seems to violate the spirit of simplicity that this document espouses so strongly, and the specific proposed fix is not strong enough to warrant its incorporation. Moreover, this ordering allows parallel processing at a receiver, as a means of increasing throughput and reducing delay.] This does not always lead to a direct security problem. In the case of the ESP protocol, the encryption key and authentication key are part of a single ESP key in the SA. A successful authentication shows that the packet was sent by someone who knew the authentication key. The recipient trusts the sender to encrypt that packet with the other half of the ESP key, so that the decrypted data is in fact the same as the original data that was sent. The exact argument why this is secure gets to be very complicated, and requires special assumptions about the key agreement protocol. For example, suppose an attacker can manipulate the key agreement protocol used to set up the SA in such a way that the two parties get an agreement on the authentication key but a disagreement on the encryption key. When this is done, the data transmitted will be authenticated successfully, but decryption takes place with a different key than encryption, and all the plaintext data is still garbled. [The fundamental assumption is that an ESP SA that employs both encryption and an HMAC will have the keys bound together, irrespective of the means by which they are generated. This assumption probably could be better stated in the RFCs.] In other situations, the wrong order does lead to direct security weaknesses. \subsection{An attack on IPsec} Suppose two hosts have a manually keyed transport-mode AH-protocol SA, which we will call SAah. Due to the manual keying, the AH protocol does not provide any replay protection. These two hosts now negotiate a transport-mode encryption-only ESP SA (which we will call SAesp1) and use this to send information using both SAesp1 and SAah. The application can expect to get confidentiality and authentication on this channel, but no replay protection. When the immediate interaction is finished, SAesp1 is deleted. A few hours later, the two hosts again negotiate a transport-mode encryption-only ESP SA (SAesp2), and the receiver chooses the same SPI value for SAesp2 as was used for SAesp1. Again, data is transmitted using both SAesp2 and SAah. The attacker now introduces one of the packets from the first exchange. This packet was encrypted using SAesp1 and authenticated using SAah. The receiver checks the authentication and finds it valid. (As replay protection is not enabled, the sequence number field is ignored.) The receiver then proceeds to decrypt the packet using SAesp2, which presumably has a different decryption key then SAesp1. The end result is that the receiver accepts the packet as valid, decrypts it with the wrong key, and presents the garbled data to the application. Clearly, the authentication property has been violated. [this attack is not a criticism of the choice of ESP operation ordering, but rather the notion of applying AH and ESP (encryption only) in a particular order, as allowed by RFC 2401. The specific combination of keying operations described here, though not prohibited by 2401, does not seem likely to occur in practice. Specifically, if an IPsec implementation supports automated key management, as described above for the ESP SAs, then it is highly unlikely that the AH SA would be manually keyed. The push to retain manual keying as a base facility for IPsec is waning, and most implementations have IKE available. Under these circumstances, this vulnerability is unlikely to be realized.] \subsection{Other considerations} Doing the encryption first and authentication later allows the recipient to discard packets with erroneous authentication faster, without the overhead of the decryption. This helps the computer cope with denial-of-service attacks in which a large number of fake packets eat up a lot of CPU time. We question whether this would be the preferred mode of attack against a TCP/IP-enabled computer. If this property is really important, a 1- or 2-byte MAC (Message Authentication Code) on the ciphertext could be added. The MAC code allows the recipient to rapidly discard virtually all bogus packets at the cost of an additional MAC computation per packet. [a one or two byte MAC provides so little protection that this does not seem to be an attractive counter-proposal. Also, as noted above, it adds complexity ] \subsection{Conclusion} The ordering of encryption and authentication in IPsec is wrong. Authentication should be applied to the plaintext of the payload, and encryption should be applied after that. \section{Security Associations} A Security Association (SA) is a simplex ``connection' that affords security services to the traffic carried by it \cite[section 4]{RFC2401}. The two computers on either side of the SA store the mode, protocol, algorithms, and keys used in the SA. Each SA is used only in one direction; for bidirectional communications two SAs are required. Each SA implements a single mode and protocol; if two protocols (such as AH and ESP) are to be applied to a single packet, two SAs are required. Most of our aforementioned comments also affect the SA system; the use of two modes and two protocols make the SA system more complex than necessary. There are very few (if any) situations in which a computer sends an IP packet to a host, but no reply is ever sent. [we have a growing number of apps where this functionality may be appropriate. For example, broadcast packet video feeds and secure time feeds are unidirectional.] There are also very few situations in which the traffic in one direction needs to be secured, but the traffic in the other direction does not need to be secured. It therefore seems that in virtually all practical situations, SAs occur in pairs to allow bidirectional secured communications. In fact, the IKE protocol negotiates SAs in pairs. [IKE has not always been well coordinated with IPsec, unfortunately. This is why we have to have null encryption and null authentication algorithms. So, I dont think one should cite IKE behavior as a basis for making SAs bi-directional. I agree that the vast majority of examples that we see now are full duplex, but we have example where this may not apply, as noted above.] This would suggest that it is more logical to make an SA a bidirectional ``connection'' between two machines. This would halve the number of SAs in the overall system. It would also avoid asymmetric security configurations, which we think are undesirable (see section~\ref{sec:SPD}). [The SPI that is used as a primary de-multiplexing value, must be chosen locally, by the receiver, so having bi-directional SAs probably wont change the size of the SAD substantially. Specifically, how do you envision that a switch to bi-directionality would simplify implementations?] \section{Security policies}\label{sec:SPD} The security policies are stored in the SPD (Security Policy Database). For every packet that is to be sent out, the SPD is checked to find how the packet is to be processed. The SPD can specify three actions: discard the packet, let the packet bypass IPsec processing, or apply IPsec processing. In the last case, the SPD also specifies which SAs should be used (if suitable SAs have already been set up) or specifies with what parameters new SAs should be set up to be used. The SPD seems to be a very flexible control mechanism that allows a very fine-grained control over the security processing of each packet. Packets are classified according to a large number of selectors, and the SPD can match some or all selectors to determine the appropriate action. Depending on the SPD, this can result in either all traffic between two computers being carried on a single SA, or a separate SA being used for each application, or even each TCP connection. Such a very fine granularity has disadvantages. There is a significantly increased overhead in setting up the required SAs, and more traffic analysis information is made available to the attacker. At the same time we do not see any need for such a fine-grained control. [a lot of customers for IPsec products disagree!] The SPD should specify whether a packet should be discarded, should bypass any IPsec processing, requires authentication, or requires authentication and encryption. Whether several packets are combined on the same SA is not important. [yes it is. By allowing an administrator the ability to select the granularity of protection, one can control the level of partial traffic flow confidentiality offered between security gateways. Also, fine-grained access control allows an admin to allow some forms of connections through the gateway, while rejecting others. Access control is often the primary, underlying motivation for using IPsec. A number of attacks become possible if one cannot tightly bind the authentication provided by IPsec to the access control decision. Also, given the computational costs of SA establishment via IKE, it is important to allow an administrator to select the granularity of SAs.] The same holds for the exact choice of cryptographic algorithm: any good algorithm will do. There are two reasons for this. First of all, nobody ever attacks a system by cryptanalysis. Instead, attacks are made on the users, implementation, management, etc. Any reasonable cryptographic algorithm will provide adequate protection. The second reason is that there are very efficient and secure algorithms available. Two machines should negotiate the strongest algorithm that they are allowed. There is no reason to select individual algorithms on an application-by-application basis. [if one were to employ ESP without authentication, because a specific higher layer protocol provided its own authentication, and maybe because the application employed FEC, then one might well imagine using different encryption algorithms, or different modes (e.g., block vs. stream) for different SAs. while I agree that the focus on algorithm agility may be overstated, it does allow communicating parties to select a higher quality algorithm, relative to the mandated default, if they both support that algorithm.] In our opinion, management of the IPsec protocols can be simplified by letting the SPD contain policies formulated at such a higher level. As we argued in section~\ref{sec:complexity}, simplification will strengthen the actual system. [examples provided above illustrate why fine-grained access control is important.] It would be nice if the same high-level approach could be done in relation to the choice of SA end-points. As there currently does not seem to be a reliable automatic method of detecting IPsec-enabled security gateways, we do not see a practical alternative to manual configuration of these parameters. It is questionable whether automatic detection of IPsec-enabled gateways is possible at all. Without some initial knowledge of the other side, any detection and negotiation algorithm can be subverted by an active attacker. [the authors identify a good problem, but it is hardly an unsolvable one. A proposal was put forth (by Bob Moscowtiz, over a year ago) to include records in the DNS analogous to MX records. When one tried to establish an SA to a host behind an SG, fetching this record would direct the initiator to an appropriate SG. This solves the SG discovery problem. Other approaches have been put forth in the more recent BBN work on security policy management, which forms the basis for a new IETF WG, chaired by Luis Sanchez. The fact that none of the approaches has been deployed says more about the priorities of IPsec vendors and early adopters than about the intractability of the problem. The other part of the problem is verifying that an SG is authorized to represent the SA target. Here too various approaches have been described on the IPsec mailing list.] \section{General comments} This section contains general comments that came up during our evaluation of IPsec. \begin{enumerate} \item In \cite[p.\ 22]{RFC2401}, several fields in the SAD are required for all implementations, but only used in some of them. It does not make sense to require the presence of fields within an implementation. Only the external behavior of the system should be standardized. [the SAD defined in 2401 is nominal, as the text explains. An implementation is not required to implement these fields, but must exhibit behavior consistent with the presence of these fields. We were unable to specify external behavior without reference to a construct of this sort. The SAD has the same property.] \item According to \cite[p.\ 23]{RFC2401}, an SA can be either for transport mode, tunnel mode, or ``wildcard,'' in which case the sending application can choose the mode on a packet-by-packet basis. Much of the rest of the text does not seem to take this possibility into account. It also appears to us to be needless complexity that will hardly every be used, and is never a necessity. We have already argued that transport mode should be eliminated, which implies that this option is removed too. If transport mode is to be retained, we would certainly get rid of this option. [I agree, but Dan McDonald of Sun is adamant about this. So, chalk it up to the committee process!] \item IPsec does not allow replay protection on an SA that was established using manual key management techniques. This is a strange requirement. We realize that the replay protection limits the number of packets that can be transmitted with the SA to $2^{32}-1$. Still, there are applications that have a low data rate where replay protection is important and manual keying is the easiest solution. [elsewhere this critique argues for not presenting options in a standard that can be misconfigured. Yet here, the authors make an argument for just such an option! The WG decided that there was too great a chance that a manually keyed SA would fail to maintain counter state across key lifetime and thus made a value judgement to ban anti-replay in this context.] \item \cite[section 5.2.1, point 3]{RFC2401} suggests that an implementation can find the matching SPD entry for a packet using back-pointers from the SAD entries. In general this will not work correctly. Suppose the SPD contains two rules: the first one outlaws all packets to port $X$, and the second one allows all incoming packets that have been authenticated. An SA is set up for this second rule. The sender now sends a packet on this SA addressed to port $X$. This packet should be refused as it matches the first SPD rule. However, the backpointer from the SA points to the second rule in the SPD, which allows the packet. This shows that back-pointers from the SA do not always point to the appropriate rule, and that this is not a proper method of finding the relevant SPD entry. [this is point #3 and is applied only after points #1 and #2. Since point #1 calls for a liner search of the SPD, the packet would be rejected, as required. Thus point #3 is not in error.] \item The handling of ICMP messages as described in \cite[section 6]{RFC2401} is unclear to us. It states that an ICMP message generated by a router must not be forwarded over a transport-mode SA, but transport mode SAs can only occur in hosts. By definition, hosts do not forward packets, and a router never has access to a transport-mode SA. [???] The text further suggests that unauthenticated ICMP messages should be disregarded. This creates problems. Let us envision two machines that are geographically far apart and have a tunnel-mode SA set up. There are probably a dozen routers between these two machines that forward the packets. None of these routers knows about the existence of the SA. Any ICMP messages relating to the packets that are sent will be unauthenticated and unencrypted. Simply discarding these ICMP messages results in a loss of IP functionality. This problem is mentioned, but the text claims this is due to the routers not implementing IPsec. Even if the routers implement IPsec, they still cannot send authenticated ICMP messages about the tunnel unless they themselves set up an SA with the tunnel end-point for the purpose of sending the ICMP packet. The tunnel end-point in turn wants to be sure the source is a real router. This requires a generic public-key infrastructure, which does not exist. [2401 clearly states the dangers associated with blindly accepting unauthenticated ICMP, and the functionality problems associated with discarding such messages. System administrators are provided with the ability to make this tradeoff locally. The first step to addressing this problem is the addition of IPsec into routers, as stated in the RFC. Only then does one face the need to have a PKI that identifies routers. Yes, this second PKI does not exist, but a subset of it (at BGP routers) might be established if the S-BGP technology is deployed. These are the routers most likely to issue ICMP PMTU messages.] As far as we understand this problem, this is a fundamental compatibility problem with the existing IP protocol that does not have a good solution. \item \cite[section 6.1.2.1]{RFC2401} lists a number of possible ways of handling ICMP PMTU messages. An option that is not mentioned is to keep a limited history of packets that were sent, and to match the header inside the PMTU packet to the history list. This can identify the host where the packet that was too large originated. [the approach suggested by the authors was rejected as imposing too much of a burden on an SG. section 6.1.2.1 offers options (not suggestions) for an SG to respond to ICMP PMTU messages, including heuristics to employ when not enough information is present in the returned header. These options may not as responsive as a strategy that caches traffic on each SA, but they are modest in the overhead imposed. Also, an SA that carries a wide range of traffic (not fine-grained) might not benefit from a limited traffic history, as the traffic that caused the ICMP might well be from a host whose traffic has been flushed from the limited history.] \item \cite[section 7]{RFC2401} mentions that each auditable event in the AH and ESP specifications lists a minimum set of information that should be included in the audit-log entry. Not all auditable events defined in \cite{RFC2406} include that information. Furthermore, auditable events in \cite{RFC2401} do not specify such a minimum list of information. The documentation should be reviewed to ensure that a minimum list of audit-log information is specified with each auditable event. [???] \item Various algorithm specifications require the implementation to reject known weak keys. For example, the DES-CBC encryption algorithm specifications \cite{RFC2405} requires that DES weak keys are rejected. It is questionable whether this actually increases security. It might very well be that the extra code that this requires creates more security problems due to bugs than are solved by rejecting weak keys. Weak keys are not really a problem in most situations. For DES, it is far less work for an attacker to do an exhaustive search over all possible keys than to wait for an SA that happens to use a weak key. After all, the easiest way for the attacker to detect the weak keys is to try them all. Weak-key rejection is only required for algorithms where detecting the weak key class by the weak cipher properties is significantly less work than trying all the weak keys in question. We recommend that the weak-key elimination requirement be removed. Encryption algorithms that have large classes of weak keys that introduce security weaknesses should simply not be used. [I tend to agree with this analysis. The argument for weak key checking was made by folks who dont understand the cryptographic issues involved, but who are persistent and loud, e.g., Bill Simpson. Another flaw in the committee process.] \item The only mandatory encryption algorithm in ESP is DES-CBC. Due to the very limited key length of DES, this cannot be considered to be very secure. We strongly urge that this algorithm not be standardized but be replaced by a stronger alternative. The most obvious candidate is triple-DES. Blowfish could be used as an interim high-speed solution.\footnote{On a Pentium CPU, Blowfish is about six to seven times faster than triple-DES.} The upcoming AES standard will presumably gain quick acceptance and probably become the default encryption method for most systems. [DES as a default was mandated because of pressure from vendors who, at the time, could not get export permission for 3DES. Triple DES or AES will certainly augment DES, and may replace it in the future. ] \item The insistence on randomly selected IV values in \cite{RFC2405} seems to be overkill. It is true that a counter would provide known low Hamming-weight input differentials to the block cipher. All reasonable block ciphers are secure enough against this type of attack. Use of a random generator results in an increased risk of an implementation error that will lead to low-entropy or constant IV values; such an error would typically not be found during testing. [in practice the IV is usually acquired from previous ciphertext output, which is easy to acquire and not likely to result in significant complexity. In hardware assisted environment an RNG is usually available anyway.] \item Use of a block cipher with a 64-bit block size should in general be limited to at most $2^{32}$ block encryptions per key. This is due to the birthday paradox. After $2^{32}$ blocks we can expect one collision.\footnote{To get a $10^{-6}$ probability of a collision it should be limited to about $2^{22}$ blocks.} In CBC mode, two equal ciphertexts give the attacker the XOR of two blocks of the plaintext. The specifications for the DES-CBC encryption algorithm \cite{RFC2405} should mention this, and require that any SA using such an algorithm limit the total amount of data encrypted by a single key to a suitable value. \item The preferred mode for using a block cipher in ESP seems to be CBC mode \cite{RFC2451}. This is probably the most widely used cipher mode, but it has some disadvantages. As mentioned earlier, a collision gives direct information about the relation of two plaintext blocks. Furthermore, in hardware implementations each of the encryptions has to be done in turn. This gives a limited parallelism, which hinders high-speed hardware implementations. [first, this is not an intrinsic part of the architecture; one can define different modes for use with existing or different algorithms if the WG is so motivated. Second, current hardware is available at speeds higher than the associated packet processing capability of IPsec devices, so this does not appear to be a problem for the near term. Transition to AES will decrease the processing burden (relative to 3DES), which may render this concern less serious.] Although not used very often, the counter mode seems to be preferable. The ciphertext of block $i$ is formed as $C_i = P_i \oplus E_K( i )$, where $i$ is the block number that needs to be sent at the start of the packet.\footnote{If replay protection is always in use, then the starting $i$-value could be formed as $2^{32}$ times the sequence number. This saves eight bytes per packet.} After more than $2^{32}$ blocks counter mode also reveals some information about the plaintext, but this is less than what occurs in CBC. The big advantage of counter mode is that hardware implementations can parallelize the encryption and decryption process, thus achieving a much higher throughput. [earlier the authors criticize IPsec for a lack of orthogonality, but introducing interdependence between the anti-replay counter and encryption would certainly violate the spirit of the earlier criticism! Counter mode versions of algorithms can be added to the list easily if there is sufficient vendor support.] \item \cite[section 2.3]{RFC2451} states that Blowfish has weak keys, but that the likelihood of generating one is very small. We disagree with these statements. The likelihood of getting two equal 32-bit values in any one 256-entry S-box is about ${256 \choose 2} \cdot 2^{-32} \approx 2^{-17}$. This is an event that will certainly occur in practice. However, the Blowfish weak keys only lead to detectable weaknesses in reduced-round versions of the cipher. There are no known weak keys for the full Blowfish cipher. \item In \cite[section 2.5]{RFC2451}, it is suggested to negotiate the number of rounds of a cipher. We consider this to be a very bad idea. The number of rounds is integral to the cipher specifications and should not be changed at will. Even for ciphers that are specified with a variable number of rounds, the determination of the number of rounds should not be left up to the individual system administrators. The IPsec standard should specify the number of rounds for those ciphers. [???] \item \cite[section 2.5]{RFC2451} proposes the use of RC5. We urge caution in the use of this cipher. It uses some new ideas that have not been fully analyzed or understood by the cryptographic community. The original RC5 as proposed (with 12 rounds) was broken, and in response to that the recommended number of rounds was increased to 16. We feel that further research into the use of data-dependent rotations is required before RC5 is used in fielded systems. [RC5 is not required by IPsec implementations. In the spirit of flexible implementations, vendors are free to offer any additional algorithms in addition to the required default. In general, the IETF is not prepared to make value judgements about these algorithms.] \item \cite[section 2.4]{RFC2406} specifies that the ESP padding should pad the plaintext to a length so that the overall ciphertext length is both a multiple of the block size and a multiple of 4. If a block cipher of unusual block size is used (e.g., 15 bytes), then this can require up to 59 bytes of padding. This padding rule works best for block sizes that are a multiple of 4, which fortunately is the case for most block ciphers. [this padding rule is based primarily on IP packet alignment considerations, not on common block cipher sizes, as stated in the text] \item \cite[p.\ 6, point a]{RFC2406} states that the padding computations of the ESP payload with regard to the block size of the cipher apply to the payload data, excluding the IV (if present), Pad Length, and Next Header fields. This would imply that the Pad Length and Next Header fields are not being encrypted. Yet the rest of the specification is clear that the Pad Length and Next Header field are to be encrypted, which is what should happen. The text of point a should be made consistent with the rest of the text. [The text says the padding computation applies to the Payload Data exclusive of the IV, the Pad Length, and Next Header fields. The comma after IV is meat to terminate the scope of the word exclusive, and thus the intent is to include the pad length and next header fields. The term payload in ESP applies to a set of data not including the latter two fields, so the sentence is, technically, unambiguous, and it is consistent with the terms employed in the figure in section 2. But, I admit the wording could be improved.] \item There is a document that defines the NULL encryption algorithm used in ESP \cite{RFC2410}, but no document that defines the NULL authentication algorithm, which is also used by ESP \cite[section 5]{RFC2406}. [good point. Another RFC publication opportunity!] \item The NULL cipher specifies an IV length of zero \cite{RFC2410}. This would seem to imply that the NULL cipher is used in CBC mode, which is clearly not the case. The NULL cipher is in fact used in ECB mode, which does not require an IV. Therefore, no IV length should be specified. [use of the NULL cipher in ECB mode would be inconsistent with the guidance in FIPS 82, and thus CBC mode is intended, to preserve the confidentiality characteristics inherent in this cipher :-).] \end{enumerate} \section{Conclusions} The IPsec system should be simplified significantly. This can be done without loss of functionality or performance. There are also some security weaknesses that should be fixed. [the extensive comments above illustrate that the proposed changes to IPsec would change the functionality, contrary to the claim made here. One might argue about the importance of some of this functionality, but several examples have been provided to illustrate application contexts that the authors of this report did not consider in their analysis. Several misunderstandings of some RFCs also were noted.] Due to its high complexity, we have not been able to analyze IPsec as thoroughly as we would have liked. After simplification, a new security analysis should be performed. \chapter{ISAKMP}\label{chap:ISAKMP} ISAKMP \cite{RFC2408} defines the overall structure of the protocols used to establish SAs and to perform other key management functions. ISAKMP supports several Domains Of Interpretation (DOI), of which the IPsec-DOI is one. ISAKMP does not specify the whole protocol, but provides building blocks for the various DOIs and key-exchange protocols. This chapter analyzes the ISAKMP specifications. Section references and page numbers in this chapter refer to \cite{RFC2408}. We found the ISAKMP document \cite{RFC2408} very difficult to understand. Essential explanations are missing, and the document contradicts itself in various places. \section{Header types} The definition of the ISAKMP headers gives rise to various questions. The standard header for each payload contains the type of the \emph{next\/} payload in the message \cite[section 3.2]{RFC2408}. This is an odd construction that would seem to complicate both the generation and parsing of messages. As the ISAKMP header already contains the overall length, the parser already knows whether there is another payload in the message. It would seem simpler to have each payload contain its own type in the standardized payload-header, instead of the type of the next payload. Section 3.4 does not make it clear that the Security Association Payload is in fact a header, and is always followed by zero or more Proposal payloads. (A similar situation occurs with the Proposal and Transform payloads.) This type of dependency should be documented more clearly. The current text caused the authors much confusion, as it was not at all clear that such a system of sub-payloads was being used. Another oddity is the fact that there is no field in the SA header to indicate the type of the first sub-payload. Each payload specifies the type of the \emph{next\/} payload, but there is no corresponding field for the very first sub-payload. Presumably the receiver has to know that an SA payload will always have a proposal payload as the first sub-payload. This gives rise to the question why the proposal payload has a ``next header'' field at all. Using the same type of information (allowed sub-payload structures), the receiver can already deduce what the value of this field should be. There are also other inconsistencies. The SA header does not specify how many proposals are included as sub-payloads, but the proposal header does specify how many transform payloads are included as sub-payloads. Why? The system of sub-payloads should be documented more clearly. We would suggest that the ``next header'' field be changed into a ``this header'' field. That would certainly make a lot of things simpler. The confusion over the sub-payloads also leads to a second confusion. Presumably a Certificate Request payload may not be inserted between two Proposal payloads, although this is not made clear. If a Certificate Request payload was inserted before the first proposal, the recipient would have no way of identifying that payload as a Certificate Request payload, and would interpret it as a Proposal. The fact that the Certificate Request Payload section specifies that it must be accepted at any point during the exchange only adds to the confusion. \section{Comments on the documentation} The description of ISAKMP is not very clear. We had great trouble understanding the intentions of the much of the description. \begin{enumerate} \item The document often contains repeated instances of the same text, or very similar texts. This makes the text unnecessarily long, and hard to read. For example, in section 5.2 the list of checking actions and possible logging and notifications could be described much more succinctly. \item Section 2.5.3 imposes some requirements on the cookies. It continues to suggest a method of generating them, and then requires certain features to be used in this method. The text should be clear as to whether the method is a suggestion (in which the word ``MUST'' should not be used) or whether it is part of the standard. \item Section 5.2 specifies how to start an ISAKMP exchange, but claims to specify how to send an ISAKMP message. If new cookies are created for each message, the system will obviously fail. The description should be fixed. \item \cite[section 3.11]{RFC2408} defines the Hash Payload, which is used to verify the integrity and authentication of the data in the ISAKMP message. The data is described as being the result of a hash function applied to the message; this provides no integrity or authentication. Presumably this payload contains a MAC, in which case the name ``Hash Payload'' (as well as the ``Hash Data'' field name) is a misnomer. \item Page 45 states that the order of payloads within a message is not mandated. Page 46 states that the HDR exchange type defines the payload orderings. This is a contradiction. \item Section 5.1 specifies the generic processing of sending an ISAKMP message. The description method used to specify the algorithm is ambiguous, and probably even wrong. It is not clear when exactly step 4 is entered. Strictly speaking, in step 2 the message is resent and the counter is decremented. Let us suppose it reaches 0. Step 3 is now executed immediately, which logs the RETRY LIMIT REACHED event in the log before the other side has had a chance to respond to the last resend. Assuming step 4 is executed immediately after step 3, the last resend of the packet will never be answered, and is in vain. This is clearly not the intention of the designers. The description of the resend mechanism should be clarified. Presumably the resend mechanism is disabled as soon as a valid reply is received. \item In section 5.2, the recipient is expected to verify both cookies. As the recipient has only his own cookie-generation key, he cannot verify the cookie of the sender of the message. \item Section 5.13 requires the nonce value that a party generates to be unique. The standard should specify the set within which the nonce has to be unique. \item Data attributes are only present in a Transform payload. The IPsec DOI defines several data attributes that apply to the various levels. Some attributes apply to the entire SA. An SA can contain several proposals, and a proposal can contain several transforms. Should the SA-wide attributes be in the first transform, in each of the transforms, or elsewhere? How should the various placings of attributes be interpreted? \end{enumerate} \section{Security comments} We found several cases in which the security of the constructions is questionable. As the ISAKMP is a very general structure document, it is often unclear whether this will result in weaknesses in actual specific cases in which ISAKMP is used. \begin{enumerate} \item ISAKMP allows great latitude to the participants in the exact messages that are sent and the exact processing that is done. This makes it extremely hard to give any reasonable statement about the security properties achieved by the protocols. The authors do not feel they have a good overview of all the different variations that are allowed by ISAKMP. This makes a good security analysis extremely hard to do. \item Section 5.1 specifies the resend functionality. What is not clear is how the receiver responds to multiple copies of the same message. Ideally, the implementation should verify that all copies it receives are identical, and resend identical copies of the first reply that it sent. A less careful implementation might re-process the incoming message. This opens up various modes of attack. For example, in the identity protection exchange an attacker could resend the fourth message to the initiator, and collect authentications on many chosen messages by varying the nonce. (We are ignoring the encryption for the moment; note that the encryption might be weak or nonexistent.) Even more threatening, by changing the KE payload the attacker might be able to use subtle interactions to find information about the key. An attack along the following lines might be possible. An attacker eavesdrops on an identity protection exchange, and then resends the fourth message with modified KE payloads. Let us assume that a DH key agreement protocol modulo $p$ is used with a subgroup of size $q|(p-1)$, and that $p-1$ has several other small divisors. (Even though this specific choice of DH group might seem unfortunate, it could be used in a practical and secure key exchange algorithm.) The attacker can now recover the DH secret of the initiator by repeatedly sending KE payloads that contain elements of a low order and checking which of the limited set of possible keys is being used in the encryption. This reveals the initiator's DH secret modulo the order of the element sent in the KE payload. Combining several of these tries reveals the entire DH secret. Once the DH secret of the initiator is known, the attacker resends the original fourth message. This returns both parties to the same state they had before the attacker interfered. Any subsequent exchange continues as normal, but the attacker has the key, which clearly violates the intention of the protocol. This shows that it is important to specify how each party should react to a repeat of a message in an exchange. We have not analyzed other protocols for similar weaknesses, but it seems clear that any solution that reprocesses a protocol step can introduce additional weaknesses. Therefore, the retransmission system and handling of duplicate messages should avoid reprocessing messages. Rejecting copies of a message that are not identical to the first copy received does not provide for recovery from a bogus message. There is little security risk in not providing for this recovery. The exchange will have to be abandoned and a new one started. In general, there is no method of ensuring the completion of an exchange in the presence of an active attacker. It is always possible for the attacker to flip some bits in each message, in which case any exchange will fail. \item Section 4.6 defines the authentication-only exchange that provides authentication of the other party but does not exchange keys. There is no direct use for this protocol. At the end of the exchange both parties know who they were talking to, but by itself that does not provide much information. We assume this protocol is meant to be used to authenticate the other party when a secure channel has already been established without authentication. This does not work, as the other side can perform a man-in-the-middle attack against the authentication-only protocol. This is in fact a general property of the four exchanges defined in ISAKMP. All of them can be completed by a man in the middle. However, the man in the middle does not learn the key that is established by the exchange. As the authentication-only protocol does not establish a key, and does not link the authentication to an existing key, none of the participants in the protocol is much wiser at the end. We fail to see any use for this protocol. \item The Identity Protection Exchange of section 4.5 is vulnerable to an active attack. The Initiator sends its identity before having authenticated the other party. An active attacker can pretend to be the responder, and collect the Initiator's identity before abandoning the protocol. The Initiator has little choice but to try again to negotiate the SA. If the attacker does not interfere this will complete, but the attacker has retrieved the IDii value. Note that this type of weakness can be avoided by the use of public-key encryption. The initiator can send his own identity encrypted with the public key of the responder. For this to work, the initiator has to retrieve the responder's public key in some way. A central public-key directory can provide this service, without revealing more information to an attacker than that the initiator is retrieving somebody's key. \end{enumerate} \section{Functional comments} The following comments are mostly on the functionality of ISAKMP. \begin{enumerate} \item Cookies are 64 bits, and are used to identify the ISAKMP SA and the negotiation thereof. There is a non-negligible probability that a server will issue the same cookie value twice. We expect this to happen after about $2^{32}$ negotiations. After $2^{22}$ negotiations, the chance of such a collision is on the order of $2^{-20}$. This would allow an attacker to create two SA negotiations that have the same set of cookies, and to attempt to swap messages between the two. It is unclear what the consequences of this would be; that depends on the details of the actual protocol. At a minimum, it should be noted in the ISAKMP documentation that the cookies by themselves do not provide a unique identifier for the exchange and that individual protocols should provide their own random nonces to protect against these types of attacks. \item The separation of functions between the ISAKMP and the DOI is haphazard. For example, the formatting of the key exchange payload is left completely for the DOI to define, but for the identification payload the ISAKMP restricts the DOI and forces a certain formatting structure. If the ISAKMP and DOI are to be separated, then anything that does not directly affect the ISAKMP should be left to the DOI. \item The Certificate Request Payload is used to request a certificate from the other party. It allows the requestor to specify a single CA that it will accept. The responder must send ``its certificate based on the value contained in the payload.'' In many practical systems, a single responder might have many certificates. It is unclear whether the responder should send only one suitable certificate, or all suitable certificates. This issue should be clarified in the standard. \item There does not seem to be a way for one of the parties to ask for a certificate issued by any one of a list of CAs. This could be very useful. There are currently many competing CAs for X.509v3 certificates. A specific machine might very well trust a subset of them. In that case it would accept a certificate signed by any one of a list of CAs. In ISAKMP, sending a list of CAs is interpreted as asking for all certificates from these SAs (see section 3.10). \item Section 4.5 defines the Identity Protection Exchange. The nonces in this protocol could also be sent in the first two messages, making this protocol more like the base exchange. Furthermore, the exchange can be shortened by two messages. The order of the third and fourth message are not important. If the order of these two messages is swapped, then each of them can be merged with an adjacent message and sent in a single packet. This would save a full round-trip time in the negotiations without loss of functionality. \item Section 4.7 defines the aggressive exchange. It states that the initial SA payload can only contain one proposal and one transform. This does not seem to be a necessary restriction. First of all, two proposal payloads with the same proposal number constitute a single proposal. If the concern is that the Initiator must know the final transforms to be used while sending the first message, then the requirement that only one proposal number is used is enough. As the KE payload is not dependent on the way in which the final keys are actually being used, we do not see a reason why the single-proposal restriction is in place. The restriction to a single transform seems redundant. We see no problems with a single proposal that contains multiple transforms. \item Section 5.5 forces the SPI to be generated pseudorandomly. This is a needless restriction on the sender, and should be removed. Some implementations might wish to use the SPI directly as a index into a table, in which case it cannot be generated pseudorandomly. \cite[appendix A]{RFC2401} states that the SPI has only local significance, and that the recipient may choose various ways to interpret the SPI. This would seem to imply that the SPI does not have to be chosen randomly. The uniqueness requirement should be documented further; it should be specified within what set of values the newly chosen SPI value has to be unique. \item Section 5.5 allows the responder to send an INVALID-PROTOCOL-ID notification in case he does not know the protocol in question. This is listed as an ``error'' notification, which would at least suggest that the exchange is aborted. We suggest that the responder simply ignore the payload, the associated transforms, and any other proposal payloads with the same proposal number. Unknown protocols can be seen as unacceptable protocols. If the sender is to be informed of this fact, then a warning notification should be sent, not an error. \item Various features, such as the cookies, are included to prevent denial-of-service attacks against the participants. As stated in \cite[section 1.7.1]{RFC2408}, denial-of-service attacks cannot be prevented completely. We are not convinced that it is a good idea to increase the complexity of the protocol to provide a partial solution to this problem. This would require an analysis of the complexity of the various forms of IP-related denial-of-service attacks against computers. Partial countermeasures only make sense if they make attacks harder to perform. Protecting against difficult attacks makes no sense if there is no protection against the easy forms of attack. This remains an area for further study. \end{enumerate} \section{General comments} \begin{enumerate} \item It is interesting to note that \cite[section 1]{RFC2408} claims that splitting the functionality into the ISAKMP, DOI, and key exchange protocol makes the security analysis more complex. We feel that a modularization along well-chosen boundaries could simplify the analysis significantly. Unfortunately, the ISAKMP, DOI and key exchange protocol document still contain numerous cross-dependencies. \item An exchange type does not specify the order of the payloads within a message. This is needless flexibility that only adds to the complexity of the software. \end{enumerate} \chapter{The IPsec DOI}\label{chap:IPsecDOI} The IPsec Domain Of Interpretation is given in \cite{RFC2407}. The DOI is mostly concerned with specifying the exact way in which various values are interpreted; most of the DOI is not security-critical. \section{General comments} \begin{enumerate} \item Section 4.4.3 specifies transform IDs that are a kind of generic group based on a specific primitive. The exact use of the primitive is further specified by an attribute. This does not make much sense. The entire MAC construction should be seen as one indivisible unit. There is nothing to be gained from grouping them into transform-groups by their primitive. No such grouping is used for the ESP encryption transforms. Each transform is specified fully by the transform ID. The ESP authentication algorithm is specified by the attributes. We would suggest that a single method of specifying authentication transforms is used for both AH and ESP. \item On page 14, KPDK is listed as an Authentication Algorithm. This is not a fully specified algorithm. It can be used by AH in combination with the AH transform ID, but it cannot be used by ESP. This is weird, and we have no idea why the standard is written this way. We propose to remove the KPDK algorithm, or specify KPDK-MD5 and KPDK-SHA separately. \item The definition of the SA Life Type and SA Duration attributes is unfortunate. This introduces order-dependencies and forces the parser to carry state, both of which make the parser more complex. It would be much simpler to create two attributes: SA-lifetime-seconds and SA-lifetime-kbytes. Additional lifetime units are then introduced by adding new attributes, instead of adding new attribute values. \item It is not clear to us from the documentation what the higher-level interpretation is of the Secrecy level, Secrecy category bitmap, Integrity level, and Integrity category bitmap fields in the SA payload in section 4.6.1. As there are currently no labeled domain identifiers allocated, these fields do not seem to be used in any current system. \item Section 4.6.2 states that the Identification payload is used to identify the initiator. The protocols in \cite{RFC2408} also use the identification payload to identify the responder. \end{enumerate} \chapter{IKE}\label{chap:IKE} IKE is the default key-exchange protocol for ISAKMP, and at the moment the only one. IKE is built on top of ISAKMP and performs the actual establishment of both ISAKMP SAs and IPsec SAs. \section{Primitive functions} IKE supports the negotiation of various primitive functions for use in the protocols. Among these are the hash function and the pseudorandom function (PRF) to be used. No requirements are given for the hash function and PRF. There is no mention of the properties that IKE assumes the hash function and PRF have. \subsection{Hash function}\label{sec:hashfunc} The most widely used definition of a hash function uses the requirement that the hash function is collision-resistant. Thus, it should be impossible to find two messages $m_1$ and $m_2$ such that $H(m_1)=H(m_2)$ where $H$ is the hash function. In \cite{And:Hash93} Ross Anderson showed that this is often not enough, and that many protocols break for certain collision-resistant hash functions. He gave one simple example. Let $m'$ be the first $n$ bits of the message $m$, and let $m''$ be the rest. Define $H'(m'|m'') := m' | H( m'' )$ for any collision-resistant hash function $H$. It is clear that $H'$ is as collision-resistant as $H$ is. However, many protocols silently assume that the hash function is more or less a random oracle, and can fail when this is not the case \cite{And:Hash93}. For example, the HMAC construction fails miserably with $H'$ as hash function, as it reveals the key in the output. This shows that it is important to define which properties are required from the hash function. Applying HMAC to a collision-resistant hash function does not always result in a good MAC function. \subsection{PRF} Currently no special PRFs are defined; the default mode of using the negotiated hash function in the HMAC construction is used instead. There are no requirements given for a new PRF; the description calls for a ``keyed pseudorandom function.'' Following the notational convention of \cite{RFC2409}, we will call the first argument of the PRF the key and the second argument the message. We take this to mean the following: for a fixed key, the mapping of messages to the output is a pseudorandom function. The PRF should be indistinguishable from a function where the key uniformly selects a random element of the set of all functions mapping messages into suitable output values. Note that this definition does not preclude a PRF that is invertible for a known key. We define a PRF called NPRF (for Nasty PRF) as follows: for a short message the PRF is defined as $$ \mbox{prf}(k,m) = E( k, 0 | m ) $$ while for long messages it is defined as $$ \mbox{prf}(k,m) = E( k, 1 | H(m) ) $$ Here, $H$ is a suitable hash function, $E$ is a block cipher encryption taking a key and a plaintext block as arguments, and a message is considered ``long'' if it is at least as long as the block size of the block cipher. For short messages, this PRF is invertible if the key is known. If the block cipher is good and the block size is large enough (e.g., 1024 bits), this function is indistinguishable from a random function, as detecting the fact that it is a permutation and not a random function requires too much work. IKE uses the PRF sometimes with known key input. It is clearly not the designer's intention to have an invertible function in this case. As with the hash function, IKE should specify what properties it expects from its PRF. The default construction of the PRF is to use HMAC and the hash function. As shown above, some hash functions result in very bad PRFs when used with the HMAC construction. This can break any protocol using the PRF. For example, the main mode exchange with public-key encryption fails when using HMAC with $H'$ defined above as the HASH\_I reveals SKEYID, allowing a fake responder to impersonate the real responder. \subsection{Conclusions} Whenever primitive functions are used, it is important to specify exactly which properties are assumed. This can be seen as specifying the interface between the two parts of the definition. It allows each of the parts to be analyzed separately. Without such clear specifications it is much harder to analyze the security of the system. Furthermore, there is a serious danger that some future extension will introduce a new primitive with an undesirable property that was silently assumed by the designers and evaluators of the original version. \section{Derivation of SKEYID data} Observe the computation of SKEYID \cite[page 10]{RFC2409} in the three different authentication cases. For signature authentication, the key input of the PRF is public, and the message input is secret. This is clearly an abuse of the PRF. (If the NPRF is used, revealing SKEYID also reveals $g^{xy}$.) Furthermore, the concatenation of the two nonces can be up to 512 bytes long, while the HMAC construction takes at most 64 bytes of key. The public-key encryption case on the next line resolves this by inserting an extra hash function application. The three formulas for computing SKEYID seem somewhat ad hoc. It is not clear what properties are wanted, and which are achieved. Why are the cookies used in the public-key encryption case, and not in the pre-shared key case? One idea seems to be to use every value at most once as input. This principle is not followed in the derivation of the SKEYID\_d, SKEYID\_a, and SKEYID\_e where the same values are repeatedly used in the derivation. In the signature authentication case, $g^{xy}$ affects both the key and the message field of the PRF application used to compute SKEYID\_d. As far as we are able to see these properties do not lead to a direct weakness, as PRFs are very forgiving (in the ideal case). The signature authentication case is saved by the fact that SKEYID itself is never revealed, but only used as key input to other PRF applications. We recommend that the derivation of SKEYID and associated values be re-evaluated, and that the SKEYID computation for the signature authentication case be changed. \section{The HASH authentication values} Alongside the SKEYID derivation, the HASH values are defined that are used in the authentication functions. These HASH values are computed as PRF applications using SKEYID as the key and a concatenation of various data fields as message. The nonces only affect the HASH values through the SKEYID. It would seem more obvious to include all relevant fields of the protocol in the message part of the PRF. \subsection{A reflection attack} The two formulas for computing HASH\_I and HASH\_R are symmetrical with regard to swapping the initiator and the responder. This opens up the possibility of a reflection attack. In main mode with pre-shared keys, a fraudulent responder can claim the same identity as the initiator and still pass the authentication phase. The responder does this by choosing CKY-R as CKY-I and $g^{x_r}$ as $g^{x_i}$, and using the initiator's identity. In this case HASH\_R is equal to HASH\_I, so the responder can just send the back the value that the initiator sent.\footnote{Actually, the fraudulent responder cannot read the fifth message it gets from the initiator, as it is encrypted. This does not matter, as the message that he wants to send in reply has the same format, so the encrypted fifth message can be sent back as the sixth message.} The related attack for a fraudulent initiator in aggressive mode does not work as the initiator has to commit to $g^{x_i}$ before the responder chooses $g^{x_r}$ in a random manner. The same attack seems to apply to the signature authenticated main mode exchange. The responder can replay all the initiator's values and the last message, and pass the authentication. \subsection{A proposal attack} The HASH computations do not include the SA reply by the responder. This implies that an attacker can manipulate this payload without adverse effects within the protocol. Suppose the initiator sends a list of many proposals in order of preference. The least preferred proposal only provides marginal security (e.g., 40 bits or so). The attacker can now modify the responder's SA to select this weak mode, and let the rest of the exchange complete as usual. The initiator will now start using the newly negotiated SA, which is considerably weaker than it should be. Suppose this is done in an aggressive mode negotiation for phase 1. The resulting ISAKMP SA is weak. As soon as the initiator starts to use the weak keys, the attacker can do a brute-force search for the keys. Once found, the attacker has recovered the ISAKMP SA keys and can now negotiate full-strength IPsec SAs with the initiator while pretending to be the responder. This is a clear violation of the intention of the protocol. Another subtlety is that changing the responder's SA might change the mode being used. An attacker can thus have the responder performing the protocol in one mode, and the initiator the protocol in another mode. We have not investigated the possible interactions, but this is clearly undesirable. The responder's SA should be included in the HASH computations. \subsection{Conclusion} The definition of the HASH values is unacceptably weak and should be improved. \section{Parsing a string of bytes} The PRFs, signature functions, and hash functions are each applied to strings of bytes. By themselves, these strings of bytes do not specify how they are formatted. This opens up a lot of freedom for an attacker. Let us suppose that there are two places in the protocol where a PRF function is applied with the same key but with different message formats. If these formats could generate strings of the same length, then it is in principle possible to confuse the two PRF computations. An attacker can take the result of the first PRF computation (which he might receive in the first part of the protocol) and use this value in the second PRF computation. Whether or not this leads to an actual weakness depends on too many factors, but it is clearly an undesirable property. Instead of authenticating the intended message, the PRF is authenticating a string of bytes whose interpretation is not fully defined. This violates the ``Horton principle'' \cite{WS:SSL30}. Even if the set and order of the fields is known, the parsing of some of the messages depends on outside information. For example the HASH\_I computation has a message that consists of six concatenated fields. The length of each field has to be derived from some context, which is open to manipulation by an attacker. There are too many ways in which this type of attack can be attempted to analyze them all. We strongly recommend that the input to every hash function, PRF function, and signature be extended with a field that uniquely identifies the position within the protocol. Furthermore, each message that is used as an input to a hash, PRF, or signature algorithm should be parseable into its constituent fields without any outside information. This can be achieved by using a Tag-Length-Value (TLV) encoding scheme along the lines of ASN.1.\footnote{We would not advocate using ASN.1 itself, as it is very complex.} \section{Efficiency} As we noted earlier, the ISAKMP identity protection exchange can be shortened to four messages. The Main mode exchanges of IKE are implementations of the identity protection exchange of ISAKMP. The main mode exchange with signature authentication or pre-shared keys authentication can be shortened in the same way. The main modes that use public-key encryption for authentication cannot be shortened in exactly the same way, as the responder would need to know the identity of the initiator instead of the other way around. This would change the properties of the protocol. However, it is possible to shorten the exchange to five messages, by swapping the order of the last two and merging the two adjacent messages that the responder sends into a single packet. \section{Comments relating to security} \begin{enumerate} \item IKE can use the Tiger hash function. This is a fairly new hash function that uses some new ideas that have not yet been thoroughly analyzed. At the moment of writing we are not aware of any published results on Tiger other than the original paper. We feel that it is too early to use Tiger in a production system. \item Page 11 describes how the choice of signature algorithm affects the choice of PRF algorithm used to compute the HASH values. This is an ugly construction, and should be removed. It can even affect security. Suppose the signature method uses a weird hash function like the one in section~\ref{sec:hashfunc}; this is perfectly suitable for a signature system, as the hash function is collision-resistant. IKE would use this hash function in HMAC mode, which is not at all secure. The overall effect might very well be to reveal SKEYID to an attacker. This is not as far-fetched as it seems. The RSA system allows message bits to be recovered from a signature. A system that wants to take advantage of this property could very well use a definition similar to the one we gave in section~\ref{sec:hashfunc}, as this produces exactly the type of value that is suitable for an RSA signature with (partial) message recovery. \item Appendix B contains explicit rules to support CBC mode encryption algorithms. This is a violation of module boundaries, and complicates the protocol (and the software) by introducing arbitrary dependencies. We advise that such dependencies be removed and encryption be left to the encryption transform. The IV rules in appendix B do not guarantee a unique IV for all messages. If two phase 2 negotiations are done that happen to have the same message ID, then the same IV will be generated. The result is that a passive eavesdropper can recognize whether the first eight bytes of the encrypted message are the same or not. Given the very structured form of the start of a message this might actually happen once in a while, and thus reveal information to the attacker. Collisions on the message ID are far more likely than collisions on the IV, as the message ID is only four bytes. \item The method used to derive the key material for the newly negotiated SA in the phase 2 quick mode contains a weakness. The KEYMAT value depends on SKEYID\_d, the protocol, the SPI, and both nonces. The SPI values are only 32-bit, and might very well be chosen from a much smaller set of index values. This implies that it is quite likely that both the initiator and the responder will choose the same SPI value. In that case, the keying material for the two SAs (one in each direction) will be the same, which in turn allows all kind of splicing attacks. This weakness exists whether PFS was used or not. We recommend that the key material derivation be changed to avoid this problem. \item In section 5.6, the New Group Mode is specified. The two HASH values used for authentication are computed in exactly the same manner. If the SA in the first message contains only a single proposal, then the SA reply will be identical, and HASH(2) will be identical to HASH(1). As a result, HASH(2) does not really provide any authentication. If authentication is needed, the definitions of the HASH values should be changed. If authentication is not needed, the HASH values should be removed. \item We mentioned earlier that there is an active attack aginst the Identity Protection Exchange protocol of ISAKMP. In this attack the attacker pretends to be the responder, and collects the initiator's identity before abandoning the protocol execution. This works against the main mode exchanges with signature authentication and with pre-shared key authentication. It does not work against the public-key encryption authenticated versions. \end{enumerate} \section{General comments} We have the following general comments on IKE. \begin{enumerate} \item Section 5 defines encoding of group elements in the KE payload. This is different from other group element encodings in other parts of the protocols. Group element encodings should be consistent. \item Section 5 specifies that the final message of the aggressive exchange may not be protected by the ISAKMP SA. The next sentence says that the message does not have to be in the clear. These two sentences seem to contradict each other. \item Section 5.2 shows the main mode and aggressive mode protocols for authentication by public-key encryption. Even though the order of the fields in the actual implementation can be arbitrary, most descriptions use the same order of fields. The order of KE and HASH(1) shown in the two protocols are different. If there is a reason for this, it should be documented. Otherwise, we suggest that a single order be used for clarity. \item Section 5.3 shows a revised mode of using public-key encryption for authentication. From the properties given, this mode is superior to the mode of section 5.2. As there does not seem to be a reason to retain the modes of section 5.2, these should be removed. \item Section 5.3 poses additional restrictions on the order of the payloads in a message. This is overly complex. The order should either be well-defined, or free of restrictions. \item Appendix B defines the methods used to stretch the output length of the PRF, or to stretch other keying material. These methods are strong enough (given a good enough PRF), but can be improved. Even with a theoretically perfect PRF, the current definition does not generate uniformly distributed outputs. In the example given on page 37, if BLOCK1-8 is equal to BLOCK9-16, then it must also be equal to BLOCK17-24. This implies that about $2^{-64}$ of all possible SKEYID values cannot be generated by this construction. The same criticism applies to the stretching of encryption keys for ciphers that need a longer key. This is shown on pages 15, 19, and 38. This construction cannot generate all possible sequences of K1, K2, and K3. These stretching methods can easily be fixed by including a counter in the message input of the PRF. This has already been done in deriving the SKEYID\_d, SKEYID\_a, and SKEYID\_e from SKEYID. The derivation of the values SKEYID\_d, SKEYID\_a, and SKEYID\_e from SKEYID could use the same stretching function, which would simplify the implementation. \item On page 15, a CBC encryption mode is defined. This one is different from the CBC encryption modes used by the IPsec ESP protocol. There does not seem a good reason for having two incompatible CBC modes in use. Note that this CBC mode uses a fixed IV of 0, whereas the ESP encryption uses a randomly generated IV. Encryption should be defined as a clearly separate transformation. The ESP part of the standard includes clear definitions of such a separate transformation. We would like to see the ISAKMP use the same encryption functions as ESP. \item The protocol in section 5.4 can be made more flexible by allowing an additional data field that provides some kind of identifier for the pre-shared key. The aggressive exchange already provides the identity in the clear, and this is given as an advantage of aggressive mode. Adding a key-identification field gives the main mode exchange the same functionality. \item It is not quite clear what the use of the client identities are in Quick mode (see page 17). These are used to indicate the client identities that will be using this SA, and to route traffic from these clients to the right tunnel. We see no reason why a client would need to specify a particular tunnel, or have his own tunnel. This is transparent to the client. What the client could request is a level of service, such as encryption, or a certain level of security. Whether the traffic of that client is sent through the same tunnel as other traffic is unimportant. \item \cite{RFC2409} consistently confuses a hash with a PRF. The output of a PRF is often called a HASH value. This nonstandard terminology is confusing to others. \item The Quick mode negotiation protocol could be simplified significantly by using the ESP transform from IPsec for both encryption and authentication. The current solution uses a separate CBC encryption mode, and ad hoc message authentication based on specific HASH values. The protocols would be much easier to analyze if the ISAKMP SA were used to set up an confidential and authenticated tunnel (without replay protection), and the quick mode was built on top of that. As every ISAKMP implementation must also support IPsec, this would also simplify any implementation. \end{enumerate} \chapter{Conclusions} IPsec and ISAKMP have been a great disappointment to us. They are far too complex, and the complexity has lead to a large number of ambiguities, inefficiencies, and weaknesses. It has been very hard to perform a security analysis. We do not feel that we have been able to evaluate all aspects of the system within the available time frame. We have found several serious security weaknesses in IPsec and ISAKMP. What worries us more is the complexity of the systems. In our opinion, current implementation methods are not capable of creating a secure implementation of a system as complex as this. Fixing the specific security weaknesses that we found will be relatively straightforward. By itself this will not make the protocols secure. Our analysis was in no way exhaustive, and we expect that there are many more weaknesses still to be found. We feel that the only way to salvage the system is to rigorously reduce the complexity by eliminating options and improving the modularization. This will require a major overhaul. Based on the information that we have, we strongly discourage the use of IPsec for protection of confidential information. %\bibliographystyle{alpha} %\bibliography{counterpane,rfc} % Beth: this bibliography was generated automatically. % There is not much reason to check it. { \newcommand{\noopsort}[1]{}\def\x{\allowbreak}\def\s{\slash} \begin{thebibliography}{MSST98} \bibitem[And93a]{A:WhyFail} Ross Anderson. \newblock Why cryptosystems fail. \newblock In {\em Proceedings of the 1st {ACM} Conference on Computer Communications Security '93}, pages 215--227, November 1993. \bibitem[And93b]{And:Hash93} Ross Anderson. \newblock The classification of hash functions. \newblock In {\em Proceedings of the Fourth {IMA} Conference on Cryptography and Coding}, pages 83--93, 1993. \newblock Available from {\tt http:/\s www.cl.cam.ac.uk\s ftp\s users\s rja14\s hash.ps.Z}. \bibitem[FKK96]{SSLv3Nov96} Alan~O. Freier, Philip Karlton, and Paul~C. Kocher. \newblock The {SSL} protocol, version 3.0. \newblock Internet draft, Transport Layer Security Working Group, November~18, 1996. \newblock Available from {\tt http:/\s home.netscape.com\s eng\s ssl3/}. \bibitem[GK98]{RFC2410} R.~Glenn and S.~Kent. \newblock The {NULL} encryption algorithm and its use with {IPsec}, November 1998. \newblock RFC 2410. \bibitem[HC98]{RFC2409} D.~Harkins and D.~Carrel. \newblock The {I}nternet key exchange ({IKE}), November 1998. \newblock RFC 2409. \bibitem[KA98a]{RFC2402} S.~Kent and R.~Atkinson. \newblock {IP} authentication header, November 1998. \newblock RFC 2402. \bibitem[KA98b]{RFC2406} S.~Kent and R.~Atkinson. \newblock {IP} encapsulating security payload ({ESP}), November 1998. \newblock RFC 2406. \bibitem[KA98c]{RFC2401} S.~Kent and R.~Atkinson. \newblock Security architecture for the internet protocol, November 1998. \newblock RFC 2401. \bibitem[Kah67]{TheCodebreakers} David Kahn. \newblock {\em The Codebreakers, The Story of Secret Writing}. \newblock Macmillan Publishing Co., New York, 1967. \bibitem[MD98]{RFC2405} C.~Madson and N.~Doraswamy. \newblock The {ESP} {DES-CBC} cipher algorithm with explicit {IV}, November 1998. \newblock RFC 2405. \bibitem[MG98a]{RFC2403} C.~Madson and R.~Glenn. \newblock The use of {HMAC-MD5-96} within {ESP} and {AH}, November 1998. \newblock RFC 2403. \bibitem[MG98b]{RFC2404} C.~Madson and R.~Glenn. \newblock The use of {HMAC-SHA-1-96} within {ESP} and {AH}, November 1998. \newblock RFC 2404. \bibitem[MSST98]{RFC2408} D.~Maughan, M.~Schertler, M.~Schneider, and J.~Turner. \newblock Internet security association and key management protocol ({ISAKMP}), November 1998. \newblock RFC 2408. \bibitem[Orm98]{RFC2412} H.~Orman. \newblock The {OAKLEY} key determination protocol, November 1998. \newblock RFC 2412. \bibitem[PA98]{RFC2451} R.~Pereira and R.~Adams. \newblock The {ESP} {CBC}-mode cipher algorithms, November 1998. \newblock RFC 2451. \bibitem[Pip98]{RFC2407} D.~Piper. \newblock The {I}nternet {IP} security domain of interpretation for {ISAKMP}, November 1998. \newblock RFC 2407. \bibitem[TDG98]{RFC2411} R.~Thayer, N.~Doraswamy, and R.~Glenn. \newblock {IP} security document roadmap, November 1998. \newblock RFC 2411. \bibitem[WS96]{WS:SSL30} David Wagner and Bruce Schneier. \newblock Analysis of the {SSL} 3.0 protocol. \newblock In {\em The Second {USENIX} Workshop on Electronic Commerce Proceedings}, pages 29--40. USENIX Press, 1996. \newblock Revised version available from {\tt http:/\s www.counterpane.com}. \end{thebibliography} } \appendix \chapter{What we would like to change in IPsec} In this appendix we outline some of the major changes that we would like to see in IPsec. \begin{enumerate} \item Eliminate transport mode. Tunnel mode can provide all necessary functionality. If the reduced bandwidth requirement of transport mode is crucial, it can be achieved by applying a specialized compression to the tunnel payload (using the outer IP header as template). \item Eliminate the AH protocol. ESP can provide the authentication of the inner header in tunnel mode. If authentication of the outer header is required, the authentication of ESP can be extended to cover this as well. Authentication-only communications are provided by selecting the NULL encryption algorithm. \item Always apply authentication to any IPsec processed packet. Encryption without authentication is hardly ever useful. \item Change the order of encryption and authentication. The authentication should be performed on the plaintext, not on the ciphertext. \item Make IPsec SAs bidirectional. \item Improve modularization of IPsec and the IPsec documentation. \item Revise ISAKMP and IKE thoroughly. There are too many problems to be listed individually here. \end{enumerate} \end{document} ( R S T e | "# #F##777778 88"8P88<r===\>m>䥜xoxfHh<HHhSA&HHh<HHh<HHhSA&HHh<HHh<HHh<HHh<HHh<HHh<HHh<HHh<HHh<HHhSA&HHh<HHh<H&.G[op%d[\ ;<M.G[op%d[\ ;<MNefLM|}+,>? ##$$''))D-E- .!.0011113344U7V7778 8 88899999;;;<cMNefLM|}+,>? ##$$$''))D-E- .!.0011113344U7V799999;;;<<<==>>BBCCZC[CDDDDqEyE4F5FJFKFGGGGGJJfNgNRRBSOSTXX\\]]^(_)_befff*f+ffffffhhh i ii{lllllllllmmimjmooooooo pIpKpLpHrIrYrZrurt uuu+uyyzzdm>n>>@@@(A,A:AUAAA@BBC4CXCYCQDDDqEF F3FLLLbMtMMMMeNOOOOO PPxxoHhA&HHhA&HHhA&HHh<HHhA&HHhA&HHh<HHh<HHhA&HHhA&HHhA&HHhA&HHhA&HHh<HHh<HHhA&H(<>>ZC[CDDDD4F5FJFKFGGGGGJJfNgNRRXX\\]]C$PPPP$P4P7PYPiPPPPPPQQQQ"Q/QQ!RMRNRORPR SBSOSPSTSsSvS{SSSSSTTT)TSTTTUT&UNUYUzUUiVqVHh A&HHhA&HHh A&HHh A&HHhA&HHhTA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&H3qVrVVVVVVV'WXXX-Y6YBYOYYY\YU]]`aaa=bDbbbbbbc ccc"c-cRcZc\ccdd@eBeReaefxxHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHh A&HHh A&HHhA&H/](_)_ff*f+ffff i iiimjmKpLpHrIrYrZruruu+uzzklC$ffffffhhhh ikkk{llllllllllllmmhmnnn oooooIpJpqGr}ssttxoHh'A&HHh&A&HHhI[AFHHh%A&HcHdh%A&gHHh$A&HHhH[AFHHh#A&HHhG[AFHHh"A&HHh!A&HHh A&HHhA&HHhTA&HHhA&HHhA&H+ttt uux xx%y&y'y*y1yyyzzD}F}}}}H~M~N~~~~ "j<=>hۂɷxxoxofHhIA&HHhCA&HHh@A&HHhK[AFHHh;A&HHh:A&HHh9A&HHh8A&HHh-A&HHh,A&HHhJ[AFHHh+A&HHh*A&HHh)A&HHh(A&HHhI[AFHHh'A&H(z}~~ikl"#$BC]:dgh!-01GOmp#$%18=>Xx֐אؐېNOTmԕRSǘȘ #-3?Cd"#$BC]gh01ԕRS:;:df@BR]!-/GOmp֐אTɷxxoxof]THhGA&HHhXA&HHhWA&HHhVA&HHhUA&HHhTA&HHhSA&HHhQ[AFHHhNA&HHhEA&HHhP[AFHHhMA&HHhLA&HHhKA&HHhJA&HHh@A&HHhN[AFHHhM[AFHHhCA&H IjmǘȘ ?CUikš9VX|}Ɲǝӝuj~ŤcNxoofHhdA&HHhcA&HHhX[AFHHhbA&HHhaA&HHh^A&HHh\A&HHhW[AFHHhV[AFHHh_A&HHh`A&HHhU[AFHHhYA&HHhXA&HHhGA&HHhVA&HHhFA&H(CUijkšƚʚ՚ښ "TVWYZ[\_`rś9:;vwj~Ť/7HJKOc̥ͥҥNO[v{|(*prd;vwxy#$?pqпѿNO[v{|(*pͩթ:_ɪ?HtvwcŮ)Mcfg,XxHhjA&HHhiA&HHhlA&HHhkA&HHhhA&HHhgA&HHh_[AFHHh^[AFHHh][AFHHhfA&HHhZ[AFHHhY[AFHHhbA&HHhdA&HHheA&H-ͩթ:_ɪʪҪ?HYktvwxycpŮӮ)Mcfgk ,-.3Xΰϰ(-.wx{̱ϱձױرܱ"#$?dΰϰw{"ڴ:M/߽%oȿʿοϿ/xofo]HhA&HHhA&HHhA&HHhA&HHhuA&HHhtA&HHhqA&HHhsA&HHhrA&HHhpA&HHhoA&HHhnA&HHhmA&HHhjA&HHhlA&HHhiA&HHhkA&HHh`[AFH# [(@(NormalCJmH <A@<Default Paragraph Font4Z@4 Plain Text CJOJQJ$/$List h*B* Body Textx<C"<Body Text Indent hx222 Normal Indent(U@A( Hyperlink>*B*!!!!! !        N >&A4AN^Llk{ 1@k  l l w.G[op%d[\ ; < M N D)E) *!*,,----//00U3V3555557778::Z?[?@@@@4B5BJBKBCCCCCFFfJgJNNTTXXYY([)[bb*b+bbbb e eeiijiKlLlHnInYnZnunqq+qvvk{l{{"|#|$|B|C|]|gh01ԑRS:;vwxy$%@qrIJqrHIpqPQtuPQAB|}EF!%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1 %1%1%1%1%1 %1%1%1%1%1%!~!!\#]#m#n######,'-'((**~,,u-v-..g0h01111~334496:69 99996979I9J9::;;;;;<<<<*>+>>>L?M?@@KBLBCCiDjDzD{DDDUEVEtEFFF3K4KEKdn######,'-'((**~,,u-v-..g0h01111~334496:6:69 99996979I9J9::;;;;;<<<<*>+>>>L?M?@@KBKBLBCCiDjDzD{DDDUEVEtEFFF3K4KEKLLMMNNNNNN OEKLLMMNNNNNN O#O0Q1QRRSSSUUVV:X;XZZ:\;\d\S]T]]]^aababbbbb)e*effChDh\hhhhllmm7p8pMpqqJsKssssttvvcxdxyy{{A~B~~~DEUVWr~op!",-d O#O0Q1QRRSSSUUVV:X;XZZ:\;\d\S]T]]]^aababbbbbb)e*effChDh\hhhhllmm7p8pMpqqJsKssssttvvvcxdxyy{{A~B~~~DEUVWr~op!"",-̊͊-.mnVWǏȏ-̊͊-.mnVWǏȏklno֙<>{ǚ/no˛;dlΝ19MNfҞӞ:NOhǟ۟ܟXlm٠ &Bdklno֙<>{ǚ/no˛;;dlΝ19MNfҞӞ:NOhǟǟ۟ܟXlm٠ &Bġܡ%9:Skʢˢġܡ%9:Skʢˢl}  $=~)*Cjѥ f  ;mn`aūƫ֫׫Nl}  $=~)*Cjѥ  f  ;mn`aūƫ֫1%1%1%1%1%1%1%1%1%1%1%1%1%1\V358::Z?@4BNTY([)[b+bbb eeiijiKlunq+qvvk{]|gh0S:xy$rIJIQtuQAB|}!m>PqVfttN/̚!"%')+,FM$<];P n#:6KB Obv";ǟ ֫p $*-./1235678:;<>?@<zC!EK-#&(049=WUnknown Steve Kent Karen SeoBBNBBN.foobar Kim LegelisRichard A. BaronRachel F. Cohen Karen Sirois ssaydjariRobert W. Shirey Ken Theriault Lisa RaphaelBrian A. LaMacchia Steve Lipner Charles Lynn Larry Layten Cori D. PeeleRobert Meushaw Tim McChesneySteven B. Lipnersmw Bob BlakleyJoe Walters, Jr.Deborah MeloneDept. 7B Public MacGTE InternetworkingPreferred Customer Howard GrossGTEIValued Gateway 2000 Customer Gary DeeterKaren Saunders Timothy BowenLisa Di Pietro Jason R. Och Dick LiouIvana R. AbruzzeseShopLink EmployeeKenneth S. GoldmanBrad D. Meehan Mike Shumway Jim SchaadHemma PrafullchandraMelissa A. Milligan Jim DelandeDr. Robert William Shirey Jeff Aliber Peter Hussey Hussey, PeterGEMPLUS CARD INTERNATIONAL Cori Peele Kay PaumierMeryl FranzmanSCCccainLauriault, Simonne Scott AtwellpcainDavid Escalante EscalanteBenjamin J. WoznickBBN Communications Inc.GTE Internetworking. Bill Nelson Mike Kong Andrew Shores Ascend emmAscend Communications UserJoe WhitehouseCascade Aaron BawcomamaguireFrank Maniscalco..Catherine KnikerChristine Silva Brad D Meehan Jim O'ConnorTechnical CorrigendaHoyt L. Kesterson IISBoeyen Rod Lenniger JANET LEBLONDbbnD4M/9>EHRSY\fgmr~&2= L |    . 2 = > A 3?@Iu%*C!T!#,2,>,G,55U:Y:@@{VVhhfnsnnn!t&tuu{!{}}~~LOhuvȘ˘?KLSә֙CE^aӞ֞$' !/1:ɸJM|gpenu}DO/:_behjouvCN;@!      !"#$%&')*+,-./@123456789:;<=>?ABCDEFGHIJT[UVWXw\]^_`bcdefghiklmnostuvx0 [(@(NormalCJmH <A@<Default Paragraph Font4Z@4 Plain Text CJOJQJ$/$List h*B* Body Textx<C"<Body Text Indent hx222 Normal Indent(U@A( Hyperlink>*B*!!!!!! !        N >&A4AN^Llk{ 1@k!  l l w.G[op%d[\ ; < M N D)E) *!*,,----//00U3V355ZXZ&['[\\ccccJdKdldfffjjmmooooorrr x x||}}}}}}}!>jk345U<=ӕԕ#89)xy!"ʾ˾\]PQ$%XYnoZ[de@AcdmnRScdz5557778::Z?[?@@@@4B5BJBKBCCCCCFFfJgJNNTTXXYY([)[bb*b+bbbb e eeiijiKlLlHnInYnZnunqq+qvvk{l{{"|#|$|B|C|]|gh01ԑRS:;vwxy$%@qrIJqrHIpqPQtuPQAB|}EF #%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1 Steve Kent8Hard Disk:Temporary Items:AutoRecovery save of IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex@@@P @߭۰ݰ˻ӻԻLPlmovw/@F!%{'JUZ[LPQ[\cf>JKL[^}wz$,&Br@GL_s1Vy0@10c@1 0i@1111L11 1B1D1H1V1X11Ȑ10@1$1P@11@11111R11 111<11111 111f0@111111$1*1111ґ1ԑ1֑1ؑ1@1111Ē1Ȓ1ʒ1Β1P111Γ1*1Ɨ@0ؘ@111110@1f1l0@11@1*1d1l1v1@111111ć0@10J@0@1111V111L11111R1T1X0@11@11@1ʊ10B@1Z1@1\1@1l0@0n1p0W@0W@GTimes New Roman5O4!Mnh  t   [.-.G[op%d[\ ; < M N D)E) *!*,,----//00U3V3555557778::Z?[?@@@@4B5BJBKBCCCCCFFJJ;P?|}pqDExyz{`ars~%1%stJM%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1 %1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1\V358::Z?@4BFJJ;PPqVfttN/!"%')+,FSM$<];P n#:6KB Obv";ǟ ֫p $*-./1235678:;<>?@<zC!EK-#&(049=WUnknown Steve Kent Karen SeoBBNBBN.foobar Kim LegelisRichard A. BaronRachel F. Cohen Karen Sirois ssaydjariRobert W. Shirey Ken Theriault Lisa RaphaelBrian A. LaMacchia Steve Lipner Charles Lynn Larry Layten Cori D. PeeleRobert Meushaw Tim McChesneySteven B. Lipnersmw Bob BlakleyJoe Walters, Jr.Deborah MeloneDept. 7B Public MacGTE InternetworkingPreferred Customer Howard GrossGTEIValued Gateway 2000 Customer Gary DeeterKaren Saunders Timothy BowenLisa Di Pietro Jason R. Och Dick LiouIvana R. AbruzzeseShopLink EmployeeKenneth S. GoldmanBrad D. Meehan Mike Shumway Jim SchaadHemma PrafullchandraMelissa A. Milligan Jim DelandeDr. Robert William Shirey Jeff Aliber Peter Hussey Hussey, PeterGEMPLUS CARD INTERNATIONAL Cori Peele Kay PaumierMeryl FranzmanSCCccainLauriault, Simonne Scott AtwellpcainDavid Escalante EscalanteBenjamin J. WoznickBBN Communications Inc.GTE Internetworking. Bill Nelson Mike Kong Andrew Shores Ascend emmAscend Communications UserJoe WhitehouseCascade Aaron BawcomamaguireFrank Maniscalco..Catherine KnikerChristine Silva Brad D Meehan Jim O'ConnorTechnical CorrigendaHoyt L. Kesterson IISBoeyen Rod Lenniger JANET LEBLONDbbnD4MK/9>EHRSY\fgmr~&2 = L |    . 2 = > A 3?@Iu%*C!T!#,2,>,G,55U:Y:@@NNW X1j4joop%puuww||~~PS{lpx*-͗З47IL͚̚ԚTWěƛ!{~ߝTW?J˼μir>G?HY]M_':)DTS`eisyM Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve Kent9Hard Disk:Temporary Items:AutoRecovery save of IPsec revi Steve Kent%Hard Disk:IPSEC:IPsec review comments@NN NNEƀC$EƀtdJeJfJkJJJJJJwL}LLLLLLLLLLM M#M,MdMMMMMMM NNNVNWN[NeNjNNNNN;P`a\^LTUrͽѽǾ3MDocumentSummaryInformation8CompObjX0Table(7     [(@(NormalCJmH <A@<Default Paragraph Font4Z@4 Plain Text CJOJQJ$/$List h*B* Body Textx<C"<Body Text Indent hx222 Normal Indent(U@A( Hyperlink>*B*!               i(U5/BQIaFn|ŒGuZ*ypq    w]=>23   -.]^stJKXY#$!!##''h(i(**+++, . .//11 444=4>4364656M688==???=?|@}@@@AA/B0BBBDDIINNgThTXXnYoYZZaaaabbbddd:i;illnn*n+nFnpppYvZv<{={U{{{{||.|89PQqklӐ#$ GHsPQIJfgyȰɰZ[23Z[12YZ9:]^9:*+ef./%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1 %1%1%1%1 %1%1%1%1 %1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1Symbol3 Arial3Times? Courier New"1h?ABCDEFGHIJTNP[QRS{UVWXwZ\]^_`bcdefghiklmnox|}~   [.-.G[op%d[\ ; < M N D)E) *!*,,----//00U3V3555557778::Z?[?@@@@4B5BJBKBCCCCCFFJJ;P?|}pqDExyz{`ars~%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1 %1%1 %1%1%1%1%1%1% Today, transport mode is used primarily to carry L2TP traffic, although this is primarily an efficiency issue. todayA plausible, near-term use for AH is to provide integrity and authenticity for IPsec traffic between an end system and a first-hop intermed01%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1%1%1%1%1 %1%1 %1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1 %1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1.G[op%d\V358::Z?@4BFJJ;PPqVfttN/!"%')+,FM$<];P n#:6KB Obv";ǟ ֫p $*-./1235678:;<>?@<zC!EK-#&(049=WUnknown Steve Kent Karen SeoBBNBBN.foobar Kim LegelisRichard A. BaronRachel F. Cohen Karen Sirois ssaydjariRobert W. Shirey Ken Theriault Lisa RaphaelBrian A. LaMacchia Steve Lipner Charles Lynn Larry Layten Cori D. PeeleRobert Meushaw Tim McChesneySteven B. Lipnersmw Bob BlakleyJoe Walters, Jr.Deborah MeloneDept. 7B Public MacGTE InternetworkingPreferred Customer Howard GrossGTEIValued Gateway 2000 Customer Gary DeeterKaren Saunders Timothy BowenLisa Di Pietro Jason R. Och Dick LiouIvana R. AbruzzeseShopLink EmployeeKenneth S. GoldmanBrad D. Meehan Mike Shumway Jim SchaadHemma PrafullchandraMelissa A. Milligan Jim DelandeDr. Robert William Shirey Jeff Aliber Peter Hussey Hussey, PeterGEMPLUS CARD INTERNATIONAL Cori Peele Kay PaumierMeryl FranzmanSCCccainLauriault, Simonne Scott AtwellpcainDavid Escalante EscalanteBenjamin J. WoznickBBN Communications Inc.GTE Internetworking. Bill Nelson Mike Kong Andrew Shores Ascend emmAscend Communications UserJoe WhitehouseCascade Aaron BawcomamaguireFrank Maniscalco..Catherine KnikerChristine Silva Brad D Meehan Jim O'ConnorTechnical CorrigendaHoyt L. Kesterson IISBoeyen Rod Lenniger JANET LEBLONDbbnD4M!/9>EHRSY\fgmr~&2= L |    . 2 = > A 3?@Iu%*C!T!#,2,>,G,55U:Y:@@{VVhhfnsnnn!t&tuu{!{}}~~LOhuvȘ˘?KLSә֙CE^aӞ֞$' !/1:ɸJM|gpenu}DO/:_behjouvCN# Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex@P 4߭۰ݰ˻ӻԻLPlmovw/@F!%{'JUZ[LPQ[\cf>JKL[^}wz$,&Br@GL_s1Vy !0@10c@1 0i@1111L11 1B1D1H1V1X11Ȑ10@1$1P@11@11111R11 111<11111 111f0@111111$1*1111ґ1ԑ1֑1ؑ1@1111Ē1Ȓ1ʒ1Β1P111Γ1*1Ɨ@0ؘ@111110@1f1l0@11@1m>PqVfttN/8!"%')+,FSM$<];P n#:6KB Obv";ǟ ֫p $*-./1235678:;<>?@<zC!EK-#&(049=WUnknown Steve Kent Karen SeoBBNBBN.foobar Kim LegelisRichard A. BaronRachel F. *1d1l1v1@111111ć0@10J@0@1111V111L11111R1T1X0@11@11@1ʊ10B@1Z1@1\1@1l0@0n1p110W@0W@GTimes New Roman5SymCohen Karen Sirois ssaydjariRobert W. Shirey Ken Theriault Lisa RaphaelBrian A. LaMacchia Steve Lipner Charles Lynn Larry Layten Cori D. PeeleRobert Meushaw Tim McChesneySteven B. Lipnersmw Bob BlakleyJoe Walters, Jr.Deborah MeloneDept. 7B Public MacGTE InternetworkingPreferred Customer Howard GrossGTEIValued Gateway 2000 Customer Gary DeeterKaren Saunders Timothy BowenLisa Di Pietro Jason R. Och Dick LiouIvana R. AbruzzeseShopLink EmployeeKenneth S. GoldmanBrad D. Meehan Mike Shumway Jim 1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1 SchaadHemma PrafullchandraMelissa A. Milligan Jim DelandeDr. Robert William Shirey Jeff Aliber Peter Hussey Hussey, PeterGEMPLUS CARD INTERNATIONAL Cori Peele Kay PaumierMeryl FranzmanSCCccainLauriault, Simonne Scott AtwellpcainDavid Escalante EscalanteBenjamin J. WoznickBBN Communications Inc.GTE Internetworking. Bill Nelson Mike Kong Andrew Shores Ascend emmAscend Communications UserJoe WhitehouseCascade Aaron BawcomamaguireFrank Maniscalco..Catherine KnikerChristine Silva Brad D Meeh%1%1 %1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%1%1%1%1 %1%1%1%1%1%1%1%%1%1%1%1%1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1%1%1%1%1 %1pqпѿ{|mnXYfgRS\]JK$%abst=>U]^)*PQRz  ./yzZ\      ? @      !d/t Qp"%>?zflzU{W۷xHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&H+{|mnXYfgRS\]JK$%abC$B$eQCEI#&H_`moxxoxfHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&HHhA&H& '+AHZrLk $,<lXxof]Hh\AFHHh\AFHHh\AFHHhA&HHh[AFHHh[AFHHh[AFHHh[AFHHh[AFHHhc[AFHHhpA&HHha[AFHHhA&HHhA&HHhA&HHhA&HHhA&HHhA&H st=>U]^)*PPQRz  ./yzZ\      ? @       !~!!\#]#m#n#%1 %1%1%1%1%1%1%1%1 %1%1 %1%1 %1%1 %1%1 %1%1%1%1 %1%1 %1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1%1\V358::Z?@4BFJJ;PPqVfttN/8!"%')+,FSM$<];P n#:6KB Obv";ǟ ֫p $*-./1235678:;<>?@<zCan Jim O'ConnorTechnical CorrigendaHoyt L. Kesterson IISBoeyen Rod Lenniger JANET LEBLONDbbnD4M/9>EHRSY\fgmr~&2= L |    . 2 = > A 3?@Iu%*C!T!#,2,>,G,55֫׫pDC$Eƀ\AF/ =!'"'#$%,SPRFC messages So, the answer here is that the specifications allow site administrators to make security/functionality tradeoffs, locally. The longer term solution described would require routers to implement IPsec, so that they can send authenticated ICMP messages. Yes, this would require a PKI, but such a PKI may arise for other reasons.Ted T'so and I discussed this problem, and tried to explain it to the list, but were unsuccessful. as additional, mandatory defualts [I In a high assurance hardware implementa!EK-#&(049=WUnknown Steve Kent Karen SeoBBNBBN.foobar Kim LegelisRichard A. BaronRachel F. Cohen Karen Sirois ssaydjariRobert W. Shirey Ken Theriault Lisa RaphaelBrian A. LaMacchia Steve Lipner Charles Lynn Larry Layten Cori D. PeeleRobert Meushaw Tim McChesneySteven B. Lipnersmw Bob BlakleyJoe Walters, Jr.Deborah MeloneDept. 7B Public MacGTE InternetworkingPreferred Customer Howard GrossGTEIValued Gateway 2000 Customer Gary DeeterKaren Saunders Timothy BowenLisa Di Pietro Jason R. Och Dick LiouIvana R. AbruzzeseShopLink EmployeeKenneth S. GoldmanBrad D. Meehan Mike Shumway Jim SchaadHemma PrafullchandraMelissa A. Milligan Jim DelandeDr. Robert William Shirey Jeff Aliber Peter Hussey Hussey, PeterGEMPLUS CARD INTERNATIONAL Cori Peele Kay PaumierMeryl FranzmanSCCccainLauriault, Simonne Scott AtwellpcainDavid Escalante EscalanteBenjamin J. WoznickBBN Communications Inc.GTE Internetworking. Bill Nelson Mike Kong Andrew Shores Ascend emmAscend Communications UserJoe WhitehouseCascade Aaron BawcomamaguireFrank Maniscalco..Catherine KnikerChristine Silva Brad D Meehan Jim O'ConnorTechnical CorrigendaHoyt L. Kesterson IISBoeyen Rod Lenniger JANET LEBLONDbbnD4M/9>EHRSY\fgmr~&2= L |    . 2 = > A 3?@Iu%*C!T!#,2,>,G,55U:Y:@@W X1j4joo p-puuw$w||~~X[tx 25՗ؗ<?$' QTȚԚ՚ܚ\_̛Λ")\_$'ì_j&^g_hy}mGZ>I dts Steve KentHard Disk:IPSec.tex Steve KentHard Disk:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve Kent9Hard Disk:Temporary Items:AutoRecovery save of IPsec revi Steve Kent%Hard Disk:IPSEC:IPsec review comments Steve Kent%Hard Disk:IPSEC:IPsec review comments@}}x\}}EƀC$Eƀ| dJeJfJkJJJJJJwL}LLLLLLLLLLM M#M,MdMMMMMMM NNNVNWN[NeNjNNNNN;Pjjjjhidfϴltu о%3457Sm014]zGMN[\]^{&/8:;=~ouvy~b"#$%(,v}xmno?@j{ABCK]^ 5}~0@11111R1d1|0Ȝ@1Μ@1ޞ1@11111111Ο11*1,121D111b1111111$111111161F0Z@0t@11@1"0@10c@1 0i@1.1P1`1b1l11n@0n@1111L11 1B1D1H1V1X11Ȑ10@1$1P@11@11111R11 111<11111 111f0@111111$1*1111ґ1ԑ1֑1ؑ1@1111Ē1Ȓ1ʒ1Β1P111Γ1*1Ɨ@0ؘ@111110@1f111ƨ10@11@1*1d1l1v1@111111ć0@10J@1@0@1111V111L11111R1T1X0@11@11@1ʊ10B@1Z1@1\1@1l0@0n1p111H1J1Ȩ1101161ȣ1أ1 0W@0W@GTimes New Roman5Symbol3 Arial3Times? Courier New"qh<,A1#kh0ddJ]-\documentclass[chapterpage,12pt]{counterpane} Steve Kent Steve Kenttion, the crypto chip would generate the IV.(co-chair of the WG) as suggested in the text for CBC mode ciphers, current IETF parameterization of and so one may see RFCs that specify a variety of additional algorithms!This is . I have not review the ISAKMP/IKE comments.Z\lnċLHȐĒΓ*,V ̚ޞxxof]THhAFHHhAFHHhcdAfHHhbdAfHHhadAfHHh`dAfHHh_dAfHHhYdAfHHhXdAfHHhWdAfHHhUdAfHHhRdAfHHhQdAfHHhPdAfHHhNdAfHHh\AFHHh\AFHHhA&HHh\AFHthe text in the beginning of section 6 is emphasizing that an SA from a router to a host or security gateway, must be a tunnel mode SA, vs. a transport mode SA. If we didn t make this clear, someone might choose to establish a transport mode SA from an intermediate system, and this would cause the source address checks to fail under certain circumstances, as noted by the text.[you re right. Exactly one auditable event in 2406 does not specify the list of data that SHOULD be audited. We ll fix that in the next pass.[there are exactly 3 events defined as auditable in 2401, one of which overlaps with 2406. So, to be more precise, the other 2 auditable events defined in 2401 ought to have the minimum data requirements defined. Another good point that we will fix in the next pass.] I agree that this algorithm spec ought not encourage negotiation of the number of rounds, without specifying a minimum for each cipher, although this gets us into the crypto strength value judgement arena again. Also, the inclusion of 3DES in this table is inappropriate!] as it is a 48 round algorithm, period. So, yes, there is definite room for improvement in this RFC.]edbol3 Arial3Times? Courier New"qhPqVfttN/8!"%')+,FSM$<];P n#:6KB Obv";ǟ ֫p $*-./1235678:;<>?@<zC!EK-#&(049=WUnknown Steve Kent Karen SeoBBNBBN.foobar Kim LegelisRichard A. BaronRachel F. Cohen Karen Sirois ssaydjariRobert W. Shirey Ken Theriault Lisa RaphaelBrian A. LaMacchia Steve Lipner Charles Lynn Larry Layten Cori D. PeeleRobert Meushaw Tim McChesneySteven B. Lipnersmw Bob BlakleyJoe Walters, Jr.Deborah MeloneDept. 7B Public MacGTE InternetworkingPreferred Customer Howard GrossGTEIValued Gateway 2000 Customer Gary DeeterKaren Saunders Timothy BowenLisa Di Pietro Jason R. Och Dick LiouIvana R. AbruzzeseShopLink EmployeeKenneth S. GoldmanBrad D. Meehan Mike Shumway Jim SchaadHemma PrafullchandraMelissa A. Milligan Jim DelandeDr. Robert William Shirey Jeff Aliber Peter Hussey Hussey, PeterGEMPLUS CARD INTERNATIONAL Cori Peele Kayiary. For example, AH can be used between a host inside an enclave and a security gateway at the perimeter, to allow the SG to control what traffic leaves the enclave, without granting the SG access to plaintext traffic. This, and similar concatenated SA examples, motivate retention of AH. One could achieve a similar effect with (authentication-only) ESP tunnels, but with increased bandwidth and processing overhead. However, I agree that this protocol is very complex, the result of incremental enhancement and a reluctance on the part of developers to discard older versions of code.(*,2Db6H.ƨȨ68Hh,AHHh[AFHHh+AHHh*AHHhAFHHhNAFHHhMAFHHhKAFHHhAFHHhAFHHhJAFHHhAFHHhAFH/ =!'"'#$%a checkbut at least one knowledgeable WG member was quite additional, mandatory defut this protocol is very complex. Much of the complexitysU:Y:@@W X1j4joo p-puuw$w||~~X[tx 25՗ؗ<?$' QTȚԚ՚ܚ\_̛Λ")\_$'ì_j&^g_hy}mGZ>I dts Steve KentHard Disk:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve Kent9Hard Disk:Temporary Items:AutoRecovery save of IPsec revi Steve Kent%Hard Disk:IPSEC:IPsec review comments Steve Kent%Hard Disk:IPSEC:IPsec review comments Steve Kent%Hard Disk:IPSEC:IPsec review comments@(jppcHdh1AgHEƀC$Eƀ< .G[op%ddJeJfJkJJJJJJwL}LLLLLLLLLLM M#M,MdMMMMMMM NNNVNWN[NeNjNNNNN;Pjjjjhidfϴltu о%3457Sm014]zGMN[\]^{&/8:;=~ouvy~b"#$%(,v}xmno?@j{ABCK]^ 5}~0@0\@0@0@0@0@0@0 @0N @0 @0 @0J @0 @06 @08 @0Z @0p @11111R1d1|0Ȝ@1Μ@1ޞ1@11111111Ο11*1,121D111b1111111$111111161F0Z@0t@11@1"0@10c@1 0i@1.1P1`1b1l11n@0n@1111L11 1B1D1H1V1X11Ȑ10@1$1P@11@11111R11 111<11111 111f0@111111$1*1111ґ1ԑ1֑1ؑ1@1111Ē1Ȓ1ʒ1Β1P111Γ1*1Ɨ@0ؘ@111110@1f111ƨ10@11@1*1d1l1v1@111111ć0@10J@1@0@1111V111L11111R1T1X0@11@11@1ʊ10B@1Z1@1\1@1l0@0n1p111H1J1Ȩ1101161ȣ1أ1 0W@0W@GTimes New Roman5Symbol3 Arial3Times? Courier New"qh<1A2#kh0d]-\documentclass[chapterpage,12pt]{counterpane} Steve Kent Steve KentDocumentSummaryInformation8CompObjX0Table(7=Z'-.;<=>[^OUVY^sB_chq VXMNOx J[!"#+=>stIJK0@11111R1d1|0Ȝ@1Μ@1ޞ1@11111111Ο11*1,121D111b1111111$111111161F0Z@0t@10c@1 0i@1111L11 1B1D1H1V1X11Ȑ10@1$1P@11@11111R11 111<11111 111f0@111111$1*1111ґ1ԑ1֑1ؑ1@1111Ē1Ȓ1ʒ1Β1P111Γ1*1Ɨ@0ؘ@111110@1f1l0@11@1*1d1l1v1@111111ć0@10J@0@1111V111L11111R1T1X0@11@11@1ʊ10B@1Z1@1\1@1l0@0n1p111H1J1أ1 0W@0W@GTimes New Roman5Symbol3 Arial3Times? Courier New"qh _PID_GUID'AN{B204C100-B46C-11D3-BFDF-000502852F29} Oh+'0 $ @ L Xdlt|'.\documentclass[chapterpage,12pt]{counterpane}.0doc Steve KentatevNormale Steve Kenta50vMicrosoft Word 8.0t@v6@ډeH@ Ed#ks jbjb kk]jlllll+nd |9{m*Ɏ͎͎͎͎͎͎͎ۖݖݖݖݖݖݖ, d l͎͎͎͎͎ ll͎͎Qx ͎l͎l͎ۖlsmllll͎ۖHۖllۖTv{.ۖ\documentclass[chapterpage,12pt]{counterpane} \usepackage[T1]{fontenc} \usepackage{xspace} \usepackage{epsfig} %\raggedbottom \title{A Security Evaluation of IPsec} \author{Niels Ferguson and Bruce Schneier} \contactemail{\{niels,schneier\}@counterpane.com} \purpose{Technical report 99-13} \documentdate{1999/02/27} % Beth, this date format is correct. % The style sheet converts it to something nicer. \begin{document} \maketitle \chapter*{Executive summary} IPsec is a set of protocols that provides communication security for computers using IP-based communication networks. It provides authentication and confidentiality services on a packet level. To support the IPsec security, a key management protocol called ISAKMP is used. ISAKMP uses public-key cryptographic techniques to set up keys between the different parties to be used with IPsec. Both IPsec and ISAKMP are too complex. [a protocol is too complex only relative to a specified set of requirements that are satisfied by a simpler protocol. To substantiate this observation, one ought to define the requirements that one believes the protocol is trying top satisfy, and then offer a simpler protocol.] This high complexity leads to errors. We have found security flaws in both IPsec and ISAKMP, and expect that there are many more. We expect any actual implementation to contain many more errors, some of which will cause security weaknesses. These protocols give the impression of having been designed by a committee: they try to be everything for everybody at the cost of complexity. For normal standards, that is bad enough; for security systems, it is catastrophic. In our opinion, the complexity of both IPsec and ISAKMP can be reduced by a large factor without a significant loss of functionality. IPsec is in better shape than ISAKMP. The description and definitions are reasonably clear. A careful implementation of IPsec can achieve a good level of security. Unfortunately, IPsec by itself is not a very useful protocol. Use on a large scale requires the key management functions of ISAKMP. [while I would tend to agree with this observation, I should note that a non-trivial number of IPsec implementations, used in constrained contexts, are manually keyed.] ISAKMP is currently not in a suitable state for implementation. Major work will be required to get it to that point. There are many security-critical errors, as well as many unnecessary cross-dependencies within the protocol. These should all be eliminated before a new evaluation is done. Based on our analysis, we recommend that IPsec and ISAKMP not be used for confidential information. At the moment we cannot recommend a direct alternative. Some applications might be able to use SSL \cite{SSLv3Nov96}, which in our opinion is a much better protocol that provides a much higher level of security when used appropriately. \tableofcontents \chapter{Introduction} At the request of NSA, Counterpane has conducted a security review of the IPsec and ISAKMP security protocols. This evaluation is based on RFCs 2401--241 PaumierMeryl FranzmanSCCccainLauriault, Simonne Scott AtwellpcainDavid Escalante EscalanteBenjamin J. WoznickBBN Communications Inc.GTE Internetworking. Bill Nelson Mike Kong Andrew Shores Ascend emmAscend Communications UserJoe WhitehouseCascade Aaron BawcomamaguireFrank Maniscalco..Catherine KnikerChristine Silva Brad D Meehan Jim O'ConnorTechnical CorrigendaHoyt L. Kesterson IISBoeyen Rod Lenniger JANET LEBLONDbbnD4M ^ ` a v z COP\{ &O[amfrk*z***24;488-?;?DVTVyh|h7nDnhnunssguluzz||~~˅υTX`cȒՒz} 9FloGT$jq˛Λ/2lo 36enPYNW-8#HKNQSX^_,7 Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve KentMacintosh HD:IPSec.tex Steve Kent9Hard Disk:Temporary Items:AutoRecovery save of IPsec revi Steve Kent%Hard Disk:IPSEC:IPsec review comments Steve Kent%Hard Disk:IPSEC:IPsec review comments Steve Kent%Hard Disk:IPSEC:IPsec review comments Steve Kent%Hard Disk:IPSEC:IPsec review comments@ .(jEƀC$Eƀ| HHHHHHHIIJJJJJKKK#K9KGKgKhKkKtKKKLL'L.L0LQL[LdLLLLLLLLLLNii1i7i(016@I\ڻ59UVX_`)/ dm{|}3>CDxy|59:DELO'nw345DGabcf`cjklmpt +[)05H\?b 1QT[\d}0p @11111R1d1|0Ȝ@1Μ@1ޞ1@11111111Ο11*1,121D111b1111111$111111161F0Z@0t@11@1"0@10c@1 0i@1.1P1`1b1l11n@0n@1111L11 1B1D1H1V1X11Ȑ10@1$1P@11@11111R11 111<11111 111f0@111111$1*1111ґ1ԑ1֑1ؑ1@1111Ē1Ȓ1ʒ1Β1P111Γ1*1Ɨ@0ؘ@111110@1f111ƨ10@11@1*1d1l1v1@111111ć0@10J@1@0@1111V111L11111R1T1X0@11@11@1ʊ10B@1Z1@1\1@1l0@0n1p111H1J1Ȩ1101161ȣ1أ1 0W@0W@GTimes New Roman5Symbol3 Arial3Times? Courier New"qh<2A3#kh0d]-\documentclass[chapterpage,12pt]{counterpane} Steve Kent Steve Kent FMicrosoft Word DocumentNB6WWord.Document.8 ՜.+,D՜.+,h$ hp  'BBN Technologiessshb .\documentclass[chapterpage,12pt]{counterpane} Title 6> _PID_GUID'AN{B204C100-B46C-11D3-BFDF-000502852F29} Oh+'0 $ @ L Xdlt|'.\documentclass[chapterpage,12pt]{counterpane}.0doc Steve KentatevNormale Steve Kenta51vMicrosoft Word 8.0t@ 7@ډeH@4hd#ks jbjb kk]>dpppp|5*|######## + + + + + + +,688+ #####8+'##x '''### +# +'l' + +Tp' +\documentclass[chapterpage,12pt]{counterpane} \usepackage[T1]{fontenc} \usepackage{xspace} \usepackage{epsfig} %\raggedbottom \title{A Security Evaluation of IPsec} \author{Niels Ferguson and Bruce Schneier} \contactemail{\{niels,schneier\}@counterpane.com} \purpose{Technical report 99-13} \documentdate{1999/02/27} % Beth, this date format is correct. % The style sheet converts it to something nicer. \begin{document} \maketitle \chapter*{Executive summary} IPsec is a set of protocols that provides communication security for computers using IP-based communication networks. It provides authentication and confidentiality services on a packet level. To support the IPsec security, a key management protocol called ISAKMP is used. ISAKMP uses public-key cryptographic techniques to set up keys between the different parties to be used with IPsec. Both IPsec and ISAKMP are too complex. [a protocol is too complex only relative to a specified set of requirements that are satisfied by a simpler protocol. To substantiate this observation, one ought to define the requirements that one believes the protocol is trying top satisfy, and then offer a simpler protocol.] This high complexity leads to errors. We have found security flaws in both IPsec and ISAKMP, and expect that there are many more. We expect any actual implementation to contain many more errors, some of which will cause security weaknesses. These protocols give the impression of having been designed by a committee: they try to be everything for everybody at the cost of complexity. For normal standards, that is bad enough; for security systems, it is catastrophic. In our opinion, the complexity of both IPsec and ISAKMP can be reduced by a large factor without a significant loss of functionality. IPsec is in better shape than ISAKMP. The description and definitions are reasonably clear. A careful implementation of IPsec can achieve a good level of security. Unfortunately, IPsec by itself is not a very useful protocol. Use on a large scale requires the key management functions of ISAKMP. [while I would tend to agree with this observation, I should note that a non-trivial number of IPsec implementations, used in constrained contexts, are manually keyed.] ISAKMP is currently not in a suitable state for implementation. Major work will be required to get it to that point. There are many security-critical errors, as well as many unnecessary cross-dependencies within the protocol. These should all be eliminated before a new evaluation is done. Based on our analysis, we recommend that IPsec and ISAKMP not be used for confidential information. At the moment we cannot recommend a direct alternative. Some applications might be able to use SSL \cite{SSLv3Nov96}, which in our opinion is a much better protocol that provides a much higher level of security when used appropriately. \tableofcontents \chapter{Introduction} At the request of NSA, Counterpane has conducted a security review of the IPsec and ISAKMP security protocols. This evaluation is based on RFCs 2401--241