[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