[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPSEC Minutes




		  IPsec Working Group Meeting Minutes

[ Minutes compiled from notes taken by Barbara Fraser, John Linn and Geoff
Huang.]

Monday, August 6, 2001

Document status/updates
=======================

IPsec MIB doc had a few edits and they'll soon be ready to go to
working group last call.  The GSSAPI-IKE has a new draft just posted
and it should go to wg last call immediately.  This will be
informational.  The other one is the mod-p DH group definitions.  Tero
said it's ready to go, and it's ready to go to wg last call.  We'll
move all three of these immediately after the wg.

Motivations for including an IV in AES counter modes
======================================================

Steve Kent presented why you might want to use IV in counter
mode. Counter modes offer improved performance. Two counters: per packet
and intrapacket counters. System perspective to get a nice number of
bits to change each time, and have something you can do on the chip to
stay within the current evaluation requirements. No less than 32 bits
and may have to bring it up to 64 bits.

AES cipher document
===================

Current status of the AES cipher document was discussed by Sheila
Frankel.  It's (AES and CBC mode) been around for awhile. There are
multiple implementations. They are planning a draft of AES MAC, and
there has been interest in a draft for AES SHA.

Son of Ike / Immediate Changes to Ike
=====================================

Ted Ts'o made some opening comments to frame the discussion.  Marcus,
Jeff, and Steve's note to the list was a restatement of the position
they set a year or so ago.  The two things that require near term changes
to IKE are SCTP compatibility and NAT/Firewall traversal.  There haven't
been many changes to the SCTP draft and Barbara and Ted will be talking
to the editors after the meeting to see how we can move the document
forward.  NAT/firewall traversal drafts now exist that harmonize the
previous drafts.  The only problem remaining is AH.  The AH part in
encapsulation draft is incorrect.  Question is do we need AH? About a
dozen folks are implementing. Only one person in the room supported
including AH, all others were against including AH. This topic will be
taken to the list to allow for comment and within 3 weeks we should be
able to go to wg last call.

Opportunistic IPSEC
===================

Hugh discussed the opportunistic keying, which is being pursued by the
Freeswan project, and discussed in
draft-richardson-ipsec-opportunistic-00.txt.  It uses secure DNS to
discover that two systems have keys out there that can be used for
communications.  It allows most hosts to communicate
opportunistically. Freeswan v 1 came out about a month ago. They don't
do any verification of the keys, assuming that's done by DNS-sec. 

Matt Blaze asked what the killer argument is for why someone should
run this?  Answer: A way to get encryption going on the net.
Discussion continued on the motivation for using such a protocol. Hugh
suggested that we need to get confidentiality deployed and then worry
about authorization.  

Question asked as to whether most sites can afford it.  For example,
most people don't stay on a single site for lengthy periods of
time. Can most hosts handle the CPU load given that are sites even now
that want to use SSL but can't even handle that. Two things that make
this difficult: very short transactions. 

Another issue is concern that the DNS SEC folks won't be happy about
using DNS to pass around keys that are not DNS keys. Bill Sommerfeld
responded to the DNS SEC comment saying that they are supporting
Secure Shell wg and they also support IPsec. A comment was made that
benchmarking showed that IPsec can be a win over SSL, etc. because of
the use of kernel space. Comments made supporting the experimental use
of this protocol and see what the activity and performance
characteristics are.

Tuesday, August 7, 2001
=======================

Clarification of IESG/IAB message
=================================

Last week, Jeff Schiller, Marcus Leech, and Steve Bellovin published a
position statement on the ground rules for further development of IKE.
Marcus noted that its premises were well known to the Ipsec community,
but others took it more critically than was intended.  Steve and Marcus
stated that no exploitable attacks on IKE are currently known.

The main point that was meant in the position statement: IKE is too
complex to analyze and determine whether or not it's bug-free. The intent
is not to preclude progression of PIC in IPSRA, but rather to reiterate
that IPSRA shouldn't change IKE.  The message wasn't anything new; just
a reiteration of what's been said for over a year: i.e., that there
should be no drastically new changes to IKE.  The issue, now, is what
needs to be done to address the shortcomings of IKE.

During the brief question and answer period, William Dixon raised a
question about unpublished analysis of IPSEC; where they analysis of
implementations or the protocol.  The answer was that most of the
analysis, especially the early ones, such as the one done by Cathy
Meadows, focused on the protocol, and in some cases on draft versions of
the documents.

Steve Bellovin stated that a complex protocol requires complex
implementations, and complex implementations lend themselves to bugs and
security problems.  He pointed out the majority of CERT advisories are
just bugs.  Marcus stated that no one has asserted that any particular
implementation is known to be insecure; it's just that complex
implementations, by nature, tend to have security problems.


Introducing Son-of-Ike Discussion
==================================

Barbara Fraser introduced the discussion by making the following
observations: IPSec is entering a new phase, looking into IKE based on
experience to filter requests into design requirements for how to move
forward.  It is premature to judge whether to modify or replace IKE.
The two proposals to be discussed subsequently are proposed first steps
in this direction.  Open mike discussion will need to be followed up on
the mailing list.

Improving IKE
=============

Improving IKE (Radia Perlman): The primary goal is simplification,
that's code-preserving where possible, but also considering
improvements.  The draft is a summary of a paper co-authored with
Charlie Kaufman (url available in the draft).  

Proposals:

*) Remove aggressive mode, rather than expecting users to choose between
main and aggressive and reducing the number of sub-protocols.  Either
identity hiding is important, or it isn't; removing aggressive mode would
remove half the protocol.

*) Remove public-key encryption variants, leaving signature modes; among
other reasons, they're less likely to be escrowed, few will have
encryption keys without signature keys, and everyone knows their
signature keys before performing any protocol.  This further reduces the
set of sub-protocols.

*) Allow stateless cookies, as provided in Photuris but not preserved in
IKE.

*) More compact parameter negotiation than possible in ISAKMP, with
smaller number of negotiation proposals.

*) Fix main mode preshared key operation, or remove preshared keys

*) Remove Phase 2?  This is recognized as a more contentious suggestion.
If there aren't to be a lot of Phase 2s, amortizing a smaller number of
Phase 1s, it's more efficient to combine the phases.

*) Invert identity protection, hiding originator's rather than target's
identity.  The target's identity is generally less important to keep
secret, since the identity is usually know due to a fixed IP address.

*) Additional suggestion: SSL-like unidirectional authentication or strong
password-based authentication (e.g., EKE).


Implementation Cleanups
=======================

Andrew Krywaniuk presented some protocol cleanup proposals from an
implementors perspective.  Primary concern: Don't destroy the existing
code base.

Andrew doesn't believe we should remove phase 2.  However, he 
believes that Phase 2 PFS is superfluous given phase 1.  The commit bit
may also not be necessary.  We should adopt Tero's revised
authentication hash.

Rekeying has been a major operational problem, since it's unspecified in
the documents, and people try to do it in different ways.

We need to clarify the use of certificate request/vendor ID payloads.

Things which Andrew believes we should add include: Dead peer detection,
replay protection into phase 2 exchange, distributed denial of service
attack protection, and Reliable notification messages.

Open Mike
=========

Matt Blaze noted that he and his team is still working on Just Fast
Keying (JFK).  It should be ready for presentation by the next IETF.

Various people noted that if we are creating a new protocol, or even
modifying an existing one, we need to be clear about defining
requirements and scope.  (Who knew when we started that a protocol
like iSCSI would want to use IPSEC?)

A number of commentors (Steve Kent, HI, William Dixon) agreed that
paring down the IKE feature list would be a good thing.  Besides
simplifying implementations, it improves the likelihood of
interoperability.

David Black from the iSCSI working group noted that iSCSI was
sensitive to roundtrip counts, and so he thought aggressive mode might
be needed.  Howard from Intel noted that iSCSI would require fast
rekeying, since with 10GB wire speed, rekeying might need to happen
after 5 minutes.

There was discussion both in favor and against preserving existing
implementations.  Some people believe it was important; others did
not.  Ted Ts'o noted that at the previous IETF meeting, a straw poll
was taken, and a clear majority at that time believed that code
preservation was important.  At the end of the open mike session,
another straw poll was taken; this time a clear majority (45) believed
that code preservation was NOT important.  Approximately 15 people
believed that code preservation was important.  Interestingly, these
percentages were almost exactly reversed in Minneapolis.



Follow-Ups: