I-D ACTION:draft-ietf-ipsec-isakmp-oakley-02.txt

[[e-mail]]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the IP Security Protocol Working
 Group of the IETF.                                                        

       Title     : The resolution of ISAKMP with Oakley                    
       Author(s) : D. Harkins, D. Carrel
       Filename  : draft-ietf-ipsec-isakmp-oakley-02.txt
       Pages     : 27
       Date      : 11/20/1996

[MSST96] (ISAKMP) provides a framework for authentication and key 
exchange but does not define them.  ISAKMP is designed to be 
key exchange independant; that is, it is designed to support many 
different key exchanges.                       
                                          
[Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and
details the services provided by each (e.g. perfect forward secrecy for 
keys, identity protection, and authentication).                        

This document describes a proposal for using the Oakley Key Exchange 
Protocol in conjunction with ISAKMP to obtain authenticated keying 
material for use with ISAKMP, and for other security associations 
such as AH and ESP for the IETF IPsec DOI.


Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-ipsec-isakmp-oakley-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [e-mail]. In the body type: 
     "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-02.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-isakmp-oakley-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--

--NextPart--



From owner-ipsec  Thu Nov 21 14:47:08 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07165 for ipsec-outgoing; Thu, 21 Nov 1996 14:38:43 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 21 Nov 1996 11:40:27 -0800
To: [e-mail]
From: Bob Monsour <[e-mail]>
Subject: Packet-by-packet compression within IPSec
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Here's a recap of recent history on this topic and a specific proposal to
bring the
discussion to closure.

In recent weeks there has been some good debate regarding the use of
lossless data compression within the context of the IP security framework.
Having reviewed the wg list comments, here's an extremely brief recap. [For
those new to the list, please see the list archives for details.]

 1. concept was initially embraced by a few
 2. suggestion was made to add fields to ESP to support stateful compression
    (i.e., compression history retained across multiple IP datagrams)
 3. some suggested the use of a separate compression header to support it
    (as opposed to fields within ESP)
 4. stateful nature of compression raised some concerns
 5. issue of a sequence counter, redundant with the replay ctr raised concerns
 6. issue of the lossyness of the IP media raised concerns
 7. need for negotiating SA parameters to support statefulness was stated
 8. analysis of packet loss raised serious concerns over stateful compression
 9. comments that stateless compression had benefit were stated
10. packet loss concerns seemed to depart in the face of stateless compression
11. proposal made to allow for stateless compression within ESP

Since that time, there has been little or no additional comment on the
subject. I would like to clarify my most recent proposal and provide
specific language to support its implementation.

I fully understand that the working group is moving full steam ahead to get
the IPSec documents ready for the San Jose meeting and to move toward
wide-spread interoperable deployments during the coming year. I do not
believe that this proposal or its implementation will hinder those efforts
and am willing to provide any support needed to assist.

Before going into the specifics of my proposal, I would like to point out a
subtlety involving the use of compression with encryption. The reduced
payload resulting from compression also reduces the amount of work (i.e.,
CPU cycles) required for subsequent encryption operations. Clearly, the CPU
cost of compression must be low enough to realize a net gain, but in our
tests, this bears out in enough cases to make it interesting. This speaks
directly to second paragraph of section 1.1 of the ESP draft regarding the
increased communications latency expected due to the encryption and
decryption operations.

MY PROPOSAL

The essence of my proposal is to add simple, straightforward language
(provided below) to the ESP draft which allows compression to be performed
on a packet-by-packet basis (keeping *NO* history or state information
across packets). The use of compression would be negotiated as an security
association parameter along with the algorithm to be employed. The ESP
payload data would simply be either compressed or uncompressed and *NO*
additional fields (in the header *OR* in the payload) would be required to
support it. This is the simplest form of compression support. I would
further suggest that, at some later time, the working group undertake the
effort to examine methods for supporting stateful compression. Nothing in
the proposed language is intended to preclude such efforts.

SPECIFIC LANGUAGE

The proposed changes are relative to draft-ietf-ipsec-payload-00.txt, dated
June
6, 1996 by Ran Atkinson. I understand that a revisoion of the draft is in
progress am confident that, given the nature of the changes specified
below, they could be easily be mapped into the new draft.

Section 1.1 (Overview)

Add the following sentence to the end of the first paragraph:

  The encrypted user data portion of the payload may be compressed
  prior to encryption. Security association parameters, negotiated
  by the key management mechanism, are used to determine whether or
  not compression is used and which compression algorithm will be used.

Section 3. (ENCAPSULATING SECURITY PAYLOAD SYNTAX)

Add the following sentence to first paragraph, making it the second to the
last sentence in the section (prior to "A high-level...").

  The protected user data portion of the payload may be compressed
  prior to encryption.

Immediately following the second ESP header diagram, change the sentence to
read:

  Encryption, authentication and optional compression algorithms, and
  the precise...

Section 4.1 (ESP in Tunnel-mode)

Change the first sentence of the second paragraph to read:

   ...to locate the corect Security Association, optionally applies the 
   appropriate compression transform, and then applies the appropriate
   encryption transform.

Change the first sentence of the fifth paragraph to read:

   If decryption succeeds, optional decompression is performed as necessary,
   and the original IP datagram...

Section 4.2 (ESP in Transport-mode)

Change the first sentence of the second paragraph to read:

   ...to locate the corect Security Association, optionally applies the 
   appropriate compression transform, and then applies the appropriate
   encryption transform.

Change the first sentence of the fifth paragraph to read:

   If decryption succeeds, optional decompression is performed as necessary,
   and the original transport layer...


We will be producing a draft compression transform which adheres to the
proposed "new model" for transforms. It will contain no fields, but will
simply specify how to transform a variabble sized data block from an
uncompressed block to a compressed block.

I would very much like to hear comments from those interested in the
subject and from the authors and/or co-chairs of the group regarding their
suggestions and guidance.


Bob Monsour
[e-mail]



From owner-ipsec  Thu Nov 21 15:26:01 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07278 for ipsec-outgoing; Thu, 21 Nov 1996 15:25:13 -0500 (EST)
Message-Id: <[e-mail]>
To: Bob Monsour <[e-mail]>
cc: [e-mail]
Subject: Re: Packet-by-packet compression within IPSec 
Date: Thu, 21 Nov 1996 15:23:00 -0500
From: Steven Bellovin <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I think your proposal is quite acceptable.  I'm willing to go a step
further -- the key management protocol should allow for negotiation
of currently-unspecified parameters for some future compression scheme.

From owner-ipsec  Thu Nov 21 16:36:58 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07348 for ipsec-outgoing; Thu, 21 Nov 1996 16:35:14 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: [e-mail]
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0b36 (32)
Date: Thu, 21 Nov 1996 16:35:41 -0500
To: [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: IPsec Interoperability Week #1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id QAA07345
Sender: [e-mail]
Precedence: bulk

The following is a proposal from the AIAG to all IPSec implementors.

We are very serious about getting product.  To the extent that we will
supply resources to get interoperablity.

Below is the general plan for an interoperability week.  Please discuss it
here, amongst yourselves and with us.  We are open to fleshing out (ie
nailing down) what ever details are appropriate.  Of course, I will be at
IETF to take what ever blooding deemed appropriate, just remember that I
have to leave on friday ;)

IPsec Interoperability Week #1

TO:	All implementers of the Ipsec protocols
From:	The Automotive Industry Action Group
	ANX Security work group
What:	1st working session for IPsec interoperability
Where:	MCI’s Richardson Texas test facilities
When:	January 6th - 10th, 1997
Participation Contact:	[e-mail] (810 351-5124),
[e-mail] (810 351-5257)
RSVP by:	Dec 10th, 1997
Document Questions/Issues:		[e-mail] by Dec 6th, 1996

GOALS:

Determine the current state of deployablity of IPsec components for the
Auto industry.  At this time, demonstration of Key management via
Oakley/ISAKMP is very important to the ANX work group.  The intention is to
create as close to a real world inter-company environment for vendor
testing.  Multiple scenario testing will be desired.  Work on the basis
that firewalls, split DNS, and private addressing is common.  Subsets of
these situations will be documented.

Participants minimally need to have product that uses RFCs 1825-9, Oakley
aggressive or main mode with authentication with pre-shared keys

Border-to-border via tunneling
	Consider access to ‘trade zones’ or entire company network.
Remote-to-border
Remote-to-interior
Interior-to-foreign border
	Through local border
Interior-to-interior

Technology to demonstrate interoperability:

Basic IPsec protocols, emphasis on ESP-HMAC
	(add draft name here)
Keying material for IPsec setup with Key Management exchange via
Oakley/ISAKMP (Choice of ANX wg)
	(all three drafts)
	Proxy modes
	Please provide Oakley modes demonstrable at this time.
Public key format of X.509v3
	Keys can be cached
X.509 key retrieval via LDAP
	CA will be provided for testing

Subsets of these will be documented by product.  A more compete testing
matrix and success criteria will be developed between now and Dec 8th. 

Policy issues will be sorted out as well is operational:

Unintended routing through multiple tunnels
Access control granularity
Oakley and ESP options as X.509 extensions
	Des vs 3Des, Compression supported, others

The test facility will be connected to the Internet, so vendors unable to
attend are encouraged to contact the MCI coordination team (TBN) to work
out arrangements for remote participation.

Follow up testing will be planned for 2Q97.



Robert Moskowitz
Chrysler Corporation
[phone]


From owner-ipsec  Thu Nov 21 17:25:25 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07423 for ipsec-outgoing; Thu, 21 Nov 1996 17:24:44 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 21 Nov 1996 17:24:12 -0500
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: compression transform conclusions
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

[response to Bob Monsour's proposal]

I believe his charactarization of the discussion so far is accurate.

I believe it is the rough consensus of the group that compression
should be part of the ESP transform, one way or the other, with or
without statefulness, parameter negotiation, sequence numbers, etc.

I myself think the ESP transform is excessively complex as it is,
regardless of the compression features.  I think this will interfere
with deployment and will increase the risk of security problems due
to buggy implementations.

But, I do think Bob's proposal represents the view of the group, so
I think that's what we should go with.


-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
Comment: PGP by ViaCrypt

iQCVAgUBMpTWPMKmlvJNktGxAQGoywQAgAhOO/aGTYhZsqfZvspaGq9Azcgrr+F6
ZeWZf08n157opre07UTVr98wujdJs+PFo0/1IWApGioQUwV4tV9tbN062SSu3+F1
x29e954kB5C801pA1IG1MwXa1vtdQsA8El4D5igRg4ug1iHCMaYags8frCgLP9co
xxSXdN8qhFg=
=Uq+S
-----END PGP SIGNATURE-----

               Rodney Thayer <[e-mail]>       [phone]
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: [phone]           http://www.shore.net/~sable
                           Communications Software Development


From owner-ipsec  Thu Nov 21 18:11:33 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07449 for ipsec-outgoing; Thu, 21 Nov 1996 18:10:48 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 21 Nov 1996 18:12:33 -0500
From: Lewis McCarthy <[e-mail]>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.2 alpha)
MIME-Version: 1.0
To: Luis Saiz Gimeno <[e-mail]>
CC: [e-mail]
Subject: Re: Any work in IPsec multicast  key management?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

LUIS SAIZ GIMENO writes:
> I would like to know if there is some work in progress in 
> multicast/anycast key management in this WG. Any idea about which 
> kind of cryptographic protocol is suitable to be adopted?

The most recent mail I've seen about this on the list was from Ran on
Sept.9 ("Subject: FYI: Multicast Key Management documents") -- check
the archives. He mentions GKMP [Harney et al.] and RFC 1949 [Ballardie]. 

Ran Atkinson wrote on Sept. 9:
>>> I'm told that work is underway at several places (e.g. ORNL) on a
>>> PF_KEY-based freely distributable implementation of GKMP technology
>>> inside the ISAKMP framework.

The survey essay Secure Multicast [Pessi],
<http://www.nixu.fi/~pnr/netsec-lopulliset/3-0-multicast.html>,
is already rather out of date, but you might find the discussion of
an old version of SKIP (draft-...-skip-03) w.r.t. multicast to be
worth reading.

-- 
Lewis		http://www.cs.umass.edu/~lmccarth/lmkey.asc

From owner-ipsec  Thu Nov 21 18:23:55 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07485 for ipsec-outgoing; Thu, 21 Nov 1996 18:23:51 -0500 (EST)
X-Sender: [e-mail]
Message-Id: <v03007811aeba9476da70@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 21 Nov 1996 18:25:28 -0500
To: Bob Monsour <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Packet-by-packet compression within IPSec
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Bob,

	I have no objections to your proposal, and it certainly can be
easily integrated into the newly revised ESP spec.  We also can allow for
an optional, variable length field in front of the payload, that contains
any per-packet data needed for a specific algorithm.  This is easy to
include in the ESP spec, with SA negotiation determining the presence or
absence of the field and its size.  The only issue,is how we deal with the
possible requirement to support any specific compression protocols.  From
an interoperability perspective, we need to address this aspect of the
standards, and that, I believe, is the basis for concern in terms of
delaying deployment of this technology.

Steve



From owner-ipsec  Thu Nov 21 19:00:35 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07513 for ipsec-outgoing; Thu, 21 Nov 1996 19:00:19 -0500 (EST)
Message-Id: <[e-mail]>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
To: [e-mail]
Cc: [e-mail]
Subject: Re: IPsec Interoperability Week #1 
In-Reply-To: Your message of "Thu, 21 Nov 1996 16:35:41 EST."
             <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 Nov 1996 19:56:21 +0000
From: Matt Thomas <[e-mail]>
Sender: [e-mail]
Precedence: bulk


I don't about others but Jan 6th is effectively the week after
next for me.  

Nov 25th	Thanksgiving week		
Dec 2st		UNH IPv6 testing 		
Dec 9th		the IETF in San Jose
Dec 16th	nothing
Dec 23rd	Christmas
Dec 30th	New Years
Jan 6th		IPsec testing

To get travel, systems, etc. ready by Jan 6th is going to be
difficult at best.  I think you should really consider moving
the testing date out 2 week if you can.
-- 
Matt Thomas                          Internet:   [e-mail]
IPv6 Kernel Grunt                    WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.



From owner-ipsec  Thu Nov 21 19:22:46 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07538 for ipsec-outgoing; Thu, 21 Nov 1996 19:21:50 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 21 Nov 1996 16:23:35 -0800
To: Stephen Kent <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: Packet-by-packet compression within IPSec
Cc: Bob Monsour <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 06:25 PM 11/21/96 -0500, Stephen Kent wrote:
>Bob,
>
>	I have no objections to your proposal, and it certainly can be
>easily integrated into the newly revised ESP spec.  We also can allow for
>an optional, variable length field in front of the payload, that contains
>any per-packet data needed for a specific algorithm.  This is easy to
>include in the ESP spec, with SA negotiation determining the presence or
>absence of the field and its size.  

Thanks. FYI, the only per-packet data I am imagining for our particular
proposal would be a single byte to contain a compressed/uncompressed bit.
This is needed to handle the case where the source data expands and you
want to instead send the original uncompressed data. In this case, you
would set the bit saying that the particular packet is uncompressed, even
though the SPI specifies that compression is an active function for this
channel.

>The only issue,is how we deal with the
>possible requirement to support any specific compression protocols.

When you say, "...possible requirement to support any specific compression
protocols.", I'm not sure I understand the issue. Do you mean the minimum
or mandatory support levels for compression in IPSec/ESP? If so, I would
expect that its optional nature precludes any such requirement. If you mean
support for specific compression algorithms, I would suggest that we treat
that issue in a similar manner as was done with PPP, where any number
algorithms can be supported as long as there is a draft/standard document
to describe how it is done in the context of IPSec/ESP. Since the specific
compression algorithm that we will be proposing will be based on the LZS
algorithm, it will ultimately result in an informational RFC (which is what
happened in the PPP case for LZS as well).

>From an interoperability perspective, we need to address this aspect of the
>standards, and that, I believe, is the basis for concern in terms of
>delaying deployment of this technology.

Are you refering to the requirement for two interoperable implementations
of compressed ESP before the document can be moved to the Draft Standard
stage? Having done some recent homework on the IETF standards process, I'm
guessing this is the concern. If that is indeed the case, I believe that we
could easily achieve such a goal.

-Bob



From owner-ipsec  Fri Nov 22 13:04:19 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08702 for ipsec-outgoing; Fri, 22 Nov 1996 13:00:43 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 22 Nov 1996 10:00:14 -0800
To: [e-mail]
From: Derek Palma <[e-mail]>
Subject: Unexpected silence (Test posting)
Sender: [e-mail]
Precedence: bulk

Either I am now longer receiving messages for this list
or there is very little discussion before an IETF.

This is a test!


From owner-ipsec  Fri Nov 22 16:06:41 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09104 for ipsec-outgoing; Fri, 22 Nov 1996 16:01:10 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 22 Nov 1996 12:59:54 -0800
To: [e-mail]
From: Derek Palma <[e-mail]>
Subject: Decoupling compression and security
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Some recent IPSEC implementation experiences and the current discussion
has caused me to consider the virtues of coupling compression
transforms with security.  No doubt use of compression has
benefits, even if only applied to a single packet.

I see no problem with having compression be part of an SA.
But I think it lacks some generality.  The output of a compression
algorithm can be larger than the input, the sender will no
doubt like to selectively compress.  This means the receiver
must be able to receive compressed and uncompressed data.
This seems independent from the SA.  Howeverm, the SA setup
can be used to select the compression algorithm.

Generic (probably PPP like) compression transforms which stand
on their own (apart from IPSEC) seemslike a more general solution.
However, IPSEC is the only group who can justify using compression
on a per packet basis.  Would a set of IP-COMP transforms (vs IPSEC)
be more appropriate?

Derek


From owner-ipsec  Fri Nov 22 23:57:15 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA09490 for ipsec-outgoing; Fri, 22 Nov 1996 23:54:51 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 22 Nov 1996 20:57:01 -0800
To: Derek Palma <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: Decoupling compression and security
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 12:59 PM 11/22/96 -0800, Derek Palma wrote:
>Some recent IPSEC implementation experiences and the current discussion
>has caused me to consider the virtues of coupling compression
>transforms with security.  No doubt use of compression has
>benefits, even if only applied to a single packet.
>
>I see no problem with having compression be part of an SA.
>But I think it lacks some generality.  The output of a compression
>algorithm can be larger than the input, the sender will no
>doubt like to selectively compress.  This means the receiver
>must be able to receive compressed and uncompressed data.
>This seems independent from the SA.  Howeverm, the SA setup
>can be used to select the compression algorithm.

When using packet-by-packet compression within IPSec, while an SA parameter
will exist to define the compression algorithm and whether or not
compression is enabled for a particular sender to receiver, the sender (as
you suggest) will not want to send data when it expands. We have suggested
that each compressed payload include a bit (within a one-byte field) which
indicates whether or not the IP datagram is compressed or not. So, in
effect, the sender operates as follows:
         
         compress the packet
         if it gets smaller
            compressed = true
            send it compressed
         else
            compressed = false
            send the packet in uncompressed form

On the reciever side, it just checks the compressed/uncompressed bit to
decide whether or not to attempt decompression.

>Generic (probably PPP like) compression transforms which stand
>on their own (apart from IPSEC) seemslike a more general solution.
>However, IPSEC is the only group who can justify using compression
>on a per packet basis.  Would a set of IP-COMP transforms (vs IPSEC)
>be more appropriate?

The attractive part of PPP-like compression solutions is that operate over
a connection-oriented protocol and therefore can compress across multiple
packets, realizing greater efficiencies than by doing it a packet at a
time. Unfortunately, we don't have that luxury in IP. At an even higher
layer, say SSL, there again is a connection-oriented protocol and
compression can indeed be done over a series of transmitted packets. Once
equipped with the packet-by-packet mode of compression, I would suspect
that if there is sufficient interest and energy in the working group, some
effort could be put forth to figure out how to reliably compress across
multiple IP datagrams. 

How would you see an IP-COMP transform operating?


Bob Monsour
[e-mail]

From owner-ipsec  Sat Nov 23 16:25:14 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09748 for ipsec-outgoing; Sat, 23 Nov 1996 16:18:53 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 23 Nov 1996 16:18:20 -0500
To: [e-mail]
From: Rodney Thayer <[e-mail]>
Subject: Re: Decoupling compression and security
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Have you looked at the draft I did in July?  What you're talking about
sounds like the direction I was headed.  How would you add/change what I
proposed?

>X-Sender: [e-mail]
>Date: Fri, 22 Nov 1996 20:57:01 -0800
>To: Derek Palma <[e-mail]>
>From: Bob Monsour <[e-mail]>
>Subject: Re: Decoupling compression and security
>Cc: [e-mail], [e-mail]
>Sender: [e-mail]
>
>At 12:59 PM 11/22/96 -0800, Derek Palma wrote:
>>Some recent IPSEC implementation experiences and the current discussion
>>has caused me to consider the virtues of coupling compression
>>transforms with security.  No doubt use of compression has
>>benefits, even if only applied to a single packet.
>>
>>I see no problem with having compression be part of an SA.
>>But I think it lacks some generality.  The output of a compression
>>algorithm can be larger than the input, the sender will no
>>doubt like to selectively compress.  This means the receiver
>>must be able to receive compressed and uncompressed data.
>>This seems independent from the SA.  Howeverm, the SA setup
>>can be used to select the compression algorithm.
>
>When using packet-by-packet compression within IPSec, while an SA parameter
>will exist to define the compression algorithm and whether or not
>compression is enabled for a particular sender to receiver, the sender (as
>you suggest) will not want to send data when it expands. We have suggested
>that each compressed payload include a bit (within a one-byte field) which
>indicates whether or not the IP datagram is compressed or not. So, in
>effect, the sender operates as follows:
>         
>         compress the packet
>         if it gets smaller
>            compressed = true
>            send it compressed
>         else
>            compressed = false
>            send the packet in uncompressed form
>
>On the reciever side, it just checks the compressed/uncompressed bit to
>decide whether or not to attempt decompression.
>
>>Generic (probably PPP like) compression transforms which stand
>>on their own (apart from IPSEC) seemslike a more general solution.
>>However, IPSEC is the only group who can justify using compression
>>on a per packet basis.  Would a set of IP-COMP transforms (vs IPSEC)
>>be more appropriate?
>
>The attractive part of PPP-like compression solutions is that operate over
>a connection-oriented protocol and therefore can compress across multiple
>packets, realizing greater efficiencies than by doing it a packet at a
>time. Unfortunately, we don't have that luxury in IP. At an even higher
>layer, say SSL, there again is a connection-oriented protocol and
>compression can indeed be done over a series of transmitted packets. Once
>equipped with the packet-by-packet mode of compression, I would suspect
>that if there is sufficient interest and energy in the working group, some
>effort could be put forth to figure out how to reliably compress across
>multiple IP datagrams. 
>
>How would you see an IP-COMP transform operating?
>
>
>Bob Monsour
>[e-mail]
>
>

               Rodney Thayer <[e-mail]>       [phone]
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: [phone]           http://www.shore.net/~sable
                           Communications Software Development


From owner-ipsec  Mon Nov 25 03:40:13 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10369 for ipsec-outgoing; Mon, 25 Nov 1996 03:32:24 -0500 (EST)
Date: Mon, 25 Nov 1996 10:34:24 +0200 (EET)
From: Santeri Paavolainen <[e-mail]>
X-Sender: santtu@hutcs
To: [e-mail]
Subject: Re: Decoupling compression and security
In-Reply-To: <[e-mail]>
Message-ID: <Pine.GSO.3.94.961125100351.29183A-100000@hutcs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> When using packet-by-packet compression within IPSec, while an SA parameter
> will exist to define the compression algorithm and whether or not
> compression is enabled for a particular sender to receiver, the sender (as
> you suggest) will not want to send data when it expands. We have suggested
> that each compressed payload include a bit (within a one-byte field) which
> indicates whether or not the IP datagram is compressed or not. So, in
> effect, the sender operates as follows:
>          
>          compress the packet
>          if it gets smaller
>             compressed = true
>             send it compressed
>          else
>             compressed = false
>             send the packet in uncompressed form
> 
> On the reciever side, it just checks the compressed/uncompressed bit to
> decide whether or not to attempt decompression.

If the compression was another IPSEC transformation there would be no
need for such a "bit" in the actual _security_ transformation
data. Have everybody forgotten that applying transformations on a
packet is still optional? If I want an option of not applying a packet
compression transformation I can just not apply it -- no need for any
information bits in the packet. As an example,

there is two transformations defined, COMP for compression and CRYPT
for some crypto. If I get a acceptable compression ratio for a packet,
I leave the compression transformation on and pass the packet to the
rest of the transformation chain, finally giving a packet like

	CRYPT(COMP(packet))

OTOH, if the compression ratio is unacceptable, just leave the
compression layer off:

	CRYPT(packet)

Because the receiver sees only SPIs of the various layers, it will
first decrypt and either get a regular (not compressed) packet, or a
compressed packet which will then have to be uncompressed to gain the
final packet.

Of course, this would mean there is overhead of SPI vs. "bit", but I
think the generality is a clear plus. What if you later find out the
cryptographic transformation you have embedded the compression layer
is not secure? Also, there is no clear way how to interoperate between
different transformations which have the same compression engine (you
must remember that each transformation should be self-contained from
the coding point of view). 

Also, some persons might want compression, and only that. I imagine
there would be plenty of situations (two computers connected by a
secure network/line) where getting "compression" out of IPSEC layer
could not be justified because of the extra costs because the
compression would imply (cpu-intensive) cryptographic methods.

Of course, it is another matter whether compression should be included
in the IPSEC layer at all.



PS. In the IP Authentication Header draft (4 June 1996, are there
newer versions?) at chapter 3, the combination of AH(AH(...)) is said
to be invalid at all times. Why? Take the following situation as an
example where AH(AH(...)) could be used:

A VPN network, eg. an intranet created by establishing a secure tunnel
between two separate networks. Typically, the VPN routers apply some
IPSEC AH+ESP transformation on a packet before sending it through the
internet network. But, there can be a case when the VPN router does
not want to encrypt a packet, but still requires authentication. 

If there are IPSEC-capable hosts within these two parts of the
intranet talking to each other with some AH+ESP transformations the
VPN routers will get packets in the form of AH(ESP(...)). If the VPN
routers have knowledge about the used ESP (by acting as a middlemen in
key management routine, for example) an deem it as "secure enough"
they might not want to apply a second layer of ESP, because it would
be unnecessary.

Still they want to apply an AH, so that the other VPN router can
confirm the authenticity of the packet coming from the internet (that
it really is coming from the other VPN router). This leads to a
situation where the packet would look like AH(AH(ESP(...))) when send
to the internet. But this seems not to be allowed by the draft!

--
[e-mail]          I have become death, destroyer of the worlds.


From owner-ipsec  Mon Nov 25 07:20:22 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10567 for ipsec-outgoing; Mon, 25 Nov 1996 07:18:20 -0500 (EST)
Date: 25 Nov 96 09:27:26 +0300
From: "RIITTINEN HEIKKI" <[e-mail]>
Subject: RE:Packet-by-packet compression within IPSec
Reply-To: [e-mail]
In-Reply-To: Packet-by-packet compression within IPSec
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Bob Monsour:
>MY PROPOSAL
>
>The essence of my proposal is to add simple, straightforward language
>(provided below) to the ESP draft which allows compression to be performed
>on a packet-by-packet basis (keeping *NO* history or state information
>across packets). The use of compression would be negotiated as an security
>association parameter along with the algorithm to be employed. The ESP
>payload data would simply be either compressed or uncompressed and *NO*
>additional fields (in the header *OR* in the payload) would be required to
>support it. This is the simplest form of compression support. 

>Bob Monsour
>[e-mail]

I fully support the proposal. We have implemented a prototype
of a proprietary "encryption" (stateless compression and standard
encryption) that fulfills all the requirements set by the proposal.

[e-mail] from Europe



From owner-ipsec  Mon Nov 25 10:06:21 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11013 for ipsec-outgoing; Mon, 25 Nov 1996 10:02:53 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;@[e-mail];;;
From: [e-mail]
cc: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-mcdonald-simple-ipsec-api-00.txt
Date: Mon, 25 Nov 1996 09:38:09 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.                                                              


       Title     : A Simple IP Security API Extension to BSD Sockets       
       Author(s) : D. McDonald
       Filename  : draft-mcdonald-simple-ipsec-api-00.txt
       Pages     : 9
       Date      : 11/22/1996

In order to take advantage of the IP Security Architecture [Atk95], an 
application should be able to tell the system what IP-layer security 
services it needs to function with some degree of confidence.   A simple 
API that also allows simple security association policy to be set is 
presented here.  This document descends from earlier work performed in the 
U. S. Naval Research Laboratory's IPv6 and IP security implementation 
[AMPMC96].                                                                 

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-mcdonald-simple-ipsec-api-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [e-mail]. In the body type: 
     "FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-mcdonald-simple-ipsec-api-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--

--NextPart--

From owner-ipsec  Mon Nov 25 15:38:13 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11709 for ipsec-outgoing; Mon, 25 Nov 1996 15:35:58 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 25 Nov 1996 15:36:39 -0500
From: "Jeffrey I. Schiller" <[e-mail]>
Organization: Massachusetts Institute of Technology
X-Mailer: Mozilla 3.0 (X11; U; IRIX 5.2 IP22)
MIME-Version: 1.0
To: [e-mail]
Subject: Documents Approved at last IESG Telechat
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

>From the IESG (as yet unpublished) minutes. This is an *unofficial*
announcement:

 o  The IESG approved publication of HMAC-MD5 IP Authentication with
    Replay Prevention <draft-ietf-ipsec-ah-hmac-md5-04.txt> as a
    Proposed Standard. Steve to send announcement.


 o  The IESG approved publication of HMAC-SHA IP Authentication with
    Replay Prevention <draft-ietf-ipsec-ah-hmac-sha-04.txt> as a
    Proposed Standard. Steve to send announcement.


 o  The IESG approved the reclassification of RFC1828, IP
    Authentication using Keyed MD5, from Proposed Standard to Historic
    status.

 o  The IESG approved publication of HMAC: Keyed-Hashing for Message
    Authentication <draft-ietf-ipsec-hmac-md5-01.txt> as an
    Informational RFC. Steve to send announcement.

                                -Jeff


From owner-ipsec  Tue Nov 26 07:24:44 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12729 for ipsec-outgoing; Tue, 26 Nov 1996 07:18:40 -0500 (EST)
Date: Mon, 25 Nov 96 18:59:16 EST
From: "Whelan, Bill" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: AH (without ESP) on a secure gateway
Sender: [e-mail]
Precedence: bulk

     Last month there was a question regarding ESP and AH on a secure 
     gateway as in the following model.

     
       secure                 (untrusted)         secure
       hostA  gatewayA---------------------------gatewayB  hostB
        |      |                                     |      |
       ----------                                   -----------
      (trusted subnet)                             (trusted subnet)
     
     
     My question is whether AH on a secure gateway even makes sense at all 
     if ESP is not being performed.
     
     Consider hostA sending a packet to hostB.  If gatewayA places an AH on 
     the packet, it would appear as if it was authenticated by hostA, not a 
     good idea in my mind.
     
     How do other secure gateway implementations handle this situation?
     
     Bill Whelan




From owner-ipsec  Tue Nov 26 10:23:32 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13855 for ipsec-outgoing; Tue, 26 Nov 1996 10:21:01 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ipsec-isakmp-06.txt, .ps
Date: Tue, 26 Nov 1996 09:19:21 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the IP Security Protocol Working
 Group of the IETF.                                                        

       Title     : Internet Security Association and Key Management 
                   Protocol (ISAKMP)                                       
       Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner
       Filename  : draft-ietf-ipsec-isakmp-06.txt, .ps
       Pages     : 78
       Date      : 11/25/1996

This memo describes a protocol utilizing security concepts necessary for 
establishing Security Associations (SA) and cryptographic keys in an 
Internet environment.  A Security Association protocol that negotiates, 
establishes, modifies and deletes Security Associations and their 
attributes is required for an evolving Internet, where there will be 
numerous security mechanisms and several options for each security 
mechanism.  The key management protocol must be robust in order to handle 
public key generation for the Internet community at large and private key 
requirements for those private networks with that requirement.        

The Internet Security Association and Key Management Protocol (ISAKMP) 
defines the procedures for authenticating a communicating peer, creation and 
management of Security Associations, key generation techniques, and threat 
mitigation (e.g.  denial of service and replay attacks).  All of these are 
necessary to establish and maintain secure communications (via IP Security 
Service or any other security protocol) in an Internet environment.        

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-ipsec-isakmp-06.txt".
 Or 
     "get draft-ietf-ipsec-isakmp-06.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-06.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [e-mail]. In the body type: 
     "FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.txt".
 Or 
     "FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.ps".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-isakmp-06.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--

--NextPart--


From owner-ipsec  Tue Nov 26 10:28:38 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13886 for ipsec-outgoing; Tue, 26 Nov 1996 10:28:30 -0500 (EST)
Message-Id: <[e-mail]>
From: Greg Carter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: PF_KEY
Date: Tue, 26 Nov 1996 10:12:49 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
Sender: [e-mail]
Precedence: bulk

Hi All,
        Can anyone give me an idea of the exceptance of PF_KEY and the
platforms it is/will be supported on.

Thanks.
----
Greg Carter
Nortel Secure Networks - Entrust
[e-mail]



From owner-ipsec  Tue Nov 26 11:11:22 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14141 for ipsec-outgoing; Tue, 26 Nov 1996 11:11:02 -0500 (EST)
Message-Id: <[e-mail]>
From: Greg Carter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: sorry, spelling...
Date: Tue, 26 Nov 1996 11:01:09 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
Sender: [e-mail]
Precedence: bulk

Obviously I can't spell and I should really reread before I hit send, I
meant "acceptance" of PF_KEY.

Bye.

----
Greg Carter
Nortel Secure Networks - Entrust
[e-mail]



From owner-ipsec  Tue Nov 26 11:20:13 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14229 for ipsec-outgoing; Tue, 26 Nov 1996 11:20:09 -0500 (EST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt 
References: <[e-mail]>
In-reply-to: Internet-Drafts's message of "Wed, 20 Nov 1996 09:56:50 -0500".
	 <[e-mail]> 
From: "C. Harald Koch" <[e-mail]>
Organization: Secure Computing Canada Ltd.
Phone: [phone]
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
 z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
 did@Pr9
Date: Tue, 26 Nov 1996 11:22:20 -0500
Sender: [e-mail]
Precedence: bulk

Some quibbles regarding the IPsec DOI definitions, that I just tripped over
while trying to define a text-based SA exchange format. Basically, if we're
going to a) name and b) number protocol entities, we need to ensure that the
list is both intelligible and complete.

	4.4.3 IPSEC AH Transform Values

	       Transform                           Value
	       ---------                           -----
	       RESERVED                            0
	       AH_1828                             1
	       AH_HMAC_MD5_REPLAY                  2
	       AH_MHAC_SHA_REPLAY                  3
 
I object to the use of RFC numbers in the name of the transform; it's
either meaningless or obscure, depending on who you ask. AH_MD5 would be
better than AH_1828.

The "AH_HMAC_MD5" transform is missing from the list. While this transform
never became an RFC, it is in use by several vendors, and so needs an
identifier for proper interoperability. (Yes, it's a proper subset of
AH_HMAC_MD5_REPLAY, But to support historical implementations, I think it
needs to be kept separate. I'm willing to negotiate on this one :-)


	4.4.4 IPSEC ESP Transform Identifiers

	       Transform ID                        Value
	       ------------                        -----
	       RESERVED                            0
	       ESP_1829_TRANSPORT                  1
	       ESP_1829_TUNNEL                     2
	       ESP_DES_CBC_HMAC_REPLAY             3

Again, I object to the use of RFC numbers in the name; IMHO, these should be
"ESP_DES_CBC_TRANSPORT" and "ESP_DES_CBC_TUNNEL". (And I though the
"transport" v.s. "tunnel" distinction was an RFC 1827 thing; if so,
shouldn't we be consistent here?)

ESP_3DES_CBC is missing (RFC 1851). Again, there are vendors using this
already; an ID and number are required for interoperability.

</soapbox> :-)

-- 
C. Harald Koch          | Senior System Developer, Secure Computing Canada Ltd.
[e-mail]          | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
[phone] (voice) | "Madness takes its toll. Please have exact change."
[phone] (fax)   |		-Karen Murphy <[e-mail]>

From owner-ipsec  Tue Nov 26 12:56:36 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14512 for ipsec-outgoing; Tue, 26 Nov 1996 12:54:00 -0500 (EST)
Date: Tue, 26 Nov 1996 11:24:51 -0600 (CST)
From: Tom Markham <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: RE:  AH (without ESP) on a secure gateway
Sender: [e-mail]
Precedence: bulk


Bill

BW> Last month there was a question regarding ESP and AH on a secure 
     gateway as in the following model.

     
       secure                 (untrusted)         secure
       hostA  gatewayA---------------------------gatewayB  hostB
        |      |                                     |      |
       ----------                                   -----------
      (trusted subnet)                             (trusted subnet)
     
     
BW>   My question is whether AH on a secure gateway even makes sense at all 
     if ESP is not being performed.


Consider the case where one gateway is in a country like France which
does not allow encryption. An organization could still use AH to
authenticate that the source of the packets was another secure gateway
belonging to the organization.

BW>  Consider hostA sending a packet to hostB.  If gatewayA places an AH on 
     the packet, it would appear as if it was authenticated by hostA, not a 
     good idea in my mind.

The receiving gateway/host knows (should know) that the AH keying material
is held by Gateway A and not Host A. If the receiving gateway/host
does not know which devices it shares keying material with, you have a
key management problem. 

Tom Markham

From owner-ipsec  Tue Nov 26 13:01:17 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14528 for ipsec-outgoing; Tue, 26 Nov 1996 13:01:00 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 26 Nov 1996 10:03:12 -0800
To: Santeri Paavolainen <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: Decoupling compression and security
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 10:34 AM 11/25/96 +0200, Santeri Paavolainen wrote:
...
>If the compression was another IPSEC transformation there would be no
>need for such a "bit" in the actual _security_ transformation
>data. Have everybody forgotten that applying transformations on a
>packet is still optional? If I want an option of not applying a packet
>compression transformation I can just not apply it -- no need for any
>information bits in the packet. As an example,
>
>there is two transformations defined, COMP for compression and CRYPT
>for some crypto. If I get a acceptable compression ratio for a packet,
>I leave the compression transformation on and pass the packet to the
>rest of the transformation chain, finally giving a packet like
>
>	CRYPT(COMP(packet))
>
>OTOH, if the compression ratio is unacceptable, just leave the
>compression layer off:
>
>	CRYPT(packet)
>
>Because the receiver sees only SPIs of the various layers, it will
>first decrypt and either get a regular (not compressed) packet, or a
>compressed packet which will then have to be uncompressed to gain the
>final packet.
>
>Of course, this would mean there is overhead of SPI vs. "bit", but I
>think the generality is a clear plus. What if you later find out the
>cryptographic transformation you have embedded the compression layer
>is not secure? Also, there is no clear way how to interoperate between
>different transformations which have the same compression engine (you
>must remember that each transformation should be self-contained from
>the coding point of view). 
...

This is more than just an issue of the overhead of an SPI vs. a "bit". Let
me explain by way of example. Let's say that a security association has
been set up for traffic traveling from a sender to a receiver. Thus the SPI
for traffic in that direction is  specified. Let's also say that the SPI
specifies the use of a particular set of compression, encryption and
authentication algorithms. Then, let's say that the sender wants to send a
datagram to the receiver. Suppose the data expands. The sender would then
want to send the original uncompressed form of the data. Under our
proposal, all the sender would have to do is to change a bit at the start
of the payload. Under what you propose, the SPI is no longer valid since
the reciever will erroneously attempt to decompress raw data. Your method
would thus require that a new SPI be used which would likely require some
renegotiation between the sender and receiver as to which algorithms and
modes are to be used for the connection.

Bob Monsour
[e-mail]



From owner-ipsec  Tue Nov 26 14:29:18 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14778 for ipsec-outgoing; Tue, 26 Nov 1996 14:28:06 -0500 (EST)
Message-Id: <[e-mail]>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: "Whelan, Bill" <[e-mail]>
Cc: [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: bwhelan's message of Mon, 25 Nov 1996 18:59:16 -0500.
	     <[e-mail]> 
Date: Tue, 26 Nov 1996 14:28:31 -0500
From: Bill Sommerfeld <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>      My question is whether AH on a secure gateway even makes sense at all 
>      if ESP is not being performed.
>      
>      Consider hostA sending a packet to hostB.  If gatewayA places an AH on 
>      the packet, it would appear as if it was authenticated by hostA, not a 
>      good idea in my mind.

If a router places an AH on the packet, it must do so using an
outbound SPI to some other host/router.

The corresponding inbound SPI on that host should specify that the
sender is a gateway, not a host.

The "policy engines" on each end need to be sophisticated enough to
deal with things like this.  In particular, if ip-address based access
controls are in use, then the policy engine should probably do
consistency checks between the SPI and the source address..


						- Bill


From owner-ipsec  Tue Nov 26 15:27:52 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15076 for ipsec-outgoing; Tue, 26 Nov 1996 15:27:03 -0500 (EST)
To: IETF-Announce:;;;;@[e-mail];;;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: HMAC-MD5 IP Authentication with Replay Prevention
	 to Proposed Standard
Date: Tue, 26 Nov 1996 13:09:54 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk


  The IESG has approved the Internet-Drafts

  1. HMAC-MD5 IP Authentication with Replay Prevention
	<draft-ietf-ipsec-ah-hmac-md5-04.txt> and
  2. HMAC-SHA IP Authentication with Replay Prevention
	<draft-ietf-ipsec-ah-hmac-sha-04.txt>

  as Proposed Standards.

  The IESG also approved the reclassification of RFC1828, IP
  Authentication using Keyed MD5, from Proposed Standard to Historic.

  These documents are the product of the IP Security Protocol Working
  Group. The IESG contact person is Jeffrey Schiller.


Technical Summary

   These documents describe two similar Keyed Hashes (one based on MD5
   and the other based on SHA) for use in IP Security's Authentication
   Header (both IPv4 and IPv6). Hashes such as MD5 and SHA were
   designed to be used as "keyless" hashes which can be used in digital
   signature systems such as the RSA system and the U.S. Digital
   Signature Standard (DSS).

   An obvious approach to using them as "keyed" hashes has involved
   either prepending the data to be hashed with a secret value (key) or
   appending the secret value after the data to be hashed (or both).
   However recently significant analysis work has been carried out by
   cryptographers as to security of keyed modes of these hashes.

   The keyed hash mechanism described in these documents benefits from
   this analytical experience and is therefore believed to be much
   stronger than the simplistic approaches taken to date in the
   Internet community (both in AH and SNMP).

Working Group Summary

   These documents are the work product of the IP Security Working
   Group. The group has come to consensus that these hashes are good
   approaches to the keyed hash function required by the Authentication
   Header.

Protocol Quality

   This protocol has been reviewed by Jeffrey I. Schiller, Security
   Area Director.



From owner-ipsec  Tue Nov 26 16:35:03 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15139 for ipsec-outgoing; Tue, 26 Nov 1996 16:31:38 -0500 (EST)
Message-Id: <[e-mail]>
To: Tom Markham <[e-mail]>
Cc: [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: Your message of Tue, 26 Nov 1996 11:24:51 -0600.
             <[e-mail]> 
Date: Tue, 26 Nov 1996 13:33:49 -0800
From: "\"\"Yan-Fa LI <[e-mail]>\"\"" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Hi Bill and Tom,

> 
> Bill
> 
> BW> Last month there was a question regarding ESP and AH on a secure 
>      gateway as in the following model.
> 
>      
>        secure                 (untrusted)         secure
>        hostA  gatewayA---------------------------gatewayB  hostB
>         |      |                                     |      |
>        ----------                                   -----------
>       (trusted subnet)                             (trusted subnet)
>      
>      
> BW>   My question is whether AH on a secure gateway even makes sense at all 
>      if ESP is not being performed.
> 
> 
> Consider the case where one gateway is in a country like France which
> does not allow encryption. An organization could still use AH to
> authenticate that the source of the packets was another secure gateway
> belonging to the organization.

This is exactly what I would like AH only support for.  It would give us
the extra capabilities of Anti-Spoofing and Integrity checking which
would be a big win over today's infrastructure.  There are some instances
where privacy is not a big deal, or where export/import usage
restrictions forbid the use of strong cryptography.

> 
> BW>  Consider hostA sending a packet to hostB.  If gatewayA places an AH on 
>      the packet, it would appear as if it was authenticated by hostA, not a 
>      good idea in my mind.
> 
> The receiving gateway/host knows (should know) that the AH keying material
> is held by Gateway A and not Host A. If the receiving gateway/host
> does not know which devices it shares keying material with, you have a
> key management problem. 
> 
> Tom Markham

I don't believe this is the case in some of the gateway products which
are available today.  Some of the gateway products transparently proxy
for hosts in the trusted network.  This is the fundamental weak spot in
gateway solutions.  They assume:

	- your trusted network is secure

	- you do not have users spoofing the addresses of other users
	  within the trusted network.

The strength of this approach is you can support legacy devices without
making any changes to them.  Gateways are a compromise between security
and medium-term implementation realities.

Does anyone know if there are specific set up messages in the
ISAKMP-OAKLEY protocol to identify which architectural case a pair of
communicating peers is in ?  i.e.  Host-to-Host, Host-to-Gateway, and
Gateway-to-Gateway.

For example, if one knew the conversation was between two gateways, one
could accept the risks of this architectural model and just negotiate a
pair of SAs for the communication with all traffic between the networks
being multiplexed over a single TCP/IP connection.  Much more efficient
for the gateways.  However if we do this are we making it easier for
an attacker to perform cryptanalysis on our connection ?

If you implement the reverse situation, where a new SA pair is negotiated
for every IP pair that attempts communication between the networks,
this could quickly bog down the gateways while they authenticate
public keys exchanges, context switch between secret session keys and
encrypt and decrypt packets.

One could argue that this will happen anyway in the Host-to-Gateway
scenario, and one needs to engineer for this case, so why not make
it the general one ?  Right now, with gateway solutions, I think
that Host-to-Host is how they operated.  I would interested in
finding out if there is a way to identify which model is in use.

Also, if I have made any gross conceptual mistakes in this text,
I would appreciate being helped to understand why.  Thanks for your
time.

Sincerely,

   Yan

 ___________________________________________________________________

My views do not necessarily represent those of the Hewlett Packard
 Company and should be taken with a large dose of salt or whatever
 passes for sodium in your neck of the woods/universe/continuum/etc...
 ___________________________________________________________________


From owner-ipsec  Tue Nov 26 16:53:00 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15168 for ipsec-outgoing; Tue, 26 Nov 1996 16:51:34 -0500 (EST)
Date: Tue, 26 Nov 96 13:44:00 PST
From: John H Wilson <[e-mail]>
Message-ID: <Tue, 26 Nov 96 13:53:21 [e-mail]>
To: [e-mail]
Subject: ipsec implementations
Sender: [e-mail]
Precedence: bulk

I would like to get an idea of what Win95 or NT implementations of IPSEC 
are either planned or are available already.....
......Company, availability date, content, API, 

If any implementers would be willing to provide this type of 
information, I'd apreciate it.

[e-mail]

From owner-ipsec  Tue Nov 26 17:29:50 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15215 for ipsec-outgoing; Tue, 26 Nov 1996 17:28:04 -0500 (EST)
Date: Tue, 26 Nov 1996 17:30:19 -0500 (EST)
Message-Id: <[e-mail]>
From: Ben Rogers <[e-mail]>
To: Bill Sommerfeld <[e-mail]>
Cc: "Whelan, Bill" <[e-mail]>, [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Reply-To: [e-mail] (Ben Rogers)
Sender: [e-mail]
Precedence: bulk

Bill Sommerfeld writes:
> >      My question is whether AH on a secure gateway even makes sense at all 
> >      if ESP is not being performed.
> >      
> >      Consider hostA sending a packet to hostB.  If gatewayA places an AH on 
> >      the packet, it would appear as if it was authenticated by hostA, not a 
> >      good idea in my mind.
> 

It seems to me that gatewayA should never try to place an AH, nor do an
ESP encapsulation on the packet using transport mode (assuming that
gatewayA did not originate the packet).  A gateway that put IPSEC
headers on packets in transport mode would not only cause confusing
problems like this, but would have severe problems dealing with
fragmented packets.

> The "policy engines" on each end need to be sophisticated enough to
> deal with things like this.  In particular, if ip-address based access
> controls are in use, then the policy engine should probably do
> consistency checks between the SPI and the source address..

Why?  I believe the RFC states that the Security Association(SA) is
chosen using only the destination address and the SPI.  It doesn't seem
to be illegal for several hosts to send us packets using the same
Security Association (SPI).

It makes sense to only check the headers on packets that are destined
for the local machine.  Otherwise, we would be intercepting (and
probably modifying) packets not destined to that machine, and violating
many of the ideas that make IP work.  Thus, I don't see any reason that
a gateway could use transport mode to tack on an AH to a packet from
hostA to hostB.

To address the original question, using the following scenario:

>       secure                 (untrusted)         secure
>       hostA  gatewayA---------------------------gatewayB  hostB
>        |      |                                     |      |
>       ----------                                   -----------
>      (trusted subnet)                             (trusted subnet)
     
the packets should look like (on the untrusted segment)

hostA -> hostB :
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(hostA->gateB)
  AH(hostA->gateB)
  IP_HEADER(hostA->hostB)
  PACKET

hostA -> gateB :
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(hostA->gateB) 
  AH(hostA->gateB)
  PACKET
or
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(hostA->gateB) 
  AH(hostA->gateB)
  IP_HEADER(hostA->gateB) 
  PACKET

gateA -> gateB :
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  PACKET
or
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(gateA->gateB)
  PACKET

gateA -> hostB
  IP_HEADER(gateA->gateB)
  AH(gateA->gateB)
  IP_HEADER(gateA->hostB)
  PACKET

to avoid any ambiguity.  Note that this never allows AH, AH and assumes
that no machine will attempt to de-encapsulate a packet whose
destination address is not assigned to that machine.  As a result, none
of the machines ever has to make any complicated policy decisions (on
whether to look at the AH, or how to handle the assignment of SPI's).  I
feel that this is the best way to handle all such multiple
encapsulations.


ben

From owner-ipsec  Tue Nov 26 18:02:29 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15279 for ipsec-outgoing; Tue, 26 Nov 1996 18:00:36 -0500 (EST)
Message-Id: <[e-mail]>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: [e-mail] (Ben Rogers)
Cc: "Whelan, Bill" <[e-mail]>, [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: ben's message of Tue, 26 Nov 1996 17:30:19 -0500.
	     <[e-mail]> 
Date: Tue, 26 Nov 1996 18:02:47 -0500
From: Bill Sommerfeld <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> > The "policy engines" on each end need to be sophisticated enough to
> > deal with things like this.  In particular, if ip-address based access
> > controls are in use, then the policy engine should probably do
> > consistency checks between the SPI and the source address..
> 
> Why?  I believe the RFC states that the Security Association(SA) is
> chosen using only the destination address and the SPI.  It doesn't seem
> to be illegal for several hosts to send us packets using the same
> Security Association (SPI).

All things which aren't illegal aren't necessarily also good ideas.

> It makes sense to only check the headers on packets that are destined
> for the local machine.  Otherwise, we would be intercepting (and
> probably modifying) packets not destined to that machine, and violating
> many of the ideas that make IP work.  Thus, I don't see any reason that
> a gateway could use transport mode to tack on an AH to a packet from
> hostA to hostB.

Let's consider the case where you're attempting to add AH/ESP
protection to an existing network which *currently uses IP-address
based access controls*.  Naturally, you don't want to create security
holes while doing this.

Let's assume you have a network of cooperating but mutually suspicious
organizations, like the auto industry net which Bob Moskowitz is
building.

For simplicity, let's assume orgs A, B, and C, connected in a "full
mesh" of leased lines (A-B, A-C, and B-C).  Assume filtering routers
on each leased line, so that C can't impersonate B when communicating
with A.  We now want to migrate to IPSEC without causing a flag day.

Let's start by replacing the leased line between C and A with a tunnel
over an untrusted network protected with AH or ESP.

What stops C from tunnelling a packet to A with a source address on
B's network?  You need a policy check that the packet emerging from
the tunnel is from a source address which is allowed to use that
particular tunnel..

For a particularly extreme example, assume that A and B are divisions
of the same company, and that C is a division of a different company
which is simultaneously a supplier and a competitor of the first
company.

					- Bill

From owner-ipsec  Tue Nov 26 18:19:11 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15305 for ipsec-outgoing; Tue, 26 Nov 1996 18:19:05 -0500 (EST)
Date: Tue, 26 Nov 1996 18:19:34 -0500 (EST)
Message-Id: <[e-mail]>
From: Ben Rogers <[e-mail]>
To: Bill Sommerfeld <[e-mail]>
Cc: [e-mail] (Ben Rogers), "Whelan, Bill" <[e-mail]>,
        [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Reply-To: [e-mail] (Ben Rogers)
Sender: [e-mail]
Precedence: bulk

Bill Sommerfeld writes:
> > Why?  I believe the RFC states that the Security Association(SA) is
> > chosen using only the destination address and the SPI.  It doesn't seem
> > to be illegal for several hosts to send us packets using the same
> > Security Association (SPI).
> 
> All things which aren't illegal aren't necessarily also good ideas.

Well...  It seems to me that it might be a good idea to allow IPSEC to
be used over multicast packets.  Then, your destination address (that of
the multicast group) would be constant, but there would be many source
addresses.  You would need to use an AH, but that should be sufficient
to verify the sender.  I don't see what security a check on source
address of authenticated packets adds.  Of course this all changes if
you are talking about the packet after it has been extracted from the
tunnel.

> Let's consider the case where you're attempting to add AH/ESP
> protection to an existing network which *currently uses IP-address
> based access controls*.  Naturally, you don't want to create security
> holes while doing this.
> 
> Let's assume you have a network of cooperating but mutually suspicious
> organizations, like the auto industry net which Bob Moskowitz is
> building.
> 
> For simplicity, let's assume orgs A, B, and C, connected in a "full
> mesh" of leased lines (A-B, A-C, and B-C).  Assume filtering routers
> on each leased line, so that C can't impersonate B when communicating
> with A.  We now want to migrate to IPSEC without causing a flag day.
> 
> Let's start by replacing the leased line between C and A with a tunnel
> over an untrusted network protected with AH or ESP.
> 
> What stops C from tunnelling a packet to A with a source address on
> B's network?  You need a policy check that the packet emerging from
> the tunnel is from a source address which is allowed to use that
> particular tunnel..

Unfortunately, I misinterpreted this the first time it came around.
I'll diagram several "packets" to illustrate :

original packet :
  IP_HEADER(gateC->gateA)
  AH(gateC->gateA)
  IP_HEADER(hostB->hostA)
  PACKET

de-encapsulated packet :
  IP_HEADER(hostB->hostA)
  PACKET

There are no checks that we want to do on the original packet.  I was
assuming that you wanted to check the source address on the original
packet, which is made immaterial by checking the AH.  The policy
decision you are talking about is on the source address of the
de-encapsulated packet, which I agree is necessary.

In most cases it wouldn't be necessary because you share the tunnel with
a *trusted* gateway.  But in this case, there is certainly need for
additional machinery to do the policy work.


ben

From owner-ipsec  Tue Nov 26 18:28:40 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15319 for ipsec-outgoing; Tue, 26 Nov 1996 18:28:36 -0500 (EST)
Date: Tue, 26 Nov 1996 15:29:12 -0800
Message-Id: <[e-mail]>
From: Karl Fox <[e-mail]>
To: Bill Sommerfeld <[e-mail]>
Cc: [e-mail] (Ben Rogers), "Whelan, Bill" <[e-mail]>,
        [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
Reply-To: Karl Fox <[e-mail]>
Organization: Ascend Communications
Sender: [e-mail]
Precedence: bulk

Bill Sommerfeld writes:
> For simplicity, let's assume orgs A, B, and C, connected in a "full
> mesh" of leased lines (A-B, A-C, and B-C).  Assume filtering routers
> on each leased line, so that C can't impersonate B when communicating
> with A.  We now want to migrate to IPSEC without causing a flag day.
> 
> Let's start by replacing the leased line between C and A with a tunnel
> over an untrusted network protected with AH or ESP.
> 
> What stops C from tunnelling a packet to A with a source address on
> B's network?  You need a policy check that the packet emerging from
> the tunnel is from a source address which is allowed to use that
> particular tunnel..

Yes, that's indeed what we do.  Any encrypting gateway that didn't
would have a huge hole in it.  I assume we're not alone in
anticipating this.
-- 
Karl Fox, servant of God, employee of Ascend Communications
3518 Riverside Drive, Suite 101, Columbus, Ohio 43221   [phone]


From owner-ipsec  Tue Nov 26 19:11:04 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15395 for ipsec-outgoing; Tue, 26 Nov 1996 19:10:35 -0500 (EST)
Message-Id: <[e-mail]>
To: [e-mail] (Ben Rogers)
cc: Bill Sommerfeld <[e-mail]>,
        "Whelan,    Bill" <[e-mail]>, [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
References: <[e-mail]> <[e-mail]>
            <[e-mail]>
In-reply-to: ben's message of "Tue, 26 Nov 1996 17:30:19 -0500".
	 <[e-mail]> 
From: "C. Harald Koch" <[e-mail]>
Organization: Secure Computing Canada Ltd.
Phone: [phone]
X-uri: <URL:http://www.eng.border.com/homes/chk/>
X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw
 z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ)
 did@Pr9
Date: Tue, 26 Nov 1996 19:12:50 -0500
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Ben Rogers writes:
> 
> It seems to me that gatewayA should never try to place an AH, nor do an
> ESP encapsulation on the packet using transport mode (assuming that
> gatewayA did not originate the packet).  A gateway that put IPSEC
> headers on packets in transport mode would not only cause confusing
> problems like this, but would have severe problems dealing with
> fragmented packets.

and 

> It makes sense to only check the headers on packets that are destined
> for the local machine.  Otherwise, we would be intercepting (and
> probably modifying) packets not destined to that machine, and violating
> many of the ideas that make IP work.  Thus, I don't see any reason that
> a gateway could use transport mode to tack on an AH to a packet from
> hostA to hostB.

I disagree. The counter example: firewalls (or John Gilmore's "cryptowalls").

I see an incredible advantage for firewalls to add IPsec information to
packets, acting as proxies for the machines they're protecting. Keeps all
your Security Association information in one place, where it can be easily
configured and monitored.

People aren't going to start ripping out their firewalls just because they
have IPsec support on their hosts; firewalls allow much more security
control than IPsec does.  (Analogy: you don't unlock the front door just
because everyone can lock their own filing cabinets).

You also write:

> Why?  I believe the RFC states that the Security Association(SA) is
> chosen using only the destination address and the SPI.  It doesn't seem
> to be illegal for several hosts to send us packets using the same
> Security Association (SPI).

A security association is *indexed* by destination address and SPI. However,
It can include information about the source, including strong authentication
checks, and instructions to reject packets from an invalid IP address. It's
not illegal for several hosts to using the same SPI, but it's also not
secure (it would allow all hosts with the same keying information to spoof
each other, for example).

I think it's much more likely that a host would enforce the use of different
SPIs (and different keys) for each different source host.

-- 
C. Harald Koch          | Senior System Developer, Secure Computing Canada Ltd.
[e-mail]          | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
[phone] (voice) | "Madness takes its toll. Please have exact change."
[phone] (fax)   |		-Karen Murphy <[e-mail]>

From owner-ipsec  Tue Nov 26 20:45:13 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15500 for ipsec-outgoing; Tue, 26 Nov 1996 20:43:37 -0500 (EST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-reply-to: Your message of "Tue, 26 Nov 1996 18:02:47 EST."
             <[e-mail]> 
Date: Tue, 26 Nov 1996 20:44:51 -0500
From: Michael Richardson <[e-mail]>
Sender: [e-mail]
Precedence: bulk


>>>>> "Bill" == Bill Sommerfeld <[e-mail]> writes:
    Bill> Let's consider the case where you're attempting to add
    Bill> AH/ESP protection to an existing network which *currently
    Bill> uses IP-address based access controls*.  Naturally, you
    Bill> don't want to create security holes while doing this.

    Bill> Let's assume you have a network of cooperating but mutually
    Bill> suspicious organizations, like the auto industry net which
    Bill> Bob Moskowitz is building.

  Let's not forget that Bob's problem is more complicated that you
actually describe :-) [Bob said he was going to write a requirements
document up in June. Did anyone see this from him?]
  But it is a good problem.

    Bill> What stops C from tunnelling a packet to A with a source
    Bill> address on B's network?  You need a policy check that the
    Bill> packet emerging from the tunnel is from a source address
    Bill> which is allowed to use that particular tunnel..

  The way I like to do this is to consider all tunnels to be virtual
interfaces. You can make add routes, etc.. Alas, I still haven't had a
chance to investigate how close that aspect (the "route add -net x.y
tunnel q.r") of the NRL code is to this assumption.
  IP spoof checks (which you say are already in place) can handle this
case without a problem.

  Good IP spoof checks are essentially:
	1. if1 = calculate route to take to reach ip->ip_src if 
		we had to reply.
	2. if interface we received ip on == if1, then okay,
		otherwise it is a spoof.

  These checks would have to be done anyway for the leased line case
for your assumption (C can not impersonate A to B) to be true.

     :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[e-mail]</A>. PGP key available.

	
  



From owner-ipsec  Tue Nov 26 20:46:39 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15516 for ipsec-outgoing; Tue, 26 Nov 1996 20:46:36 -0500 (EST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-reply-to: Your message of "Tue, 26 Nov 1996 18:02:47 EST."
             <[e-mail]> 
Date: Tue, 26 Nov 1996 20:48:27 -0500
From: Michael Richardson <[e-mail]>
Sender: [e-mail]
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Bill" == Bill Sommerfeld <[e-mail]> writes:
    Bill> Let's consider the case where you're attempting to add
    Bill> AH/ESP protection to an existing network which *currently
    Bill> uses IP-address based access controls*.  Naturally, you
    Bill> don't want to create security holes while doing this.

    Bill> Let's assume you have a network of cooperating but mutually
    Bill> suspicious organizations, like the auto industry net which
    Bill> Bob Moskowitz is building.

  Let's not forget that Bob's problem is more complicated that you
actually describe :-) [Bob said he was going to write a requirements
document up in June. Did anyone see this from him?]
  But it is a good problem.

    Bill> What stops C from tunnelling a packet to A with a source
    Bill> address on B's network?  You need a policy check that the
    Bill> packet emerging from the tunnel is from a source address
    Bill> which is allowed to use that particular tunnel..

  The way I like to do this is to consider all tunnels to be virtual
interfaces. You can make add routes, etc.. Alas, I still haven't had a
chance to investigate how close that aspect (the "route add -net x.y
tunnel q.r") of the NRL code is to this assumption.
  IP spoof checks (which you say are already in place) can handle this
case without a problem.

  Good IP spoof checks are essentially:
	1. if1 = calculate route to take to reach ip->ip_src if 
		we had to reply.
	2. if interface we received ip on == if1, then okay,
		otherwise it is a spoof.

  These checks would have to be done anyway for the leased line case
for your assumption (C can not impersonate A to B) to be true.

     :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[e-mail]</A>. PGP key available.

	
  



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQBVAwUBMpudONTTll4efmtZAQHP2wIAlMI3CxpmJQAJJjGO6L7M3HhsLgudhr3L
i8x4jUusxwi52NOKYvOlANCxknTLrLtxuV6N58UFFBl29v7Z9btUCQ==
=bQB3
-----END PGP SIGNATURE-----

From owner-ipsec  Tue Nov 26 21:35:52 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA15576 for ipsec-outgoing; Tue, 26 Nov 1996 21:35:20 -0500 (EST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail]
Subject: ANNOUNCEMENT: ISOC 1997 SYMPOSIUM NETWORK & DISTRIBUTED SYSTEM SECURITY
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <[e-mail]>
Date: Tue, 26 Nov 1996 21:35:11 -0500
From: "David M. Balenson" <[e-mail]>
Sender: [e-mail]
Precedence: bulk

---------------------------------------------------------------------------

                 THE INTERNET SOCIETY 1997 SYMPOSIUM ON
                 NETWORK AND DISTRIBUTED SYSTEM SECURITY
                              (NDSS '97)

                          10-11 FEBRUARY 1997

            SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA


  This fourth annual symposium will bring together researchers,
  implementors, and users of network and distributed system security
  technologies to discuss today's important security issues and
  challenges.  It will provide a mix of technical papers and panel
  presentations that describe promising new approaches to security
  problems that are practical, and to the extent possible, have
  been implemented.  We hope to foster the exchange of technical
  information and encourage the Internet community to deploy
  available security technologies and develop new solutions to
  unsolved problems.

WHY YOU SHOULD ATTEND

  The use of the Internet is rapidly growing and expanding into
  all aspects of our society.  Commercial organizations are coming
  under increasing pressure to make their services available on-line.
  This in turn is increasing the need for rapid and widespread
  deployment of usable and effective network and distributed system
  security technologies.  High visibility attacks on the Internet
  underscore the vulnerabilities of the Internet and the need to
  solve its security problems.  There is growing concern for securing
  the network infrastructure itself.  Recent trends in software
  distribution (such as Java and ActiveX technologies) have made
  certain attacks easier to carry out.  Privacy has become an
  important issue for the Internet.

  NDSS '97 will bring together researchers, implementors, and users
  of network and distributed system technologies to discuss today's
  important security issues and challenges.  We have selected the
  technical papers and panel presentations that describe promising
  new approaches to security problems that are practical, and to
  the extent possible, have been implemented.  Topics to be addressed
  include Internet infrastructure and routing security, security
  for the World Wide Web, Java and ActiveX security, cryptographic
  protocols, public key management, and protection of privacy.

  The symposium will have a positive impact on the state of Internet
  security.  You will have the opportunity to actively participate
  in the dialog.  Ask questions of the speakers, raise your important
  issues during the panel sessions, and let other participants know
  of your requirements, observations, and experience in this
  important area.  We hope to encourage the wide-scale deployment
  of security technologies and to promote new research that can
  address the currently unmet security needs of the Internet
  community.

CONTENTS

  Preliminary Program
  Organizing Committee
  San Diego Princess Resort
  Registration Information
  Registration Form

---------------------------------------------------------------------------

                 P R E L I M I N A R Y   P R O G R A M

SUNDAY, FEBRUARY 9

6:00 P.M. - 8:00 P.M.
RECEPTION

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

MONDAY, FEBRUARY 10

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
OPENING REMARKS

9:00 A.M.
SESSION 1: THINGS THAT GO BUMP IN THE NET
Chair: Stephen T. Kent (BBN Corporation, USA)

  Experimental Results of Covert Channel Elimination in One-Way
  Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard
  Schroeppel, Sean O'Malley, and Oliver Spatscheck (University
  of Arizona, USA)

  Blocking Java Applets at the Firewall, David M. Martin Jr.,
  Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA)

  Continuous Assessment of a Unix Configuration: Integrating
  Intrusion Detection & Configuration Analysis, Abdelaziz Mounji
  and Baudouin Le Charlier (Institut D'Informatique, Namur,
  BELGIUM)

10:30 A.M.
BREAK

11:00 A.M.
SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT
Chair: Aviel Rubin (Bellcore, USA)

12:30 NOON
LUNCH

2:00 P.M.
SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS
Chair: Christoph Schuba (Purdue University, USA)

  An Interface Specification Language for Automatically Analyzing
  Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA)

  Probable Plaintext Cryptanalysis of the IP Security Protocols,
  Steven M. Bellovin (AT&T Research, USA)

  Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun 
  Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford
  (Purdue University, USA)

3:30 P.M.
BREAK

4:00 P.M.
SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE
Chair: Russ Mundy (Trusted Information Systems, USA)

7:00 P.M.
DINNER BANQUET

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

TUESDAY, FEBRUARY 11

7:30 A.M.
CONTINENTAL BREAKFAST

8:30 A.M.
SESSION 5: ROUTING SECURITY
Chair: Hilarie Orman (DARPA, USA)

  Securing the Nimrod Routing Architecture, Karen E. Sirois and
  Stephen T. Kent (BBN Corporation, USA)

  Securing Distance-Vector Routing Protocols, Bradley R. Smith,
  Shree Murthy and J.J. Garcia-Luna-Aceves (University of California
  Santa Cruz, USA)

  Reducing the Cost of Security in Link-State Routing, R. Hauser,
  A. Przygienda and G. Tsudik (IBM and USC/ISI, USA)

10:00 A.M.
BREAK

10:30 A.M.
SESSION 6: SECURITY FOR THE WORLD WIDE WEB
Chair: Win Treese (OpenMarket, USA)

  Securing Web Access with DCE, Brian C. Schimpf (Gradient 
  Technologies, USA)

  PANEL: SECURITY FOR THE WORLD WIDE WEB
  Chair: Win Treese (OpenMarket, USA)

12:00 A.M.
LUNCH

1:30 P.M.
SESSION 7: PUBLIC KEY MANAGEMENT
Chair: Jonathan Trostle (CyberSafe, USA)

  Hierarchical Organization of Certification Authorities for
  Secure Environments, Lourdes Lopez (Universidad Politecnica de
  Madrid, SPAIN)

  Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic
  (Univeristy of Salford, UNITED KINGDOM)

  Distributed Authentication in Kerberos Using Public Key
  Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie 
  Mellon University, USA)

3:00 P.M.
BREAK

3:30 P.M.
SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY
Chair: (To Be Determined)


---------------------------------------------------------------------------

                O R G A N I Z I N G   C O M M I T T E E

GENERAL CHAIR
  David Balenson, Trusted Information Systems

PROGRAM CHAIRS
  Clifford Neuman, USC Information Sciences Institute
  Matt Bishop, University of California at Davis

PROGRAM COMMITTEE
  Steve Bellovin, AT&T Research
  Tom Berson, Anagram Laboratories
  Doug Engert, Argonne National Laboratory
  Warwick Ford, Verisign
  Richard Graveman, Bellcore
  Li Gong, JavaSoft
  Burt Kaliski, RSA Laboratories
  Steve Kent, BBN Corporation
  Tom Longstaff, CERT
  Doug Maughan, National Security Agency
  Dan Nessett, 3Com Corporation
  Hilarie Orman, DARPA/ITO
  Michael Roe, University of Cambridge
  Christoph Schuba, Purdue University
  Jonathan Trostle, CyberSafe
  Theodore Ts'o, Massachusetts Institute of Technology
  Doug Tygar, Carnegie Mellon University
  Vijay Varadharajan, University of W. Sydney
  Roberto Zamparo, Telia Research

PUBLICATIONS CHAIR
  Steve Welke, Institute for Defense Analyses

LOCAL ARRANGEMENTS CHAIR
  Thomas Hutton, San Diego Supercomputer Center

REGISTRATIONS CHAIR
  Torryn Brazell, Internet Society

STEERING GROUP
  Internet Research Task Force, Privacy and Security Research Group

SPONSORED BY THE INTERNET SOCIETY
  Donald M. Heath, President & CEO
  Martin Burack, Executive Director


---------------------------------------------------------------------------

           S A N   D I E G O   P R I N C E S S   R E S O R T

LOCATION

  The Symposium venue is the San Diego Princess Resort, a tropical
  paradise on a forty-four acre island in Mission Bay, ten minutes
  from the international airport.  Lush gardens landscaped with
  hundreds of species of tropical and subtropical plants are
  always ablaze with color and perfect for themed group events.
  Charming pathways wander among sparkling waterfalls, across
  quaint footbridges and sleepy lagoons filled with water lilies
  and waterfowl.  A white sand beach curves around the island
  for over a mile, and the award-winning grounds encompass five
  swimming pools and six lighted tennis courts.

  Spouses and family members can catch a convenient Harbor Hopper
  for a quick trip to Sea World.  Plan to visit La Jolla, the world
  famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley.

HOUSING INFORMATION

  We have reserved a special block of sleeping rooms at the San Diego
  Princess Resort at the following rates:

      Lanai Patio Rooms           $ 81*
      Lanai Garden Rooms          $114

  * This represents the Government Rate for San Diego.  A limited 
    number of rooms are available at this rate.  Reservations must 
    be made no later than January 13, 1997.  You must present a 
    valid government id upon check-in.

  Based on room type and space availability, the special group
  rates are applicable two days prior to and two days after the
  symposium.  Current Room Tax is 10.5%.

  Check-in availability cannot be committed prior to 4:00 p.m.
  Check-out time is 12:00 noon. The San Diego Princess Resort
  will make every effort to accommodate any early arrivals, so
  make sure you give them your arrival time when you make your
  reservation.

TO MAKE A RESERVATION

  Contact the San Diego Princess Resort at [phone]
  ([phone] if outside the United States).  To receive
  the special group rates, reservations must be made no later
  than January 20, 1997.  To receive the special goverment 
  rate, you must make your reservation by January 13, 1997.

CLIMATE

  February weather in San Diego is normally very pleasant.  Early
  morning temperatures average 55 degrees while afternoon
  temperatures average 67 degrees.  Generally, a light jacket or
  sweater is adequate, although, occasionally it rains.

---------------------------------------------------------------------------

            R E G I S T R A T I O N   I N F O R M A T I O N

FEES                                      ISOC            Non-
                                         Members         Member*
  Early registration 
  (postmarked on/before Jan. 22)         $305            $345

  Late registration                      $375            $415

REGISTRATION INCLUDES

  - Attendance      - Symposium Proceedings     - Two luncheons
  - Reception       - Banquet                   - Coffee Breaks

  * Non-Member fee includes one year Internet Society membership.

FOR MORE INFORMATION 

  Contact Carol Gray at the Internet Society at [phone] 
  or send E-mail to [e-mail].

WEB PAGE

  Additional information about the symposium and San Diego, plus
  on-line registration, are available via the Web at:

            http://www.isoc.org/conferences/ndss97

SPONSORSHIP OPPORTUNITIES AVAILABLE!

  Contact Torryn Brazell at the Internet Society at [phone] 
  or send E-mail to [e-mail].

---------------------------------------------------------------------------

                  R E G I S T R A T I O N   F O R M

INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY
10-11 FEBRUARY, 1997                       SAN DIEGO, CALIFORNIA, USA

Fill out this form and FAX it to NDSS'97 Registration at [phone],
send it via E-mail to [e-mail], or mail it to NDSS97,
12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA

PERSONAL INFORMATION

  __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle

  First Name: ________________________________  MI: ____________________

  Family Name: ___________________________________  __Sr __Jr __II __III

  Badge Name: __________________________________________________________
  Please enter your name as you would like it to appear on your name tag.

CONTACT INFORMATION

  Title: _______________________________________________________________

  Organization: ________________________________________________________

  Street address: ______________________________________________________

  ______________________________________________________________________

  City: ________________________________________________________________

  State/Province: ___________________________  Postal Code: ____________

  Country: _____________________________________________________________

  Telephone Number (work): _____________________________________________

  Telephone Number (home): _____________________________________________

  Fax Number: __________________________________________________________

  E-mail address: ______________________________________________________

SPECIAL NEEDS?  (Vegetarian meals, wheelchair access, etc?)

  ______________________________________________________________________

  ______________________________________________________________________

APPEAR ON REGISTRANTS LIST?

  ___  Please check here if you would NOT like your name included 
       in the list of registrants.

PAYMENT INFORMATION

  All Payments must be in United States Dollars.

  Conference Fee
  --------------

  If you are an Internet Society member, you are eligible for a
  reduced conference registration fee.  Non-member symposium 
  attendees will receive a one year Internet Society membership 
  as part of the non-member registration fees.

  Check one:                        On/Before        After
                                    January 22    January 22
                                    ----------    ----------
  ___ Internet Society Member Fee   US$ 305.00    US$ 375.00

  ___ Non-Member Fee                US$ 345.00    US$ 415.00

  Method of Payment
  -----------------

  Payment must be received on/before February 7, 1997 or we will 
  be unable to pre-register you.

  1. ___ Check.  Make payable to the Internet Society.  

  2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard

         Name on Credit Card: ____________________________________
  
         Credit Card Number: _____________________________________

         Expiration Date: ________________________________________

  3. ___ CyberCash.  Account Number: _____________________________

  4. ___ First Virtual.  Account Number: _________________________

  5. ___ Wire Transfer*		

         Bank ABA Number: 054000030
         Account Number: Internet Society 148 387 10

         Riggs National Bank of Virginia   
         950 Herndon Parkway               
         Herndon, VA  20171  USA

         Wire Transfer Confirmation Number: ______________________

         * Please process wire transfer before sending registration 
	   form.

  6. ___ U.S. Government Purchase Order*

         P.O. Number: ____________________________________________

         * Please fax or mail a copy of your purchase order along 
	   with your registration form.

  Cancellation Policy
  -------------------

  Refunds (less a $25 processing fee) will be issued for cancellations 
  received on/before February 7, 1997.  No refunds will be issued 
  after February 7, 1997.

------------------------------------------------------------------------


From owner-ipsec  Wed Nov 27 07:25:54 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15967 for ipsec-outgoing; Wed, 27 Nov 1996 07:20:51 -0500 (EST)
To: IETF-Announce:;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: HMAC-MD5: Keyed-MD5 for Message Authentication to
	 Informational
Date: Tue, 26 Nov 1996 13:13:51 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk



  The IESG has reviewed the Internet-Draft "HMAC: Keyed-Hashing for
  Message Authentication" <draft-ietf-ipsec-hmac-md5-01.txt> and
  recommends that it be published by the RFC Editor as an Informational
  RFC. This document is the product of the IP Security Protocol Working
  Group. The IESG contact person is Jeffrey Schiller.



--
John C. Kelley
System Administrator                            [phone]
Trusted Information Systems, Inc.               [phone] FAX
3060 Washington Road                            [e-mail] (work)
Glenwood, MD  21738                             [e-mail] (play)


From owner-ipsec  Wed Nov 27 11:29:19 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17029 for ipsec-outgoing; Wed, 27 Nov 1996 11:23:12 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ipsec-inline-isakmp-00.txt
Date: Wed, 27 Nov 1996 10:17:08 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
Precedence: bulk

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the IP Security Protocol Working
 Group of the IETF.                                                        

       Title     : Inline Keying within the ISAKMP Framework.              
       Author(s) : B. Sommerfeld
       Filename  : draft-ietf-ipsec-inline-isakmp-00.txt
       Pages     : 9
       Date      : 11/26/1996

The current proposal for IP-layer key management [ISAKMP, OAKLEY, ISAOAK] 
has fairly high overhead.  Before a security association can be 
established, at least one pair of messages need to be exchanged between the
communicating peers.  For efficiency, this suggests that ISAKMP setup 
should be infrequent.  However, general principles of key management 
suggest that individual keys should be used as little as practical and 
changed as frequently as possible.  Steve Bellovin has suggested that, 
ideally, different security associations should be used for each different 
transport-level connection[BADESP]. 

This document discusses different ways of structuring a protocol to 
permit this to happen with minimal overhead, both in round-trip delay 
at connection setup, and in bandwidth once the connection is established. 

Portions of this protocol have been inspired by SKIP, which is 
fundamentally built around the concept of inline keying[SKIP]. 
SKIP's approach is burdened by the addition of an extra intermediate 
header of perhaps 20 to 28 bytes to every protected packet, essentially 
doubling the overhead of protected traffic compared with ESP 
with manual keying.                                                        

Ideally, an inline keying header would be used only until the desired
security association is established, at which point the peers will
fall back to pure ESP/AH.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-ipsec-inline-isakmp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  nic.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [e-mail]. In the body type: 
     "FILE /internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipsec-inline-isakmp-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--

--NextPart--

From owner-ipsec  Wed Nov 27 13:07:01 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17200 for ipsec-outgoing; Wed, 27 Nov 1996 13:02:25 -0500 (EST)
Date: Wed, 27 Nov 1996 13:02:52 -0500 (EST)
Message-Id: <[e-mail]>
From: Ben Rogers <[e-mail]>
To: "C. Harald Koch" <[e-mail]>
Cc: Bill Sommerfeld <[e-mail]>,
        "Whelan,    Bill" <[e-mail]>, [e-mail]
Subject: Re: AH (without ESP) on a secure gateway 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
	<[e-mail]>
Reply-To: [e-mail] (Ben Rogers)
Sender: [e-mail]
Precedence: bulk

C. Harald Koch writes:
> In message <[e-mail]>, Ben Rogers writes:
> > 
> > It seems to me that gatewayA should never try to place an AH, nor do an
> > ESP encapsulation on the packet using transport mode (assuming that
> > gatewayA did not originate the packet).  A gateway that put IPSEC
> > headers on packets in transport mode would not only cause confusing
> > problems like this, but would have severe problems dealing with
> > fragmented packets.
> 
> and 
> 
> > It makes sense to only check the headers on packets that are destined
> > for the local machine.  Otherwise, we would be intercepting (and
> > probably modifying) packets not destined to that machine, and violating
> > many of the ideas that make IP work.  Thus, I don't see any reason that
> > a gateway could use transport mode to tack on an AH to a packet from
> > hostA to hostB.
> 
> I disagree. The counter example: firewalls (or John Gilmore's "cryptowalls").
> 
> I see an incredible advantage for firewalls to add IPsec information to
> packets, acting as proxies for the machines they're protecting. Keeps all
> your Security Association information in one place, where it can be easily
> configured and monitored.
> 
> People aren't going to start ripping out their firewalls just because they
> have IPsec support on their hosts; firewalls allow much more security
> control than IPsec does.  (Analogy: you don't unlock the front door just
> because everyone can lock their own filing cabinets).

Hmmm.... This statement doesn't seem to disagree with my original
statement.  I said that the gateway should never do encapsulation in
*transport* mode.  Tunnel mode is still acceptable, and would be the
perfect thing to use in this case -- the "cryptowall" would ben one of
the tunnel endpoints.

The problem in using transport mode on a gateway lies mainly in the
fragmentation of packets.  Imagine that the "cryptowall" receives a 1500
byte fragment, and adds a header to it.  The authenticated packet is
then again too big to send out on ether, and so it must be fragmented
again.  The problem is that we changed the size of the total packet by
adding the AH to it.  You *cannot* calculate fragment offsets in an
unambiguous manner without keeping the enough state to calculate new
offsets for all the other fragments.

> You also write:
> 
> > Why?  I believe the RFC states that the Security Association(SA) is
> > chosen using only the destination address and the SPI.  It doesn't seem
> > to be illegal for several hosts to send us packets using the same
> > Security Association (SPI).
> 
> A security association is *indexed* by destination address and SPI. However,
> It can include information about the source, including strong authentication
> checks, and instructions to reject packets from an invalid IP address. It's
> not illegal for several hosts to using the same SPI, but it's also not
> secure (it would allow all hosts with the same keying information to spoof
> each other, for example).
> 
> I think it's much more likely that a host would enforce the use of different
> SPIs (and different keys) for each different source host.

This is definitely the more secure method, and should be used when you
are dealing with untrustworthy peers.  However, if you trust your peers,
there is no reason to disallow a priori several "source" hosts sending
you packets on the same security association.  If all you want to do is
to authenticate that someone sending to the multicast address is allowed
to, and not to authenticate their individual identity, then this should
be sufficient, and should save space (in not having to have seperate
security associations for a large number of "identical" peers).

You can still check on source address if you want (for example, in a
"cryptowall"), but it seems that this should be a policy decision, and
should be separated from plain vanilla IP security.


ben

From owner-ipsec  Wed Nov 27 15:14:07 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17538 for ipsec-outgoing; Wed, 27 Nov 1996 15:10:28 -0500 (EST)
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 4.1
Date: Wed, 27 Nov 1996 12:11:44 -0800
From: CJ Lee <[e-mail]>
To: [e-mail]
Subject: Re: replay counter size
Sender: [e-mail]
Precedence: bulk

Derrell Piper wrote sometime back:
> The latest HMAC AH draft (the one following
Montreal) specifies a 64-bit
> replay field.  The latest Combined ESP draft uses
only a 32-bit field.
> 
> Jim, was it your intention for these specs to diverge
like this?  I 
> would like to understand why these fields need to be
different for AH 
> and ESP.  I would rather see them be the same.  I
personally believe that 
> 2^32 packets is too much data to encrypt under one
key anyway, so I 
> think 32-bits is the right number.  But I'm more
concerned that AH and 
> ESP be equally protected.
> 
> I recall some discussion in Montreal about the
performance of replay 
> window checks being dependent on the underlying
hardware register size, 
> which supports our desire to make this
implementation dependent.  I do 
> not recall discussing changing the replay counter
from 32 to 64 bits, 
> though I confess to being a bit late for the first
working group meeting, 
> due to not being able to get into the room due to
overcrowding.

I don't remember that I saw an explanation about the
question on the 
mailing list.  To me, different replay counter size for
different AH/ESP 
transforms would definitely complicate an IPsec
implementation in terms
of storing and using the per session (SA) replay
checking state - the 
largest counter seen so far.  I'd appreciate that
someone could enlighten 
me on this.

CJ Lee  ([e-mail])

From owner-ipsec  Wed Nov 27 15:48:50 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17619 for ipsec-outgoing; Wed, 27 Nov 1996 15:48:21 -0500 (EST)
From: [e-mail]
Date: Wed, 27 Nov 1996 15:53:29 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: AH (without ESP) on a secure gateway
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Md5: b4Ny6eHOqoEJQTvjvj0zEA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA17616
Sender: [e-mail]
Precedence: bulk

I have a question triggered by the discussion :

  If two firewalls (gateways), IDii and IDir, did a successful ISAKMP
  phase-II proxy negotiation for IDui and IDur. Then, which one is the
  right usage of the SA resulting from the negotiation :
  
  
  1. The SA is shared between IDii and IDir (the gateways), and IDii
     IDir are performing IPSEC protection on traffic between IDui and
     IDur. In this case, IDui and IDur are unware of the IPSEC protection.
     
     
  2. The SA is shared between IDui and IDur and IDui and IDur perform IPSEC
     by themselves. IDii and IDir (the gateways) become more or less (IPSEC)
     transparent.
     
     
     



Pau-Chen

From owner-ipsec  Wed Nov 27 16:20:30 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17662 for ipsec-outgoing; Wed, 27 Nov 1996 16:18:18 -0500 (EST)
Message-Id: <[e-mail]>
From: Greg Carter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: ISAKMP & IPSEC DOI Drafts - Notify Payload - Certificate Authorities
Date: Wed, 27 Nov 1996 15:50:35 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
Sender: [e-mail]
Precedence: bulk

Questions on ISAKMP draft:

Can Notify Payloads be sent in any exchange or are they valid only in
Informational Exchanges?

What action should be taken when a Notify Payload is received and the
Message Type is not known.  i.e. My ISAKMP server is using some of the
private Message Types to exchange Environment information, but the peer
ISAKMP server has no concept of this info (and hence the private message
types).

Section 3.10 Certificate Request Payload of ISAKMP - draft 6

For the Certificate Authorities field it references the IPSEC DOI
document, however I couldn't find any reference to 'Distinguished Name
Attribute Type' value in the IPSEC DOI doc.

Could someone expand on this?

Thanks.
----
Greg Carter
Nortel Secure Networks - Entrust
[e-mail]



From owner-ipsec  Fri Nov 29 11:37:15 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19253 for ipsec-outgoing; Fri, 29 Nov 1996 11:24:00 -0500 (EST)
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
From: Greg Carter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Certificate Request Payload
Date: Fri, 29 Nov 1996 11:16:34 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24
Sender: [e-mail]
Precedence: bulk


>From draft 6 of ISAKMP
3.10 Certificate Request Payload
..."The responder to the Certificate Request payload MUST send its
immediate certificate,
if certificates are supported, and SHOULD send as much of its
certificate chain as possible."

As part of the certificate chain can we send Certificate Revocation
Lists (CRL) and Authority Revocation
Lists (ARL)?

Or was it intended that the certificate chain only include the immediate
certificates of the users/CAs in 
question?

Thanks
----
Greg Carter
Nortel Secure Networks - Entrust
[e-mail]

From owner-ipsec  Sat Nov 30 19:18:17 1996
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA19768 for ipsec-outgoing; Sat, 30 Nov 1996 19:09:29 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 30 Nov 1996 16:11:40 -0800
To: [e-mail]
From: Bob Monsour <[e-mail]>
Subject: I-D ACTION:draft-sabin-lzs-payload-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

For those on the list who might not be on the "announce" list.
-Bob

>To: IETF-Announce: ;
>Sender: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-sabin-lzs-payload-00.txt
>Date: Wed, 27 Nov 1996 10:18:23 -0500
>X-Orig-Sender: [e-mail]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.                                                              
>
>       Title     : LZS Payload Compression Transform for ESP               
>       Author(s) : M. Sabin, R. Monsour
>       Filename  : draft-sabin-lzs-payload-00.txt
>       Pages     : 7
>       Date      : 11/26/1996
>
>This memo proposes a "payload compression transform" based on the LZS 
>compression algorithm.  The transform can be used to compress the payload 
>field of an IP datagram that uses the Encapsulating Security Payload (ESP) 
>format.  The compression transform proposed here is stateless, meaning that
>a datagram can be decompressed independently of any other datagram.  
>Compression is performed prior to the encryption operation of ESP, which 
>has the side benefit of reducing the amount of data that must be encrypted.
>
>This memo anticipates a forthcoming draft of ESP that will supercede 
>[Atkins96].  The forthcoming draft will allow for ESP payloads to be 
>compressed via transforms such as the one described in this memo.          
>
>Internet-Drafts are available by anonymous FTP.  Login with the username
>"anonymous" and a password of your e-mail address.  After logging in,
>type "cd internet-drafts" and then
>     "get draft-sabin-lzs-payload-00.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-sabin-lzs-payload-00.txt
> 
>Internet-Drafts directories are located at:	
>	                                                
>     o  Africa:  ftp.is.co.za                    
>	                                                
>     o  Europe:  nic.nordu.net            	
>                 ftp.nis.garr.it                 
>	                                                
>     o  Pacific Rim: munnari.oz.au               
>	                                                
>     o  US East Coast: ds.internic.net           
>	                                                
>     o  US West Coast: ftp.isi.edu               
>	                                                
>Internet-Drafts are also available by mail.	
>	                                                
>Send a message to:  [e-mail]. In the body type: 
>     "FILE /internet-drafts/draft-sabin-lzs-payload-00.txt".
>							
>NOTE: The mail server at ds.internic.net can return the document in
>      MIME-encoded form by using the "mpack" utility.  To use this
>      feature, insert the command "ENCODING mime" before the "FILE"
>      command.  To decode the response(s), you will need "munpack" or
>      a MIME-compliant mail reader.  Different MIME-compliant mail readers
>      exhibit different behavior, especially when dealing with
>      "multipart" MIME messages (i.e., documents which have been split
>      up into multiple messages), so check your local documentation on
>      how to manipulate these messages.
>							
>							
>
>Below is the data which will enable a MIME compliant mail reader 
>implementation to automatically retrieve the ASCII version
>of the Internet-Draft.
>
><ftp://ds.internic.net/internet-drafts/draft-sabin-lzs-payload-00.txt>
>