[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Any News on UUNET encryption patents?
Hello,
A few months ago, the validity of the following patents by UUNET was
discussed on this mailing list. Would you let me know recent recent
news on these patents, e.g, if someone challenged the patents?
>5,442,708 - Computer Network Encryption/Decryption Device
>Inventors: Richard L. Adams, Jr., Fairfax, Va.;
> Peter D. Hallenbeck, Elfland, N.C.
>Assignee: UUNET Techologies, Inc., Falls Church, Va.
>Appl. No: 305,509
>Filed: Sep. 13, 1994
>Related U.S. Application Data:
> Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned.
>5,444,782 - Computer Network Encryption/Decryption Device
>Inventors: Richard L. Adams, Jr., Fairfax, Va.;
> Peter D. Hallenbeck, Elfland, N.C.
>Assignee: UUNET Techologies, Inc., Falls Church, Va.
>Appl. No: 184,631
>Filed: Jan. 19, 1994
>Related U.S. Application Data:
> Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned.
--
Shoichiro Seno, (E-mail) senos@kousoku.isl.melco.co.jp
High-Speed Network Department, Information Technology R&D Center
Mitsubishi Electric Corporation
(Tel) +81-467-41-2434, (Fax) +81-467-41-2419
Date: Thu, 29 Aug 1996 19:24:27 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608292324.TAA00290@mcn.netsec.com>
To: ipsec@TIS.COM, karn@qualcomm.netsec.com, rgm3@chrysler.com
Subject: "user" and "network layer" security.
Cc: nelson@mcn.netsec.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Re Robert Moskowitz's "inter" and "intra" business model, I think
that this is again a bit of a red-herring. At the network layer
there is not to much distinction. The entities that are sensitive
to this are very much at the application layer. Hence the *whole*
construct of distinquishing between inter and intra really belongs
in an application layer security model. The construct could perhaps
have some small consequence with respect to routing. But even so,
such a consequence would probably only come into a network layer
security model as a second order contribution. (Parenthetically
recall that some c.f. Tannenbaum, feel that IP routing already has
a somewhat confused architecture).
Re the suggestion to immediately adapt SKIP, I feel that it is
important to first clearly state the objectives of network layer
security, and then discuss proposals in those terms. If it is
agreed that SKIP is at least more or less in the right direction,
then very good. After that, I suspect there are some questions
of a mathematical-cryptographical nature that should be discussed.
I'm hesitant to bring out my own questions in this category at
this moment, because I feel that at this moment it would be a
digression. The first thing is to clearly state an appropriate
set of objectives.
Regards,
Mitch Nelson
netsec@panix.com
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Cc: ipsec@TIS.COM, gnu@toad.com
Subject: PFS, key escrow, and legality
In-Reply-To: <199608291500.LAA00829@thunk.orchard.medford.ma.us>
Date: Thu, 29 Aug 1996 17:08:10 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608300802.aa20484@neptune.TIS.COM>
> I'm not sure these assumptions about key escrow policy are realistic;
> in any situation where key escrow is mandated, skip-pfs, photuris, and
> OAKLEY will all be illegal as specified.
Bill, there are numerous situations in which key escrow of some sort
might occur, without making the development, deployment, or use of
secure protocols such as Photuris illegal. Kindly don't hand the
government what it wants (our capitulation) before we are forced at
gunpoint to surrender our privacy.
For example, see the Administration's Clipper-3 policy (announced only
in July; see http://www.crypto.com/#clipper3). It proposes that
users' long-term private keys must be generated by, or stored in, an
escrow agency, before a certification authority would publish the
corresponding public key. It would allow the use of any algorithm or
protocol, even in exportable products. It states "There are no
federal laws regulating the use of cryptographic products within the
United States.", and continues the Clinton Administration policy of
having no plans or proposals to control the domestic use of
encryption.
It will be a very hard job to ram legislation through Congress that
makes everything that you and I are working on illegal. Everyone who
owned a copy of PGP or Kerberos would be a felon, including numerous
government officials, agencies, and corporations at all levels.
Congressional interest in encryption issues is continuing to rise, and
it's clear to all interested parties (inside and outside Congress)
that nobody supports Government Access to Keys (GAK) except for
government officials, people they are paying, and a very small number
of public policy activists (Dorothy Denning is the only one I can
think of). Making domestic crypto illegal in Congress is a very long
shot -- and even if they succeed, EFF is building a legal team that
would fight it, the same way we are fighting and winning
Constitutional battles against the CDA legislation and the export
control legislation.
It is far more likely that we'll have to deal with non-legislative
programs, or legislation that does not outlaw the domestic use of
strong crypto. For example, the government could try to strong-arm or
purchase VeriSign, RSA, and other certification authorities to
"voluntarily" require GAK, the way they strong-armed AT&T to offer the
original Clipper phone. They are currently working to convince
governments of naive or unfree countries to mandate the use of GAK,
which would mean that vendors who wanted to sell products in those
countries would have to supply GAK even if it wasn't required for US
use. They could require government contractors to use GAK, etc.
Partial GAK, without making strong crypto illegal, doesn't accomplish
their aims, though. Using a properly designed protocol with PFS, even
escrowing all the long-term keys does not permit them to break the
traffic, because the long-term keys are only used for authentication,
never for encryption. Encryption is done with an ephemeral key
generated by Diffie-Hellman.
Even if the government has your long-term private key, has tapped your
phone line, and is doing an active attack on your Diffie-Hellman
protocol, you will detect the attack and avoid communication -- unless
they also have real-time access to the escrowed private keys of
EVERYONE YOU COMMUNICATE WITH.
Think about that. Giving the government real-time (30 seconds or
less) access to every single escrowed private key, without a warrant,
based on the flimsy assertion that "someone who we *do* have a warrant
for is currently trying to communicate with that person", is something
that the public is very unlikely to stand for. It would basically
mean that all administrative controls over the key-escrow database
would be thrown in the trash. Any law enforcement agency would be
able to get anyone's key at any time.
Even if machinery enforced the rules, and would only give them keys
for parties that a legally wiretapped suspect attempted communication
with, they could inject bogus-return-address packets that would cause
the wiretapped machine to attempt to communicate with any site whose
key they wanted to look up. For example, they could pretend to be
opening an SMTP connection, doing a DNS lookup, or starting an IPSEC
key exchange from that site. They or an accomplice could do that from
anywhere on the net, without even mounting an active attack.
So, let's not constrain the debate or our protocols by premature ideas
on "what would be legal or illegal". As requested by the IAB and the
IESG, let's design protocols that are as strong as we can make them,
against every kind of attack we can envision. Including attacks by
our own governments on our civil rights.
John Gilmore
PS: As you might guess, I strongly support keeping the identities of
the communicating parties private in the key negotiation protocol, as
well as continuing to require PFS for the end-user data. It should be
possible with firewall-to-firewall keying and encryption to never
reveal the end-system identities, which would be a big help in
defeating traffic analysis against large sites such as universities or
corporations.
Date: Thu, 29 Aug 1996 20:13:05 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608300013.UAA00353@mcn.netsec.com>
To: ipsec@TIS.COM, PALAMBER@us.oracle.com
Subject: "user" and "network layer" security. reply to respondents.
Cc: netsec@panix.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Paul, I think you need to think through your scenario a little
more carefully. You'll probably see that your argument doesn't fly.
The present IPSEC does in fact, break the network architecture.
(But, thank you for a challenging effort.)
Regads,
Mitch Nelson
netsec@panix.com
reference - palamber's comment:
> IPsec does not break the "Internet Architecture". The use of the term
> "user" with IPsec security associations is confusing, but not
> inappropriate for some scenarios. Key management is an application
> layer activity where the security associations are created and provide
> authentication to peer application layer entities. The security
> association is then available to be used by ESP, AH or perhaps other
> security mechanisms. The authentication provided by applicaitons can
> be at the granularity of a "user". The use of the resulting
> authenticaiton process can be enforced at the network layer using ESP
> or AH.
p.s.
The experience that you cited is not comparable to what is being
proposed here. We are dealing with a very different environment,
context, and scale.
reference - palamber's comment:
> There is significant experience fielding network layer security by
> various governments and defense contractors. There is also significant
> experience by many commercial vendors ...
To: ipsec@TIS.COM
Subject: Announcing DNS Security in production BIND code
Date: Thu, 29 Aug 1996 19:11:34 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608300806.aa20532@neptune.TIS.COM>
Paul Vixie has released a test version of BIND which contains some DNS
Security features. The release is available now at
ftp://ftp.vix.com/pub/bind/testing/bind-4.9.5-T3B.tar.gz.
Only the existence of KEY and SIG records is implemented in this BIND.
There is no cryptography implemented; the signatures are never
checked. This permits keys and signatures to be stored and retrieved
in a completely exportable version of BIND, which is part of the main
production BIND evolution.
The released code is partly based on IBM changes for Dynamic DNS, and
is partly original with me. It was not based on TIS's version because
of their export control concerns and restrictive copyrights (which
have since been almost resolved). The State Department has approved
TIS's request to export their cryptographic version of BIND. TIS is
now waiting for final Commerce Dept. approval. When they receive it,
I will work with them and Paul to merge their version into the
production BIND sources, and to add further cryptographic code to the
resolver, to provide production-quality, worldwide, end-to-end
cryptovalidation of DNS resource records.
In the meantime, TIS's release (ftp://ftp.tis.com/pub/DNSSEC/README)
is useful in the US for experimentation, and for generating offline
KEY and SIG records (which can then be published with the just-released
production BIND server).
I encourage all organizations who are interested in Secure DNS to
upgrade their organization's production copy of BIND to Paul's latest
release. This will facilitate Secure DNS testing and deployment.
I have started a mailing list <dnssec-interest@toad.com> for people
who are interested in deploying Secure DNS in production use. There
is also <dnssec-nics@toad.com> for top-level domain service providers
to work out their issues with Secure DNS. Send me email at
postmaster@toad.com if you'd like to join either list.
This is the first software release from my S/WAN (Secure Wide Area
Network) project, whose ultimate goal is to provide transparent
improvements to the privacy and security of all Internet
communications. See http://www.cygnus.com/~gnu/swan.html.
Thank you for supporting the ongoing securing of the Internet
infrastructure.
John Gilmore
To: ipsec@TIS.COM
Subject: Patents by Sun?
Date: Thu, 29 Aug 1996 17:32:20 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608300807.aa20583@neptune.TIS.COM>
Someone forwarded this to me. I don't know if its real.
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...
Perry
------- Forwarded Message
System for signatureless transmission and reception of
data packets between computer networks (Assignee -- Sun
Microsystems, Inc.)
Abstract: A system for automatically encrypting and
decrypting data packet sent from a source host to a
destination host across a public internetwork.
A tunnelling bridge is positioned at each network, and
intercepts all packets transmitted to or from its
associated network.
The tunnelling bridge includes tables indicated pairs of
hosts or pairs of networks between which packets should
be encrypted.
When a packet is transmitted from a first host, the
tunnelling bridge of that host's network intercepts the
packet, and determines from its header information
whether packets from that host that are directed to the
specified destination host should be encrypted; or,
alternatively, whether packets from the source host's
network that are directed to the destination host's
network should be encrypted.
If so, the packet is encrypted, and transmitted to the
destination network along with an encapsulation header
indicating source and destination information: either
source and destination host addresses, or the broadcast
addresses of the source and destination networks (in the
latter case, concealing by encryption the hosts'
respective addresses).
An identifier of the source network's tunnelling bridge
may also be included in the encapsulation header. At the
destination network, the associated tunnelling bridge
intercepts the packet, inspects the encapsulation header,
from an internal table determines whether the packet was
encrypted, and from either the source (host or network)
address or the tunnelling bridge identifier determines
whether and how the packet was encrypted.
If the packet was encrypted, it is now decrypted using a
key stored in the destination tunnelling bridge's memory,
and is sent on to the destination host.
The tunnelling bridge identifier is used particularly in
an embodiment where a given network has more than one
tunnelling bridge, and hence multiple possible
encryption/decryption schemes and keys.
In an alternative embodiment, the automatic encryption
and decryption may be carried out by the source and
destination hosts themselves, without the use of
additional tunnelling bridges, in which case the
encapsulation header includes the source and destination
host addresses.
Ex Claim Text: A method for transmitting and receiving
packets of data via an internetwork from a first host
computer on a first computer network to a second host
computer on a second computer network, the first and
second computer networks including, respectively, first
and second bridge computers, each of said first and
second host computers and first and second bridge
computers including a processor and a memory for storing
instructions for execution by the processor, each of said
first and second bridge computers further including
memory storing at least one predetermined encryption/
decryption mechanism and information identifying a
predetermined plurality of host computers as hosts
requiring security for packets transmitted between them,
the method being carded out by means of the instructions
stored in said respective memories and including the
steps of:
(1) generating, by the first host computer, a first data
packet for transmission to the second host computer, a
portion of the data packet including information
representing an internetwork address of the first host
computer and an internetwork address of the second host
computer;
(2) in the first bridge computer, intercepting the first
data packet and determining whether the first and second
host computers are among the predetermined plurality of
host computers for which security is required, and if
not, proceeding to step 5, and if so, proceeding to step
3;
(3) encrypting the first data packet in the first bridge
computer;
(4) in the first bridge computer, generating and
appending (4) in the first bridge computer, generating
and appending to the first data packet an enapsulation
header, including:
(a) key management information identifying the
predetermined encryption method, and
(b) a new address header representing the source and
destination for the data packet, thereby generating a
modified data packet;
(5) transmitting the data packet from the first bridge
computer via the internetwork to the second computer
network;
(6) intercepting the data packet at the second bridge
computer;
(7) in the second bridge computer, reading the
encapsulation header, and determining therefrom whether
the data packet was encrypted, and if not, proceeding to
step 10, and if so, proceeding to step 8;
(8) in the second bridge computer, determining which
encryption mechanism was used to encrypt the first data
packet;
(9) decrypting the first data packet by the second bridge
computer;
(10) transmitting the first data packet from the second
bridge computer to the second host computer; and
(11) receiving the unencrypted data packet at the second
host computer.
Assignee: Sun Microsystems, Inc.
Patent Number: 5548646
Issue Date: 1996 08 20
Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson,
Martin; Scott, Glenn. State/Country CA
------- End of Forwarded Message