[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patents by Sun?
If it is true that it was granted it is not yet
online. However, Ashar (and hence Sun) have been
granted another patent (in 1995) that I found in
the database. The returned abstract is listed
below. Sorry if the formatting is bad but I cut
and pasted from Netscape. This patent is certainly
also relevant to IPSEC.
------------begin patent stuff----------------
United States Patent
5,416,842
Aziz
May 16, 1995
Method and apparatus for key-management scheme for use with internet
protocols at site firewalls
Inventors:
Aziz; Ashar (Fremont, CA).
Assignee:
Sun Microsystems, Inc. (Mountain View, CA).
Appl. No.:
258,344
Filed:
Jun. 10, 1994
Intl. Cl.:
H04L 9/30; H04L 9/08; H04L 9/00
U.S. Cl.:
380/ 30; 380/ 4; 380/ 21; 380/ 23; 380/ 25; 380/ 49
Field of Search:
380/4, 21, 23, 25, 30, 46, 49, 50; 371/68.3
References Cited [Referenced By:]
U.S. Patent Documents
4,916,704
Apr., 1990
Bruckert et al.
371/ 68.3
Other References
Whitfield Diffie, "The First Ten Years of Public-Key Cryptography",
(Proceedings of the IEEE, vol. 76, No. 5, May 1988).
Paul Fahn, "Answers to Frequently Asked Questions About Today's
Cryptography", (RSA Laboratories, 1992).
"Part I: Message Encryption and Authentication Procedures", (Privacy
Enhancement for Internet Electronic Mail, J. Linn (Network Working Group), Feb.,
1993.
"Part II: Certificate-Based Key Management", (Privacy Enhancement for
Internet Electronic Mail, S. Kent (Network Working Group), Feb., 1993.
"Part III: Algorithms, Modes, and Identifiers", (Privacy Enhancement
for Internet Electronic Mail), D. Balenson (Network Working Group), Feb., 1993.
"Part IV: Key Certification and Related Services" (Privacy Enhancement
for Internet Electronic Mail), B. Kaliski (Network Working Group), Feb., 1993.
Whitfield Diffie, Paul C. Van Oorschoot and Michael J. Wiener,
"Authentication and Authenticated Key Exchanges" (Designs, Codes and
Cryptography,
2-107-125 (1992), Kluwer Academic Publishers).
"The MD5 Message-Digest Algorithm"; MIT Laboratory for Computer Science
and RSA Data Security, Inc. (1992), R. Rivest (Network Working Group).
RSA Data Security, Inc. Technology Bulletin, copy undated.
Primary Examiner: Gregory; Bernarr E.
Attorney, Agent or Firm: Irell & Manella
Abstract
The present invention includes a first data processing device (node I)
coupled to a first private network and to a firewall server (FWA). Firewall
server FWA is in
turn coupled to a public network, such as the Internet. A second data
processing device (node J) is coupled to a second private network which is
coupled to the
Internet through a firewall server (FWB). Node I provides a data packet
including IP data and a destination address for the intended receiving node
J to firewall
FWA. Firewall FWA is provided with a secret value a, and a public value
.varies.(^a) mod p. Similarly, firewall FWB is provided with a secret value
b and a
public value .varies.(^b) mod p. The firewall FWA obtains a Diffie-Hellman
(DH) certificate for firewall FWB and determines the public value
.varies.(^b) mod p
from the DH certificate. Firewall FWA then computes the value of
.varies.(^ab) mod p, and derives a key K(ab) from the value .varies.(^ab)
mod p. A transient
key K(p) is randomly generated and is used to encrypt the data packet to be
transmitted by firewall FWA to firewall FWB. The encrypted data packet is then
encapsulated in a transmission packet by the firewall FWA. The transmission
packet includes an unencrypted destination address for the firewall FWB.
Firewall
FWA then sends the transmission packet to firewall FWB over the Internet.
Upon receipt of the transmission packet from firewall FWA, firewall FWB
obtains a
DH certificate for firewall FWA, and determines the public value of
.varies.(^a) mod p from the DH certificate. Firewall FWB computes the value
of .varies.(^ab)
mod p, and derives the key K(ab). Firewall B utilizes the key K(ab) to
decrypt the transient key K(p), and using the decrypted transient key K(p),
firewall FWB
decrypts the encrypted data packet received from FWA, thereby resulting in
the recovery of the original data sent by node I in unencrypted form to the
firewall
FWA. The firewall FWB then transmits the decrypted data packet to the
receiving node J over the second private network.
Ken Siegel
Switchblade Networks, Inc.
6 Lisa Drive
Nashua, NH 03062
Phone: (603) 891-1500
Internet: ksiegel@switchblade.com
URL: www.switchblade.com
Date: Fri, 30 Aug 1996 10:50:52 -0700
From: Glenn Scott <asdf@osmosys.incog.com>
Message-Id: <199608301750.KAA22206@ono-sendai.incog.com>
To: ipsec@TIS.COM
Subject: Re: Patents by Sun?
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>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.
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.
This list is starting to read a bit like alt.conspiracy.
Glenn
Message-Id: <3.0b11.32.19960830143943.00a3ad48@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 30 Aug 1996 15:16:24 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Will the real PFS please stand up?
Cc: "David M. Balenson" <balenson@TIS.COM>, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 10:59 AM 8/29/96 -0400, Bill Sommerfeld wrote:
>
>> >Now, if I and J are just host identities, this isn't interesting
>> >(because the same information is found in their IP addresses) but if
>> >SKIP gets extended to do per-user keying I think we have a potential
>> >problem.
>>
>> Huh? Please enlighten me.
>
>If the `name' in the certificate is just an IP address, then
>compromise of the contents of Cert_I and Cert_J reveals no information
>not already available to eavesdroppers, and skip-pfs's lack of PFS
>protection on the exchanged certificates is moot.
>
>If the `name' in the certificate contains something other than an IP
>address, or something more than an IP address, then skip-pfs's lack of
>PFS protection on the exchanged certificates becomes interesting.
AH HA! Ok, the certs that I see using will be either X.509 or SDSI. And
yes, I will not want even this exposure. The cert will say that this is Bob
Eaton currently over in Frankfurt. Whoa, no.
>As above.. if principal names are always IP addresses, there's no
>benefit in keeping them secret in the key mgt protocol because they're
>sent in the clear in every packet..
I expect to have x.509 certs for this and they will not be IP addressed.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Message-Id: <3.0b11.32.19960830151026.009cc120@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 30 Aug 1996 15:16:29 -0400
To: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Everything degenerates to Key Management
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 01:03 PM 8/29/96 -0500, David Wheeler-P26179 wrote:
>I've been listening/reading the group's discussions for some time.It is
>clear
>that IPSEC, we, must produce and field a viable solution within the next
>year
>or be overcome by events. This truth, while brutal, I think can be
>confirmed
>independently by all of us.
OK People. On Sept 19th, the AIAG's ANX security wg will have its 2nd
meeting in Detroit. At this meeting we will be calling for interoperbility
testing to deliver products YE96 - 1Q97.
>I agree heartily with Mr. Harald Koch:
>>The people working on other protocols requiring security (TLS, L2TP, LDAP,
>>and probably others) have all been overheard saying the same thing:
>>
>> Wouldn't it be nice to have a single key negotiation protocol for
>> IPsec *and* for our protocols?
The AIAG's ANX EC messaging wg has been floating a secure EDI envelope on
the SMIME-DEV list. Guess what, X.509 again but HTTP protocol, LDAP or
SDSI? Gee we will want something commonized here.
>>how can my laptop get back through my company's
>>firewall in a safe and secure fashion?
Back then this was a noble goal. In today's environment there are solutions
you can buy to address this tactically. Yes the market overtook the group;
probably learned a lot from the group too. Today's business world is my
laptop connecting back to 3 company divisions and 2 trading partners at the
same time.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Message-Id: <3.0b11.32.19960830145003.012bad40@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 30 Aug 1996 15:16:27 -0400
To: caronni@tik.ee.ethz.ch, Robert Moskowitz <rgm3@chrysler.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Will the real PFS please stand up?
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 04:08 PM 8/29/96 +0200, Germano Caronni wrote:
>
>by the way:
>In my opinion escrowing communicated data is nuts anyway, you want key
>escrow for long term archived data, where key owners (and their secrets)
>may 'get lost'...
Agreed. Actually on escrowing I am mind-game playing. Determine a
methodology that meets business functional goals. show that it
'invalidates' key excrowing. Watch the fun start in the belt-way. sigh.
BTW, I THINK that all of these are vulnerable to man-in-the-middle attacks
where the private keys of both parties are know? I can see a business for
sniffers that can work in this way.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Follow-Ups: