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

ADMIN: Dallas IETF Minutes for IP Security WG

All,

  Appended below are the written minutes for the IP Security WG that were
submitted to CNRI for inclusion in the written proceedings.

  Special thanks are due to Richard Graveman (Bellcore) who once again
provided the co-chairs with his clearly written notes on the meetings
and did so very shortly after each session.  Our minutes are almost 
entirely his words.

Ran Atkinson		Paul Lambert
rja@cisco.com		palamber@us.oracle.com


---------------------  cut here ---------------------------------


Minutes for IP Security Working Group
34th IETF, Dallas, TX, December 1995.


	These minutes are largely based on the notes taken by Richard
Graveman <rfg@ctt.bellcore.com> during the meetings.  The WG chairs
thank him for his assistance in taking good notes during the meeting.
Co-chair Paul Lambert <palamber@us.oracle.com> was the floor moderator
for most of this session.  He was assisted by Randall Atkinson
<rja@cisco.com>.  Paul noted that both of the co-chairs recently
changed employers and so have new email addresses.

	IP Security WG mailing list is likely to be rehomed early
in 1996.  If it moves, the change will be announced on the main ietf
mailing list.  The current (as of December 1995) mailing list addresses are:
	Postings:	ipsec@ans.net
	Admin:		ipsec-request@ans.net


IP Security (IPSEC) Session 1, December 4th, 1995:
--------------------------------------------------

	RFC 1825 through RFC-1829 define the IP Encapsulating Security
Payload (ESP) and the IP Authentication Header (AH).  These were issued 
as Proposed Standard RFCs this past August.  The discussions during
the first IPsec meeting were focused on these specifications.

LIAISONS: 
	Ran noted that options in IPv6 are handled differently from
IPv4.  A bag of Hop-By-Hop options may follow the base IPv6 header.
After these may come Destination Options and then the upper layer
protocol (e.g. ICMP, TCP, or UDP).  Destination Options are only
handled by specifically listed destination systems for the IPv6
packet, while Hop-By-Hop options are handled by each intermediate
system and end system (host or router).  It might be useful to
consider specifying AH for IPv6 as either a Hop-By-Hop Option or
Destination Option rather than as a separate header.  One advantage is
that if AH were specified in this new way, the semantics of AH
processing might be more clear for IPv6 implementations and two
different semantics could be supported.  Another possible advantage is
to force AH to be parsed first at the destination(s), even though would
not be handled at the routers.  This is expected to be discussed
more during the IPng WG meetings later this week.



AH/ESP IMPLEMENTATION STATUS:

Ran posed the following questions for all implementers:
	Whose implementation ?
	Implemented in what (host router, etc) ?
	Is it commercial or freely available?
	Which transforms were implemented ?
	It is known to interoperate with ?
	Which key distribution techniques are implemented ?

Ran: 
	The freely distributable NRL implementation covers IPv4 and
IPv6 for hosts and routers, is based on 4.4-Lite BSD, Implements Keyed
MD5 and DES-CBC, works with Karn and Morningstar, and has manual key
management.  A particular feature is that this implementation includes
a Key Management Socket (PF_KEY) that permits key management daemons
to be implemented outside the kernel in a portable manner.  It is
likely that NRL will document PF_KEY in an Informational RFC during
the next few months.  Additional transforms are easy to add to this
implementation.  Configured secure tunnels, dynamic tunnel-mode
encryption, and transport-mode encryption are all supported using
extensions to the widely used BSD network Sockets API.  Applications
that support use of IPsec via command-line options are also included
in the distribution.

	See Dan McDonald <danmcd@cs.nrl.navy.mil> or Bao Phan
<phan@cs.nrl.navy.mil> for more information.  This implementation is
freely available (modulo US Export Controls) and is reportedly online
at ftp://ftp.c2.org MIT is expected to be the official archive site
for the NRL software, but is still working on getting the software
online.  Enhancements to the NRL software are underway and will also
become freely distributable.  A paper on the details of this
implementation will be presented at the January 1995 USENIX
Conference.

John Ioannidis ("JI") : 
	This implementation was implemented in Greece, runs on BSDI, and will
be freely available.  It implements keyed MD5 and DES CBC, uses manual key
distribution or Photuris (also implemented outside US) key distribution, 
and handles multiple transformations in any order with built in tunneling.
Contact JI at <ji@tla.org> for more information.

Phil Karn: 
	KA9Q implementation for hosts and routers based on MS-DOS,
does encapsulation separately, will be distributable, uses keyed MD5,
DES, and 3DES (IDEA perhaps next).  It talks to at least Morningstar and
NRL, and has manual key management.  Photuris is planned for the future.
Contact Phil Karn <karn@unix.ka9q.ampr.org> for more information.

Mark Linehan: 
	IBM's Pau-Chen Cheng has an implementation that runs on AIX,
will be in a commercial firewall product.  Mark indicated that they
will have an exportable version, and uses manual key distribution.
Pau-Chen has a copy of the implementation at the IETF so that
interoperability testing can occur this week.  Contact Pau-Chen
<pau-chen@watson.ibm.com> for more information.

Steve Bellovin: 
  Two implementations were done last summer by David Wagner (UC
Berkeley) while he was at AT&T Bell Labs.  The first implementation
runs on BSDI and uses keyed MD5 and DES.  This AH is known to not
interoperate with other implementations.

  The second implementation runs on MSDOS, uses keyed MD5 for AH, 
looks like a  packet driver, so it can work with many boards and IP 
stacks. This has been tested with ftp Software and a paper on this
implementation will be presented at ISOC in February.  Contact
Steve Bellovin <smb@research.att.com> for more information.

Hilarie Orman: 
	This implementation was done in the "x-kernel" research
operating system at the University of Arizona.  It is a user process
in MACH, implements AH with keyed MD5, and implements ESP with DES CBC
and 3DES. It has ping and ftp clients.  Tools for manual key
distribution exist.  A Photuris implementation also exists.  Will be
freely distributable with the x-kernel software.  Contact Hilarie
Orman <ho@cs.arizona.edu> for more information.

Ashar Aziz: 
	Sun has implementations of ESP and AH with SKIP for SunOS
4.1.3 (kernel driver source), and Solaris 2.x (binaries only).
Contact Ashar Aziz at <ashar@eng.sun.com> for more information.

Swiss Federal Institute of Technology: 
	Runs on Solaris 2.x, IRIS, and NetBSD, freely distributable,
implements AH and ESP with a fixed SPI (i.e. only works with SKIP key
distribution).  Key distribution is manual or with SKIP.

Rob Glenn:
	NIST and NSA have an implementation of ESP and AH with MD5 and
DES-CBC.  It runs on BSDI, SunOS 4.1.x, FreeBSD, and NetBSD.  They
brought a FreeBSD implementation for interoperability testing and are
working to make the implementation freely distributable within the US.
Their implementation can use ISAKMP and was designed to support multiple
security policies.  Contact Rob Glenn <rob.glenn@nist.gov> for more
information.

Other:
	Two other implementations were mentioned without much detail.
Jeff Kramer of Raptor has implemented some of IPsec.  Antonio
Fernandez of Bellcore has an AH implementation.  Interoperability
testing will occur in a hotel meeting room on Tuesday afternoon,
thanks to Tim Matthews who arranged for the room.

OPEN ISSUES:
	Where do current RFCs need clarification?

	The current RFCs will be cleaned up and reissued as Internet
Drafts before the next IETF.  Then everyone should send comments (preferably
with replacement text) on confusing portions of the current specs so that
the specifications can be cleared up prior to moving to Draft Standard
RFC.  We already meet the interoperability requirements to move to 
Draft Standard.

	Paul Lambert solicited implementor comments on AH/ESP RFCs and
also on the DES, MD5, 3DES, and SHA tranforms RFCs:

	Bellovin and others asked which fields in the IPv4 header
should be zeroed.  There was consensus that this is the biggest
problem with AH/ESP.  Ran responded that the next version of the AH
spec will specifically enumerate which IPv4 options and header fields
are included in AH calculations and which are zeroed.  A note to the
IPsec WG mailing list late last August enumerated these in more detail
than was present in the RFCs.

	The options important to include in the Authentication Data
calculation are IPSO (RFC-1108)and CIPSO (no public specification
exists).  JI suggested adding sequence numbers to AH. It is in the
Photuris extensions draft and would use the 16 bits of reserved AH
header.  Bob Moscowitz brought up concerns about interactions with
firewalls.  Perry Metzger brought up need for ways to use (fast)
stream ciphers (synchronization problem).

	Bill Simpson asked for comments on the transform RFCs.  The
main comment was that many implementers have been confused on how
to perform the MD5 padding.  Hilarie Orman suggested including example
C source code in an informational Appendix to the MD5 transform draft
in order to make this more clear.


NEW TRANSFORMS:

	Hugo from IBM discussed an alternate approach to Keyed MD5.

	RFC 1828 specifies:	MD5(K pad x K).

	New nested mode: 	MD5(K padsub2 MD5(K padsub1 x))
				|K| = 16 bytes
				padsub1 = 0x36 repeated 48 times
				padsub2 = 0x5C repeated 48 times

	Hugo's Comparison:
	- is still MD5 based (available, unrestricted, good performance)
	- is replaceable (SHA, MD6, ...)
	- no performance degradation
	- short keys, simple setup
	- MD5 unchanged
	- better security:
	   * improved analysis
	   * weaker assumptions about hash function
	   * tighter security: MAC as secure as underlying hash function
	   * double key effect

	He asserted that to break the new MD5 transform, either the
output of the MD5 compression is predictable or MD5 collisions can be
found even when the IV is secret and random.  Both of these are
believed to be untrue for MD5.

	The underlying construction considers MD5 with the IV set to
K. Only one K is needed but the pads have to be different.  Also, for
added efficiency, implementations can compute the first block once and
use each time with a given key.

	Much discussion followed.  Perry Metzger, Bill Simpson,
Hilarie Orman, JI, Steve Bellovin, Ted Ts'o, Bob Moscowitz, Phil Karn,
and Jeff Schiller had comments on this.  Simpson suggested using
Hugo's approach with SHA and not MD5. Hilarie asked where Hugo's
analysis could be obtained and noted the need for outside
cryptographic and mathematical review of Hugo's proposal.

WG Consensus seemed to be: 
	Put this new transform out as a Proposed Standard (Elective)
in its own RFC with a new transform identifier.  Advertise that either
1828 or this new transform might become the required future transform
when we move to Draft Standard.  In order to move the new transform
to Draft Standard, at least 2 independent interoperable implementations
must exist and be demonstrated interoperating.


OTHER TRANSFORMS:
	Paul Lambert noted that there might be other transforms (e.g.
DES-CBC integrated with MD5 for use with ESP) needed.  He solicited
volunteers to write up additional drafts.  Only Bill Simpson and Perry
Metzger volunteered.  Other volunteers are still solicited by the WG
chairs.  Volunteers should write up their proposed transforms and put
them out as Internet Drafts (filenames of the form
draft-LASTNAME-TRANSFORM_NAME-*.txt should be used) and mention the
published I-Ds on the WG list.




IP Security WG, Session 2, 6 December 1995:  
-------------------------------------------

This session was mostly focused on key management and related issues. 

	Paul Lambert showed the matrix of AH and ESP interoperability
testing.  The grid was about half filled in.  Ran observed that not
all combinations of implementations had been tested, so a blank space
was not necessarily indicative of non-interoperability.  A number of
implementation bugs were found and fixed on Tuesday during the
information interoperability testing session.  Two SKIP
implementations worked together.  Two Photuris implementations worked
together.  The group was pleasantly surprised at the rapid progress
towards interoperability and the unexpectedly large number of
independent implementations.



LIAISONS:

ANSI:
John Kennedy discussed ANSI X9F.  There are two drafts:  
	X9.52 for Triple-DES (3DES) is near working draft status.
Contact Bill Latin +1 (408) 735-6679 or via email at
<latin@cylink.com> for more information on X9.F2.

	X9.42 is on Diffie-Hellman (DH).  Contact John Kennedy 
at +1 (408) 735-5885 or via email to kennedy@cylink.com for more
information.

	Also ANSI X9.55 is tracking the X.509 Public Key certificate
standards work; see Russ Housley or Warwick Ford for more information.


IEEE Microprocessor standards:
	This group covers RSA, DH, and related techniques. Burt Kaliski
is the Chair. See ftp://ftp.rsa.com for more information. 

	Elliptic curve (EC) implementation of discrete log systems is
going to ballot within IEEE.  The patent situation is different for EC
than DH. Other sections on RSA, DH, and random number generation.  The
next meeting of this IEEE group is the two days before ISOC Security
Symposium that will be held during February in San Diego.

	The usual comments about the need for no-cost on-line availability 
of these non-IETF specifications followed.


PATENT ISSUES:
	Paul Lambert noted that many of the technologies discussed
by the IPsec WG might be affected by patent claims.  He then tried to
summarise all known patent claims that might be issues.

	Ashar noted that the Sun patents relating to SKIP are
available for use at no cost.  Patents claimed by NeXT are reportedly
under negotiation.  Hugo noted that IBM issued an RFC on use of one of
their patents.  UUNET has a US patent claim on all network encryption.
Novell has a claim on the use of Message Authentication Codes such as
Keyed MD5.  Motorola has patent claims on certain compression techniques.
Paul solicited information on non-US patents, but no one had any
information on this.  It was suggested that any other known patent
claims be mentioned on the IPsec mailing list.

	For Cylink: see http://www.cylink.com or telephone Bob 
			Fougner at +1 (408) 735-5893.

	For RSA, see http://www.rsa.com or telephone Paul 
			Livesay at +1 (415) 595-8782.


	For UUNET, contact Rick Adams <rick@uu.net>


ELLIPTICAL CURVE PRESENTATION:
	Hilarie Orman presented an argument for using Elliptical
Curves instead of Modular Exponentiation with Public-key technology.

   She showed a graph illustrating that to get more key bits, DH
compute time increases rapidly even using Karatsuba multiplication and
Montgomery reduction.

	For DH modulus M, |M| = 512-2048 bits and exponent E, 
|E| = 128-256 bits, compute time is |E| |M|^1.6. 

Strength depends on: 
	minimum(E/2, 2.5M^(1/3),   log(M)^((2/3)-15)). 

	<NB: this expression contains apples and oranges; 
	the first two are comparable, the third is not, 
	so it ought to be checked>  

Using |E| = 128, |M| = 512 really only yields 53 bits of equivalent
DES key strength.  This estimate used an interpolation into an
asymptotic bound for the number field sieve based on the factoring of
a 119 digit number with that method.

	ECs give equivalent strength with 155 bits over a field of
characteristic 2. More information on this subject is available at
http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html.  

	Hugo questioned some of the conclusions that Hilarie drew.
The WG was very interested in Hilarie's presentation but no consensus
either way was obvious.  The matter remains open for further study
and discussion.



ALTERNATIVE ENCRYPTION ALGORITHM:
	John Kennedy presented Jim Massey's "Safer SK" algorithm.
This is a 64 bit block cipher with 40, 64, or 128 bit keys.  It is
freely available and robust against differential and linear
cryptanalysis.  He suggested that this might be of interest.  It was
suggested that he document an ESP transform for this as an Internet
Draft so that the WG could discuss this proposal in more concrete
terms.  It was also suggested that an Informational RFC documenting
the cryptographic algorithm would be helpful.



KEY MANAGMENT:
	Paul then turned discussion towards the currently available
Internet Drafts on Key Management technology.  There are 3 documents
online at present, namely Photuris, SKIP, and ISAKMP.

Photuris:
	Phil Karn presented the changes to Photuris.  Interchangeable
parts of the protocol may lead to weaknesses (exchange, key
generation, signature).  Two implementations exist today that
interoperate: JI (University of Crete) and HO (University of Arizona).
Also work is underway or contemplated at NRL (on top of PF_KEY), and
by Simon Spero and Phil Karn.  Phil expects a "bottom up" deployment
from AH and ESP to cases where a public key already exists, say in a
password file, and access control is being enforced.

Two questions were posed: 
	How to support multiple ESP transforms ?
	How to support user-to-user keying ?

Phil Karn then solicited issues from the WG and came up with
the following list:
	1. Are options for the station-to-station (STS) phase necessary ?
	2. What is the public key certificate infrastructure ?
	3. Security association attribute negotiation is needed.
	4. Document is too long and hard to comprehend.
	5. Session key from shared secret: use of dependent keys.
	6. Should  encryption for privacy in STS really be mandatory ?
	7. Is there potential for convergence with SKIP ?


SKIP:
	Ashar Aziz presented SKIP to the Working Group.  Since Danvers
there have been several major changes such that the current draft is
not compatible with older SKIP implementations.  Specifically,

	- The SKIP header now only performs key management and ESP/AH 
	  are used for IP authentication or encryption.
	The new structure is: 
	[IP header][SKIP header][AH or ESP][upper-layer protocol]

	- A public-key Certificate Discovery Protocol based on UDP
	  was developed in order to obtain long-term keys.
	  This allows multiple certificate types (PGP, X.509, etc.)
          and can be run bilaterally or with a central server. 
	  One effect of this change is that SKIP now has some state.

	Ran Atkinson asked to move this protocol into a separate draft 
	from SKIP so that it could be used more generally rather than
	only for SKIP. Ashar agreed to make this change.  Phil
	Zimmermann stated that this protocol will work with a new 
	release of PGP expected in January 1996.

	- A "SKIP Algorithm Discovery Protocol" based on ICMP has
	  been added.  This message is authenticated but is sent
	  in the clear.  This addition also adds state into SKIP.

	- Naming is now disassociated from source and destination 
	  IP addressees: This helps support mobile hosts with dynamic 
	  IP addresses better.

	- A specification bug relating to IP multicasting was fixed.

	Two "SKIP with ESP and DES-CBC and certificate discovery" 
implementations interoperate.  Raised hands from the audience indicate
that other implementations of this are being considered.



ISAKMP:
	Mark Schertler presented the ISAKMP specification.  Their goal
is to have a single key management protocol that is usable by ESP/AH
and also other protocols (e.g. SSL, PCT, RIP-II, 802.10 SDE, TLS,
OSPF).  They seek independence from security policy, mechanism, and
algorithm.  All approaches that have been proposed in the WG allow
protocol as well as crypto attacks.  The focus of his work has been on
resolving the protocol attacks.

	The main changes are: 
		1. User Negotiation protected by server established SA,
		2. Situation (usage policy),
		3. Authentication only mode,
		4. Version number.

They brought a prototype demonstration on DTOS microkernel that was
shown afterwards in the hallway.  This implementation could be moved
to BSD with little difficulty. They have the TIS version of DNS
Security (DNSsec) running on SunOS 4.1.3, and they can extract
certificates from Fortezza tokens and may use PGP certificates in the
future.  The implementation is not copyrighted and available to US
citizens or government agencies.  They are willing do interoperability
testing with independent implementations from outside the US.

Mark then commented on the other key management protocols:
	SKIP works best with connectionless protocols and does
		not support security association management.
	Photuris is ESP and AH specific and not compatible 
		with security tokens (this was challenged by 
		Simpson and was deferred for further discussion).  



WORKING GROUP SUMMARY:
	Paul observed that SKIP is now in WG last call for Proposed
Standard (Elective).  Jeff Schiller asked whether SKIP meets the WG
charter?  What about perfect forward secrecy?  At Ran's request, Jeff
then summarised the property of Perfect Forward Secrecy and why it is
important.

Jeff then described the IETF standards process.

Hugo asked whether perfect forward secrecy is still a consensus goal 
for a mandatory standard?   Ashar responded by explaining the limited
forward secrecy possible with SKIP.  Karn stated that Perfect Forward
Secrecy should be at least available.  Bob Moscowitz stated that Perfect
Forward Secrecy is sometimes necessary in a business environment.
Perry Metzger mentioned need to support multiple mechanisms.  

WG CONSENSUS:
	There was very clear working group consensus that Perfect
Forward Secrecy remains a requirement for any specification moving
forward as a mandatory-to-implement IETF standard.  SKIP does not
claim to provide this property, while Photuris claims to provide it.
ISAKMP can support a session-key exchange that provides this property
but does not currently specify any session-key exchange algorithm.