CURRENT MEETING REPORT
Reported by Ran Atkinson
Minutes of the IP Security
Protocol Working Group (ipsec)
AGENDA
1. WG Agenda & Introduction
2. ESP/AH
A. RSVP and IPsec
B. ESP transform for DES-CBC,
unkeyed MD5, and replay protection C. HMAC for AH (Hugo, IBM)
3. Key Management
A. Status and progression of Key Management, Paul Lambert
B. Cylink presentation on D-H patent license
C. ISAKMP
1. Status Update, Mark Schertler
2. Comments, Dave Carrel
D. Oakley, Oliver Spacek
E. SKIP, Ashar Aziz
F. Photuris, Bill Simpson
G. Naming Issues, Steve Bellovin
4. Closing Remarks
MEETING SUMMARY
Monday Evening:
1. WG Agenda & Introduction
Paul Lambert introduced the
goals of the WG for the benefit of newcomers and walked through
the current set of Internet Drafts at a high-level. He then presented
the overall Agenda shown above.
2. Paul Lambert showed a summary
of ESP/AH implementations. About 15 implementations exist now
or are in progress. Bill Simpson asked how many implementations
supported sensitivity labels. Ran raised his hand for the NRL
implementation (which is the basis for several other implementations).
2A. Lou Berger presented an
approach to providing QoS to flows of encrypted IPv4 data using
RSVP.
The RSVP WG is responsible
for this item. They had met Monday morning and discussed RSVP
interaction with ESP. RSVP is a resource reservation protocol
for the Internet. It provides dynamic QoS setup for flows of unicast
and multicast IP data packets. It does not introduce new headers
into data packets, rather the flows are identified by data packet
destination and the control is based on source address. RSVP provides
limited support for protocols that don't have UDP/TCP-link ports.
The proposal on use of RSVP
with ESP flows is straight forward, introducing some definitions
on how to define the flows based in SPI. The proposal uses SPI
in place of UDP/TCP-like ports. The SPIs are used as generalized
source ports for filtering. The proposal provides session de multiplexing
via virtual destination ports. The limitations on their proposal
are that it limits the usage of WF style reservations, another
limitations is that all flows with same protocol and destinations
address match WF reservations. Every time a new SPI is used, need
to establish new reservation, it may use SE to avoid problem but
other options are being explored. The SPI-based approach assumes
that each flow between a pair of hosts will have its own SPI value.
The result of their work was accepted by the RSVP WG and it is
moving in last call status.
2B. Jim Hughes presented a
new draft defining a possible mandatory transform for ESP that
combines confidentiality and integrity. His presentation was an
extension of his past comments and presentation on the IPsec mailing
list. Jim indicated a preference for a 64 bit IV length. One to
the major differences is that the packet is decrypted and then
the the MD5 is checked. This provides protection from cut-and-paste
attacks. There were several options to this transform. Options
are negotiated for each Security Association using key management.
Unkeyed MD5 is mandatory,
others items depend on the negotiation of the keys. Keyed MD5
could be implemented instead of unkeyed MD5. Jim's discussion
with a hardware implementer indicates that unkeyed MD5 is easier
to do in hardware than keyed MD5.
Replay protection uses a 32-bit
nonce that is protected under both DES and Keyed MD5. Keys must
be changed before the counter wraps. Such a key change will normally
actually mean that a new Security Association would be used in
place of the original Security Association. Window-based replay
protection is possible.
Overall, this transform will require the following amount of key material:
128 bits for MD5
56 bits for DES-CBC
32 bits for Replay Preventing
sequence numbers.
There was some discussion
on the floor on the desirability of having so many options. Steve
Bellovin preferred to reduce the number of options because that
made the protocol easier to understand and implement. After a
straw poll, the default was changed to Keyed MD5 and support for
unkeyed MD5 is to be removed from the next version of the draft.
Phil Karn presented his objections
in the ordering of encryption and authentication. He prefers to
have authentication outside so that if that fails he won't have
to attempt a decryption.
The was a call for a straw
poll from the floor to see if the group agreed with aspects of
this proposal. Steve Bellovin supported the confidentiality with
integrity checking, because both are needed to provide solid security.
There was smooth consensus that Replay Protection should be mandatory
to implement and that all ESP transforms need to have strong integrity
protection. Further discussion is to occur on the IPsec mailing
list.
2C. Presentation on HMAC MD5
Transform for AH
Hugo Krawcyzk presented his technique for an HMAC MD5 transform. The basic approach is:
MD5(K.pad2.MD5(K.pad1.text))
This can be used with hash
functions such as MD5 and SHA. Various lengths of output can be
used (128, 80, 64 bits with MD5, 160 or 80 bits with SHA). The
output is at least half of the bits, but not less than 80 bits,
just in case some bits are predictable. We need to define what
length is mandatory.
Proposal for the default length
is: HMAC-MD5-80
Hugo will published a revised
I-D with this length. There was some discussion on having 80 or
128 as mandatory in the MAC implementation.
3. Key Management
Paul Lambert briefly reviewed
each of the 3 main proposals for key management: SKIP, ISAKMP
with Oakley, and Photuris.
Then Jeff Schiller, Security
AD, asked how many people were familiar with SKIP, Photuris, and
ISKMP, then he tried to measure how many people planned to implement
each of the proposals. Each proposal had about 25-30% of the attendees
in the room raise their hands. Another roughly 20-25% of the attendees
did not participate. It was very clear that the WG does not currently
have consensus on an approach to key management.
3B. Cylink
John Kennedy gave a presentation for Cylink on the Diffie-Hellman and Hellman-Merkle patents. Cylink is offering standard terms for any party that is licensing these patents for use in a standards-track IETF protocol. The license terms are a fixed one-time fee of $75,000. Several narrow legal questions were asked from the floor.
SUN has paid for the license
to implement SKIP and now SUN is giving the implementations free
for all IETF. cisco is doing the same exact thing for a UNIX PF_KEY-based
daemon that implements ISAKMP with the Oakley extensions.
3C. ISAKMP
1. Status and Overview
Mark Schertler presented an
update focused on the differences between the version presented
at the Dallas IETF and the current draft. Several ideas already
in the original draft but not originally well described have been
significantly clarified. Some of these items are: user
negotiation protected by server established SA, security policy
identifiers,domain of interpretation (DOI), etc.
2. Thoughts on IPsec Key Management
Dave Carrel presented his take on the key management proposals. Cisco is implementing ISAKMP with Oakley extensions, first as a freely distributable UNIX key management daemon but later also in cisco's routers. Dave indicated that cisco has running code now for the UNIX daemon. Dave likes the following features of this approach:
ISAKMP can also be used for protocols other than IP. ISAKMP supports AH/ESP as well as non standard mechanisms. ISAKMP is likely to meet application layer keys exchange needs. Specifications are clean not hacked.
Specification is straightforward
to implement Key management can be simple (just keys) or full
featured
The source code for the UNIX ISAKMP+Oakley daemon should be freely available for commercial or non-commercial use in late April 1996. It can be ported to other platforms without any additional fee being owed to Cylink. For more information, see the file at
ftp://ftp.cisco.com/isakmp-oakley/README
A mailing list has been setup
for this software. Contact the mailing list via <majordomo@cisco.com>.
TUESDAY MORNING:
Paul Lambert gave an introduction.
One item was that after last night's session it is clear that
we currently lack consensus on Key Management. The question arose
of whether we would go with the HMAC MD5 or the current RFC-1828
approach. Hugo presented his approach. A straw poll indicated
smooth consensus in favour of the HMAC MD5 approach to replace
the current RFC-1828 approach. The new HMAC MD5 would get its
own transform identifier for key management purposes so that we
will be backwards compatible.
3D. Oakley key exchange presentation
Oakley is a session key exchange
protocol that can be used alone, if only key setup is needed,
or with ISAKMP, if full attribute negotiation is required. Hilarie
Orman <ho@cs.arizona.edu> wrote up Oakley after being asked
by the IPsec WG co-chairs to do so. Oliver Spatschek (Univ. of
Arizona) gave the presentation for Hilarie.
Oakley has several features,
including (1) authenticated key exchange and key state, (2) it
is based on Diffie-Hellman, and (3) it is compatible with ISAKMP.
At present there are 3-1/2 modes and 2 operations. They could
define either more or fewer modes if preferred by the WG. Private
groups are allowed, passing the description of the group and verifies
that the group is allowed. Hugo suggested that the concept of
private groups be moved to an extension and not in the main document.
Oliver did not object.
3E. SKIP and extensions
Ashar Aziz presented an update
on the SKIP key management proposal. The original document has
been broken in different extensions making it very modular. Changes
in one document will not necessarily affect the other documents.
The major change is that SKIP
now has an extension to provide Perfect Forward Secrecy (PFS).
Other changes are a new certificate type for ephemeral DH values,
which combines ephemeral and long-lived DH values to provide authenticated
PFS. He presented the details of the PFS extension, which are
documented in one of the current Internet Drafts.
There is mode that has less
transactions but does not provide PFS, and if PFS is wanted them
more overhead is required. The third mode is the multicast mode.
SKIP source code is available
from http://skip.incog.com. This is currently the Alpha-2 version,
which is available for commercial and non-commercial purposes.
It supports SKIP, CDP, X509, VDH, AH/ESP, DES/3DES, Keyed MD5.
The Sun implementation does interoperate with the ETH Zurich implementation
and the "Elvis" implementation in Russia. The Sun implementation
is for SunOS 4.1.3. Sun is going to set up a machine so other
implementors can try their implementations interoperability. A
new release is planned that will be able to interoperate with
other implementations of AH/ESP that use manual key management.
Time ran out and further discussions are for the IPsec mailing
lists.
3F. Photuris
Phil Karn did not present
this time. Bill Simpson presented his document to the Working
Group at some length. Bill asserted that there are fewer options
in the new release of Photuris according with the consensus from
of the WG at previous meeting. There was an extensive heated discussion
between Hugo and Bill on the need for some additions to and modifications
of Photuris to make it more reliable and secure. Hugo will send
his suggestions to the mailing list to be considered by the WG.
Convergence of SKIP and Photuris looks like hard to obtain. As
with other IPsec presentations, time was short and discussions
are to be continued on the mailing list.
3G. Naming Issues
Steve Bellovin discussed naming
issues. His concern is not with the format of X.509 or PGP, but
rather how we name the end point. He is very concerned about the
notion of finding any of these endpoint names or IP addresses.
Steve Kent suggested the need to keep the IP address. The certification
must be bound to the address to avoid modifications at the application
layer. Another concern is about how to deal with provider-required
renumbering, which complicates the issue of binding the certificates
with the IP address. We are getting to the last stages of key
management so we have to defined very clearly what we want to
managed.
4. Closing Remarks
Paul Lambert noted that we
need resolution on sensitivity label formats and naming semantics.
Bill Simpson said that he still has some open questions that need the feedback from the WG. Some of these questions relate to AH/ESP orthogonality, mandatory transforms for Photuris, and support for compression.