[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "user" and "network layer" security. reply to respondents.
It is not true that if we cannot have a user-keyed network layer
mechanism we should throw our hands-up and leave the table. There
is a place in the network architecture for user keyed security.
But it is not in the lower layers.
Obviously, it is also not true that user oriented keying is orthogonal
to network stack layering (architecture).
We should provide appropriate security services using appropriate
mechanisms implemented in a manner consistent with existing
architecture. If user security is needed, there is at least one
right way to do it. Do it right - it will cost less, be easier to
implement, and work better.
Regards,
Mitch Nelson
netsec@panix.com
On Fri, 30 Aug 1996, C. Harald Koch wrote:
> In message <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>, "M.C.Nelson" writes:
> >
> > The transport layer doesn't have "user" either. Adding a "user" concept
> > in a new layer between the transport and network layer still breaks the
> > network architecture.
>
> Fine. I guess we should all throw our hands up in disgust and walk away from
> the table. The pristine purity of the ISO reference model must be preserved
> at all cost, right?
>
> Do you propose removing all user-based authentication from PPP (CHAP and
> PAP) also? After all, PPP is a link layer protocol, and the link layer
> doesn't have a "user" either. How about SSL, at the transport layer?
>
> User-oriented keying is useful, and works. The concept is orthogonal to
> network stack layering. If it voliates some holy "architecture design
> principles", then those principles should be changed.
>
> IMHO, of course.
>
> --
> Harald Koch
> chk@border.com
>
Message-Id: <199608302051.QAA12777@jekyll.piermont.com>
To: Glenn Scott <asdf@osmosys.incog.com>
Cc: ipsec@TIS.COM
Subject: Re: Patents by Sun?
In-Reply-To: Your message of "Fri, 30 Aug 1996 10:50:52 PDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 30 Aug 1996 16:51:40 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
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.
+ 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
References: