[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Results of the IPSEC document reading party
- To: ipsec@tis.com
- Subject: Results of the IPSEC document reading party
- From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
- Date: Fri, 19 Dec 1997 15:01:25 -0500
- Address: 1 Amherst St., Cambridge, MA 02139
- Phone: (617) 253-8091
- Sender: owner-ipsec@ex.tis.com
Hi all,
Below please find the collected results of the IPSEC document
reading party. My apologies for the delay in getting these out; I
should have pushed them out before the end of the IETF meeting, before I
took a few days off visiting friends in the Washinton area.
- Ted
From: John Ioannidis <ji@research.att.com>
Date: Tue, 9 Dec 1997 12:55:53 -0500 (EST)
To: tytso@MIT.EDU
Subject: results from last night's document reading
Here are the comments my group (ESP) came up with.
Marc Hasson
Richard Briggs
Inder Monga
John Ioannidis
draft-ietf-ipsec-
arch-sec-02.txt
====================
In -ciph-des-expiv-01, section 4 reads
...
[ESP] describes the general mechanism to derive keying material for
the ESP transform. The derivation of the key from some amount of
keying material does not differ between the manually- and
automatically-keyed security associations.
...
The description is NOT in the [ESP] document, but in the architecture
document, in section 4.6.2. The reference should be changed to [arch].
====================
In auth-hmac-md5-96-01.txt, section 3., the same problem exists:
change:
...
[ESP] describes the general mechanism to obtain keying material for
the ESP transform. The derivation of the key from some amount of
keying material does not differ between the manual and automatic key
management mechanisms.
...
to [arch]...
====================
In -ciph-cbc-01.doc, section 3.2, reads:
...
3.2 Keying Material
The minimum number of bits sent from the key exchange protocol to
this ESP algorithm must be greater or equal to the key size.
The cipher's encryption and decryption key is taken from the first
<x> bits of the keying material, where <x> represents the required
key size.
...
This section should reference section 4.6.2 in the [arch] document.
====================
-esp-v2-02.txt, section 3.1, reads:
...
Support for additional combinations of AH and ESP is optional. Use
of other, optional combinations may adversely affect
interoperability.
...
but the architecture document, section 4.5, reads:
...
the implementor. Compliant implementations MUST be capable of
generating these four combinations and on receipt, of processing
them, but SHOULD be able to receive and process any combination. The
diagrams and text below describe the basic cases.
...
these two sections are not exactly consistent; we suggest
-esp-v2-02.txt be fixed.
The exact same problem exists in the -auth-header-03.txt document.
====================
Tunnel mode, issue #1:
Nowhere in the documents is it mentioned what protocol should be used
in the next header field for tunnel mode. Traditionally, it has been
protocol 4 (IP-in-IP), which is not really documented anywhere, but
simply involves encapsulating an entire IP datagram. We think this
should be made explicit in the architecture document, probably where
tunnel mode is discussed in section 5.1.2.1 in the architecture
document (it is implicitely assumed by a reference to rfc2003).
Tunnel mode, issue #2:
This goes beyond IPSEC, really; the question is what happens when we
want to tunnel an IPv6 datagram inside IPv4 IPSEC; The headers would
go like this:
[ipv4, next_header=50 [ESP, next_header=xxx [IPv6 datagram]]]
If we were tunneling an IPv4 datagram, xxx would be 4; if we tunnel
IPv6, do we use 4 again, and rely on the version field of the IPv6
header to correctly interpret the inner datagram as IPv6? Or do we use
the ( ), much like we have separate ether-types and ppp types for
IPv6 (so as not to rely on implementations checking the protocol
version)?
====================
In -esp-v2-03.txt, section 3.4.1
...
packet offered to ESP for processing appears to be an IP fragment,
i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
...
this is confusing; it seems to imply that a packet may be sent which
causes this to happen. After discussing it with Steve Kent, it turns
out that it is a "belt-and-suspenders" point; a well-functioning IP
stack should never pass a fragment up to ESP, but in case it happens,
ESP should be prepared for it and discard the packet.
====================
----------------------------------------------------------
From: Steve Bellovin <smb@research.att.com>
To: tytso@MIT.EDU, rgm3@chrysler.com
Subject: ESP document inconsistencies
Date: Mon, 08 Dec 1997 19:17:59 -0500
Sender: smb@research.att.com
In draft-ietf-ipsec-ciph-des-expiv-01.txt:
There is confusion about rejection of weak keys. Section 4
says "Weak key checks will be performed". Should that be
MUST? The whole sentence is in the passive mode, which is
especially bad here, since the reader doesn't know who is
to perform the checks. The next section, 4.1, says that
implementations "SHOULD take care" not to pick such keys.
Which is it? This also conflicts with draft-ietf-ipsec-ciph-cbc-01.txt,
which says that weak keys MUST be rejected.
draft-ietf-ipsec-ciph-cbc-01.txt
See the above comments on weak key processing.
2.5 has very bad terminology. It is not how "how many
times a block is encrypted"; rather, it is how many rounds
must be performed to accomplish one encryption.
The description of the status of the different ciphers is
incomplete. For example, I believe that RC5 and CAST are
patented. This should be stated, just as it is for IDEA>
(But CAST has been released, I think.)
There are two different discussions of IV selection. The
second is much better. Should we say that a simple counter
MUST NOT be used for an IV? I think so.
draft-ietf-ipsec-esp-v2-02.txt
3.1 Say that tunnel mode *MUST* be used.
3.3.5 I'm not convinced that the description of how to do fragmentation
is correct. I'm especially concerned that transport and tunnel modes
require different processing. The interaction of the rules here with
IPv6 fragmentation is especially worthy of attention. (See the discussion
of fragmentation in Wagner and Bellovin's "A Bump in the Stack Encryptor
for MS-DOS", http://www.research.att.com/~smb/papers/bisconf.ps)
3.4.1 A fragment being passed to ESP is a host bug, not an auditable
event. The lower layer should have reassembled the fragment, as it
does for all higher-layer protocols.
3.4.5 There are many more ways in which decryption can "fail". For
example, it can yield an illegal pad length, illegal pad values, or
(maybe) a bad "next protocol" value.
-------------------------------------------------------------------------
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: tytso@MIT.EDU, rgm3@chrysler.com
Cc: ddp@network-alchemy.com
Subject: results from the reading "party"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 11 Dec 1997 15:03:29 -0800
From: Daniel Harkins <dharkins@cisco.com>
Ted, Bob,
Here's the results of the ISAKMP, ISAKMP/Oakley, and DOI document
reading party.
Dan.
------------------------------------------------------------------------
Issues with the resolution document and the base ISAKMP spec
------------------------------------------------------------------------
0. isakmp-09 reference in resolution doc should be to -08, but if
we're re-reving all these I should just leave it.
1. DOI of 0 in phase 1 says to use the ID semantics from the base
ISAKMP draft but the base ISAKMP draft doesn't define any semantics.
A minimal set of ID types has to be added to the base ISAKMP draft.
2. 3DES-CBC-MAC is not defined. Issues with it are: 1) what to do if the
key is exactly 24 bytes; and, 2) what about padding? Ben Rogers
volunteered to write such a description.
Desires for more restrictive language in the resolution document and DOI
----------------------------------------------------------------------------
0. should add: MUST NOT send a key length attribute with a fixed length
cipher; needs to be consistent in DOI and resolution document too.
1. should mention that phase 2 proposals that are logically related
must be consistent and if PFS is desired the same group must be in all
proposals.
2. should mention that phase 1 SA offers consist of a single proposal
with possibly multiple transforms and not multiple proposals-- the
protocol has to be ISAKMP anyway so multiple proposals doesn't really
make sense.
3. mention that attributes described in the DOI as basic MUST NOT be
encoded as VPIs. Also mention that if the initiator offers an attribute
encoded as a VPI that could physically be encoded as a basic (e.g. it's
value can fit in 2 octets) the responder MAY encode the response as
a basic.
Issues outside our scope that came up anyway
-------------------------------------------------
0. there is no way to negotiate cascaded SAs. This may be moot based on
the results of the Arch+DOI partiers.
1. encapsulation attribute semantics may cause interoperability problems.
This may be moot based on the results of the Arch+DOI partiers.
2. Arch doc seems to mandate that the "first" SA bundle be used to
protect targeted packets and not the most restrictive. E.g. if there
are SAs in the SADB currently for:
all packets from net A to net B
all telnet packets from host a to host b
all packets from host a to host b
(in that order) and a telnet packet from host a to host b comes along
the most restrictive SA (the one with the most exact matches vs. wild-
card matches), the one specifically for telnet packets from a to b
should be used and not "the first".
I'm not sure I agree with this contention but the issue did arise.
As an aside, we (cisco) _always_ use the most restrictive SA as that
seems the best way to build and properly use shared SAs.
-----------------------------------------------------------------------
X-Sender: rmonsour@earthlink.net (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 08 Dec 1997 21:10:29 -0800
To: rgm3@chrysler.com, tytso@MIT.EDU
From: Bob Monsour <rmonsour@hifn.com>
Subject: Roadmap and related doc review
Cc: rfriend@hifn.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Bob & Ted,
Below are comments from Rob Friend and myself on the roadmap doc and on
some of the documents they relate to. The approach we took was to review
the requirements for the encryption and authentication algorithms and to
relate those to the mandatory drafts (expiv-01, md5-96-01, and sha196-01 -
or whatever the current names are). As you'll see some of the three don't
quite measure up. We also identified some ESP doc issues that tie in to the
issues we identified.
Regards,
Bob & Rob
ROADMAP DOCUMENT COMMENTS
-------------------------
Issue 0: Section 3 is titled Keying Material, and would seem to better fit
under section 4 as it applies to both encryption and authentication
algorithms.
Section 4.1 Encryption and Authentication Algorithms
This section describes the requirements that are common to encryption and
authentication algorithms.
The following 4 issues all relate to section 4.1 of the roadmap doc.
Issue 1: There is a requirement to discuss random number generator
techniques. The des-expiv-01 doc does not cover this topic.
Issue 2: There is a requirement to discuss the "format of keying material".
The des-expiv-01 doc does not cover this topic.
Issue 3: There is a requirement that "requirements and/or recommendations
on how often keying material should be refreshed" should be in the
algorithm docs. There are 2 sub-issues related to this: (a) We question
whether this should really be in the algorithm documents, and (b) The
des-expiv-01 doc states "there are no current recommendations for key
lifetime." Also, the term key lifetime seems inappropriate in the des doc.
Issue 4: There is a requirement that the Security Considerations section
include discussion of "any relevant validation procedures". The
des-expiv-01 doc does not cover this topic, either in the Security
Considerations section, nor anywhere else in the document.
MD5-96-01 and SHA196-01 COMMENTS
--------------------------------
Issue 1: Section 3. Keying Material - The 4th paragraph references the ESP
doc (and not AH) as to how to obtain and process keying material. We
question why this paragraph exists at all. In addition, the ESP has NO such
description of how to do these things.
Issue 2: There is a requirement that "requirements and/or recommendations
on how often keying material should be refreshed" should be in the
algorithm docs. There are 2 sub-issues related to this: (a) We question
whether this should really be in the algorithm documents, and (b) The
MD-96-01 and SHA196-01 docs states "current literature does not include any
recommended key lifetimes". Also, the term key lifetime seems inappropriate
in the des doc.
Issue 3: There is a requirment that "any known attacks" be discussed in the
Security Considerations section. The MD5-96-01 doc does not discuss this.
DES-EXPIV-01 COMMENTS
---------------------
Issue 1: Section 4. Key Material - The 2nd paragraph references the ESP,
stating that it contains a mechanism to derive keying material for the ESP
transform. We question why this paragraph exists at all. In addition, the
ESP has NO such description of how to do these things.
----------------------------------------------------------------
Bob Monsour Hi/fn Inc.
rmonsour@hifn.com 2105 Hamilton Avenue
408-558-8065 Suite 230
408-558-8074 fax San Jose, CA 95125
----------------------------------------------------------------
Follow-Ups: