[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF Draft for ESP with stream ciphers
In article <2.2.32.19960421223444.006e30f8@ktik0.ethz.ch> Germanno wrote:
>some time ago, Marcel (Waldvogel) and I have submitted an internet draft,
>which gives a proposal on how 'Encapsulated Security Payload' can be
>implemented for stream ciphers, at the same time offering mechanisms for
>replay protection.
>
>Now we would be very interested in the opinion of the IPSEC working group,
>and possible other readers. Is 'esp-stream' of interest?
The main issue with the current draft is that it does not specify a
particular stream algorithm. An ESP transform MUST specify a particular
algorithm as part of the transform so that when key management negotiates
use of that transform, both sides know which algorithm to use.
So perhaps my fundamental request is that this be edited into a transform
for a specific algorithm or possibly for two specific algorithms (with some
note that each algorithm would need its own "transform identifier" for key
management use.
It is NOT the case that the current spec works for all stream algorithms,
for example the "Stream Offset" as currently defined will not work when
more than 64 bits of crypto-sync are needed for some algorithm. While
algorithm-independence is important for the base AH and ESP specs, it
should not be a goal for a transform document since transform documents are
supposed to specify how to use a single particular crypto algorithm with AH
or ESP.
>What do the members and chairs think about the fitness of this document?
As an ordinary person, my take on this is that it has limited applicability
and should probably become an Experimental RFC or Informational RFC. I do
not know the patent status of SEAL in various countries, but IETF practice
is to avoid standardising patented techniques when unpatented techniques
(e.g. DES CFB) exist.
Given the existence of fairly fast DES code (e.g. Karn's i386 assembly) and
commercial high-speed DES chips, I'm not sure that this particular tradeoff
of speed for less security is one that I'd be making.
I would want MD5 (or equivalent) integrity/authentication to be added to
the transform because we know that strong integrity/authentication is
needed to obtain commercial-grade security. I'm aware of MD5 code in
software that does better than OC-3 rate now on a commercial 64-bit RISC
processor. I'm also aware of MD5 hardware that is well above OC-3 rates.
In general, I do not agree with all of the conclusions of RFC-1810 because
of private discussions I've had with employees of National Semiconductor
(these discussions actually date back prior to my arrival at cisco).
>If it is relevant, perhaps we could move it into the 'draft-ietf-ipsec-*'
>name domain?
Only if the WG decides it should be a standards-track document. It is not
yet clear to me that there is anything like consensus that this draft
should be on the standards-track.
I've been told from above that we should not be standardising any transform
that is vulnerable to published attacks. The WG in LA made it clear that
RFC-1828 and RFC-1829 should be replaced-on-the-standards-track with new
transforms having improved security properties. So I'd view addition of
MD5 (or similar, SHA would be fine with me personally) integrity/
authentication to be needed before this draft goes anywhere.
Ran
rja@cisco.com
References: