[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-thayer-seccomp-00.txt



At 07:07 PM 8/12/96 -0400, Stephen Kent wrote:
>Marcel,
>
>        Our plans for re-writing the ESP and AH specs will avoid the need
>to document the combinatorial set of transforms.  Instead, it will be
>possible to define the algorithms or transform elements via distinct RFCs.
>The ESP and AH specs will be upgraded to define formats for all of the
>optional fields required by the different transforms.

Steve,

Are you anticipating that the revised ESP spec will define formats for the
optional fields necessary to support lossless data compression? We are
planning a proposal along the lines of a combined compression/encryption
transform. I worry that your plans make it difficult to 'predict' "all of
the optional fields required by the different transforms". Did I
misunderstand what you meant?

Bob Monsour
Bob Monsour
rmonsour@earthlink.net


From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199608200611.PAA07631@necom830.hpcl.titech.ac.jp>
Subject: Re: "user" and "network layer" security.
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Date: Tue, 20 Aug 96 15:10:50 JST
Cc: ipsec@TIS.COM
X-Mailer: ELM [version 2.3 PL11]
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

> > The most appropriate place to discuss and design "user" security 
> > mechanisms woud seem to be in another discussion group.
> 
> IPSEC is designing two protocols.  One of them operates at the IP layer
> and performs transforms on packets.  The other operates at the application
> layer and establishes the keys for the first.

Agreed.

"user" gives information to establish appropriate "network" layer
security.

The problem is that the required security varies application by
application.

Thus, neither secure "network" layer nor SECDNS can give "user"
appropriate security.

For example, even if your mail address is "name@provider.com",
you don't want your provider have control on your keys to decrypt
your mail.

> > It is difficult
> > to understand how one could use the term "user" anywhere below the 
> > application layer.

It's an API issue, I think.

							Masataka Ohta