[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some comments on IPSEC proposals
To: IPSEC Community, IESG
(iesg@cnri.reston.va.us, ietf@cnri.reston.va.us, ipsec@ans.net)
From: Ronald L. Rivest
Date: June 30, 1995
Re: Comments on IPSEC Internet Drafts
This is response to the call for comments on the following documents,
which are proposed for consideration as Proposed Standards:
[SA] Security Architecture for the Internet Protocol
<draft-ietf-ipsec-arch-02.txt>
[AH] IP Authentication Header
<draft-ietf-ipsec-auth-02.txt>
[AHMD] IP Authentication using Keyed MD5
<draft-ietf-ipsec-ah-md5-03.txt>
[ESP] IP Encapsulating Security Payload (ESP)
<draft-ietf-ipsec-esp-01.txt>
[ESPDES] The ESP DES-CBC Transform
<draft-ietf-ipsec-esp-des-cbc-04.txt>
0. EXECUTIVE SUMMARY
I believe these documents are in need of significant further work
before they are ready for adoption as proposed standards.
1. INTRODUCTION
These documents propose techniques for securing network communications
at the IP layer. The first gives a general overview of the proposed
security architecture. The next two discuss the use of authentication
headers to authenticate IP packets. The last two discuss methods for
achieving confidentiality (and authentication) of IP packets. This
note will critique these documents collectively, emphasizing the areas
where I believe further work is needed, rather than discussing areas
that are already well done.
Since I have not actively followed the dialogue leading up to these
proposals, and am not an expert at IP/Internet protocols, some of my
concerns may reflect my own ignorance of the context or intent of
these proposals. If so, this may be an indication of where these
documents should be improved, without necessarily changing the
proposals themselves.
I was stimulated in part to provide these comments by Phil Rogaway's note:
[ROG] Problems with Proposed IP Cryptography
<draft-rogaway-ipsec-comments-00.txt>
Some of my comments will be based on Phil Rogaway's excellent critique.
I have also found the following excellent document very relevant and
interesting:
[PO] MDx-MAC and Building Fast MACs from Hash Functions
by Bart Preeneel and Paul C. van Oorschot
available by ftp from K.U.Leuven:
ftp server: ftp.esat.kuleuven.ac.be
directory: pub/COSIC/preneel
file: mdxmac_crypto95.ps
2. DISCUSSION OF PHIL ROGAWAY'S COMMENTS
I begin by reviewing Phil Rogaway's comments.
2.1 "AUTHENTICITY = INTEGRITY" [cf ROG 1.]
I agree entirely with Phil here; the distinction between message authenticity
and message integrity is vacuous here, and the proposed documents should be
rewritten to use just a single term (message authenticity) for this notion.
(I support Phil's recommendation 1.)
2.2 "ENCRYPTION DOES NOT GUARANTEE INTEGRITY" [cf ROG 2.]
Again, Phil is on target here. The proposed documents have a confused
and ambiguous discussion as to how authenticity is to be achieved. The
confidentiality and authenticity techniques should be cleanly separated
orthogonal mechanisms.
(I strongly support Phil's recommendation 2.)
2.3. "IT IS WORTHLESS TO ENCRYPT KNOWN HEADERS" [cf ROG 3.]
Here Phil recommends (his recommendation 3) that the encryption of
known headers should be forbidden, on the grounds that AH, and not ESP,
should be used for authenticity. I agree.
(I support Phil's recommendation 3.)
2.4 "DON'T ENCRYPT MESSAGE AUTHENTICATION CODES" [cf ROG 4.]
Although it is not uncommon to encrypt MACs, Phil is exhibiting excellent
taste by suggesting that the scope of the authentication header should
include the encrypted packet, rather than vice versa. While I don't know
of any security weaknesses from the proposed organization, Phil's suggestion
is cleaner and preferable.
(I support Phil's recommendation 4.)
2.5 "DEFINE TRANSFORMS GENERICALLY" [cf ROG 5.]
This recommendation is just common sense in support of better modularity
in the description of what is being proposed.
(I support Phil's recommendation 5.)
2.6 "MANDATE HARDWARE-EFFICIENT *AND* SOFTWARE-EFFICIENT TRANSFORMS"[cf ROG 6.]
Efficiency is clearly an important issue when we are talking about
operations that affect potentially every packet on the Internet.
I think that the main point here is that there should be considerable
freedom to choose alternative encryption techniques.
(I have no problem with Phil's recommendation 6.)
2.7 "USE 128-BIT KEYS" [cf ROG 7]
The key sizes should either be totally arbitrary (perhaps up to some
generous limit, such as 4096 bits), at the user's discretion, or else
be fixed at 128 bits as Phil proposes. I prefer the former approach,
as it provides flexibility that may be necessary to accomodate
different algorithms or other considerations (such as export control).
(I think that the key sizes should be at the user's discretion.)
2.8 "THE MAC MECHANISM" [cf ROG 8]
I begin by noting that Burt Kaliski and Matt Robshaw have written an
excellent article that is relevant:
"Message Authentication with MD5"
by Burt Kaliski and Matt Robshaw
CRYPTOBYTES, vol 1, number 1 (spring 1995), pages 5--8.
(available from the authors at burt@rsa.com or matt@rsa.com)
Phil criticizes the proposed use of MD5 as a MAC mechanism for:
(1) being too slow,
(2) having no theoretical foundations for the proposed mode of use
of MD5.
(3) having no manifest parallelism in the design of MD5.
Unfortunately, at this point in time we faced with choosing from what
is available. Phil proposes an excellent direction in his recommendation
8, but this is still research, not something that is ready for standardization.
Phil says he is working on something, and this may turn out to be a better
proposal than the current MD5 proposal. I have also been thinking about
new hash function designs that might provide superior performance. However,
at this point in time there are no concrete alternatives on the table.
Keyed-MD5 may be a plausible choice at the current instant, but we should be
prepared for the fact that in the very near future we may see
significantly better alternatives proposed and sufficiently evaluated
to be considered as replacements. (Also, the use of hash functions
with more than 128 bits of output may become routine good practice.)
There may be some confusion as to whether the current proposal is
(1) MAC_a(x) = MD5(MD5(x).a) or
(2) MAC_a(x) = MD5(a.x.a)
Phil seems to say that the current proposal is (1), whereas [AH] says
that it is (2); I believe Phil's comment here is based on an earlier
proposal.
The general question of how to best design a (keyed-)MAC from a
one-way hash function is still quite open, and under vigorous
research. The paper [PO] provides some excellent discussion and
analysis of the proposed methods (1) and (2), among others. I think
that our understanding of this area is likely to improve significantly
in the very near term. The best solution in the end is likely to be
an approach one that is designed to be a keyed-MAC from the start. We
are still at the early stages of understanding how to do this, but I
think that efficient and workable proposals may arise very quickly
from the crypto community, now that attention has been drawn to this
issue.
(I think Phil's recommendation 8 is an excellent goal; but it doesn't
answer the question as to what one should do something immediately,
or if one should do something immediately.)
The best approach may be not to commit to a keyed-MAC function at this
time, but rather to explicitly nominate a "straw-man" proposal that is
obviously weak and which MUST clearly be replaced at a later date (but
soon!) when we know a little more. The straw-man algorithm could be
used in trial implementations for testing purposes, but would provide
no real authentication. For example, choosing as a straw-man
algorithm MD5 with NO key input would be such a straw-man algorithm.
This can be used as a place-holder until there is a better consensus
in the cryptographic community as to how to proceed with a
(keyed-)MAC. I believe that such an approach is better than
nominating one of the current proposals (e.g. (2) above) as a
"straw-man", since there might then be too much pressure to leave it
in place, even if it turned out to have significant deficiencies under
further analysis (such as is begun with [PO].) Having an explicitly
weak "straw-man standard" in place as an acknowledgement that we are
not really sure yet of what we are doing will put intense pressure on
the crypto community to get its act together on this matter quickly,
and I would hope that within six to eighteen months a consensus will
evolve (so this issue could be resolved during '96 at the latest).
The current workings of the ipsec community have generally been
outside the purview of much of the crypto community, although a few
cryptographers have paid attention to ipsec issues and have
contributed generously of their time. The straw-man proposal would
provide a very high-profile challenge that there is a still a felt
need for efficient, secure, keyed-MACs for standardization purposes.
2.9 "THE ENCRYPTION MECHANISM" [cf ROG 9]
Phil suggests that "at this point, it may be irresponsible for any NEW
proposal to specify DES in a mode of operation which is susceptible to
2**56 complexity key-exhaustion." I agree. The proposal to use triple-DES
in a mode that is potentially compatible with single-DES (due originally,
I believe, to Walt Tuchman), can satisfy those users who want the efficiency
(and security) of single-DES.
(I agree with Phil's recommendation number 9.)
Phil also criticizes the proposal for lack of specificity in describing
how the DES-CBC is to be performed. I think that his comments here are
well-motivated.
(I agree with Phil's recommendation number 10, although I think that this
is a minor point.)
3. ADDITONAL COMMENTS AND DISCUSSION
I give here some additional comments, in no particular order. Some of these
may reflect real concern about the security or feasibility of the proposed
schemes, whereas others may merely reflect my misunderstanding of the
proposal. Some of these comments may repeat themes already addressed
above.
3.1 KEY DISTRIBUTION / KEY AGREEMENT
These proposals are incomplete and essentially unusable without at
least one specific proposal for non-manual key distribution or key
agreement. While individual parties can clearly set up ad-hoc
mechanism for key distribution or key agreement, the proposals studied
here are not going to have any widespread deployment or utility until
some standards for key distribution or key agreement are also available.
While there is some discussion of this issue in [SA], there is nothing
yet usable provided in terms of a proposal for a standard.
I think that the current proposals should be held in abeyance (and worked on)
until a complete package including key distribution and/or key agreement
is also ready for consideration; I see little harm, and much potential
good, in doing so.
3.2 LACK OF SPECIFICITY OR CLARITY
There are many places where the proposals are insufficiently clear about
what is intended, so much so that an implementor can not proceed. Here
is a small list of items I noticed. (This is not intended to be comprehensive.)
[SA]
p 6: "SHOULD let that SPI become stale..."
(when is an SPI stale?)
[AH]
(page 6) It is recommended here and in other
places [e.g. AHMD p. 1] to use "pseudo-random" values
(here for the SPI, in AHMD for the authentication key).
How is a user to pick a "pseudo-random" value? Are
counters suitable for the SPI? Is a linear-congruential generator
suitable?
(page 7-8) "This requirement is placed in order to allow for
future IP optional headers which the receiver might not know about
but the sender necessarily knows about if it is including such
options in the packet." (I have no idea what this means.)
[AHMD]
[ESP]
(page 6) "If strict red/black separation is being enforced..."
(This term needs a reference or a definition.)
(page 7) "If no key exists for this session or the attempt to
decrypt fails,"
It is not clear what it means for the decryption to fail.
The authors seem to imply that the it means that the next
layer of protocol has a problem with the decrypted text, which
is, in my opinion, a poor choice. I think that the only reason
decryption should "fail" is that decryption is impossible
(e.g. the ciphertext is not a multiple of the cipher block
size). Authentication failure should be used to detect all
other problems.
(page 8) If user-oriented keying is not in use..."
This paragraph makes no sense to me. It should be elaborated.
What is the attack that is being prevented here?
[ESPDES]
(page 3) "The session key SHOULD be changed at least as frequently
as every 2**32 datagrams."
What is the justification for this condition? What attack
is being prevented here?
(page 3) "This field is considered to be transparent, though most
users will not be able to make sense of its contents."
This sentence pretends to be transparent, but this reader could
not make sense of its contents.
3.3 HOST-ORIENTED vs USER-ORIENTED KEYING
In [SA, section 4.4] it is stated that "support for user-oriented keying
SHOULD be present in all IP implementations".
Since "users" as such are not named principals at the IP protocol level,
we are getting into strange territory here.
It is not clear what "support for user-oriented keying" means. Does
this merely mean that each user can be associated with a separate SPI,
or does it mean that the host system must support secure multi-user
processing somehow (e.g., so one user can not read another user's key
by probing memory addresses assigned to the other user)? If I send
encrypted traffice to an SPI that is associated with a particular
user, what am I guaranteed about the security of that traffic from other
users on the same host as the receiver? If nothing is guaranteed, why
have this feature?
The entire discussion on user-oriented keying seems confused (or at least
confusing). This capability ought to be more carefully described, or
dropped. I'm tempted to recommend just dropping it.
More broadly, these documents need to have a clearer philosophical position
as to what their goals are. In particular, these documents should make it
clear how what they are doing differs from security protocols that work
at higher layers of the protocol stack. It would seem sensible to think
that a protocol at this IP layer should ONLY worry about security between
hosts, and let protocols at higher layers take care of security between
end-users or their applications. Bringing in users and userids to this
protocol risks great confusion and muddled systems.
3.4 USE OF MD5
The language in [AH, section 4] says "If a block-oriented authentication
algorithm (e.g. MD5 or MD4) is in use and the IP packet is not an integral
number of blocks, the authentication data calculation is performed using
zero bytes at the end to pad the length out to an integral number of blocks
[Riv92]."
This is VERY confused, since MD5 (and MD4) are byte-oriented algorithms
that are specified to normally take variable-length byte-strings as input.
It is not necessary (and may even be dangerous) for the user to supply his
own padding!
3.5 AUDIT LOGS
In [AH, page 9] and other places, it is stated that the system "MUST
record the authentication failure in the system log or audit log."
Given the rate at which bad packets can be delivered to a system by a
malicious adversary, it may not be too hard for the adversary to fill
up the disk of a complying implementation with the audit log. I think
the "MUST" should be downgraded to "SHOULD".
4. CONCLUSIONS
I feel that the proposed protocols are not sufficiently worked out to
allow proceedings with them as a proposed standard.
Ronald L. Rivest
Room 324
545 Technology Square
Cambridge, MA 02139
617-646-0504
http://theory.lcs.mit.edu/~rivest
rivest@theory.lcs.mit.edu
Follow-Ups: