Comments on the IPSEC Internet drafts.

["Phillip M. Hallam-Baker" <[e-mail]>]

Comments on the IPSEC Internet drafts.

Dr Phillip M. Hallam-Baker
World Wide Web Consortium

This document is available as hypertext at the following URL:
http://www.w3.org/hypertext/WWW/Security/ipsec_comments.html

This is in response to the call for comments on the following internet draft
proposals:

draft-ietf-ipsec-arch-02.txt, draft-ietf-ipsec-auth-02.txt,
draft-ietf-ipsec-esp-01.txt, draft-ietf-ipsec-ah-md5-03.txt,
draft-ietf-ipsec-esp-des-cbc-04.txt

Executive summary

I believe that these documents require further work before they are ready
for adoption as proposed standards. The documents as currently written
define a framework that is insufficiently generic.

Introduction

This response was in art stimulated by comments made by Phil Rogaway in his
note: draft-rogaway-ipsec-comments-00.txt

It is worth noting in passing that ASCII text is a sub-optimal means of
expressing cryptographic systems. The ambiguity of natural language renders
it a cumbersome notation for what are essentially mathematical concepts.
Many of the problems with the drafts would almost certainly had been
rectified at an earlier stage if the means of expression had permitted a
more rigorously algebraic approach. Natural language encourages reference to
specific examples rather than concentration on the high level abstractions
crucial to the task.

Conspicuously lacking from the standards documents is a grounding of the
concepts in a well developed formalism such as the specification languages Z
or VDM. It is to be hoped that future standards development will recognize
the significant advantages that a well chosen and appropriate notation for
discourse provides and that plain ASCII text alone is not such a notation.
If ASCII text does not permit adequate expression of such notations that
should be considered a reason to consider another form of notation and not a
reason not to employ such an analysis.

Use of a message digest function for authenticity checking.

The specifications auth-02 and ah-md5-03 imply that a message digest
function should be used to ensure authenticity. This makes two questionable
assumptions. First that such a use is an appropriate use of a digest
function and second that digest functions are appropriate for this task.

A message digest is a function of a single variable, a keyed digest is a
function of two variables. It is clearly undesirable to confuse the two.

The use of a digest function and a shared secret to produce a symmetric key
secret function is a relatively new concept, one that has received little
attention in the literature. Most cryptographic digest functions have been
designed as an adjunct to a public key signature scheme. Such use makes
flaws such as a possibility of an extension attack unimportant. When
applying a cryptographic component designed with one purpose in mind for a
different purpose careful evaluation of the new requirements is essential.

Even if a mode of use of a message digest function has the necessary
properties for security it does not follow that such use is appropriate. It
is probable that an algorithm specifically designed for the purpose of
ensuring authenticity would be more satisfactory.

The construction of a keyed digest function from cryptographic primitives
such as hash functions and ciphers is in general concerned with preventing
the exploitation of specific weaknesses in specific algorithms. As a
consequence it is not useful to separate consideration of the underlying
hash function from the mode of operation employed to construct a keyed
digest function.

It is therefore considered undesirable to specify modes of operation for
cryptographic primitives in a manner analogous to DES. Although such a
modular approach would be of assistance in building libraries the security
of M1(H1) and M2(H2) does not imply the security of M1(H2) or M2(H1).

On the specific keyed digest mechanism proposed

There is at present no known attack against MD5 which renders it unsuitable
for keyed digest use. It is however susceptible to two specific forms of
attack, an extension attack and an attack on the internal compressor
function which may be used to synthesize collisions. In such circumstances a
decision to base IP security on a theoretically untested mode of operation
of this specific algorithm might be considered a brave step.

Alternative keyed digest algorithms.

I do not propose to suggest an alternative keyed digest algorithm within the
timeframe for responses to the standards documents nor even to provide a
complete statement of requirements for such an algorithm. I believe however
that it is better that it is better to mention no keyed digest mechanism in
the architectural documents at the present time rather than mandate all
implementations to implement an algorithm that has at best no strong
foundations in the proposed mode of usage and at worst may be suspect.

It is clearly desirable that a keyed digest function be resistant to
extension attacks and have no known weaknesses such as the MD5 compressor
function attack. Additionally it is desirable that the key be involved in
the calculation process throughout the digest process. This may be
considered an aesthetic requirement, that the calculation process should be
symmetric involving commensurate calculations on both inputs.

Proposal:

The IPSEC architecture should be phrased in terms of a fast symmetric key
signature mechanism rather than assume that a generic hash function should
be employed for this purpose.

This proposal corresponds to a strong endorsement of Rogaway's
recommendation number 5.

Encryption of known plaintext.

Cryptanalysis using known or chosen plaintext is considerably easier than
direct attack. Encryption of known headers is thus clearly undesirable since
it provides a direct route to formation of a known plaintext attack and may
open a route to construction of a chosen plaintext attack.

A specific form of attack must be considered which exploits weaknesses in
multiple cryptographic components. If for example a system employed related
keys to ensure encryption and authenticity a chosen plaintext attack on the
privacy component might provide information to compromise the authenticity
mechanism.

Proposal:

Encryption of known headers should be prohibited.

This proposal corresponds to a strengthening of Rogaway's recommendation
number 3.

Encryption of message digests.

The encryption of message digest functions of encrypted text should be
considered undesirable. Consider the difficulty of solving the the following
constraint set for m:

   *  e = E (k, m)
   *  d = E (k, H(m))

Compared to the difficulty of solving for m in the following case:

   *  e = E (k, m)
   *  d = H (E (k, m))

In the first case we have two independent equations in m. In the second only
one. It is possible therefore for the second mode of operation to provide
unconditional security in certain situations (e.g. m is an unknown genuinely
random value fewer bits in length than the key) whereas this is not possible
in the first case.

Proposal:

It is proposed that the scope of any digest function should encompass the
encrypted text and not vice versa.

This proposal corresponds to a strengthening of Rogaway's recomendation
number 4.

Key sizes

A limitation of key sizes to 64 bits may be considered in future to be the
cryptographic equivalent of the original Arpanet decision to limit addresses
to 32 bits.

I concur with Rogaway's proposal that the key sizes of at least 128 bits
should be permitted. I prefer Rivest's proposal that key sizes should be
arbitrary or subject to a generous limit.

Attack model

It is important that the security assurances of the system be understood.
Two tools for analyzing such assurances are threat trees and constraint
networks. It is strongly advised that such analysis be performed.

The construction of threat trees from a taxonomy of risks is a well
established technique for constructing an attack model for a system. Such an
analysis has been of great assistance to the author in consideration of
transaction level protocols.

A common reason for failure of cryptographic systems is the creation of
unintended correlations between components which although individually
secure fail in particular combinations. An example of this being the DES-CBC
TIC mode in PM. Such unintended correlations may often be uncovered by
construction of constraint networks corresponding to the data structures and
algorithms employed. Such an analysis is most effective if subjected to
automated verification.

Summary of proposals.

   * Eliminate references to message digest functions where a keyed digest
     usage is actually intended.
   * Do not encrypt known headers.
   * Do not specify public constraints on encrypted objects, specifically do
     not incorporate message digests of message plaintext even if these are
     encrypted.
   * Allow arbitrary key sizes.
   * A comprehensive attack model consisting of as a minimum threat tree and
     constraint network analysis should be compiled.

In addition it is strongly recommended that even if IETF procedures insist
on the precedence of ASCII text renditions of specification documents that a
document detailing the architecture in algebraic terms be compiled.