[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patents by Sun?
> Reply-to: perry@piermont.com
> Date: Fri, 30 Aug 1996 16:51:40 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Glenn Scott writes:
> > >I must admit I haven't yet tracked this down to confirm it (it might
> > >be a hoax) but it appears by the looks of it that Ashar has patented
> > >IPSEC. Again, I have to track down an independent copy to confirm
> > >it. If the claims listed are genuine, they are all on their face
> > >invalidated by prior art, but...
> >
> > I actually have a copy of the whole patent and since I'm one of the
> > inventors I can at least state what we did: It's a way to use fake addressing
> > to do some tunneling and topology hiding.
>
> That isn't what the claims section I received (which I posted) says.
>
> > This patent does not attempt to patent IPSEC. Having been through this
> > stuff before I caution any reader to judge a patent's defensibility or what
> > invalidates it by just its abstract.
>
> The abstract isn't the important part. The claims are -- they are the
> portion which is legally actionable. Were the claims posted the actual
> ones, or was I sent an inaccurate set of claims? The claims there
> appear to cover *any* IPSEC style mechanism. This is the set that I
> have in my possession.
>
Perry,
I have learned of the issue of this patent from the
postings on this list.
My recollection of this patent (the work was done
a few years ago, and isn't fresh in my mind) is that it
isn't a patent on a generic IPSEC mechanism. Rather, this
was related to the specific use of key-management and
encryption on devices that were not IP addressable,
yet intercepted IP traffic (hence the "signatureless" title,
and the use of the bridge terminology).
This related to a product that we were designing
(SunScreen) which had the cloaking (or "stealth") feature,
such that it was not IP addressable, for security
reasons. I believe the techniques we were designing
involved identifying tunnel end-points such that
the actual encryption/decryption end-points
(outer IP header) were not meaningful from an IP
connectivity point of view, yet IP routing still worked,
and the internal topology of networks protected by
these devices remained hidden.
I believe that this is essentially what Glenn said.
Now, I don't have a copy of either the issued patent
or the patent application (and since I am in a remote office,
don't have easy access to these documents), but I
have requested a copy be mailed to me. I will review
the claims section, and send a follow-up message,
if anything changes my recollection of this patent.
(This may take a week or so.)
Ashar.
Message-Id: <3.0b11.32.19960902195918.0069e610@cybercash.com>
X-Sender: crocker@cybercash.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Mon, 02 Sep 1996 20:04:47 -0400
To: Hilarie Orman <ho@earth.hpc.org>
From: Steve Crocker <crocker@cybercash.com>
Subject: Re: Everything degenerates to Key Management
Cc: David_Wheeler-P26179@email.mot.com, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
For what it's worth, here's my opinion:
This is a vital area for the net. We should have had encryption at the IP
level many years ago, and it remains vital.
We should partition the features and implement a minimum set NOW and work on
additional stuff later. In my opinion, the following is essential, urgent,
sufficient for a number of vital purposes and does not inhibit future work:
o Encryption algorithms which are not easily breakable. DES will do for now.
o Key management: Anything which makes it possible for parties who know each
other to invoke compatible keys.
All else, including certificates, authentication, PFS, etc. is secondary.
The work this group has done goes far beyond the minimal list above, so it
should be possible to extract a workable scheme out of what's been done, get
it out, and move forward.
Steve
At 05:07 PM 9/1/96 -0400, Hilarie Orman wrote:
>How far does the group want to go to achieve consensus? One can
>easily design a single protocol that meets all the proposed goals for
>key management. What seems impossible is convince people that this
>all MUST be implemented. For every option there is a contingent that
>opposes it, for every option there is a contingent that supports it,
>for every subset there is a group that thinks it is too much to implement.
>(heavy sigh).
>
>The shopping list is:
>
> sessions, in-line key encrypting keys
> sublist for second item above: separate hdr, extensions to ESP/AH hdrs
> key determination via PFS or non-PFS
> identity protection via PFS or non-PFS
> authentication via DH, RSA encryption, RSA signatures, or DSS
> (El Gamal hasn't yet been seriously considered)
> X.509v3 and DNS KEY/SIG records for PK authentication
> certificate inclusion, certificate retrieval
> elliptic curve groups
> new group definitions via protocol
> ISAKMP framework, other framework
> (I think that's all)
>
>Agree whole-heartedly on what you want, set a design team to work, good will
>follow.
>
>Hilarie Orman
>
>
>
>
>
----------------------------------
Steve Crocker Main: +1 703 620 4200
CyberCash, Inc. Desk: +1 703 716 5214
2100 Reston Parkway Fax: +1 703 620 4215
Reston, VA 22091 crocker@cybercash.com
Message-Id: <199609030132.SAA06805@toad.com>
To: ipsec@TIS.COM, gnu@toad.com
Subject: Re: Patents by Sun?
In-Reply-To: <199608302201.AAA07280@kom30.ethz.ch>
Date: Mon, 02 Sep 1996 18:32:52 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I have updated the "Network Encryption - history and patents" web page
at http://www.cygnus.com/~gnu/netcrypt.html to include the full text
of Sun's recent patent, as well as their earlier one which has been
dedicated to the public.
John Gilmore
Message-Id: <199609030706.AAA17528@toad.com>
To: Hilarie Orman <ho@earth.hpc.org>
Cc: David_Wheeler-P26179@email.mot.com, ipsec@TIS.COM, gnu@toad.com
Subject: Re: Everything degenerates to Key Management
In-Reply-To: <199609012107.RAA15389@earth.hpc.org>
Date: Tue, 03 Sep 1996 00:06:00 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hilarie, thanks for the list of proposed goals.
> The shopping list is:
> ...
> (I think that's all)
Don't forget:
Scales cleanly to the entire Internet, not just to small VPN's
If all we're standardizing is a protocol for small virtual private
networks, we're wasting the IETF's time. Half a dozen companies could
get together and do that. Our job is to engineer the Internet.
John
From: Rich Skrenta <skrenta@osmosys.incog.com>
Message-Id: <199609031702.KAA02553@miraj.incog.com>
Subject: Re: Everything degenerates to Key Management
To: John Gilmore <gnu@toad.com>
Date: Tue, 3 Sep 1996 10:02:51 -0700 (PDT)
Cc: ipsec@TIS.COM
In-Reply-To: <199609030706.AAA17528@toad.com> from "John Gilmore" at Sep 3,
96 00:06:00 am
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Don't forget:
>
> Scales cleanly to the entire Internet, not just to small VPN's
>
> If all we're standardizing is a protocol for small virtual private
> networks, we're wasting the IETF's time. Half a dozen companies could
> get together and do that. Our job is to engineer the Internet.
I'll submit that this has more to do with ACL management, i.e. the
"naming problem", than the underlying encryption protocol.
Designing crypto exchanges and packet formats is comparatively easy;
informing your machine that it's supposed to encrypt with a particular set
of modes+algorithms to a particular (possibly randomly assigned) IP
address is hard. But insofar as a workable solution is developed, I
believe that it should prove fairly independent of the underlying
encryption system.
This problem is really at a different level than the SKIP vs. Oakley
debate, since neither set of drafts speak much to this issue.
To: Ashar Aziz <ashar@sunpak.sdnpk.undp.org>
Cc: ipsec@TIS.COM
Subject: Re: Patents by Sun?
In-Reply-To: Your message of "Mon, 02 Sep 1996 17:22:06 -0000."
<199609030550.KAA18950@sdnpk.undp.org>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 03 Sep 1996 13:18:59 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609031321.aa22975@neptune.TIS.COM>
Ashar Aziz writes:
> My recollection of this patent (the work was done
> a few years ago, and isn't fresh in my mind) is that it
> isn't a patent on a generic IPSEC mechanism.
That might not have been the intent, but the claims easily cover any
conceivable IPSEC mechanism. It is entirely possible that this was not
your intent, but it does appear to be what has happened in practice.
> Rather, this was related to the specific use of key-management and
> encryption on devices that were not IP addressable, yet intercepted
> IP traffic (hence the "signatureless" title, and the use of the
> bridge terminology).
1) The claims speak of the same mechanisms being used without bridges.
2) The "bridge" terminology is probably insufficient to distinguish
the fundamental concepts from IPSEC.
> Now, I don't have a copy of either the issued patent
> or the patent application (and since I am in a remote office,
> don't have easy access to these documents), but I
> have requested a copy be mailed to me. I will review
> the claims section, and send a follow-up message,
> if anything changes my recollection of this patent.
> (This may take a week or so.)
Okay...
Perry