Subject: "Michael H. Warfield": Re: current IPSEC/SKIP implementations?
To: None <>
From: Michael Richardson <>
List: tech-crypto
Date: 01/12/2000 13:54:56
Content-Type: text/plain; charset=US-ASCII

  This is from the Linux netdev list.
  Buyer beware.

Content-Type: message/rfc822

Delivery-Date: Tue Jan 11 20:52:50 2000
Date:   Tue, 11 Jan 2000 20:50:25 -0500
From: "Michael H. Warfield" <>
To: Richard Guy Briggs <>
Cc: "Michael H. Warfield" <>, Greg Simpson <>,
Subject: Re: current IPSEC/SKIP implementations?
Message-ID: <>
References: <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <>; from on Tue, Jan 11, 2000 at 12:46:19AM -0500

On Tue, Jan 11, 2000 at 12:46:19AM -0500, Richard Guy Briggs wrote:
> On Mon, Jan 10, 2000 at 03:00:09PM -0500, Michael H. Warfield wrote:
> > On Mon, Jan 10, 2000 at 02:32:36PM -0500, Greg Simpson wrote:

> > > Do you guys know the status of IPSEC within the linux kernel?

> For the foreseeable future, IPSEC CANNOT be included in the kernel
> because it is export restricted and it is being maintained and
> distributed primarily from the USA.

	Actually...  If everything goes according to schedule (and it looks
like it will), it looks like that "forseable future" ends in three days.

	For those a little behind in US current events...

	On September 16, 1999, the US administration announced that it
was drafting regulations to relax export of commercial mass market
cryptography.  At that time, they gave no indication that anything was 
going to change in the open source or free-(beer or speech)-ware arena.

	Not long after that, Eric Raymond and I decided to include my
SSL patches to fetchmail into the main fetchmail sources.  I told Eric
I was going to run it past the powers-that-be where I work (Internet
Security Systems Inc), just so they didn't have any surprises (Keith,
the VP of Engineering, hates surprises and he lets me occasionally get
away with murder as long as he has no surprises and he retains plausable

	ISS surprised me by footing the bill for a little chat with our
Washington crypto/export lawyer, just to make sure everyone knew where
everyone stood and what was going on.  I learned at that time that there
was a major shakeup on the way for open source as well.  I dropped a few
hints on this list a little while later.  The SSL patches went into the
fetchmail sources and have been on Eric's site for a couple of months now.

	On November 19, the first draft of the proposed regulations were
published.  They contained good (but not unmixed) news for the open source
community but raised a lot of questions and contained a lot of ambiguities.
The proposed date for finalization was around December 15.  That never

	There was apparently significant feedback to the first draft so the
finalization was delayed and a second draft published on December 17.  That
draft is available at:


	What was good got even better.  The open source regs were reduced to
three paragraphs in section 740.13...

]   (e) Unrestricted Encryption Source Code 
] 	(1) Encryption source code controlled under 5D002 which would be
] 	considered publicly available under Section 734.3(b)(3) and which
] 	is not subject to an express agreement for the payment of a
] 	licensing fee or royalty for further commercial production or
] 	sale of any product developed with the source code is released from
] 	EI controls and may be exported or re-exported without review under
] 	License Exception TSU, provided you have submitted written
] 	notification to BXA of the Internet address (e.g. URL) or a copy
] 	of the source code by the time of export. Submit the notification
] 	to BXA and send a copy to ENC Encryption Request Coordinator
] 	(see Section 740.17(g)(5) for mailing addresses). 
] 	(2) You may not knowingly export or re-export source code or
] 	products developed with this source code to Cuba, Iran, Iraq,
] 	Libya, North Korea, Sudan or Syria. 
] 	(3) Posting of the source code on the Internet (e.g., FTP or
] 	World Wide Web site) where the source code may be downloaded by
] 	anyone would not establish "knowledge" as described in subparagraph
] 	(2) of this section. In addition, such posting would not trigger
] 	"red flags" necessitating the affirmative duty to inquire under
] 	the "Know Your Customer" guidance provided in Supplement No. 3
] 	to Part 732. 

	You'll notice that the second paragraph is the stock "restricted
countries" list and the third paragraph is a "safe haven" clause for
ftp/http posting.

	This basically says that crypto source code which is unencumbered
may be exported merely by notifying them of the URL (mailto URL's????)
where it is available from.  No review, no approval, no license, no key
length silliness, and no inherited encumberances.  :-)

	I won't post the whole $#@$#@ thing (since you can read it at the
CDT site anyways) but for things like "Idea" and "RSA", which ARE encumbered
by patents, similar clauses exist at 740.17(a)(5) which say basically the
same thing.

	This is scheduled to become finalized on January 14.  Everything
I have heard indicates that there will be no significant changes at this
point and these will be the new regulations and will be finalized on

> It CAN be added afterwards by anyone (except where local law prohibits
> its use, ie. USSR, Cuba, etc...)

> This situation could change if the US government gives up its
> pointless export restrictions on purely defensive technology, OR, the
> main maintenance/distribution of the kernel leaves the US (Hey Linus,
> going back to Finland anytime soon?)

	Looks like he won't even have to do it for 2.4.  Linus and HPA have
already indicated readiness to included hardened cryptography in the kernel
sources, based on the first draft regulations.  Second draft goes beyond
even that, and they won't even need to go to any special effort to
segregate out the crypto code.  All they have to do is file the paperwork
on the URL for the kernel sources and a-way-we-go.

	As soon as these regs ARE finalized and we have confirmed that they
ARE what we now expect them to be, I think a lot of us are going to lobby
Linus, HPA, and Alan Cox to get it done.  I would personally love to see
KLIPS in 2.4 and that's not totally outlandish considering that the time
frames and a 2.4 release date of mid Feb at earliest.

> > > I haven't been able to find any good, recently updated resources on this
> > > topic, and ppp over ssh isn't perfect - or compatible with routers :)

> >

> > 	Currently in release version 1.2.  Daily snapshots are required
> > if you are working with the 2.3.x kernels or want the latest toots and
> > whistles.  Version 1.2 will patch the 2.2.x kernels.  Pluto (IKE) supports
> > automatic keying.  Some patches exist for PKI and certificates.

> The version 1.2 patches are fairly important, or get a new snapshot.
> Another release is due around the end of January.  "Release Early,
> Release Often"

> > 	Mailing list:

> > 	FTP Site:

> > > TIA,

> > > -g

> > 	Mike

> Thanks Mike!

> > -- 
> >  Michael H. Warfield    |  (770) 985-6132   |
> >   (The Mad Wizard)      |  (770) 331-2437   |
> >   NIC whois:  MHW9      |  An optimist believes we live in the best of all
> >  PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

> 	slainte mhath, RGB
> -- 
> Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
> <>               </>
> Prevent Internet Wiretapping!         --       FreeS/WAN:<>
> Thanks for voting Green! -- <>      Marillion:<>

 Michael H. Warfield    |  (770) 985-6132   |
  (The Mad Wizard)      |  (770) 331-2437   |
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!