multi-layer IPSEC draft

[Yongguang Zhang <[e-mail]>]

<x-flowed>
Hi, all:

This draft is a follow-up of my short presentation in last IETF.
(I sent out last week but hasn't got response back from Internet-Draft.)
But it is also available from my web site:
http://www.wins.hrl.com/people/ygz/ml-ipsec/draft-zhang-ipsec-mlipsec-00.txt

To repeat the concept, multi-layer IPSEC applies separate 
encryption/authentication
with different keys on different parts of an IP datagram.  It allows certain
intermediate routers to have limited and controllable access to part of IP 
datagram
(usually headers) but not the user data, for applications like flow 
classification,
diffserv, TCPPEP, NAT, transparent proxy, etc. (and those "intelligent 
routing" that
need access to higher-layer protocol headers).

I'd like to hear your comments on this.

Regards,

Yongguang
    

</x-flowed>
From ???@??? Tue Oct 26 19:20:19 1999
X-Persona: <a phoffman VPNC>
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13654
	for <[e-mail]>; Tue, 26 Oct 1999 19:13:25 -0700 (PDT)
Received: from akalice.research.att.com (akalice.research.att.com [135.207.26.22])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 6EB381E034; Tue, 26 Oct 1999 22:16:23 -0400 (EDT)
Received: (from majordomo@localhost)
	by akalice.research.att.com (980427.SGI.8.8.8/8.8.7) id WAA69788
	for tf-esp-list; Tue, 26 Oct 1999 22:15:46 -0400 (EDT)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103])
	by akalice.research.att.com (980427.SGI.8.8.8/8.8.7) with ESMTP id WAA71958
	for <[e-mail]>; Tue, 26 Oct 1999 22:15:45 -0400 (EDT)
Received: by mail-green.research.att.com (Postfix)
	id 242BC1E030; Tue, 26 Oct 1999 22:15:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from fw-es10.hac.com (fw-es10.HAC.COM [128.152.1.26])
	by mail-green.research.att.com (Postfix) with ESMTP id 355BC1E029
	for <[e-mail]>; Tue, 26 Oct 1999 22:15:44 -0400 (EDT)
Received: from malpha.hrl.hac.com ([192.27.95.96])
	by fw-es10.hac.com (8.9.1/8.9.1) with SMTP id TAA06312
	for <[e-mail]>; Tue, 26 Oct 1999 19:15:45 -0700 (PDT)
Received: from isl.hrl.hac.com by malpha.hrl.hac.com (5.65v4.0/1.1.19.2/28Dec98-0405PM)
	id AA03983; Tue, 26 Oct 1999 19:15:42 -0700
Received: from maygz by isl.hrl.hac.com (8.9.1b+Sun/SMI-SVR4)
	id TAA27872; Tue, 26 Oct 1999 19:14:25 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 26 Oct 1999 19:15:44 -0700
To: [e-mail], [e-mail]
From: Yongguang Zhang <[e-mail]>
Subject: multi-layer IPSEC draft
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
X-UIDL: 009e3ee7667d30fce50b1455b27a24ca

<x-flowed>
Hi, all:

This draft is a follow-up of my short presentation in last IETF.
(I sent out last week but hasn't got response back from Internet-Draft.)
But it is also available from my web site:
http://www.wins.hrl.com/people/ygz/ml-ipsec/draft-zhang-ipsec-mlipsec-00.txt

To repeat the concept, multi-layer IPSEC applies separate 
encryption/authentication
with different keys on different parts of an IP datagram.  It allows certain
intermediate routers to have limited and controllable access to part of IP 
datagram
(usually headers) but not the user data, for applications like flow 
classification,
diffserv, TCPPEP, NAT, transparent proxy, etc. (and those "intelligent 
routing" that
need access to higher-layer protocol headers).

I'd like to hear your comments on this.

Regards,

Yongguang
    

</x-flowed>
From ???@??? Wed Oct 27 07:36:19 1999
X-Persona: <a phoffman VPNC>
Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26961
	for ietf-ipsra-bks; Wed, 27 Oct 1999 02:44:53 -0700 (PDT)
Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26957
	for <[e-mail]>; Wed, 27 Oct 1999 02:44:50 -0700 (PDT)
Received: from checkpoint.com (gray.checkpoint.com [199.203.71.94])
	by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id LAA04342;
	Wed, 27 Oct 1999 11:54:31 +0200 (IST)
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 1999 11:51:23 +0200
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scott G. Kelly" <[e-mail]>
CC: Stephane Beaulieu <[e-mail]>, [e-mail],
        [e-mail], [e-mail]
Subject: Re: Comments on CRACK
References: <319A1C5F94C8D11192DE00805FBBADDFEC9812@exchange> <[e-mail]>
Content-Type: multipart/mixed;
 boundary="------------551C72AF621C0C49C1634ED7"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-UIDL: ef65a9e9385238400d1d6b632e999c65

Scott,

"Scott G. Kelly" wrote:

> Stephane Beaulieu wrote:
> > What would those be?
> >
> > I've heard...
> >
> > 1 - It encourages the use of weak pre-shared keys. - Perhaps, but this can
> > easily be fixed in XAUTH.  I would still like to get a concensus on this.
>
> This "easy" fix requires deployment of client certificates.

Deployment of client certificates together with hardware tokens (preferably FIPS
140-1 level 4 certified) is the best fix. The easy secure fix is hybrid.

> > 2 - It's too complicated to be secure... Please !
>
> Prove to me that it's secure. Better review your predicate logic
> first...

Let's start from the beginning, all the suggested protocols are based on IKE, so
we can start with a proof of security for IKE. Then we can try to give a proof in
the same level for the other suggestions.

> > 3 - Too much known plain text.  - All three proposals (XAUTH, CRACK, and ULA
> > have know plain text.
>
> None have the copious amounts of ASCII TEXT that xauth does. Some known
> plaintext may be unavoidable, but xauth has a ridiculous amount.

Know plain text is non-issue (BTW actually the largest amount of known plain text
is with certificate, when the whole public certificate chain is being passed).

Regards,

Moshe

Attachment Converted: "C:\Temp\moshe.vcf"
From ???@??? Wed Oct 27 08:23:09 1999
X-Persona: <a phoffman VPNC>
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06720
	for <[e-mail]>; Wed, 27 Oct 1999 08:05:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04237
	Wed, 27 Oct 1999 09:26:04 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Wed, 27 Oct 1999 11:51:23 +0200
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scott G. Kelly" <[e-mail]>
CC: Stephane Beaulieu <[e-mail]>, [e-mail],
        [e-mail], [e-mail]
Subject: Re: Comments on CRACK
References: <319A1C5F94C8D11192DE00805FBBADDFEC9812@exchange> <[e-mail]>
Content-Type: multipart/mixed;
 boundary="------------551C72AF621C0C49C1634ED7"
Sender: [e-mail]
Precedence: bulk
X-UIDL: 5fa9664ec0c1fecaf9fac01d2dacc615

Scott,

"Scott G. Kelly" wrote:

> Stephane Beaulieu wrote:
> > What would those be?
> >
> > I've heard...
> >
> > 1 - It encourages the use of weak pre-shared keys. - Perhaps, but this can
> > easily be fixed in XAUTH.  I would still like to get a concensus on this.
>
> This "easy" fix requires deployment of client certificates.

Deployment of client certificates together with hardware tokens (preferably FIPS
140-1 level 4 certified) is the best fix. The easy secure fix is hybrid.

> > 2 - It's too complicated to be secure... Please !
>
> Prove to me that it's secure. Better review your predicate logic
> first...

Let's start from the beginning, all the suggested protocols are based on IKE, so
we can start with a proof of security for IKE. Then we can try to give a proof in
the same level for the other suggestions.

> > 3 - Too much known plain text.  - All three proposals (XAUTH, CRACK, and ULA
> > have know plain text.
>
> None have the copious amounts of ASCII TEXT that xauth does. Some known
> plaintext may be unavoidable, but xauth has a ridiculous amount.

Know plain text is non-issue (BTW actually the largest amount of known plain text
is with certificate, when the whole public certificate chain is being passed).

Regards,

Moshe

Attachment Converted: "C:\Temp\moshe2.vcf"
From ???@??? Wed Oct 27 14:33:50 1999
X-Persona: <a phoffman VPNC>
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13429
	for <[e-mail]>; Wed, 27 Oct 1999 12:53:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05645
	Wed, 27 Oct 1999 14:28:40 -0400 (EDT)
Message-Id: <3.0.6.32.19991027121504.00acf380@127.0.0.1>
X-Sender: rodney@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 27 Oct 1999 12:15:04 +0200
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: Re:-ipsec-pki-req-03 - intro
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
X-UIDL: bba121d1f81db3873a73c61b65eb6ecb

This is a DRAFT.  It's not an RFC.  It's not a BCP.
One of the very disturbing things about the IPsec RFC's
is that I find, in my travels, that there are people out
there reading them as the gospel truth, including the
really lame stuff.

So, labelling this with the truth, i.e. the fact it's
not terribly synchronized, is ADDING value for implementors,
in that it tells them this is unstable.

Many many many labor-hours were wasted over many years
in the IPsec communities because drafts were unstable and
therefore, we had implementations that were severely
jerked around because of this sort of things.

So I thing the addition of warning labels is appropriate.

>From: Brian Korver <[e-mail]>

>Greg Carter writes:

>> >From 1. Introduction, first paragraph:
>> 
>> "Note that many IPsec implementers are not completely happy with the PKIX
>> documents and procedures, but have agreed to use the PKIX protocols because
>> they are supported in other contexts and have a significant market share."
>> 
>> and last paragraph
>> 
>> "(It is noted that the fact that the two documents differ does not give
>> great confidence to the IPsec community or other users of the PKIX
>> protocols.)"
>> 
>> Both of these, whether or not true, are opinions and don't really do
>> anything to help implementers beside adding confusion.  I would suggest
they
>> be taken out for clarity.