Received: from relay.hq.tis.com by neptune.TIS.COM id aa29884; 1 Aug 96 3:58 EDT
Received: by relay.hq.tis.com; id EAA08190; Thu, 1 Aug 1996 04:01:19 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008183; Thu, 1 Aug 96 04:00:55 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11687; Thu, 1 Aug 96 04:00:27 EDT
Received: by relay.hq.tis.com; id EAA08175; Thu, 1 Aug 1996 04:00:53 -0400
Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1)
id xma008154; Thu, 1 Aug 96 04:00:19 -0400
Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id BAA20589; Thu, 1 Aug 1996 01:02:40 -0700 (PDT)
Message-Id: <199608010802.BAA20589@toad.com>
X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: Ran Atkinson <rja@cisco.com>
Cc: ipsec@TIS.COM, postel@isi.edu, gnu@toad.com
Subject: Re: Key Management, anyone? (DNS keying)
In-Reply-To: <199607230358.UAA20330@puli.cisco.com>
Date: Thu, 01 Aug 1996 01:02:40 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Ran Atkinson said:
> The IETF requires that _implementations_ of IP also _implement_
> support for DNS. The IETF does NOT require that users actually _USE_
> DNS. Now most users DO use DNS because it is widely implemented and
> it is often easier to use than typing an IP number. However, on
> occasion users (e.g. me) don't use DNS and instead just type an IP
> number on the command line (e.g. "telnet 1.2.3.4") and this isn't
> violating any IETF requirement.
I agree it's desirable to maintain the ability to use manual keying,
like the ability to use manual IP addressing.
> Similarly, the IPsec WG would be wrong to try to mandate that "users
> MUST use DNS to obtain IPsec keys", while it might be very legitimate
> for the IPsec WG to mandate that "IPsec implementations SHOULD/MUST
> also implement support for DNSsec" if that is what the IPsec WG were
> to decide to do. [1]
In the context of "If you use the IPSEC WG's key management protocol",
it would be a perfectly fine statement for us to say "the key
management software MUST use DNS to obtain IPsec keys". It's like the
SMTP spec saying that mailers MUST look for DNS MX records rather than
simply looking up domain names in a "host table" file somewhere. If
we build a mechanism to solve a problem, and expect to use it widely,
then we should mandate its use in that problem domain, to guarantee
interoperability.
The effort we're going through to define a single key management
protocol would be wasted, if that unified key management protocol
ended up having to try six different ways to find the other guy's
public key. Or to find out if the other guy supports IPSEC at all.
Those folks who use somebody else's key management protocol, of course,
can get keys by telepathy, voodoo, or by extracting them from a key
escrow database. The WG should never say "this is the only key
management protocol or key publication protocol you can use". Instead
it's "if you want to interoperate with all the other hosts that use
this standard, then you should use the protocols we specify".
Communications networks that have different needs are completely free
to implement both WG-keying to talk to the public and e.g. MIL-keying
to talk to each other.
The military will be using different packet-level transforms as well,
since Skipjack is not as far as I know on the IETF standards track.
That would be troublesome, since there is no published spec. I don't
think NSA can twist IESG's arm the way they twisted NIST's, to issue a
standard which says "Poof, it's a standard, even though we refuse to
tell you how it works". They might even have trouble getting IANA to
issue them an algorithm number without specifying the algorithm that
it identifies.
Given that the key-escrowed government network will not use either
IPSEC standard transforms, or an IPSEC standard key exchange protocol
like Oakley or Photuris, it clearly need not use DNS keys either. But
by the same token, their needs or desires are no reason for the rest
of us to *avoid* using DNS keys.
> NOTE 1: IETF rules prohibit a standards-track RFC at level N in the standards
> process from back referencing a standards-track RFC at a level less
> than N. At present, IPsec is a Proposed Standard and DNSsec is not
> a standards-track RFC. This winter, IPsec will probably move to
> Draft Standard, but DNSsec is required to remain at Proposed Standard
> until (1) at least 6 months have passed since publication as a
> Proposed Standard RFC and (2) interoperability of multiple independent
> implementations is demonstrated. Hence, if the IPsec RFCs mandate
> implementation of DNSsec, then the progress of the IPsec RFCs is
> likely to be delayed accordingly. It is up to the WG as a whole
> to develop consensus on whether such an explicit standards-dependence
> is desirable.
Ran, please don't try to mislead the group on procedural issues.
The only IPSEC RFC that would require the use of DNSSEC (if any did)
is the IPSEC key management RFC. It isn't yet an Internet-Draft, let
alone a standards-track RFC; it's still being hashed out in a
smoke-filled room upon Jeff Schiller's request. DNSSEC will be way
ahead of it in the standards track, so there is no delay issue.
John Gilmore
Received: from relay.hq.tis.com by neptune.TIS.COM id aa00883; 1 Aug 96 5:09 EDT
Received: by relay.hq.tis.com; id FAA08730; Thu, 1 Aug 1996 05:11:48 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008728; Thu, 1 Aug 96 05:11:19 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA12829; Thu, 1 Aug 96 05:10:52 EDT
Received: by relay.hq.tis.com; id FAA08725; Thu, 1 Aug 1996 05:11:18 -0400
Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1)
id xma008723; Thu, 1 Aug 96 05:11:08 -0400
Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id FAA29883; Thu, 1 Aug 1996 05:16:26 -0400 (EDT)
Received: by earth.hpc.org (SMI-8.6/SMI-SVR4)
id FAA21838; Thu, 1 Aug 1996 05:15:04 -0400
Date: Thu, 1 Aug 1996 05:15:04 -0400
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199608010915.FAA21838@earth.hpc.org>
To: PALAMBER@us.oracle.com
Cc: ipsec@TIS.COM
In-Reply-To: Yourmessage <9607312301.AA16100@maildig1.us.oracle.com>
Subject: Re: DNS? was Re: Key Management, anyone?
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I agree with the individual points, but I'm not convinced by the conclusion.
Why isn't DNSSEC the appropriate minimal common basis for authentication?
I believe we need such a basis, and DNSSEC seems to be the obvious choice.
This wouldn't rule out the optional use of other methods.
TCP requires IP, so the IETF guidelines cannot be taken too seriously in
the regard to banning protocol dependencies!
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03367; 1 Aug 96 8:04 EDT
Received: by relay.hq.tis.com; id IAA09912; Thu, 1 Aug 1996 08:06:49 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma009894; Thu, 1 Aug 96 08:06:22 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16213; Thu, 1 Aug 96 08:05:54 EDT
Received: by relay.hq.tis.com; id IAA09888; Thu, 1 Aug 1996 08:06:20 -0400
Received: from servo.qualcomm.com(129.46.128.14) by relay.tis.com via smap (V3.1.1)
id xma009864; Thu, 1 Aug 96 08:05:57 -0400
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id FAA18604; Thu, 1 Aug 1996 05:08:09 -0700 (PDT)
Date: Thu, 1 Aug 1996 05:08:09 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199608011208.FAA18604@servo.qualcomm.com>
To: adams@tgv.com
Cc: ipsec@TIS.COM, naganand@ftp.com
In-Reply-To: <19960731140101adams@North-Bridge.cisco.com> (message from Rob Adams on Wed Jul 31 14:01:01 1996)
Subject: Re: Question on TCP MSS with repsect to IPSEC
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
You can only do so much to reduce TCP segment sizes to account for
IPSEC headers. Especially since a very common (if not the single most
important) case of tunnel mode assumes a TCP that knows nothing about
IPSEC.
The best you can really hope for is Path MTU support on the sending
TCP that will respond appropriately to ICMP messages from an IPSEC
tunnel endpoint that knows what its next hop interface MTU is after
being adjusted for IPSEC overhead.
Phil
Received: from relay.hq.tis.com by neptune.TIS.COM id aa04633; 1 Aug 96 9:08 EDT
Received: by relay.hq.tis.com; id JAA11607; Thu, 1 Aug 1996 09:11:17 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011600; Thu, 1 Aug 96 09:10:48 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19537; Thu, 1 Aug 96 09:10:20 EDT
Received: by relay.hq.tis.com; id JAA11594; Thu, 1 Aug 1996 09:10:47 -0400
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1)
id xma011591; Thu, 1 Aug 96 09:10:33 -0400
Received: from ftp.com by ftp.com ; Thu, 1 Aug 1996 09:12:52 -0400
Received: from athena.ftp.com by ftp.com ; Thu, 1 Aug 1996 09:12:52 -0400
Message-Id: <2.2.32.19960801131747.009ac5f4@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 01 Aug 1996 09:17:47 -0400
To: Phil Karn <karn@qualcomm.com>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: Question on TCP MSS with repsect to IPSEC
Cc: adams@tgv.com, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Phil,
>The best you can really hope for is Path MTU support on the sending
>TCP that will respond appropriately to ICMP messages from an IPSEC
>tunnel endpoint that knows what its next hop interface MTU is after
>being adjusted for IPSEC overhead.
>
Doesnt the ICMP message indicate the datagram size (IP Header + data) that
it can send? This being the case, the router or tunnel end point may not
take into account the overhead of IPSEC, correct?
In this scenario, it will be upto the host sending the IPSEC traffic to
adjust the tcp data size.
Thanks,
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
Received: from relay.hq.tis.com by neptune.TIS.COM id aa06054;
1 Aug 96 10:08 EDT
Received: by relay.hq.tis.com; id KAA13222; Thu, 1 Aug 1996 10:11:38 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma013215; Thu, 1 Aug 96 10:11:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA22839; Thu, 1 Aug 96 10:10:42 EDT
Received: by relay.hq.tis.com; id KAA13208; Thu, 1 Aug 1996 10:11:08 -0400
Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1)
id xma013198; Thu, 1 Aug 96 10:10:43 -0400
Received: from munin.fnal.gov ("port 3517"@munin.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7R8IQU1JM001G3M@FNAL.FNAL.GOV>;
Thu, 01 Aug 1996 09:13:05 -0600 (CST)
Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m)
id JAA02474; Thu, 01 Aug 1996 09:11:31 -0500 (CDT)
Date: Thu, 01 Aug 1996 09:11:30 -0500
From: Matt Crawford <crawdad@fnal.gov>
Subject: Re: Question on TCP MSS with repsect to IPSEC
In-Reply-To: "01 Aug 1996 05:08:09 PDT."
<"199608011208.FAA18604"@servo.qualcomm.com>
To: Phil Karn <karn@qualcomm.com>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: adams@tgv.com, ipsec@TIS.COM, naganand@ftp.com
Message-Id: <199608011411.JAA02474@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> You can only do so much to reduce TCP segment sizes to account for
> IPSEC headers. Especially since a very common (if not the single most
> important) case of tunnel mode assumes a TCP that knows nothing about
> IPSEC.
Pardon my cloddish opinion, but I think that's the EASY case. The
tunnel's far end will decapsulate and the receiver will find its MSS
has been respected.
> The best you can really hope for is Path MTU support on the sending
> TCP that will respond appropriately to ICMP messages from an IPSEC
> tunnel endpoint that knows what its next hop interface MTU is after
> being adjusted for IPSEC overhead.
I think we've all been presuming an implicit MIN(PMTU, MSS+10*ip->ip_v).
_________________________________________________________
Matt Crawford crawdad@fnal.gov Fermilab
PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A
Received: from relay.hq.tis.com by neptune.TIS.COM id aa08256;
1 Aug 96 11:51 EDT
Received: by relay.hq.tis.com; id LAA16379; Thu, 1 Aug 1996 11:54:18 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma016376; Thu, 1 Aug 96 11:54:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01031; Thu, 1 Aug 96 11:53:28 EDT
Received: by relay.hq.tis.com; id LAA16366; Thu, 1 Aug 1996 11:53:21 -0400
Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1)
id xma016350; Thu, 1 Aug 96 11:52:54 -0400
Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id LAA13272 for <ipsec@TIS.COM>; Thu, 1 Aug 1996 11:55:17 -0400
Received: from depot(144.51.53.1) by guardian via smap (V1.3)
id sma013267; Thu Aug 1 11:55:04 1996
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA13723 for <ipsec@TIS.COM>; Thu, 1 Aug 1996 11:51:42 -0400
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4)
id LAA02388; Thu, 1 Aug 1996 11:54:55 -0400
Date: Thu, 1 Aug 1996 11:54:55 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Message-Id: <199608011554.LAA02388@argon.ncsc.mil>
To: ipsec@TIS.COM
Subject: Re: Key Management, anyone? (DNS keying)
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
John Gilmore wrote:
> In the context of "If you use the IPSEC WG's key management protocol",
> it would be a perfectly fine statement for us to say "the key
> management software MUST use DNS to obtain IPsec keys".
That is unacceptable, given the current state of DNSsec. I don't
believe that the requirement to use real certificates for IPSEC keying
is going to disappear, and DNSsec has made an explicit decision not
to support X.509, PGP, or any other mainstream certificate format.
> Those folks who use somebody else's key management protocol, of course,
> can get keys by telepathy, voodoo, or by extracting them from a key
> escrow database.
Instead of telepathy and voodoo, perhaps keys could be gotten by using
LDAP (RFC 1777/1798, or LDAP V3: draft-ietf-asid-ldapv3-protocol-01.txt).
Or they could be gotten from a Web directory server using URLs as
pointers. Or instead of X.509, certificates could be in SPKI format as
defined by Ellison, Frantz, and Thomas. Will DNSsec support SPKI
certificates?
This isn't about "somebody else's" protocol; we're talking about the
IPSEC key management protocol which will standardize a set of mandatory,
recommended, and optional mechanisms. Manual keying and proprietary key
management can still be used with IPSEC data transforms, of course, but
that's not particularly germaine to the topic of IPSEC key management.
> The WG should never say "this is the only key
> management protocol or key publication protocol you can use". Instead
> it's "if you want to interoperate with all the other hosts that use
> this standard, then you should use the protocols we specify".
That is contradictory to the first paragraph. I believe the IPSEC WG
position is: "Implementations of the (yet-to-be-agreed-upon) IPSEC Key
Management Protocol MUST *include code* to support using DNS to obtain
keys." There appears to be rough consensus for that position; I will
agree to disagree as long as DNSsec keys are limited to the existing
format.
But there is no WG requirement that they "MUST *use* DNS to obtain keys."
If you want to interoperate with other hosts, you need to implement a
mechanism (recommended or required) that is implemented on those other
hosts. It is entirely possible that a recommended mechanism could achieve
nearly universal coverage, if the mandatory mechanism doesn't meet user's
needs.
DNS is well-suited as a mechanism to distribute keys associated with
IP addresses. It is not as well-suited as an exclusive mechanism to
generate and certify long-term keys. It could be used as a default for
users who aren't motivated to use any other method. But if I were a
cheap Internet user (I am! :-) and had just shelled out a whole 6 bucks
for a Verisign cert, I would want to be able to use it. With the
world, not just with other owners of the same brand of firewall.
The trust models of DNSsec are currently controversial. If it is
technically impossible to define DNS RRs to carry X.509, SPKI, or
PGP certs (because of their size), then it should at least be possible
to define RRs to carry URLs or DNs to allow certs to be retrieved
from some other directory. I view that step as a requirement before
making a mandatory link between IPSEC key management and DNSsec.
> The military will be using different packet-level transforms as well,
> since Skipjack is not as far as I know on the IETF standards track.
> That would be troublesome, since there is no published spec. I don't
> think NSA can twist IESG's arm the way they twisted NIST's, to issue a
> standard which says "Poof, it's a standard, even though we refuse to
> tell you how it works". They might even have trouble getting IANA to
> issue them an algorithm number without specifying the algorithm that
> it identifies.
Hogwash.
1) The military will be using DES/3DES transforms just like everyone else
to get interoperability with the rest of the world. The military
believes that there are security advantages to doing crypto in hardware,
as well as potential performance advantages and disadvantages, and is
including DES in FORTEZZA(tm). (See recent GCN article by Paul Constance.)
2) FORTEZZA(tm) (including Skipjack) is on the IETF standards track, as
an algorithm suite in the Transport Layer Security (TLS) protocol.
That doesn't imply that anyone other than posessors of FORTEZZA(tm)
cards will be expected, or even able, to use that particular mechanism.
It meets the need of a large community of users; no objections to
standardization of FORTEZZA(tm) as an optional CipherSuite have been
raised, or even mentioned, within the TLS WG.
Sorry for shouting the name of the card; the lawyers made me do it :-(.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa15592;
1 Aug 96 19:18 EDT
Received: by relay.hq.tis.com; id TAA00107; Thu, 1 Aug 1996 19:21:08 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma000103; Thu, 1 Aug 96 19:20:41 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA24791; Thu, 1 Aug 96 19:20:12 EDT
Received: by relay.hq.tis.com; id TAA29999; Thu, 1 Aug 1996 19:20:38 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1)
id xma029993; Thu, 1 Aug 96 19:20:28 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA015741758; Thu, 1 Aug 1996 16:22:38 -0700
Message-Id: <199608012322.AA015741758@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA155051756; Thu, 1 Aug 1996 19:22:36 -0400
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Cc: ipsec@TIS.COM, ietf-tls@w3.org
Subject: Re: Key Management, anyone? (DNS keying)
In-Reply-To: dpkemp's message of Thu, 01 Aug 1996 11:54:55 -0400.
<199608011554.LAA02388@argon.ncsc.mil>
Date: Thu, 01 Aug 1996 19:22:35 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> 2) FORTEZZA(tm) (including Skipjack) is on the IETF standards track, as
> an algorithm suite in the Transport Layer Security (TLS) protocol.
> That doesn't imply that anyone other than posessors of FORTEZZA(tm)
> cards will be expected, or even able, to use that particular mechanism.
> It meets the need of a large community of users; no objections to
> standardization of FORTEZZA(tm) as an optional CipherSuite have been
> raised, or even mentioned, within the TLS WG.
well, as best I can tell, there's NO WAY for a classified algorithm to
be on the IETF standards track.
RFC1602 says:
(A) ISOC will not propose, adopt, or continue to maintain any
standards, including but not limited to standards labelled
Proposed, Draft or Internet Standards, which can only be
practiced using technology or works that are subject to
known copyrights, patents or patent applications, or other
rights, except with the prior written assurance of the
owner of rights that:
l. ISOC may, without cost, freely implement and use the
technology or works in its standards work;
2. upon adoption and during maintenance of an Internet
Standard, any party will be able to obtain the right
to implement and use the technology or works under
specified, reasonable, non-discriminatory terms; and
3. the party giving the assurance has the right and
power to grant the licenses and knows of no other
copyrights, patents, patent applications, or other
rights that may prevent ISOC and members of the
Internet community from implementing and operating
under the standard.
Now, this is part of the part of 1602 which was generally felt to be
"broken". However, the replacement for RFC1602,
draft-ietf-poised95-std-proc-3-06.txt, says:
7.1.2 Incorporation of Other Specifications
Other proprietary specifications may be incorporated by reference
to a version of the specification as long as the proprietor meets
the requirements of section 10. If the other proprietary
specification is not widely and readily available, the IESG may
request that it be published as an Informational RFC.
The IESG generally should not favor a particular proprietary
specification over technically equivalent and competing
specification(s) by making any incorporated vendor specification
"required" or "recommended".
and, later on:
10.2 Confidentiality Obligations
No contribution that is subject to any requirement of confidentiality
or any restriction on its dissemination may be considered in any part
of the Internet Standards Process, and there must be no assumption of
any confidentiality obligation with respect to any such contribution.
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa15628;
1 Aug 96 19:21 EDT
Received: by relay.hq.tis.com; id TAA00213; Thu, 1 Aug 1996 19:24:09 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma000206; Thu, 1 Aug 96 19:23:40 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA24851; Thu, 1 Aug 96 19:23:12 EDT
Received: by relay.hq.tis.com; id TAA00203; Thu, 1 Aug 1996 19:23:38 -0400
Received: from hubbub.cisco.com(198.92.30.31) by relay.tis.com via smap (V3.1.1)
id xma000185; Thu, 1 Aug 96 19:23:12 -0400
Received: from spook (dharkins-ss20.cisco.com [171.69.60.241]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id QAA19487 for <ipsec@tis.com>; Thu, 1 Aug 1996 16:29:11 -0700
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by spook (8.6.8+c/CISCO.WS.1.1) with SMTP id QAA00232 for <ipsec@tis.com>; Thu, 1 Aug 1996 16:25:49 -0700
Message-Id: <199608012325.QAA00232@spook>
X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: ipsec@TIS.COM
Subject: New ISAKMP+Oakley code!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 01 Aug 1996 16:25:48 -0700
From: Daniel Harkins <dharkins@cisco.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Cisco Systems is pleased to announce the release of the next version of
their ISAKMP daemon. This software distribution is being made available
free of charge for any commercial or non-commercial use to advance ISAKMP
as a solution to Internet Key Management.
Major changes from the previous version include:
* Compliance with draft-ietf-ipsec-isakmp-oakley-01.txt
* HMAC-MD5 ("derived from the RSA Data Security, Inc. MD5 Message-
Digest Algorithm") and HMAC-SHA.
* Colin Plumb's BigNum multiprecision integer library.
* truerand() random number generator by Don Mitchell and Matt Blaze.
To software can be obtained by pointing your favorite browser to
http://www.cisco.com/public/library/isakmp/isakmp.html and following the
hot links. This entire distribution is export controlled and unfortunately
cannot be obtained by non-US citizens or non-US permanent residents.
This daemon uses the PF_KEY Key Management API to register with a
kernel which has implemented this API and the surrounding key management
infrastructure. The NRL IPsec software distribution (currently bundled with
IPv6) is such an implementation. Security associations negotiated by the
ISAKMP daemon are inserted into the kernel's key engine and are available
for use by its AH/ESP security mechanisms. To facilitate use of this ISAKMP
daemon, the NRL distribution is also being made available an the same URL
described above.
This distribution comes with a cryptographic library from Cylink Corporation.
Cylink has granted Cisco the right to offer this library-- source code to
the Diffie-Hellman key exchange, the Digital Signature Standard, and the
Digital Encryption Standard-- to all third parties on a royalty-free basis
for use only with this ISAKMP reference implementation.
Note: Both the BigNum package and the cryptographic library come with
exercise routines to validate each package. If errors occur and the
respective README is not helpful, please contact the mailing list below
for help. If either the BigNum package or the cryptographic library is not
in full working order, the ISAKMP daemon will not work properly.
A mailing list for problems, bug fixes, porting changes, and general
discussion of ISAKMP and Oakley has been established: isakmp-oakley@cisco.com
(majordomo@cisco.com for admin requests).
Received: from relay.hq.tis.com by neptune.TIS.COM id aa17487;
1 Aug 96 22:04 EDT
Received: by relay.hq.tis.com; id WAB02141; Thu, 1 Aug 1996 22:07:09 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma002137; Thu, 1 Aug 96 22:06:40 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA27940; Thu, 1 Aug 96 22:06:13 EDT
Received: by relay.hq.tis.com; id WAA02134; Thu, 1 Aug 1996 22:06:39 -0400
Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1.1)
id xma002131; Thu, 1 Aug 96 22:06:20 -0400
Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA00346; Thu, 1 Aug 1996 22:08:38 -0400 (EDT)
Date: Thu, 1 Aug 1996 22:08:38 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Message-Id: <199608020208.WAA00346@newdev.harvard.edu>
To: dpkemp@missi.ncsc.mil, sommerfeld@apollo.hp.com
Subject: Re: Key Management, anyone? (DNS keying)
Cc: ietf-tls@w3.org, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> well, as best I can tell, there's NO WAY for a classified algorithm to
> be on the IETF standards track.
>
> rfc1602 sez:
note that RFC 1602 has been replaced and is no longer the IETF standards
process - the new process has not yet been published as an RFC but can
be found in the internet-drafts directory as:
draft-ietf-poised95-std-proc-3-06.txt
This new version changes the IPR rules quite a bit and the cited language
is no longer in the document.
Scott
Received: from relay.hq.tis.com by neptune.TIS.COM id aa18460;
1 Aug 96 23:32 EDT
Received: by relay.hq.tis.com; id WAA02155; Thu, 1 Aug 1996 22:09:39 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma002151; Thu, 1 Aug 96 22:09:11 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA27970; Thu, 1 Aug 96 22:08:43 EDT
Received: by relay.hq.tis.com; id WAA02148; Thu, 1 Aug 1996 22:09:09 -0400
Received: from newdev.harvard.edu(128.103.65.15) by relay.tis.com via smap (V3.1.1)
id xma002146; Thu, 1 Aug 96 22:09:02 -0400
Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA00355; Thu, 1 Aug 1996 22:11:26 -0400 (EDT)
Date: Thu, 1 Aug 1996 22:11:26 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199608020211.WAA00355@newdev.harvard.edu>
To: dpkemp@missi.ncsc.mil, sommerfeld@apollo.hp.com
Subject: Re: Key Management, anyone? (DNS keying)
Cc: ietf-tls@w3.org, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
oops - I did not read far enough in the note - if the proposal deals with
a classified algorithm then I agree with your reading
Scott
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24933; 2 Aug 96 8:36 EDT
Received: by relay.hq.tis.com; id IAA08306; Fri, 2 Aug 1996 08:39:26 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008290; Fri, 2 Aug 96 08:39:07 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11034; Fri, 2 Aug 96 08:38:38 EDT
Received: by relay.hq.tis.com; id IAA08283; Fri, 2 Aug 1996 08:38:56 -0400
Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma008272; Fri, 2 Aug 96 08:38:52 -0400
Received: by janus.border.com id <18505-1>; Fri, 2 Aug 1996 08:40:18 -0400
Message-Id: <96Aug2.084018edt.18505-1@janus.border.com>
X-Mailer: exmh version 1.6.2 7/18/95
To: ipsec@TIS.COM
Subject: Re: New ISAKMP+Oakley code!
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 2 Aug 1996 08:41:15 -0400
From: "Ozan S. Yigit" <oz@border.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> ... This software distribution is being made available
> free of charge for any commercial or non-commercial use to advance ISAKMP
> as a solution to Internet Key Management. --------------
-------------
i thought isakmp and skip proposals were to be merged into a single proposal.
i must have missed something between the ietf meetings and getting on the
mailing list...
oz
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28287;
2 Aug 96 11:32 EDT
Received: by relay.hq.tis.com; id LAA25165; Fri, 2 Aug 1996 11:35:04 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma024864; Fri, 2 Aug 96 11:34:39 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA18929; Fri, 2 Aug 96 11:34:07 EDT
Received: by relay.hq.tis.com; id LAA24801; Fri, 2 Aug 1996 11:34:33 -0400
Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1)
id xma024609; Fri, 2 Aug 96 11:34:15 -0400
Received: by pilotx.firewall.is.chrysler.com; id LAA21207; Fri, 2 Aug 1996 11:36:25 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma021203; Fri, 2 Aug 96 11:36:02 -0400
Received: from rgm3 by mhbclpr2-nf0.is.chrysler.com (8.7.5/SMI-4.1)
id LAA07124; Fri, 2 Aug 1996 11:29:05 -0400 (EDT)
Message-Id: <2.2.32.19960802153331.00d1c01c@pop3hub.is.chrysler.com>
X-Sender: t3125rm@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 02 Aug 1996 11:33:31 -0400
To: Derek Atkins <warlord@mit.edu>, dennis.glatting@plaintalk.bellevue.wa.us
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: DNSSEC for IPSEC?
Cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 03:08 PM 7/26/96 EDT, Derek Atkins wrote:
>> There is an issue. Storing the private key off-line is not
>> a deterrent: the mischievous person simply generates a
>> new key pair and re-signs the zone.
>
>Actually, this doesn't work. The problem is that the parent zone
>needs to have signed the zone's key. So, I couldn't go and forge
>a zone key for MIT.EDU, because the MIT.EDU key needs to be signed
>by the EDU key, which in turn needs to be signed by the root key.
>
>So, you can't forge a key without forging the whole hierarchy.
>
Gee it sounds like a job for an AlterNIC...
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28655;
2 Aug 96 11:48 EDT
Received: by relay.hq.tis.com; id LAA06117; Fri, 2 Aug 1996 11:51:35 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma005916; Fri, 2 Aug 96 11:51:14 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19655; Fri, 2 Aug 96 11:50:42 EDT
Received: by relay.hq.tis.com; id LAA05807; Fri, 2 Aug 1996 11:51:07 -0400
Received: from soscorp.soscorp.com(204.52.248.130) by relay.tis.com via smap (V3.1.1)
id xma005557; Fri, 2 Aug 96 11:50:46 -0400
Received: from fearless.soscorp.com (fearless.soscorp.com [204.52.249.130]) by brimstone.soscorp.com ($Revision: 2.30 $/8.6.12/8.6.4.287) with BSMTP id BS0003595/LAA03602; Fri, 2 Aug 1996 11:53:09 -0400
Received: from fearless.soscorp.com (aggelos@localhost) by fearless.soscorp.com (8.6.12/8.6.4.287) with ESMTP id LAA02557; Fri, 2 Aug 1996 11:52:44 -0400
Message-Id: <199608021552.LAA02557@fearless.soscorp.com>
To: dennis.glatting@plaintalk.bellevue.wa.us
Cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM
Subject: Re: DNSSEC for IPSEC? -- or, how to exploit DNSSEC
In-Reply-To: Your message of "Sat, 27 Jul 1996 12:49:58 PDT."
<199607271950.MAA00914@imo.plaintalk.bellevue.wa.us>
Date: Fri, 02 Aug 1996 11:52:42 -0400
From: "Angelos D. Keromytis" <aggelos@soscorp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Better late than never i guess.
In message <199607271950.MAA00914@imo.plaintalk.bellevue.wa.us>, Dennis Glattin
g writes:
>
>The DNSSEC extensions document little addresses the
>issue of key roll-over. Consequently, it is difficult to
>differentiate between an alarm be sounded as a result of a
>root server compromise and the attacker replacing its
>key pair and one sounded in response to legitimate key
>roll-over. The document mentions the issue of cross
>signatures but does not indicate their role. I have not
>found a document that addresses these issues.
>
I believe this is covered by mandating that any implementation should
be able to handle at least 2 valid KEY records for each name (intro of
section 3).
>The DNSSEC extensions document recommends a procedure
>for server private key management. That is all it is: a
>recommendation. Is that how the entities managing the
>root servers will manage them? Moreover, how are the root
>servers themselves secured? How will the weakest link,
>the people, be managed?
>
Lock em up and post a marine with an M16A2 outside the door ?
Seriously tho, the draft is concerned with the technological aspect of
security, not with the...social. No matter what key management one
has, people will always be a potential leak/weak link/whatever.
>Administrators tend to aggregate service classes to
>"ease administration". The same set of procedures and
>functions applied to one service are applied to all
>members of the aggregate. Therefore, it is highly
>probable that a technique used to penetrate one root
>server is a successful avenue to another. Consequently,
>it is possible to create a believable web of trust across
>compromised servers.
>
I fail to see what this has to do with DNSSEC. Clearly, if a host is
compromised, the assumptions on which IPSEC was built no longer hold.
Besides, I still don't know why breaking into a DNS server (maybe a
root ?) would somehow give you divine powers over the zone data; the
private key is supposed to be offline.
>When a parent zone changes its key, all its siblings will
>have to be updated (hmm, what is the number of zones under
>COM?). How will the administrators of those zones get the
>new key? How can they trust what they are getting? Suppose
>for a moment that a root server is compromised. Oh what
>chaos one can create.
Get the key through DNS, and this key is signed by the old key (if
this is a normal rollover) and by whoever signs the keys for that
root. Again, i assume that even the root keys are signed by one or
more other "trusted" authorities (maybe IETF, ISOC etc should
create a key just to sign root keys, which shouldn't happen all that
often).
>* A compromised server could redirect the address of the
> trusted key repository, resulting in a schizophrenic
> Internet.
The old key is still in effect, so the server can't fake data.
>* If bogus responses are believable, the cache of tens of
> thousands of servers will quickly be polluted. To clean
> them, those servers will have to be rebooted. The result
> is something close to rebooting the Internet.
See above.
>* The root server can reduce TTL values to their minimum,
> resulting in other servers often reloading the RRs
> and recomputing SIGs -- watch their CPU load jump!
That is true. However, also easily noticeable.
>* How about increasing key sizes too.
>Morris did nothing compared to the damage possible with
>DNSSEC.
>
Expand on this ?
>It is easy for a DNSSEC aware resolver to believe a
>response from a DNSSEC aware source; however, in a
>combined DNSSEC aware and unaware Internet, what is a
>resolver going to do when it gets a response from a DNSSEC
>unaware source? Ignore it? To do so would limit
>resolution breadth.
>
Indicate to the user that this might not be as secure a lookup as he
might think maybe. Let me ask something else in return.
In a mixed IPSEC-using and not Internet, what is someone who wants to
securely connect to some remote host that doesn't use IPSEC going to
do ?
>(Bear in mind that no body has the authority to impose
>DNSSEC across the Internet. Therefore, the issue of
>DNSSEC aware resolvers having to figure out what to do
>with responses from DNSSEC unaware sources will not go
>away.)
>
But it is not a totally impossible task either. There are a few
approaches that will accelerate deployment of DNSSEC.
>
>What kind of chaos can be created if the server's code is
>replaced? One thought is to always clear the AD bit in
>responses.
>
Expand on this ?
>
>Does DNSSEC add value to IPSEC? Maybe. I believe that for
>the next several years its value is limited.
>
There probably are alternatives, but they (probably) won't scale as
good, and will require some sort of new infrastructure.
-Angelos
Received: from relay.hq.tis.com by neptune.TIS.COM id aa04934;
2 Aug 96 18:24 EDT
Received: by relay.hq.tis.com; id SAA22853; Fri, 2 Aug 1996 18:26:46 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma022813; Fri, 2 Aug 96 18:26:07 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA05485; Fri, 2 Aug 96 18:25:29 EDT
Received: by relay.hq.tis.com; id SAA22795; Fri, 2 Aug 1996 18:25:53 -0400
Received: from unix.ka9q.ampr.org(129.46.90.35) by relay.tis.com via smap (V3.1.1)
id xma022779; Fri, 2 Aug 96 18:25:22 -0400
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id PAA04957; Fri, 2 Aug 1996 15:21:19 -0700 (PDT)
Date: Fri, 2 Aug 1996 15:21:19 -0700 (PDT)
Message-Id: <199608022221.PAA04957@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: naganand@ftp.com
Cc: adams@tgv.com, ipsec@TIS.COM
In-Reply-To: <2.2.32.19960801131747.009ac5f4@mailserv-H.ftp.com> (message from
Naganand Doraswamy on Thu, 01 Aug 1996 09:17:47 -0400)
Subject: Re: Question on TCP MSS with repsect to IPSEC
Reply-To: karn@qualcomm.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>Doesnt the ICMP message indicate the datagram size (IP Header + data) that
>it can send? This being the case, the router or tunnel end point may not
>take into account the overhead of IPSEC, correct?
Well, that's how Path MTU discovery works -- it relies on the MTU
fields in the ICMP messages that bounce back when a packet is too
large to fit and the don't-fragment bit is set. When an IPSEC gateway
generates such an ICMP message for a destination on the other end
of a tunnel, this field should indeed be adjusted to compensate for
the IPSEC overhead. That should cause the original sender to adjust
its MSS appropriately, just as it would if IPSEC weren't in use.
Phil
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28751;
4 Aug 96 22:00 EDT
Received: by relay.hq.tis.com; id CAA05001; Fri, 2 Aug 1996 02:37:06 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma004986; Fri, 2 Aug 96 02:36:38 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA02817; Fri, 2 Aug 96 02:36:10 EDT
Received: by relay.hq.tis.com; id CAA04982; Fri, 2 Aug 1996 02:36:36 -0400
Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1)
id xma004973; Fri, 2 Aug 96 02:36:25 -0400
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199608020638.PAA12221@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id PAA12221; Fri, 2 Aug 1996 15:38:16 +0900
Subject: Re: DNS? was Re: Key Management, anyone?
To: Hilarie Orman <ho@earth.hpc.org>
Date: Fri, 2 Aug 96 15:38:15 JST
Cc: PALAMBER@us.oracle.com, ipsec@TIS.COM
In-Reply-To: <199608010915.FAA21838@earth.hpc.org>; from "Hilarie Orman" at Aug 1, 96 5:15 am
X-Mailer: ELM [version 2.3 PL11]
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> I agree with the individual points, but I'm not convinced by the conclusion.
> Why isn't DNSSEC the appropriate minimal common basis for authentication?
Authentication for what?
> I believe we need such a basis,
Why? I think we don't need DNS-structured authentication chain
as a basis.
Masataka Ohta
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09084;
5 Aug 96 11:45 EDT
Received: by relay.hq.tis.com; id LAA23220; Mon, 5 Aug 1996 11:48:30 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma023196; Mon, 5 Aug 96 11:48:06 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA20376; Mon, 5 Aug 96 11:47:32 EDT
Received: by relay.hq.tis.com; id LAA23183; Mon, 5 Aug 1996 11:47:59 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xmaa23152; Mon, 5 Aug 96 11:47:31 -0400
Received: from localhost by ietf.org id aa01672; 5 Aug 96 11:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-udh-01.txt
Date: Mon, 05 Aug 1996 11:12:50 -0400
Message-Id: <9608051112.aa01672@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : Encoding of an Unsigned Diffie-Hellman Public Value
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-udh-01.txt
Pages : 6
Date : 08/02/1996
It is useful to be able to communicate public keys in the absence of a
certificate hierarchy and a signature infrastructure. This document
describes a method by which certificates which communicate Diffie-Hellman
public values and parameters may be encoded and securely named.
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-skip-udh-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805101155.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-udh-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805101155.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09396;
5 Aug 96 12:00 EDT
Received: by relay.hq.tis.com; id MAA23806; Mon, 5 Aug 1996 12:02:59 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma023793; Mon, 5 Aug 96 12:02:31 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA21161; Mon, 5 Aug 96 12:02:02 EDT
Received: by relay.hq.tis.com; id MAA23786; Mon, 5 Aug 1996 12:02:29 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma023780; Mon, 5 Aug 96 12:02:13 -0400
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id JAA07645; Mon, 5 Aug 1996 09:04:32 -0700
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id JAA05453; Mon, 5 Aug 1996 09:07:58 -0700
Message-Id: <199608051607.JAA05453@mailsun2.us.oracle.com>
Date: 05 Aug 96 08:52:03 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ho@earth.hpc.org
Subject: Re: DNS? was Re: Key Management, anyone?
Cc: ipsec@TIS.COM
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.hq.tis.com's message of 01-Aug-96 05:15
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.2.0.35)
Content-Type: multipart/mixed; boundary="=_ORCL_6295698_0_11919608051008590"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_6295698_0_11919608051008590
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
Hilarie,
>TCP requires IP, so the IETF guidelines cannot be
>taken too seriously in the regard to banning protocol dependencies!
Yes, they are only loose recommendations, and I believe (not having the exact
RFC in front of me) that the intent was to minimise the interaction between
major subsystems and not specific protocols.
>Why isn't DNSSEC the appropriate minimal common basis for authentication?
This seems to be a strong direction of recent mailing list discussion...
DNSSEC is one way to format and distribute certificates. It also implies a
specific trust model and naming based on DNS.
An IPsec specification should provide recommendations for the minimum required
certificate format for IPsec authentication.
For ISAKMP, I do not see why certificate distribution is required. Peer
systems can readily exchange all required certificates directly, so a
certificate distribution system like DNS may not be required.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Still hiring, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
--=_ORCL_6295698_0_11919608051008590
Content-Type:message/rfc822
Date: 01 Aug 96 05:15:04
From:"Hilarie Orman " <ipsec-approval@neptune.hq.tis.com>
To:PALAMBER@us.oracle.com
Subject:Re: DNS? was Re: Key Management, anyone?
Cc:ipsec@tis.com
X-Orcl-Application:In-Reply-To: Yourmessage <9607312301.AA16100@maildig1.us.oracle.com>
X-Orcl-Application:Sender: ipsec-approval@neptune.hq.tis.com
X-Orcl-Application:Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
I agree with the individual points, but I'm not convinced by the conclusion.
Why isn't DNSSEC the appropriate minimal common basis for authentication?
I believe we need such a basis, and DNSSEC seems to be the obvious choice.
This wouldn't rule out the optional use of other methods.
TCP requires IP, so the IETF guidelines cannot be taken too seriously in
the regard to banning protocol dependencies!
--=_ORCL_6295698_0_11919608051008590--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09943;
5 Aug 96 12:21 EDT
Received: by relay.hq.tis.com; id MAA24133; Mon, 5 Aug 1996 12:23:59 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma024128; Mon, 5 Aug 96 12:23:32 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA21951; Mon, 5 Aug 96 12:23:03 EDT
Received: by relay.hq.tis.com; id MAA24118; Mon, 5 Aug 1996 12:23:30 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xma024110; Mon, 5 Aug 96 12:23:14 -0400
Received: from localhost by ietf.org id aa03714; 5 Aug 96 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-udh-01.txt
Date: Mon, 05 Aug 1996 11:49:28 -0400
Message-Id: <9608051149.aa03714@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : Encoding of an Unsigned Diffie-Hellman Public Value
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-udh-01.txt
Pages : 6
Date : 08/02/1996
It is useful to be able to communicate public keys in the absence of a
certificate hierarchy and a signature infrastructure. This document
describes a method by which certificates which communicate Diffie-Hellman
public values and parameters may be encoded and securely named.
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-skip-udh-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960802103034.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-udh-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-udh-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960802103034.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa17746;
5 Aug 96 19:37 EDT
Received: by relay.hq.tis.com; id TAA05226; Mon, 5 Aug 1996 19:40:17 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma005222; Mon, 5 Aug 96 19:39:48 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA00863; Mon, 5 Aug 96 19:39:19 EDT
Received: by relay.hq.tis.com; id TAA05217; Mon, 5 Aug 1996 19:39:47 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma005213; Mon, 5 Aug 96 19:39:33 -0400
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id QAA20547; Mon, 5 Aug 1996 16:41:57 -0700
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id QAA16081; Mon, 5 Aug 1996 16:45:32 -0700
Message-Id: <199608052345.QAA16081@mailsun2.us.oracle.com>
Date: 05 Aug 96 16:34:53 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: IPsec Minutes from Montreal
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.2.0.35)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The minutes of the last IPsec Working Group were posted to the IETF weeks ago
and have yet to appear in the official archive. For those of you that missed
attending the meeting in Montreal the minutes are attached below.
Regards,
Paul
--------------------------------------------------------------
IPSEC WG Meeting Notes, Montreal IETF, June 1996
The co-chairs would like to thank Steve Kent for contributing his
personal notes on the meeting, which were used as the basis for these minutes.
The co-chairs edited the notes somewhat, so any errors are their
responsibility.
SESSION 1, Tuesday: AH/ESP and existing IPsec documents
Jim Hughes presented his Combined ESP transform with HMAC and
anti-replay. Steve Kent suggested changing the proposal to rely on a
negotiated anti-replay window size, to accept all packets within the window
unless they are replays, and to not try to reduce the overhead by relying on a
constructed IV. All three suggestions were adopted. Note that this protocol
requires distinct simplex channel keys, derived from a master key for the SA.
RSA reported on their S/WAN interoperability testing: TIS, NSA,
Raptor, SCC, and others worked well together. The next test session will
require Oakley/ISAKMP, and optionally SKIP, for key management, in support of
AH and ESP.
John Gilmore argued for widespread, near term deployment to protect
against passive wiretapping. His goal is 5% of Internet traffic by the end of
1996. His personal agenda is to counter government (not just US Government)
efforts for key-escrow initiatives. His proposal is to put crypto-walls in
place (devices that don't even do packet filtering and don't rely on
authenticated keys). His tactic is to leverage freely available software in
order to build such crypto-walls, define new DNS records for unauthenticated
key storage, avoid export controls by developing software outside of the US.
A firewall vendor gave a talk on using IPSEC with firewalls, as a
followup to mobile IP problem of getting mobile IP traffic out of a foreign
domain. Asssume a model where presence of valid AH is required for firewall
traversal, in either direction. The initially presented model looks at
traversing a single firewall, nominally at the home agent permieter. The
second model presented shows foreign and home firewalls. The talk points out
the need for multiple, layered SAs, from MN-to-firewall-1, then maybe between
firewalls, then from HA to firewall-2, and eventually one SA above these to
carry forwarded traffic from HA to MN. Speaker notes the problems of being
able to transmit the mobile IP messages, ICMP messages, and key management
messages through firewalls as a precursor to establishing SAs in this complex
environment. The bottom line is that one has to look carefully at the rules
that firewalls employ to determine what traffic will be allowed across, as
this might cause serious problems for SA establishment, especially for mobile
IP case. However, the proposed solution is pretty complex and there are
easier approaches to dealing with this problem in the mobile IP case, e.g.,
co-locating FAs and HAs with firewalls, or establishing long term SAs, between
HAs and FAs and their local firewalls, to facilitate forwarding of mobile IP
traffic.
Ran Atkinson spoke about the standards process and it's applicability
to the IPSEC RFCs. Because some of the 1825-29 RFCs are being replaced, and
because all of them cross reference one another, the group cannot be advanced
from Proposed Standard to Draft Standard until 6 months elapses after the last
of the inter-related documents have been updated. Ran also discussed his
revised IPSEC Security Architecture document, a replacement for RFC-1825.
Steve Kent suggested that the WG revisit AH to remove its two-different modes
of use, given the new ESP options that incorporate autehntication and thus
obviate the need for the embedded AH mode (ESP followed directly by AH).
Steve also suggested that the WG revise ESP to add in optional, variable
length fields for IVs, integrity checks, etc. so that the transform documents
are independent of one another and don't grow geometrically as new algorithms
are added. The WG adopted both suggestions and Steve Kent agreed to work with
the WG co-chairs to provide suitable text for the revised RFCs.
Session 2, Wednesday: Key Management Issues
Bob Moskowitz (Chrysler) challenged the group to solve a network layer
security problem for communication among automotive parts suppliers and
manufacturers, but with a lot of nasty residual problems, e.g., misuse of net
numbers by particiants, diverse set of existing firewalls, etc. Bob's goal is
to start deploying IPsec by the end of 1996.
Ashar Aziz presented SKIP. Note the use of the SKIP header
between IP header and AH or ESP. Two modes of use: the first mode has no
setup messages once the master keys are in place, no Perfect Forward Secrecy,
and has significant per-message overhead. This mode relies on pre-positioned
D-H master keys from which unicast keys are derived. The second mode uses
ephemeral Diffie-Hellman, with certificates, in a 4-6 message exchange, with
approximate PFS, anonymity, etc. Claimed multicast mode support is based on a
group co-ordinator creating a group key (distribution of the private key to
group members is not described here and is potentially hard to implement or
scale) which the sender uses as the target for Diffie-Hellman computation.
Checkpoint, Toshiba, ETH, Sun have interoperable implementations of SKIP,
based on recent testing. Some gaps in the SKIP-06 spec were uncovered, and
are being fixed in the next draft. Ashar pushed for adoption of the
certificate discovery protocol (CDP) independent of SKIP. Also can move CRLs
as well as certificates, not just X.509 certificates, but PGP too.
Doug Maughan reported on ISAKMP. Free software is available via MIT
server at http://web.mit.edu/network/isakmp. cisco has also worked on an
ISAKMP with Oakley implementation, also freely available from cisco and MIT
web sites. There is also an implementation by the UK Defence Research Agency.
ISAKMP provides very general KMP framework, capable of supporting various key
exchange algorithms, authentication, security association management, and
denial of service protection. Recent I-D changes: moved from request/response
to chained payload format (for better performance and/or more flexible for
multi-exchange protocols), can negotiate multiple SPIs at the same time (for
greater efficiency and flexibility), and an expanded set of authentication
payload types (for better support of more exchnage types). Format is more
complex now, because of support of multiple paylodas per message, negotiating
multiple protocols at one time, etc. See version 5 specification I-D for
details. Jon Millen's analysis notes that cookies don't buy much
Denial-of-Service protection, and that authentication and key exchange is
sufficiently decoupled to require further analysis. Interoperability testing,
using Oakley, is now going on between cisco and DRA. Work will continue to
add other key exchange algorithms, commercial and government.
Hilarie Orman described Oakley briefly. Oakley is quite flexible: can
use Diffie-Hellman exchange and/or pre-positioned keys or Public Key (RSA)
encryption ; authentication via RSA encryption, signatures or predistributed
shared secrets; integrity is available but can be omitted, and Perfect Forward
Secrecy is available but can be omitted. Minimal message exchange is 3
messages, though more round-trips can also occur. She has also published the
group paramaters for several bases, yielding 90-bit strength key outputs.
ISAKMP integration is almost complete. She suggested having the ESP and AH
transforms define how the necessary key bits are extracted from the output of
the Oakley computation. Basically, a general collection of modules that can
meet lots of different requirements, using a consistent syntax.
Dan Harkins reported on the status of the ISAKMP-Oakley integration
effort. A new Internet-Draft is out with a coherent profile of ISAKMP and
Oakley when used together. The first two ISAKMP messages establish an SA,
then the parties negotiate SAs for their clients. Four modes of Oakley are
specified: Main Mode (for ISAKMP phase 1 exchange, four messages); Agressive
Mode (quick, but no identity protection, an alternate phase 1 exchange in 3
messages); Quick Mode ( a phase 2 exchange, in 3 messages, but can be repeated
multiple times after a phase 1 exchange); Group Mode (for changing from one
group to another, over time). cisco's free ISAKMP+Oakley code will be
implementing this specification.
Hugo made some comments on Oakley/ISAKMP. He likes the overall
framework, but sees a need to refine the specs to remove some ambiguity and
facilitate interoperability. From a cryptographic standpoint he has some
suggestions, but lacked time to go into details. From a capability
perspective, he would like to see a support for pre-positioned or
centrally-distributed symetric keys, with PFS, which Oakley does allow. cisco
has indicated that they would accommodate that request. Hugo doesn't like the
reliance on Diffie-Hellman in the new Oakley/ISAKMP profile, relative to the
broader capabilities of Oakley. Finally, Hugo expressed some concerns about
the differences in types of attacks one might mount in the public key
vs. symmetric key arena. The bottom line is that the ISAKMP and Oakley
protocols accommodate all of these suggestions, it's just an issue of of
getting the cisco implementation to incorporate these features.
Very brief, surprizing comments from John Gilmore, announcing that he
has purchased all of Bill Simpson's rights, including copyright, for Photuris,
to ensure that it is considered as a viable contender in the key management
protocol sweepstakes. However, he has not obtained any rights to Photuris
from Phil Karn. Further, there is no new draft available addressing the
previously discussed deficiencies of Photuris. There was no evidence of
broad support for Photuris at this meeting.
There was a short talk on Eliptical Curve Cryptography (ECC)
technology, for both Diffie-Hellman exchanges and DSA- & RSA-equivalent
(signature with recovery, but not excatly RSA) signautues. A major benefit is
that shorter key lengths are security equivalent to larger key lengths. The
IEEE P1363 specifications were mentioned and there was some discussion of
patents relative to the use of ECC. There are some ECC-related patents, in
addition to the general public key patent, but they relate mostly to
implementations not to the basic math. The speaker is from Certicom, which
holds some of these implementation patents.
Closing discussions were process oriented, i.e., how will the WG
decide what will become the default key management standard for IPSEC ? Jeff
Schiller conducted straw polls which showed significant differences of opinion
between Oakley/ISAKMP and SKIP, although everyone wants a quick resolution to
the issue! Jeff suggests having a special committee come back with a
justifiable resolution.
--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23005; 6 Aug 96 2:51 EDT
Received: by relay.hq.tis.com; id CAA08072; Tue, 6 Aug 1996 02:54:17 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008070; Tue, 6 Aug 96 02:53:49 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA06185; Tue, 6 Aug 96 02:53:19 EDT
Received: by relay.hq.tis.com; id CAA08065; Tue, 6 Aug 1996 02:53:48 -0400
Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1)
id xma008060; Tue, 6 Aug 96 02:53:22 -0400
Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id XAA10933; Mon, 5 Aug 1996 23:55:26 -0700 (PDT)
Message-Id: <199608060655.XAA10933@toad.com>
X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
Cc: ipsec@TIS.COM, gnu@toad.com
Subject: Re: IPsec Minutes from Montreal
In-Reply-To: <199608052345.QAA16081@mailsun2.us.oracle.com>
Date: Mon, 05 Aug 1996 23:55:26 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Some minutes additions from my own notes:
Details on my presentation on rapid deployment of IPSEC in the first
meeting are available at http://www.cygnus.com/~gnu/swan.html.
Jeff Schiller's closing discussions in the second meeting included
these "straw poll" questions, with my rough estimations of the
audience reaction. He said he deliberately structured the questions
to avoid a straw-poll on particular algorithms, but instead focused on
our goals or process.
Should we let the marketplace decide on a key managment standard,
or should we pick one and move forward?
Marketplace - 2/5
Pick one - 3/5
Should we favor generality, or simplicity?
Generality - 2/5
Simplicity - 3/5
Do we have to have a plan by the next IETF?
On this we have consensus -- YES.
Should Jeff grab a few of the WG people who are known not to be committed
to any proposal, and together decide?
Strong consensus that this was not the way to go.
This was when he suggested convening a small group, largely composed of
the authors/proponents of existing proposals, to try to hammer out a
compromise proposal. He also said that if this group didn't come up with
anything by September, Jeff would personally choose one as the standard,
though he did not want to be forced to do that.
John
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28811; 6 Aug 96 9:50 EDT
Received: by relay.hq.tis.com; id JAA12444; Tue, 6 Aug 1996 09:53:18 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012438; Tue, 6 Aug 96 09:52:50 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15998; Tue, 6 Aug 96 09:52:19 EDT
Received: by relay.hq.tis.com; id JAA12432; Tue, 6 Aug 1996 09:52:48 -0400
Received: from ns.newbridge.com(192.75.23.67) by relay.tis.com via smap (V3.1.1)
id xma012426; Tue, 6 Aug 96 09:52:20 -0400
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA10154; Tue, 6 Aug 1996 09:54:09 -0400
Received: from portero(192.75.23.66) by ns via smap (V1.3)
id sma010062; Tue Aug 6 09:53:36 1996
Received: from tsntsrv1.timestep.com (tsntsrv1.timestep.com [192.168.219.190]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id JAA22084; Tue, 6 Aug 1996 09:53:35 -0400
Received: from Microsoft Mail (PU Serial #1121)
by tsntsrv1.timestep.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm))
id AA-1996Aug06.094718.1121.40243; Tue, 06 Aug 1996 09:52:55 -0400
From: Roy Pereira <rpereira@timestep.com>
To: "Brian W. McKenney" <mckenney@smiley.mitre.org>,
"'IPSEC@TIS.COM'" <IPSEC@TIS.COM>
Message-Id: <1996Aug06.094718.1121.40243@tsntsrv1.timestep.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Organization: TimeStep Corporation
Date: Tue, 06 Aug 1996 09:52:55 -0400
Subject: RE: ESP RC5-CBC Transform
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>The recent S/WAN interoperability tests were focused on DES-CBC for ESP.
>Will future tests include RC5-CBC for ESP? I am interested in
>vendor/product support for this transform.
>The future standard that is being pushed for ESP is the Combined ESP
>transform (identified in latest IETF-DRAFT), although other algorithms
and
>modes may also be implemented.
TimeStep Corp will include the RC5-CBC ESP transform in its next
generation PermitPC products.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29171;
6 Aug 96 10:05 EDT
Received: by relay.hq.tis.com; id KAA12770; Tue, 6 Aug 1996 10:07:49 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012760; Tue, 6 Aug 96 10:07:24 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16871; Tue, 6 Aug 96 10:06:50 EDT
Received: by relay.hq.tis.com; id KAA12746; Tue, 6 Aug 1996 10:07:18 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xmab12731; Tue, 6 Aug 96 10:07:05 -0400
Received: from localhost by ietf.org id aa04416; 6 Aug 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-mc-01.txt
Date: Tue, 06 Aug 1996 09:18:59 -0400
Message-Id: <9608060919.aa04416@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : SKIP Extensions for IP Multicast
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-mc-01.txt
Pages : 20
Date : 08/05/1996
This document describes extensions to the base SKIP [1] protocol to allow
encrypted/authenticated multicast communications.
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-skip-mc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-mc-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-mc-01.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805161131.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-mc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-mc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805161131.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29169;
6 Aug 96 10:05 EDT
Received: by relay.hq.tis.com; id KAA12772; Tue, 6 Aug 1996 10:07:48 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012761; Tue, 6 Aug 96 10:07:26 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16872; Tue, 6 Aug 96 10:06:52 EDT
Received: by relay.hq.tis.com; id KAA12743; Tue, 6 Aug 1996 10:07:18 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xma012731; Tue, 6 Aug 96 10:07:05 -0400
Received: from localhost by ietf.org id aa04384; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-x509-01.txt
Date: Tue, 06 Aug 1996 09:18:55 -0400
Message-Id: <9608060918.aa04384@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : X.509 Encoding of Diffie-Hellman Public Values
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-x509-01.txt
Pages : 6
Date : 08/05/1996
This document describes the ASN.1 [1] encoding of the CCITT 1988 X.509 [2]
certificate with Diffie-Hellman public values for use with SKIP [5].
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-skip-x509-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-x509-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-x509-01.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805155442.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-x509-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-x509-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805155442.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29170;
6 Aug 96 10:05 EDT
Received: by relay.hq.tis.com; id KAA12773; Tue, 6 Aug 1996 10:07:48 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012762; Tue, 6 Aug 96 10:07:27 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16873; Tue, 6 Aug 96 10:06:52 EDT
Received: by relay.hq.tis.com; id KAA12748; Tue, 6 Aug 1996 10:07:19 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xmac12731; Tue, 6 Aug 96 10:07:06 -0400
Received: from localhost by ietf.org id aa04432; 6 Aug 96 9:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-pfs-01.txt
Date: Tue, 06 Aug 1996 09:19:01 -0400
Message-Id: <9608060919.aa04432@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : SKIP extension for Perfect Forward Secrecy (PFS)
Author(s) : A. Aziz
Filename : draft-ietf-ipsec-skip-pfs-01.txt
Pages : 11
Date : 08/05/1996
This document describes an optional extension specifying how to use an
ephemeral Diffie-Hellman exchange in conjunction with the SKIP protocol in
order to provide perfect forward secrecy for situations where forward
secrecy is necessary.
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-skip-pfs-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-pfs-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-01.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805161609.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-pfs-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-pfs-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805161609.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29172;
6 Aug 96 10:05 EDT
Received: by relay.hq.tis.com; id KAA12771; Tue, 6 Aug 1996 10:07:48 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012759; Tue, 6 Aug 96 10:07:23 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16870; Tue, 6 Aug 96 10:06:50 EDT
Received: by relay.hq.tis.com; id KAA12745; Tue, 6 Aug 1996 10:07:18 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xmaa12731; Tue, 6 Aug 96 10:07:05 -0400
Received: from localhost by ietf.org id aa04400; 6 Aug 96 9:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-adp-01.txt
Date: Tue, 06 Aug 1996 09:18:57 -0400
Message-Id: <9608060918.aa04400@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : SKIP Algorithm Discovery Protocol
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-adp-01.txt
Pages : 7
Date : 08/05/1996
SKIP [1] provides privacy and authentication with Internet Protocols.
It does not define a method by which two entities may mutually agree on
encryption, authentication and compression algorithms. We describe a
protocol which will allow one SKIP entity to inform another entity of
the capabilities it supports.
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-skip-adp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-adp-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-adp-01.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960805160054.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-adp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-adp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960805160054.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29311;
7 Aug 96 13:40 EDT
Received: by relay.hq.tis.com; id NAA18374; Wed, 7 Aug 1996 13:43:22 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma018372; Wed, 7 Aug 96 13:42:54 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA23587; Wed, 7 Aug 96 13:42:22 EDT
Received: by relay.hq.tis.com; id NAA18367; Wed, 7 Aug 1996 13:42:52 -0400
Received: from dg-webo.us.dg.com(128.221.131.1) by relay.tis.com via smap (V3.1.1)
id xma018362; Wed, 7 Aug 96 13:42:44 -0400
Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1)
id AA23471; Wed, 7 Aug 1996 13:44:35 -0400
Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08)
id AA20413; Wed, 7 Aug 1996 13:44:34 -0400
Message-Id: <9608071744.AA20413@wellspring.us.dg.com>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 07 Aug 1996 13:44:11 -0400
To: ipsec@TIS.COM
From: Rodney Thayer <rodney@sabletech.com>
Subject: I-D ACTION:draft-thayer-seccomp-00.txt
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I would like to find out if anyone else has thought about what format would
be needed to represent compressed data within an IPSEC datastream. I've
written up something (see attached) per suggestions I received at the
Montreal IETF.
>To: IETF-Announce:;
>Sender: ietf-announce-request@ietf.org
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-thayer-seccomp-00.txt
>Date: Mon, 22 Jul 1996 10:04:32 -0400
>X-Orig-Sender: cclark@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : Compression Payload for Use with IP Security
> Author(s) : R. Thayer
> Filename : draft-thayer-seccomp-00.txt
> Pages : 4
> Date : 07/17/1996
>
>This document describes a payload format to be used to store compressed
>protocol messages within an IP packet which is using security features as
>defined in [RFC-1825].
>
>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-thayer-seccomp-00.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-thayer-seccomp-00.txt
>
>Internet-Drafts directories are located at:
>
> o Africa
> Address: ftp.is.co.za (196.4.160.8)
>
> o Europe
> Address: nic.nordu.net (192.36.148.17)
> Address: ftp.nis.garr.it (193.205.245.10)
>
> o Pacific Rim
> Address: munnari.oz.au (128.250.1.21)
>
> o US East Coast
> Address: ds.internic.net (198.49.45.10)
>
> o US West Coast
> Address: ftp.isi.edu (128.9.0.32)
>
>Internet-Drafts are also available by mail.
>
>Send a message to: mailserv@ds.internic.net. In the body type:
> "FILE /internet-drafts/draft-thayer-seccomp-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.
>
>For questions, please mail to Internet-Drafts@ietf.org
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version
>of the Internet-Draft.
>Content-Type: text/plain
>Content-ID: <19960717141737.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-thayer-seccomp-00.txt
>Content-Type: text/plain
>Content-ID: <19960717141737.I-D@ietf.org>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
Received: from relay.hq.tis.com by neptune.TIS.COM id aa01197;
7 Aug 96 14:57 EDT
Received: by relay.hq.tis.com; id OAA20821; Wed, 7 Aug 1996 14:59:52 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma020812; Wed, 7 Aug 96 14:59:24 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA27813; Wed, 7 Aug 96 14:58:52 EDT
Received: by relay.hq.tis.com; id OAA20807; Wed, 7 Aug 1996 14:59:22 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xma020791; Wed, 7 Aug 96 14:59:08 -0400
Received: from localhost by ietf.org id aa19436; 7 Aug 96 14:58 EDT
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: HMAC-IP Authentication with Replay Prevention to
Proposed Standard
Reply-To: iesg@ietf.org
Date: Wed, 07 Aug 1996 14:58:16 -0400
Message-Id: <9608071458.aa19436@ietf.org>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The IESG has received a request from the IP Security Protocol Working
Group to consider the following Internet-Drafts for Proposed Standard:
1. HMAC-MD5 IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-md5-01.txt>
2. HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-01.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa11398;
7 Aug 96 22:56 EDT
Received: by relay.hq.tis.com; id WAA01430; Wed, 7 Aug 1996 22:59:44 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma001428; Wed, 7 Aug 96 22:59:25 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14077; Wed, 7 Aug 96 22:58:44 EDT
Received: by relay.hq.tis.com; id WAA01422; Wed, 7 Aug 1996 22:59:14 -0400
Received: from copernicus.hpc.org(192.187.8.4) by relay.tis.com via smap (V3.1.1)
id xma001419; Wed, 7 Aug 96 22:59:09 -0400
Received: from earth.hpc.org (earth.hpc.org [192.187.8.34]) by hpc.org (8.7.1/8.7.1) with SMTP id XAA15627; Wed, 7 Aug 1996 23:04:33 -0400 (EDT)
Received: by earth.hpc.org (SMI-8.6/SMI-SVR4)
id XAA02552; Wed, 7 Aug 1996 23:03:02 -0400
Date: Wed, 7 Aug 1996 23:03:02 -0400
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199608080303.XAA02552@earth.hpc.org>
To: mohta@necom830.hpcl.titech.ac.jp
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
In-Reply-To: Yourmessage <199608050227.TAA06242@baskerville.CS.Arizona.EDU>
Subject: Re: "Re: DNS? was Re: Key Management, anyone?"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Authentication for what?
Clarified Assertion:
The minimal basis for authentication is the association of a public key
with an IP address. The minimal authentication chain is through DNS
zone authorities.
This seems to me to be generally useful and meaningful mechanism for most
Internet purposes. If a site doesn't have an appropriate key entry, it
won't be able participate in ordinary authenticated services --- sort of like
not having a valid IP address would invalidate it as an Internet member.
So, why is this wrong?
Received: from relay.hq.tis.com by neptune.TIS.COM id aa11701;
7 Aug 96 23:20 EDT
Received: by relay.hq.tis.com; id XAA01674; Wed, 7 Aug 1996 23:22:44 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma001669; Wed, 7 Aug 96 23:22:16 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14575; Wed, 7 Aug 96 23:21:45 EDT
Received: by relay.hq.tis.com; id XAA01663; Wed, 7 Aug 1996 23:22:14 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma001658; Wed, 7 Aug 96 23:21:49 -0400
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id UAA00041; Wed, 7 Aug 1996 20:24:11 -0700
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id UAA29223; Wed, 7 Aug 1996 20:27:47 -0700
Message-Id: <199608080327.UAA29223@mailsun2.us.oracle.com>
Date: 07 Aug 96 19:52:51 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: mcr@milkyway.com
Subject: Re: IPsec Minutes from Montreal
Cc: ipsec@TIS.COM
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:mcr@milkyway.com's message of 06-Aug-96 10:30
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.2.0.35)
Content-Type: multipart/mixed; boundary="=_ORCL_6371449_0_11919608072128460"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_6371449_0_11919608072128460
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
>(I think everyone will agree that we have endless
>debates about what layering is allowed!)
It seems like any layering should be allowed. A harder question is
determining if there should be a mandate for minimum support of layering
required in a conformant IPsec implementation. For now it seems premature to
mandate support for specific layering configuration, but it would be useful to
document some common useful configurations.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Hiring, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
--=_ORCL_6371449_0_11919608072128460
Content-Type:message/rfc822
Date: 06 Aug 96 10:30:16
From:"Michael Richardson " <mcr@milkyway.com>
To:PALAMBER@us.oracle.com
Subject:Re: IPsec Minutes from Montreal
X-Mailer: exmh version 1.6.7 5/3/96
X-Orcl-Application:Pgp-Action: none; rfc822=off
X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4
X-Face: =)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F
X-Face: ~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf
X-Face: |;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5
X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html
X-Orcl-Application:References: <199608052345.QAA16081@mailsun2.us.oracle.com>
X-Orcl-Application:In-Reply-To: Your message of "05 Aug 1996 16:34:53 PDT."
X-Orcl-Application:In-Reply-To: <199608052345.QAA16081@mailsun2.us.oracle.com>
X-Orcl-Application:Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
In a galaxy far, far away, : 05 Aug 1996 16:34:53 PDT
> A firewall vendor gave a talk on using IPSEC with firewalls, as a
> followup to mobile IP problem of getting mobile IP traffic out of a foreign
> domain. Asssume a model where presence of valid AH is required for firewall
> traversal, in either direction. The initially presented model looks at
> traversing a single firewall, nominally at the home agent permieter. The
> second model presented shows foreign and home firewalls. The talk points out
>-
> the need for multiple, layered SAs, from MN-to-firewall-1, then maybe between
>-
> firewalls, then from HA to firewall-2, and eventually one SA above these to
> carry forwarded traffic from HA to MN. Speaker notes the problems of being
> able to transmit the mobile IP messages, ICMP messages, and key management
> messages through firewalls as a precursor to establishing SAs in this complex
>-
> environment. The bottom line is that one has to look carefully at the rules
> that firewalls employ to determine what traffic will be allowed across, as
Up to this point, I agree with the minutes.
> this might cause serious problems for SA establishment, especially for mobile
>-
> IP case. However, the proposed solution is pretty complex and there are
My perspective is that mobile IP is simply the tip of the iceberg. A good
part of the IPsec architecture makes space for security gateways and the like.
(I think everyone will agree that we have endless debates about what layering
is allowed!)
> easier approaches to dealing with this problem in the mobile IP case, e.g.,
> co-locating FAs and HAs with firewalls, or establishing long term SAs, betwee
>-n
> HAs and FAs and their local firewalls, to facilitate forwarding of mobile IP
> traffic.
This doesn't solve the general problem. Does this general problem really
exist? Yes: I should point out that Bob Moskowitz's problem is very highly
related. (This might not be clear to some, but remember that I build
application layer firewalls. I fear to be too partisan if I were to describe
how I'd use IPsec+application layer firewalls to solve his problems. Besides,
I haven't seen his requirements document yet... Bob?)
--
mcr@milkyway.com | <A HREF="http://www.milkyway.com/">Milkyway
Networks Corporation</A>
Michael C. Richardson | Makers of the Black Hole firewall
Senior Research Specialist | info@milkyway.com for BlackHole questions
Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio
.html">mcr@sandelman.ocunix.on.ca</A>.
"In a razor of Love." "Voodoo People! Magic People! Voodoo People! Magic
People!"
--=_ORCL_6371449_0_11919608072128460--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13024; 8 Aug 96 1:06 EDT
Received: by relay.hq.tis.com; id BAA02410; Thu, 8 Aug 1996 01:09:14 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma002408; Thu, 8 Aug 96 01:08:46 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16477; Thu, 8 Aug 96 01:08:14 EDT
Received: by relay.hq.tis.com; id BAA02405; Thu, 8 Aug 1996 01:08:44 -0400
Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1)
id xma002403; Thu, 8 Aug 96 01:08:40 -0400
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199608080510.OAA10224@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id OAA10224; Thu, 8 Aug 1996 14:10:35 +0900
Subject: Re: "Re: DNS? was Re: Key Management, anyone?"
To: Hilarie Orman <ho@earth.hpc.org>
Date: Thu, 8 Aug 96 14:10:34 JST
Cc: mohta@necom830.hpcl.titech.ac.jp, ipsec@TIS.COM
In-Reply-To: <199608080303.XAA02552@earth.hpc.org>; from "Hilarie Orman" at Aug 7, 96 11:03 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > Authentication for what?
>
> Clarified Assertion:
> The minimal basis for authentication is the association of a public key
> with an IP address.
Agreed, though the association of a public key with a hostname would
be a little more useful.
But, note that any string, for example, URLs, containing a hostname,
signature, date etc. can authenticate a hostname.
> The minimal authentication chain is through DNS
> zone authorities.
I disagree here.
The source, root, of the authentication varies application by
application.
DNS zone delegation chain is the natural chain for Internic to
^^^^^^^^^^^^
authenticate DNS data structure itself, but nothing more than
that.
Secure DNS chain is NOT useful to track to an authentication root.
To track to the proper root, we need application specific signatures.
For example, it is possible to modify SIG RRs and KEY RRs of secure
DNS to have some field designating the authentication root.
Then, using multiple SIG and KEY RRs for each root, we can track the
appropriate chain to reach the desired root of the authentication.
This, I think, could be the minimal authentication chain with DNS.
But, now, we are not so much motivated to let the authentication
chain follow the DNS structure. Authetication chain can just be a
relationship between DNS nodes. Note that traversing DNS structure
with NS, glue A and CNAME cause a lot of wierd problems unrelated
to the authentication chain itself.
Finally, the problem of using DNS for such generic authentication
is that, we need separate SIG RR and KEY RR for each root, which
can easily cause DNS UDP packet overflow.
So, I'm rather discouraged to use DNS for authentication other than
securing DNS structure itself.
Masataka Ohta
Received: from relay.hq.tis.com by neptune.TIS.COM id aa22288;
8 Aug 96 10:19 EDT
Received: by relay.hq.tis.com; id KAA10336; Thu, 8 Aug 1996 10:22:26 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma010328; Thu, 8 Aug 96 10:22:00 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01441; Thu, 8 Aug 96 10:21:28 EDT
Received: by relay.hq.tis.com; id KAA10321; Thu, 8 Aug 1996 10:21:57 -0400
Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1)
id xma010314; Thu, 8 Aug 96 10:21:52 -0400
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA26053; Thu, 8 Aug 1996 10:28:43 -0400 (EDT)
X-Sender: kent@po1.bbn.com
Message-Id: <v02130506ae2fa443cfc6@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 8 Aug 1996 10:24:53 -0400
To: Hilarie Orman <ho@earth.hpc.org>
From: Stephen Kent <kent@bbn.com>
Subject: Re: "Re: DNS? was Re: Key Management, anyone?"
Cc: mohta@necom830.hpcl.titech.ac.jp, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hilarie,
I think there have been two threads of authentication discussion,
both of which have merit. As Steve Bellovin pointed out, if one starts
with a DNS name, then one wants the binding between the name and the
corresponding IP address to be authenticated, or you are in trouble.
However, although most of the security association (SA) establishment
procedures take that path, some might proceed directly from an address.
Hence, an authenticated binding between an IP address and a public key also
is necessary, and sometime sufficient.
Th DNS security mechanism facilities provide a necessary service
whenever one starts with a DNS name as an input to SA creation, especially
if one is not sure about the existance of key material for the target, or
the target's existance. If you know that the target exists, and has key
material, then one could do without the DNS security facilities and merely
fetch a certificate from the DNS (or elsewhere). That certificate could
embody the address/key binding, and it might also include the DNS name.
(X.509 v3 certificates allow for multiple alternative name forms in a
single certificate, so it is feasible to include multiple bindings, so long
as one can establish a certification system that is consistent with the
multiple bindings.) So, I also agree with the observations made by David
Kemp, that the DNS security approach to providing key and signature records
is not the only game in town. Some subscribers may find that they require
some of the features that come from using certificates (vs. the signature
and key records of DNSSEC).
The two schemes are not necessarily in conflcit; they offer
somewhat different sets of services. One might even go with a hybrid scheme
where DNSSEC was used to authenticate existing records for hosts, but
certificates were stored for the hosts themselves. This would reduce the
extent to which DNS signature and key records would be introduced, since
they would be required only to represent the domains (not the hosts), while
certificates could be used for the hosts. (Just a quick thought, noithing
that I've worked on in depth.)
Steve
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23052;
8 Aug 96 10:47 EDT
Received: by relay.hq.tis.com; id KAA11342; Thu, 8 Aug 1996 10:50:27 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011314; Thu, 8 Aug 96 10:50:00 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA03377; Thu, 8 Aug 96 10:49:27 EDT
Received: by relay.hq.tis.com; id KAA11302; Thu, 8 Aug 1996 10:49:57 -0400
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1)
id xma011295; Thu, 8 Aug 96 10:49:55 -0400
Received: from ftp.com by ftp.com ; Thu, 8 Aug 1996 10:52:18 -0400
Received: from athena.ftp.com by ftp.com ; Thu, 8 Aug 1996 10:52:18 -0400
Message-Id: <2.2.32.19960808145715.00b4d320@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Aug 1996 10:57:15 -0400
To: ipsec@TIS.COM
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Comments on ISAKMP/Oakley
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
These are mostly implemetation type comments:
2.4.1. Security Association Payload
Is the "Payload Length" field *really* supposed to be specified in
four-octet units, or should it be in octets as all the other payloads
are?
A.6.1. Attribute Value Assigned Numbers, IPSEC ESP
TLV constructs: how long is "Type"? How long is "Length"? Is "Length"
in terms of octets, or some other unit? Are the lengths of "Type" and
"Length" included in "Length" or not?
Where is "Multiple Precision Integer" specified?
A.7.1 The basic proposal format does has the following fields defined in the
header:
- Proposal #, Proposal Len, Protocol # and Attribute TLV's
However, the ESP, AH, and ISAKMP proposals have defined the Transforms ID's
and a reserved field. Shouldnt the basic proposal format take care of
this as
well?
A.7.4. Proposal Formats, ISAKMP: ???
A.8.1. Security Association Payload Format
Does the Situation field length need to be an integral multiple of
four octets, as the Proposal field needs to be? Is the Situation Length
field (Figure 20) specified as octets, four-octet units, or ... ?
draft-ietf-ipsec-isakmp-oakley-00.txt
Where are ISAKMP exchange numbers defined for the various Oakley modes?
What happens to the Base, Identity Protection, and Authentication Only
exchanges defined in the ISAKMP draft? How does one implemement the other
exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley is
the only supported key exchange and is there any need to implement the basic
ISAKMP modes if one is supporting only key exchange for IPSEC?
5.1 Oakley Main Mode
Oakley Main Mode looks a lot like the Identity Protection exchange from
the ISAKMP draft, except that the Envelope is missing in all transactions,
a Nonce is added to the third and fourth messages, and the placement of
the optional Certificate relative to the Signature in the fifth and sixth
messages is reversed. Can these two exchanges be merged somehow?
Thanks,
-- Shawn Mamros and Naganand Doraswamy
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23381;
8 Aug 96 10:59 EDT
Received: by relay.hq.tis.com; id LAA11979; Thu, 8 Aug 1996 11:02:12 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011952; Thu, 8 Aug 96 11:01:47 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA04033; Thu, 8 Aug 96 11:01:14 EDT
Received: by relay.hq.tis.com; id LAA11939; Thu, 8 Aug 1996 11:01:41 -0400
Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma011899; Thu, 8 Aug 96 11:01:10 -0400
Received: by janus.border.com id <18491-2>; Thu, 8 Aug 1996 10:56:38 -0400
Date: Thu, 8 Aug 1996 10:55:11 -0400
From: Norman Shulman <norm@border.com>
To: iesg@ietf.net
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ietf@ietf.net, ipsec@TIS.COM, mjo@tycho.ncsc.mil, rob.glenn@nist.gov
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: <draft-ietf-ipsec-ah-hmac-md5-01.txt>
Message-Id: <96Aug8.105638edt.18491-2@janus.border.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Comments on <draft-ietf-ipsec-ah-hmac-md5-01.txt>
Page 4, 2.1, paragraph 1: "Protection" should be "Prevention" in two places.
Page 5, 2.2, paragraph 1, line 4:
"zeros" should be "zeros prior to the computation".
Page 5, 2.2, paragraph 2, line 4: "SHA" should be "MD5".
Norman Shulman Border Network Technologies Inc.
Software Engineer Tel 1 416 368 7157 ext 304
norm@border.com Fax 1 416 368 7178
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23611;
8 Aug 96 11:03 EDT
Received: by relay.hq.tis.com; id LAA12267; Thu, 8 Aug 1996 11:06:39 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012241; Thu, 8 Aug 96 11:06:17 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA04276; Thu, 8 Aug 96 11:05:42 EDT
Received: by relay.hq.tis.com; id LAA12229; Thu, 8 Aug 1996 11:06:09 -0400
Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma012224; Thu, 8 Aug 96 11:05:49 -0400
Received: by janus.border.com id <18468-1>; Thu, 8 Aug 1996 11:01:22 -0400
Date: Thu, 8 Aug 1996 10:58:36 -0400
From: Norman Shulman <norm@border.com>
To: iesg@ietf.net
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: ietf@ietf.net, ipsec@TIS.COM, shu-jen.chang@nist.gov, rob.glenn@nist.gov
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: <draft-ietf-ipsec-ah-hmac-sha-01.txt>
Message-Id: <96Aug8.110122edt.18468-1@janus.border.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Comments on <draft-ietf-ipsec-ah-hmac-sha-01.txt>
Page 4, paragraph 2, line 6: Delete the double quote.
Page 4, 1.2, third sentence: Seems to me that the ability to handle unpadded
message digests should either be dropped or made mandatory. If it is optional,
then it adds an element to the security parameter negotiations. If it is
retained, then 2.2(8) must be modified accordingly.
Page 5, paragraph 1: "Protection" should be "Prevention" in two places.
Page 6, 2.2(8): This has to be modified to accommodate an unpadded hash.
Norman Shulman Border Network Technologies Inc.
Software Engineer Tel 1 416 368 7157 ext 304
norm@border.com Fax 1 416 368 7178
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25105;
8 Aug 96 12:09 EDT
Received: by relay.hq.tis.com; id MAA15017; Thu, 8 Aug 1996 12:12:02 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma015011; Thu, 8 Aug 96 12:11:34 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA08265; Thu, 8 Aug 96 12:11:02 EDT
Received: by relay.hq.tis.com; id MAA15008; Thu, 8 Aug 1996 12:11:32 -0400
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1)
id xma015006; Thu, 8 Aug 96 12:11:22 -0400
Received: from ftp.com by ftp.com ; Thu, 8 Aug 1996 12:13:39 -0400
Received: from athena.ftp.com by ftp.com ; Thu, 8 Aug 1996 12:13:39 -0400
Message-Id: <2.2.32.19960808161836.00b48ca0@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Aug 1996 12:18:36 -0400
To: Rodney Thayer <rodney@sabletech.com>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Instead of adding a new header for compression, does it make sense to say
that we negotiate compression as a part of transform? For example, can we
negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression
enabled so that we compress the data before encrypting. We will avoid the
extra overhead of another header this way.
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03458;
8 Aug 96 17:37 EDT
Received: by relay.hq.tis.com; id RAA27310; Thu, 8 Aug 1996 17:40:21 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma027285; Thu, 8 Aug 96 17:39:53 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA02519; Thu, 8 Aug 96 17:39:20 EDT
Received: by relay.hq.tis.com; id RAA27277; Thu, 8 Aug 1996 17:39:51 -0400
Received: from iberia-c.it.earthlink.net(206.85.92.119) by relay.tis.com via smap (V3.1.1)
id xma027271; Thu, 8 Aug 96 17:39:48 -0400
Received: from rmonsour (max2-wc-ca-39.earthlink.net [206.149.198.139]) by iberia.it.earthlink.net (8.7.5/8.7.3) with SMTP id OAA04041; Thu, 8 Aug 1996 14:40:46 -0700 (PDT)
Message-Id: <2.2.32.19960808214308.006e95d4@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Aug 1996 14:43:08 -0700
To: Naganand Doraswamy <naganand@ftp.com>,
Rodney Thayer <rodney@sabletech.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 12:18 PM 8/8/96 -0400, Naganand Doraswamy wrote:
>Instead of adding a new header for compression, does it make sense to say
>that we negotiate compression as a part of transform? For example, can we
>negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression
>enabled so that we compress the data before encrypting. We will avoid the
>extra overhead of another header this way.
We at Stac have also been thinking about methods for adding compression in
the context of IPsec; specifically due to the problem as identified in the
draft as follows:
The introduction of security into packets transmitted using
Internet IP (Version 4) [RFC-791] causes a change in the
applicability of compression technology to data communications.
Specifically, when a packet is encrypted, it becomes essentially
random data, and therefore is highly incompressible. This makes
it difficult to use conventional techniques to compress IP
datagrams, such as PPP compression. To solve this problem it
becomes desirable to compress the data before it is encapsulated
with security features.
Our original thoughts were to push the compression function down to the ESP
transform level, i.e., define a transform (or set of transforms) which
combine compression with encryption under ESP and to include additional
"opaque" transform data that was compression-specific to handle packet to
packet sequencing for maintaining compression history across packets. The
downside to this approach, however, is that it does not allow compression to
be used in the absence of ESP (say, where only AH is used). I think that the
general method proposed in Rodney's draft (or a derivative thereof) may
indeed be preferable as it circumvents this problem.
I would add that this does pose another problem for the environment where
there may be a subsystem (say a chip or chipset) which takes an
under-construction IP datagram as input and performs compression, encryption
and AH MAC computation, outputting the complete IP datagram to be
transmitted. Since the AH MAC is computed over the entire IP datagram, the
datagram/payload length field of the packet is not known until after the
data is compressed (prior to encryption). In order to avoid making multiple
passes over the data, I would propose that the definition of the span of the
MAC for AH eliminate the datagram/payload length field.
Comments?
Bob Monsour
Stac, Inc.
rmonsour@stac.com
Received: from relay.hq.tis.com by neptune.TIS.COM id aa04588;
8 Aug 96 18:49 EDT
Received: by relay.hq.tis.com; id SAA29323; Thu, 8 Aug 1996 18:52:22 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma029312; Thu, 8 Aug 96 18:51:53 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA04260; Thu, 8 Aug 96 18:51:21 EDT
Received: by relay.hq.tis.com; id SAA29306; Thu, 8 Aug 1996 18:51:52 -0400
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1)
id xma029299; Thu, 8 Aug 96 18:51:22 -0400
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id SAA18933; Thu, 8 Aug 1996 18:53:29 -0400 (EDT)
Message-Id: <199608082253.SAA18933@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: Bob Monsour <rmonsour@earthlink.net>
Cc: ipsec@TIS.COM
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
In-Reply-To: Your message of "Thu, 08 Aug 1996 14:43:08 PDT."
<2.2.32.19960808214308.006e95d4@earthlink.net>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 08 Aug 1996 18:53:29 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Bob Monsour writes:
> I would add that this does pose another problem for the environment where
> there may be a subsystem (say a chip or chipset) which takes an
> under-construction IP datagram as input and performs compression, encryption
> and AH MAC computation, outputting the complete IP datagram to be
> transmitted. Since the AH MAC is computed over the entire IP datagram, the
> datagram/payload length field of the packet is not known until after the
> data is compressed (prior to encryption). In order to avoid making multiple
> passes over the data, I would propose that the definition of the span of the
> MAC for AH eliminate the datagram/payload length field.
>
> Comments?
That probably lowers security in some environments. Folding in the
length of the datagram makes it harder to fake a datagram with the
same MAC.
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12867; 9 Aug 96 5:18 EDT
Received: by relay.hq.tis.com; id FAA04564; Fri, 9 Aug 1996 05:21:36 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma004561; Fri, 9 Aug 96 05:21:08 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15016; Fri, 9 Aug 96 05:20:35 EDT
Received: by relay.hq.tis.com; id FAA04555; Fri, 9 Aug 1996 05:21:06 -0400
Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1)
id xma004545; Fri, 9 Aug 96 05:20:52 -0400
Received: from komsys-pc-mw.ethz.ch (komsys-pc-mw [129.132.66.24]) by tik1.ethz.ch (8.7.5/8.7.3) with SMTP id LAA11191; Fri, 9 Aug 1996 11:22:54 +0200 (MET DST)
Message-Id: <199608090922.LAA11191@tik1.ethz.ch>
Received: by komsys-pc-mw.ethz.ch (NX5.67f2/NX3.0X)
id AA00297; Fri, 9 Aug 96 11:22:44 +0200
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
In-Reply-To: <2.2.32.19960808161836.00b48ca0@mailserv-H.ftp.com>
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3)
Received: by NeXT.Mailer (1.118.2)
From: Marcel Waldvogel <mwa@tik.ee.ethz.ch>
Date: Fri, 9 Aug 96 11:22:42 +0200
To: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
Cc: ipsec@TIS.COM
References: <2.2.32.19960808161836.00b48ca0@mailserv-H.ftp.com>
X-Image-Url: http://www.tik.ee.ethz.ch/~mwa/mwa.mail.tiff
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
On Thu, 08 Aug 1996, Naganand Doraswamy <naganand@ftp.com> wrote:
> Instead of adding a new header for compression, does it make sense to say
> that we negotiate compression as a part of transform? For example, can we
> negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression
> enabled so that we compress the data before encrypting. We will avoid the
> extra overhead of another header this way.
I think it's much better to have separate AH, ESP and COMP headers.
I don't like the approach of creating combined AH-ESP transforms.
Especially now, with the upcoming compression algorithms (which I'm very
much in favor of), this would result in a massive explosion of the number of
combined AH-COMP-ESP-transforms. Just having 2 of each of the transforms
plus the possibility to drop any of them already gives us (2+1)^3=27
combinations, which already will make creating/maintaining any IPSEC
implementation into a nightmare.
Therefore I very much like the orthogonality approach originally intended,
so that you can choose every combination of AH, COMP, and ESP you think fits
your needs best. This approach also improves modularity and flexibility in
the implementation.
-Marcel
---
Marcel Waldvogel Swiss Federal Institute of Technology (ETH)
Phone/Fax +41-1-632 70 62/10 35 Computer Engineering and Networks Laboratory
http://www.tik.ee.ethz.ch/~mwa ETH Zentrum, ETZ G63; CH-8092 Zürich
PGP public key fingerprint = 5D D0 A1 6D F2 BC 60 69 46 49 2C 6D F8 EE 9E BF
Received: from relay.hq.tis.com by neptune.TIS.COM id aa20960;
9 Aug 96 13:12 EDT
Received: by relay.hq.tis.com; id NAA14267; Fri, 9 Aug 1996 13:02:43 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma014246; Fri, 9 Aug 96 13:02:14 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA06782; Fri, 9 Aug 96 13:01:41 EDT
Received: by relay.hq.tis.com; id NAA14240; Fri, 9 Aug 1996 13:02:13 -0400
Received: from park.interport.net(199.184.165.2) by relay.tis.com via smap (V3.1.1)
id xma014236; Fri, 9 Aug 96 13:01:49 -0400
Received: from massey (massey.ftp.com [128.127.128.152]) by park.interport.net (8.7.3/8.7.3) with SMTP id NAA05486; Fri, 9 Aug 1996 13:04:07 -0400 (EDT)
Message-Id: <199608091704.NAA05486@park.interport.net>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 09 Aug 1996 13:03:46 -0400
To: ipsec@TIS.COM
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: compression algorithms
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Regarding mail from Marcel Waldvogel...
>X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3)
>From: Marcel Waldvogel <mwa@tik.ee.ethz.ch>
>Date: Fri, 9 Aug 96 11:22:42 +0200
>Especially now, with the upcoming compression algorithms (which I'm very
>much in favor of), this would result in a massive explosion of the number of
>combined AH-COMP-ESP-transforms.
Which compression algorithms should be covered? I myself have thought about
ZLIB, STAC, IBM. I know of at least one other. I'm curios if there are
others because I'm trying to think about this in terms of providing
capability for compression history/context or other features,
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
Received: from relay.hq.tis.com by neptune.TIS.COM id aa22095;
9 Aug 96 13:57 EDT
Received: by relay.hq.tis.com; id NAA16824; Fri, 9 Aug 1996 13:59:37 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma016812; Fri, 9 Aug 96 13:59:09 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA09559; Fri, 9 Aug 96 13:58:35 EDT
Received: by relay.hq.tis.com; id NAA16809; Fri, 9 Aug 1996 13:59:06 -0400
Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1)
id xma016795; Fri, 9 Aug 96 13:58:50 -0400
Received: from [192.1.7.164] ([192.1.7.164]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id OAA26481; Fri, 9 Aug 1996 14:05:49 -0400 (EDT)
Date: Fri, 9 Aug 1996 14:05:49 -0400 (EDT)
X-Sender: rshirey@rosslyn.bbn.com
Message-Id: <v02140b20ae30f468a8d0@[192.1.7.164]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Rodney Thayer <rodney@sabletech.com>, ipsec@TIS.COM
From: "Robert W. Shirey" <rshirey@bbn.com>
Subject: Re: compression algorithms A FEW MORE
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 1:03 PM 8/9/96, Rodney Thayer wrote:
>Regarding mail from Marcel Waldvogel...
>
>>X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3)
>>From: Marcel Waldvogel <mwa@tik.ee.ethz.ch>
>>Date: Fri, 9 Aug 96 11:22:42 +0200
>
>>Especially now, with the upcoming compression algorithms (which I'm very
>>much in favor of), this would result in a massive explosion of the number of
>>combined AH-COMP-ESP-transforms.
>
>Which compression algorithms should be covered? I myself have thought about
>ZLIB, STAC, IBM. I know of at least one other. I'm curios if there are
>others because I'm trying to think about this in terms of providing
>capability for compression history/context or other features,
>
> Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
> Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
> Fax: +1 617 332 7970 http://www.shore.net/~sable
> "Developers of communications software"
Rod,
There are a "few" that you have missed. (See attachment.)
Regards, -Rob-
rshirey@bbn.com, Tel 703-284-4641, Sec 284-4600, Fax 284-4777
Robert W. Shirey, BBN Corporation, Mail Stop 30/4C, Suite 1200,
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA
-----------------------------------------------------------------
The most recent copy of this text may be anonymous ftp'd from
ftp.cso.uiuc.edu (128.174.5.61) in the directory /doc/pcnet as
the file compression.
This file is maintained by David Lemson (lemson@uiuc.edu).
Please do not strip this note from this list when passing it on.
-------------------------------------------------------------------------------
DECODING THIS CHART: This chart has been compacted to fit into 80 columns
so it can be viewed on-line. The first column is the name of the compression/
archiving technique. The next field is the file extension given to the
resulting file. After that are 5 columns each for a different operating system.
Each one of these consists of the name of the file/program to undo the given
compression/archiving style and a letter that tells where the file/program may
be obtained. All symbols and letters are decoded at the bottom portion of this
file.
-------------------------------------------------------------------------------
FILE COMPRESSION, ARCHIVING, AND TEXT<->BINARY FORMATS
Last Update: 17 October 1994 Operating System/Unpackaging Program
NAME File DOS * Mac * Unix * VM/CMS * Amiga *
Extension
abe ? abe.exe N - abe Q - -
afio - - - afio ? - -
ar (any) - - ar L - -
ARC .ARC arc602.exe B ArcMac1.3c D arc521 Barcutil2.04K Arc 0.23 Aa
ARCHDOS .IBM Internal IBM only - creates .EXE self-extractors also
ARJ .ARJ arj239d.exe B unarjmac B unarj230 B unarj K -
BinHex .Hqx BINHEX.EXE B BinHex4.0 + A mcvert D binhex X -
xbin23.zip B
binscii * - - sciibin3.10 - -
BLU ? - - - - -
BOO .BOO msbpct.exe B ? ? - - -
msbmkb.exe
btoa (any)atob11.zip B + btoa L - compress Ab
Bundle .bndl - Bundle ? Unbundle M - -
CardDump(any) - - - card K -
compact .C - - uncompact L - -
Compact
Pro .cpt EXT_PC10.arj ? Compact Pro 1.34 D - - -
compress.Z u16.zip A MacCompress3.2D compress L compress K compress Ac
comp430d.zip B
.compressed *** NEXTSTEP - same as .tar.Z, use zcat <filnam> | tar xf -
GNU ZIP .gz gzip123.exe B MacGzip0.2 D gzip123 L
(NOTE: also known as "GNU Compress" and used .z extension until v 1.1.1)
cpio ? pax2exe.zip H - cpio L - -
COMT .COM comt010d.zip B - - - -
Crunch ? - - - arcutil K -
Diamond (spc+hibit) - Diamond 3.0 Z - - -
Diet (any)diet110a.zip B - - - -
Disk-
Doubler .dd - DiskDoubler3.7.6 Z - - -
Disk- .DMS - - - - dms-102 B
Masher .EXE
DWC .DWC dwc-a501.exe B - - - -
FPack (any) ? ? FPack2.2 D ? ? - -
HPACK .HPK hpack78.zip B
HYPER .HYP hyper25.zip B - - - -
Imploder(any) - - - - imploder1.3 B
Ish .ish ish200.lzh B ishmac-0.6 D ? ? ?
JPEG (any) (See note at bottom - C source available) ***
Larc .LZS larc333.zip B - - - -
LHA .LHA lha255b.exe B MacLHA 2.13 D lha1.00 U - lha_e138.run B
LHarc .LZH lh113c.exe H MacLHarc 0.41 D lharc102 U - LHarc Ad
(NOTE: LHA supersedes LHarc in functionality)
LHWarp .LZW - LZWRes 1.0 D - - Lhwarp Ae
LU (LAR).LBR lue220.arc B - l(t)ar ? arcutil K -
LZari ? - MacLZAri 7-11 ? - - -
LZEXE .EXE lzexe91.zip A - - - -
LZSS .lzss ? ? CompRes 1.1 D - - -
MDCD .MD mdcd10.arc B - - - -
pack .z - - unpack L - -
PackIt .pit UnPackIt ? PackIt3.1.3 D unpit ? - -
PAK .PAK pak251.exe H ? ? - - -
PKLITE .EXE pklte115.exe B - - - -
PKPAK .ARC pk361.exe A ArcMac1.3c A arc521 I arcutil2.0K PKAX ?
PKZIP .ZIP pkz204g.exe B ZipIt1.2.6 D unzip511 B arcutil2.04K PKAZip Af
Power- .pp
Packer - - - - PowerPacker Ai
Scrunch .COM scrnch.arc B - - - -
Shark - - sh E
shell - .shar
archive toadshr1.arc B UnShar2.1 D unshar L - UnShar Ag
Ship (any) (See note at bottom about Ship and Portable Zip) *
shrinkit.shk nulib34 O - nulib34 O - -
Shrink-
ToFit .stf - STF1.2 A - - -
SPL ? - ? ? - - -
Squash .ARC squash.arc B - - - -
Squeeze .xQx sqpc131.arc B ? ? ? ? arcutil K Sq.Usq Ah
Squeeze .sqz sqz1083.exe B
StuffIt .sit unstuff.exe B StuffItLite307D unsit D - -
tar .tar tar.zip A Tar 4.0b D tar L - TarSplit Ai
tarread.arc I
extar10.zip B
ltarv1.zip B
terse (any)Copyright IBM - - vmarc + -
uuencode.UUE ncdc151.zip B uutool2.3.2 B uudecode L arcutil K uudecode Aj
UltraCII.UC2 uc2ins.exe B - - - -
Warp .WRP - - - - WarpUtil Ak
whap .AP ? ? yabbawhap M ? yabbawhap M
xxencode.XXE ncdc150.zip B - xxdecode A xxdecode K -
yabba .Y ? ? yabbawhap M ? yabbawhap M
ZOO .ZOO zoo210.exe A MacBooz2.1 D zoo210 B zoo K amigazoo A
------------------------------------------------------------------------------
Extended Chart:
VMS * Apple 2 * Atari * OS/2 * Windows3
aaf (any) - aaftools O
abe ? - - - - -
afio - - - - - -
ar (any) - - - - -
ARC .arc arcvms.uue B angel.shk O B arc521e.arc R arc2.arc A -
ARJ .ARJ unarj220 B - unarj_st.lzh R - -
BinHex .Hqx - - - - -
binscii * - binscii.exe O - - -
BLU ? - unblu O - - -
BOO .BOO - - - - -
btoa (any) - - - - -
Bundle .bndl - - - - -
CardDump(any) - - - - -
compact .C - - - - -
Compact
Pro .cpt - - - - -
compress.Z lzdcomp.exe P compress.shk O compress.arc R - -
cpio ? - - - - -
Crunch ? - - - - -
Disk-
Doubler ? - - - - -
DWC .DWC - - - - -
FPack (any) - - - - -
GZIP .gz gzip-1-2-2.zipP
HPACK .HPK ? * ? * ? * ? * ? *
HYPER .HYP - - - - -
Larc .LZS - - - - -
LHA .LHA - angel O - lha214_2 -
LHarc .LZH - - lzh_2011.lzh R clhar103 S -
LHWarp .LZW - - - - -
LU(LAR) .LBR vmssweep B - - - -
LZari ? - - - - -
LZEXE .EXE - - - - -
LZSS .lzss - - - - -
MDCD .MD - - - - -
PackIt .pit - - - - -
PAK .PAK - - - - -
PKPAK .ARC - - pkunarc.arc R - -
PKZIP .ZIP unzip51 P pmpunzip20 B STZIP22.tos R pkz101-2.exe A -
Power-
Packer (any) - - - - -
Scrunch .COM - - - - -
shell-
archive .shar - unshar.shk O shar.arc R - -
shrinkit.shk - ? O - - -
Shrink-
ToFit .stf - - - - -
SPL ? - - - - -
Squash .ARC - - - - -
Squeeze ? vmsusq.pas B a2unix O ezsqueeze.arc R - -
StuffIt .Sit - - - - -
tar .tar vmstar Q - sttar.arc R - -
terse (any) - - - - -
uuencode.uue uudecode2.vmsB uu.en.decode O uucode10.arcR - -
Warp .WRP - - - - -
whap ? ? - ? ? -
xxencode.XXE - - - - -
yabba ? ? - ? ? -
ZOO .ZOO ZOO210.TAR-Z B - zoo21bin.arcR booz.exe A -
------------------------------------------------------------------------------
WHERE TO GET THEM:
A. ftp.cso.uiuc.edu [128.174.5.61]
/pc/exec-pc/ {Zip, arc, lots of good stuff}
/pc/local
/mac/
NOTE: Many mac things in: /mac/MUG/Utilities2.0-sit.Hqx;1
/amiga/fish/(see individual references)
a ff070 b ff051 c ff051 d ff312 e ff305 f ff311 g ff345
h ff051 i ff053 j ff092 k ff243 i ff253
B. wuarchive.wustl.edu [128.252.135.4] (UIUC: NFS mounted on uxa and mrcnext)
-> See H. below for another site for /systems/ibmpc/simtel/ directories <-
/systems/ibmpc/simtel/archivers/ {arc, LHARC, hpack}
/filutl/ {atob11, msbpct - BOO, toadshr, DIET, ncdc151}
/sq-usq/ {NUSQ}
/zip/ {unzip}
/mac/ {unsit30}
/systems/mac/info-mac/util/
/systems/unix/arc-progs/ {ARC,GZIP}
/misc/vaxvms/ {UNZIP for VMS}
/misc/unix/ {UNZIP, ZOO for UNIX/VMS, UNARJ}
/systems/amiga/aminet/util/arc {AMIGA}
/systems/amiga/aminet/util/pack {AMIGA}
/systems/apple2/umich.edu/gs/util {Apple 2}
C. omnigate.clarkson.edu [128.153.4.2]
/pub/ncsa2.2tn/
D. sumex-aim.stanford.edu [36.44.0.6]
/info-mac/util/ {Stuffit Lite, Compactor Pro, etc.}
/unix/ {unsit, mcvert}
E. ftp.uu.net [137.39.1.9]
/pub/
/ioccc/shar.1990.* {shark}
F. grape.ecs.clarkson.edu [128.153.28.129.]
- collection varies - see the file 'allfiles'
G. watsun.cc.columbia.edu [128.59.39.2]
Definitive source for KERMIT releases for all machines
/kermit/a/
H. wsmr-simtel20.army.mil [192.88.110.20]
oak.oakland.edu [141.210.10.117] is the primary mirror for
simtel20. wuarchive (B) is a secondary mirror.
cd pd1:<msdos.arc-lbr>
SIMTEL20 files are available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
archive.orst.edu (128.193.2.13), ftp.uu.net (137.39.1.9), nic.funet.fi
(128.214.6.100), src.doc.ic.ac.uk (146.169.3.7), nic.switch.ch
(130.59.1.40), archie.au (139.130.4.6), NCTUCCCA.edu.tw (140.111.3.21),
by e-mail through the BITNET/EARN file servers, or by uucp from UUNET's
1-900-GOT-SRCS. See UUNET file uunet!~/info/archive-help for details.
I. pc.usl.edu [130.70.40.3]
/pub/unix/
K. vmd.cso.uiuc.edu [128.174.5.98]
card - cd public.460
others, including ARCUTIL - cd public.477
- NOTE: UUDECODE, UNARJ, ZOO and COMPRESS are originally from
LISTSERV@BLEKUL11
L. (should be available on all major unix systems including
wuarchive.wustl.edu in /unix-c/arc-progs
also uxc.cso.uiuc.edu in /pub)
M. comp.sources.unix archives
(varies, including wuarchive in /usenet/comp.sources.unix)
N. comp.binaries.ibm.pc archives
(varies, including wuarchive in /usenet/comp.binaries.ibm.pc)
O. cco.caltech.edu [131.215.139.100]
/pub/apple2/ {binscii.exe}
/ARCHIVERS {angel.shk, unblu in a2unix.aaf}
/source {aaftools}
P. ftp.spc.edu [192.107.46.27]
GZIP - [.macro32.savesets]gzip-1-*.zip
(use [.macro32]unzip.exe to extract)
Q. vmsa.oac.uci.edu [128.200.9.5]
/
R. atari.archive.umich.edu [141.211.164.8]
/atari/archivers/
S. mtsg.ubc.ca [137.82.27.1]
/os2
U. alt.sources archives (available on wuarchive.wustl.edu in
/usenet/alt.sources/)
{LHarc is articles number 2217 and 2218}
V. rascal.ics.utexas.edu [128.83.138.20]
/misc/mac/utilies
W. akiu.gw.tohoku.ac.jp [130.34.8.9]
/pub/mac/tools/archiver
X. brownvm.brown.edu [128.148.128.40]
/ {BINHEX.READ-ME for instructions}
Z. Commercial software product - check discount mail order
software houses, computer stores.
NOTES:
Symbols: + means see the notes below for special information
- means that nothing exists to the best of my knowledge
? means that something exists but I do not know the name
of the program or where to get it
* means that e-mail should be sent to lemson@uiuc.edu
for details/explanation
JPEG - source (Free code) is available in
ftp.uu.net:/graphics/jpeg/jpegsrc.v?.tar.Z. Supports conversion
between JPEG "JFIF" format and image files in PBMPLUS PPM, Utah RLE,
Truevision Targa, and GIF file formats. Contact for more info:
Dr. Thomas G. Lane, organizer, Independent JPEG Group
Internet: jpeg-info@uunet.uu.net
Current version (1/93) is v4.
PKZIP 2.04g is shareware. The Encryption version is freely
exportable to all countries except Cuba,Iran,Iraq,North Korea, the
police or military of South Africa, Syria, and Vietnam. (by order of
the US Government)
Some uuencode/uudecode programs are able to read xxencode files.
Stuffit Lite 3.0 is the replacement version of Stuffit
Classic 1.6 for Macintosh. Stuffit Lite is shareware, $25. Stuffit
Deluxe is the commercial version from Aladdin Software.
Stuffit Expander 3.0.1 is a free version from Aladdin that can
decompress most Macintosh compression schemes. It is available in
the same place as other Mac decompression products.
VMARC, available with the command "TELL LISTSERV AT RPIECS GET VMARC
PACKAGE" from a CMS machine, will decode any CMS terse program. The
PC version of terse is a commercial program available from IBM
directly.
There is a portable 'ZIP' that goes along with unzip50p1 that is
available from wuarchive and other mirrors in the same places as
unzip. (see (B) above)
WizUnzip, WINUNZ20.ZIP in the WINDOWS3 dir on
wuarchive (B), is a MS Windows 3 version of Unzip50p1.
GZIP, the GNU Zip-like utility, is available from prep.ai.mit.edu.
Current version is 1.2.2 (16 June 93). A VMS version is available
as follows: (this has binaries for VMS for VAX and AXP)
To get gzip via anonymous ftp from ftp.spc.edu, you'll need:
[.MACRO32]UNZIP.EXE or UNZIP.ALPHA_EXE
[.MACRO32.SAVESETS]GZIP-1-2-2.ZIP
To get it via e-mail, send the following commands in the body of a
mail message to FILESERV@WKUVX1.WKU.EDU:
SEND GZIP-1-2-2
SEND FILESERV_TOOLS
There is a set of translators that will allow Stuffit Deluxe to read
btoa, UUencoded files, zip, pack, tar, MacBinary, and others. They are in
sumex-aim.stanford.edu:/info-mac/utils/stuffit-deluxe-translators.hqx.
When using tar.exe for PC's, the order of option flags is important.
For extraction, use tar -xvf <filename>.
ARC : From SEA, ARC 6.02 is the latest widespread shareware release.
It is available at A (ftp.cso.uiuc.edu).
Also, SEA has ARC 7.10, but it is commercial, not shareware.
(see note at bottom)
When using binscii.exe for an Apple II, there are different file extensions
depending on the type of file being changed.
BinHexed files (with the extension .hqx) can be UnBinHexed with BinHex 4.0 or
Stuffit (preferably Stuffit). BinHex5.0 format is a MacBinary format,
while BinHex 4.0 files are ASCII format.
The files listed are only supposed to uncompress/unarchive.
To compress/archive, further software may be needed.
USAGE NOTES:
There are certain "standard" combinations of compression used:
unix - .tar.Z
(often this will be .taz for PC's)
unix - tar.Z.btoa (abbrev. to .TZB sometimes) (aka "tarmail")
mac - .sit.hqx
- these must be undone in order starting at the end of the name
Sometimes an archive may be self-extracting. These will look like normal
executable programs. Simply run them to undo the archive.
LZEXE (PC), PKLITE(PC), Imploder(Amiga), and PowerPacker(Amiga)
are executable compressors.
They compress an executable file and attach an uncompressing header so that
the file can still be executed while in compressed form.
The listed programs for these utilities compress files, in order to uncompress
a file with these types of compression, just execute them.
DIET (PC) is a TSR program that compresses and decompresses both
executables and data files as needed.
DEFINITIVE SOURCES:
PKWARE Support BBS - avaliable 24 hours
(414) 352-7176
ZOO - author: Rahul Dhesi
source code in C on Usenet and GEnie's IBM PC Roundtable
ARC - SEA (System Enhancement Associates, Inc.)
804-442-5865
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25026;
9 Aug 96 16:14 EDT
Received: by relay.hq.tis.com; id QAA20304; Fri, 9 Aug 1996 16:17:07 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma020301; Fri, 9 Aug 96 16:16:41 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16211; Fri, 9 Aug 96 16:16:07 EDT
Received: by relay.hq.tis.com; id QAA20288; Fri, 9 Aug 1996 16:16:38 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1)
id xma020279; Fri, 9 Aug 96 16:16:09 -0400
Received: from copacabana.watson.ibm.com (copacabana.watson.ibm.com [9.2.19.74]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id QAA21160; Fri, 9 Aug 1996 16:18:57 -0400
Received: by copacabana.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96)
id AA19934; Fri, 9 Aug 1996 16:16:53 -0400
Date: Fri, 9 Aug 1996 16:16:53 -0400
From: "H.Krawczyk" <hugo@watson.ibm.com>
Message-Id: <9608092016.AA19934@copacabana.watson.ibm.com>
To: iesg@ietf.org
Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA)
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>
> 2. HMAC-SHA IP Authentication with Replay Prevention
> <draft-ietf-ipsec-ah-hmac-sha-01.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by August 20, 1996.
I propose the following change to the above draft (page 6).
Replace:
> (7) apply SHA to the stream generated in step (6)
> (8) The sender then zero pads the resulting hash to a 64-bit boundary
> for word alignment. The receiver compares the generated 160-bit hash
> to the first 160-bits of authentication data contained in the AH.
With:
(7) apply SHA to the stream generated in step (6) and output the first
(leftmost) 128 bits of the result.
--------
Thus, I am proposing that instead of padding the 160 bits of SHA output
to 192 bits, truncate the result to 128 bits.
Beyond the advantage for bandwidth, this truncation is plausible to
add to the security.
In general, it is an old practice to truncate MACs. In the context
of keyed-hash this has been explicitely proposed by Preneel and van
Oorschot (Crypto'95). I do not know of any *proof* that
truncating adds to the security. However, there are examples of attacks where
this is the case. And as long as you do not truncate "too much"
then everything indicates that it helps. In particular, I know of no
reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario.
Note: Be careful not to get confused with the unkeyed uses of SHA.
There, collision resistance is usually the sacred goal and truncating the
output HURTS HURTS HURTS (because of birthday attacks).
For keyed-hash for message authentication the story is very different.
Actually, the justification for truncation in [PV] is *exactly*
because it helps *against* birthday attacks.
(Yes, I know it sounds confusing but that's the way it is...)
Still in the application of HMAC the 160 bits in the definition of SHA help
as the length of the *intermediate* results of the compression function,
but not as the final result.
ANyway, truncation as a general method has an advantage (less information
available to the adversary) and a disadvantage (less bits to predict for the
attacker). When truncating 160 to 128 the advatage is far more significant
than the disadvantage (It would be different if we truncated to 64 bits;
that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my
"personal minimum".)
BTW, in the RFC on HMAC that I am submitting to the IETF there is a section
on truncation of HMAC output.
----------
The patent issue:
There is a patent by Novell (US 5349642) that claims keyed hash functions
for message authentication. Such claim would cover (I am not a lawyer!)
all hash based schemes that have ever been suggested in this WG, including HMAC.
Fortunately, the filing date of that patent is Nov 3 1992, while
Gene Tsudik's paper proposing such functions appeared in Infocom in May 1992.
(This work is also part of Gene's UCLA's PhD dissertation of May 1991).
The one element that does not appear in Tsudik's work is truncation.
However, truncating the output of MAC functions is an old and very well
known practice in cryptography. For example,
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982.
[ANSI] ANSI X9.9, ``American National Standard for Financial
Institution Message Authentication (Wholesale),'' American
Bankers Association, 1981. Revised 1986.
and therefore a hard to defend claim (I'm not a lawyer!!).
After consulting with Jeff Schiller and the WG chairs, it became clear
to me that the existence of Novell's patent shouldn't be an obstacle to
include a section on truncation in the HMAC rfc, and more significantly,
to propose it for adoption for AH-HMAC-SHA.
Hugo
PS: In the next weeks I will be reading e-mail very sporadicly (like,
maybe, once each two weeks :), so do not get angry if I do not respond
(especially after Tuesday).
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25334;
9 Aug 96 16:25 EDT
Received: by relay.hq.tis.com; id QAA20612; Fri, 9 Aug 1996 16:28:37 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma020596; Fri, 9 Aug 96 16:28:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16738; Fri, 9 Aug 96 16:27:37 EDT
Received: by relay.hq.tis.com; id QAA20591; Fri, 9 Aug 1996 16:28:07 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1)
id xma020566; Fri, 9 Aug 96 16:27:44 -0400
Received: from copacabana.watson.ibm.com (copacabana.watson.ibm.com [9.2.19.74]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id QAA08862; Fri, 9 Aug 1996 16:30:35 -0400
Received: by copacabana.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96)
id AA24044; Fri, 9 Aug 1996 16:28:48 -0400
Date: Fri, 9 Aug 1996 16:28:48 -0400
From: "H.Krawczyk" <hugo@watson.ibm.com>
Message-Id: <9608092028.AA24044@copacabana.watson.ibm.com>
To: perry@piermont.com
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Perry,
>
> Bob Monsour writes:
> > I would add that this does pose another problem for the environment where
> > there may be a subsystem (say a chip or chipset) which takes an
> > under-construction IP datagram as input and performs compression, encryption
> > and AH MAC computation, outputting the complete IP datagram to be
> > transmitted. Since the AH MAC is computed over the entire IP datagram, the
> > datagram/payload length field of the packet is not known until after the
> > data is compressed (prior to encryption). In order to avoid making multiple
> > passes over the data, I would propose that the definition of the span of the
> > MAC for AH eliminate the datagram/payload length field.
> >
> > Comments?
>
> That probably lowers security in some environments. Folding in the
> length of the datagram makes it harder to fake a datagram with the
> same MAC.
A personal "historical" remark:
One of the design principles of HMAC was not to rely on prepended length.
Actually, my own involvement with MAC based on hash functions in IPSEC
started when the "official" proposal for AH was to use prepend-only key
(ie, MD5(K,data)) which *requires* prepended length (to prevent trivial
extension attacks).
The answer to this objection of mine by certain people in the group
(I'm sure you remember) was that IP headers carry the length anyway.
I tried to argue that relying on that was a security and engineering
mistake: ``may be one day...'' went the argument.
The day is now here. A good lesson against security myopia
And by the way, in Jim Hughes' draft the header (and then length) is not
authenticated either.
All of this is not to say that certain MAC (like CBC-MAC or even HMAC
with some hash functions) couldn't be benefited from prepended length. But
in that case the MAC MUST include the prepended length as part of its
definition and not to rely on the particularities of the data being
authenticated.
Hugo
>
> Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25791;
9 Aug 96 16:36 EDT
Received: by relay.hq.tis.com; id QAA20963; Fri, 9 Aug 1996 16:39:07 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma020952; Fri, 9 Aug 96 16:38:39 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA17198; Fri, 9 Aug 96 16:38:06 EDT
Received: by relay.hq.tis.com; id QAA20946; Fri, 9 Aug 1996 16:38:37 -0400
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap (V3.1.1)
id xma020937; Fri, 9 Aug 96 16:38:17 -0400
Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id QAA05056; Fri, 9 Aug 1996 16:40:37 -0400 (EDT)
Message-Id: <199608092040.QAA05056@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol
To: "H.Krawczyk" <hugo@watson.ibm.com>
Cc: ipsec@TIS.COM
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
In-Reply-To: Your message of "Fri, 09 Aug 1996 16:28:48 EDT."
<9608092028.AA24044@copacabana.watson.ibm.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 09 Aug 1996 16:40:31 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
"H.Krawczyk" writes:
> > That probably lowers security in some environments. Folding in the
> > length of the datagram makes it harder to fake a datagram with the
> > same MAC.
>
> A personal "historical" remark:
>
> One of the design principles of HMAC was not to rely on prepended length.
Certainly. But not all MACs used by IPSEC will necessarily be as
robust as HMAC.
> All of this is not to say that certain MAC (like CBC-MAC or even HMAC
> with some hash functions) couldn't be benefited from prepended length. But
> in that case the MAC MUST include the prepended length as part of its
> definition and not to rely on the particularities of the data being
> authenticated.
Certainly at the very least one must mention in such a transform
document that one is explicitly relying on the length being present...
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa27233;
9 Aug 96 17:33 EDT
Received: by relay.hq.tis.com; id RAA22173; Fri, 9 Aug 1996 17:36:07 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma022154; Fri, 9 Aug 96 17:35:47 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19145; Fri, 9 Aug 96 17:35:06 EDT
Received: by relay.hq.tis.com; id RAA22144; Fri, 9 Aug 1996 17:35:38 -0400
Received: from mailserv.esat.kuleuven.ac.be(134.58.56.129) by relay.tis.com via smap (V3.1.1)
id xma022136; Fri, 9 Aug 96 17:35:20 -0400
Received: from domus.esat.kuleuven.ac.be by mailserv (5.67b8/IDA/v1.5)
id AA14910; Fri, 9 Aug 1996 23:37:22 +0200
Date: Fri, 9 Aug 1996 23:37:23 +0200 (METDST)
From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
To: "H.Krawczyk" <hugo@watson.ibm.com>
Cc: iesg@ietf.org, ipsec@TIS.COM
Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA)
In-Reply-To: <9608092016.AA19934@copacabana.watson.ibm.com>
Message-Id: <Pine.HPP.3.91.960809232943.11184E-100000@domus.esat.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Charset: ISO_8859-1
X-Char-Esc: 29
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hugo,
I support your statement that shortening the result of
HMAC based on SHA-1 from 160 to 128 bits will probably be an
improvement.
I would not even see a problem to shorten the SHA-1 output to
64 bits. When considering attack scenarios, I would be much more
worried about an attacker who uses the known text-MAC pairs to
obtain information on the key than about an attacker who tries to
predict some bits to forge a MAC for two reasons:
- a key recovery is more serious than a forgery
- for concrete hash functions such as MD5 and SHA-1, I feel
that the first attack is more likely (just intuition).
Bart
-------------------------------------------------------------------------------
Katholieke Universiteit Leuven tel. +32 16 32 11 48
Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 86
K. Mercierlaan 94, B-3001 Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be
-------------------------------------------------------------------------------
On Fri, 9 Aug 1996, H.Krawczyk wrote:
...
> Thus, I am proposing that instead of padding the 160 bits of SHA output
> to 192 bits, truncate the result to 128 bits.
>
> Beyond the advantage for bandwidth, this truncation is plausible to
> add to the security.
>
...
> Anyway, truncation as a general method has an advantage (less information
> available to the adversary) and a disadvantage (less bits to predict for the
> attacker). When truncating 160 to 128 the advatage is far more significant
> than the disadvantage (It would be different if we truncated to 64 bits;
> that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my
> "personal minimum".)
>
...
Received: from relay.hq.tis.com by neptune.TIS.COM id aa27702;
9 Aug 96 17:53 EDT
Received: by relay.hq.tis.com; id RAA22547; Fri, 9 Aug 1996 17:56:08 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma022543; Fri, 9 Aug 96 17:55:40 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19704; Fri, 9 Aug 96 17:55:06 EDT
Received: by relay.hq.tis.com; id RAA22537; Fri, 9 Aug 1996 17:55:38 -0400
Received: from janus.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma022532; Fri, 9 Aug 96 17:55:31 -0400
Received: by janus.border.com id <18436-1>; Fri, 9 Aug 1996 17:57:20 -0400
Message-Id: <96Aug9.175720edt.18436-1@janus.border.com>
To: "Robert W. Shirey" <rshirey@bbn.com>
Cc: Rodney Thayer <rodney@sabletech.com>, ipsec@TIS.COM
Subject: Re: compression algorithms A FEW MORE
References: <v02140b20ae30f468a8d0@[192.1.7.164]>
In-Reply-To: Your message of "Fri, 09 Aug 1996 14:05:49 -0400".
<v02140b20ae30f468a8d0@[192.1.7.164]>
From: "C. Harald Koch" <chk@border.com>
Organization: Border Network Technologies Inc.
Phone: +1 416 368 7157
X-Uri: <URL:http://www.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: Fri, 9 Aug 1996 17:57:47 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
This is getting a bit off-topic. However:
In message <v02140b20ae30f468a8d0@[192.1.7.164]>, "Robert W. Shirey" writes:
>
> There are a "few" that you have missed. (See attachment.)
That list contains file comression and archiving *software*, not compression
algorithms. Those packages use one (or more) of a very small number of
compression algorithms. In fact, most of the algorithms used are simply
variants on LZ77 and LZ78, usually combined with other algorithms like
Huffman coding or Shannon-Fano coding.
For more details on compression algorithms, see the comp.compression FAQ
documents, available from
<ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/> (among other
places). One explicit quote:
"All popular archivers (arj, lha, zip, zoo) are variations on the LZ77
theme."
--
C. Harald Koch | Border Network Technologies Inc.
chk@border.com | Senior System Developer
+1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7789 (fax) | Madness takes its toll. Please have exact change.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24343;
11 Aug 96 17:44 EDT
Received: by relay.hq.tis.com; id RAA07293; Sun, 11 Aug 1996 17:47:33 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma007291; Sun, 11 Aug 96 17:47:05 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA21490; Sun, 11 Aug 96 17:46:30 EDT
Received: by relay.hq.tis.com; id RAA07288; Sun, 11 Aug 1996 17:47:03 -0400
Received: from merit.edu(35.1.1.42) by relay.tis.com via smap (V3.1.1)
id xma007283; Sun, 11 Aug 96 17:46:48 -0400
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-21.dialip.mich.net [141.211.7.157]) by merit.edu (8.7.5/merit-2.0) with SMTP id RAA02117 for <ipsec@TIS.COM>; Sun, 11 Aug 1996 17:49:03 -0400 (EDT)
Date: Sun, 11 Aug 96 21:37:26 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5409.wsimpson@greendragon.com>
To: iesg@ietf.org
Cc: ipsec@TIS.COM
Subject: Re: Last Call: HMAC-IP (Truncated HMAC-SHA)
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I had proposed shortening the length of the SHA output last winter.
However, there was strong consensus on the ipsec-dev list that multiple
lengths be supported. And thus, the language in draft-simpson-ah-sha-
kdp-00.txt. I urge these authors to insert this facility in their draft:
Therefore, several options are available for data alignment (most
preferred to least preferred):
1) only the most significant 128-bits (16 octets) of output are used.
2) an additional 32-bits (4 octets) of padding is added before the
SHA1 output.
3) an additional 32-bits (4 octets) of padding is added after the
SHA1 output.
4) the SHA1 output is variably bit-positioned within 192-bits (24
octets).
The size and position of the output are negotiated as part of the key
management. Padding bits are filled with unspecified implementation
dependent (random) values, which are ignored on receipt.
Discussion:
Although truncation of the output for alignment purposes may
appear to reduce the effectiveness of the algorithm, some analysts
of attack verification suggest that this may instead improve the
overall robustness [PO95a].
...
[PO95a] Preneel, B., and van Oorshot, P., "MDx-MAC and Building Fast
MACs from Hash Functions", Advances in Cryptology -- Crypto
'95 Proceedings, Santa Barbara, California, August 1995.
> Date: Fri, 9 Aug 1996 23:37:23 +0200 (METDST)
> From: Bart Preneel <Bart.Preneel@esat.kuleuven.ac.be>
> I would not even see a problem to shorten the SHA-1 output to
> 64 bits. When considering attack scenarios, I would be much more
> worried about an attacker who uses the known text-MAC pairs to
> obtain information on the key than about an attacker who tries to
> predict some bits to forge a MAC for two reasons:
> - a key recovery is more serious than a forgery
> - for concrete hash functions such as MD5 and SHA-1, I feel
> that the first attack is more likely (just intuition).
>
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Received: from relay.hq.tis.com by neptune.TIS.COM id aa04923;
12 Aug 96 7:35 EDT
Received: by relay.hq.tis.com; id HAA12073; Mon, 12 Aug 1996 07:38:34 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012070; Mon, 12 Aug 96 07:38:07 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01841; Mon, 12 Aug 96 07:37:31 EDT
Received: by relay.hq.tis.com; id HAA12065; Mon, 12 Aug 1996 07:38:04 -0400
Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.tis.com via smap (V3.1.1)
id xma012059; Mon, 12 Aug 96 07:37:34 -0400
Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1)
id AA07014; Mon, 12 Aug 96 07:39:40 EDT
Date: Mon, 12 Aug 96 07:39:40 EDT
From: "Mark S. Schneider" <mss@tycho.ncsc.mil>
Message-Id: <9608121139.AA07014@tarius.tycho.ncsc.mil>
To: naganand@ftp.com
Subject: Re: Comments on ISAKMP/Oakley
Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil, mjs@terisa.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From: Naganand Doraswamy <naganand@ftp.com>
>
> These are mostly implemetation type comments:
>
> 2.4.1. Security Association Payload
> Is the "Payload Length" field *really* supposed to be specified in
> four-octet units, or should it be in octets as all the other payloads
> are?
>
I believe it should be in octets. It seems unlikely that a SA payload
will ever be large enough to require a length in 4-octet units.
>
> A.6.1. Attribute Value Assigned Numbers, IPSEC ESP
> TLV constructs: how long is "Type"? How long is "Length"? Is "Length"
> in terms of octets, or some other unit? Are the lengths of "Type" and
> "Length" included in "Length" or not?
1 2 3
TLV = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Tag/Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value/Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Length is the length of the Value/Data *only* in the TLV.
>
> Where is "Multiple Precision Integer" specified?
>
It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D.
>
> A.7.1 The basic proposal format does has the following fields defined in the
> header:
> - Proposal #, Proposal Len, Protocol # and Attribute TLV's
> However, the ESP, AH, and ISAKMP proposals have defined the
> Transforms ID's and a reserved field. Shouldnt the basic proposal
> format take care of this as well?
Yes. I guess we intended that the TLV could be used for the Transform
ID. Granted, that would take 8 octets. Are you suggesting adding a
Transform ID field to the Proposal #, Proposal Len, and Protocol #
fields? If so, how do you think this should be done? Reducing the
size of the Protocol # field? Your thoughts are appreciated.
>
> A.7.4. Proposal Formats, ISAKMP: ???
>
Section A.7.4. is intended to describe the confidentiality and authentication
mechanisms that are internal to ISAKMP and used to provide Phase I security.
Confidentiality will be provided by applying the IPsec ESP transform(s) to
ISAKMP messages. Authentication can also use IPsec AH transforms, only if
keys have been preplaced. This means we have to determine a public key
mechanism for authentication. We're working on this.
>
> A.8.1. Security Association Payload Format
> Does the Situation field length need to be an integral multiple of
> four octets, as the Proposal field needs to be? Is the Situation Length
> field (Figure 20) specified as octets, four-octet units, or ... ?
>
It should be specified as the size in octets.
> draft-ietf-ipsec-isakmp-oakley-00.txt
> Where are ISAKMP exchange numbers defined for the various Oakley modes?
They currently aren't defined in the ISAKMP draft. In the next version,
I assume they will be assigned exchange numbers 4-7.
> What happens to the Base, Identity Protection, and Authentication Only
> exchanges defined in the ISAKMP draft? How does one implemement the other
> exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley is
> the only supported key exchange and is there any need to implement the basic
> ISAKMP modes if one is supporting only key exchange for IPSEC?
We see ISAKMP as a framework that permits negotiation of many security
features, including the key exchange mechanism. The exchange types
defined by the ISAKMP/Oakley resolution draft all have a defined key
exchange. In this case the key exchange is not negotiable. To support
negotiation of key exchange mechanisms, the three exchange types defined
in ISAKMP are *required*. If they didn't exist, then it would be
impossible to negotiatiate key exchange mechanisms.
Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges,
a generalization of the Oakley modes can be made in the ISAKMP draft. Since,
as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect
exchange, then it seems that Oakley Aggressive, Quick, and New Group
modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only
exchanges. The proposal could then include Oakley as the key exchange
mechanism along with the specific Oakley group that should be used.
Thoughts on this??
> 5.1 Oakley Main Mode
> Oakley Main Mode looks a lot like the Identity Protection exchange from
> the ISAKMP draft, except that the Envelope is missing in all transactions,
> a Nonce is added to the third and fourth messages, and the placement of
> the optional Certificate relative to the Signature in the fifth and sixth
> messages is reversed. Can these two exchanges be merged somehow?
Actually, I think the two should look identical. ISAKMP is missing nonces
for "freshness". We also feel the envelope payload should be standardized
in all messages: i.e. always used for consistency purposes. They can't
be merged as the Oakley key exchange is required in Oakley Main Mode and
not required in ISAKMP's ID Protect Mode.
> Thanks,
> -- Shawn Mamros and Naganand Doraswamy
Regards,
Mark Schneider
Received: from relay.hq.tis.com by neptune.TIS.COM id aa11693;
12 Aug 96 13:13 EDT
Received: by relay.hq.tis.com; id NAA22473; Mon, 12 Aug 1996 13:16:39 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma022465; Mon, 12 Aug 96 13:16:12 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA20539; Mon, 12 Aug 96 13:15:36 EDT
Received: by relay.hq.tis.com; id NAA22459; Mon, 12 Aug 1996 13:16:09 -0400
Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1)
id xma022448; Mon, 12 Aug 96 13:15:47 -0400
Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id KAA30687; Mon, 12 Aug 1996 10:03:48 -0700
X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs
Date: Mon, 12 Aug 1996 10:03:46 -0700 (MST)
From: Oliver Spatscheck <spatsch@cs.arizona.edu>
To: "Mark S. Schneider" <mss@tycho.ncsc.mil>
Cc: naganand@ftp.com, ipsec@TIS.COM, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil,
mjs@terisa.com
Subject: Re: Comments on ISAKMP/Oakley
In-Reply-To: <9608121139.AA07014@tarius.tycho.ncsc.mil>
Message-Id: <Pine.LNX.3.94.960812095207.30099B-100000@P-spatsch.cs.arizona.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 12 Aug 1996, Mark S. Schneider wrote:
>
> We see ISAKMP as a framework that permits negotiation of many security
> features, including the key exchange mechanism. The exchange types
> defined by the ISAKMP/Oakley resolution draft all have a defined key
> exchange. In this case the key exchange is not negotiable. To support
> negotiation of key exchange mechanisms, the three exchange types defined
> in ISAKMP are *required*. If they didn't exist, then it would be
> impossible to negotiatiate key exchange mechanisms.
>
> Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges,
> a generalization of the Oakley modes can be made in the ISAKMP draft. Since,
> as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect
> exchange, then it seems that Oakley Aggressive, Quick, and New Group
> modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only
> exchanges. The proposal could then include Oakley as the key exchange
> mechanism along with the specific Oakley group that should be used.
> Thoughts on this??
>
>
I completely agree. I also think the ISAKMP proposal fits the Oakley
requirements. Actually the way I am implementing ISAKMP/Oakley
currently uses the ISAKMP proposal with the Oakley KEI.
I made this decision since the payload formats in the current Oakley
draft don't match the current ISAKMP draft(In the hope that my
implementation will be close to the final standard).
Oliver
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBMg9j8znVPgUZ7uZJAQGxLwQAsnhP2jH8YS/ASD6daaxui9/lIWCkUbiJ
BSSyz/L2AJNfWa/K4xNVXn40CTs8orCsnGKqUwTwPZIBRciAZBanzn7YHOZ5b4Km
m5752x3ch1rOPYsjHHwi8xnOfSd0GyYTpAK61xwnCld2bx3oCLr9e++9C1PyfB0l
xV2G23Pg5Rk=
=UslG
-----END PGP SIGNATURE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa16453;
12 Aug 96 19:02 EDT
Received: by relay.hq.tis.com; id TAA03134; Mon, 12 Aug 1996 19:05:08 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma003127; Mon, 12 Aug 96 19:04:39 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11477; Mon, 12 Aug 96 19:04:03 EDT
Received: by relay.hq.tis.com; id TAA03121; Mon, 12 Aug 1996 19:04:38 -0400
Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1)
id xma003118; Mon, 12 Aug 96 19:04:11 -0400
Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id TAA23036; Mon, 12 Aug 1996 19:11:18 -0400 (EDT)
X-Sender: kent@po1.bbn.com
Message-Id: <v02130509ae356852519e@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 Aug 1996 19:07:30 -0400
To: Marcel Waldvogel <mwa@tik.ee.ethz.ch>
From: Stephen Kent <kent@bbn.com>
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
Cc: Naganand Doraswamy <naganand@ftp.com>, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Marcel,
Our plans for re-writing the ESP and AH specs will avoid the need
to document the combinatorial set of transforms. Instead, it will be
possible to define the algorithms or transform elements via distinct RFCs.
The ESP and AH specs will be upgraded to define formats for all of the
optional fields required by the different transforms.
None of this avoids the complexity that comes with implementing
various subsets of the transforms. However, moving transforms into
separate protocols arguably does not avoid this complexity either. At the
last meeting we also decided to address this problem, in part, by
registering allowed combinations of transforms through the IANA (after WG
approval), as a means of identifying allowed combinations. Still, the WG
needs to evaluate the attractiveness of various combinations and pass
judgement on them; that is the ultimate means of keeping the complexity
level manageable.
Steve
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24428;
13 Aug 96 10:52 EDT
Received: by relay.hq.tis.com; id KAA13011; Tue, 13 Aug 1996 10:55:30 -0400
From: pau@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma013004; Tue, 13 Aug 96 10:55:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA02814; Tue, 13 Aug 96 10:54:28 EDT
Received: by relay.hq.tis.com; id KAA12984; Tue, 13 Aug 1996 10:54:54 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1)
id xma012979; Tue, 13 Aug 96 10:54:46 -0400
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id KAA08755; Tue, 13 Aug 1996 10:56:21 -0400
Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/08-11-96) with SMTP id KAA61845; Tue, 13 Aug 1996 10:55:44 -0400
Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03)
id AA22570; Tue, 13 Aug 1996 10:55:48 -0400
Date: Tue, 13 Aug 1996 10:55:48 -0400
Message-Id: <9608131455.AA22570@secpwr.watson.ibm.com>
To: mss@tycho.ncsc.mil
Subject: Re: Comments on ISAKMP/Oakley
Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil, mjs@terisa.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Md5: YxdKgByZ+/O/xjsdiqeYrQ==
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From ipsec-request@neptune.hq.tis.com Mon Aug 12 10:46:16 1996
> Date: Mon, 12 Aug 96 07:39:40 EDT
> From: "Mark S. Schneider" <mss@tycho.ncsc.mil>
> Message-Id: <9608121139.AA07014@tarius.tycho.ncsc.mil>
> To: naganand@ftp.com
> Subject: Re: Comments on ISAKMP/Oakley
> Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, =
sjt@tycho.ncsc.mil,
mjs@terisa.com
> Sender: ipsec-approval@neptune.hq.tis.com
> Precedence: bulk
> Content-Length: 5367
> Status: RO
.........
.
>=20
> >=20
> > A.6.1. Attribute Value Assigned Numbers, IPSEC ESP
> > TLV constructs: how long is "Type"? How long is "Length"? Is =
"Length"
> > in terms of octets, or some other unit? Are the lengths of =
"Type" and
> > "Length" included in "Length" or not?
>=20
> 1 2 3
> TLV =3D 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =
0 1
> =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ! Tag/Type ! Length =
=
!
> =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ~ Value/Data =
=
~
> =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> Where Length is the length of the Value/Data *only* in the TLV.
Mark, are the values of "tag" and their associate data defined any where =
?
........................
>=20
> > Where are ISAKMP exchange numbers defined for the various Oakley =
modes?
>=20
> They currently aren't defined in the ISAKMP draft. In the next =
version,
> I assume they will be assigned exchange numbers 4-7.
>=20
> > What happens to the Base, Identity Protection, and Authentication =
Only
> > exchanges defined in the ISAKMP draft? How does one implemement the =
other
> > exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley =
is
> > the only supported key exchange and is there any need to implement =
the basic
> > ISAKMP modes if one is supporting only key exchange for IPSEC?
>=20
>=20
> We see ISAKMP as a framework that permits negotiation of many =
security
> features, including the key exchange mechanism. The exchange types
> defined by the ISAKMP/Oakley resolution draft all have a defined key
> exchange. In this case the key exchange is not negotiable. To =
support
> negotiation of key exchange mechanisms, the three exchange types =
defined
> in ISAKMP are *required*. If they didn't exist, then it would be =20
> impossible to negotiatiate key exchange mechanisms.
>=20
> Actually, upon looking closer at the ISAKMP exchanges and Oakley =
exchanges,
> a generalization of the Oakley modes can be made in the ISAKMP =
draft. Since,
> as you note below, Oakley Main Mode is equivalent to ISAKMP's ID =
Protect
> exchange, then it seems that Oakley Aggressive, Quick, and New Group
> modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA =
Only
=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> exchanges. The proposal could then include Oakley as the key =
exchange
> mechanism along with the specific Oakley group that should be used.=20
> Thoughts on this??
Mark, I am confused by your answer. If Key Exchange Protocol is meant =
to
be nogotiated (which I think is a good idea), why not put Oakley in =
the
proposal part of a ISAKMP base exchange ? I mean, is there a need to=20
define exhcnage numbers for Oakley ? There are only twelve unused =
values
for the 4-bit "exchane" field. I think the values should be reserved =
for
some very different flows of messages.
=20
Also, I don't see draft 5 mentioning ISAKMP Aggressive, Quick, and SA =
Only
exchanges. Am I missing something ?
>=20
.....................
>=20
>=20
> Regards,
> Mark Schneider
>=20
=20
Thank you.
Regards, Pau-Chen
Received: from relay.hq.tis.com by neptune.TIS.COM id aa27579;
13 Aug 96 15:29 EDT
Received: by relay.hq.tis.com; id PAA23692; Tue, 13 Aug 1996 15:32:26 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma023683; Tue, 13 Aug 96 15:32:03 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19466; Tue, 13 Aug 96 15:31:23 EDT
Received: by relay.hq.tis.com; id PAA23671; Tue, 13 Aug 1996 15:31:57 -0400
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1)
id xma023662; Tue, 13 Aug 96 15:31:41 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id MAA11630 for ipsec@tis.com; Tue, 13 Aug 1996 12:33:57 -0700
Message-Id: <199608131933.MAA11630@puli.cisco.com>
From: Ran Atkinson <rja@cisco.com>
Date: Tue, 13 Aug 1996 12:33:56 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: ipsec@TIS.COM
Subject: PF_KEY paper
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The PF_KEY paper by Dan McDonald that was presented at INET'96 in
Montreal last June is available online in Postscript from:
http://tonnant.itd.nrl.navy.mil/PF_KEY.ps
The NRL IPsec software for BSD is an example of an implementation of PF_KEY.
I hope to see a PF_KEY I-D appear online in the near future. I believe
there is an effort underway to create such an I-D based on both the NRL PF_KEY
API and also on the similar PF_SADB API of the NIST/NCSC IPsec code.
Ran
rja@inet.org
--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28686;
13 Aug 96 16:59 EDT
Received: by relay.hq.tis.com; id RAA27695; Tue, 13 Aug 1996 17:02:57 -0400
From: pau@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma027692; Tue, 13 Aug 96 17:02:36 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA27944; Tue, 13 Aug 96 17:01:53 EDT
Received: by relay.hq.tis.com; id RAA27689; Tue, 13 Aug 1996 17:02:27 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1)
id xma027687; Tue, 13 Aug 96 17:02:18 -0400
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id RAA20601; Tue, 13 Aug 1996 17:05:08 -0400
Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id RAA121205; Tue, 13 Aug 1996 17:04:30 -0400
Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03)
id AA22698; Tue, 13 Aug 1996 17:04:30 -0400
Date: Tue, 13 Aug 1996 17:04:30 -0400
Message-Id: <9608132104.AA22698@secpwr.watson.ibm.com>
Subject: Re: Comments on ISAKMP/Oakley
To: mss@tycho.ncsc.mil
Cc: ipsec@TIS.COM, mjs@terisa.com, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Md5: rpLAtYeX9q3nfYV6oLCHag==
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Subject: Re: Comments on ISAKMP/Oakley
> Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, =
sjt@tycho.ncsc.mil,
mjs@terisa.com
> Sender: ipsec-approval@neptune.hq.tis.com
> Precedence: bulk
> Content-Length: 5367
> Status: RO
.........
.
>=20
> >=20
> > A.6.1. Attribute Value Assigned Numbers, IPSEC ESP
> > TLV constructs: how long is "Type"? How long is "Length"? Is =
"Length"
> > in terms of octets, or some other unit? Are the lengths of =
"Type" and
> > "Length" included in "Length" or not?
>=20
> 1 2 3
> TLV =3D 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =
0 1
> =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ! Tag/Type ! Length =
=
!
> =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ~ Value/Data =
=
~
> =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> Where Length is the length of the Value/Data *only* in the TLV.
Mark, are the values of "tag" and their associate data defined any where =
?
........................
>=20
> > Where are ISAKMP exchange numbers defined for the various Oakley =
modes?
>=20
> They currently aren't defined in the ISAKMP draft. In the next =
version,
> I assume they will be assigned exchange numbers 4-7.
>=20
> > What happens to the Base, Identity Protection, and Authentication =
Only
> > exchanges defined in the ISAKMP draft? How does one implemement the =
other
> > exchanges (which are defined as MUSTs in the ISAKMP draft) if Oakley =
is
> > the only supported key exchange and is there any need to implement =
the basic
> > ISAKMP modes if one is supporting only key exchange for IPSEC?
>=20
>=20
> We see ISAKMP as a framework that permits negotiation of many =
security
> features, including the key exchange mechanism. The exchange types
> defined by the ISAKMP/Oakley resolution draft all have a defined key
> exchange. In this case the key exchange is not negotiable. To =
support
> negotiation of key exchange mechanisms, the three exchange types =
defined
> in ISAKMP are *required*. If they didn't exist, then it would be =20
> impossible to negotiatiate key exchange mechanisms.
>=20
> Actually, upon looking closer at the ISAKMP exchanges and Oakley =
exchanges,
> a generalization of the Oakley modes can be made in the ISAKMP =
draft. Since,
> as you note below, Oakley Main Mode is equivalent to ISAKMP's ID =
Protect
> exchange, then it seems that Oakley Aggressive, Quick, and New Group
> modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA =
Only
=
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> exchanges. The proposal could then include Oakley as the key =
exchange
> mechanism along with the specific Oakley group that should be used.=20
> Thoughts on this??
Mark, I am confused by your answer. If Key Exchange Protocol is meant =
to
be nogotiated (which I think is a good idea), why not put Oakley in =
the
proposal part of a ISAKMP base exchange ? I mean, is there a need to=20
define exhcnage numbers for Oakley ? There are only twelve unused =
values
for the 4-bit "exchane" field. I think the values should be reserved =
for
some very different flows of messages.
=20
Also, I don't see draft 5 mentioning ISAKMP Aggressive, Quick, and SA =
Only
exchanges. Am I missing something ?
>=20
.....................
>=20
>=20
> Regards,
> Mark Schneider
>=20
=20
Thank you.
Regards, Pau-Chen=20
------------- End Forwarded Message -------------
Received: from relay.hq.tis.com by neptune.TIS.COM id aa01348;
13 Aug 96 21:28 EDT
Received: by relay.hq.tis.com; id VAA02319; Tue, 13 Aug 1996 21:31:33 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma002312; Tue, 13 Aug 96 21:31:14 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA05740; Tue, 13 Aug 96 21:30:28 EDT
Received: by relay.hq.tis.com; id VAA02304; Tue, 13 Aug 1996 21:31:04 -0400
Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1)
id xma002296; Tue, 13 Aug 96 21:30:37 -0400
Received: from mailsun2.us.oracle.com by inet-user-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id SAA06194; Tue, 13 Aug 1996 18:32:17 -0700
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id SAA15815; Tue, 13 Aug 1996 18:30:13 -0700
Message-Id: <199608140130.SAA15815@mailsun2.us.oracle.com>
Date: 13 Aug 96 18:24:13 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: "Re: DNS? was Re: Key Management, anyone?"
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-approval@neptune.hq.tis.com's message of 07-Aug-96 23:03
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.2.0.35)
Content-Type: multipart/mixed; boundary="=_ORCL_6501180_0_11919608131931140"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_6501180_0_11919608131931140
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
Hilarie,
On you assertion:
>Clarified Assertion:
>The minimal basis for authentication is the association
>of a public key with an IP address. The minimal
>authentication chain is through DNS zone authorities.
I have always viewed the minimum information to be a "name"... Perhaps I'm
wrong, but your assertion provides clarity to the discussions and this an
issue that needs resolution. So ...
A Different Assertion:
The minimal basis for authentication is the association
of a public key with a name that can be used to support access control
decisions.
IP addresses may be dynamically assigned and are not as useful as "names" in
supporting end system security.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
--------------------------------------------------------------
--=_ORCL_6501180_0_11919608131931140
Content-Type:message/rfc822
Date: 07 Aug 96 23:03:02
From:"Hilarie Orman " <ipsec-approval@neptune.hq.tis.com>
To:mohta@necom830.hpcl.titech.ac.jp
Subject:Re: "Re: DNS? was Re: Key Management, anyone?"
Cc:ipsec@tis.com
X-Orcl-Application:Mmdf-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
X-Orcl-Application:In-Reply-To: Yourmessage <199608050227.TAA06242@baskerville.CS.Arizona.EDU>
X-Orcl-Application:Sender: ipsec-approval@neptune.hq.tis.com
X-Orcl-Application:Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
> Authentication for what?
Clarified Assertion:
The minimal basis for authentication is the association of a public key
with an IP address. The minimal authentication chain is through DNS
zone authorities.
This seems to me to be generally useful and meaningful mechanism for most
Internet purposes. If a site doesn't have an appropriate key entry, it
won't be able participate in ordinary authenticated services --- sort of like
not having a valid IP address would invalidate it as an Internet member.
So, why is this wrong?
--=_ORCL_6501180_0_11919608131931140--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09535;
14 Aug 96 13:29 EDT
Received: by relay.hq.tis.com; id NAA24884; Wed, 14 Aug 1996 13:32:32 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma024872; Wed, 14 Aug 96 13:32:03 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19249; Wed, 14 Aug 96 13:31:25 EDT
Received: by relay.hq.tis.com; id NAA24869; Wed, 14 Aug 1996 13:32:02 -0400
Received: from motgate2.mot.com(129.188.136.20) by relay.tis.com via smap (V3.1.1)
id xma024850; Wed, 14 Aug 96 13:31:37 -0400
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (8.7.3/8.6.10/MOT-3.8) with ESMTP id RAA25016 for <ipsec@tis.com>; Wed, 14 Aug 1996 17:30:48 GMT
Received: from ilbx.mot.com (ilbx.mot.com [129.188.137.185]) by pobox.mot.com (8.7.3/8.6.10/MOT-3.8) with SMTP id MAA23526 for <ipsec@tis.com>; Wed, 14 Aug 1996 12:33:47 -0500 (CDT)
Received: by ilbx.mot.com
(1.37.109.4/16.2) id AA15812; Wed, 14 Aug 96 12:33:46 -0500
Date: Wed, 14 Aug 1996 11:53:42 -0500
From: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>
Message-Id: <MSMAIL PC */PRMD=MOT/ADMD=MOT/C=US/@MHS>
Subject: Re: "Re: DNS? was Re: Key Management, an
To: ipsec@TIS.COM
X400-Mts-Identifier: [ /P=MOT/A=MOT/C=US/ ; m\gstmd\960814115342d ]
X-Mailer: Worldtalk (4.0.2-p15)/STREAM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Paul Lambert writes:
>Hilarie,
>
>On you assertion:
>
>>Clarified Assertion:
>>The minimal basis for authentication is the association
>>of a public key with an IP address. The minimal
>>authentication chain is through DNS zone authorities.
>
>I have always viewed the minimum information to be a "name"... Perhaps I'm
>wrong, but your assertion provides clarity to the discussions and this an
>issue that needs resolution. So ...
>
>A Different Assertion:
>
>The minimal basis for authentication is the association
>of a public key with a name that can be used to support access control
>decisions.
>
>IP addresses may be dynamically assigned and are not as useful as "names" in
>supporting end system security.
I have a problem with this as a basis for authentication also. If I am
"dialed-in" through my ISP, and receive a dynamic address, I don't have a DNS
entry, hostname, or otherwise. In fact, the only thing I really have is an e-
mail address. The question that really needs to be asked is:
"What am I authenticating:
a person,
a machine/host,
or a network entrypoint?
I can make a case for all three given different security policies, and
different security perspectives.
The personal authentication is intuitive (but I'll clarify anyway); a
particular application only allows named users and specific authenticated
users to access it's services (e.g. a library database server only wants
John Smith to have access - because he paid his bill - we don't want to
allow anyone from joesmidnightisp.com [John's ISP provider] to have
access).
Host authentication is most common (did I really get to host XYZ.ABC.COM ?).
This is the perspective of a client accessing a server. Can I be sure that
the newest beta version of Netscape I just downloaded is from the
Netscape server?
Network entrypoint authentication is the opposite perspective. The host
wants authentication of the origin of access. It is common to restrict a
host to be accessed from only certain locations - we do this all the time
with network management using various techniques (called-back using modems
etc.)
What about the network manager that wants full access from home through his/
her ISP to correct network problems at 2 AM? We surely want VERY strong
authentication that this is really the network manager and not Bobby Hacker.
I don't have a really good a solution - I need to think about it some
more. Regardless, all types of authentication will be important, and neither
IP address nor hostname covers all three. Maybe the best thing to do is
say all three types of authentication will be handled by different
certificates.
Is it sufficient to say that authentication is based on an e-mail address
(personal), hostname, OR an IP address (network entrypoint)? Then the
application/service which is accepting the authenticated identity must
determine if this binding is sufficient authentication for the particular
activity/access/application?
Then the minimal basis for authentication is the association of a public key
with an e-mail address, a hostname, or an IP address that can be used to
support access control decisions.
Comments?
Dave Wheeler
Information Security Operations
Space and Systems Technology Group, Motorola
Scottsdale, Arizona
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13261;
14 Aug 96 19:51 EDT
Received: by relay.hq.tis.com; id TAA07032; Wed, 14 Aug 1996 19:54:23 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma007022; Wed, 14 Aug 96 19:53:56 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA09882; Wed, 14 Aug 96 19:53:18 EDT
Received: by relay.hq.tis.com; id TAA07010; Wed, 14 Aug 1996 19:53:54 -0400
Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1)
id xma007001; Wed, 14 Aug 96 19:53:41 -0400
Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id QAA08155; Wed, 14 Aug 1996 16:56:00 -0700 (PDT)
Message-Id: <199608142356.QAA08155@toad.com>
X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: ipsec@TIS.COM, gnu@toad.com
Subject: Re: DNS? was Key Management
Date: Wed, 14 Aug 1996 16:55:59 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
One of the problems that has hung up all sorts of crypto protocols is
getting confused about what problem you are trying to solve. Like PEM,
let's not define all the packet formats and then spend three years
arguing over who authenticates what to who.
> Then the minimal basis for authentication is the association of a public key
> with an e-mail address, a hostname, or an IP address that can be used to
> support access control decisions.
DNSSEC supports associating a public key (or several public keys) with
each of the above. IP addresses are encoded into the domain-name
space in the usual 1.2.174.140.in-addr.arpa way. Email addresses
are encoded as e.g. gnu.toad.com by setting a bit in the KEY record
which indicates that the first component refers to a user rather than
to a host or subdomain.
However, IPSEC only authenticates to IP addresses. There's no further
identification in the IPSEC packets. Even if usernames or hostnames
are used in generating keys, there's no well-defined way to get that
information back to an application; all it has is getpeername().
> Is it sufficient to say that authentication is based on an e-mail address
> (personal), hostname, OR an IP address (network entrypoint)? Then the
> application/service which is accepting the authenticated identity must
> determine if this binding is sufficient authentication for the particular
> activity/access/application?
I believe you meant "sufficient authorization".
IPSEC and DNSEEC do not solve this second problem (applications
deciding whether to accept authenticated identities). That's an
access control question (is he allowed?) as opposed to an identity
question (who is he?).
IPSEC doesn't solve the global "single signon" problem; don't expect
it to.
I may supply information to authenticate myself to other parts of the
network, and a firewall somewhere may use this information to decide
whether to let my packets in the door. But IPSEC running at FOO.COM
should be willing to build an encrypted tunnel to my laptop, whether
or not my laptop later ends up authenticated as "the laptop that
FOO.COM's system administrator borrowed while he was at a conference".
I also think we should focus on shipping standards that hit the sweet
spot (most gain for least pain), which includes securing communications
among all the hosts with fixed IP addresses. If dynamically assigned
IP addresses are easy, throw 'em in; if not, leave them for the next
round of standards. Since everyone seems to think they're hard,
let's leave them for next time, and secure the large fraction of
the Internet that we know how to do now.
John Gilmore
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14036;
14 Aug 96 21:29 EDT
Received: by relay.hq.tis.com; id VAA08293; Wed, 14 Aug 1996 21:32:53 -0400
From: wobber@pa.dec.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008291; Wed, 14 Aug 96 21:32:25 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA12014; Wed, 14 Aug 96 21:31:47 EDT
Received: by relay.hq.tis.com; id VAA08286; Wed, 14 Aug 1996 21:32:24 -0400
Received: from mail2.digital.com(204.123.2.56) by relay.tis.com via smap (V3.1.1)
id xma008282; Wed, 14 Aug 96 21:32:05 -0400
Received: from hickory.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA17448; Wed, 14 Aug 1996 18:27:12 -0700
Received: by hickory.pa.dec.com; id AA15906; Wed, 14 Aug 1996 18:27:07 -0700
Message-Id: <9608150127.AA15906@hickory.pa.dec.com>
To: John Gilmore <gnu@toad.com>
Cc: ipsec@TIS.COM
Subject: Re: DNS? was Key Management
In-Reply-To: Message of Wed, 14 Aug 1996 16:55:59 -0700
from John Gilmore <gnu@toad.com>
<199608142356.QAA08155@toad.com>
Date: Wed, 14 Aug 96 18:27:07 -0700
X-Mts: smtp
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>> However, IPSEC only authenticates to IP addresses. There's no further
>> identification in the IPSEC packets. Even if usernames or hostnames
>> are used in generating keys, there's no well-defined way to get that
>> information back to an application; all it has is getpeername().
Isn't it the case that IPSEC packets are bound to security associations,
and that security associations are sufficient to identify all sorts
of communicating entities (not just IP addresses)? If so, then the
proposed protocols should support authentication within multiple
namespaces/trust domains. The problem is how to standardize an appropriate
API for managing the security associations appurtenant to communications
channels.
While I agree that authentication of fixed IP addresses probably
constitutes a "sweet spot", it would be unfortunate if this ruled
out other forms of authentication appropriate to security-aware applications.
Regards,
Ted Wobber
DEC Systems Research Center
Received: from relay.hq.tis.com by neptune.TIS.COM id aa19411;
15 Aug 96 9:18 EDT
Received: by relay.hq.tis.com; id JAA20399; Thu, 15 Aug 1996 09:21:23 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma020397; Thu, 15 Aug 96 09:20:56 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01579; Thu, 15 Aug 96 09:20:17 EDT
Received: by relay.hq.tis.com; id JAA20388; Thu, 15 Aug 1996 09:20:54 -0400
Received: from ietf.org(132.151.1.19) by relay.tis.com via smap (V3.1.1)
id xma020375; Thu, 15 Aug 96 09:20:33 -0400
Received: from localhost by ietf.org id aa01666; 15 Aug 96 9:16 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-skip-07.txt
Date: Thu, 15 Aug 1996 09:16:15 -0400
Message-Id: <9608150916.aa01666@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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 : Simple Key-Management For Internet Protocols (SKIP)
Author(s) : A. Aziz, T. Markson, H. Prafullchandra
Filename : draft-ietf-ipsec-skip-07.txt
Pages : 34
Date : 08/14/1996
There are occasions where it is advantageous to put authenticity and
privacy features at the network layer. The vast majority of the privacy and
authentication protocols in the literature deal with session oriented
key-management schemes. However, many of the commonly used network layer
protocols (for example, IPv4 and IPv6) are session-less datagram oriented
protocols. We describe a key-management scheme that is particularly well
suited for use in conjunction with a session-less datagram protocol like
IPv4 or IPv6.
SKIP has been designed to work with the IP Security Protocols AH and ESP
[8, 9, 10] which are specified for both IPv4 and IPv6.
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-skip-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-skip-07.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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960814144020.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-skip-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-skip-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960814144020.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa20437;
15 Aug 96 10:59 EDT
Received: by relay.hq.tis.com; id LAA23812; Thu, 15 Aug 1996 11:02:53 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma023788; Thu, 15 Aug 96 11:02:25 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA07120; Thu, 15 Aug 96 11:01:44 EDT
Received: by relay.hq.tis.com; id LAA23777; Thu, 15 Aug 1996 11:02:21 -0400
Received: from ns.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma023768; Thu, 15 Aug 96 11:02:10 -0400
Received: by janus.border.com id <18446-1>; Thu, 15 Aug 1996 11:04:05 -0400
Message-Id: <96Aug15.110405edt.18446-1@janus.border.com>
To: John Gilmore <gnu@toad.com>
Cc: ipsec@TIS.COM
Subject: Re: DNS? was Key Management
References: <199608142356.QAA08155@toad.com>
In-Reply-To: Your message of "Wed, 14 Aug 1996 19:55:59 -0400".
<199608142356.QAA08155@toad.com>
From: "C. Harald Koch" <chk@border.com>
Date: Thu, 15 Aug 1996 11:04:12 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <199608142356.QAA08155@toad.com>, John Gilmore writes:
>
> However, IPSEC only authenticates to IP addresses. There's no further
> identification in the IPSEC packets. Even if usernames or hostnames
> are used in generating keys, there's no well-defined way to get that
> information back to an application; all it has is getpeername().
Since when? It was my understanding that IPsec authenticated to the nebulous
concept of a "key owner", which could be a single user, a host, or even a
set of hosts (say, behind a crypto-gateway?).
As for authorization, the most common use I see for IPsec, in the short
term, is to secure 'standard' A&A techniques (such as OTP, challenge
response cards, etc.) from network-layer based attacks. After all, if I can
trust that a TCP session has not been tampered with, then I can make
stronger trust decisions about OTP or token based authentication of the user
at the end of the tunnel, right?
--
Harald Koch
chk@border.com
Received: from relay.hq.tis.com by neptune.TIS.COM id aa20808;
15 Aug 96 11:27 EDT
Received: by relay.hq.tis.com; id LAA24610; Thu, 15 Aug 1996 11:30:51 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma024601; Thu, 15 Aug 96 11:30:26 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA08690; Thu, 15 Aug 96 11:29:46 EDT
Received: by relay.hq.tis.com; id LAA24596; Thu, 15 Aug 1996 11:30:21 -0400
Received: from dg-webo.us.dg.com(128.221.131.1) by relay.tis.com via smap (V3.1.1)
id xma024590; Thu, 15 Aug 96 11:30:07 -0400
Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1)
id AA24618; Thu, 15 Aug 1996 11:31:23 -0400
Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08)
id AA17325; Thu, 15 Aug 1996 11:31:22 -0400
Message-Id: <9608151531.AA17325@wellspring.us.dg.com>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 11:31:03 -0400
To: ipsec@TIS.COM
From: Rodney Thayer <rodney@sabletech.com>
Subject: ...draft ...*skip*...
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Excuse me but what's the status of the "what key management scheme are we
agreeing upon" process?
If SKIP is it than this is nice.
IF SKIP isn't it then what is this? (I mean, it's a free internet but that
would mean the filename didn't start with "draft-ietf-...")
Attention SKIP people: this message is *not* meant in any way to be
derogatory towards SKIP, I'm just confused and your email was in my hand
when I decided it was time to say something.
>To: IETF-Announce:;, tis.com@TIS.COM
>MMDF-Warning: Parse error in original version of preceding line at
neptune.TIS.COM
>Cc: ipsec@TIS.COM
>From: Internet-Drafts@ietf.org
>Reply-To: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-ietf-ipsec-skip-07.txt
>Date: Thu, 15 Aug 1996 09:16:15 -0400
>Sender: ipsec-approval@neptune.hq.tis.com
>
>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 : Simple Key-Management For Internet Protocols (SKIP)
> Author(s) : A. Aziz, T. Markson, H. Prafullchandra
> Filename : draft-ietf-ipsec-skip-07.txt
> Pages : 34
> Date : 08/14/1996
>
>There are occasions where it is advantageous to put authenticity and
>privacy features at the network layer. The vast majority of the privacy and
>authentication protocols in the literature deal with session oriented
>key-management schemes. However, many of the commonly used network layer
>protocols (for example, IPv4 and IPv6) are session-less datagram oriented
>protocols. We describe a key-management scheme that is particularly well
>suited for use in conjunction with a session-less datagram protocol like
>IPv4 or IPv6.
>
>SKIP has been designed to work with the IP Security Protocols AH and ESP
>[8, 9, 10] which are specified for both IPv4 and IPv6.
>
>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-skip-07.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-skip-07.txt
>
>Internet-Drafts directories are located at:
>
> o Africa
> Address: ftp.is.co.za (196.4.160.8)
>
> o Europe
> Address: nic.nordu.net (192.36.148.17)
> Address: ftp.nis.garr.it (193.205.245.10)
>
> o Pacific Rim
> Address: munnari.oz.au (128.250.1.21)
>
> o US East Coast
> Address: ds.internic.net (198.49.45.10)
>
> o US West Coast
> Address: ftp.isi.edu (128.9.0.32)
>
>Internet-Drafts are also available by mail.
>
>Send a message to: mailserv@ds.internic.net. In the body type:
> "FILE /internet-drafts/draft-ietf-ipsec-skip-07.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.
>
>For questions, please mail to Internet-Drafts@ietf.org
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version
>of the Internet-Draft.
>Content-Type: text/plain
>Content-ID: <19960814144020.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ipsec-skip-07.txt
>Content-Type: text/plain
>Content-ID: <19960814144020.I-D@ietf.org>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21547;
15 Aug 96 12:18 EDT
Received: by relay.hq.tis.com; id MAA26512; Thu, 15 Aug 1996 12:21:43 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma026498; Thu, 15 Aug 96 12:21:15 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA12476; Thu, 15 Aug 96 12:20:36 EDT
Received: by relay.hq.tis.com; id MAA26491; Thu, 15 Aug 1996 12:21:13 -0400
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1)
id xma026484; Thu, 15 Aug 96 12:21:10 -0400
Received: from ftp.com by ftp.com ; Thu, 15 Aug 1996 12:23:23 -0400
Received: from athena.ftp.com by ftp.com ; Thu, 15 Aug 1996 12:23:23 -0400
Message-Id: <2.2.32.19960815162824.00ae9794@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 12:28:24 -0400
To: "Mark S. Schneider" <mss@tycho.ncsc.mil>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: Comments on ISAKMP/Oakley
Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil, mjs@terisa.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>>
>> Where is "Multiple Precision Integer" specified?
>>
>
> It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D.
>
For completeness, I suggest that you atleast mention where to look for the
definition of multiple precision integer, or just add it in appendix in the
draft.
>>
>> A.7.1 The basic proposal format does has the following fields defined in the
>> header:
>> - Proposal #, Proposal Len, Protocol # and Attribute TLV's
>> However, the ESP, AH, and ISAKMP proposals have defined the
>> Transforms ID's and a reserved field. Shouldnt the basic proposal
>> format take care of this as well?
>
> Yes. I guess we intended that the TLV could be used for the Transform
> ID. Granted, that would take 8 octets. Are you suggesting adding a
> Transform ID field to the Proposal #, Proposal Len, and Protocol #
> fields? If so, how do you think this should be done? Reducing the
> size of the Protocol # field? Your thoughts are appreciated.
>>
I think we could reduce the protocol field size to one octet. Almost all the
protocols I have seen have only one octet allocated for protocol ID and I
feel it is safe to allocate one byte and use the other octet for transform
ID, unless other people feel strongly against this.
>> A.7.4. Proposal Formats, ISAKMP: ???
>>
>
>Section A.7.4. is intended to describe the confidentiality and authentication
>mechanisms that are internal to ISAKMP and used to provide Phase I security.
>Confidentiality will be provided by applying the IPsec ESP transform(s) to
>ISAKMP messages. Authentication can also use IPsec AH transforms, only if
>keys have been preplaced. This means we have to determine a public key
>mechanism for authentication. We're working on this.
>
>
How does one obtain the keys for ESP transform on Phase I ISAKMP messages?
Is it an out of band mechanism or are the keys derived based on some public
key mechanism?
> We see ISAKMP as a framework that permits negotiation of many security
> features, including the key exchange mechanism. The exchange types
> defined by the ISAKMP/Oakley resolution draft all have a defined key
> exchange. In this case the key exchange is not negotiable. To support
> negotiation of key exchange mechanisms, the three exchange types defined
> in ISAKMP are *required*. If they didn't exist, then it would be
> impossible to negotiatiate key exchange mechanisms.
>
> Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges,
> a generalization of the Oakley modes can be made in the ISAKMP draft. Since,
> as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect
> exchange, then it seems that Oakley Aggressive, Quick, and New Group
> modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only
> exchanges. The proposal could then include Oakley as the key exchange
> mechanism along with the specific Oakley group that should be used.
> Thoughts on this??
>
>
This will help a lot as the number of protocol formats one needs to
implement will be fewer. Also, as ISAKMP is a general mechanism, as it is
already doing, there should be more protocol exhance modes defined so that
it can support various key exchange mechanisms. That is the reason why I
like the idea of trying to fit Oakley key exchange mechanisms within the
available ISAKMP modes rahter than defining new modes for the basic modes.
This way we a new key exchange mechanism is added we dont end up adding
another "n" xchg types to the ISAKMP headers and we may soon run out of
these 4 bits!
I have a few questions on Modify payload.
- How does one send a Modify payload. Do I use the reserved XCHG to send
this message? Is so, dont I need some kind of verfication? The same argument
is true even for the Delete payload.
- When I send a modify message do I create a new SPI or modify the
attributes of the existing SA? For example, say between two machines A and B
I have an SA established. On A I want B to use a different transform, then I
will send a Modify message to B with the SPI B was using to send secure
messages to A in the SPI field of the Modify payload. In addition to that I
will also send a SA payload. Does the auxillary SPI field in the SA payload
point to a new SPI or can I reuse the old one? If I reuse the old one, how
will I handle the packets that are sent from B to A in the window where the
Modify message that A sent has still not reached B and A has already modify
it's SA?
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21795;
15 Aug 96 12:35 EDT
Received: by relay.hq.tis.com; id MAA26982; Thu, 15 Aug 1996 12:38:13 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma026966; Thu, 15 Aug 96 12:37:50 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14268; Thu, 15 Aug 96 12:37:11 EDT
Received: by relay.hq.tis.com; id MAA26952; Thu, 15 Aug 1996 12:37:46 -0400
Received: from raptor.com(204.7.243.11) by relay.tis.com via smap (V3.1.1)
id xma026937; Thu, 15 Aug 96 12:37:23 -0400
Received: from raptor1.raptor.com ([204.7.242.10]) by eagle1.raptor.com
via smtpd (for relay.hq.tis.com [192.94.214.100]) with SMTP; 15 Aug 1996 16:39:22 UT
Received: from Joe_Tardo.raptor.com (pool030.Max20.San-Francisco.CA.DYNIP.ALTER.NET [153.37.20.94]) by raptor1.raptor.com (8.7.3/8.7.3) with SMTP id MAA19969; Thu, 15 Aug 1996 12:38:54 -0400 (EDT)
Message-Id: <2.2.32.19960815163912.006f75f4@204.7.242.10>
X-Sender: jtardo@204.7.242.10
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 09:39:12 -0700
To: John Gilmore <gnu@toad.com>
From: Joe Tardo <tardo@raptor.com>
Subject: Re: DNS? was Key Management
Cc: ipsec@TIS.COM, wobber@pa.dec.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 04:55 PM 8/14/96 -0700, John Gilmore wrote:
>However, IPSEC only authenticates to IP addresses. There's no further
>identification in the IPSEC packets. Even if usernames or hostnames
>are used in generating keys, there's no well-defined way to get that
>information back to an application; all it has is getpeername().
As Ted points out, IPSEC packets are bound to SA's, and that's where
the actual authenticated identity is, not in ESP or AH packets.
While true that the ISAKMP Internet DOI as defined in the NSA draft
only uses ip addresses and FQDN's for identifiers, these are really
needed to identify SA endpoints (hosts and subnetworks), especially
for proxy netotiation. They are not necessarily the only means for
identifying the authenticated "entity" that will be using that SA.
Even if shortcomings such as this in the current draft remained,
identities can still be passed in other fields whose semantics have
yet to be pinned down (e.g., in certificates).
>I may supply information to authenticate myself to other parts of the
>network, and a firewall somewhere may use this information to decide
>whether to let my packets in the door. But IPSEC running at FOO.COM
>should be willing to build an encrypted tunnel to my laptop, whether
>or not my laptop later ends up authenticated as "the laptop that
>FOO.COM's system administrator borrowed while he was at a conference".
I don't follow. Are you advocating that DNSSEC be used even if the best
it can do is one-way authentication, since authentication in the other
direction is ... somebody else's problem?
>I also think we should focus on shipping standards that hit the sweet
>spot (most gain for least pain), which includes securing communications
>among all the hosts with fixed IP addresses. If dynamically assigned
>IP addresses are easy, throw 'em in; if not, leave them for the next
>round of standards. Since everyone seems to think they're hard,
>let's leave them for next time, and secure the large fraction of
>the Internet that we know how to do now.
You should qualify "sweet spot" by "in yesterday's internet". This message
originated at pool030.Max20.San-Francisco.CA.DYNIP.ALTER.NET and
comes to you via an encrypted tunnel to our POP server in Waltham, MA.
This is my "sweet spot", hard for DNSSEC to handle maybe, but not rocket
science.
DNSSEC is *not* a "shipping standard". If you want a shipping standard,
I'll point out that X.509 based schemes are currently deployed and
becomming more widely so every day (e.g., VeriSign, Netscape, Microsoft,
Cybertrust, Sun, Nortel ...). They are used extensively in tls. Why
exclude this shipping standard and include one that still experimental,
permits only one trust infrastructure, has no developed sense of quality
of authentication (read: who takes responsiblilty and liability for
for authenticated but bogus domain names), and for which there is no
committed schedule for deployment?
Put another way, if you want good encryption, why use authentication that
doesn't solve enough of the problem?
-- Joe
= ========================================================= =
Joe Tardo Voice: 415-843-0991
Raptor Systems, Inc.
777 San Antonio Ave. Suite 92 Fax: 617-487-6755
Palo Alto, CA. 94303
= ========================================================= =
Received: from relay.hq.tis.com by neptune.TIS.COM id aa22042;
15 Aug 96 12:50 EDT
Received: by relay.hq.tis.com; id MAA27439; Thu, 15 Aug 1996 12:53:43 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma027414; Thu, 15 Aug 96 12:53:15 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15916; Thu, 15 Aug 96 12:52:36 EDT
Received: by relay.hq.tis.com; id MAA27408; Thu, 15 Aug 1996 12:53:13 -0400
Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1)
id xma027403; Thu, 15 Aug 96 12:53:09 -0400
Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9])
by internet with ESMTP (DuhMail/3.0)
id MAA01264; Thu, 15 Aug 1996 12:53:45 -0400
Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id MAA00649; Thu, 15 Aug 1996 12:50:50 -0400
Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client)
id MAA12131; Thu, 15 Aug 1996 12:50:46 -0400
Message-Id: <199608151650.MAA12131@milkyway.com>
X-Mailer: exmh version 1.6.7 5/3/96
X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4
=)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F
~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf
|;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5
X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html
To: ipsec@TIS.COM
Cc: John Gilmore <gnu@toad.com>
Subject: Re: DNS? was Key Management
References: <199608142356.QAA08155@toad.com>
In-Reply-To: Your message of "Wed, 14 Aug 1996 16:55:59 PDT."
<199608142356.QAA08155@toad.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 15 Aug 1996 12:50:41 -0400
From: Michael Richardson <mcr@milkyway.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In a galaxy far, far away, : Wed, 14 Aug 1996 16:55:59 PDT
> However, IPSEC only authenticates to IP addresses. There's no further
> identification in the IPSEC packets. Even if usernames or hostnames
> are used in generating keys, there's no well-defined way to get that
> information back to an application; all it has is getpeername().
Well, I'd say that is a limitation of the current APIs, not IPsec itself.
> I also think we should focus on shipping standards that hit the sweet
> spot (most gain for least pain), which includes securing communications
> among all the hosts with fixed IP addresses. If dynamically assigned
I agree here.
> IP addresses are easy, throw 'em in; if not, leave them for the next
> round of standards. Since everyone seems to think they're hard,
In that case, you authenticate the user. You do this by having the
user generate a certificate saying "Packets from a.b.c.d are from me until
<time>" and provide that certificate to the "server" during the key management
phase.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21277;
15 Aug 96 11:53 EDT
Received: by relay.hq.tis.com; id LAA25690; Thu, 15 Aug 1996 11:56:13 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma025670; Thu, 15 Aug 96 11:55:48 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11438; Thu, 15 Aug 96 11:55:09 EDT
Received: by relay.hq.tis.com; id LAA25662; Thu, 15 Aug 1996 11:55:45 -0400
Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via
Message-ID: <9608151342.aa22819@neptune.TIS.COM>
smap (V3.1.1)
id xma025630; Thu, 15 Aug 96 11:55:34 -0400
Received: by pilot.firewall.is.chrysler.com; id LAA12853; Thu, 15 Aug 1996
11:56:05 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by
pilot.is.chrysler.com via smap (g3.0.1)
id sma012841; Thu, 15 Aug 96 11:55:56 -0400
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by
mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02738; Thu, 15
Aug 1996 11:48:32 -0400 (EDT)
Message-Id: <2.2.32.19960815155349.00ca03ac@pop3hub.is.chrysler.com>
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 11:53:49 -0400
To: "Mark S. Schneider" <mss@tycho.ncsc.mil>, naganand@ftp.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Comments on ISAKMP/Oakley
Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil, mjs@terisa.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote:
>> From: Naganand Doraswamy <naganand@ftp.com>
>>
>> These are mostly implemetation type comments:
>>
>> 2.4.1. Security Association Payload
>> Is the "Payload Length" field *really* supposed to be specified in
>> four-octet units, or should it be in octets as all the other payloads
>> are?
>>
>
> I believe it should be in octets. It seems unlikely that a SA payload
> will ever be large enough to require a length in 4-octet units.
IPv6 jumbograms?????
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21225;
15 Aug 96 11:51 EDT
Received: by relay.hq.tis.com; id LAA25613; Thu, 15 Aug 1996 11:54:46 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma025600; Thu, 15 Aug 96 11:54:18 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11377; Thu, 15 Aug 96 11:53:36 EDT
Received: by relay.hq.tis.com; id LAA25591; Thu, 15 Aug 1996 11:54:13 -0400
Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via
Message-ID: <9608151406.aa23122@neptune.TIS.COM>
smap (V3.1.1)
id xma025578; Thu, 15 Aug 96 11:53:52 -0400
Received: by pilot.firewall.is.chrysler.com; id LAA12855; Thu, 15 Aug 1996
11:56:04 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by
pilot.is.chrysler.com via smap (g3.0.1)
id sma012843; Thu, 15 Aug 96 11:55:59 -0400
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by
mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02752; Thu, 15
Aug 1996 11:48:35 -0400 (EDT)
Message-Id: <2.2.32.19960815155352.00b5f818@pop3hub.is.chrysler.com>
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 11:53:52 -0400
To: John Gilmore <gnu@toad.com>, ipsec@TIS.COM, gnu@toad.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: DNS? was Key Management
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 04:55 PM 8/14/96 -0700, John Gilmore wrote:
>
>I also think we should focus on shipping standards that hit the sweet
>spot (most gain for least pain), which includes securing communications
>among all the hosts with fixed IP addresses. If dynamically assigned
>IP addresses are easy, throw 'em in; if not, leave them for the next
>round of standards. Since everyone seems to think they're hard,
>let's leave them for next time, and secure the large fraction of
>the Internet that we know how to do now.
John, there are about 8,000 productive parts suppliers in the auto industry
and 17 oems. Chyrsler has already deployed 5,000 notebooks.
I could throw in NADA (dealers) and pick up 10,000 businesses, but then the
Ford notebooks will tilt the balance.
I think that dynamic addressing exceeds fix addressing unless we deal with
split horizon DNS firewall traversal (with NAT thrown in for good measure).
Day one, I've got lot more dynamic than I have fixed.
And oh, we want to be in pilot 4Q96 :)
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21277;
15 Aug 96 11:53 EDT
Received: by relay.hq.tis.com; id LAA25690; Thu, 15 Aug 1996 11:56:13 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma025670; Thu, 15 Aug 96 11:55:48 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11438; Thu, 15 Aug 96 11:55:09 EDT
Received: by relay.hq.tis.com; id LAA25662; Thu, 15 Aug 1996 11:55:45 -0400
Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via
Message-ID: <9608151408.aa23157@neptune.TIS.COM>
smap (V3.1.1)
id xma025630; Thu, 15 Aug 96 11:55:34 -0400
Received: by pilot.firewall.is.chrysler.com; id LAA12853; Thu, 15 Aug 1996
11:56:05 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by
pilot.is.chrysler.com via smap (g3.0.1)
id sma012841; Thu, 15 Aug 96 11:55:56 -0400
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by
mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02738; Thu, 15
Aug 1996 11:48:32 -0400 (EDT)
Message-Id: <2.2.32.19960815155349.00ca03ac@pop3hub.is.chrysler.com>
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 11:53:49 -0400
To: "Mark S. Schneider" <mss@tycho.ncsc.mil>, naganand@ftp.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Comments on ISAKMP/Oakley
Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil, mjs@terisa.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote:
>> From: Naganand Doraswamy <naganand@ftp.com>
>>
>> These are mostly implemetation type comments:
>>
>> 2.4.1. Security Association Payload
>> Is the "Payload Length" field *really* supposed to be specified in
>> four-octet units, or should it be in octets as all the other payloads
>> are?
>>
>
> I believe it should be in octets. It seems unlikely that a SA payload
> will ever be large enough to require a length in 4-octet units.
IPv6 jumbograms?????
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21226;
15 Aug 96 11:51 EDT
Received: by relay.hq.tis.com; id LAA25612; Thu, 15 Aug 1996 11:54:46 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma025599; Thu, 15 Aug 96 11:54:15 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11378; Thu, 15 Aug 96 11:53:36 EDT
Received: by relay.hq.tis.com; id LAA25590; Thu, 15 Aug 1996 11:54:13 -0400
Received: from pilot.is.chrysler.com(204.189.94.35) by relay.tis.com via
Message-ID: <9608151415.aa23352@neptune.TIS.COM>
smap (V3.1.1)
id xma025577; Thu, 15 Aug 96 11:53:52 -0400
Received: by pilot.firewall.is.chrysler.com; id LAA12854; Thu, 15 Aug 1996
11:56:04 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by
pilot.is.chrysler.com via smap (g3.0.1)
id sma012842; Thu, 15 Aug 96 11:55:58 -0400
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by
mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id LAA02750; Thu, 15
Aug 1996 11:48:35 -0400 (EDT)
Message-Id: <2.2.32.19960815155352.00978dc0@pop3hub.is.chrysler.com>
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 11:53:52 -0400
To: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "Re: DNS? was Re: Key Management, an
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 11:53 AM 8/14/96 -0500, David Wheeler-P26179 wrote:
>
>I have a problem with this as a basis for authentication also. If I am
>"dialed-in" through my ISP, and receive a dynamic address, I don't have a DNS
>entry, hostname, or otherwise. In fact, the only thing I really have is an e-
>mail address. The question that really needs to be asked is:
>
> "What am I authenticating:
> a person,
> a machine/host,
> or a network entrypoint?
>
>I can make a case for all three given different security policies, and
>different security perspectives.
I think I have said this a number of times. The auto industy is starting to
move forward with their inter-partner security requirements. All of the
above will be used. Also due to different policies and changing software,
option negotiation will be very important in a key mananagement protocol.
So too will RSVP and multicast support. Of course PFS will be used. ITAR
and such might get very interesting.
If I redefine VPN as:
Privacy via a secure network protocol and Membership via secure key
exchange, then the auto industry will have many VPNs working over the same
infrastructure. Chyrsler might have the Catia community and Ford the CP3.
Frank Nylon Bushing might be connecting their 2 plants and 2 remote sales
people. And PACCAR their engine systems with Cat and Allison-Chalmers. Etc.
DNSSEC can barely get me started. Only those sites with dedicated
connections and then really only for tunnels. The interesting part will
require something more, X.509v3 or DSS perhaps? We do have our own agency
to handle our registry.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24563;
15 Aug 96 15:04 EDT
Received: by relay.hq.tis.com; id PAA02451; Thu, 15 Aug 1996 15:06:56 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma002439; Thu, 15 Aug 96 15:06:31 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA24555; Thu, 15 Aug 96 15:05:51 EDT
Received: by relay.hq.tis.com; id PAA02432; Thu, 15 Aug 1996 15:06:25 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma002413; Thu, 15 Aug 96 15:05:41 -0400
Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7)
id MAA04135; Thu, 15 Aug 1996 12:07:28 -0700
Received: by maildig1.us.oracle.com (5.65v3.2/37.8)
id AA31703; Thu, 15 Aug 1996 12:07:10 -0700
Message-Id: <9608151907.AA31703@maildig1.us.oracle.com>
Date: 15 Aug 96 12:04:59 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: DNS? was Key Management
Cc: gnu@toad.com
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 14-Aug-96 16:55
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 2.1.16.0.0)
Content-Type: multipart/mixed; boundary="=_ORCL_23644078_0_11919608151308100"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_23644078_0_11919608151308100
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
John,
>However, IPSEC only authenticates to IP addresses.
You are wrong.
IPsec provides authentication to the "owner" of the security association.
This security association may be bound to one or more IP addresses, one or
more DNS names, or some other named entity (like a PGP key).
The implementations that you choose to field may be limited to provided IP
addresses as an authentication "handle".
>Even if usernames or hostnames
>are used in generating keys, there's no well-defined
>way to get that information back to an application;
>all it has is getpeername().
Getting the name from a IPsec security association to an application is a
"local issue". Some operating systems and application will not be able to
support this capability. This should not prevent the access control decisions
that are enforced at the network layer from being tied to a useful user
oriented identity.
For example, consider a dial-in host (with IPsec) connecting throught the
internet to a firewall (with IPsec). The IP address for the remote host is
not a useful identification mechanism since it changes. A PGP name and key
would be much more useful as an entry in a Access Control List (ACL). I am
not strongly advocating PGP as a certificate infrastrucuter for IPsec, but am
surprized that implementations have not surfaced using this technology.
>If dynamically assigned
>IP addresses are easy, throw 'em in; if not,
>leave them for the next round of standards. Since
>everyone seems to think they're hard, let's leave
>them for next time, and secure the large fraction of
>the Internet that we know how to do now.
Everyone? Dynamically assigned IP adresses are not a big problem for IPsec
and vendors on this list already have implementions that support this feature.
In our rush to field public domain code we should not throw out useful
features.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Still hiring, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
--=_ORCL_23644078_0_11919608151308100
Content-Type:message/rfc822
Date: 14 Aug 96 16:55:59
From:"John Gilmore <gnu@toad.com>" <ipsec-request@neptune.hq.tis.com>
To:ipsec@tis.com,gnu@toad.com
Subject:Re: DNS? was Key Management
X-Authentication-Warning:toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
Sender:ipsec-approval@neptune.hq.tis.com
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
One of the problems that has hung up all sorts of crypto protocols is
getting confused about what problem you are trying to solve. Like PEM,
let's not define all the packet formats and then spend three years
arguing over who authenticates what to who.
> Then the minimal basis for authentication is the association of a public key
> with an e-mail address, a hostname, or an IP address that can be used to
> support access control decisions.
DNSSEC supports associating a public key (or several public keys) with
each of the above. IP addresses are encoded into the domain-name
space in the usual 1.2.174.140.in-addr.arpa way. Email addresses
are encoded as e.g. gnu.toad.com by setting a bit in the KEY record
which indicates that the first component refers to a user rather than
to a host or subdomain.
However, IPSEC only authenticates to IP addresses. There's no further
identification in the IPSEC packets. Even if usernames or hostnames
are used in generating keys, there's no well-defined way to get that
information back to an application; all it has is getpeername().
> Is it sufficient to say that authentication is based on an e-mail address
> (personal), hostname, OR an IP address (network entrypoint)? Then the
> application/service which is accepting the authenticated identity must
> determine if this binding is sufficient authentication for the particular
> activity/access/application?
I believe you meant "sufficient authorization".
IPSEC and DNSEEC do not solve this second problem (applications
deciding whether to accept authenticated identities). That's an
access control question (is he allowed?) as opposed to an identity
question (who is he?).
IPSEC doesn't solve the global "single signon" problem; don't expect
it to.
I may supply information to authenticate myself to other parts of the
network, and a firewall somewhere may use this information to decide
whether to let my packets in the door. But IPSEC running at FOO.COM
should be willing to build an encrypted tunnel to my laptop, whether
or not my laptop later ends up authenticated as "the laptop that
FOO.COM's system administrator borrowed while he was at a conference".
I also think we should focus on shipping standards that hit the sweet
spot (most gain for least pain), which includes securing communications
among all the hosts with fixed IP addresses. If dynamically assigned
IP addresses are easy, throw 'em in; if not, leave them for the next
round of standards. Since everyone seems to think they're hard,
let's leave them for next time, and secure the large fraction of
the Internet that we know how to do now.
John Gilmore
--=_ORCL_23644078_0_11919608151308100--
Received: from ftp.com by neptune.TIS.COM id aa24610; 15 Aug 96 15:05 EDT
Received: from ftp.com by ftp.com ; Thu, 15 Aug 1996 15:10:29 -0400
Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 15 Aug 1996 15:10:29 -0400
Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4)
id PAA05631; Thu, 15 Aug 1996 15:10:17 -0400
Message-Id: <199608151910.PAA05631@MAILSERV-2HIGH.FTP.COM>
X-Mapi-Messageclass: IPM
Priority: Normal
To: ipsec@neptune.tis.com
X-Mailer: FTP Software Internet Mail 2.0
Mime-Version: 1.0
From: Frank T Solensky <solensky@ftp.com>
Subject: Re: Comments on ISAKMP/Oakley
Date: Thu, 15 Aug 1996 15:07:55 -0400
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>>> 2.4.1. Security Association Payload
>>> Is the "Payload Length" field *really* supposed to be specified =
in
>>> four-octet units, or should it be in octets as all the other
payloads
>>> are?
>>>
>> I believe it should be in octets. It seems unlikely that a SA payloa=
d
>> will ever be large enough to require a length in 4-octet units.
>
>IPv6 jumbograms?????
Yep. -- Frank
Date: Thu, 15 Aug 1996 11:53:52 -0400
To: John Gilmore <gnu@toad.com>, ipsec@TIS.COM, gnu@toad.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: DNS? was Key Management
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608151650.aa26859@neptune.TIS.COM>
At 04:55 PM 8/14/96 -0700, John Gilmore wrote:
>
>I also think we should focus on shipping standards that hit the sweet
>spot (most gain for least pain), which includes securing communications
>among all the hosts with fixed IP addresses. If dynamically assigned
>IP addresses are easy, throw 'em in; if not, leave them for the next
>round of standards. Since everyone seems to think they're hard,
>let's leave them for next time, and secure the large fraction of
>the Internet that we know how to do now.
John, there are about 8,000 productive parts suppliers in the auto industry
and 17 oems. Chyrsler has already deployed 5,000 notebooks.
I could throw in NADA (dealers) and pick up 10,000 businesses, but then the
Ford notebooks will tilt the balance.
I think that dynamic addressing exceeds fix addressing unless we deal with
split horizon DNS firewall traversal (with NAT thrown in for good measure).
Day one, I've got lot more dynamic than I have fixed.
And oh, we want to be in pilot 4Q96 :)
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
--
John C. Kelley
System Administrator (301) 854-6889
Trusted Information Systems, Inc. (301) 854-5363 FAX
3060 Washington Road johnk@tis.com (work)
Glenwood, MD 21738 johnk@radix.net (play)
Date: Thu, 15 Aug 1996 11:53:49 -0400
To: "Mark S. Schneider" <mss@tycho.ncsc.mil>, naganand@ftp.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Comments on ISAKMP/Oakley
Cc: ipsec@TIS.COM, mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil,
sjt@tycho.ncsc.mil, mjs@terisa.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608151701.aa27111@neptune.TIS.COM>
At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote:
>> From: Naganand Doraswamy <naganand@ftp.com>
>>
>> These are mostly implemetation type comments:
>>
>> 2.4.1. Security Association Payload
>> Is the "Payload Length" field *really* supposed to be specified in
>> four-octet units, or should it be in octets as all the other payloads
>> are?
>>
>
> I believe it should be in octets. It seems unlikely that a SA payload
> will ever be large enough to require a length in 4-octet units.
IPv6 jumbograms?????
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa27172;
15 Aug 96 17:05 EDT
Received: by relay.hq.tis.com; id RAA06482; Thu, 15 Aug 1996 17:08:49 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma006474; Thu, 15 Aug 96 17:08:31 -0400
Received: from outland.tis.com (outland.hq.tis.com) by tis.com (4.1/SUN-5.64)
id AA03039; Thu, 15 Aug 96 17:07:52 EDT
Message-Id: <2.2.32.19960815211420.00732110@pop.tis.com>
X-Sender: johnk@pop.tis.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 15 Aug 1996 17:14:20 -0400
To: ipsec@neptune.tis.com
From: "John C. Kelley" <johnk@TIS.COM>
Subject: Apologies
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I want to apologize for the possible multiple postings of two messages
from Robert Moskowitz at Chrysler Corporation. We have recently implemented
a policy to moderate postings from non-members of all of our majordomo
lists. This is due to the recent increase in spamming. Something
threw our moderating procedure out of whack with these messages from
Robert, making the first attempts to post his message have invalid
headers. These should be cleaned up now.
Thank you for bearing with us as we go through this change to make
the lists better with hopefully a minimum of impact on you.
-John Kelley
--
John C. Kelley
System Administrator (301) 854-6889
Trusted Information Systems, Inc. (301) 854-5363 FAX
3060 Washington Road johnk@tis.com (work)
Glenwood, MD 21738 johnk@radix.net (play)
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14484;
16 Aug 96 7:17 EDT
Received: by relay.hq.tis.com; id HAA14539; Fri, 16 Aug 1996 07:20:20 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma014532; Fri, 16 Aug 96 07:19:52 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16278; Fri, 16 Aug 96 07:19:13 EDT
Received: by relay.hq.tis.com; id HAA14528; Fri, 16 Aug 1996 07:19:51 -0400
Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.tis.com via smap (V3.1.1)
id xma014523; Fri, 16 Aug 96 07:19:40 -0400
Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1)
id AA09199; Fri, 16 Aug 96 07:19:17 EDT
Date: Fri, 16 Aug 96 07:19:17 EDT
From: "Mark S. Schneider" <mss@tycho.ncsc.mil>
Message-Id: <9608161119.AA09199@tarius.tycho.ncsc.mil>
To: rgm3@chrysler.com
Subject: Re: Comments on ISAKMP/Oakley
Cc: mss@tycho.ncsc.mil, wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil,
mjs@terisa.com, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> At 07:39 AM 8/12/96 EDT, Mark S. Schneider wrote:
> >> From: Naganand Doraswamy <naganand@ftp.com>
> >>
> >> These are mostly implemetation type comments:
> >>
> >> 2.4.1. Security Association Payload
> >> Is the "Payload Length" field *really* supposed to be specified in
> >> four-octet units, or should it be in octets as all the other payloads
> >> are?
> >>
> >
> > I believe it should be in octets. It seems unlikely that a SA payload
> > will ever be large enough to require a length in 4-octet units.
>
> IPv6 jumbograms?????
>
> Robert Moskowitz
> Chrysler Corporation
> (810) 758-8212
>
Bob,
Sorry for the confusion. An SA (security association) payload is an ISAKMP
payload for negotiating security attributes and for indentifying the
domain of interpretation (DOI) and situation under which the negotiation is
taking place. So, the length field I'm referencing applies only to the contents
of this payload. I don't believe the representation of security attributes
supported by any one entity will exceed 64K octets.
Mark Schneider
Received: from relay.hq.tis.com by neptune.TIS.COM id aa19786;
16 Aug 96 10:48 EDT
Received: by relay.hq.tis.com; id KAA21352; Fri, 16 Aug 1996 10:51:04 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma021324; Fri, 16 Aug 96 10:50:42 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA24956; Fri, 16 Aug 96 10:50:00 EDT
Received: by relay.hq.tis.com; id KAA21313; Fri, 16 Aug 1996 10:50:34 -0400
Received: from wizard.pn.com(204.96.36.2) by relay.tis.com via smap (V3.1.1)
id xma021305; Fri, 16 Aug 96 10:50:30 -0400
Received: from massey (massey.ftp.com [128.127.128.152]) by wizard.pn.com (8.6.12) with SMTP
id KAA31126 for <ipsec@tis.com>; Fri, 16 Aug 1996 10:52:43 -0400
Message-Id: <199608161452.KAA31126@wizard.pn.com>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 16 Aug 1996 10:52:23 -0400
To: ipsec@TIS.COM
From: Rodney Thayer <rodney@sabletech.com>
Subject: Apologies
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
"trust but verify"?
(thank you for taking such good care of the list. geting nude belly dancing
advertisements on ietf was bad enough thank you...)
>X-Sender: johnk@pop.tis.com
>Date: Thu, 15 Aug 1996 17:14:20 -0400
>To: ipsec@neptune.hq.tis.com
>From: "John C. Kelley" <johnk@TIS.COM>
>Subject: Apologies
>Sender: ipsec-approval@neptune.hq.tis.com
>
>
>I want to apologize for the possible multiple postings of two messages
>from Robert Moskowitz at Chrysler Corporation. We have recently implemented
>a policy to moderate postings from non-members of all of our majordomo
>lists. This is due to the recent increase in spamming. Something
>threw our moderating procedure out of whack with these messages from
>Robert, making the first attempts to post his message have invalid
>headers. These should be cleaned up now.
>
>Thank you for bearing with us as we go through this change to make
>the lists better with hopefully a minimum of impact on you.
>
> -John Kelley
>--
>John C. Kelley
>System Administrator (301) 854-6889
>Trusted Information Systems, Inc. (301) 854-5363 FAX
>3060 Washington Road johnk@tis.com (work)
>Glenwood, MD 21738 johnk@radix.net (play)
>
>
>
>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
Received: from relay.hq.tis.com by neptune.TIS.COM id aa20217;
16 Aug 96 10:59 EDT
Received: by relay.hq.tis.com; id LAA21924; Fri, 16 Aug 1996 11:02:36 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma021907; Fri, 16 Aug 96 11:02:21 -0400
Received: from london.eu.tis.com by tis.com (4.1/SUN-5.64)
id AA25714; Fri, 16 Aug 96 11:01:19 EDT
Received: from relay.eu.tis.com (firewall-user@relay.eu.tis.com [10.217.55.100]) by london.eu.tis.com (8.7.3/8.7.3) with ESMTP id PAA01003 for <ipsec@tis.com>; Fri, 16 Aug 1996 15:59:57 +0100 (BST)
Received: by relay.eu.tis.com; id LAA27135; Fri, 16 Aug 1996 11:55:47 +0100 (BST)
Received: from unknown.tycho.ncsc.mil(144.51.3.1) by relay.eu.tis.com via smap (V3.1.1)
id xma027133; Fri, 16 Aug 96 11:55:25 +0100
Received: by tarius.tycho.ncsc.mil (4.1/SMI-4.1)
id AA02301; Fri, 16 Aug 96 09:45:21 EDT
Date: Fri, 16 Aug 96 09:45:21 EDT
From: "Mark S. Schneider" <mss@tycho.ncsc.mil>
Message-Id: <9608161345.AA02301@tarius.tycho.ncsc.mil>
To: naganand@ftp.com
Subject: Re: Comments on ISAKMP/Oakley
Cc: mss.wdm@tycho.ncsc.mil, sjt@tycho.ncsc.mil, mjs@terisa.com,
ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Naganand,
Conversation guide:
>>> and > == Naganand Doraswamy
>> == Mark Schneider
>>>
>>> Where is "Multiple Precision Integer" specified?
>>>
>>
>> It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D.
>>
> For completeness, I suggest that you atleast mention where to look for the
> definition of multiple precision integer, or just add it in appendix in the
> draft.
Ok.
>>>
>>> A.7.1 The basic proposal format does has the following fields defined in the
>>> header:
>>> - Proposal #, Proposal Len, Protocol # and Attribute TLV's
>>> However, the ESP, AH, and ISAKMP proposals have defined the
>>> Transforms ID's and a reserved field. Shouldnt the basic proposal
>>> format take care of this as well?
>>
>> Yes. I guess we intended that the TLV could be used for the Transform
>> ID. Granted, that would take 8 octets. Are you suggesting adding a
>> Transform ID field to the Proposal #, Proposal Len, and Protocol #
>> fields? If so, how do you think this should be done? Reducing the
>> size of the Protocol # field? Your thoughts are appreciated.
>>
> I think we could reduce the protocol field size to one octet. Almost all the
> protocols I have seen have only one octet allocated for protocol ID and I
> feel it is safe to allocate one byte and use the other octet for transform
> ID, unless other people feel strongly against this.
Now that I've had more time to think about this and have been (gently)
reminded about the purpose of a *basic* proposal format, I don't think
it should be changed. The basic proposal format provides the foundation
from which other proposal formats can be derived. So, ESP and AH and ISAKMP
proposals are derived from the basic format and happen to include transform
ids. It's possible in the future (for possibly other protocols) that the
things we're negotiating don't have transform ids.
>>> A.7.4. Proposal Formats, ISAKMP: ???
>>>
>>
>>Section A.7.4. is intended to describe the confidentiality and authentication
>>mechanisms that are internal to ISAKMP and used to provide Phase I security.
>>Confidentiality will be provided by applying the IPsec ESP transform(s) to
>>ISAKMP messages. Authentication can also use IPsec AH transforms, only if
>>keys have been preplaced. This means we have to determine a public key
>>mechanism for authentication. We're working on this.
>>
>>
>How does one obtain the keys for ESP transform on Phase I ISAKMP messages?
>Is it an out of band mechanism or are the keys derived based on some public
>key mechanism?
I really blew this one! Section A.7.4 is intended to describe the
confidentiality and authentication mechanisms that are internal to ISAKMP
and used to provide security *in* Phase I to protect Phase II negotiations.
So, its intended to describe the mechanisms that ISAKMP uses to protect
ISAKMP-ISAKMP communications. My loose use of terminology concerning ESP
transforms is also a problem. I didn't intend to imply that we are letting
IPsec handle Phase I confidentiality. All I'm saying is we can leverage
off the work done for IPsec ESP and use the algorithms defined there in
ISAKMP. Yes, I understand that the ESP transforms are tied to processing
IP packets and adding an ESP header. We'll have to define how to apply the
algorithms in ISAKMP.
So, then the keys are obtained in the Phase I negotiation by using the
Oakley key exchange. It is not until after the key exchange that
confidentiality can be provided. I hope this is a little clearer.
You raise some interesting points regarding Modifying SAs. Since I'm leaving
early today :) I hope you don't mind if I address these issues next week.
Regards,
Mark Schneider
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24241;
16 Aug 96 13:16 EDT
Received: by relay.hq.tis.com; id NAA25917; Fri, 16 Aug 1996 13:04:41 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma025909; Fri, 16 Aug 96 13:04:20 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01897; Fri, 16 Aug 96 13:03:40 EDT
Received: by relay.hq.tis.com; id NAA25896; Fri, 16 Aug 1996 13:04:16 -0400
Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1)
id xma025845; Fri, 16 Aug 96 13:03:39 -0400
Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id KAA01205 for <ipsec@tis.com>; Fri, 16 Aug 1996 10:02:00 -0700
X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs
Date: Fri, 16 Aug 1996 10:01:56 -0700 (MST)
From: Oliver Spatscheck <spatsch@cs.arizona.edu>
Reply-To: Oliver Spatscheck <spatsch@cs.arizona.edu>
To: ipsec@TIS.COM
Subject: KEI visa XCHG (ISAKMP & OAKLEY)
Message-Id: <Pine.LNX.3.94.960816095936.1186A-100000@P-spatsch.cs.arizona.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
I am just implementing the ISAKMP header and realized that the xchg
field has only 4 bit. This seems to small. The Oakley modes has to be
handled as different exchange types as already mentioned by Mark.
However counting the 4 reserved exchange types and the 4 Oakley
exchange types there are only 8 other exchange types left. Considering
that we are currently designing a multicast key exchange protocol
using the ISAKMP framework I would strongly recommend to use 16 Bit in
the xchg field of the header.
Realizing this problem I was thinking about the Oakley KEI and
I don't think Oakley needs it's own KEI. Oakley main mode uses regular
DH key exchange or RSA encryption and the other Oakley modes don't use
key exchange payload at all.
Therefore a general KEI for DH, RSA encryption and a KEI for no key
exchange payload should be added.
The ISAKMP draft mentions Oakley multiple times as a key exchange
technique identified by a KEI. This is not true Oakley is a full size
exchange using sa, nonce, id, key exchange, signature and hash
payloads. The combination of selected attributes and used Oakley
mode defines the contents and presence of the hash, id, nonce and
signature payloads. There is no such thing as ONE Oakley KEI.
I forgot to mention in my last email that I am only implementing the
Oakley exchanges at this point. I am establishing the Phase 1 ISAKMP
SA using Oakley as I am using Oakley to establish the IPSEC SA.
It would be easy for me to add the ISAKMP exchanges or CISCO exchange.
However they all are less flexible than Oakley.
Oliver
- -----
Grad student and research assistant in computer science at the University of Arizona, Tucson, USA
For my PGP public key please check my homepage URL: http://www.cs.arizona.edu/people/spatsch
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBMhSphznVPgUZ7uZJAQEywQQAiE+WqkNsyPzLI4PNpIA8wb6kuKpsBqoZ
7SNvv9AdBrKdBMVhCYScN03xnZheziU/765u+CD9nZxmBCBaseRA4wGT9sPHLku/
tE4EVIlTqmQDkrGcn/+w8K0BuJ5iroRWSiiODU+1bkXoRJtwd5m4WAeX2l/uAgMf
ZqBEn4zvfK4=
=a85z
-----END PGP SIGNATURE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa26487;
16 Aug 96 14:46 EDT
Received: by relay.hq.tis.com; id OAA00981; Fri, 16 Aug 1996 14:49:15 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma000951; Fri, 16 Aug 96 14:48:50 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA08068; Fri, 16 Aug 96 14:48:10 EDT
Received: by relay.hq.tis.com; id OAA00945; Fri, 16 Aug 1996 14:48:45 -0400
Received: from ns.incog.com(199.190.177.251) by relay.tis.com via smap (V3.1.1)
id xma000918; Fri, 16 Aug 96 14:48:22 -0400
Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501)
id LAA12540; Fri, 16 Aug 1996 11:48:50 -0700
Received: from miraj.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4)
id LAA05351; Fri, 16 Aug 1996 11:50:38 -0700
Received: by miraj.incog.com (SMI-8.6/SMI-SVR4)
id LAA01604; Fri, 16 Aug 1996 11:49:48 -0700
From: Rich Skrenta <skrenta@osmosys.incog.com>
Message-Id: <199608161849.LAA01604@miraj.incog.com>
Subject: Re: ...draft ...*skip*...
To: Rodney Thayer <rodney@sabletech.com>
Date: Fri, 16 Aug 1996 11:49:47 -0700 (PDT)
Cc: ipsec@TIS.COM
In-Reply-To: <9608151531.AA17325@wellspring.us.dg.com> from "Rodney Thayer" at Aug 15, 96 11:31:03 am
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Excuse me but what's the status of the "what key management scheme are we
> agreeing upon" process?
>
> If SKIP is it than this is nice.
>
> IF SKIP isn't it then what is this? (I mean, it's a free internet but that
> would mean the filename didn't start with "draft-ietf-...")
skip-07 is mostly tightening-up of some ambiguous language in the
draft, based on comments we received from the other implementors at
our developer's workshop. We promised them a revised draft, and Tom
Markson presented the changes at Montreal. We've finally gotten the
revised draft out the door.
As far as the status of the smoke-filled room discussions... we don't
have an answer to give you just yet.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa02267;
16 Aug 96 19:30 EDT
Received: by relay.hq.tis.com; id TAA10152; Fri, 16 Aug 1996 19:33:22 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma010147; Fri, 16 Aug 96 19:32:54 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA25777; Fri, 16 Aug 96 19:32:14 EDT
Received: by relay.hq.tis.com; id TAA10141; Fri, 16 Aug 1996 19:32:52 -0400
Received: from atc.boeing.com(130.42.28.80) by relay.tis.com via smap (V3.1.1)
id xma010136; Fri, 16 Aug 96 19:32:24 -0400
Received: by atc.boeing.com (5.65/splinter.boeing.com)
id AA08673; Fri, 16 Aug 1996 16:33:50 -0700
Received: from commanche.ca.boeing.com by splinter.boeing.com with SMTP
(1.37.109.16/16.2) id AA143658399; Fri, 16 Aug 1996 16:33:19 -0700
Received: by commanche.ca.boeing.com (AIX 4.1/UCB 5.64/4.03)
id AA34366; Fri, 16 Aug 1996 16:34:30 -0700
Message-Id: <9608162334.AA34366@commanche.ca.boeing.com>
To: Robert Moskowitz <rgm3@chrysler.com>
Cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM,
tld5032@commanche.ca.boeing.com
Subject: Re: DNS? was Key Management
In-Reply-To: (Your message of Thu, 15 Aug 96 11:53:52 -0400.)
<9608151650.aa26859@neptune.TIS.COM>
Date: Fri, 16 Aug 96 16:34:28 -0700
From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" <tld5032@commanche.ca.boeing.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 04:55 PM 8/14/96 -0700, John Gilmore wrote:
>
>I also think we should focus on shipping standards that hit the sweet
>spot (most gain for least pain), which includes securing communications
>among all the hosts with fixed IP addresses.
On Thu, 15 Aug 1996 11:53:52 -0400 Robert Moskowitz responded:
>
>John, there are about 8,000 productive parts suppliers in the auto industry
>and 17 oems. Chyrsler has already deployed 5,000 notebooks.
>....
>Day one, I've got lot more dynamic than I have fixed.
>
Chrysler's not alone here! As of last count in May we had 104,000 active
IP addresses. About 40% are now supported with DHCP. It should be well
50% by the end of 97 after we begin to get the bulk of our UNIX
systems converted to DHCP. But the new installs and newer systems that
would be candidates for IPSEC are already well over 50% DHCP supported.
I also have heard that a number of the large ISP's are using DHCP; perhaps
someone from that group could comment on the impacts?
Take care
| Terry L. Davis, P.E.| Boeing Information & Support Services, Bellevue, WA |
| 206-957-5325 | BOEING EMAIL: tld5032@commanche.ca.boeing.com. |
----------------- Friday August 16,1996 04:32 PM PDT ----------------
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03751;
16 Aug 96 20:38 EDT
Received: by relay.hq.tis.com; id QAA04534; Fri, 16 Aug 1996 16:00:51 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma004519; Fri, 16 Aug 96 16:00:21 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11240; Fri, 16 Aug 96 15:59:39 EDT
Received: by relay.hq.tis.com; id QAA04508; Fri, 16 Aug 1996 16:00:16 -0400
Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1)
id xma004494; Fri, 16 Aug 96 15:59:40 -0400
Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id QAA14209; Fri, 16 Aug 1996 16:01:31 -0400 (EDT)
Date: Fri, 16 Aug 1996 16:01:31 -0400 (EDT)
From: "M.C.Nelson" <netsec@panix.com>
To: ipsec@TIS.COM
Subject: "user" and "network layer" security.
Message-Id: <Pine.SUN.3.91.960816155715.811B-100000@panix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Language in the Internet draft IPSEC architecture, and in its predecessor
RFC 1825, refer to "IP-layer security". This is in itself consistent with
lanquage in the IPSEC charter that refers to a "security protocol in the
network layer". However, several contributions to this discussion group
as well other lanquage in the IPSEC docments, refer to the term "user".
This is curious.
There is no concept of "user" at the IP layer (i.e. the network layer).
Moreover, there is no clean and reliable way to map from IP datagram to
user. Any such code will be problematic unless the functionality of
IP is severely altered. For example, consider a transport protocol
that combines service to several users simultaneously. Perfectly legal,
but problematic for a network layer mechanism that needs to know about
users. The candidate network layer code would need to know all of the
protocols that would be used with IP. In short, it would no longer be a
true network layer mechanism, but rather a kludge.
The most appropriate place to discuss and design "user" security
mechanisms woud seem to be in another discussion group. It is difficult
to understand how one could use the term "user" anywhere below the
application layer. Mixing "user" constructs into the network layer breaks
the network architecture and should be expected to lead to undesirable and
probably needless consequences.
"User" based security and "network layer" security can each be designed
and implemented in ways that are consistent with the established network
architecture. With some pro-forma cross consultation, one should expect
to arrive at reasonable results that provide good security without
conflict and without unduly compromising present network functionality.
The alternative does not offer as much grounds for optimism. Therefore it
seems that all lanquage related to "user" should be expunged from IPSEC
and instead treated in a seperate discussion group.
Regards to all,
Mitch Nelson
netsec@panix.com
Date: Fri, 16 Aug 1996 16:55:16 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608162055.QAA01070@mcn.netsec.com>
To: ipsec@TIS.COM, netsec@panix.com
Subject: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Language in the Internet draft IPSEC architecture, and in its predecessor
RFC 1825, refer to "IP-layer security". This is in itself consistent with
lanquage in the IPSEC charter that refers to a "security protocol in the
network layer". However, several contributions to this discussion group
as well other lanquage in the IPSEC docments, refer to the term "user".
This is curious.
There is no concept of "user" at the IP layer (i.e. the network layer).
Moreover, there is no clean and reliable way to map from IP datagram to
user. Any such code will be problematic unless the functionality of
IP is severely altered. For example, consider a transport protocol
that combines service to several users simultaneously. Perfectly legal,
but problematic for a network layer mechanism that needs to know about
users. The candidate network layer code would need to know all of the
protocols that would be used with IP. In short, it would no longer be a
true network layer mechanism, but rather a kludge.
The most appropriate place to discuss and design "user" security mechanisms
woud seem to be in another discussion group. It is difficult to understand
how one could use the term "user" anywhere below the application layer.
Mixing "user" constructs into the network layer breaks the network
architecture and should be expected to lead to undesirable and probably
needless consequences.
"User" based security and "network layer" security can each be designed and
implemented in ways that are consistent with the established network
architecture. With some pro-forma cross consultation, one should expect
to arrive at reasonable results that provide good security without conflict
and without unduly compromising present network functionality. The
alternative does not offer as much grounds for optimism. Therefore it
seems that all lanquage related to "user" should be expunged from IPSEC
and instead treated in a seperate discussion group.
Regards to all,
Mitch Nelson
netsec@panix.com
Received: from relay.hq.tis.com by neptune.TIS.COM id aa04985;
16 Aug 96 22:28 EDT
Received: by relay.hq.tis.com; id WAA11771; Fri, 16 Aug 1996 22:31:52 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011769; Fri, 16 Aug 96 22:31:23 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA28587; Fri, 16 Aug 96 22:30:44 EDT
Received: by relay.hq.tis.com; id WAA11766; Fri, 16 Aug 1996 22:31:22 -0400
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1)
id xma011764; Fri, 16 Aug 96 22:31:01 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id TAA20759; Fri,
16 Aug 1996 19:33:17 -0700
Date: Fri, 16 Aug 1996 19:33:17 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199608170233.TAA20759@puli.cisco.com>
To: mrf@epilogue.com
Subject: Re: (IPng 2039) Re: IPv6 encryption requirement
In-Reply-To: <9608160932.aa23772@quern.epilogue.com>
References: <199608151738.NAA01091@jekyll.piermont.com>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
My understanding of the IESG's decision is that both AH and ESP (and the
corresponding standards-track mandatory transforms, currently 1828 and 1829
but subject to change via normal IETF process) are mandatory for all IPv6
nodes.
The current RFCs and I-Ds are not sufficiently clear. I plead guilty to the
lack of clarity. I plan to fix this in the next set of I-D revisions. If I
don't fix it in the next set of I-D revisions, I'm sure one or more folks will
send me a gentle reminder that I forgot to make those fixes. :-)
Ran
rja@cisco.com
Received: from relay.hq.tis.com by neptune.TIS.COM id aa00969;
19 Aug 96 9:21 EDT
Received: by relay.hq.tis.com; id JAA01571; Mon, 19 Aug 1996 09:24:25 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma001565; Mon, 19 Aug 96 09:23:57 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA09605; Mon, 19 Aug 96 09:23:15 EDT
Received: by relay.hq.tis.com; id JAA01559; Mon, 19 Aug 1996 09:23:55 -0400
Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1)
id xma001556; Mon, 19 Aug 96 09:23:50 -0400
Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA11077 for <ipsec@TIS.COM>; Mon, 19 Aug 1996 09:26:04 -0400
Received: from depot(144.51.53.1) by guardian via smap (V1.3)
id sma011074; Mon Aug 19 09:25:47 1996
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA13222 for <ipsec@TIS.COM>; Mon, 19 Aug 1996 09:22:30 -0400
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4)
id JAA14640; Mon, 19 Aug 1996 09:25:37 -0400
Date: Mon, 19 Aug 1996 09:25:37 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Message-Id: <199608191325.JAA14640@argon.ncsc.mil>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security.
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From: "M.C.Nelson" <netsec@panix.com>
>
> There is no concept of "user" at the IP layer (i.e. the network layer).
> [A:] Moreover, there is no clean and reliable way to map from IP datagram to
> user. Any such code will be problematic unless the functionality of
> IP is severely altered. [B:] For example, consider a transport protocol
> that combines service to several users simultaneously.
IP datagrams can, however, be associated unambiguously with src and dst
addresses and port numbers, which (must necessarily) map unambiguously to
processes, which in turn can map to users on those systems which support
the notion of users. Your example B above is proof that assertion
A is incorrect.
> The most appropriate place to discuss and design "user" security
> mechanisms woud seem to be in another discussion group.
IPSEC is designing two protocols. One of them operates at the IP layer
and performs transforms on packets. The other operates at the application
layer and establishes the keys for the first.
It may indeed be appropriate to divide the effort into two working groups
and two mailing lists. It would certainly be easier to explain what is
meant for a product to be "IPSEC-compliant" if there were another label
"IP-SA-MGT-compliant" to remove the overloading from the first. But the
current IPSEC charter is not so divided, therefore discussions of key
management, application-layer daemons, and "users" are currently
appropriate for this group.
> It is difficult
> to understand how one could use the term "user" anywhere below the
> application layer.
Perhaps it would be easier to understand how the term "context" (in the
sense of the X window system's "graphics context" - a pointer to a
blob of data) fits in at the IP layer. IP doesn't need to interpret
the entire contents of the blob, just the parts it's interested in.
To: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Cc: ipsec@TIS.COM, netsec@panix.com
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Fri, 16 Aug 1996 16:55:16 EDT."
<199608162055.QAA01070@mcn.netsec.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 19 Aug 1996 11:02:16 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608191101.aa03898@neptune.TIS.COM>
"Mitchell C. Nelson" writes:
> Language in the Internet draft IPSEC architecture, and in its predecessor
> RFC 1825, refer to "IP-layer security". This is in itself consistent with
> lanquage in the IPSEC charter that refers to a "security protocol in the
> network layer". However, several contributions to this discussion group
> as well other lanquage in the IPSEC docments, refer to the term "user".
> This is curious.
>
> There is no concept of "user" at the IP layer (i.e. the network layer).
You seem to have missed the point, which is that IPSEC has this notion
of "security association" (actually, now its called "Security
Parameters" and has the associated "Security Parameters Index").
Why don't you go through the archives instead of making guesses about
what you think IPSEC does?
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03743;
19 Aug 96 10:57 EDT
Received: by relay.hq.tis.com; id LAA04675; Mon, 19 Aug 1996 11:01:00 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma004654; Mon, 19 Aug 96 11:00:32 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA17033; Mon, 19 Aug 96 10:59:50 EDT
Received: by relay.hq.tis.com; id LAA04646; Mon, 19 Aug 1996 11:00:30 -0400
Received: from jekyll.piermont.com(206.1.51.15) by relay.tis.com via smap
Message-ID: <9608191107.aa04103@neptune.TIS.COM>
(V3.1.1)
id xma004641; Mon, 19 Aug 96 11:00:18 -0400
Received: from localhost (perry@localhost) by jekyll.piermont.com
(8.7.5/8.6.12) with SMTP id LAA11313; Mon, 19 Aug 1996 11:02:21 -0400 (EDT)
Message-Id: <199608191502.LAA11313@jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't
use HELO protocol
To: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Cc: ipsec@TIS.COM, netsec@panix.com
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Fri, 16 Aug 1996 16:55:16 EDT."
<199608162055.QAA01070@mcn.netsec.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 19 Aug 1996 11:02:16 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
"Mitchell C. Nelson" writes:
> Language in the Internet draft IPSEC architecture, and in its predecessor
> RFC 1825, refer to "IP-layer security". This is in itself consistent with
> lanquage in the IPSEC charter that refers to a "security protocol in the
> network layer". However, several contributions to this discussion group
> as well other lanquage in the IPSEC docments, refer to the term "user".
> This is curious.
>
> There is no concept of "user" at the IP layer (i.e. the network layer).
You seem to have missed the point, which is that IPSEC has this notion
of "security association" (actually, now its called "Security
Parameters" and has the associated "Security Parameters Index").
Why don't you go through the archives instead of making guesses about
what you think IPSEC does?
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa06155;
19 Aug 96 12:27 EDT
Received: by relay.hq.tis.com; id MAA07209; Mon, 19 Aug 1996 12:30:28 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma007194; Mon, 19 Aug 96 12:30:05 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA21984; Mon, 19 Aug 96 12:29:19 EDT
Received: by relay.hq.tis.com; id MAA07188; Mon, 19 Aug 1996 12:29:58 -0400
Received: from copilot.is.chrysler.com(204.189.94.36) by relay.tis.com via smap (V3.1.1)
id xma007179; Mon, 19 Aug 96 12:29:31 -0400
Received: by pilotx.firewall.is.chrysler.com; id MAA06449; Mon, 19 Aug 1996 12:31:36 -0400
Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1)
id sma006441; Mon, 19 Aug 96 12:31:31 -0400
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id MAA22114 for <ipsec@tis.com>; Mon, 19 Aug 1996 12:23:57 -0400 (EDT)
Message-Id: <2.2.32.19960819162829.00bd8840@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Aug 1996 12:28:29 -0400
To: ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re:
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 12:12 PM 8/19/96 -0400, ipsec-request@neptune.tis.com wrote:
>To: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
I'm getting these messages rather wierdly this morning, is anyone else???
>Date: Mon, 19 Aug 1996 11:02:16 -0400
>From: "Perry E. Metzger" <perry@piermont.com>
>>
>> There is no concept of "user" at the IP layer (i.e. the network layer).
>
>You seem to have missed the point, which is that IPSEC has this notion
>of "security association" (actually, now its called "Security
>Parameters" and has the associated "Security Parameters Index").
>
>Why don't you go through the archives instead of making guesses about
>what you think IPSEC does?
Perry, people should not have to 'read the archives' for so basic a concept.
Maybe it really is too obscure in the architecture RFC. Going to have to
reread it :(
Yes, Mitchell, IPsec has a concept of a user. This is for setting up
security associations between two IP addresses, potentially at the transport
layer (rather than as a tunnel).
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa19856;
20 Aug 96 1:25 EDT
Received: by relay.hq.tis.com; id BAA24187; Tue, 20 Aug 1996 01:28:36 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma024184; Tue, 20 Aug 96 01:28:08 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA22270; Tue, 20 Aug 96 01:27:27 EDT
Received: by relay.hq.tis.com; id BAA24175; Tue, 20 Aug 1996 01:28:07 -0400
Received: from austria-c.it.earthlink.net(206.85.92.44) by relay.tis.com via smap (V3.1.1)
id xma024168; Tue, 20 Aug 96 01:27:45 -0400
Received: from rmonsour (max1-wc-ca-40.earthlink.net [206.149.198.90]) by austria.it.earthlink.net (8.7.5/8.7.3) with SMTP id WAA24373; Mon, 19 Aug 1996 22:29:34 -0700 (PDT)
Message-Id: <2.2.32.19960820053051.007412f4@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Aug 1996 22:30:51 -0700
To: Stephen Kent <kent@bbn.com>, Marcel Waldvogel <mwa@tik.ee.ethz.ch>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: I-D ACTION:draft-thayer-seccomp-00.txt
Cc: Naganand Doraswamy <naganand@ftp.com>, ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 07:07 PM 8/12/96 -0400, Stephen Kent wrote:
>Marcel,
>
> Our plans for re-writing the ESP and AH specs will avoid the need
>to document the combinatorial set of transforms. Instead, it will be
>possible to define the algorithms or transform elements via distinct RFCs.
>The ESP and AH specs will be upgraded to define formats for all of the
>optional fields required by the different transforms.
Steve,
Are you anticipating that the revised ESP spec will define formats for the
optional fields necessary to support lossless data compression? We are
planning a proposal along the lines of a combined compression/encryption
transform. I worry that your plans make it difficult to 'predict' "all of
the optional fields required by the different transforms". Did I
misunderstand what you meant?
Bob Monsour
Bob Monsour
rmonsour@earthlink.net
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199608200611.PAA07631@necom830.hpcl.titech.ac.jp>
Subject: Re: "user" and "network layer" security.
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Date: Tue, 20 Aug 96 15:10:50 JST
Cc: ipsec@TIS.COM
X-Mailer: ELM [version 2.3 PL11]
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > The most appropriate place to discuss and design "user" security
> > mechanisms woud seem to be in another discussion group.
>
> IPSEC is designing two protocols. One of them operates at the IP layer
> and performs transforms on packets. The other operates at the application
> layer and establishes the keys for the first.
Agreed.
"user" gives information to establish appropriate "network" layer
security.
The problem is that the required security varies application by
application.
Thus, neither secure "network" layer nor SECDNS can give "user"
appropriate security.
For example, even if your mail address is "name@provider.com",
you don't want your provider have control on your keys to decrypt
your mail.
> > It is difficult
> > to understand how one could use the term "user" anywhere below the
> > application layer.
It's an API issue, I think.
Masataka Ohta
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03258;
20 Aug 96 10:12 EDT
Received: by relay.hq.tis.com; id KAA00896; Tue, 20 Aug 1996 10:15:28 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma000883; Tue, 20 Aug 96 10:15:04 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA07471; Tue, 20 Aug 96 10:14:20 EDT
Received: by relay.hq.tis.com; id KAA00873; Tue, 20 Aug 1996 10:14:58 -0400
Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1)
id xma000869; Tue, 20 Aug 96 10:14:50 -0400
Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id KAA28323; Tue, 20 Aug 1996 10:16:42 -0400
Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA247460617; Tue, 20 Aug 1996 10:16:57 -0400
Received: by mordred.sware.com (5.65/2.1) id AA00964; Tue, 20 Aug 96 10:09:03 -0400
Message-Id: <9608201409.AA00964@mordred.sware.com>
Subject: Re: "user" and "network layer" security mechanisms.
To: perry@piermont.com
Date: Tue, 20 Aug 1996 10:09:03 -0400 (EDT)
From: Charles Watt <watt@sware.com>
Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com
In-Reply-To: <9608191101.aa03898@neptune.TIS.COM> from "Perry E. Metzger" at Aug 19, 96 11:02:16 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3627
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
BVIkGz4BmKij6ZtnUyFpDF6s9eXCX+6ZtMa+5csK4aBxc0BXSfEnQm2Racglqkav
c4vxdH4Iyt7nYMMSrkkgtxw=
> > M.C.Nelson <netsec@panix.com> wrote:
> >
> > There is no concept of "user" at the IP layer (i.e. the network layer).
> > [A:] Moreover, there is no clean and reliable way to map from IP datagram to
> > user. Any such code will be problematic unless the functionality of
> > IP is severely altered. [B:] For example, consider a transport protocol
> > that combines service to several users simultaneously.
>
> David Kemp wrote:
>
> IP datagrams can, however, be associated unambiguously with src and dst
> addresses and port numbers, which (must necessarily) map unambiguously to
> processes, which in turn can map to users on those systems which support
> the notion of users. Your example B above is proof that assertion
> A is incorrect.
>
>
> Perry E. Metzger wrote:
>
> You seem to have missed the point, which is that IPSEC has this notion
> of "security association" (actually, now its called "Security
> Parameters" and has the associated "Security Parameters Index").
>
> Why don't you go through the archives instead of making guesses about
> what you think IPSEC does?
Mr. Nelson is quite correct, in spite of the assertions otherwise.
Yes IPSEC has a concept of a security association, which could
conceivably be linked to individual users rather than hosts. But in
order for such a mechanism to be useful for user-level authentication
with an IP security protocol, there must be an unambiguous way to link
each IP datagram protected by the security protocol to a specific user-level
security association. Mr. Nelson's point was simply that UDP and TCP port
numbers are not a sufficient mechanism to make this link, unless you are
willing to limit the set of applications that you plan to support. As he
stated quite clearly, the Internet protocol stack permits higher layer
protocols to multiplex multiple logical channels across a single IP:port #
association.
Two very specific examples where the proposed mechanisms fail:
1) Implementations of RFC 1006 - ISO transport on top of TCP. This is
heavily used within the DMS infrastructure. It allows multiple users
of an OSI application, such as X.500 or X.400, to make OSI transport
connections over TCP. For efficiency, most implementations of this
service will multiplex all concurrent sessions over a single TCP
connection, so there is no way to tell which IP datagram corresponds
to which user-level "security association" of the service.
2) NFS. Most implementations of the NFS client operate with a fixed pool
of endpoints dedicated to the service. As a further complication, for
efficiency, most implementations support read-ahead and write-behind,
implemented as a daemon process on behalf of the actual user. Once
again it is not possible at the IP layer to determine which user-level
security association is responsible for a specific datagram.
There are many more examples where Internet services multiplex data from
several users across a single IP:port # association. As Perry would say,
read the RFCs. Perhaps some of them can be ignored as "not mainstream".
Attempts can be made to explain away others, such as the argument that NFS
really only works when the client system is fully trusted as part of the
same distributed system as the server, so just do host-host authentication
and trust the client system to get the user. But in total, all of this
ignoring and explaining away greatly limits the set of services that you can
offer over a secure IP that supports user-level associations. These quite
rightly belong at a higher layer.
Charlie Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
Date: Tue, 20 Aug 1996 11:52:42 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608201552.LAA00215@mcn.netsec.com>
To: ipsec@TIS.COM
Subject: "user" and "network layer", continuation and reply.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Continuing and responding to comments on
my email `"user" and "network layer" security':
The IP layer as presently defined, is not conditionalized to any next
or higher layer protocol. It is defined to provide "connectionless",
"unreliable", service between Internet hosts identified by IP address,
with fragmentation of datagrams as needed, unless otherwise flagged.
These are the basic facts of IP architecture. Most of the discussion
group seems to understand the significance of these facts very well.
At present (i.e. absent IPSEC), an IP datagram is defined only in terms
of src and dst IP addresses, a number representating a next layer
protocol, parameters for fragmentation, and a data payload. There is
nothing in the definition of the IP layer that is conditionalized to
the next layer protocol or to the contents of the data payload.
IPSEC deviates from the present network architecture by requiring the
IP layer to deal with an additional parameter, the security parameters
index (SPI) (more precisely, security parameters and headers
principally characterized by an SPI). The extent and consequences of
this deviation are related to the extent to which the SPI deviates
from directly mapping onto the values already available at the network
layer, i.e. <src,dst,prot>.
If SPI does not map onto <src,dst,prot>, there are three general types
of implementations. The cleanest, and closest to present architecture
is that the protocol layer at which the SPI is mapped passes the SPI
downward through the stack, to the IP layer. The IP layer then
processes the packet using the parameters indicated by the SPI.
(As consequences go, this might seem manageable. The basic packet
format can still be consistent with much of the presently installed
network infrastructure. However, one is entitled to question a
network layer security scheme that requires the participation of
upper layer entities (other than a key mgt daemon). For example,
what security services or benefits can be provided by such a scheme
that could not be provided by upper-layer code directly?)
To the point at hand, nothing in the network layer architecture even
with the added SPI, requires the network layer to deal in the
parameters of upper layer protocols. The extension simply requires
upper layer protocols to specify an SPI along with addresses, numeric
protocol, fragmentation flags, and data. What upper layer parameters
the SPI maps to is not information that is needed or dealt with by the
network layer. We do not deal with "user" at the network layer.
"User" is the business of upper layer protocols.
-------------
The following is offered by way of response to some specific points
contained in the replies to my posting.
(1) From mcr@milkyway.com:
"I can see several ways to discuss user based security within
current stacks."
Evidently, I failed to convey the point in an adequately clear way.
(2) From dpkemp@missi.ncsc.mil
"IP datagrams can, however, be associated unambiguously with src
and dst addresses and port numbers"
and,
"... IP doesn't need to interpret the entire contents of the
blob, just the parts it's interested in."
IP doesn't know anything about a "port". "Port" is a parameter
defined within *some* transport protocol headers.
Regarding the "blob", IP doesn't process the "blob" at all, except
to copy it to/from the datagram.
(3) xxx@xxx.com writes:
"You seem to have missed the point, which is that IPSEC has this
notion of "security association" (actually, now its called
"Security Parameters" and has the associated "Security Parameters
Index").
Why don't you go through the archives instead of making guesses
about what you think IPSEC does?"
My coments are based on familiarity with the archives, documents,
current discussions, and experience.
(4) Robert Moskowitz writes:
"xxx, people should not have to 'read the archives' for so
basic a concept. Maybe it really is too obscure in the
architecture RFC. Going to have to reread it :(
Yes, Mitchell, IPsec has a concept of a user. This is for
setting up security associations between two IP addresses,
potentially at the transport layer (rather than as a tunnel).
The description of the security association in the RFC documents
seems very clear.
My point is that the term "user" does not belong in a discussion
of network layer security mechanisms. If the SPI is to relate
to parameters outside of the network layer, the details of that
relationship should still be irrelevant to network layer mechanisms.
(The merit of supporting SPI = SPI(...,upper-layer-parameter) in
network layer mechanisms, is a related but seperate question.)
Regards,
Mitch Nelson
netsec@panix.com
Received: from relay.hq.tis.com by neptune.TIS.COM id aa07576;
20 Aug 96 12:32 EDT
Received: by relay.hq.tis.com; id MAA04687; Tue, 20 Aug 1996 12:35:29 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma004665; Tue, 20 Aug 96 12:35:00 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA24725; Tue, 20 Aug 96 12:34:18 EDT
Received: by relay.hq.tis.com; id MAA04662; Tue, 20 Aug 1996 12:34:59 -0400
Received: from milkyway.com(198.53.167.2) by relay.tis.com via smap (V3.1.1)
id xma004655; Tue, 20 Aug 96 12:34:41 -0400
Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9])
by internet with ESMTP (DuhMail/3.0)
id MAA21415; Tue, 20 Aug 1996 12:36:10 -0400
Received: from milkyway.com (root@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.12/8.6.12) with ESMTP id MAA22279 for <ipsec@tis.com>; Tue, 20 Aug 1996 12:34:08 -0400
Received: from metis.milkyway.com by milkyway.com (8.6.12/BSDI-Client)
id MAA22626; Tue, 20 Aug 1996 12:33:48 -0400
Message-Id: <199608201633.MAA22626@milkyway.com>
X-Mailer: exmh version 1.6.7 5/3/96
X-Face: x7OynEM*dB$e.2'7pigelLk>5:Nu:%r*iV96{F2XIT.apbrc-vOFSi{yI$3=nJ-Qi)allj4
=)4cWlX@IQ1Dsmk}T4qX~{XI5Z01>PV^cYR'~cL]&ma<{rYg~Ao-:~:sM%z}^M65`;1TZ}Tze"4/=F
~o&8;"SKHwB?%"xpP/=pkhdZVP$rQQ{"{QT`#kcx7!\/y+crQa4^nLEms6_k4O*o#fo[WBs~~&.%jf
|;W@E2K#{U~%vhvth^uDLWD`<OLQ;48T].laq_}3abY7nO5
X-Uri: http://www.milkyway.com/People/Michael_Richardson/Bio.html
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
References: <9608201409.AA00964@mordred.sware.com>
In-Reply-To: Your message of "Tue, 20 Aug 1996 10:09:03 EDT."
<9608201409.AA00964@mordred.sware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Aug 1996 12:33:48 -0400
From: Michael Richardson <mcr@milkyway.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In a galaxy far, far away, Charles Watt <watt@sware.com> says:
> Mr. Nelson is quite correct, in spite of the assertions otherwise.
> Yes IPSEC has a concept of a security association, which could
> conceivably be linked to individual users rather than hosts. But in
> order for such a mechanism to be useful for user-level authentication
> with an IP security protocol, there must be an unambiguous way to link
> each IP datagram protected by the security protocol to a specific user-level
> security association. Mr. Nelson's point was simply that UDP and TCP port
> numbers are not a sufficient mechanism to make this link, unless you are
> willing to limit the set of applications that you plan to support. As he
Huh?
Who said anything about UDP or TCP?
IPsec has an SPI. *That* is the unambiguous link between packets and
*all* security associations, whether they be user or node ones.
One of my major problems with SKIP is that it effectively kills the SPI
as a useful concept.
> Two very specific examples where the proposed mechanisms fail:
>
> 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is
> heavily used within the DMS infrastructure. It allows multiple users
> of an OSI application, such as X.500 or X.400, to make OSI transport
> connections over TCP. For efficiency, most implementations of this
> service will multiplex all concurrent sessions over a single TCP
> connection, so there is no way to tell which IP datagram corresponds
> to which user-level "security association" of the service.
I see. This sounds like an application problem. Why is it more efficient
to multiplex all sessions over a single TCP session? You've built a tunnel
with TCP. Thus, you are reimplementing the network layer, and you will
have to implement security there.
> 2) NFS. Most implementations of the NFS client operate with a fixed pool
> of endpoints dedicated to the service. As a further complication, for
NFS is inherently node-to-node as currently *implemented*, not
user-to-server. You can not do user level security associations with currently
implemented NFS. I suggest you look at AFS. I do not know enough about
Sprite's file sharing to comment where it would stand.
I wish NFS would go away, but I do not have a better solution yet. Further,
NFS doesn't have be implemented the way it is: we *could* push a user-server
SA down the through the vnode interface. The write-behind/read-ahead is
implemented by "processes" because of the way Unix works. It is implemented
as kernel threads on many systems.
To: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 20 Aug 1996 12:13:41 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608201241.aa07866@neptune.TIS.COM>
Charles Watt writes:
> Yes IPSEC has a concept of a security association, which could
> conceivably be linked to individual users rather than hosts. But in
> order for such a mechanism to be useful for user-level authentication
> with an IP security protocol, there must be an unambiguous way to link
> each IP datagram protected by the security protocol to a specific user-level
> security association.
The SPI number in the packet is perfectly suitable for this
purpose. The real issue is being able to negotiate the use of a
particular SPI for a particular connection -- thats a
Photuris/Oakley/ISAKMP/Whatever issue.
> 2) NFS. Most implementations of the NFS client operate with a fixed pool
> of endpoints dedicated to the service. As a further complication, for
> efficiency, most implementations support read-ahead and write-behind,
> implemented as a daemon process on behalf of the actual user. Once
> again it is not possible at the IP layer to determine which user-level
> security association is responsible for a specific datagram.
NFS is a protocol that isn't suited to securing things on a per-user
basis, but the key problem is that all NFS authentication is done (for
practical purposes) by the client, with the server trusting that a
client that has a file handle is allowed to claim to have any user
credential it wants. There is no way, in NFS, to do the "logical
thing" and check cryptographic credentials on a per file basis.
Perry
Date: Tue, 20 Aug 1996 09:00:24 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608201600.JAA28800@dfs-1.eng.sun.com>
To: perry@piermont.com, watt@sware.com
Subject: Re: "user" and "network layer" security mechanisms.
Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From watt@sware.com Tue Aug 20 08:07:17 1996
> > > M.C.Nelson <netsec@panix.com> wrote:
> > >
> > > There is no concept of "user" at the IP layer (i.e. the network layer).
> > > [A:] Moreover, there is no clean and reliable way to map from IP
datagram to
> > > user. Any such code will be problematic unless the functionality of
> > > IP is severely altered. [B:] For example, consider a transport protocol
> > > that combines service to several users simultaneously.
> Mr. Nelson is quite correct, in spite of the assertions otherwise.
> Yes IPSEC has a concept of a security association, which could
> conceivably be linked to individual users rather than hosts. But in
> order for such a mechanism to be useful for user-level authentication
> with an IP security protocol, there must be an unambiguous way to link
> each IP datagram protected by the security protocol to a specific user-level
> security association. Mr. Nelson's point was simply that UDP and TCP port
> numbers are not a sufficient mechanism to make this link, unless you are
> willing to limit the set of applications that you plan to support. As he
> stated quite clearly, the Internet protocol stack permits higher layer
> protocols to multiplex multiple logical channels across a single IP:port #
> association.
>
> Two very specific examples where the proposed mechanisms fail:
>
> 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is
> heavily used within the DMS infrastructure. It allows multiple users
> of an OSI application, such as X.500 or X.400, to make OSI transport
> connections over TCP. For efficiency, most implementations of this
> service will multiplex all concurrent sessions over a single TCP
> connection, so there is no way to tell which IP datagram corresponds
> to which user-level "security association" of the service.
>
> 2) NFS. Most implementations of the NFS client operate with a fixed pool
> of endpoints dedicated to the service. As a further complication, for
> efficiency, most implementations support read-ahead and write-behind,
> implemented as a daemon process on behalf of the actual user. Once
> again it is not possible at the IP layer to determine which user-level
> security association is responsible for a specific datagram.
Note that even with connection-oriented NFS (NFS on TCP), NFS client
implementations typically multiplex traffic from diffrent users to the
over the same connection to an NFS server. Some implementations go
further and multiplex all traffic, regardless of the number of mounted
file systems between a client/server pair over the same connection.
Moreover when using TCP, it is possible for the same *datagram* to
contain multiple NFS requests, each from different users.
> There are many more examples where Internet services multiplex data from
> several users across a single IP:port # association. As Perry would say,
> read the RFCs. Perhaps some of them can be ignored as "not mainstream".
> Attempts can be made to explain away others, such as the argument that NFS
^^^^
> really only works when the client system is fully trusted as part of the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> same distributed system as the server, so just do host-host authentication
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and trust the client system to get the user. But in total, all of this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the case when NFS operates over the AUTH_SYS oncrpc
authentication flavor. However, nothing in the NFS architecture
precludes a using a flavor that supports a user security association
that does not depend on trusting the client host. The ID
draft-oncrpc-rpcsec_gss-00.txt proposes a new onc rpc security flavor
that uses GSS-API security associations ("contexts" in the parlance
used by the CAT working group).
> ignoring and explaining away greatly limits the set of services that you can
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I agree, especially after thinking about how to actually implement
support for all services, including the two you list. In thinking about
how to implement user security associations on operation systems that
use asynchronous network I/O, such as Streams, I realize that it
introduces several implementation difficulties. Considering the Streams
model, one would have to tag each Streams buffer (an mblk) with an
identifier that is unique to each user security association. This in
theory could be done automatically at the Stream head. I am ignoring
the issue of multiple security associations per mblk or what ahppens
when one wishes to link mlbks with different tags together for the
purpose of transnsmission as one IP datagram.
Streams supports a dynamic plumbing model ... applications are free to
push and pop modules and link streams at will. Each Streams module
would have to agree to copy security association the tag whenever they
copy data from one mblk to another. If the modules used Streams APIs
like copyb(), and copymsg(), this would not be an issue. But it is not
infrequent for modules to allocate mblks and copy them using methods
outside the Streams API. One could certainly extend the Streams
framework such that it could be sure that all modules on the stack
apprehend the notions of the security association tag. But then there
is a binary compatibility issue whenever an application pushes a module
that hasn't been "IPSECized". Either the framework allows the push, and
risks untagged mblks be generated, or it refuses the push. Either way,
the application stops working.
I am curious if anyone has implemented IPSEC with user-level security
associations, and whether the associations are bound at the time the
end-point is open or if they are switchable with each outgoing
datagram. If the latter, is the I/O framework asynchronous or not? An
existance proof might make me less pessimistic about end-user IPSEC.
> offer over a secure IP that supports user-level associations. These quite
> rightly belong at a higher layer.
>
> Charlie Watt
> SecureWare, Inc.
Mike Eisler
SunSoft, Inc.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09227;
20 Aug 96 13:27 EDT
Received: by relay.hq.tis.com; id NAA06826; Tue, 20 Aug 1996 13:30:29 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma006822; Tue, 20 Aug 96 13:30:22 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA28505; Tue, 20 Aug 96 13:29:24 EDT
Received: by relay.hq.tis.com; id NAA06804; Tue, 20 Aug 1996 13:30:03 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1)
id xma006792; Tue, 20 Aug 96 13:29:50 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA032122323; Tue, 20 Aug 1996 10:32:04 -0700
Message-Id: <199608201732.AA032122323@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA188112322; Tue, 20 Aug 1996 13:32:02 -0400
To: Michael Richardson <mcr@milkyway.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: mcr's message of Tue, 20 Aug 1996 12:33:48 -0400.
<199608201633.MAA22626@milkyway.com>
Date: Tue, 20 Aug 1996 13:32:01 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > 2) NFS. Most implementations of the NFS client operate with a fixed pool
> > of endpoints dedicated to the service. As a further complication, for
>
> NFS is inherently node-to-node as currently *implemented*, not
> user-to-server. You can not do user level security associations with currently
> implemented NFS. I suggest you look at AFS. I do not know enough about
> Sprite's file sharing to comment where it would stand.
> I wish NFS would go away, but I do not have a better solution yet. Further,
> NFS doesn't have be implemented the way it is: we *could* push a user-server
> SA down the through the vnode interface.
Actually, you don't need to change the vnode interface at all. All
the hair lives below the vnode layer, either in the transport layer
(which needs to carry around security associations in about the same
way that carries around IP addresses), in the filesystem itself, and
in the interfaces between the filesystem, the transport, and the IP
layer.
To nitpick (I have substantial familiarity with the innards of AFS and
DCE/DFS, and once had similar familiarity with NFS):
There's already a "credentials" structure pointer in the vnode
interface; traditionally, this contains just the effective, real, and
saved user-id and group-id set. AFS extends this to also include a
"pointer" of sorts to the user's cryptographic credentials.
This cred structure can be passed around within the kernel between
different kernel threads/processes; in fact, it has to be, because of
UNIX permission semantics... file descriptors are capabilities, and
the credentials you use for I/O are the ones which were effective at
the time open() was called, not the ones which are currently in effect
in the current process.
Under the vnode layer, this cred pointer can find its way to your
"RPC" layer, which can use it to pick the outgoing SA and thus the
outbound SPI to use for the request.
While SPI's are unidirectional, the key management protocols tend to
create them in pairs. A security association thus has *two* SPI's:
one inbound, and one outbound.
On the server end, the inbound SPI can be used to look up the "real"
credentials to use; those credentials are then passed to the vnode ops
on the server. The response to the client is sent using the outbound
SPI which is paired with the inbound SPI over which the request was
received.
If you're operating over TCP, this *probably* means that you need
separate connection for each user -- but doing this will be a
relatively simple change considering the magnitude of other changes
needed.
If you're operating over UDP, you can probably continue to use the
same endpoint for all users, but you need to make sure that the
inbound SPI's are carried along with each packet and checked by the
receiver.
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09957;
20 Aug 96 13:57 EDT
Received: by relay.hq.tis.com; id OAA07611; Tue, 20 Aug 1996 14:00:29 -0400
From: pau@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma007607; Tue, 20 Aug 96 14:00:02 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA00336; Tue, 20 Aug 96 13:59:20 EDT
Received: by relay.hq.tis.com; id NAA07596; Tue, 20 Aug 1996 14:00:00 -0400
Received: from igw2.watson.ibm.com(129.34.139.6) by relay.tis.com via smap (V3.1.1)
id xma007587; Tue, 20 Aug 96 13:59:51 -0400
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id OAA18256; Tue, 20 Aug 1996 14:02:41 -0400
Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id OAA15313; Tue, 20 Aug 1996 14:01:56 -0400
Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03)
id AA23236; Tue, 20 Aug 1996 14:02:46 -0400
Date: Tue, 20 Aug 1996 14:02:46 -0400
Message-Id: <9608201802.AA23236@secpwr.watson.ibm.com>
To: ipsec@TIS.COM, spatsch@cs.arizona.edu
Subject: Re: KEI visa XCHG (ISAKMP & OAKLEY)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Md5: oG0PLyNwqw32iCSOZ+PxDw==
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Oliver, how about treating OAKLEY as a "security" protocol" under ISAKMP
(like ESP is a "security protocol" for IP.) and treating differnet modes
of OAKLEY as the attributes of OAKLEY.
In othwer words, we can construct OAKLEY, or any other KEP,
and its mode(s) as a ISAKMP proposal. Theefore a KEP can be negotiated
just like ESP and its transform.
Regards, Pau-Chen
> From ipsec-request@neptune.hq.tis.com Fri Aug 16 15:56:26 1996
> X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned =
process doing -bs
> Date: Fri, 16 Aug 1996 10:01:56 -0700 (MST)
> From: Oliver Spatscheck <spatsch@cs.arizona.edu>
> Reply-To: Oliver Spatscheck <spatsch@cs.arizona.edu>
> To: ipsec@TIS.COM
> Subject: KEI visa XCHG (ISAKMP & OAKLEY)
> Message-Id: =
<Pine.LNX.3.94.960816095936.1186A-100000@P-spatsch.cs.arizona.edu>
> Mime-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=3DUS-ASCII
> Sender: ipsec-approval@neptune.hq.tis.com
> Precedence: bulk
> Content-Length: 2120
> Status: RO
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
>=20
>=20
> I am just implementing the ISAKMP header and realized that the xchg
> field has only 4 bit. This seems to small. The Oakley modes has to be
> handled as different exchange types as already mentioned by Mark.
>=20
> However counting the 4 reserved exchange types and the 4 Oakley
> exchange types there are only 8 other exchange types left. Considering
> that we are currently designing a multicast key exchange protocol
> using the ISAKMP framework I would strongly recommend to use 16 Bit in
> the xchg field of the header.
>=20
> Realizing this problem I was thinking about the Oakley KEI and
> I don't think Oakley needs it's own KEI. Oakley main mode uses regular
> DH key exchange or RSA encryption and the other Oakley modes don't use
> key exchange payload at all.
>=20
> Therefore a general KEI for DH, RSA encryption and a KEI for no key
> exchange payload should be added.
>=20
> The ISAKMP draft mentions Oakley multiple times as a key exchange
> technique identified by a KEI. This is not true Oakley is a full size
> exchange using sa, nonce, id, key exchange, signature and hash
> payloads. The combination of selected attributes and used Oakley
> mode defines the contents and presence of the hash, id, nonce and
> signature payloads. There is no such thing as ONE Oakley KEI.
>=20
> I forgot to mention in my last email that I am only implementing the
> Oakley exchanges at this point. I am establishing the Phase 1 ISAKMP
> SA using Oakley as I am using Oakley to establish the IPSEC SA.
>=20
> It would be easy for me to add the ISAKMP exchanges or CISCO exchange.
> However they all are less flexible than Oakley.
>=20
> Oliver
>=20
> - -----
>=20
> Grad student and research assistant in computer science at the =
University of Arizona, Tucson, USA
> For my PGP public key please check my homepage URL: =
http://www.cs.arizona.edu/people/spatsch
>=20
>=20
>=20
>=20
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>=20
> iQCVAwUBMhSphznVPgUZ7uZJAQEywQQAiE+WqkNsyPzLI4PNpIA8wb6kuKpsBqoZ
> 7SNvv9AdBrKdBMVhCYScN03xnZheziU/765u+CD9nZxmBCBaseRA4wGT9sPHLku/
> tE4EVIlTqmQDkrGcn/+w8K0BuJ5iroRWSiiODU+1bkXoRJtwd5m4WAeX2l/uAgMf
> ZqBEn4zvfK4=3D
> =3Da85z
> -----END PGP SIGNATURE-----
>=20
>=20
Received: from relay.hq.tis.com by neptune.TIS.COM id aa10418;
20 Aug 96 14:11 EDT
Received: by relay.hq.tis.com; id OAA07974; Tue, 20 Aug 1996 14:14:32 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma007959; Tue, 20 Aug 96 14:14:02 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01391; Tue, 20 Aug 96 14:13:19 EDT
Received: by relay.hq.tis.com; id OAA07955; Tue, 20 Aug 1996 14:13:59 -0400
Received: from toxicwaste.mit.edu(18.85.0.40) by relay.tis.com via smap (V3.1.1)
id xma007948; Tue, 20 Aug 96 14:13:29 -0400
Received: (from warlord@localhost) by toxicwaste.media.mit.edu (8.6.10/8.6.10) id OAA09658; Tue, 20 Aug 1996 14:15:35 -0400
Message-Id: <199608201815.OAA09658@toxicwaste.media.mit.edu>
To: perry@piermont.com
Cc: Charles Watt <watt@sware.com>, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Tue, 20 Aug 1996 12:13:41 EDT."
<9608201241.aa07866@neptune.TIS.COM>
Date: Tue, 20 Aug 1996 14:15:34 EDT
From: Derek Atkins <warlord@mit.edu>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> NFS is a protocol that isn't suited to securing things on a per-user
> basis, but the key problem is that all NFS authentication is done (for
> practical purposes) by the client, with the server trusting that a
> client that has a file handle is allowed to claim to have any user
> credential it wants. There is no way, in NFS, to do the "logical
> thing" and check cryptographic credentials on a per file basis.
Huh? The fact that authentication is done at the client is an
implementation detail. It is implement that way, IMHO, because there
is no "secure" way for the server to know what access rights the
client has. However, that is in no way a requirement of the NFS
protocol.
You could easily change the RPC Security flavor to do something
different and implement the server such that access checks are
performed there as well. So, your statement about there being "no
way" is just plain wrong. OTOH, it would take a lot of programming to
change the implementation to "do the logical thing". But I believe it
is possible.
-derek
Received: from relay.hq.tis.com by neptune.TIS.COM id aa10774;
20 Aug 96 14:22 EDT
Received: by relay.hq.tis.com; id OAA08319; Tue, 20 Aug 1996 14:25:32 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008295; Tue, 20 Aug 96 14:25:02 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA02767; Tue, 20 Aug 96 14:24:19 EDT
Received: by relay.hq.tis.com; id OAA08289; Tue, 20 Aug 1996 14:25:00 -0400
Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1)
id xma008282; Tue, 20 Aug 96 14:24:53 -0400
Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id OAA29619; Tue, 20 Aug 1996 14:26:51 -0401
Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA029595386; Tue, 20 Aug 1996 14:23:06 -0400
Received: by mordred.sware.com (5.65/2.1) id AA01416; Tue, 20 Aug 96 14:14:09 -0400
Message-Id: <9608201814.AA01416@mordred.sware.com>
Subject: Re: "user" and "network layer" security mechanisms.
To: perry@piermont.com
Date: Tue, 20 Aug 1996 14:14:08 -0400 (EDT)
From: Charles Watt <watt@sware.com>
Cc: watt@sware.com, ipsec@TIS.COM
In-Reply-To: <199608201613.MAA13992@jekyll.piermont.com> from "Perry E. Metzger" at Aug 20, 96 12:13:41 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 5284
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
AsSicdunBDB1fTEjL203HnnGkWbgyYoI8agZmpGNJme1A5ggVXQAlW24/YM2OhTs
LU82juyKTXVcoAPbaCHXrE8=
>Perry E. Metzger wrote:
>> Charles Watt writes:
>> Yes IPSEC has a concept of a security association, which could
>> conceivably be linked to individual users rather than hosts. But in
>> order for such a mechanism to be useful for user-level authentication
>> with an IP security protocol, there must be an unambiguous way to link
>> each IP datagram protected by the security protocol to a specific user-level
>> security association.
>
>The SPI number in the packet is perfectly suitable for this
>purpose. The real issue is being able to negotiate the use of a
>particular SPI for a particular connection -- thats a
>Photuris/Oakley/ISAKMP/Whatever issue.
I think you are missing the point Perry. For example, if you have six
concurrent users of an X.400 product that makes use of an RFC 1006
convergence module for its OSI "transport connections", you wind up with
user data from six user-level security associations multiplexed over a
single TCP connection. Your IPSEC implementation is sitting at the
network level to secure outgoing data. It will see a datagram with source
address X.X.X.X:1014 (or some other dynamic port number chosen by the local
TSAP module for ALL data to destination host's TSAP module) and a
destination address of Y.Y.Y.Y:102 (officially assigned tsap port number).
This same pair of addresses is the same for all six X.400 users. So which
of the six SPI numbers do you put in the IPSEC header??? You don't know at
the IP level. Worse yet, what if the data segment contains several TP0
segments from different users? What SPI do you use when the user level
data belongs to multiple users?
I have been involved with this ongoing problem for five years now, and have
only found three solutions:
1) Modify the operating system, protocol stack, and TSAP convergence
module to propagate user identity information to the network
security layer. This was the wrong choice. It cost too much.
2) Use a higher layer security protocol that has access to user
identity. We got it right the second time.
3) Don't use TSAP. This wasn't an option for the billion+ dollar
procurement.
>
>> 2) NFS. Most implementations of the NFS client operate with a fixed pool
>> of endpoints dedicated to the service. As a further complication, for
>> efficiency, most implementations support read-ahead and write-behind,
>> implemented as a daemon process on behalf of the actual user. Once
>> again it is not possible at the IP layer to determine which user-level
>> security association is responsible for a specific datagram.
>
>NFS is a protocol that isn't suited to securing things on a per-user
>basis, but the key problem is that all NFS authentication is done (for
>practical purposes) by the client, with the server trusting that a
>client that has a file handle is allowed to claim to have any user
>credential it wants. There is no way, in NFS, to do the "logical
>thing" and check cryptographic credentials on a per file basis.
>
And how do you get the file handle? (rhetorical question) The client
passes the user's UID and GID in an NFS_LOOKUP (in most cases) request.
Should we just believe the offered ids? Or should a reasonable user-level
security protocol allow us to cryptographically verify this identity?
>Michael.Eisler wrote:
>
>> From watt@sware.com Tue Aug 20 08:07:17 1996
>> > > M.C.Nelson <netsec@panix.com> wrote:
>
>> ignoring and explaining away greatly limits the set of services that you can
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I agree, especially after thinking about how to actually implement
>support for all services, including the two you list...
...
>I am curious if anyone has implemented IPSEC with user-level security
>associations, and whether the associations are bound at the time the
>end-point is open or if they are switchable with each outgoing
>datagram. If the latter, is the I/O framework asynchronous or not? An
>existance proof might make me less pessimistic about end-user IPSEC.
I have done something similar. I designed SecureWare's various versions
of MaxSix software for multilevel secure networking. The single most costly
mistake I have ever made was to include user-level information into the
1.0 MaxSix network layer security protocol. The implications were enormous.
Tracking user level information for ALL applications required tremendous
modifications to the operating system and protocol stack. This was the
primary reason we appended our original design to include two layers of
security -- at the network layer we enforced mandatory access control
(being data driven a MAC label could be passed without much effort between
user process and network layer), with all user-level information, such as
authenticated identity, added to a second layer that effectively sat on top
of the transport much like the OSI TLSP. This was MUCH cleaner.
The bottom line: if you use a network layer security protocol to
propagate user-level information, you can cover perhaps 95% of current
use (you can invent a number just as easily as I) easily, but you will not
be able to cover everything. How critical is this shortfall? Well that's
rather dependent upon what you are doing, isn't it?
Charles Watt
SecureWare
-----END PRIVACY-ENHANCED MESSAGE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa11105;
20 Aug 96 14:34 EDT
Received: by relay.hq.tis.com; id OAA08717; Tue, 20 Aug 1996 14:37:30 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma008707; Tue, 20 Aug 96 14:37:01 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA03432; Tue, 20 Aug 96 14:36:19 EDT
Received: by relay.hq.tis.com; id OAA08701; Tue, 20 Aug 1996 14:37:00 -0400
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1)
id xma008691; Tue, 20 Aug 96 14:36:30 -0400
Received: from ftp.com by ftp.com ; Tue, 20 Aug 1996 14:38:40 -0400
Received: from athena.ftp.com by ftp.com ; Tue, 20 Aug 1996 14:38:40 -0400
Message-Id: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 20 Aug 1996 14:43:42 -0400
To: ipsec@TIS.COM
From: Naganand Doraswamy <naganand@ftp.com>
Subject: AH in tunnel mode
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I would like to know what people think about AH in tunnel mode. Ran
suggested that I post this to the list to evoke some discussion and then add
the following text either in the AH spec or write an informational document
on using IPSec to build VPN's.
------------------------------------------------------------------------------
Tunnled AH is useful in a couple of scenarious
- Virtual Private Networks: If an organization is geographically separated
and all the packets going from one subnet to the other needs to be
authencticated, then the packets can be authenticated by the border
gateways(routers). This is of value if and only if the border gateways dont
accept any unauthenticated packets. The border gateways (routers) MUST NOT
be willing to do key management or IPsec with nodes that are not authorised
to participate in the VPN.
- Road Warrior: If a mobile user is sending packets to the host net, then
the user can send authenticated packets tunneled to the border gateway,
which can then foward the packets to the hosts behind it.
Using AH in tunnel mode has the same security implications as using ESP in
tunneled mode (refer to Ran's comments on this).
------------------------------------------------------------------------------
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
Received: from relay.hq.tis.com by neptune.TIS.COM id aa11654;
20 Aug 96 14:56 EDT
Received: by relay.hq.tis.com; id PAA09700; Tue, 20 Aug 1996 15:00:00 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma009692; Tue, 20 Aug 96 14:59:32 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA05378; Tue, 20 Aug 96 14:58:50 EDT
Received: by relay.hq.tis.com; id OAA09683; Tue, 20 Aug 1996 14:59:30 -0400
Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1)
id xma009676; Tue, 20 Aug 96 14:59:25 -0400
Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id OAA29775; Tue, 20 Aug 1996 14:55:25 -0400
Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA035367308; Tue, 20 Aug 1996 14:55:09 -0400
Received: by mordred.sware.com (5.65/2.1) id AA01510; Tue, 20 Aug 96 14:46:43 -0400
Message-Id: <9608201846.AA01510@mordred.sware.com>
Subject: Re: "user" and "network layer" security mechanisms.
To: Michael Richardson <mcr@milkyway.com>
Date: Tue, 20 Aug 1996 14:46:43 -0400 (EDT)
From: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
In-Reply-To: <199608201633.MAA22626@milkyway.com> from "Michael Richardson" at Aug 20, 96 12:33:48 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1932
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
DKm25f1Al+YilzR4LegqMJhKKvS2GDQEJho8nsyZe59nLzoXodExIBdSFE6cKv9/
pf6m22/3zeAMzU063W96d8Q=
> Michael Richardson wrote:
> NFS is inherently node-to-node as currently *implemented*, not
> user-to-server. You can not do user level security associations with currently
> implemented NFS. I suggest you look at AFS. I do not know enough about
> Sprite's file sharing to comment where it would stand.
> I wish NFS would go away, but I do not have a better solution yet. Further,
> NFS doesn't have be implemented the way it is: we *could* push a user-server
> SA down the through the vnode interface. The write-behind/read-ahead is
> implemented by "processes" because of the way Unix works. It is implemented
> as kernel threads on many systems.
I play in the NFS source code all the time. You have simply restated my
first point -- user level authentication within a network layer security
protocol doesn't work with all applications.
Point number two: you cannot realistically design a security protocol and
expect installed sites to rewrite their applications or move to applications
that Michael Richardson considers to be a better solution. The market
dynamics are such that if your security solution does not provide adequate
security for a customer's network and INSTALLED applications, they will keep
their installed applications and get rid of your security solution.
I am merely stating observations made over the past seven years of
implementing similar network security protocols. If you expect a network
layer security protocol to supply user-level authentication, most large
sites will not accept the limitations required by the solution. We have
sold such a product in the past. Market requirements forced us to a
two-layer approach. I don't see the mix of applications being substantially
different today. Feel free to disagree and implement user-level security
associations within IPSEC. Good luck. Luckily the spec won't force the
rest of us into doing so.
Charlie Watt
SecureWare.
-----END PRIVACY-ENHANCED MESSAGE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12714;
20 Aug 96 15:34 EDT
Received: by relay.hq.tis.com; id PAA10559; Tue, 20 Aug 1996 15:37:30 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma010528; Tue, 20 Aug 96 15:37:03 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA07875; Tue, 20 Aug 96 15:36:20 EDT
Received: by relay.hq.tis.com; id PAA10522; Tue, 20 Aug 1996 15:37:00 -0400
Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma010508; Tue, 20 Aug 96 15:36:33 -0400
Received: by janus.border.com id <18474-2>; Tue, 20 Aug 1996 15:38:28 -0400
Message-Id: <96Aug20.153828edt.18474-2@janus.border.com>
To: ipsec@TIS.COM
Subject: Re: AH in tunnel mode
References: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
In-Reply-To: Your message of "Tue, 20 Aug 1996 14:43:42 -0400".
<2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
From: "C. Harald Koch" <chk@border.com>
Organization: Border Network Technologies Inc.
Phone: +1 416 368 7157
X-Uri: <URL:http://www.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, 20 Aug 1996 15:38:19 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> I would like to know what people think about AH in tunnel mode. Ran
> suggested that I post this to the list to evoke some discussion and then add
> the following text either in the AH spec or write an informational document
> on using IPSec to build VPN's.
Is tunnelled AH prohibited anywhere? i.e.:
IP[fw1,fw2] | AH | IP[src,dst] | ULP
Since AH has a "next hop protocol" field, and a valid protocol is IP
(protocol #4), this should work fine (It does in my code :-).
Personally, I've *never* understood the emphasis placed on "Transport mode"
v.s. "Tunnel mode". There already exists a separate IP in IP document;
adding AH and/or ESP between the two IP headers was obvious to me.
I understand that specific security issues arise with this configuration,
but those should be listed, IMHO, as an implementation note, instead of
separating out IP from every other possible "next hop" protocol in the
standards.
Maybe I'm just missing something obvious. If so, I beg enlightenment...
--
C. Harald Koch | Border Network Technologies Inc.
chk@border.com | Senior System Developer
+1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7789 (fax) | Madness takes its toll. Please have exact change.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13436;
20 Aug 96 16:09 EDT
Received: by relay.hq.tis.com; id QAA11644; Tue, 20 Aug 1996 16:12:30 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011627; Tue, 20 Aug 96 16:12:03 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11580; Tue, 20 Aug 96 16:11:21 EDT
Received: by relay.hq.tis.com; id QAA11622; Tue, 20 Aug 1996 16:12:00 -0400
Received: from dg-rtp.rtp.dg.com(128.222.1.2) by relay.tis.com via smap (V3.1.1)
id xma011617; Tue, 20 Aug 96 16:11:52 -0400
Received: from splinter.rtp.dg.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
id AA29013; Tue, 20 Aug 1996 16:14:02 -0400
Received: by splinter.rtp.dg.com (8.6.10/200.15.1.2)
id QAA05657; Tue, 20 Aug 1996 16:12:14 -0400
From: Jon Spencer <spencerj@dg-rtp.dg.com>
Message-Id: <199608202012.QAA05657@splinter.rtp.dg.com>
Subject: Re: "user" and "network layer" security mechanisms.
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Date: Tue, 20 Aug 1996 16:12:11 -0400 (EDT)
Cc: mcr@milkyway.com, ipsec@TIS.COM
In-Reply-To: <199608201732.AA032122323@relay.hp.com> from "Bill Sommerfeld" at Aug 20, 96 01:32:01 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2203
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>
> Actually, you don't need to change the vnode interface at all. All
> the hair lives below the vnode layer, either in the transport layer
> (which needs to carry around security associations in about the same
> way that carries around IP addresses), in the filesystem itself, and
> in the interfaces between the filesystem, the transport, and the IP
> layer.
>
> To nitpick (I have substantial familiarity with the innards of AFS and
> DCE/DFS, and once had similar familiarity with NFS):
>
> There's already a "credentials" structure pointer in the vnode
> interface; traditionally, this contains just the effective, real, and
> saved user-id and group-id set. AFS extends this to also include a
> "pointer" of sorts to the user's cryptographic credentials.
>
> This cred structure can be passed around within the kernel between
> different kernel threads/processes; in fact, it has to be, because of
> UNIX permission semantics... file descriptors are capabilities, and
> the credentials you use for I/O are the ones which were effective at
> the time open() was called, not the ones which are currently in effect
> in the current process.
And what do you do with third party streams multiplexers and/or SMP?
Trying to carry around extra credentials, either as an extension to the
credentials packet or as a separate structure pointer to by the credentials
packet falls apart in this scenario, I do think.
As for using the credentials which were effective at open time, this is
fine for standard Unix security policies, but as soon as you attempt to
deal with the more common current threats such as viruses, administrative
threats, internet access to systems with organizational confidential data,
then those policies are woefully insufficient, and some current credentials
are necessary.
--
Jon F. Spencer spencerj@rtp.dg.com (uunet!rtp.dg.com!spencerj)
Data General Corp. Phone : (919)248-6246
62 T.W. Alexander Dr, MS #119 FAX : (919)248-6108
Research Triangle Park, NC 27709 Office RTP 121/9
Reality is an illusion - perception is what counts.
No success can compensate for failure at home.
President David O. McKay
***** UCC 1-207 ********
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13592;
20 Aug 96 16:14 EDT
Received: by relay.hq.tis.com; id QAA11817; Tue, 20 Aug 1996 16:18:00 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011811; Tue, 20 Aug 96 16:17:44 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA12113; Tue, 20 Aug 96 16:16:56 EDT
Received: by relay.hq.tis.com; id QAA11798; Tue, 20 Aug 1996 16:17:30 -0400
Received: from p-spatsch.cs.arizona.edu(150.135.1.98) by relay.tis.com via smap (V3.1.1)
id xma011788; Tue, 20 Aug 96 16:17:13 -0400
Received: from localhost (spatsch@localhost) by P-spatsch.cs.arizona.edu (8.6.12/8.6.9) with SMTP id KAA04774; Tue, 20 Aug 1996 10:45:27 -0700
X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs
Date: Tue, 20 Aug 1996 10:45:23 -0700 (MST)
From: Oliver Spatscheck <spatsch@cs.arizona.edu>
To: pau@watson.ibm.com
Cc: ipsec@TIS.COM
Subject: Re: KEI visa XCHG (ISAKMP & OAKLEY)
In-Reply-To: <9608201802.AA23236@secpwr.watson.ibm.com>
Message-Id: <Pine.LNX.3.94.960820102744.4155B-100000@P-spatsch.cs.arizona.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 20 Aug 1996 pau@watson.ibm.com wrote:
>Oliver, how about treating OAKLEY as a "security" protocol" under ISAKMP
>(like ESP is a "security protocol" for IP.) and treating differnet modes
>of OAKLEY as the attributes of OAKLEY.
>
>In othwer words, we can construct OAKLEY, or any other KEP,
>and its mode(s) as a ISAKMP proposal. Theefore a KEP can be negotiated
>just like ESP and its transform.
>
>
>Regards, Pau-Chen
>
If you define the progress of an exchange using the security protocol
instead of the xchng field then why should there be an exchange field
at all?
ISAKMP Base, Identity and Auth only Exchanges could also be defined
via the security protocol or as attributes to the ISAKMP proposal.
To avoid confusion I would like to mention that Oakley specifies when
which payload has to be exchanged. It not only specifies the contents
of the payloads.
I have a few reasons to oppose this concept.
1. You have to negotiate a proposal before you can start up an
exchange adding one message exchange (send/receive SA payload).
Otherwise you won't know how to generate/process the other
payloads.
2. You allays have to pass the SA payload in clear.
(OAKLEY or ISAKMP don't encrypt the FIRST SA payload, but
a key exchange framework shouldn't prevent a key exchange
protocol from doing so.)
3. You can't demultiplex early by only reading the header to the
right state machine for processing. This is an implementation issue
but I think an important one.
Oliver
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBMhn5tjnVPgUZ7uZJAQFqqAP/VqkRDN0f4bfLk7qP3J86tiXdLflyiY0R
K94OuySyCEOOSKTbKPx4H/qzhCrCVLOYEdP0n5/MqNQQjyN3j/y5jZZIsWk8r5tF
ml/BtgjDDen/jMSiIXzjf6AYTUregRM0FHNmqZxZd8YGJkJ0AMLvvy/JytrAX2LC
RnB6fO+NHc0=
=VioU
-----END PGP SIGNATURE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13591;
20 Aug 96 16:14 EDT
Received: by relay.hq.tis.com; id QAA11816; Tue, 20 Aug 1996 16:18:00 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma011810; Tue, 20 Aug 96 16:17:43 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA12111; Tue, 20 Aug 96 16:16:52 EDT
Received: by relay.hq.tis.com; id QAA11799; Tue, 20 Aug 1996 16:17:30 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma011786; Tue, 20 Aug 96 16:16:58 -0400
Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7)
id NAA24613; Tue, 20 Aug 1996 13:18:41 -0700
Received: by maildig1.us.oracle.com (5.65v3.2/37.8)
id AA03144; Tue, 20 Aug 1996 13:18:33 -0700
Message-Id: <9608202018.AA03144@maildig1.us.oracle.com>
Date: 20 Aug 96 13:17:08 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer", continuation and reply.
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 20-Aug-96 08:52
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 2.1.16.0.0)
Content-Type: multipart/mixed; boundary="=_ORCL_23978113_0_11919608201419330"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_23978113_0_11919608201419330
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
On the subject of Ipsec "users:
>From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
>...
> Evidently, I failed to convey the point in an adequately clear way.
I agree.
I hope it is clear now that -
IPsec processing binds an authenticated packet to a Security Association (SA).
The information contained in the SA may provide additional authentication
information corresponding to one or more IP addresses, one or more DNS names,
or one or more "users".
I agree that "user" does not cover this felxibilty well and is confusing ...
perhaps the documentation could refer to something obtuse like principles or
authenticated entities.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Still hiring, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
--=_ORCL_23978113_0_11919608201419330
Content-Type:message/rfc822
Date: 20 Aug 96 08:52:42
From:"Mitchell C. Nelson <nelson@mcn.netsec.com>" <ipsec-request@neptune.hq.tis.com>
To:ipsec@tis.com
Subject:"user" and "network layer", continuation and reply.
Sender:ipsec-approval@neptune.hq.tis.com
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
Continuing and responding to comments on
my email `"user" and "network layer" security':
The IP layer as presently defined, is not conditionalized to any next
or higher layer protocol. It is defined to provide "connectionless",
"unreliable", service between Internet hosts identified by IP address,
with fragmentation of datagrams as needed, unless otherwise flagged.
These are the basic facts of IP architecture. Most of the discussion
group seems to understand the significance of these facts very well.
At present (i.e. absent IPSEC), an IP datagram is defined only in terms
of src and dst IP addresses, a number representating a next layer
protocol, parameters for fragmentation, and a data payload. There is
nothing in the definition of the IP layer that is conditionalized to
the next layer protocol or to the contents of the data payload.
IPSEC deviates from the present network architecture by requiring the
IP layer to deal with an additional parameter, the security parameters
index (SPI) (more precisely, security parameters and headers
principally characterized by an SPI). The extent and consequences of
this deviation are related to the extent to which the SPI deviates
from directly mapping onto the values already available at the network
layer, i.e. <src,dst,prot>.
If SPI does not map onto <src,dst,prot>, there are three general types
of implementations. The cleanest, and closest to present architecture
is that the protocol layer at which the SPI is mapped passes the SPI
downward through the stack, to the IP layer. The IP layer then
processes the packet using the parameters indicated by the SPI.
(As consequences go, this might seem manageable. The basic packet
format can still be consistent with much of the presently installed
network infrastructure. However, one is entitled to question a
network layer security scheme that requires the participation of
upper layer entities (other than a key mgt daemon). For example,
what security services or benefits can be provided by such a scheme
that could not be provided by upper-layer code directly?)
To the point at hand, nothing in the network layer architecture even
with the added SPI, requires the network layer to deal in the
parameters of upper layer protocols. The extension simply requires
upper layer protocols to specify an SPI along with addresses, numeric
protocol, fragmentation flags, and data. What upper layer parameters
the SPI maps to is not information that is needed or dealt with by the
network layer. We do not deal with "user" at the network layer.
"User" is the business of upper layer protocols.
-------------
The following is offered by way of response to some specific points
contained in the replies to my posting.
(1) From mcr@milkyway.com:
"I can see several ways to discuss user based security within
current stacks."
Evidently, I failed to convey the point in an adequately clear way.
(2) From dpkemp@missi.ncsc.mil
"IP datagrams can, however, be associated unambiguously with src
and dst addresses and port numbers"
and,
"... IP doesn't need to interpret the entire contents of the
blob, just the parts it's interested in."
IP doesn't know anything about a "port". "Port" is a parameter
defined within *some* transport protocol headers.
Regarding the "blob", IP doesn't process the "blob" at all, except
to copy it to/from the datagram.
(3) xxx@xxx.com writes:
"You seem to have missed the point, which is that IPSEC has this
notion of "security association" (actually, now its called
"Security Parameters" and has the associated "Security Parameters
Index").
Why don't you go through the archives instead of making guesses
about what you think IPSEC does?"
My coments are based on familiarity with the archives, documents,
current discussions, and experience.
(4) Robert Moskowitz writes:
"xxx, people should not have to 'read the archives' for so
basic a concept. Maybe it really is too obscure in the
architecture RFC. Going to have to reread it :(
Yes, Mitchell, IPsec has a concept of a user. This is for
setting up security associations between two IP addresses,
potentially at the transport layer (rather than as a tunnel).
The description of the security association in the RFC documents
seems very clear.
My point is that the term "user" does not belong in a discussion
of network layer security mechanisms. If the SPI is to relate
to parameters outside of the network layer, the details of that
relationship should still be irrelevant to network layer mechanisms.
(The merit of supporting SPI = SPI(...,upper-layer-parameter) in
network layer mechanisms, is a related but seperate question.)
Regards,
Mitch Nelson
netsec@panix.com
--=_ORCL_23978113_0_11919608201419330--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14021;
20 Aug 96 16:27 EDT
Received: by relay.hq.tis.com; id QAA12249; Tue, 20 Aug 1996 16:30:05 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012233; Tue, 20 Aug 96 16:29:38 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA13217; Tue, 20 Aug 96 16:28:54 EDT
Received: by relay.hq.tis.com; id QAA12224; Tue, 20 Aug 1996 16:29:33 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1)
id xma012215; Tue, 20 Aug 96 16:29:13 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA221773087; Tue, 20 Aug 1996 13:31:29 -0700
Message-Id: <199608202031.AA221773087@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA225123086; Tue, 20 Aug 1996 16:31:26 -0400
To: Jon Spencer <spencerj@dg-rtp.dg.com>
Cc: mcr@milkyway.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: spencerj's message of Tue, 20 Aug 1996 16:12:11 -0400.
<199608202012.QAA05657@splinter.rtp.dg.com>
Date: Tue, 20 Aug 1996 16:31:25 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> And what do you do with third party streams multiplexers and/or SMP?
> Trying to carry around extra credentials, either as an extension to the
> credentials packet or as a separate structure pointer to by the credentials
> packet falls apart in this scenario, I do think.
I plead ignorance to the fine implementation details of STREAMS --
there may well need to be an API bump to pass the SA information
through.
At the worst case, third-party STREAMS modules would lose SA info (and
thus wouldn't be able to play nice with user-oriented keying) until
they had been tweaked for the new regime.
> As for using the credentials which were effective at open time, this is
> fine for standard Unix security policies, but as soon as you attempt to
> deal with the more common current threats such as viruses, administrative
> threats, internet access to systems with organizational confidential data,
> then those policies are woefully insufficient, and some current credentials
> are necessary.
Probably correct, but completely irrelevant to the discussion; the
distributed filesystem client can use the ambient credentials as well
as the open-time creds to choose the SA to use if it really is
relevant..
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14117;
20 Aug 96 16:30 EDT
Received: by relay.hq.tis.com; id QAA12388; Tue, 20 Aug 1996 16:33:33 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012370; Tue, 20 Aug 96 16:33:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA13557; Tue, 20 Aug 96 16:32:23 EDT
Received: by relay.hq.tis.com; id QAA12356; Tue, 20 Aug 1996 16:33:03 -0400
Received: from mail11.digital.com(192.208.46.10) by relay.tis.com via smap (V3.1.1)
id xma012350; Tue, 20 Aug 96 16:32:56 -0400
Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV)
id QAA27248; Tue, 20 Aug 1996 16:21:36 -0400 (EDT)
Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
id AA07437; Tue, 20 Aug 1996 16:21:33 -0400
Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id QAA12066; Tue, 20 Aug 1996 16:25:59 GMT
Message-Id: <199608201625.QAA12066@whydos.lkg.dec.com>
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: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Tue, 20 Aug 1996 14:14:08 -0400."
<9608201814.AA01416@mordred.sware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Aug 1996 16:25:57 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> I think you are missing the point Perry. For example, if you have six
> concurrent users of an X.400 product that makes use of an RFC 1006
> convergence module for its OSI "transport connections", you wind up with
> user data from six user-level security associations multiplexed over a
> single TCP connection.
Sorry, that's impossible. RFC 1006 (and RFC 1859) only allows one OSI
transport connection per TCP connection; multiplexing multiple connections
is specificly not allowed. Therefore there is always a one-to-one mapping.
--
Matt Thomas Internet: matt@lkg.dec.com
IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation Disclaimer: This message reflects my
Littleton, MA own warped views, etc.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa15310;
20 Aug 96 17:10 EDT
Received: by relay.hq.tis.com; id RAA13918; Tue, 20 Aug 1996 17:13:33 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma013908; Tue, 20 Aug 96 17:13:05 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15667; Tue, 20 Aug 96 17:12:22 EDT
Received: by relay.hq.tis.com; id RAA13904; Tue, 20 Aug 1996 17:13:03 -0400
Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1)
id xma013898; Tue, 20 Aug 96 17:12:44 -0400
Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id RAA00742; Tue, 20 Aug 1996 17:13:21 -0400
Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA085655616; Tue, 20 Aug 1996 17:13:36 -0400
Received: by mordred.sware.com (5.65/2.1) id AA01723; Tue, 20 Aug 96 17:05:43 -0400
Message-Id: <9608202105.AA01723@mordred.sware.com>
Subject: Re: "user" and "network layer" security mechanisms.
To: Matt Thomas <matt@lkg.dec.com>
Date: Tue, 20 Aug 1996 17:05:42 -0400 (EDT)
From: Charles Watt <watt@sware.com>
Cc: watt@sware.com, ipsec@TIS.COM
In-Reply-To: <199608201625.QAA12066@whydos.lkg.dec.com> from "Matt Thomas" at Aug 20, 96 04:25:57 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 1511
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
AVo1Xh4yR+G5j3ixIrot6HfjbqBQoset/frbmjzM2IWwJfxzlUMIisGqa5NoiXnt
eaEHfx630VXVlY0KLEun+V8=
> Matt Thomas wrote:
>
> > I think you are missing the point Perry. For example, if you have six
> > concurrent users of an X.400 product that makes use of an RFC 1006
> > convergence module for its OSI "transport connections", you wind up with
> > user data from six user-level security associations multiplexed over a
> > single TCP connection.
>
> Sorry, that's impossible. RFC 1006 (and RFC 1859) only allows one OSI
> transport connection per TCP connection; multiplexing multiple connections
> is specificly not allowed. Therefore there is always a one-to-one mapping.
Upon review of the spec, you are correct. It appears that my memory is not
immune to age afterall. However, I've looked at the source to our vendor's
RFC 1006 streams module and the basic problem remains. It internally
manages a pool of TCP endpoints, maintaining its own internal binding
between TP0 connection and TCP connection. There is no way software
at the IP layer can correlate the TCP connection back to the originating
process without substantial modification to this product. This renders
user-level authentication within IPSEC useless for any application running
upon this transport.
Pick at the specifics all you want, the basic point remains valid. The
Internet stack was designed to permit multiplexing above IP. There are
several things out there that do this. User-level authentication within
IPSEC cannot work for these products unless they are substantially
modified.
Charlie Watt
SecureWare
-----END PRIVACY-ENHANCED MESSAGE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa15700;
20 Aug 96 17:22 EDT
Received: by relay.hq.tis.com; id RAA14285; Tue, 20 Aug 1996 17:26:03 -0400
From: wobber@pa.dec.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma014265; Tue, 20 Aug 96 17:25:34 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16294; Tue, 20 Aug 96 17:24:52 EDT
Received: by relay.hq.tis.com; id RAA14261; Tue, 20 Aug 1996 17:25:33 -0400
Received: from mail1.digital.com(204.123.2.50) by relay.tis.com via smap (V3.1.1)
id xma014251; Tue, 20 Aug 96 17:25:23 -0400
Received: from hickory.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA00870; Tue, 20 Aug 1996 14:11:09 -0700
Received: by hickory.pa.dec.com; id AA25177; Tue, 20 Aug 1996 14:11:00 -0700
Message-Id: <9608202111.AA25177@hickory.pa.dec.com>
To: Charles Watt <watt@sware.com>
Cc: perry@piermont.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Message of Tue, 20 Aug 1996 14:14:08 -0400 (EDT)
from Charles Watt <watt@sware.com>
<9608201814.AA01416@mordred.sware.com>
Date: Tue, 20 Aug 96 14:11:00 -0700
X-Mts: smtp
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Charles Watt says:
>> The bottom line: if you use a network layer security protocol to
>> propagate user-level information, you can cover perhaps 95% of current
>> use (you can invent a number just as easily as I) easily, but you will not
>> be able to cover everything. How critical is this shortfall? Well that's
>> rather dependent upon what you are doing, isn't it?
In a Mandatory Access Control world, perhaps this 5% shortfall is
a significant problem.
However, in less-rigorous environments it would seem a Good Thing
to offer user-level security to a broad majority of applications
without inventing yet another security infrastructure at application
level.
As long as IPSec enables security policies that restrict the form of
acceptable SA identities (e.g. to IP addresses), I can see little
reason to enforce such a limit by mandate.
However, I am concerned about your comments on the cost of "propagating"
user-level identity within the network code. How much of this cost
do you attribute to the nature of your MAC environment? I imagine
that for some protocol elements the job might have been straightforward,
and for others not. Does the majority of the cost come from fitting
square pegs into round holes?
Regards,
Ted Wobber
DEC Systems Research Center
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21910;
20 Aug 96 21:06 EDT
Received: by relay.hq.tis.com; id VAA18377; Tue, 20 Aug 1996 21:09:32 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma018375; Tue, 20 Aug 96 21:09:03 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA23224; Tue, 20 Aug 96 21:08:21 EDT
Received: by relay.hq.tis.com; id VAA18372; Tue, 20 Aug 1996 21:09:02 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma018369; Tue, 20 Aug 96 21:08:40 -0400
Received: from maildig1.us.oracle.com by inet-smtp-gw-1.us.oracle.com with SMTP (8.6.12/37.7)
id SAA27944; Tue, 20 Aug 1996 18:10:55 -0700
Received: by maildig1.us.oracle.com (5.65v3.2/37.8)
id AA16039; Tue, 20 Aug 1996 18:10:48 -0700
Message-Id: <9608210110.AA16039@maildig1.us.oracle.com>
Date: 20 Aug 96 18:11:05 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: AH in tunnel mode
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 20-Aug-96 12:38
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 2.1.16.0.0)
Content-Type: multipart/mixed; boundary="=_ORCL_24000549_0_11919608201911480"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_24000549_0_11919608201911480
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
>Personally, I've *never* understood the emphasis
>placed on "Transport mode"v.s. "Tunnel mode".
The distinctions came from discussions on the interoperability of "end system"
implementations and "intermediate system" implementations. It seems
reasonable to require support of a "tunnel mode" in an end system to ensure
interoperability of the two types of implementations. End system
implementations (aka transport mode) are easily developed that do not support
the tunnel mode.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Still hiring, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
--=_ORCL_24000549_0_11919608201911480
Content-Type:message/rfc822
Date: 20 Aug 96 12:38:19
From:"C. Harald Koch <chk@border.com>" <ipsec-request@neptune.hq.tis.com>
To:ipsec@tis.com
Subject:Re: AH in tunnel mode
References:<2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
In-Reply-To:Your message of "Tue, 20 Aug 1996 14:43:42 -0400". <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
Organization:Border Network Technologies Inc.
Phone:+1 416 368 7157
X-Uri:<URL:http://www.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
Sender:ipsec-approval@neptune.hq.tis.com
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
> I would like to know what people think about AH in tunnel mode. Ran
> suggested that I post this to the list to evoke some discussion and then add
> the following text either in the AH spec or write an informational document
> on using IPSec to build VPN's.
Is tunnelled AH prohibited anywhere? i.e.:
IP[fw1,fw2] | AH | IP[src,dst] | ULP
Since AH has a "next hop protocol" field, and a valid protocol is IP
(protocol #4), this should work fine (It does in my code :-).
Personally, I've *never* understood the emphasis placed on "Transport mode"
v.s. "Tunnel mode". There already exists a separate IP in IP document;
adding AH and/or ESP between the two IP headers was obvious to me.
I understand that specific security issues arise with this configuration,
but those should be listed, IMHO, as an implementation note, instead of
separating out IP from every other possible "next hop" protocol in the
standards.
Maybe I'm just missing something obvious. If so, I beg enlightenment...
--
C. Harald Koch | Border Network Technologies Inc.
chk@border.com | Senior System Developer
+1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8
+1 416 368 7789 (fax) | Madness takes its toll. Please have exact change.
--=_ORCL_24000549_0_11919608201911480--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14604;
20 Aug 96 16:46 EDT
Received: by relay.hq.tis.com; id QAA13297; Tue, 20 Aug 1996 16:49:03 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma013291; Tue, 20 Aug 96 16:48:52 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14478; Tue, 20 Aug 96 16:47:58 EDT
Received: by relay.hq.tis.com; id QAA13278; Tue, 20 Aug 1996 16:48:36 -0400
Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1.1)
id xma013272; Tue, 20 Aug 96 16:48:19 -0400
Received: by mercury.Sun.COM (Sun.COM)
id NAA24093; Tue, 20 Aug 1996 13:50:34 -0700
Received: from pacific.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
id NAA24557; Tue, 20 Aug 1996 13:50:11 -0700
Received: from dfs-1.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4)
id NAA17085; Tue, 20 Aug 1996 13:49:52 -0700
Received: by dfs-1.eng.sun.com (SMI-8.6/SMI-SVR4)
id NAA29148; Tue, 20 Aug 1996 13:48:08 -0700
Date: Tue, 20 Aug 1996 13:48:08 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608202048.NAA29148@dfs-1.eng.sun.com>
To: watt@sware.com, perry@piermont.com, mcr@milkyway.com
Subject: Re: "user" and "network layer" security mechanisms.
Cc: ipsec@TIS.COM
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From perry@piermont.com Tue Aug 20 10:31:38 1996
> NFS is a protocol that isn't suited to securing things on a per-user
> basis, but the key problem is that all NFS authentication is done (for
> practical purposes) by the client, with the server trusting that a
> client that has a file handle is allowed to claim to have any user
> credential it wants. There is no way, in NFS, to do the "logical
> thing" and check cryptographic credentials on a per file basis.
NFS implementations have been checking cryptographic credentials a per
file, user, and NFS request basis for nearly 10 years. That is
what NFS on AUTH_DES (rechristened AUTH_DH in a oncrpc wg draft of
an informational RFC) does. Ditto NFS on AUTH_KERB (Kerberos v4),
since 1992.
> From mcr@milkyway.com Tue Aug 20 10:16:17 1996
>> Two very specific examples where the proposed mechanisms fail:
>>
>> 1) Implementations of RFC 1006 - ISO transport on top of TCP. This is
>> heavily used within the DMS infrastructure. It allows multiple users
>> of an OSI application, such as X.500 or X.400, to make OSI transport
>> connections over TCP. For efficiency, most implementations of this
>> service will multiplex all concurrent sessions over a single TCP
>> connection, so there is no way to tell which IP datagram corresponds
>> to which user-level "security association" of the service.
> I see. This sounds like an application problem. Why is it more efficient
> to multiplex all sessions over a single TCP session? You've built a tunnel
> with TCP. Thus, you are reimplementing the network layer, and you will
> have to implement security there.
It is more efficient because additional TCP connections take up more resources.
Multiple TCP connections between the same client and server will unnecessarily
introduce scalability problems. For example, in a multithreaded environment,
where creating a new connection may require getting the write side of
a multi-reader/single write lock. As the # of connections grows, so does
the latency for creating the connection. Finally, using a single TCP connection
reduces congestion over slow/lossy routes.
> > 2) NFS. Most implementations of the NFS client operate with a fixed pool
> > of endpoints dedicated to the service. As a further complication, for
>
> NFS is inherently node-to-node as currently *implemented*, not
> user-to-server. You can not do user level security associations with currently
see my previous comments on AUTH_DH and AUTH_KERB.
> implemented NFS. I suggest you look at AFS. I do not know enough about
> Sprite's file sharing to comment where it would stand.
> I wish NFS would go away, but I do not have a better solution yet. Further,
> NFS doesn't have be implemented the way it is: we *could* push a user-server
NFS and AFS make use of the same vnode interfaces to access security
associations. The vnode interfaces all take a credential pointer that
has UNIX uid, gid, gid array etc. information. When NFS uses AUTH_DES
and AUTH_KERB, it simply takes the UNIX uid and maps to the security
association via one stored in an in-kernel cache, or if not cached, via
an upcall to the user-level helper daemon. AFS implementations go one
step futher to note that a particular UNIX user may want to assume more
than one "role". So the cred is either extended to contain the role
identfier, or a gid array entry is overloaded to contain the role
identifier.
> SA down the through the vnode interface. The write-behind/read-ahead is
> implemented by "processes" because of the way Unix works. It is implemented
> as kernel threads on many systems.
Simply attaching the UNIX credential or the security association to
each enqueued asynchornous NFS read-ahead or write-behind solves this,
regardless whether one uses threads or processes.
-mre
Received: from relay.hq.tis.com by neptune.TIS.COM id aa17024;
20 Aug 96 18:14 EDT
Received: by relay.hq.tis.com; id SAA15806; Tue, 20 Aug 1996 18:17:30 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma015802; Tue, 20 Aug 96 18:17:06 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19610; Tue, 20 Aug 96 18:16:19 EDT
Received: by relay.hq.tis.com; id SAA15798; Tue, 20 Aug 1996 18:16:59 -0400
Received: from soscorp.soscorp.com(204.52.248.130) by relay.tis.com via smap (V3.1.1)
id xma015791; Tue, 20 Aug 96 18:16:31 -0400
Received: from fearless.soscorp.com (fearless.soscorp.com [204.52.249.130]) by brimstone.soscorp.com ($Revision: 2.30 $/8.6.12/8.6.4.287) with BSMTP id BS0025775/SAA25778; Tue, 20 Aug 1996 18:18:44 -0400
Received: from fearless.soscorp.com (aggelos@localhost) by fearless.soscorp.com (8.6.12/8.6.4.287) with ESMTP id SAA29981; Tue, 20 Aug 1996 18:18:11 -0400
Message-Id: <199608202218.SAA29981@fearless.soscorp.com>
To: Charles Watt <watt@sware.com>
Cc: Matt Thomas <matt@lkg.dec.com>, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Tue, 20 Aug 1996 17:05:42 EDT."
<9608202105.AA01723@mordred.sware.com>
Date: Tue, 20 Aug 1996 18:18:05 -0400
From: "Angelos D. Keromytis" <aggelos@soscorp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
In message <9608202105.AA01723@mordred.sware.com>, Charles Watt writes:
>
>Pick at the specifics all you want, the basic point remains valid. The
>Internet stack was designed to permit multiplexing above IP. There are
>several things out there that do this. User-level authentication within
>IPSEC cannot work for these products unless they are substantially
>modified.
>
But what you're talking about is multiplexing above TCP.
In any case, i think user-level authentication will require specially
modified/writen applications, but that's no reason not to support it.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMho5mb0pBjh2h1kFAQEdrwP9GTeRv02XaY5Jj5Gujnn7Y8QAXM2zhtku
6vrBiVJO09nWkf8pKAYjidXflSA+zxKnJjGJ6u+kr9Dgo9l3bmt31wtVzryam93E
RGjgkjapceBj0Mc5smYVPR70rP66TWtlgb8hyIcNW8gLKGlLYzv5tNL6zH5NDz3K
LM8A52b4vyk=
=eA5h
-----END PGP SIGNATURE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21044;
20 Aug 96 20:34 EDT
Received: by relay.hq.tis.com; id UAA18060; Tue, 20 Aug 1996 20:38:02 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma018055; Tue, 20 Aug 96 20:37:33 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA22717; Tue, 20 Aug 96 20:36:51 EDT
Received: by relay.hq.tis.com; id UAA18048; Tue, 20 Aug 1996 20:37:32 -0400
Received: from puli.cisco.com(171.69.1.174) by relay.tis.com via smap (V3.1.1)
id xma018044; Tue, 20 Aug 96 20:37:13 -0400
Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id RAA01482; Tue, 20 Aug 1996 17:38:14 -0700
Date: Tue, 20 Aug 1996 17:38:14 -0700
From: Ran Atkinson <rja@cisco.com>
Message-Id: <199608210038.RAA01482@puli.cisco.com>
To: wobber@pa.dec.com
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: <9608202111.AA25177@hickory.pa.dec.com>
References: <watt@sware.com> <9608201814.AA01416@mordred.sware.com>
Organization: cisco Systems, Inc., Menlo Park, Ca.
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote:
>In a Mandatory Access Control world, perhaps this 5% shortfall is
>a significant problem.
In a MAC environment, such as a CMW, it is a hard requirement in the TCSEC
(including derivatives such as Red Book and equivalent specifications) that
the security attributes of objects be dependably propogated to all the
legitimately communicating endpoints.
Identity of the SA is just another security attribute to propogate. MAC
controls already require significant changes deep inside TCP/IP stacks.
(e.g. so that IP packets get correctly labeled using IPSO). Those changes are
so significant that it shouldn't be much additional work to add IPsec with
user-oriented keying as well.
As one of the few people on this list who have actually written both
IPsec code and MLS OS code, this is not idle speculation on my part.
I'm pretty sure that I could implement it inside BLS 8.09, for example,
(if I had access to BLS source code).
It is possible to design an MLS OS that makes IPsec difficult,
but the problem there is poor OS design not the IPsec per se. It is
similarly possible to design an OS that makes networking protocols
difficult, but that doesn't mean the TCP/IP specs are bad.
Now in non-MLS systems, unique SAs are also not very hard to implement. The
NRL IPsec code has always supported them, by way of providing an existence
proof.
>However, I am concerned about your comments on the cost of "propagating"
>user-level identity within the network code. How much of this cost
>do you attribute to the nature of your MAC environment? I imagine
>that for some protocol elements the job might have been straightforward,
>and for others not. Does the majority of the cost come from fitting
>square pegs into round holes?
Using BSD as an example, the kernel knows which process opened a socket and
also can dependably determine which uid owns that process, thereby determining
which uid should be associated with that socket. A privileged process can
fork/exec and change its identity after the socket has opened, but this is not
necessarily a security problem since it is a _privileged_ process. If an
unprivileged process can change its identity at will, then there are bigger
security problems within that system than IPsec could hope to help with.
In the BSD code, one can store security information about a socket inside
socket state. A pointer to that socket state can be added to the mbuf chain
that travels downward through the system. At points where the per-socket
security information needs to be checked, the backpointer can be used to read
it from socket state. Inbound data first gets checked against the minimum
system security level roughly during ip input processing. It gets checked a
second time, now against the security information stored in the destination
socket state, just before its handed up to the application. Adding identity
information to the security information associated with a socket is
straight-forward.
Ran
rja@cisco.com
Received: from relay.hq.tis.com by neptune.TIS.COM id aa01273;
21 Aug 96 2:51 EDT
Received: by relay.hq.tis.com; id CAA21186; Wed, 21 Aug 1996 02:54:50 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma021181; Wed, 21 Aug 96 02:54:23 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA28668; Wed, 21 Aug 96 02:53:39 EDT
Received: by relay.hq.tis.com; id CAA21176; Wed, 21 Aug 1996 02:54:20 -0400
Received: from radmail.rad.co.il(192.114.26.219) by relay.tis.com via smap (V3.1.1)
id xma021172; Wed, 21 Aug 96 02:54:04 -0400
Received: from radguard.com ([192.114.26.210]) by radmail.rad.co.il
(post.office MTA v1.9.3 ID# 0-12126) with SMTP id AAA29053;
Wed, 21 Aug 1996 09:58:09 +0300
Received: by radguard.com (4.1/SMI-4.1)
id AA01075; Wed, 21 Aug 96 09:56:45 IDT
Received: from elgamal.radguard.co.il(192.114.33.2) by gatekeeper.radguard.com via smap (V1.3)
id sma001073; Wed Aug 21 09:56:43 1996
Received: by elgamal.radguard.com (4.1/SMI-4.1)
id AA12071; Wed, 21 Aug 96 09:56:54 IDT
Date: Wed, 21 Aug 1996 09:56:54 +0300 (IDT)
From: Dan Frommer <dan@radguard.com>
To: Naganand Doraswamy <naganand@ftp.com>
Cc: ipsec@TIS.COM
Subject: Re: AH in tunnel mode
In-Reply-To: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
Message-Id: <Pine.SUN.3.91.960821092245.11256D-100000@elgamal.radguard.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
On Tue, 20 Aug 1996, Naganand Doraswamy wrote:
> I would like to know what people think about AH in tunnel mode. Ran
> suggested that I post this to the list to evoke some discussion and then add
> the following text either in the AH spec or write an informational document
> on using IPSec to build VPN's.
>
I believe tunnel mode in AH should be supported for the same reasons it is
supported in ESP. However, the existing drafts/RFCs should be made clear in
this area. Specifically, the following should be removed from
the architecture draft:
"While the Authentication Header might be implemented by a
security gateway on behalf of hosts on a trusted network behind
that security gateway, this mode of operation is not encouraged."
Tunnel mode in ESP is explicitly discussed in the drafts while the
AH documents seem to focus on "upper protocols". I vote for changing this.
Dan
Dan Frommer | Voice: +972-3-645-5396 | Email: dan@radguard.com
RADGUARD, Ltd. | Fax: +972-3-648-0859 |
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03901;
21 Aug 96 4:21 EDT
Received: by relay.hq.tis.com; id EAA21560; Wed, 21 Aug 1996 04:04:50 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma021558; Wed, 21 Aug 96 04:04:22 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA29585; Wed, 21 Aug 96 04:03:39 EDT
Received: by relay.hq.tis.com; id EAA21555; Wed, 21 Aug 1996 04:04:20 -0400
Received: from grosses-raetsel-tor.genua.de(193.141.169.26) by relay.tis.com via smap (V3.1.1)
id xma021545; Wed, 21 Aug 96 04:03:59 -0400
Received: (from smap@localhost) by Grosses-Raetsel-Tor.GeNUA.DE (8.6.12/8.6.12) id KAA26901; Wed, 21 Aug 1996 10:06:08 +0200
Received: from auryn.genua.de(192.109.217.42) by Grosses-Raetsel-Tor.GeNUA.DE via smap (V1.3)
id sma026897; Wed Aug 21 10:05:58 1996
Received: from auryn.genua.de (localhost [127.0.0.1]) by auryn.genua.de (8.7.4/8.7.3) with ESMTP id KAA23262; Wed, 21 Aug 1996 10:05:47 +0200 (MET DST)
Message-Id: <199608210805.KAA23262@auryn.genua.de>
To: Naganand Doraswamy <naganand@ftp.com>
Cc: ipsec@TIS.COM
Subject: Re: AH in tunnel mode
In-Reply-To: Your message of Tue, 20 Aug 1996 14:43:42 -0400.
<2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <23259.840614746.1@auryn.genua.de>
Date: Wed, 21 Aug 1996 10:05:46 +0200
From: Bernhard Schneck <Bernhard_Schneck@genua.de>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>you write:
> - Virtual Private Networks: If an organization is geographically separated
> and all the packets going from one subnet to the other needs to be
> authencticated, then the packets can be authenticated by the border
> gateways(routers). This is of value if and only if the border gateways dont
> accept any unauthenticated packets. The border gateways (routers) MUST NOT
> be willing to do key management or IPsec with nodes that are not authorised
> to participate in the VPN.
I assume if a filtering component supports tunnel mode AH, it will
have the capability to distinguish between packets received with and
without AH and combine this with IP filtering.
Eg: allow from <remote subnet> to <local subnet> if AH
deny from <remote subnet> to <local subnet> without AH
Anyone trying to spoof remote subnet addresses would have to spoof AH.
This should provide sufficient protection (IMHO, iff we trust AH).
As to doing key management with other entities, if you want to do
that you'll have to include filtering capabilities on SAs/SPIs
(``I'll do AH with anyone, but they won't be able use <remote subent>
adresses unless they use the SPI associated with that net'').
\Bernhard.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12879;
21 Aug 96 9:41 EDT
Received: by relay.hq.tis.com; id JAA26585; Wed, 21 Aug 1996 09:44:51 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma026578; Wed, 21 Aug 96 09:44:23 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA10586; Wed, 21 Aug 96 09:43:40 EDT
Received: by relay.hq.tis.com; id JAA26569; Wed, 21 Aug 1996 09:44:21 -0400
Received: from guardian.guard.ncsc.mil(144.51.52.1) by relay.tis.com via smap (V3.1.1)
id xma026556; Wed, 21 Aug 96 09:43:53 -0400
Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA19359 for <ipsec@TIS.COM>; Wed, 21 Aug 1996 09:46:06 -0400
Received: from depot(144.51.53.1) by guardian via smap (V1.3)
id sma019355; Wed Aug 21 09:45:52 1996
Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA21082 for <ipsec@TIS.COM>; Wed, 21 Aug 1996 09:42:35 -0400
Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4)
id JAA16060; Wed, 21 Aug 1996 09:45:42 -0400
Date: Wed, 21 Aug 1996 09:45:42 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Message-Id: <199608211345.JAA16060@argon.ncsc.mil>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From: Charles Watt <watt@sware.com>
>
> Pick at the specifics all you want, the basic point remains valid. The
> Internet stack was designed to permit multiplexing above IP. There are
> several things out there that do this. User-level authentication within
> IPSEC cannot work for these products unless they are substantially
> modified.
That point is not specific to IP, and no "additional restrictions" you
could place on IP or IPX or any other layer 3 protocol can prevent
tunnelling (and therefore multiplexing) through it - all communication
channels are equivalent. If you have a hypothetical "secure" system
that permits only bidirectional SMTP email, you can still establish
IP dataflow through it, and (with appropriate adjustment of timeouts),
TCP connections as well :-). Stick a PPP connection on top of that, and
you've got a layer 2 link running over a layer 7 protocol. The nesting
could continue ad infinitum.
So what?
The discussion seems to be motivated from two different viewpoints:
Mitch and Charlie say that there is no way to attach contexts or SPIs
to IP packets in a manner that will guarantee 100% MAC-grade
cryptographic separation based on anything other than IP addresses.
This is correct - there is only one SPI per IP packet, and if data
from two different "users" is placed into the packet, it must be separated
using some other mechanism.
They then argue that because IP-layer mechanisms cannot in general do MAC
based on anything other than IP addresses (a correct assertion), that the
IP protocol should not be permitted to use SPIs based on "users" or
"authenticated entities" or anything other than src and dst IP addresses.
That is the bottom-up view: design IP so that it advertises a simple
capability, and provides near-100% assurance that it does what it claims
to do.
The other viewpoint is top-down: there is a huge universe of applications
running on real customer networks that need to be "secured". We could do
it by modifying every single application and every application protocol to
provide security services at the highest layer, or we could recognize that
application protocols fall into classes, and that for some classes (those
that don't multiplex services for multiple "users" through a single
connection or process), a common IP-layer mechanism can be used without
modifying the higher layer protocols. Therefore it is reasonable to
provide the mechanism (an SPI field in the IP packet) that can in some
cases be used to achieve separation between "users" at the network layer.
There is a unique window of opportunity where the entire industry will
replace their IP stacks and kernel code to accommodate IPv4/IPsec or IPv6.
It makes sense to make the kernel-level code as general as possible while
that window is open. If we later find that nearly all applications
have become RPC-based and subject to RPC security mechanisms, and
user-based IP keying is not worth the effort, then the key management
daemons can be yanked and replaced with something trivial that does
keying based on IP addresses. In that case the SPI becomes redundant
but harmless (and it still provides an efficiency benefit over using IP
addresses directly to look up SAs for each packet).
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13869;
21 Aug 96 10:23 EDT
Received: by relay.hq.tis.com; id KAA28145; Wed, 21 Aug 1996 10:26:54 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma028139; Wed, 21 Aug 96 10:26:23 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA13398; Wed, 21 Aug 96 10:25:40 EDT
Received: by relay.hq.tis.com; id KAA28136; Wed, 21 Aug 1996 10:26:21 -0400
Received: from ftp.com(128.127.2.122) by relay.tis.com via smap (V3.1.1)
id xma028130; Wed, 21 Aug 96 10:26:01 -0400
Received: from ftp.com by ftp.com ; Wed, 21 Aug 1996 10:28:09 -0400
Received: from athena.ftp.com by ftp.com ; Wed, 21 Aug 1996 10:28:09 -0400
Message-Id: <2.2.32.19960821143312.00afc928@mailserv-H.ftp.com>
X-Sender: naganand@mailserv-H.ftp.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Aug 1996 10:33:12 -0400
To: "C. Harald Koch" <chk@border.com>
From: Naganand Doraswamy <naganand@ftp.com>
Subject: Re: AH in tunnel mode
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>Is tunnelled AH prohibited anywhere? i.e.:
>
> IP[fw1,fw2] | AH | IP[src,dst] | ULP
>
>Since AH has a "next hop protocol" field, and a valid protocol is IP
>(protocol #4), this should work fine (It does in my code :-).
>
No, it is not prohibited anywhere. Just that it is not specificed anywhere!
--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)
To: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer", continuation and reply.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 10:26:31 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211033.aa14042@neptune.TIS.COM>
"Mitchell C. Nelson" writes:
> My point is that the term "user" does not belong in a discussion
> of network layer security mechanisms.
I'm afraid it does, because security models have to deal with the
notion of user. See, for example, the entire issue of mutually hostile
users (and cut and paste attacks). Discussion of the security
properties of the system under such circumstances mandates the
inclusion of a notion of the user.
It is impossible to discuss the question of a cryptographic system's
security absent a discussion of which entities are doing the
encrypting and holding the keys.
As it stands, IPSEC has been engineered so that a key management
protocol (like Photuris or Oakley) may exchange keys that are assigned
TO USERS, and use them to set up SPIs for use with specific
machine-to-machine connections. You may feel that "this does not
belong" or some such, but I'm afraid its what we are doing, and
frankly I don't understand whats wrong with it.
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14307;
21 Aug 96 10:43 EDT
Received: by relay.hq.tis.com; id KAA29087; Wed, 21 Aug 1996 10:46:52 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma029063; Wed, 21 Aug 96 10:46:26 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14718; Wed, 21 Aug 96 10:45:41 EDT
Received: by relay.hq.tis.com; id KAA29051; Wed, 21 Aug 1996 10:46:22 -0400
Received: from bastion.sware.com(139.131.15.2) by relay.tis.com via smap (V3.1.1)
id xma029041; Wed, 21 Aug 96 10:45:53 -0400
Received: from zeus.sware.com (zeus.sware.com [139.131.1.166]) by bastion.sware.com (8.6.12/8.6.5) with ESMTP id KAA03560; Wed, 21 Aug 1996 10:45:26 -0400
Received: by zeus.sware.com (1.39.111.2/2.0) from mordred.sware.com id AA063608741; Wed, 21 Aug 1996 10:45:41 -0400
Received: by mordred.sware.com (5.65/2.1) id AA03215; Wed, 21 Aug 96 10:37:31 -0400
Message-Id: <9608211437.AA03215@mordred.sware.com>
Subject: Re: "user" and "network layer" security mechanisms.
To: Ran Atkinson <rja@cisco.com>
Date: Wed, 21 Aug 1996 10:37:30 -0400 (EDT)
From: Charles Watt <watt@sware.com>
Cc: wobber@pa.dec.com, ipsec@TIS.COM
In-Reply-To: <199608210038.RAA01482@puli.cisco.com> from "Ran Atkinson" at Aug 20, 96 05:38:14 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3846
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
AWd7XZSqrLcfeKkY0N7/FKl/aheROPx38aIYGK+TN5naLv38zvqbH8Ofrk22FKtZ
BqqzUxt2qwYySKMBl7zz42U=
>Ran Atkinson wrote:
>
>In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote:
>>In a Mandatory Access Control world, perhaps this 5% shortfall is
>>a significant problem.
>
>In a MAC environment, such as a CMW, it is a hard requirement in the TCSEC
>(including derivatives such as Red Book and equivalent specifications) that
>the security attributes of objects be dependably propogated to all the
>legitimately communicating endpoints.
>
>Identity of the SA is just another security attribute to propogate. MAC
>controls already require significant changes deep inside TCP/IP stacks.
>(e.g. so that IP packets get correctly labeled using IPSO). Those changes are
>so significant that it shouldn't be much additional work to add IPsec with
>user-oriented keying as well.
>
>As one of the few people on this list who have actually written both
>IPsec code and MLS OS code, this is not idle speculation on my part.
>I'm pretty sure that I could implement it inside BLS 8.09, for example,
>(if I had access to BLS source code).
So have I. I also wrote most of the BLS 8.09 networking code. It
is precisely this experience that makes me rather insistent on this
issue. Adding user-level SA tracking as another security attribute
within an MLS stack would be easy -- only because they have invested
tremendously in building an infrastructure to pass such attributes up
and down the stack.
>Now in non-MLS systems, unique SAs are also not very hard to implement. The
>NRL IPsec code has always supported them, by way of providing an existence
>proof.
>
>>However, I am concerned about your comments on the cost of "propagating"
>>user-level identity within the network code. How much of this cost
>>do you attribute to the nature of your MAC environment? I imagine
>>that for some protocol elements the job might have been straightforward,
>>and for others not. Does the majority of the cost come from fitting
>>square pegs into round holes?
>
>Using BSD as an example, the kernel knows which process opened a socket and
>also can dependably determine which uid owns that process, thereby determining
>which uid should be associated with that socket. A privileged process can
>fork/exec and change its identity after the socket has opened, but this is not
>necessarily a security problem since it is a _privileged_ process. If an
>unprivileged process can change its identity at will, then there are bigger
>security problems within that system than IPsec could hope to help with.
>
>In the BSD code, one can store security information about a socket inside
>socket state. A pointer to that socket state can be added to the mbuf chain
>that travels downward through the system. At points where the per-socket
>security information needs to be checked, the backpointer can be used to read
>it from socket state. Inbound data first gets checked against the minimum
>system security level roughly during ip input processing. It gets checked a
>second time, now against the security information stored in the destination
>socket state, just before its handed up to the application. Adding identity
>information to the security information associated with a socket is
>straight-forward.
And then again, there are services that manage a pool of sockets within
the kernel, such as any kernel RPC service and many implementations of
the TSAP. These sockets are opened and initialized by daemon helpers when
the service is initialized. They are used by whichever process requests
access to the service. The approach Ran gives above will authenticate the
user of the service as if he/she were the daemon process, unless, of course,
the application is modified to understand the kernel hacks required for
IPSEC user authentication.
The question remains, is 95% coverage sufficient?
Charlie Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14341;
21 Aug 96 10:45 EDT
Received: by relay.hq.tis.com; id KAA29170; Wed, 21 Aug 1996 10:48:22 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma029164; Wed, 21 Aug 96 10:48:02 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14931; Wed, 21 Aug 96 10:47:14 EDT
Received: by relay.hq.tis.com; id KAA29150; Wed, 21 Aug 1996 10:47:52 -0400
Received: from sdnhq.undp.org(192.124.42.79) by relay.tis.com via smap (V3.1.1)
id xma029144; Wed, 21 Aug 96 10:47:50 -0400
Received: (from uucp@localhost) by sdnhq.undp.org (8.7.5/8.6.9) with UUCP id JAA12228 for ipsec@tis.com; Wed, 21 Aug 1996 09:17:35 -0400
Received: from sunpak.UUCP by sdnpk.undp.org (8.6.12/8.6.12) with UUCP id QAA28678 for ipsec@tis.com; Wed, 21 Aug 1996 16:50:05 +0500
Message-Id: <199608211150.QAA28678@sdnpk.undp.org>
Received: from ashar@sunpak by sunpak.sdnpk.undp.org
(PMail+UDG PegWaf v0.26 93.04.04) id 2044 for ipsec@tis.com;
Wed, 21 Aug 1996 12:42:27 PST +0500
From: Ashar Aziz <ashar@sunpak.sdnpk.undp.org>
To: mcr@milkyway.com
Date: Wed, 21 Aug 1996 12:42:25 +0000
Subject: Re: SPIs and SKIP (was "user" and "network" ..)
Cc: ipsec@TIS.COM
X-Confirm-Reading-To: ashar@sunpak.sdnpk.undp.org (Ashar Aziz)
X-Pmrqc: 1
Priority: normal
X-Mailer: Pegasus Mail for Windows (v2.01)
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>From: Michael Richardson <mcr@milkyway.com>
> To: ipsec@TIS.COM
> Subject: Re: "user" and "network layer" security mechanisms.
> Huh?
> Who said anything about UDP or TCP?
> IPsec has an SPI. *That* is the unambiguous link between packets and
> *all* security associations, whether they be user or node ones.
> One of my major problems with SKIP is that it effectively kills the SPI
> as a useful concept.
An SPI essentially provides the implementation with a
handle to process an ipsec packet. Conceptually, one
can visualize this as a table, indexed by the SPI,
where the table entry contains the attributes (crypto
variables like keys, algorithms, principal ids, etc.)
for processing the packet. There is no constraint on
what this table entry can contain.
With SKIP, one can visualize the table entry for the
SKIP SPI to essentially say: look in another place
for some of the attributes you need; namely the buffer that
contains the received packet. Essentially, all the
same information that one obtains directly from the
contents of the table entry can be obtained from this
other location in system memory.
Keep in mind that some of the crypto-variables are
contained in the packet header, even with alternative
approaches (e.g. IVs). The distinction then essentially
becomes which part of memory some of the attribute
information is obtained from. I don't view this as killing
the SPI as a useful concept. This is merely another
(legitimate) way of using the SPI in order to get different,
and in certain important application scenarious, highly
desirable protocol properties both from a cryptographic
and a network point of view.
Ashar.
To: Derek Atkins <warlord@mit.edu>
Cc: Charles Watt <watt@sware.com>, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 10:58:25 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211058.aa14732@neptune.TIS.COM>
Derek Atkins writes:
> Huh? The fact that authentication is done at the client is an
> implementation detail. It is implement that way, IMHO, because there
> is no "secure" way for the server to know what access rights the
> client has. However, that is in no way a requirement of the NFS
> protocol.
You could, of course, change that, but then it wouldn't be NFS, it
would be a new protocol.
> You could easily change the RPC Security flavor to do something
> different and implement the server such that access checks are
> performed there as well.
However, the complexity you would have to add to the RPC Security
flavor would be sufficient that you really wouldn't have a right to
call it NFS any more -- it would be "NFS plus a whole lot of extra
stuff". You need more than IPSEC -- you end up needing a fairly
complex security handshake on top, and THEN your NFS stuff would be
secured.
> So, your statement about there being "no way" is just plain wrong.
> OTOH, it would take a lot of programming to change the
> implementation to "do the logical thing". But I believe it is
> possible.
I'm not saying that you can't build secure file systems, or that they
can't even look nearly like NFS. However, when you are done, it isn't
going to be NFS any longer. This is very much unlike, say, Telnet,
where just by making the server understand SPIs a bit you could
implement per user authentication.
Perry
To: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Tue, 20 Aug 1996 14:14:08 EDT."
<9608201814.AA01416@mordred.sware.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 11:03:26 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211104.aa14983@neptune.TIS.COM>
Charles Watt writes:
> >The SPI number in the packet is perfectly suitable for this
> >purpose. The real issue is being able to negotiate the use of a
> >particular SPI for a particular connection -- thats a
> >Photuris/Oakley/ISAKMP/Whatever issue.
>
> I think you are missing the point Perry. For example, if you have six
> concurrent users of an X.400 product that makes use of an RFC 1006
Ah, unless I've lost my brain this week, X.400 is a mail
protocol. Mail systems need to secure the messages, not the links. You
could argue that IPSEC is unsuitable for the user level securing of
SMTP transmissions, and I'd agree. Protocols like that need to have
the underlying messages encrypted -- the transport doesn't matter. No
need to couch this in complex OSI protocol terms.
People often miss this point. Securing the link is suitable for
protocols like Telnet. Protocols like SMTP need the DATA secured, not
the link, although to add some traffic analysis protection one might
want to secure the link too. Protocols like FTP fall somewhere in
between, where one often has a desire to get a signature on the DATA,
but in which there will probably be benefits to assuring that the
control link has been kept secure.
Perry
Date: Wed, 21 Aug 1996 09:27:59 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608211627.JAA29477@dfs-1.eng.sun.com>
To: warlord@mit.edu, perry@piermont.com
Subject: Re: "user" and "network layer" security mechanisms.
Cc: watt@sware.com, ipsec@TIS.COM
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From perry@piermont.com Wed Aug 21 08:40:30 1996
> Derek Atkins writes:
> > Huh? The fact that authentication is done at the client is an
> > implementation detail. It is implement that way, IMHO, because there
> > is no "secure" way for the server to know what access rights the
> > client has. However, that is in no way a requirement of the NFS
> > protocol.
>
> You could, of course, change that, but then it wouldn't be NFS, it
> would be a new protocol.
The NFS protocol speciification doesn't mandate host-centric security
and access control.
> > You could easily change the RPC Security flavor to do something
> > different and implement the server such that access checks are
> > performed there as well.
>
> However, the complexity you would have to add to the RPC Security
> flavor would be sufficient that you really wouldn't have a right to
> call it NFS any more -- it would be "NFS plus a whole lot of extra
huh? Have you been paying attention to my earlier e-mail message on AUTH_DH,
and AUTH_KERB. Are you claiming that people who run NFS over either of
those two RPC security flavors are in fact not running NFS? A brief lesson:
NFS runs on onc rpc. rpc headers contain (among other things), a flavor #
following by credential information that can used for crypto authentication.
NFS (and other onc applications) treats RPC security as a protocol
layer. Claiming that NFS on on flavor other than AUTH_SYS is no
longer NFS would be like saying that NFS on a transport other
UDP, a network other than IP, or a media other than 10baseT, is no longer
NFS.
> stuff". You need more than IPSEC -- you end up needing a fairly
> complex security handshake on top, and THEN your NFS stuff would be
> secured.
Proven wrong by existance proof.
-mre
To: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 11:57:18 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211227.aa17069@neptune.TIS.COM>
Charles Watt writes:
> Upon review of the spec, you are correct. It appears that my memory is not
> immune to age afterall. However, I've looked at the source to our vendor's
> RFC 1006 streams module and the basic problem remains. It internally
> manages a pool of TCP endpoints, maintaining its own internal binding
Thats an implementation issue, not a problem in the spec.
> Pick at the specifics all you want, the basic point remains valid. The
> Internet stack was designed to permit multiplexing above IP. There are
> several things out there that do this. User-level authentication within
> IPSEC cannot work for these products unless they are substantially
> modified.
Look, the fact that you have to store SPIs in the TCBs of most
implementations makes for a significant change. No one said this was
painless. It is, however, a pretty good solution, architecturally.
Perry
Message-Id: <199608211640.JAA27077@puli.cisco.com>
From: Ran Atkinson <rja@cisco.com>
Date: Wed, 21 Aug 1996 09:40:02 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I'm glad there is now general agreement that user-oriented keying is not
particularly hard to implement in an MLS system and that folks understand
the practicality of implementing this inside BSD. I've never worked inside
STREAMS, but people with STREAMS clue tell me it can also be done there,
albeit using different implementation strategies.
On Aug 21, 10:37am, Charles Watt wrote:
% And then again, there are services that manage a pool of sockets within the
% kernel, such as any kernel RPC service and many implementations of the TSAP.
% These sockets are opened and initialized by daemon helpers when the service
% is initialized. They are used by whichever process requests access to the
% service. The approach Ran gives above will authenticate the user of the
% service as if he/she were the daemon process, unless, of course, the
% application is modified to understand the kernel hacks required for IPSEC
% user authentication.
There are a relatively small number of such cases in a typical UNIX system.
The needed modifications are, IMO, not terribly difficult or terribly
time-consuming to make, based on my examination of ONC RPC specifications and
the freely distributable TI-RPC sources a bit over a year ago. Had I remained
at my previous job, I would have been building this sometime in 1997 because
it was in my Statement of Work from ARPA to do precisely that.
As it happens, I think the big hurdle here would be agreement on what the
appropriate API extensions would look like. I suspect that GSS-API could be
used, though some might argue that is too heavyweight an API for this purpose.
I suspect that API extensions based on BSD Sockets would be most widely
useful.
Ran
rja@cisco.com
--
To: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Cc: warlord@mit.edu, perry@piermont.com, watt@sware.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 13:54:28 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211358.aa19218@neptune.TIS.COM>
Michael R. Eisler writes:
> huh? Have you been paying attention to my earlier e-mail message on AUTH_DH,
> and AUTH_KERB. Are you claiming that people who run NFS over either of
> those two RPC security flavors are in fact not running NFS? A brief lesson:
> NFS runs on onc rpc. rpc headers contain (among other things), a flavor #
> following by credential information that can used for crypto authentication.
I think we are having a semantic argument. I believe we both agree on
what the NFS spec contains and how NFS gets transported. I believe the
difference of opinion is about what we are calling things.
Yes, there are hooks in NFS that let you do lots of stuff that would
let you secure file access with various flavors of secure
RPC. However, I think of ONC RPC as being part and parcel of NFS -- it
is the major application of ONC RPC -- and a secure RPC that hooks
into the IPSEC stuff and provides user granularity file access is
nontrivial. Therefore, permit me to say that within these semantic
constraints NFS *as it stands* could not be made user granularity
secure using IPSEC in the trivial manner that, say, Telnet can (that
is, with no protocol additions other than IPSEC and Photuris or Oakley
or what have you, and with minimal source changes to the
server). However, certainly you could extend the secure RPC mechanisms
do things analagous to the AUTH_KERB hacks with IPSEC. I'm just
arguing that this is no longer NFS in the sense that a machine that
had IPSEC and a key management system added to it is still going to
require extensive hacking to get the NFS security working. Its not
"vanilla NFS".
Perry
Date: Wed, 21 Aug 1996 10:27:54 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608211727.KAA29531@dfs-1.eng.sun.com>
To: ipsec@TIS.COM, dpkemp@missi.ncsc.mil
Subject: Re: "user" and "network layer" security mechanisms.
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From dpkemp@missi.ncsc.mil Wed Aug 21 07:37:18 1996
> The other viewpoint is top-down: there is a huge universe of applications
> running on real customer networks that need to be "secured". We could do
> it by modifying every single application and every application protocol to
> provide security services at the highest layer, or we could recognize that
> application protocols fall into classes, and that for some classes (those
> that don't multiplex services for multiple "users" through a single
> connection or process), a common IP-layer mechanism can be used without
> modifying the higher layer protocols. Therefore it is reasonable to
> provide the mechanism (an SPI field in the IP packet) that can in some
> cases be used to achieve separation between "users" at the network layer.
Seems reasonable to me.
For those of us who are "securing" application protocols that aren't
members of the class that can use IP-layer user-oriented security, it
would be most helpful to have IPSEC "officially" recognize the position
that David succinctly stated above.
-mre
Received: from relay.hq.tis.com by neptune.TIS.COM id aa23596;
21 Aug 96 16:43 EDT
Received: by relay.hq.tis.com; id QAA09646; Wed, 21 Aug 1996 16:46:36 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma009638; Wed, 21 Aug 96 16:46:12 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA08771; Wed, 21 Aug 96 16:45:25 EDT
Received: by relay.hq.tis.com; id QAA09629; Wed, 21 Aug 1996 16:46:06 -0400
Received: from inet-smtp-gw-1.us.oracle.com(192.86.155.81) by relay.tis.com via smap (V3.1.1)
id xma009598; Wed, 21 Aug 96 16:45:35 -0400
Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id NAA28222; Wed, 21 Aug 1996 13:47:47 -0700
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id NAA23019; Wed, 21 Aug 1996 13:39:57 -0700
Message-Id: <199608212039.NAA23019@mailsun2.us.oracle.com>
Date: 21 Aug 96 13:34:02 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 21-Aug-96 08:57
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.2.1.40)
Content-Type: multipart/mixed; boundary="=_ORCL_6749253_0_11919608211440570"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_6749253_0_11919608211440570
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
>Charles Watt writes:
> Internet stack was designed to permit multiplexing above IP. There are
> several things out there that do this. User-level authentication within
> IPSEC cannot work for these products unless they are substantially
> modified.
No. Most computers today are single user. Multiplexing above IP does not
matter for authentication purposes when all the applications above IP are
owned by the same "user".
The issues of a "user oriented" IPsec in a compartmentalized workstation is
difficult. The CMW market is very different from the "real" world and we
should be careful not mix the requirements of the two environments.
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Last chance, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
--=_ORCL_6749253_0_11919608211440570
Content-Type:message/rfc822
Date: 21 Aug 96 08:57:18
From:"Perry E. Metzger <perry@piermont.com>" <ipsec-request@neptune.hq.tis.com>
To:Charles,Watt,<watt@sware.com>
Subject:Re: "user" and "network layer" security mechanisms.
Cc:ipsec@tis.com
Reply-to:perry@piermont.com
X-Reposting-Policy:redistribute only with permission
Sender:ipsec-approval@neptune.hq.tis.com
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
Charles Watt writes:
> Upon review of the spec, you are correct. It appears that my memory is not
> immune to age afterall. However, I've looked at the source to our vendor's
> RFC 1006 streams module and the basic problem remains. It internally
> manages a pool of TCP endpoints, maintaining its own internal binding
Thats an implementation issue, not a problem in the spec.
> Pick at the specifics all you want, the basic point remains valid. The
> Internet stack was designed to permit multiplexing above IP. There are
> several things out there that do this. User-level authentication within
> IPSEC cannot work for these products unless they are substantially
> modified.
Look, the fact that you have to store SPIs in the TCBs of most
implementations makes for a significant change. No one said this was
painless. It is, however, a pretty good solution, architecturally.
Perry
--=_ORCL_6749253_0_11919608211440570--
Message-Id: <2.2.32.19960821203151.009bce18@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Aug 1996 16:31:51 -0400
To: Michael Richardson <mcr@milkyway.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 12:33 PM 8/20/96 -0400, Michael Richardson wrote:
>
> I see. This sounds like an application problem. Why is it more efficient
>to multiplex all sessions over a single TCP session? You've built a tunnel
>with TCP. Thus, you are reimplementing the network layer, and you will
>have to implement security there.
there are many good arguments for where it makes sense to multiplex over
TCP. A terminal server to a specific server is an excellent example where
multiplexing reduced network traffic 90%.
This only proves that there are scope limits on IPsec, where special cases
make life interesting.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Message-Id: <2.2.32.19960821203154.009c5fb0@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Aug 1996 16:31:54 -0400
To: Michael.Eisler@eng.sun.com, perry@piermont.com, watt@sware.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "user" and "network layer" security mechanisms.
Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 09:00 AM 8/20/96 -0700, Michael R. Eisler wrote:
>
>I am curious if anyone has implemented IPSEC with user-level security
>associations, and whether the associations are bound at the time the
>end-point is open or if they are switchable with each outgoing
>datagram. If the latter, is the I/O framework asynchronous or not? An
>existance proof might make me less pessimistic about end-user IPSEC.
For me my view is end-user IPsec occurs for mobile notebooks. It is the
user of the notebook cert that gets used in setting up the SPI, not the
notebooks.
After all, I have my own security card that I would plug into the PCMCIA card.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Message-Id: <2.2.32.19960821204459.009a98ec@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 21 Aug 1996 16:44:59 -0400
To: Naganand Doraswamy <naganand@ftp.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: AH in tunnel mode
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 02:43 PM 8/20/96 -0400, Naganand Doraswamy wrote:
>
>Using AH in tunnel mode has the same security implications as using ESP in
>tunneled mode (refer to Ran's comments on this).
But how do you distiguish when AH is enough?
The answer is when it covers an ESP for end-to-end.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa26246;
21 Aug 96 18:44 EDT
Received: by relay.hq.tis.com; id SAA12353; Wed, 21 Aug 1996 18:48:06 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma012351; Wed, 21 Aug 96 18:47:38 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15089; Wed, 21 Aug 96 18:46:55 EDT
Received: by relay.hq.tis.com; id SAA12348; Wed, 21 Aug 1996 18:47:36 -0400
Received: from toad.com(140.174.2.1) by relay.tis.com via smap (V3.1.1)
id xma012346; Wed, 21 Aug 96 18:47:28 -0400
Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id PAA02328; Wed, 21 Aug 1996 15:49:43 -0700 (PDT)
Message-Id: <199608212249.PAA02328@toad.com>
X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: ipsec@TIS.COM, gnu@toad.com
Subject: Idea: Prizes for protocol problems in key agreement
Date: Wed, 21 Aug 1996 15:49:42 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Cliff Stoll's talk here at Crypto '96 mentioned that crypto is all
about trust, and that trust comes from a process of suspicion,
followed by scrutiny, followed by trust if no problems are found. You
can also see this as a Quality Assurance procedure.
Given the current state of IPSEC key agreement protocols, I am
thinking it would be prudent to run a competition for people to
scrutinize some candidate key agreement protocols (e.g. Photuris,
SKIP, ISAKMP/Oakley, and whatever comes out of the smoke-filled room).
I have a serious concern that we'll end up standardizing on a protocol
that has not had the scrutiny required to validate its security. For
this audience I need not point out that if the key agreement protocol
is insecure or subvertible, it doesn't matter how strong our packet
encryption is, nor how solid our public-key infrastructure is.
I'm particularly concerned that Photuris has not had recent scrutiny,
that ISAKMP/Oakley is sufficiently complex and new that it has not
been fully defined or analyzed, and that the smoke-filled protocol, if
any, will of course be new and need critical examination.
EFF has recently decided that they want to help my S/WAN efforts to
deploy IPSEC technology widely and rapidly. I'm thinking of funding
prizes that EFF would offer for protocol problems found and posted to
the IPSEC mailing list. The kinds of things that would qualify as
"problems" include:
* Revealing session keys or parts thereof to observers or attackers
* Revealing private keys or parts thereof to observers or attackers
* Enabling session keys to be forced to known or partly-known values
* Inability to scale to daily use on the entire Internet
* Revealing user identities to observers (if user keying is involved)
* Failure to provide perfect forward secrecy for packet traffic
* Enabling traffic to move in the clear which should be encrypted
* Designs that are trivial to circumvent or bypass
My current thought is that the "best" problems will win more money and
glory, but that everyone who finds a legitimate problem (in the
judges' opinion) will get some money and glory out of it.
I hope that we can do something similar for some of the reference
implementations, once the protocols are nailed down.
There might be big money for the protocol authors here -- they can
define buggy protocols and then collect by pointing out the problems!
But I think the increased general scrutiny is worth that risk.
Does anyone have objections to this kind of quality assurance process?
Please give me your reactions and suggestions about this idea.
Suggestions for a set of standards to judge the protocols against would
be particularly useful. Also suggestions on the appropriate sizes,
numbers, and categories of prizes, and potential judges.
John Gilmore
'an equal opportunistic encryptor'
Received: from relay.hq.tis.com by neptune.TIS.COM id aa03633;
22 Aug 96 1:50 EDT
Received: by relay.hq.tis.com; id BAA17724; Thu, 22 Aug 1996 01:17:58 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma017715; Thu, 22 Aug 96 01:17:28 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA20956; Thu, 22 Aug 96 01:16:45 EDT
Received: by relay.hq.tis.com; id BAA17712; Thu, 22 Aug 1996 01:17:27 -0400
Received: from necom830.hpcl.titech.ac.jp(131.112.32.132) by relay.tis.com via smap (V3.1.1)
id xma017708; Thu, 22 Aug 96 01:17:17 -0400
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199608220519.OAA13272@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id OAA13272; Thu, 22 Aug 1996 14:18:50 +0859
Subject: Re: "user" and "network layer" security mechanisms.
To: Ran Atkinson <rja@cisco.com>
Date: Thu, 22 Aug 96 14:18:50 JST
Cc: wobber@pa.dec.com, ipsec@TIS.COM
In-Reply-To: <199608210038.RAA01482@puli.cisco.com>; from "Ran Atkinson" at Aug 20, 96 5:38 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote:
>In a Mandatory Access Control world, perhaps this 5% shortfall is
>a significant problem.
What many people are using today is weak security.
With network layer real security, we can make weak security secured,
but nothing more than that.
Network layer security may satisfy 95% of today's case, only because
they are using weak security today.
But, secured weak security is not real security.
Masataka Ohta
Received: from relay.hq.tis.com by neptune.TIS.COM id aa13656;
22 Aug 96 12:56 EDT
Received: by relay.hq.tis.com; id MAA00679; Thu, 22 Aug 1996 12:59:33 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma000652; Thu, 22 Aug 96 12:59:05 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA14450; Thu, 22 Aug 96 12:58:21 EDT
Received: by relay.hq.tis.com; id MAA00645; Thu, 22 Aug 1996 12:59:03 -0400
Received: from mercury.sun.com(192.9.25.1) by relay.tis.com via smap (V3.1.1)
id xma000628; Thu, 22 Aug 96 12:58:43 -0400
Received: by mercury.Sun.COM (Sun.COM)
id KAA11027; Thu, 22 Aug 1996 10:00:52 -0700
Received: from packmind.Corp.Sun.COM by Corp.Sun.COM (5.x/SMI-5.3)
id AA29366; Thu, 22 Aug 1996 10:00:46 -0700
Received: by packmind.Corp.Sun.COM (SMI-8.6/SMI-SVR4)
id KAA08761; Thu, 22 Aug 1996 10:00:10 -0700
Date: Thu, 22 Aug 1996 10:00:10 -0700
From: Alan Monday-Internet Commerce Group <Alan.Monday@corp.sun.com>
Message-Id: <199608221700.KAA08761@packmind.Corp.Sun.COM>
To: ipsec@TIS.COM, gnu@toad.com
Subject: Re: Idea: Prizes for protocol problems in key agreement
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I like this idea. I would add to the "problems" list:
* Designs that can't be used for secure multicast applications
* Designs that support Key Escrow
* Designs that have only partial implementation
Alan
> From gnu@toad.com Thu Aug 22 05:50:04 1996
> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
> To: ipsec@TIS.COM, gnu@toad.com
> Subject: Idea: Prizes for protocol problems in key agreement
> From: John Gilmore <gnu@toad.com>
> Sender: ipsec-approval@neptune.tis.com
> Precedence: bulk
> Content-Length: 2851
> X-Lines: 55
>
> Cliff Stoll's talk here at Crypto '96 mentioned that crypto is all
> about trust, and that trust comes from a process of suspicion,
> followed by scrutiny, followed by trust if no problems are found. You
> can also see this as a Quality Assurance procedure.
>
> Given the current state of IPSEC key agreement protocols, I am
> thinking it would be prudent to run a competition for people to
> scrutinize some candidate key agreement protocols (e.g. Photuris,
> SKIP, ISAKMP/Oakley, and whatever comes out of the smoke-filled room).
> I have a serious concern that we'll end up standardizing on a protocol
> that has not had the scrutiny required to validate its security. For
> this audience I need not point out that if the key agreement protocol
> is insecure or subvertible, it doesn't matter how strong our packet
> encryption is, nor how solid our public-key infrastructure is.
>
> I'm particularly concerned that Photuris has not had recent scrutiny,
> that ISAKMP/Oakley is sufficiently complex and new that it has not
> been fully defined or analyzed, and that the smoke-filled protocol, if
> any, will of course be new and need critical examination.
>
> EFF has recently decided that they want to help my S/WAN efforts to
> deploy IPSEC technology widely and rapidly. I'm thinking of funding
> prizes that EFF would offer for protocol problems found and posted to
> the IPSEC mailing list. The kinds of things that would qualify as
> "problems" include:
>
> * Revealing session keys or parts thereof to observers or attackers
> * Revealing private keys or parts thereof to observers or attackers
> * Enabling session keys to be forced to known or partly-known values
> * Inability to scale to daily use on the entire Internet
> * Revealing user identities to observers (if user keying is involved)
> * Failure to provide perfect forward secrecy for packet traffic
> * Enabling traffic to move in the clear which should be encrypted
> * Designs that are trivial to circumvent or bypass
>
> My current thought is that the "best" problems will win more money and
> glory, but that everyone who finds a legitimate problem (in the
> judges' opinion) will get some money and glory out of it.
>
> I hope that we can do something similar for some of the reference
> implementations, once the protocols are nailed down.
>
> There might be big money for the protocol authors here -- they can
> define buggy protocols and then collect by pointing out the problems!
> But I think the increased general scrutiny is worth that risk.
>
> Does anyone have objections to this kind of quality assurance process?
>
> Please give me your reactions and suggestions about this idea.
> Suggestions for a set of standards to judge the protocols against would
> be particularly useful. Also suggestions on the appropriate sizes,
> numbers, and categories of prizes, and potential judges.
>
> John Gilmore
> 'an equal opportunistic encryptor'
>
Message-Id: <3.0b11.32.19960823114911.00a68238@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 23 Aug 1996 11:58:14 -0400
To: Alan.Monday@corp.sun.com, ipsec@TIS.COM, gnu@toad.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Idea: Prizes for protocol problems in key agreement
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 10:00 AM 8/22/96 -0700, Alan Monday-Internet Commerce Group wrote:
>I like this idea. I would add to the "problems" list:
>
> * Designs that can't be used for secure multicast applications
> * Designs that support Key Escrow
> * Designs that have only partial implementation
Designs that invalidate Key Escrow (in otherwords, escrow me all you want,
it does no good)?
Is this possible? It seems that man in the middle attacks are all that is
left to Key Escrow for some of these?
Is that adequate? If the key escrowers see that they have to launch man in
the middle attacks to see anything is this raising the cost enough to vastly
limit its use?
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa00390;
23 Aug 96 15:29 EDT
Received: by relay.hq.tis.com; id PAA00466; Fri, 23 Aug 1996 15:32:38 -0400
Received: from sol.hq.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1.1)
id xma000440; Fri, 23 Aug 96 15:32:15 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA18018; Fri, 23 Aug 96 15:31:27 EDT
Received: by relay.hq.tis.com; id PAA00428; Fri, 23 Aug 1996 15:32:08 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1)
id xma000426; Fri, 23 Aug 96 15:31:55 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA099578841; Fri, 23 Aug 1996 12:34:02 -0700
Message-Id: <199608231934.AA099578841@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA209918840; Fri, 23 Aug 1996 15:34:01 -0400
To: rgm3@chrysler.com
Cc: Alan.Monday@corp.sun.com, ipsec@TIS.COM, gnu@toad.com
Subject: Re: Idea: Prizes for protocol problems in key agreement
In-Reply-To: rgm3's message of Fri, 23 Aug 1996 11:58:14 -0400.
<3.0b11.32.19960823114911.00a68238@pop3hub.is.chrysler.com>
Date: Fri, 23 Aug 1996 15:34:00 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Designs that invalidate Key Escrow (in otherwords, escrow me all you want,
> it does no good)?
I'm not sure what you mean by this.. (use of ephemeral unescrowed DH
keys and session keys along with escrowed long-term signature keys?)
> Is this possible? It seems that man in the middle attacks are all that is
> left to Key Escrow for some of these?
Either that, or individual transforms which escrow the session key
actually used..
> Is that adequate? If the key escrowers see that they have to launch man in
> the middle attacks to see anything is this raising the cost enough to vastly
> limit its use?
Well, the protocol had better be immune to MITM attacks, at least
assuming there's a trustable certification path between the parties..
I see that as being covered by several of the problems in John's
original list.
"Revealing session keys or parts thereof to observers or attackers"
"Designs that are trivial to circumvent or bypass"
"Enabling session keys to be forced to known or partly-known values"
I'll add one more of my own:
"Failure to provide perfect forward secrecy for user
identities (if user keying is involved)".
which is, of course, a slightly stronger form of the existing:
"Revealing user identities to observers (if user keying is involved)"
- Bill
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5476.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 7:16:18 EDT
Seems reasonable to me, too. I remember Phil Karn espousing this view
repeatedly over the past years, whenever user-oriented keying came
up.... I thought that we had general consensus on this (except for our
WG chairs). I wish that we could get "official" recognition of this
position, too.
For the great class of usage, firewall to firewall tunnels (where only
network origination is authenticated), or laptop to firewall, IP
"network-layer" security easily handles those needs. The "user" or
"principle" or "party" maps nicely to the IP address.
For single-user laptop to multi-user host, the host software can avoid
application and API changes if the admittance can be managed by the host
kernel. The "user" maps nicely to the IP address plus SPI combination.
For multi-user host to multi-user host, with mutually suspicious users,
and/or multi-level security handled in a single session, and/or firewalls
attempting to authenticate user origination, major changes are needed to
the applications, APIs and to the internal segregation and management of
system security. But then, that's the domain of the "transport-layer"
security WG....
> From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
> > From dpkemp@missi.ncsc.mil Wed Aug 21 07:37:18 1996
> > The other viewpoint is top-down: there is a huge universe of applications
> > running on real customer networks that need to be "secured". We could do
> > it by modifying every single application and every application protocol to
> > provide security services at the highest layer, or we could recognize that
> > application protocols fall into classes, and that for some classes (those
> > that don't multiplex services for multiple "users" through a single
> > connection or process), a common IP-layer mechanism can be used without
> > modifying the higher layer protocols. Therefore it is reasonable to
> > provide the mechanism (an SPI field in the IP packet) that can in some
> > cases be used to achieve separation between "users" at the network layer.
>
> Seems reasonable to me.
>
> For those of us who are "securing" application protocols that aren't
> members of the class that can use IP-layer user-oriented security, it
> would be most helpful to have IPSEC "officially" recognize the position
> that David succinctly stated above.
>
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
From: William Allen Simpson <wsimpson@greendragon.com>
Message-Id: <5475.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: Idea: Prizes for protocol problems in key agreement
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 7:17:18 EDT
> From: John Gilmore <gnu@toad.com>
> I have a serious concern that we'll end up standardizing on a protocol
> that has not had the scrutiny required to validate its security. For
> this audience I need not point out that if the key agreement protocol
> is insecure or subvertible, it doesn't matter how strong our packet
> encryption is, nor how solid our public-key infrastructure is.
>
> I hope that we can do something similar for some of the reference
> implementations, once the protocols are nailed down.
>
I like both ideas very much!
> There might be big money for the protocol authors here -- they can
> define buggy protocols and then collect by pointing out the problems!
> But I think the increased general scrutiny is worth that risk.
>
Phooey, too late for Phil and I. :-( Do we get prizes for finding and
fixing past holes in the _original_ specifications? We already had some
help from reviewers, of course....
And what about holes that the WG review process forced us to add into
the protocol? Such as:
> * Revealing user identities to observers (if user keying is involved)
(As folks may remember, the change of Photuris privacy protection from
mandatory to optional, which was the only recent change to Photuris, was
the result of a nearly unanamiously straw poll instigated by Hugo at LA.
Negative prizes -- perhaps future prize disqualification -- for entire
groups of people?)
> Please give me your reactions and suggestions about this idea.
> Suggestions for a set of standards to judge the protocols against would
> be particularly useful. Also suggestions on the appropriate sizes,
> numbers, and categories of prizes, and potential judges.
>
The categories you listed seem to cover most of my concerns, as
specifics such as anti-clogging and key escrow fit under the more general:
> * Inability to scale to daily use on the entire Internet
> * Failure to provide perfect forward secrecy for packet traffic
I suggest that, as in the Nobel prizes, the prize funders be the sole
determiner of categories, sizes, and judges. You might want to find
protocol "customers" like Moskowitz to be on the panel of judges, rather
than potential contributor/recipients like cryptographers or IETF'ers.
And worldwide geographic coverage, rather than US centric.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Date: Mon, 26 Aug 1996 02:09:58 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608260609.CAA00246@mcn.netsec.com>
To: ipsec@TIS.COM
Subject: "user" and "network layer" security. reply to respondents.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The term "user" is undefined in the network layer of IP. It has no
sensible context in a discussion of *network layer* security
mechanisms. Moreover, introducing a parameter to the network layer
that corresponds to "user", breaks the network architecture. These
are basic facts of IP architecture. The basic facts of IP
architecture are established by agreed upon definition.
Important issues are raised by these basic facts. Arguments such
as those based on suggested hacks of network codes and operating
systems, are all specious with respect to the real issues.
Issue #1:
Is it appropriate for IPSEC to break network architecture, given
the absence of experience implementing security on the proposed
scale?
Issue #2:
Where is it established that network layer mechanisms should be
used to implement application layer security?
Regards,
Mitch Nelson
netsec@panix
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: netsec@panix.com
Cc: ipsec@TIS.COM
Reply-To: karn@qualcomm.com
In-Reply-To: <Pine.SUN.3.91.960816155715.811B-100000@panix.com>
(netsec@panix.com)
Subject: Re: "user" and "network layer" security.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 7:15:18 EDT
Message-ID: <9608260715.aa04497@neptune.TIS.COM>
>"User" based security and "network layer" security can each be designed
>and implemented in ways that are consistent with the established network
>architecture. With some pro-forma cross consultation, one should expect
>to arrive at reasonable results that provide good security without
>conflict and without unduly compromising present network functionality.
>The alternative does not offer as much grounds for optimism. Therefore it
>seems that all lanquage related to "user" should be expunged from IPSEC
>and instead treated in a seperate discussion group.
I couldn't agree more. As one of the originators of the IPSEC group, I
have watched with increasing resignation for the last four years as my
original idea has grown completely out of control, with very little to
show for it.
My original desire for security just above IP was to solve an
immediate and well-defined problem: when I use the network at an IETF
meeting or a USENIX, how can my laptop get back through my company's
firewall in a safe and secure fashion?
A closely related problem is the use of the Internet as a low-cost
alternative to leased lines between geographically separate subnets of
a corporate network. Leased lines are easily encrypted at the link
layer, but you have to move up to at least the IP layer to build a
"virtual leased line" over the net.
A security layer immediately above IP is a simple, straightforward and
highly effective solution to both problems.
I was so taken by IPSEC's seeming elegance that I started saying it
could displace security at the application layer. I now realize this
was a serious mistake. The interminable philosphical discussions here
about "user-oriented keying" and the geometrically increasing
complexity of the proposed key management protocols (including
Photuris) are clear proof of that.
Furthermore, there has been considerable progress in public-key-based
application-layer security in the past several years. We now have PGP
for email and files, SHTTP for the web, and SSH for remote login,
command execution and file transfer. Unlike IPSEC, I use all three
every day, and they work. SSH seems likely to develop into a general
purpose transport layer security mechanism that satisfies much (though
not all) of the need for end-to-end Internet security. So our
idealistic idea of avoiding all that application layer work has been
almost completely overtaken by events.
If the IPSEC group's work is to ever have any relevance, it must
return to the original, bare-bones goal of building protected
"tunnels" at the host-to-host or subnet-to-subnet level of
granularity. There's still plenty of need for this function, but
trying to do more than this is likely to continue to get us nowhere.
In this light, SKIP keeps looking better to me all the time. Its claim
to the "simple" label certainly keeps getting stronger. The only real
problem I've ever had with it was the lack of perfect forward secrecy
(PFS) in the original design. But that's in there too. So other than
the lack of support for a facility (user-oriented keying) that we
can't really do properly anyway, what's wrong with it?
Phil
Received: from relay.hq.tis.com by neptune.TIS.COM id aa07262;
26 Aug 96 10:23 EDT
Received: by relay.hq.tis.com; id KAA17555; Mon, 26 Aug 1996 10:26:23 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma017552; Mon, 26 Aug 96 10:25:56 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19207; Mon, 26 Aug 96 10:25:15 EDT
Received: by relay.hq.tis.com; id KAA17549; Mon, 26 Aug 1996 10:25:53 -0400
Received: from ns.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma017547; Mon, 26 Aug 96 10:25:31 -0400
Received: by janus.border.com id <18439-1>; Mon, 26 Aug 1996 10:28:05 -0400
Message-Id: <96Aug26.102805edt.18439-1@janus.border.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
From: "C. Harald Koch" <chk@border.com>
Date: Mon, 26 Aug 1996 10:27:32 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
One observation:
The people working on other protocols requiring security (TLS, L2TP, LDAP,
and probably others) have all been overheard saying the same thing:
Wouldn't it be nice to have a single key negotiation protocol for
IPsec *and* for our protocols?
So, Before we run around in a frenzy removing 'user oriented keying', we
should remember that AH/ESP are no longer the only customers of an IPSEC WG
key management protocol.
--
Harald Koch
chk@border.com
From: Hilarie Orman <ho@earth.hpc.org>
Message-Id: <199608261512.LAA23989@earth.hpc.org>
To: ipsec@TIS.COM
Subject: no SKIP/ISAKMP/OAKLEY resolution
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 26 Aug 96 11:09:36 EDT
The design group attempting to combine SKIP/OAKLEY/ISAKMP into one protocol
has been unable to resolve deeply held technical differences of opinion.
Some progress was made initially, but there has been no change in several
weeks now, so I must report failure, with great disappointment.
In my opinion, this was a group effort and a group failure --- I
exhort the greater working group to find quick agreement on goals
and an acceptable solution.
Hilarie Orman
Date: Mon, 26 Aug 1996 12:12:22 -0400
To: karn@qualcomm.com, netsec@panix.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "user" and "network layer" security.
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608261235.aa08927@neptune.TIS.COM>
At 07:15 AM 8/26/96 EDT, Phil Karn wrote:
>
>My original desire for security just above IP was to solve an
>immediate and well-defined problem: when I use the network at an IETF
>meeting or a USENIX, how can my laptop get back through my company's
>firewall in a safe and secure fashion?
Funny, that is what I define as 'user' the 'user' of the laptop. This
thingee ain't never going to work for the 'user' of a terminal attached to a
terminal server. At least the way terminal servers are working these days.
>
>Furthermore, there has been considerable progress in public-key-based
>application-layer security in the past several years. We now have PGP
>for email and files, SHTTP for the web, and SSH for remote login,
>command execution and file transfer. Unlike IPSEC, I use all three
>every day, and they work. SSH seems likely to develop into a general
>purpose transport layer security mechanism that satisfies much (though
>not all) of the need for end-to-end Internet security. So our
>idealistic idea of avoiding all that application layer work has been
>almost completely overtaken by events.
I still don't feel comfortable with transport layer security mechanisms like
SSL (that you did not list). I am going to need a good run-through by
someone that is not a proslytizer for it, but very well versed on the subject.
You see, I work with Venn diagrams in my head (sometimes I still draw them).
I have this one that has network layer security and data layer security and
it leaves very little left for transport layer security. Most seem to have
data layer as a nitch player (securing mail), I have it as a major component
and with the cost of cpus and security engines better for many of the things
that SHTTP gets used for today. Being part of an industry with general
distrust but major partnering, I need for the policy to be bound to the object.
>In this light, SKIP keeps looking better to me all the time. Its claim
>to the "simple" label certainly keeps getting stronger. The only real
>problem I've ever had with it was the lack of perfect forward secrecy
>(PFS) in the original design. But that's in there too. So other than
>the lack of support for a facility (user-oriented keying) that we
>can't really do properly anyway, what's wrong with it?
I am working on my list of items that makes Oakley (and GKMP, did you see
the drafts just released?) on ISAKMP as the better mechanism for a
inter-business security. SKIP, it looks like can be made to work for the
intra-business model. After all it is simple and inter-business is not.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa10054;
26 Aug 96 14:10 EDT
Received: by relay.hq.tis.com; id OAA24895; Mon, 26 Aug 1996 14:13:17 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma024844; Mon, 26 Aug 96 14:12:57 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01755; Mon, 26 Aug 96 14:12:14 EDT
Received: by relay.hq.tis.com; id OAA24825; Mon, 26 Aug 1996 14:12:46 -0400
Received: from relay.hp.com(15.255.152.2) by relay.tis.com via smap (V3.1.1)
id xma024811; Mon, 26 Aug 96 14:12:32 -0400
Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP
(1.37.109.16/15.5+ECS 3.3) id AA245873282; Mon, 26 Aug 1996 11:14:44 -0700
Message-Id: <199608261814.AA245873282@relay.hp.com>
Received: from snarfblatt.ch.apollo.hp.com by it_750.ch.apollo.hp.com
id AA074423282; Mon, 26 Aug 1996 14:14:42 -0400
To: Bob Natale <natale@acec.com>
Cc: fred@cisco.com, ipsec@TIS.COM, karn@qualcomm.com
Subject: Re: IETF focus
In-Reply-To: natale's message of Mon, 26 Aug 1996 11:05:47 -0400.
<ECS9608261147A@acec.com>
Date: Mon, 26 Aug 1996 14:14:41 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
[please note the change in CC: line from ietf back to ipsec...]
Interesting that you should mention WG charters as an issue.
IPSEC's charter includes..
The preliminary goals will specifically pursue host-to-host
security followed by subnet-to-subnet and host-to-subnet
topologies.
It appears that the initial "early adopters" of IPSEC are the firewall
folks -- so host-to-subnet and subnet-to-subnet is being developed and
deployed before host-to-host.
The charter also says:
The Internet Key Management Protocol (IKMP) will be specified as an
application layer protocol that is independent of the lower layer
security protocol.
Hmm. That could be interpreted to rule out SKIP, but the WG has been
behaving as if it's a candidate on equal footing with ISAKMP (and
rightly so..).
Because of these inconsistancies between the charter and the current
drafts up for discussion, and the failure of the "smoke filled key
management room" to produce anything, I think we need to seriously
consider revising the charter to reflect reality.
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12296;
26 Aug 96 17:12 EDT
Received: by relay.hq.tis.com; id RAA02537; Mon, 26 Aug 1996 17:15:20 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma002511; Mon, 26 Aug 96 17:14:51 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA12246; Mon, 26 Aug 96 17:14:12 EDT
Received: by relay.hq.tis.com; id RAA02506; Mon, 26 Aug 1996 17:14:50 -0400
Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1)
id xma002492; Mon, 26 Aug 96 17:14:32 -0400
Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id RAA23193; Mon, 26 Aug 1996 17:16:49 -0400 (EDT)
Date: Mon, 26 Aug 1996 17:16:48 -0400 (EDT)
From: "M.C.Nelson" <netsec@panix.com>
To: ipsec@TIS.COM
Cc: karn@qualcomm.com
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Subject: "user" and "network layer" security, a renewed IPSEC.
Message-Id: <Pine.SUN.3.91.960826171444.22574A-100000@panix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I am sorry that I did not read Phil's note of Aug 25 before sending my
note on Aug 26. I agree with Phil's suggestion regarding SKIP, and I
suggest that we proceed along those lines. Also, I think that the
IPSEC charter should be revised to focus more explicitly on network
layer security. The task should be well defined, as a first step
towards producing the best possible result. (Application layer
security can be the well defined task of an APPSEC working group.)
SKIP seems to reflect reasonable objectives of network layer security.
Still it would probably be a useful exercise to try and summarize what
those objectives are. Meanwhile I suggest that we set a reasonable
minimum period of time for renewed discussion of the SKIP proposal in
its details.
Mitch Nelson
netsec@panix.com
>From Phil Karn:
>>"User" based security and "network layer" security can each be designed
>>and implemented in ways that are consistent with the established network
>>architecture. With some pro-forma cross consultation, one should expect
>>to arrive at reasonable results that provide good security without
>>conflict and without unduly compromising present network functionality.
>>The alternative does not offer as much grounds for optimism. Therefore
>>it seems that all lanquage related to "user" should be expunged from
>>IPSEC and instead treated in a seperate discussion group.
(quoted by from M.C.Nelson of 8/16)
>I couldn't agree more. As one of the originators of the IPSEC group, I
>have watched with increasing resignation for the last four years as my
>original idea has grown completely out of control, with very little to
>show for it.
.....
>If the IPSEC group's work is to ever have any relevance, it must
>return to the original, bare-bones goal of building protected
>"tunnels" at the host-to-host or subnet-to-subnet level of
>granularity. There's still plenty of need for this function, but
>trying to do more than this is likely to continue to get us nowhere.
>
>In this light, SKIP keeps looking better to me all the time. Its claim
>to the "simple" label certainly keeps getting stronger. The only real
>problem I've ever had with it was the lack of perfect forward secrecy
>(PFS) in the original design. But that's in there too. So other than
>the lack of support for a facility (user-oriented keying) that we
>can't really do properly anyway, what's wrong with it?
Received: from relay.hq.tis.com by neptune.TIS.COM id aa19675;
27 Aug 96 4:45 EDT
Received: by relay.hq.tis.com; id EAA10115; Tue, 27 Aug 1996 04:49:07 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma010110; Tue, 27 Aug 96 04:48:38 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA27741; Tue, 27 Aug 96 04:47:59 EDT
Received: by relay.hq.tis.com; id EAA10107; Tue, 27 Aug 1996 04:48:37 -0400
Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1)
id xma010105; Tue, 27 Aug 96 04:48:17 -0400
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id BAA18913; Tue, 27 Aug 1996 01:50:37 -0700 (PDT)
Date: Tue, 27 Aug 1996 01:50:37 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199608270850.BAA18913@servo.qualcomm.com>
To: rgm3@chrysler.com
Cc: netsec@panix.com, ipsec@TIS.COM
In-Reply-To: <3.0b11.32.19960826120815.00b16eb0@pop3hub.is.chrysler.com> (message from Robert Moskowitz on Mon, 26 Aug 1996 12:12:22 -0400)
Subject: Re: "user" and "network layer" security.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>I am working on my list of items that makes Oakley (and GKMP, did you see
>the drafts just released?) on ISAKMP as the better mechanism for a
>inter-business security. SKIP, it looks like can be made to work for the
>intra-business model. After all it is simple and inter-business is not.
Hmm, your "inter-business" and "intra-business" distinction is a very
insightful one. My original goal for IPSEC was clearly to solve what
you are calling the "intra-business" security problem, at least for
the kind of business that doesn't have so many internal compartments
that it is really a bunch of completely separate businesses under one
roof. As you say, the other model is a LOT more complicated.
I think the intER-business problem is better left to the application
layer security guys. There certainly are many more of them on the job
now than a few years ago, and some knowledgeable customers do seem to
like what they're doing.
For example, Bank of America and Wells Fargo both support home banking
via secure Netscape. I can't think of any non-governmental entity more
conservative on security than a bank, so it seems they must have
conducted at least *some* level of in-house security
review. Especially since under the current banking laws, the banks
assume most of the risk of a security breach just as they do with
credit cards.
Phil
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21623;
27 Aug 96 7:37 EDT
Received: by relay.hq.tis.com; id OAA24938; Mon, 26 Aug 1996 14:13:46 -0400
From: wobber@pa.dec.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma024920; Mon, 26 Aug 96 14:13:36 -0400
Received: from london.eu.tis.com by tis.com (4.1/SUN-5.64)
id AA01797; Mon, 26 Aug 96 14:12:47 EDT
Received: from relay.eu.tis.com (firewall-user@relay.eu.tis.com [10.217.55.100]) by london.eu.tis.com (8.7.3/8.7.3) with ESMTP id TAA03721 for <ipsec@tis.com>; Mon, 26 Aug 1996 19:11:18 +0100 (BST)
Received: by relay.eu.tis.com; id PAA06248; Mon, 26 Aug 1996 15:07:18 +0100 (BST)
Received: from mail1.digital.com(204.123.2.50) by relay.eu.tis.com via smap (V3.1.1)
id xma006246; Mon, 26 Aug 96 15:06:57 +0100
Received: from hickory.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA12758; Mon, 26 Aug 1996 11:02:36 -0700
Received: by hickory.pa.dec.com; id AA02275; Mon, 26 Aug 1996 11:01:36 -0700
Message-Id: <9608261801.AA02275@hickory.pa.dec.com>
To: William Allen Simpson <wsimpson@greendragon.com>
Cc: ipsec@TIS.COM, wobber@pa.dec.com
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Message of Mon, 26 Aug 96 7:16:18 EDT
from William Allen Simpson <wsimpson@greendragon.com>
<5476.wsimpson@greendragon.com>
Date: Mon, 26 Aug 96 11:01:36 -0700
X-Mts: smtp
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>> For the great class of usage, firewall to firewall tunnels (where only
>> network origination is authenticated), or laptop to firewall, IP
>> "network-layer" security easily handles those needs. The "user" or
>> "principle" or "party" maps nicely to the IP address.
This works fine for folks whose laptop or PC is equipped with a static
IP address. What about everyone else?
For a majority of computers, IP addresses aren't meaningful for security.
When a user has complete physical control over a computer (such as
a laptop) there can be no realistic node-level security without special
hardware. In this environment, IP addresses serve as a convenient
indirection for operating systems and communication protocols that
can't easily deal with user names. Although we could build a security
infrastructure that institutionalizes IP addresses as shorthand for
user identities, is this really a good idea for the long term?
Ted Wobber
DEC Systems Research Center
Date: Mon, 26 Aug 1996 17:56:28 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608262156.RAA00328@mcn.netsec.com>
To: ipsec@TIS.COM, karn@qualcomm.com
Subject: A renewed IPSEC ("user" and "network layer" security).
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I am sorry that I did not read Phil's note of Aug 25 before sending my
note on Aug 26. I agree with Phil's suggestion regarding SKIP, and I
suggest that we proceed along those lines. Also, I think that the
IPSEC charter should be revised to focus more explicitly on network
layer security. The task should be well defined, as a first step
towards producing the best possible result. (Application layer
security can be the well defined task of an APPSEC working group.)
SKIP seems to reflect reasonable objectives of network layer security.
Still it would probably be a useful exercise to try and summarize what
those objectives are. Meanwhile I suggest that we set a reasonable
minimum period of time for renewed discussion of the SKIP proposal in
its details.
Mitch Nelson
netsec@panix.com
>From Phil Karn:
>>"User" based security and "network layer" security can each be designed
>>and implemented in ways that are consistent with the established network
>>architecture. With some pro-forma cross consultation, one should expect
>>to arrive at reasonable results that provide good security without
>>conflict and without unduly compromising present network functionality.
>>The alternative does not offer as much grounds for optimism. Therefore
>>it seems that all lanquage related to "user" should be expunged from
>>IPSEC and instead treated in a seperate discussion group.
(quoted by from M.C.Nelson of 8/16)
>I couldn't agree more. As one of the originators of the IPSEC group, I
>have watched with increasing resignation for the last four years as my
>original idea has grown completely out of control, with very little to
>show for it.
.....
>If the IPSEC group's work is to ever have any relevance, it must
>return to the original, bare-bones goal of building protected
>"tunnels" at the host-to-host or subnet-to-subnet level of
>granularity. There's still plenty of need for this function, but
>trying to do more than this is likely to continue to get us nowhere.
>
>In this light, SKIP keeps looking better to me all the time. Its claim
>to the "simple" label certainly keeps getting stronger. The only real
>problem I've ever had with it was the lack of perfect forward secrecy
>(PFS) in the original design. But that's in there too. So other than
>the lack of support for a facility (user-oriented keying) that we
>can't really do properly anyway, what's wrong with it?
Date: Tue, 27 Aug 96 15:10:42 GMT
From: William Allen Simpson <wsimpson@greendragon.com>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Message-Id: <5478.wsimpson@greendragon.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I'm sorry, I was insufficiently clear. The IP address (in my list of
scenarios) is part of the IP address plus SPI -- a temporary shorthand
for party/principle/user identities. There is no need for the IP
address to remain static. You still need some key management exchange
to bind an "identity" with the IP address plus SPI combination.
> From: wobber@pa.dec.com
> This works fine for folks whose laptop or PC is equipped with a static
> IP address. What about everyone else?
>
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25794;
27 Aug 96 12:32 EDT
Received: by relay.hq.tis.com; id MAA20145; Tue, 27 Aug 1996 12:35:27 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma020135; Tue, 27 Aug 96 12:35:05 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA16143; Tue, 27 Aug 96 12:34:22 EDT
Received: by relay.hq.tis.com; id MAA20130; Tue, 27 Aug 1996 12:34:57 -0400
Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1)
id xma020127; Tue, 27 Aug 96 12:34:53 -0400
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA078113831@capone.ch.apollo.hp.com>; Tue, 27 Aug 1996 12:37:11 -0400
Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id MAA01312; Tue, 27 Aug 1996 12:37:06 -0400
Message-Id: <199608271637.MAA01312@thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: Phil Karn <karn@qualcomm.com>
Cc: rgm3@chrysler.com, netsec@panix.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security.
In-Reply-To: karn's message of Tue, 27 Aug 1996 01:50:37 -0700.
<199608270850.BAA18913@servo.qualcomm.com>
Date: Tue, 27 Aug 1996 12:36:07 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
i'd actually argue that there are a bunch of different niches..
Inter-business vs intra-business oversimplifies the situation.
The "intrabusiness" niche covers a quite broad spectrum, from small
workgroups to large enterprises.
The "interbusiness" niche also covers a broad spectrum, depending on
the nature of the business relationship -- is it a casual one-shot
deal (a quantity-one catalog order of a commodity from the low bidder
of the day), or a committed multi-year multi-megabuck relationship?
In the latter case, you organization may well have a closer working
relationship with its opposite number in the other company than with
other organizations from your same company... so your computers may
well need to have a similarly "close" relationship...
- Bill
To: Phil Karn <karn@qualcomm.com>
Cc: rgm3@chrysler.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security.
In-Reply-To: Your message of "Tue, 27 Aug 1996 01:50:37 PDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 27 Aug 1996 11:05:06 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608271235.aa25853@neptune.TIS.COM>
Phil Karn writes:
> For example, Bank of America and Wells Fargo both support home banking
> via secure Netscape.
40 bit RC4 based SSL...
> I can't think of any non-governmental entity more conservative on
> security than a bank, so it seems they must have conducted at least
> *some* level of in-house security review. Especially since under the
> current banking laws, the banks assume most of the risk of a
> security breach just as they do with credit cards.
I hate to slander clients, but...
I make a considerable fraction of my money telling banks how to keep
themselves secure. You would be surprised at how bad some of what they
do is. They mean much better, of course, and they are willing to spend
the money when they know what they want, but they often don't know
good security from bad security -- they are still in many cases
building up the expertise, and its hard to get with things moving as
fast as they do now. The world of networks is as new to them as it is
to most businesses. Some banks are much better than others, of course.
IPSec has several advantages over application layer protocols, by the
way, not the least of which is that the signaling can be
protected. Try defending your BGP-4 TCP connections from spurious RSTs
with application layer defenses, for example...
Its also nice to build the security system once and have it there
always when you want it.
I know all this goes beyond what you and others originally envisioned
for swIPe and such, but it isn't an unreasonable use of the technology.
Perry
Date: Tue, 27 Aug 1996 14:56:25 -0400
To: Phil Karn <karn@qualcomm.com>, rgm3@chrysler.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "user" and "network layer" security.
Cc: netsec@panix.com, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608271457.aa28918@neptune.TIS.COM>
At 01:50 AM 8/27/96 -0700, Phil Karn wrote:
>
>I think the intER-business problem is better left to the application
>layer security guys. There certainly are many more of them on the job
>now than a few years ago, and some knowledgeable customers do seem to
>like what they're doing.
Won't ever happen too many of them and not enough security smarts. Other
complexities too. I've been studing this area for a few years now and
dealing with vendors. I can no longer wait for them to move security from
page 8 of enhancements to the top. Where you have seen security added is
the easy stuff, the top of the iceburg.
>For example, Bank of America and Wells Fargo both support home banking
>via secure Netscape.
No comparison to business to business issues. The trust model is much more
complex.
>I can't think of any non-governmental entity more
>conservative on security than a bank, so it seems they must have
>conducted at least *some* level of in-house security
>review. Especially since under the current banking laws, the banks
>assume most of the risk of a security breach just as they do with
>credit cards.
Simple, the banks extend their security model to their clientel. Can't do
than in a business to business anymore. I am deploying 3 applications like
that right now for up to 4,000 separate business and there are major
concerns if we will ever get it past a few hundred.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Date: Tue, 27 Aug 1996 14:56:29 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>,
Phil Karn <karn@qualcomm.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "user" and "network layer" security.
Cc: rgm3@chrysler.com, netsec@panix.com, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608271459.aa28948@neptune.TIS.COM>
At 12:36 PM 8/27/96 -0400, Bill Sommerfeld wrote:
>
>Inter-business vs intra-business oversimplifies the situation.
Oh course, any handle oversimplifies.
>The "intrabusiness" niche covers a quite broad spectrum, from small
>workgroups to large enterprises.
The major difference is one of trust. Even in Chrysler, there is an assumed
trust level (except between corporate and engineering ;).
>The "interbusiness" niche also covers a broad spectrum, depending on
>the nature of the business relationship -- is it a casual one-shot
>deal (a quantity-one catalog order of a commodity from the low bidder
>of the day), or a committed multi-year multi-megabuck relationship?
We have them both.
>In the latter case, you organization may well have a closer working
>relationship with its opposite number in the other company than with
>other organizations from your same company... so your computers may
>well need to have a similarly "close" relationship...
Ain't it the truth! But there is trust. We do not run/configure the
systems over at GE Plastics. Definitely not the networks. So what do we do
today? Put to systems on the poor guy's desk and two networks in GE
(actually more as there is a Ford and GM network presense too).
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Date: Tue, 27 Aug 1996 14:56:27 -0400
To: perry@piermont.com, Phil Karn <karn@qualcomm.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: "user" and "network layer" security.
Cc: rgm3@chrysler.com, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608271515.aa29325@neptune.TIS.COM>
At 11:05 AM 8/27/96 -0400, Perry E. Metzger wrote:
>
>I make a considerable fraction of my money telling banks how to keep
>themselves secure. You would be surprised at how bad some of what they
>do is. They mean much better, of course, and they are willing to spend
>the money when they know what they want, but they often don't know
>good security from bad security -- they are still in many cases
>building up the expertise, and its hard to get with things moving as
>fast as they do now. The world of networks is as new to them as it is
>to most businesses. Some banks are much better than others, of course.
Now take that to the CAD people, the MRP, the ERP, etc that have no
comprehension of this stuff. In San Jose, ask me about one experience with
an MRP company....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security.
In-Reply-To: Your message of "Tue, 27 Aug 1996 12:36:07 EDT."
<199608271637.MAA01312@thunk.orchard.medford.ma.us>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 27 Aug 1996 15:21:55 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608271525.aa29584@neptune.TIS.COM>
Bill Sommerfeld writes:
> i'd actually argue that there are a bunch of different niches..
>
> Inter-business vs intra-business oversimplifies the situation.
Strongly agreed.
BTW, IPSec is cool in many ways because it is flexible. It can be used
to build virtual private networks, or it can be used to secure an
individual TCP connection, or for other things. As such, I think its a
good mechanism in general...
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa02960;
27 Aug 96 18:21 EDT
Received: by relay.hq.tis.com; id SAA03456; Tue, 27 Aug 1996 18:24:50 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma003448; Tue, 27 Aug 96 18:24:28 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA07417; Tue, 27 Aug 96 18:23:47 EDT
Received: by relay.hq.tis.com; id SAA03438; Tue, 27 Aug 1996 18:24:21 -0400
Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1)
id xma003431; Tue, 27 Aug 96 18:24:16 -0400
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA28724; Tue, 27 Aug 1996 15:26:06 -0700 (PDT)
Date: Tue, 27 Aug 1996 15:26:06 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199608272226.PAA28724@servo.qualcomm.com>
To: perry@piermont.com
Cc: rgm3@chrysler.com, ipsec@TIS.COM
In-Reply-To: <199608271505.LAA29220@jekyll.piermont.com> (perry@piermont.com)
Subject: Re: "user" and "network layer" security.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>40 bit RC4 based SSL...
Excerpted from http://wellsfargo.com/nav/security2/:
You can use International grade security for most Internet Banking
functions EXCEPT the Internet Bill Payment Service. To access the
Internet Bill Payment service, you will need to use an Internet
browser that contains "U.S." or "Domestic" grade security encryption.
--Phil
Received: from relay.hq.tis.com by neptune.TIS.COM id aa04252;
27 Aug 96 19:43 EDT
Received: by relay.hq.tis.com; id QAA00754; Tue, 27 Aug 1996 16:41:53 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma000742; Tue, 27 Aug 96 16:41:23 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA01937; Tue, 27 Aug 96 16:40:42 EDT
Received: by relay.hq.tis.com; id QAA00733; Tue, 27 Aug 1996 16:41:20 -0400
Received: from dns1.noc.best.net(206.86.8.69) by relay.tis.com via smap (V3.1.1)
id xma000725; Tue, 27 Aug 96 16:41:08 -0400
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns1.noc.best.net (8.6.12/8.6.5) with ESMTP id NAA01360; Tue, 27 Aug 1996 13:40:52 -0700
Received: from [206.79.9.153] ([206.79.9.153]) by shellx.best.com (8.6.12/8.6.5) with SMTP id NAA10262; Tue, 27 Aug 1996 13:37:41 -0700
Date: Tue, 27 Aug 1996 13:37:41 -0700
Message-Id: <v02140b01ae4879d17e1f@[206.79.9.153]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ipsec@TIS.COM, nelson@mcn.netsec.com
From: John Lawler <jlawler@vpnet.com>
Subject: Re: A renewed IPSEC
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
As has been made clear at the last few IETF meetings, our company is
neutral about the "key management wars"--we will support whatever standard
is selected.
However, we feel very strongly that there is customer demand for network
security today, and we and other companies need to ship products to meet
those demands. Moreover, the Internet market which has sped up
*considerably* over the last year. WE CANNOT AFFORD TO FURTHER DELAY THE
DEVELOPMENT OF THIS INDUSTRY.
Our company has examined both specifications closely, and we will certainly
support whatever standard emerges. However, while we believe that both SKIP
and ISAKMP have significant benefits, it is our position that at this time,
SKIP is the more mature proposal. We concur with Phil Karn (one of the
originators of the IPSEC group) that SKIP is simple and effective. From our
independent vantage point, it appears that every "complaint" about SKIP has
been addressed: perfect forward secrecy has been added, multicast support
has been strengthened. That being the case, we believe it is in everyone's
best interests for SKIP to proceed to the next phase in the standards
process so that commercially shipping products can be developed in a timely
manner.
John Lawler | "Fifty-five crystal spheres geared
VPNet | to God's crankshaft is my idea of a
555 North Mathilda Ave, Suite. 110 | satisfying universe."
Sunnyvale, CA 94086 | -- "Arcadia", Tom Stoppard
(408) 720-7618 jlawler@vpnet.com |
To: Phil Karn <karn@qualcomm.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security.
In-Reply-To: Your message of "Tue, 27 Aug 1996 15:26:06 PDT."
<199608272226.PAA28724@servo.qualcomm.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 27 Aug 1996 18:33:19 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608280729.aa12048@neptune.TIS.COM>
Phil Karn writes:
> >40 bit RC4 based SSL...
>
> Excerpted from http://wellsfargo.com/nav/security2/:
>
> You can use International grade security for most Internet Banking
> functions EXCEPT the Internet Bill Payment Service. To access the
> Internet Bill Payment service, you will need to use an Internet
> browser that contains "U.S." or "Domestic" grade security encryption.
They've come a long way, then...
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa14831;
28 Aug 96 11:11 EDT
Received: by relay.hq.tis.com; id LAA16912; Wed, 28 Aug 1996 11:14:24 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma016905; Wed, 28 Aug 96 11:13:56 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA03925; Wed, 28 Aug 96 11:13:15 EDT
Received: by relay.hq.tis.com; id LAA16897; Wed, 28 Aug 1996 11:13:54 -0400
Received: from fnal.fnal.gov(131.225.110.17) by relay.tis.com via smap (V3.1.1)
id xma016891; Wed, 28 Aug 96 11:13:26 -0400
Received: from munin.fnal.gov ("port 4805"@munin.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I8T0KNC1YI0024II@FNAL.FNAL.GOV>;
Wed, 28 Aug 1996 10:15:40 -0600 (CST)
Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m)
id KAA02277; Wed, 28 Aug 1996 10:13:46 -0500 (CDT)
Date: Wed, 28 Aug 1996 10:13:39 -0500
From: Matt Crawford <crawdad@fnal.gov>
Subject: Re: "user" and "network layer" security.
In-Reply-To: "27 Aug 1996 18:33:19 EDT." <"9608280729.aa12048"@neptune.TIS.COM>
To: perry@piermont.com
Cc: Phil Karn <karn@qualcomm.com>, ipsec@TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Message-Id: <199608281513.KAA02277@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > Excerpted from http://wellsfargo.com/nav/security2/:
> > To access the Internet Bill Payment service, you will need to
> > use an Internet browser that contains "U.S." or "Domestic"
> > grade security encryption.
> They've come a long way, then...
> Perry
Maybe Wells Fargo has better consultants than the New York banks
you're familiar with. ;-)
Matt
Received: from relay.hq.tis.com by neptune.TIS.COM id aa18536;
28 Aug 96 15:32 EDT
Received: by relay.hq.tis.com; id PAA25872; Wed, 28 Aug 1996 15:35:58 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma025826; Wed, 28 Aug 96 15:35:35 -0400
Received: from sol.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA26652; Wed, 28 Aug 96 15:34:54 EDT
Message-Id: <9608281934.AA26652@tis.com>
To: ipsec@TIS.COM
Subject: Will the real PFS please stand up?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <26608.841260883.1@tis.com>
Date: Wed, 28 Aug 1996 15:34:51 -0400
From: "David M. Balenson" <balenson@TIS.COM>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I'd like to ask folks exactly what they mean by perfect forward secrecy?
The recent ID on SKIP extension for Perfect Forward Secrecy (PFS) uses
the term, but never actually defines it. (I think there should be a
definition, to ensure clarity and consistency.)
The latest ID draft-ietf-ipsec-isakmp-05.txt defines it (which is good),
but while the definition may be more intuitive, it is BACKWARDS from
what appeared in all the earlier drafts, as well as what I understand
to be the traditional meaning.
The best definition I know of is actually in the Diffie/Van Oorschot/
Wiener paper on Authentication and Authenticated Key Exchanges.
Regards,
-DB
---------------------------------------------------------------------------
David M. Balenson
Trusted Information Systems, 3060 Washington Rd., Glenwood, MD 21738 USA
balenson@tis.com; tel 301.854.5358; fax 301.854.5363
Received: from relay.hq.tis.com by neptune.TIS.COM id aa19157;
28 Aug 96 16:24 EDT
Received: by relay.hq.tis.com; id QAA27708; Wed, 28 Aug 1996 16:27:54 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma027696; Wed, 28 Aug 96 16:27:32 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA03806; Wed, 28 Aug 96 16:26:46 EDT
Received: by relay.hq.tis.com; id QAA27684; Wed, 28 Aug 1996 16:27:24 -0400
Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1)
id xma027654; Wed, 28 Aug 96 16:27:11 -0400
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA132594167@capone.ch.apollo.hp.com>; Wed, 28 Aug 1996 16:29:27 -0400
Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id QAA00220; Wed, 28 Aug 1996 16:29:26 -0400
Message-Id: <199608282029.QAA00220@thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: "David M. Balenson" <balenson@TIS.COM>
Cc: ipsec@TIS.COM
Subject: Re: Will the real PFS please stand up?
In-Reply-To: balenson's message of Wed, 28 Aug 1996 15:34:51 -0400.
<9608281934.AA26652@tis.com>
Date: Wed, 28 Aug 1996 16:29:23 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
On a related note, the skip-pfs draft does PFS in a different way from
how it's done in the other protocols.
Now, I don't consider myself a cryptographer, but something in
skip-pfs struck me as somewhat unconventional...
This is not the first time that I've raised this issue, but I don't
think it's been resolved..
As I read the draft, skip-pfs does not provide PFS protection of the
identity certificates of the communicating parties.
The exchange is:
I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij
(key: i,j: long term secrets of I and J
x,y: ephemeral secrets
[encryption]
{integrity protection})
The resulting traffic is protected using a key derived from g^xy,
which seems to be OK.
What concerns me is the use of g^xj to protect the ephemeral
certificates; it appears to me as if subsequent compromise of j will
allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
revealing the identities of everyone who has corresponded with j
during the period of interest.
Now, if I and J are just host identities, this isn't interesting
(because the same information is found in their IP addresses) but if
SKIP gets extended to do per-user keying I think we have a potential
problem.
It would be fairly simple to fix this by adding another round trip,
but the resulting protocol would would look a lot like OAKLEY or
Photuris.
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa20732;
28 Aug 96 18:42 EDT
Received: by relay.hq.tis.com; id SAA03606; Wed, 28 Aug 1996 18:45:38 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma003602; Wed, 28 Aug 96 18:45:09 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA13658; Wed, 28 Aug 96 18:44:28 EDT
Received: by relay.hq.tis.com; id SAA03599; Wed, 28 Aug 1996 18:45:08 -0400
Received: from servo.qualcomm.com(129.46.101.170) by relay.tis.com via smap (V3.1.1)
id xma003594; Wed, 28 Aug 96 18:44:50 -0400
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA09951; Wed, 28 Aug 1996 15:47:08 -0700 (PDT)
Date: Wed, 28 Aug 1996 15:47:08 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199608282247.PAA09951@servo.qualcomm.com>
To: balenson@TIS.COM
Cc: ipsec@TIS.COM
In-Reply-To: <9608281934.AA26652@tis.com> (balenson@TIS.COM)
Subject: Re: Will the real PFS please stand up?
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>I'd like to ask folks exactly what they mean by perfect forward secrecy?
Fair enough.
Perfect forward secrecy means a key management protocol and
implementation in which keys actually used to encrypt traffic (e.g.,
the keys in a ESP security association) are periodically changed such
that prior traffic keys cannot be recovered (and prior encrypted
traffic cannot be decrypted) even when the attacker has a complete
recording of all traffic and a complete readout of all *current*
machine state for both parties. "Current state" includes all
long-lived secret keys, but does *not* include any state that was
destroyed at the last traffic key change.
Phil
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21391;
28 Aug 96 19:48 EDT
Received: by relay.hq.tis.com; id TAA04467; Wed, 28 Aug 1996 19:51:36 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma004463; Wed, 28 Aug 96 19:51:12 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15243; Wed, 28 Aug 96 19:50:27 EDT
Received: by relay.hq.tis.com; id TAA04457; Wed, 28 Aug 1996 19:51:06 -0400
Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1)
id xma004454; Wed, 28 Aug 96 19:50:53 -0400
Received: from mailsun2.us.oracle.com by inet-user-gw-1.us.oracle.com with ESMTP (8.6.12/37.7)
id QAA23332; Wed, 28 Aug 1996 16:52:32 -0700
Received: by mailsun2.us.oracle.com (SMI-8.6/37.8)
id QAA28966; Wed, 28 Aug 1996 16:51:21 -0700
Message-Id: <199608282351.QAA28966@mailsun2.us.oracle.com>
Date: 28 Aug 96 16:46:18 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
Cc: nelson@mcn.netsec.com
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 25-Aug-96 23:09
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 4.0.2.1.40)
Content-Type: multipart/mixed; boundary="=_ORCL_6958916_0_11919608281752200"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
--=_ORCL_6958916_0_11919608281752200
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
>Issue #1:
>
> Is it appropriate for IPSEC to break network architecture, given
> the absence of experience implementing security on the proposed
> scale?
IPsec does not break the "Internet Architecture". The use of the term "user"
with IPsec security associations is confusing, but not inappropriate for some
scenarios. Key management is an application layer activity where the security
associations are created and provide authentication to peer application layer
entities. The security association is then available to be used by ESP, AH or
perhaps other security mechanisms. The authentication provided by
applicaitons can be at the granularity of a "user". The use of the resulting
authenticaiton process can be enforced at the network layer using ESP or AH.
There is significant experience fielding network layer security by various
governments and defense contractors. There is also significant experience by
many commercial vendors in the fielding of proprietary implementations of
network layer security technologies.
>
>Issue #2:
>
> Where is it established that network layer mechanisms should be
> used to implement application layer security?
Should? Secure systems can be built from many mechanisms. IPsec provides
application layer authentication (key management) that can be used by a
network layer security mechanism (ESP and/or AH).
I do agree that there are issues with "user-oriented" versus
"network-oriented" security. My issue is with the information bound to a
security association.
The definition of naming approaches (public key infrastructure etc.) has moved
even slower then IPsec :-) The real issue that needs to be addressed is the
naming framework that we are building into our security architecture. One
aspect of these names might be "what" they represent.
Paul
--------------------------------------------------------------
--=_ORCL_6958916_0_11919608281752200
Content-Type:message/rfc822
Date: 25 Aug 96 23:09:58
From:"Mitchell C. Nelson <nelson@mcn.netsec.com>" <ipsec-request@neptune.hq.tis.com>
To:ipsec@tis.com
Subject:"user" and "network layer" security. reply to respondents.
Sender:ipsec-approval@neptune.hq.tis.com
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"
The term "user" is undefined in the network layer of IP. It has no
sensible context in a discussion of *network layer* security
mechanisms. Moreover, introducing a parameter to the network layer
that corresponds to "user", breaks the network architecture. These
are basic facts of IP architecture. The basic facts of IP
architecture are established by agreed upon definition.
Important issues are raised by these basic facts. Arguments such
as those based on suggested hacks of network codes and operating
systems, are all specious with respect to the real issues.
Issue #1:
Is it appropriate for IPSEC to break network architecture, given
the absence of experience implementing security on the proposed
scale?
Issue #2:
Where is it established that network layer mechanisms should be
used to implement application layer security?
Regards,
Mitch Nelson
netsec@panix
--=_ORCL_6958916_0_11919608281752200--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25526;
29 Aug 96 2:41 EDT
Received: by relay.hq.tis.com; id CAA08451; Thu, 29 Aug 1996 02:44:34 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma008449; Thu, 29 Aug 96 02:44:09 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA22828; Thu, 29 Aug 96 02:43:24 EDT
Received: by relay.hq.tis.com; id CAA08446; Thu, 29 Aug 1996 02:44:04 -0400
Received: from vesuv.rz.tu-ilmenau.de(141.24.4.2) by relay.tis.com via smap (V3.1.1)
id xma008444; Thu, 29 Aug 96 02:43:37 -0400
Received: from PrakInf.TU-Ilmenau.DE (actually atlantis.PrakInf.TU-Ilmenau.DE)
by vesuv.rz.tu-ilmenau.de with SMTP (PP);
Thu, 29 Aug 1996 08:45:32 +0000
Received: from remus.prakinf by PrakInf.TU-Ilmenau.DE (4.1/SMI-4.1(mailhost))
id AA25469; Thu, 29 Aug 96 08:45:29 +0200
Date: Thu, 29 Aug 96 08:45:29 +0200
From: Holger Reif <Holger.Reif@prakinf.tu-ilmenau.de>
Message-Id: <9608290645.AA25469@PrakInf.TU-Ilmenau.DE>
To: perry@piermont.com
Subject: Re: "user" and "network layer" security.
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> > Excerpted from http://wellsfargo.com/nav/security2/:
> > To access the Internet Bill Payment service, you will need to
> > use an Internet browser that contains "U.S." or "Domestic"
> > grade security encryption.
> They've come a long way, then...
> Perry
They even closed their site when the PRNG bug of netscape navigator was
discovered last year. Obviously they understood the implications.
Or where at least told about them.
read you later - Holger Reif
---------------------------------------- Signaturprojekt Deutsche Einheit
TU Ilmenau - Informatik - Telematik (Verdamp lang her)
Holger.Reif@PrakInf.TU-Ilmenau.DE Alt wie ein Baum werden, um ueber
http://Remus.PrakInf.TU-Ilmenau.DE/Reif/ alle 7 Bruecken gehen zu koennen
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28249;
29 Aug 96 6:24 EDT
Received: by relay.hq.tis.com; id GAA10002; Thu, 29 Aug 1996 06:27:22 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma009994; Thu, 29 Aug 96 06:26:54 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA26393; Thu, 29 Aug 96 06:26:12 EDT
Received: by relay.hq.tis.com; id GAA09988; Thu, 29 Aug 1996 06:26:52 -0400
Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1)
id xma009983; Thu, 29 Aug 96 06:26:34 -0400
Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id MAA18289; Thu, 29 Aug 1996 12:28:24 +0200 (MET DST)
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id MAA03328; Thu, 29 Aug 1996 12:28:19 +0200 (MET DST)
Message-Id: <199608291028.MAA03328@kom30.ethz.ch>
Subject: Anonymity vs PFS (was: Will the real PFS please stand up?)
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Date: Thu, 29 Aug 1996 12:28:18 +0200 (MET DST)
Cc: ipsec@TIS.COM, Project SKIP <skip@tik.ee.ethz.ch>
In-Reply-To: <199608282029.QAA00220@thunk.orchard.medford.ma.us> from "Bill Sommerfeld" at Aug 28, 96 04:29:23 pm
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Bill Sommerfeld wrote:
> As I read the draft, skip-pfs does not provide PFS protection of the
> identity certificates of the communicating parties.
[...]
>
> The exchange is:
>
> I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
> J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij
[...]
> What concerns me is the use of g^xj to protect the ephemeral
> certificates; it appears to me as if subsequent compromise of j will
> allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
> revealing the identities of everyone who has corresponded with j
> during the period of interest.
[...]
Well, as I see it, SKIP PFS provides PFS (see the definiton of Phil Karn,
to which I fully agree) but it does not provide *perfect* anonymity.
Anonymity of participants and forward secrecy of communications really
are orthogonal properties.
If I remember correctly, we already had this discussion a few months ago?
One (rather old) answer was:
] One solution for anonymity for mobile users is to have anonymous
] principal ids (either per host or per user) (represented by private keys
] in smart cards or encrypted in some user password) that can be handed out
] to mobile users.
] These anonymous smart cards can be rotated among users, so that it isn't
] possible to know who is using a particular anonymous principal
] ID at any point in time.
] This can be implemented with SKIP, without requiring any change to the
] protocol.
This was an organisational solution to the whole issue even before PFS was
done. Unfortunatedly I have other relevant parts of my archives at the wrong
place, so I can not dig up 'conclusions', if there were any, which I doubt.
By the way, by using unsigned DH public values as defined in *-udh-* as
Cert_I and Cert_J, you get true anonymity, and perfect forward secrecy.
Actually, beacuse of the flexibility of SKIP and its namespace approach,
which I confess to like very much ;-), you can combine three types of
'certificates' and use one of them for each side of the message exchange.
The three types are 'unsigned ephemeral', 'signed ephemeral' and
'conventional' certificates. For each two of these combined you get some
nifty properties for the 'security association', and all of this can be
easily done using the certificate discovery protocol, independant of the
underlying key management proposal;-)
Germano
Date: Thu, 29 Aug 1996 07:02:25 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>,
"David M. Balenson" <balenson@TIS.COM>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Will the real PFS please stand up?
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608290746.aa29081@neptune.TIS.COM>
At 04:29 PM 8/28/96 -0400, Bill Sommerfeld wrote:
>
>The exchange is:
>
>I->J: { g^x, g, p, [Cert_I]g^xj, EMKID_J_I}Kij
>J->I: { g^y, g, p, [Cert_J]g^xj, EMKID_J_I, EMKID_I_J}Kij
>
> (key: i,j: long term secrets of I and J
> x,y: ephemeral secrets
> [encryption]
> {integrity protection})
>
>The resulting traffic is protected using a key derived from g^xy,
>which seems to be OK.
>
>What concerns me is the use of g^xj to protect the ephemeral
>certificates; it appears to me as if subsequent compromise of j will
>allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
>revealing the identities of everyone who has corresponded with j
>during the period of interest.
Does this mean that an escrowing of J can yield j? And thus escrowing is
effective against SKIP PFS? If so, this is unexceptable. PFS must be
immune to key escrowing.
For those that are looking for NSA boogiemen everywhere, look carefully at
this :)
>Now, if I and J are just host identities, this isn't interesting
>(because the same information is found in their IP addresses) but if
>SKIP gets extended to do per-user keying I think we have a potential
>problem.
Huh? Please enlighten me.
>It would be fairly simple to fix this by adding another round trip,
>but the resulting protocol would would look a lot like OAKLEY or
>Photuris.
Meaning that these are not open to recorded attacks in this manner. But
what about your comment: "if I and J are just host identities". How does
this relate in Oakley or Photuris?
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29960;
29 Aug 96 9:11 EDT
Received: by relay.hq.tis.com; id JAA12872; Thu, 29 Aug 1996 09:14:52 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma012866; Thu, 29 Aug 96 09:14:24 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA02291; Thu, 29 Aug 96 09:13:43 EDT
Received: by relay.hq.tis.com; id JAA12859; Thu, 29 Aug 1996 09:14:22 -0400
Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1)
id xma012841; Thu, 29 Aug 96 09:13:59 -0400
Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id PAA20044; Thu, 29 Aug 1996 15:15:46 +0200 (MET DST)
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id PAA03573; Thu, 29 Aug 1996 15:15:44 +0200 (MET DST)
Message-Id: <199608291315.PAA03573@kom30.ethz.ch>
Subject: OAKLEY/ISAKMP/SKIP design group
To: ipsec@TIS.COM
Date: Thu, 29 Aug 1996 15:15:43 +0200 (MET DST)
Cc: Project SKIP <skip@tik.ee.ethz.ch>
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hello everybody,
When looking back at the past 1 1/2 years, and how IPSEC evolved, I kind of
despair. Lots of progress were made all at the same time, and all in
different directions, with lots of people pulling at different strings. I
wonder how this will be going on. But, let me be a little more specific:
To my deep sorrow, Hilarie Orman has announced the failure of the design
group that was supposed to come up with a unified key management approach.
It might be very interesting for the group as a whole to understand why this
occurred. Could perhaps some of the group members elaborate on their
respective views to what technical differences were not acquiescable?
At the moment, I feel somewhat at a loss. Bot SKIP and OAKLEY/ISAKMP
respectively Photuris have important properties, Robert Moskowitz, Phil
Karn and others elaborated on the validity of the two approaches. Both
approaches have substantial backing by a broader community, at least
this is what I perceive. I personally prefer SKIP, because of its
inherent simplicity and because its easily done - and verified - but
after having invested substantial work in it, my not so humble opinion
might be tainted. Some more untainted voices arguing for the one or the
other approach would certainly be of interest to me...
Perhaps the working group should reconsider, and let both approaches go
forward on the standards track?
Friendly greetings,
Germano Caronni
Received: from relay.hq.tis.com by neptune.TIS.COM id aa01455;
29 Aug 96 10:50 EDT
Received: by relay.hq.tis.com; id KAA15453; Thu, 29 Aug 1996 10:58:23 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma015441; Thu, 29 Aug 96 10:57:56 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA15042; Thu, 29 Aug 96 10:57:14 EDT
Received: by relay.hq.tis.com; id KAA15437; Thu, 29 Aug 1996 10:57:53 -0400
Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1)
id xma015435; Thu, 29 Aug 96 10:57:46 -0400
Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA241100802@capone.ch.apollo.hp.com>; Thu, 29 Aug 1996 11:00:02 -0400
Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id LAA00829; Thu, 29 Aug 1996 11:00:00 -0400
Message-Id: <199608291500.LAA00829@thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: rgm3@chrysler.com
Cc: "David M. Balenson" <balenson@TIS.COM>, ipsec@TIS.COM
Subject: Re: Will the real PFS please stand up?
In-Reply-To: rgm3's message of Thu, 29 Aug 1996 07:02:25 -0400.
<3.0b11.32.19960829070029.00a20850@pop3hub.is.chrysler.com>
Date: Thu, 29 Aug 1996 10:59:54 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> >What concerns me is the use of g^xj to protect the ephemeral
> >certificates; it appears to me as if subsequent compromise of j will
> >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
> >revealing the identities of everyone who has corresponded with j
> >during the period of interest.
>
> Does this mean that an escrowing of J can yield j? And thus escrowing is
> effective against SKIP PFS? If so, this is unexceptable. PFS must be
> immune to key escrowing.
well, if we assume:
a) escrowing of the long-term secret j
b) no escrowing of the short-term secrets x and y
then release of `j' from escrow will reveal the identity of the
entities communicating with `J', but won't compromise their traffic.
I'm not sure these assumptions about key escrow policy are realistic;
in any situation where key escrow is mandated, skip-pfs, photuris, and
OAKLEY will all be illegal as specified.
> >Now, if I and J are just host identities, this isn't interesting
> >(because the same information is found in their IP addresses) but if
> >SKIP gets extended to do per-user keying I think we have a potential
> >problem.
>
> Huh? Please enlighten me.
Ok:
A certificate creates a binding between a principal's name and its
public key.
If the `name' in the certificate is just an IP address, then
compromise of the contents of Cert_I and Cert_J reveals no information
not already available to eavesdroppers, and skip-pfs's lack of PFS
protection on the exchanged certificates is moot.
If the `name' in the certificate contains something other than an IP
address, or something more than an IP address, then skip-pfs's lack of
PFS protection on the exchanged certificates becomes interesting.
> >It would be fairly simple to fix this by adding another round trip,
> >but the resulting protocol would would look a lot like OAKLEY or
> >Photuris.
>
> Meaning that these are not open to recorded attacks in this manner.
Right; photuris doesn't exchange certificates until after a purely
ephemeral DH exchange is completed.
I believe OAKLEY has at least one mode which behaves the same way.
> But what about your comment: "if I and J are just host identities".
> How does this relate in Oakley or Photuris?
As above.. if principal names are always IP addresses, there's no
benefit in keeping them secret in the key mgt protocol because they're
sent in the clear in every packet..
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa00673;
29 Aug 96 10:01 EDT
Received: by relay.hq.tis.com; id KAA14204; Thu, 29 Aug 1996 10:06:53 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma014200; Thu, 29 Aug 96 10:06:40 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA07775; Thu, 29 Aug 96 10:05:45 EDT
Received: by relay.hq.tis.com; id KAA14197; Thu, 29 Aug 1996 10:06:22 -0400
Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1)
id xma014195; Thu, 29 Aug 96 10:06:02 -0400
Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id QAA20645; Thu, 29 Aug 1996 16:08:17 +0200 (MET DST)
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id QAA03678; Thu, 29 Aug 1996 16:08:13 +0200 (MET DST)
Message-Id: <199608291408.QAA03678@kom30.ethz.ch>
Subject: Re: Will the real PFS please stand up?
To: Robert Moskowitz <rgm3@chrysler.com>
Date: Thu, 29 Aug 1996 16:08:12 +0200 (MET DST)
Cc: ipsec@TIS.COM
In-Reply-To: <9608290746.aa29081@neptune.TIS.COM> from "Robert Moskowitz" at Aug 29, 96 07:02:25 am
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Robert Moskowitz wrote:
> >What concerns me is the use of g^xj to protect the ephemeral
> >certificates; it appears to me as if subsequent compromise of j will
> >allow an eavesdropper to decrypt previously recorded [Cert_I]g^xj,
> >revealing the identities of everyone who has corresponded with j
> >during the period of interest.
>
> Does this mean that an escrowing of J can yield j? And thus escrowing is
> effective against SKIP PFS? If so, this is unexceptable. PFS must be
> immune to key escrowing.
Yes, by escrowing J, you can get j. But this is *not* effective against SKIP
PFS. The reason for this is that 'j' is used as an authentication key. If
the escrowing agent does not get x and/or y, which are ephemeral DH secret
values, the escrowing agent can only find out who communicated with J,
and can naturally impersonate J. This would work the same way with all other
schemes too, if authenticated exchanges are foreseen.
Friendly greetings,
Germano
by the way:
In my opinion escrowing communicated data is nuts anyway, you want key
escrow for long term archived data, where key owners (and their secrets)
may 'get lost'...
From: Rich Skrenta <skrenta@osmosys.incog.com>
Message-Id: <199608291706.KAA00973@miraj.incog.com>
Subject: Re: Will the real PFS please stand up?
To: Robert Moskowitz <rgm3@chrysler.com>
Date: Thu, 29 Aug 1996 10:06:57 -0700 (PDT)
Cc: sommerfeld@apollo.hp.com, balenson@TIS.COM, ipsec@TIS.COM
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> Does this mean that an escrowing of J can yield j? And thus escrowing is
> effective against SKIP PFS?
No, it means what Bill said -- that anonymity of the participants is not
covered by the PFS. `J' above is the identity of one of the communicating
parties; it doesn't make sense to talk about escrowing it.
If we're talking about host-host communication, the identities of the
two parties are known anyway. Hence this paragraph from the draft:
"The encryption of each principal's certificate using g^xj is
optional. It is used to provide anonymity of the parties
involved in the ephemeral exchange. In case anonymity is not
desired or necessary (e.g. node to node communications) the
encryption using g^xj may be omitted."
Date: Thu, 29 Aug 1996 13:03:36 -0500
From: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>
Message-Id: <MSMAIL PC */PRMD=MOT/ADMD=MOT/C=US/@MHS>
Subject: Everything degenerates to Key Management
To: ipsec@TIS.COM
X400-Mts-Identifier: [ /P=MOT/A=MOT/C=US/ ; m\gstmd\960829130336b ]
X-Mailer: Worldtalk (4.0.2-p15)/STREAM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I've been listening/reading the group's discussions for some time.It is
clear
that IPSEC, we, must produce and field a viable solution within the next
year
or be overcome by events. This truth, while brutal, I think can be
confirmed
independently by all of us.
Every discussion seems to degenerate into the fixed camps of key management
proponents, and it seems nearly impossible to unify until this issue is well
put to bed.
I agree heartily with Mr. Harald Koch:
>The people working on other protocols requiring security (TLS, L2TP, LDAP,
>and probably others) have all been overheard saying the same thing:
>
> Wouldn't it be nice to have a single key negotiation protocol for
> IPsec *and* for our protocols?
>
>So, Before we run around in a frenzy removing 'user oriented keying', we
>should remember that AH/ESP are no longer the only customers of an IPSEC WG
>key management protocol.
Though my preference would be an ISAKMP/OAKLEY key management solution for
IPSEC, I understand Phil's concern at how far we have gone from the original
goals.
>I couldn't agree more. As one of the originators of the IPSEC group, I
>have watched with increasing resignation for the last four years as my
>original idea has grown completely out of control, with very little to
>show for it.
>...
>how can my laptop get back through my company's
>firewall in a safe and secure fashion?
>...
>If the IPSEC group's work is to ever have any relevance, it must
>return to the original, bare-bones goal of building protected
>"tunnels" at the host-to-host or subnet-to-subnet level of
>granularity. There's still plenty of need for this function, but
>trying to do more than this is likely to continue to get us nowhere.
>
>In this light, SKIP keeps looking better to me all the time. Its claim
>to the "simple" label certainly keeps getting stronger.
I do however feel strongly that we have a responsibility to position the
Internet protocols for future capability. Ignoring the need that is well
voiced for a common, flexible, and extensible key managment protocol would
border on deliquency.
As Germano Caronni requested, I would like to reiterate, that it would be
helpful to review the TECHNICAL reasons for failure of unifying the key
management approaches.
>To my deep sorrow, Hilarie Orman has announced the failure of the design
>group that was supposed to come up with a unified key management approach.
>It might be very interesting for the group as a whole to understand why
this
>occurred. Could perhaps some of the group members elaborate on their
>respective views to what technical differences were not acquiescable?
It would be helpful if this exchange were HIGHLY moderated - much like a
debate. However, written form - through the mail list - would be a much
better forum than a meeting.
I propose that key designers/proponents of the key management protocols
collaberate and present a SHORT position paper on the primary aspects/
features of their respective protocols that cannot be unified with other
approaches; a single submittal for each protocol may be forwarded to Ran or
Paul who will then post to the group. A SINGLE, UNIFIED rebuttal from each
party be allowed to be posted following the first submittal, again through
one of the chairs.
This process will allow us the read a clearly presented position from the
major contributors WITHOUT a lot of bantering clogging up the exchange.
Folks, we need a unfied approach, or we will continue to bicker until
someone else produces a workable compromise and we will all end up looking
like fools -- many other groups/companies are doing this. If we can't get
there, and come to a professional concenus, then maybe Phil is right --
we'll
need to rope in our goals.
Dave Wheeler
Motorola, SSTG
Scottsdale, Az
"What's the difference between a wise man and a fool arguing in the street?
A stranger can't tell the difference between the wise man and the fool."
Received: from relay.hq.tis.com by neptune.TIS.COM id aa09482;
29 Aug 96 21:31 EDT
Received: by relay.hq.tis.com; id VAA02406; Thu, 29 Aug 1996 21:34:57 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma002404; Thu, 29 Aug 96 21:34:28 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA23335; Thu, 29 Aug 96 21:33:47 EDT
Received: by relay.hq.tis.com; id VAA02399; Thu, 29 Aug 1996 21:34:27 -0400
Received: from inet-user-gw-1.us.oracle.com(192.86.155.82) by relay.tis.com via smap (V3.1.1)
id xma002392; Thu, 29 Aug 96 21:34:00 -0400
Received: from maildig1.us.oracle.com by inet-user-gw-1.us.oracle.com with SMTP (8.6.12/37.7)
id SAA03125; Thu, 29 Aug 1996 18:33:03 -0700
Received: by maildig1.us.oracle.com (5.65v3.2/37.8)
id AA13364; Thu, 29 Aug 1996 17:59:09 -0700
Message-Id: <9608300059.AA13364@maildig1.us.oracle.com>
Date: 29 Aug 96 17:57:32 -0700
From: "PALAMBER.US.ORACLE.COM" <PALAMBER@us.oracle.com>
To: ipsec@TIS.COM
Subject: Re: Will the real PFS please stand up?
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:ipsec-request@neptune.hq.tis.com's message of 29-Aug-96 07:08
Mime-Version: 1.0
X-Mailer: Oracle InterOffice (version 2.1.16.0.0)
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hi Germano,
>Friendly greetings,
> Germano
>
>by the way:
>In my opinion escrowing communicated data is nuts anyway,
>you want key escrow for long term archived data, where
>key owners (and their secrets) may 'get lost'...
I agree, but would like to add that ...
"Key archiving" makes sense for long term archived data and sometimes for
private signature or encryption keys. This allows access to data when keys
are misplaced, or restoration of capabilities when a user forgets or losses
his key.
"Law enforcement escrow" makes sense to agencies that wish to covertly monitor
data being communicated in real time. Law enforcement access to stored data
may be provided by mechanisms that could be described as key archiving or law
enforcement escrow. The IPsec efforts are concerned primarily with the
"real-time" protection of IP datagrams so there should be no confusion within
this committee between the categories of key recovery.
To date, no requirements have been put forward within the IPsec working group
for support of key archiving or law enforcement key escrow.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 633-2963
Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
for a secure time -> send resumes to: palamber@us.oracle.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12711;
30 Aug 96 0:47 EDT
Received: by relay.hq.tis.com; id AAA04525; Fri, 30 Aug 1996 00:50:51 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma004523; Fri, 30 Aug 96 00:50:28 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA27162; Fri, 30 Aug 96 00:49:42 EDT
Received: by relay.hq.tis.com; id AAA04520; Fri, 30 Aug 1996 00:50:21 -0400
Received: from melcogw.melit.melco.co.jp(192.218.140.35) by relay.tis.com via smap (V3.1.1)
id xma004518; Fri, 30 Aug 96 00:50:14 -0400
Received: by melcogw.melit.melco.co.jp (5.65+1.6W/2.7W)
id AA25341; Fri, 30 Aug 96 13:52:31 JST
Received: from katase by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0)
id AA22759; Fri, 30 Aug 1996 13:55:39 +0900
Received: from kousoku.kousoku.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/)
id AA17208; Fri, 30 Aug 96 13:52:19 JST
Received: from l2seno by kousoku.kousoku.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/kousoku-master)
id AA17396; Fri, 30 Aug 1996 13:54:31 +0900
Message-Id: <9608300454.AA17396@kousoku.kousoku.isl.melco.co.jp>
Date: Fri, 30 Aug 1996 13:55:56 +0900
To: ipsec@TIS.COM
From: Shoichiro Seno <senos@kousoku.isl.melco.co.jp>
Subject: Any News on UUNET encryption patents?
Cc: watakira@kousoku.isl.melco.co.jp,
Shoichiro Seno <senos@kousoku.isl.melco.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Eudora-J(1.3.8.5-J13)
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hello,
A few months ago, the validity of the following patents by UUNET was
discussed on this mailing list. Would you let me know recent recent
news on these patents, e.g, if someone challenged the patents?
>5,442,708 - Computer Network Encryption/Decryption Device
>Inventors: Richard L. Adams, Jr., Fairfax, Va.;
> Peter D. Hallenbeck, Elfland, N.C.
>Assignee: UUNET Techologies, Inc., Falls Church, Va.
>Appl. No: 305,509
>Filed: Sep. 13, 1994
>Related U.S. Application Data:
> Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned.
>5,444,782 - Computer Network Encryption/Decryption Device
>Inventors: Richard L. Adams, Jr., Fairfax, Va.;
> Peter D. Hallenbeck, Elfland, N.C.
>Assignee: UUNET Techologies, Inc., Falls Church, Va.
>Appl. No: 184,631
>Filed: Jan. 19, 1994
>Related U.S. Application Data:
> Continuation of Ser. No. 28,437, Mar. 9, 1993, abandoned.
--
Shoichiro Seno, (E-mail) senos@kousoku.isl.melco.co.jp
High-Speed Network Department, Information Technology R&D Center
Mitsubishi Electric Corporation
(Tel) +81-467-41-2434, (Fax) +81-467-41-2419
Date: Thu, 29 Aug 1996 19:24:27 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608292324.TAA00290@mcn.netsec.com>
To: ipsec@TIS.COM, karn@qualcomm.netsec.com, rgm3@chrysler.com
Subject: "user" and "network layer" security.
Cc: nelson@mcn.netsec.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Re Robert Moskowitz's "inter" and "intra" business model, I think
that this is again a bit of a red-herring. At the network layer
there is not to much distinction. The entities that are sensitive
to this are very much at the application layer. Hence the *whole*
construct of distinquishing between inter and intra really belongs
in an application layer security model. The construct could perhaps
have some small consequence with respect to routing. But even so,
such a consequence would probably only come into a network layer
security model as a second order contribution. (Parenthetically
recall that some c.f. Tannenbaum, feel that IP routing already has
a somewhat confused architecture).
Re the suggestion to immediately adapt SKIP, I feel that it is
important to first clearly state the objectives of network layer
security, and then discuss proposals in those terms. If it is
agreed that SKIP is at least more or less in the right direction,
then very good. After that, I suspect there are some questions
of a mathematical-cryptographical nature that should be discussed.
I'm hesitant to bring out my own questions in this category at
this moment, because I feel that at this moment it would be a
digression. The first thing is to clearly state an appropriate
set of objectives.
Regards,
Mitch Nelson
netsec@panix.com
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Cc: ipsec@TIS.COM, gnu@toad.com
Subject: PFS, key escrow, and legality
In-Reply-To: <199608291500.LAA00829@thunk.orchard.medford.ma.us>
Date: Thu, 29 Aug 1996 17:08:10 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608300802.aa20484@neptune.TIS.COM>
> I'm not sure these assumptions about key escrow policy are realistic;
> in any situation where key escrow is mandated, skip-pfs, photuris, and
> OAKLEY will all be illegal as specified.
Bill, there are numerous situations in which key escrow of some sort
might occur, without making the development, deployment, or use of
secure protocols such as Photuris illegal. Kindly don't hand the
government what it wants (our capitulation) before we are forced at
gunpoint to surrender our privacy.
For example, see the Administration's Clipper-3 policy (announced only
in July; see http://www.crypto.com/#clipper3). It proposes that
users' long-term private keys must be generated by, or stored in, an
escrow agency, before a certification authority would publish the
corresponding public key. It would allow the use of any algorithm or
protocol, even in exportable products. It states "There are no
federal laws regulating the use of cryptographic products within the
United States.", and continues the Clinton Administration policy of
having no plans or proposals to control the domestic use of
encryption.
It will be a very hard job to ram legislation through Congress that
makes everything that you and I are working on illegal. Everyone who
owned a copy of PGP or Kerberos would be a felon, including numerous
government officials, agencies, and corporations at all levels.
Congressional interest in encryption issues is continuing to rise, and
it's clear to all interested parties (inside and outside Congress)
that nobody supports Government Access to Keys (GAK) except for
government officials, people they are paying, and a very small number
of public policy activists (Dorothy Denning is the only one I can
think of). Making domestic crypto illegal in Congress is a very long
shot -- and even if they succeed, EFF is building a legal team that
would fight it, the same way we are fighting and winning
Constitutional battles against the CDA legislation and the export
control legislation.
It is far more likely that we'll have to deal with non-legislative
programs, or legislation that does not outlaw the domestic use of
strong crypto. For example, the government could try to strong-arm or
purchase VeriSign, RSA, and other certification authorities to
"voluntarily" require GAK, the way they strong-armed AT&T to offer the
original Clipper phone. They are currently working to convince
governments of naive or unfree countries to mandate the use of GAK,
which would mean that vendors who wanted to sell products in those
countries would have to supply GAK even if it wasn't required for US
use. They could require government contractors to use GAK, etc.
Partial GAK, without making strong crypto illegal, doesn't accomplish
their aims, though. Using a properly designed protocol with PFS, even
escrowing all the long-term keys does not permit them to break the
traffic, because the long-term keys are only used for authentication,
never for encryption. Encryption is done with an ephemeral key
generated by Diffie-Hellman.
Even if the government has your long-term private key, has tapped your
phone line, and is doing an active attack on your Diffie-Hellman
protocol, you will detect the attack and avoid communication -- unless
they also have real-time access to the escrowed private keys of
EVERYONE YOU COMMUNICATE WITH.
Think about that. Giving the government real-time (30 seconds or
less) access to every single escrowed private key, without a warrant,
based on the flimsy assertion that "someone who we *do* have a warrant
for is currently trying to communicate with that person", is something
that the public is very unlikely to stand for. It would basically
mean that all administrative controls over the key-escrow database
would be thrown in the trash. Any law enforcement agency would be
able to get anyone's key at any time.
Even if machinery enforced the rules, and would only give them keys
for parties that a legally wiretapped suspect attempted communication
with, they could inject bogus-return-address packets that would cause
the wiretapped machine to attempt to communicate with any site whose
key they wanted to look up. For example, they could pretend to be
opening an SMTP connection, doing a DNS lookup, or starting an IPSEC
key exchange from that site. They or an accomplice could do that from
anywhere on the net, without even mounting an active attack.
So, let's not constrain the debate or our protocols by premature ideas
on "what would be legal or illegal". As requested by the IAB and the
IESG, let's design protocols that are as strong as we can make them,
against every kind of attack we can envision. Including attacks by
our own governments on our civil rights.
John Gilmore
PS: As you might guess, I strongly support keeping the identities of
the communicating parties private in the key negotiation protocol, as
well as continuing to require PFS for the end-user data. It should be
possible with firewall-to-firewall keying and encryption to never
reveal the end-system identities, which would be a big help in
defeating traffic analysis against large sites such as universities or
corporations.
Date: Thu, 29 Aug 1996 20:13:05 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608300013.UAA00353@mcn.netsec.com>
To: ipsec@TIS.COM, PALAMBER@us.oracle.com
Subject: "user" and "network layer" security. reply to respondents.
Cc: netsec@panix.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Paul, I think you need to think through your scenario a little
more carefully. You'll probably see that your argument doesn't fly.
The present IPSEC does in fact, break the network architecture.
(But, thank you for a challenging effort.)
Regads,
Mitch Nelson
netsec@panix.com
reference - palamber's comment:
> IPsec does not break the "Internet Architecture". The use of the term
> "user" with IPsec security associations is confusing, but not
> inappropriate for some scenarios. Key management is an application
> layer activity where the security associations are created and provide
> authentication to peer application layer entities. The security
> association is then available to be used by ESP, AH or perhaps other
> security mechanisms. The authentication provided by applicaitons can
> be at the granularity of a "user". The use of the resulting
> authenticaiton process can be enforced at the network layer using ESP
> or AH.
p.s.
The experience that you cited is not comparable to what is being
proposed here. We are dealing with a very different environment,
context, and scale.
reference - palamber's comment:
> There is significant experience fielding network layer security by
> various governments and defense contractors. There is also significant
> experience by many commercial vendors ...
To: ipsec@TIS.COM
Subject: Announcing DNS Security in production BIND code
Date: Thu, 29 Aug 1996 19:11:34 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608300806.aa20532@neptune.TIS.COM>
Paul Vixie has released a test version of BIND which contains some DNS
Security features. The release is available now at
ftp://ftp.vix.com/pub/bind/testing/bind-4.9.5-T3B.tar.gz.
Only the existence of KEY and SIG records is implemented in this BIND.
There is no cryptography implemented; the signatures are never
checked. This permits keys and signatures to be stored and retrieved
in a completely exportable version of BIND, which is part of the main
production BIND evolution.
The released code is partly based on IBM changes for Dynamic DNS, and
is partly original with me. It was not based on TIS's version because
of their export control concerns and restrictive copyrights (which
have since been almost resolved). The State Department has approved
TIS's request to export their cryptographic version of BIND. TIS is
now waiting for final Commerce Dept. approval. When they receive it,
I will work with them and Paul to merge their version into the
production BIND sources, and to add further cryptographic code to the
resolver, to provide production-quality, worldwide, end-to-end
cryptovalidation of DNS resource records.
In the meantime, TIS's release (ftp://ftp.tis.com/pub/DNSSEC/README)
is useful in the US for experimentation, and for generating offline
KEY and SIG records (which can then be published with the just-released
production BIND server).
I encourage all organizations who are interested in Secure DNS to
upgrade their organization's production copy of BIND to Paul's latest
release. This will facilitate Secure DNS testing and deployment.
I have started a mailing list <dnssec-interest@toad.com> for people
who are interested in deploying Secure DNS in production use. There
is also <dnssec-nics@toad.com> for top-level domain service providers
to work out their issues with Secure DNS. Send me email at
postmaster@toad.com if you'd like to join either list.
This is the first software release from my S/WAN (Secure Wide Area
Network) project, whose ultimate goal is to provide transparent
improvements to the privacy and security of all Internet
communications. See http://www.cygnus.com/~gnu/swan.html.
Thank you for supporting the ongoing securing of the Internet
infrastructure.
John Gilmore
To: ipsec@TIS.COM
Subject: Patents by Sun?
Date: Thu, 29 Aug 1996 17:32:20 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608300807.aa20583@neptune.TIS.COM>
Someone forwarded this to me. I don't know if its real.
I must admit I haven't yet tracked this down to confirm it (it might
be a hoax) but it appears by the looks of it that Ashar has patented
IPSEC. Again, I have to track down an independent copy to confirm
it. If the claims listed are genuine, they are all on their face
invalidated by prior art, but...
Perry
------- Forwarded Message
System for signatureless transmission and reception of
data packets between computer networks (Assignee -- Sun
Microsystems, Inc.)
Abstract: A system for automatically encrypting and
decrypting data packet sent from a source host to a
destination host across a public internetwork.
A tunnelling bridge is positioned at each network, and
intercepts all packets transmitted to or from its
associated network.
The tunnelling bridge includes tables indicated pairs of
hosts or pairs of networks between which packets should
be encrypted.
When a packet is transmitted from a first host, the
tunnelling bridge of that host's network intercepts the
packet, and determines from its header information
whether packets from that host that are directed to the
specified destination host should be encrypted; or,
alternatively, whether packets from the source host's
network that are directed to the destination host's
network should be encrypted.
If so, the packet is encrypted, and transmitted to the
destination network along with an encapsulation header
indicating source and destination information: either
source and destination host addresses, or the broadcast
addresses of the source and destination networks (in the
latter case, concealing by encryption the hosts'
respective addresses).
An identifier of the source network's tunnelling bridge
may also be included in the encapsulation header. At the
destination network, the associated tunnelling bridge
intercepts the packet, inspects the encapsulation header,
from an internal table determines whether the packet was
encrypted, and from either the source (host or network)
address or the tunnelling bridge identifier determines
whether and how the packet was encrypted.
If the packet was encrypted, it is now decrypted using a
key stored in the destination tunnelling bridge's memory,
and is sent on to the destination host.
The tunnelling bridge identifier is used particularly in
an embodiment where a given network has more than one
tunnelling bridge, and hence multiple possible
encryption/decryption schemes and keys.
In an alternative embodiment, the automatic encryption
and decryption may be carried out by the source and
destination hosts themselves, without the use of
additional tunnelling bridges, in which case the
encapsulation header includes the source and destination
host addresses.
Ex Claim Text: A method for transmitting and receiving
packets of data via an internetwork from a first host
computer on a first computer network to a second host
computer on a second computer network, the first and
second computer networks including, respectively, first
and second bridge computers, each of said first and
second host computers and first and second bridge
computers including a processor and a memory for storing
instructions for execution by the processor, each of said
first and second bridge computers further including
memory storing at least one predetermined encryption/
decryption mechanism and information identifying a
predetermined plurality of host computers as hosts
requiring security for packets transmitted between them,
the method being carded out by means of the instructions
stored in said respective memories and including the
steps of:
(1) generating, by the first host computer, a first data
packet for transmission to the second host computer, a
portion of the data packet including information
representing an internetwork address of the first host
computer and an internetwork address of the second host
computer;
(2) in the first bridge computer, intercepting the first
data packet and determining whether the first and second
host computers are among the predetermined plurality of
host computers for which security is required, and if
not, proceeding to step 5, and if so, proceeding to step
3;
(3) encrypting the first data packet in the first bridge
computer;
(4) in the first bridge computer, generating and
appending (4) in the first bridge computer, generating
and appending to the first data packet an enapsulation
header, including:
(a) key management information identifying the
predetermined encryption method, and
(b) a new address header representing the source and
destination for the data packet, thereby generating a
modified data packet;
(5) transmitting the data packet from the first bridge
computer via the internetwork to the second computer
network;
(6) intercepting the data packet at the second bridge
computer;
(7) in the second bridge computer, reading the
encapsulation header, and determining therefrom whether
the data packet was encrypted, and if not, proceeding to
step 10, and if so, proceeding to step 8;
(8) in the second bridge computer, determining which
encryption mechanism was used to encrypt the first data
packet;
(9) decrypting the first data packet by the second bridge
computer;
(10) transmitting the first data packet from the second
bridge computer to the second host computer; and
(11) receiving the unencrypted data packet at the second
host computer.
Assignee: Sun Microsystems, Inc.
Patent Number: 5548646
Issue Date: 1996 08 20
Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson,
Martin; Scott, Glenn. State/Country CA
------- End of Forwarded Message
Received: from relay.hq.tis.com by neptune.TIS.COM id aa21488;
30 Aug 96 8:45 EDT
Received: by relay.hq.tis.com; id IAA09556; Fri, 30 Aug 1996 08:48:35 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma009525; Fri, 30 Aug 96 08:48:07 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA07131; Fri, 30 Aug 96 08:47:24 EDT
Received: by relay.hq.tis.com; id IAA09519; Fri, 30 Aug 1996 08:48:04 -0400
Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1)
id xma009499; Fri, 30 Aug 96 08:47:51 -0400
Received: from thunk.orchard.medford.ma.us (orchard.ch.apollo.hp.com) by capone.ch.apollo.hp.com id <AA140069402@capone.ch.apollo.hp.com>; Fri, 30 Aug 1996 08:50:02 -0400
Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.6.12/8.6.12) with ESMTP id PAA00215; Thu, 29 Aug 1996 15:15:14 -0400
Message-Id: <199608291915.PAA00215@thunk.orchard.medford.ma.us>
X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs
To: nelson@mcn.netsec.com, PALAMBER@us.oracle.com
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
In-Reply-To: PALAMBER's message of 28 Aug 1996 16:46:18 -0700.
<199608282351.QAA28966@mailsun2.us.oracle.com>
Date: Thu, 29 Aug 1996 15:15:13 -0400
From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Another way of looking at ipsec is that the transforms are really a
layer *in between* network and transport.
You're not so much adding a "user" concept at the network layer as
adding a new layer next to the transport layer, which already has a
concept of "user".
- Bill
Received: from relay.hq.tis.com by neptune.TIS.COM id aa22783;
30 Aug 96 9:56 EDT
Received: by relay.hq.tis.com; id JAA11235; Fri, 30 Aug 1996 09:59:35 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma011228; Fri, 30 Aug 96 09:59:06 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA11044; Fri, 30 Aug 96 09:58:24 EDT
Received: by relay.hq.tis.com; id JAA11222; Fri, 30 Aug 1996 09:59:04 -0400
Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1)
id xma011218; Fri, 30 Aug 96 09:58:51 -0400
Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id JAA28291; Fri, 30 Aug 1996 09:59:50 -0400 (EDT)
Date: Fri, 30 Aug 1996 09:59:49 -0400 (EDT)
From: "M.C.Nelson" <netsec@panix.com>
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Cc: nelson@mcn.netsec.com, PALAMBER@us.oracle.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
In-Reply-To: <199608291915.PAA00215@thunk.orchard.medford.ma.us>
Message-Id: <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Bill,
The transport layer doesn't have "user" either. Adding a "user" concept
in a new layer between the transport and network layer still breaks the
network architecture.
Regards,
Mitch Nelson
netsec@panix.com
On Thu, 29 Aug 1996, Bill Sommerfeld wrote:
> Another way of looking at ipsec is that the transforms are really a
> layer *in between* network and transport.
>
> You're not so much adding a "user" concept at the network layer as
> adding a new layer next to the transport layer, which already has a
> concept of "user".
>
> - Bill
>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com@TIS.COM
Cc: ipsec@TIS.COM
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-02.txt
Date: Fri, 30 Aug 1996 09:41:20 -0400
Message-Id: <9608300941.aa18298@ietf.org>
Sender: ipsec-approval@neptune.tis.com
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.
Note: This revision reflects comments received during the last call period.
Title : HMAC-MD5 IP Authentication with Replay Prevention
Author(s) : M. Oehler, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-md5-02.txt
Pages : 7
Date : 08/29/1996
This document describes a keyed-MD5 transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [HMAC-MD5]. An option is also specified to guard against replay
attacks.
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-ah-hmac-md5-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-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.
For questions, please mail to Internet-Drafts@ietf.org
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="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960829163925.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-md5-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960829163925.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24083;
30 Aug 96 11:22 EDT
Received: by relay.hq.tis.com; id LAA15241; Fri, 30 Aug 1996 11:25:11 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma015228; Fri, 30 Aug 96 11:24:51 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA17783; Fri, 30 Aug 96 11:24:04 EDT
Received: by relay.hq.tis.com; id LAA15220; Fri, 30 Aug 1996 11:24:42 -0400
Received: from broadway.interport.net(199.184.165.4) by relay.tis.com via smap (V3.1.1)
id xma015204; Fri, 30 Aug 96 11:24:22 -0400
Received: from massey (massey.ftp.com [128.127.128.152]) by broadway.interport.net (8.7.3/8.7.3) with SMTP id LAA17411; Fri, 30 Aug 1996 11:26:33 -0400 (EDT)
Message-Id: <199608301526.LAA17411@broadway.interport.net>
X-Sender: rodney@pop3.pn.com
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 30 Aug 1996 11:26:28 -0400
To: "Perry E. Metzger" <perry@piermont.com>
From: Rodney Thayer <rodney@sabletech.com>
Subject: Re: Patents by Sun?
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I believe that if you're willing to dig, you can go to the Patent Office web
site at www.uspto.gov and look it up by number.
At 05:32 PM 8/29/96 -0400, you wrote:
>
>Someone forwarded this to me. I don't know if its real.
>
>I must admit I haven't yet tracked this down to confirm it (it might
>be a hoax) but it appears by the looks of it that Ashar has patented
>IPSEC. Again, I have to track down an independent copy to confirm
>it. If the claims listed are genuine, they are all on their face
>invalidated by prior art, but...
>
>Perry
>
>------- Forwarded Message
>
> System for signatureless transmission and reception of
> data packets between computer networks (Assignee -- Sun
> Microsystems, Inc.)
>
>
> Abstract: A system for automatically encrypting and
> decrypting data packet sent from a source host to a
> destination host across a public internetwork.
>
> A tunnelling bridge is positioned at each network, and
> intercepts all packets transmitted to or from its
> associated network.
>
> The tunnelling bridge includes tables indicated pairs of
> hosts or pairs of networks between which packets should
> be encrypted.
>
> When a packet is transmitted from a first host, the
> tunnelling bridge of that host's network intercepts the
> packet, and determines from its header information
> whether packets from that host that are directed to the
> specified destination host should be encrypted; or,
> alternatively, whether packets from the source host's
> network that are directed to the destination host's
> network should be encrypted.
>
> If so, the packet is encrypted, and transmitted to the
> destination network along with an encapsulation header
> indicating source and destination information: either
> source and destination host addresses, or the broadcast
> addresses of the source and destination networks (in the
> latter case, concealing by encryption the hosts'
> respective addresses).
>
> An identifier of the source network's tunnelling bridge
> may also be included in the encapsulation header. At the
> destination network, the associated tunnelling bridge
> intercepts the packet, inspects the encapsulation header,
> from an internal table determines whether the packet was
> encrypted, and from either the source (host or network)
> address or the tunnelling bridge identifier determines
> whether and how the packet was encrypted.
>
> If the packet was encrypted, it is now decrypted using a
> key stored in the destination tunnelling bridge's memory,
> and is sent on to the destination host.
>
> The tunnelling bridge identifier is used particularly in
> an embodiment where a given network has more than one
> tunnelling bridge, and hence multiple possible
> encryption/decryption schemes and keys.
>
> In an alternative embodiment, the automatic encryption
> and decryption may be carried out by the source and
> destination hosts themselves, without the use of
> additional tunnelling bridges, in which case the
> encapsulation header includes the source and destination
> host addresses.
>
>
> Ex Claim Text: A method for transmitting and receiving
> packets of data via an internetwork from a first host
> computer on a first computer network to a second host
> computer on a second computer network, the first and
> second computer networks including, respectively, first
> and second bridge computers, each of said first and
> second host computers and first and second bridge
> computers including a processor and a memory for storing
> instructions for execution by the processor, each of said
> first and second bridge computers further including
> memory storing at least one predetermined encryption/
> decryption mechanism and information identifying a
> predetermined plurality of host computers as hosts
> requiring security for packets transmitted between them,
> the method being carded out by means of the instructions
> stored in said respective memories and including the
> steps of:
>
> (1) generating, by the first host computer, a first data
> packet for transmission to the second host computer, a
> portion of the data packet including information
> representing an internetwork address of the first host
> computer and an internetwork address of the second host
> computer;
>
> (2) in the first bridge computer, intercepting the first
> data packet and determining whether the first and second
> host computers are among the predetermined plurality of
> host computers for which security is required, and if
> not, proceeding to step 5, and if so, proceeding to step
> 3;
>
> (3) encrypting the first data packet in the first bridge
> computer;
>
> (4) in the first bridge computer, generating and
> appending (4) in the first bridge computer, generating
> and appending to the first data packet an enapsulation
> header, including:
>
> (a) key management information identifying the
> predetermined encryption method, and
>
> (b) a new address header representing the source and
> destination for the data packet, thereby generating a
> modified data packet;
>
> (5) transmitting the data packet from the first bridge
> computer via the internetwork to the second computer
> network;
>
> (6) intercepting the data packet at the second bridge
> computer;
>
> (7) in the second bridge computer, reading the
> encapsulation header, and determining therefrom whether
> the data packet was encrypted, and if not, proceeding to
> step 10, and if so, proceeding to step 8;
>
> (8) in the second bridge computer, determining which
> encryption mechanism was used to encrypt the first data
> packet;
>
> (9) decrypting the first data packet by the second bridge
> computer;
>
> (10) transmitting the first data packet from the second
> bridge computer to the second host computer; and
>
> (11) receiving the unencrypted data packet at the second
> host computer.
>
> Assignee: Sun Microsystems, Inc.
>
> Patent Number: 5548646
>
> Issue Date: 1996 08 20
>
> Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson,
> Martin; Scott, Glenn. State/Country CA
>
>
>------- End of Forwarded Message
>
>
>
>
>
Rodney Thayer <rodney@sabletech.com> +1 617 332 7292
Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
Fax: +1 617 332 7970 http://www.shore.net/~sable
"Developers of communications software"
Received: from relay.hq.tis.com by neptune.TIS.COM id aa24190;
30 Aug 96 11:30 EDT
Received: by relay.hq.tis.com; id LAA15790; Fri, 30 Aug 1996 11:33:59 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma015772; Fri, 30 Aug 96 11:33:29 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA18290; Fri, 30 Aug 96 11:32:46 EDT
Received: by relay.hq.tis.com; id LAA15764; Fri, 30 Aug 1996 11:33:25 -0400
Received: from www.borderware.com(199.71.190.98) by relay.tis.com via smap (V3.1.1)
id xma015742; Fri, 30 Aug 96 11:33:19 -0400
Received: by janus.border.com id <18461-1>; Fri, 30 Aug 1996 11:31:28 -0400
Message-Id: <96Aug30.113128edt.18461-1@janus.border.com>
To: "M.C.Nelson" <netsec@panix.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
References: <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>
In-Reply-To: netsec's message of "Fri, 30 Aug 1996 09:59:49 -0400".
<Pine.SUN.3.91.960830095654.26224C-100000@panix.com>
From: "C. Harald Koch" <chk@border.com>
Date: Fri, 30 Aug 1996 11:30:27 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
In message <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>, "M.C.Nelson" writes:
>
> The transport layer doesn't have "user" either. Adding a "user" concept
> in a new layer between the transport and network layer still breaks the
> network architecture.
Fine. I guess we should all throw our hands up in disgust and walk away from
the table. The pristine purity of the ISO reference model must be preserved
at all cost, right?
Do you propose removing all user-based authentication from PPP (CHAP and
PAP) also? After all, PPP is a link layer protocol, and the link layer
doesn't have a "user" either. How about SSL, at the transport layer?
User-oriented keying is useful, and works. The concept is orthogonal to
network stack layering. If it voliates some holy "architecture design
principles", then those principles should be changed.
IMHO, of course.
--
Harald Koch
chk@border.com
Message-Id: <199608301559.LAA04638@jekyll.piermont.com>
To: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
In-Reply-To: Your message of "Thu, 29 Aug 1996 20:13:05 EDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 30 Aug 1996 11:59:20 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
"Mitchell C. Nelson" writes:
> Paul, I think you need to think through your scenario a little
> more carefully. You'll probably see that your argument doesn't fly.
>
> The present IPSEC does in fact, break the network architecture.
Given that there are real implementations of IPSEC for fairly standard
operating systems like 4.4BSD, and that people are, today,
successfully moving around IPSEC packets on the real live internet,
I'm rather unsure as to why we should be paying attention to your
continued claims that the whole thing can't possibly work.
Perry
Message-Id: <199608301606.MAA04664@jekyll.piermont.com>
To: "M.C.Nelson" <netsec@panix.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
In-Reply-To: Your message of "Fri, 30 Aug 1996 09:59:49 EDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 30 Aug 1996 12:06:30 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
"M.C.Nelson" writes:
> The transport layer doesn't have "user" either.
Gee, Mr. Nelson, so I suppose all those telnet sessions I've done over
the years were just an illusion, eh? After all, since the transport
layer has no notion of user, there is no way for the transport layer
to direct data to a particular process, so Telnet can't possibly be
implemented, not to mention SMTP. In fact, this mail message is an
illusion.
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa25011;
30 Aug 96 12:18 EDT
Received: by relay.hq.tis.com; id MAA17629; Fri, 30 Aug 1996 12:21:36 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma017604; Fri, 30 Aug 96 12:21:05 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA20800; Fri, 30 Aug 96 12:20:24 EDT
Received: by relay.hq.tis.com; id MAA17599; Fri, 30 Aug 1996 12:21:04 -0400
Received: from netcom8.netcom.com(192.100.81.117) by relay.tis.com via smap (V3.1.1)
id xma017578; Fri, 30 Aug 96 12:20:49 -0400
Received: from winp133 (ple-ca16-03.ix.netcom.com [204.31.114.195]) by netcom8.netcom.com (8.6.13/Netcom)
id JAA03651; Fri, 30 Aug 1996 09:23:08 -0700
Message-Id: <2.2.32.19960830162309.00a233f4@netcom8.netcom.com>
X-Sender: dpalma@netcom8.netcom.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 30 Aug 1996 09:23:09 -0700
To: ipsec@TIS.COM
From: Derek Palma <dpalma@netcom.com>
Subject: Re: OAKLEY/ISAKMP/SKIP design group
Cc: dpalma@netcom.com
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hello everyone,
I would also like to express my disappointment (and my customers')
regarding the outcome of the OAKLEY/ISAKMP/SKIP design group.
My company, like many others, tries to provide its customers with
with the best technologies in a timely manner. We have always
looked to the IETF to provide working, interoperable, scalable, sound, and
in many cases state-of-the-art solutions to networking problems.
IETF working groups have consisted of the best minds in the industry
working toward very explicit objectives. These groups have been able
to avoid most of the red tape found in formal standards bodies
in order to obtain quick practical objectives.
I am sorry to see that key management, the mechanism required to make
network layer security practical and useful, will not be available
in a unified form backed with the group's consensus. There are some
very good proposals and a significant number working implementations.
It is truly a shame after so much effort of so many people.
However my company must address the fact that network layer
security can be quite useful and is required by its customers. My company
must provide a solution. I hoped that it would be a draft based on
a unified solution from this work group.
Currently, we have based our implmentations on SKIP, which seems significatnly
more mature than the others. But most importantly, it solves our customers'
problems. This is all our customers care about! And as long as the
technology achieves this, we are satisfied.
So I think it is important to note that those who need network layer
security with key management will have it. This work group may not
endorse, like, or acknowledge it. But it will continue to exist and might
even proliferate.
If the working group cannot reach consensus, maybe it should let the market
be the judge. The market will certainly do this anyway. Mutiple drafts
on the standards track are better than none. And if one catches on, this
working group and the IETF will still maintain significant influence over
its design and use.
Regards,
Derek Palma
---------------------------------------------------------------------
Derek Palma Email: dpalma@netcom.com
Net Research, Inc. Direct:(510) 487-6439
32536 Monterey Way Main: (510) 487-6300
Union City, CA 94587 FAX: (510) 487-6072
Message-Id: <199608301718.NAA04790@jekyll.piermont.com>
To: Rodney Thayer <rodney@sabletech.com>
Cc: ipsec@TIS.COM
Subject: Re: Patents by Sun?
In-Reply-To: Your message of "Fri, 30 Aug 1996 11:26:28 EDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 30 Aug 1996 13:18:14 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Rodney Thayer writes:
> I believe that if you're willing to dig, you can go to the Patent Office web
> site at www.uspto.gov and look it up by number.
Unfortunately, this one was only granted a few days ago so the data at
uspto.gov isn't up yet if the patent is real.
Perry
Received: from relay.hq.tis.com by neptune.TIS.COM id aa28192;
30 Aug 96 15:24 EDT
Received: by relay.hq.tis.com; id PAA24272; Fri, 30 Aug 1996 15:27:44 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma024266; Fri, 30 Aug 96 15:27:16 -0400
Received: from la.tis.com (scintillate.la.tis.com) by tis.com (4.1/SUN-5.64)
id AA29626; Fri, 30 Aug 96 15:19:51 EDT
Received: from relay.la.tis.com by la.tis.com (4.1/SUN-5.64)
id AA29235; Fri, 30 Aug 96 12:21:35 PDT
Received: by relay.la.tis.com; id MAA27776; Fri, 30 Aug 1996 12:16:56 -0700
Received: from maildeliver4.tiac.net(199.0.65.168) by relay.la.tis.com via smap (V3.1.1)
id xma027774; Fri, 30 Aug 96 12:16:32 -0700
Received: from mailserver2.tiac.net (mailserver2.tiac.net [199.0.65.231]) by maildeliver4.tiac.net (8.6.12/8.7.4) with ESMTP id PAA03847; Fri, 30 Aug 1996 15:25:12 -0400
Received: from toonces (ksiegel.tiac.net [206.119.132.115]) by mailserver2.tiac.net (8.6.12/8.7.4) with SMTP id PAA17535; Fri, 30 Aug 1996 15:25:09 -0400
Message-Id: <2.2.32.19960830191858.006ba480@tiac.net>
X-Sender: ksiegel@tiac.net
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 30 Aug 1996 15:18:58 -0400
To: Rodney Thayer <rodney@sabletech.com>,
"Perry E. Metzger" <perry@piermont.com>
From: Ken Siegel <ksiegel@switchblade.com>
Subject: Re: Patents by Sun?
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
If it is true that it was granted it is not yet
online. However, Ashar (and hence Sun) have been
granted another patent (in 1995) that I found in
the database. The returned abstract is listed
below. Sorry if the formatting is bad but I cut
and pasted from Netscape. This patent is certainly
also relevant to IPSEC.
------------begin patent stuff----------------
United States Patent
5,416,842
Aziz
May 16, 1995
Method and apparatus for key-management scheme for use with internet
protocols at site firewalls
Inventors:
Aziz; Ashar (Fremont, CA).
Assignee:
Sun Microsystems, Inc. (Mountain View, CA).
Appl. No.:
258,344
Filed:
Jun. 10, 1994
Intl. Cl.:
H04L 9/30; H04L 9/08; H04L 9/00
U.S. Cl.:
380/ 30; 380/ 4; 380/ 21; 380/ 23; 380/ 25; 380/ 49
Field of Search:
380/4, 21, 23, 25, 30, 46, 49, 50; 371/68.3
References Cited [Referenced By:]
U.S. Patent Documents
4,916,704
Apr., 1990
Bruckert et al.
371/ 68.3
Other References
Whitfield Diffie, "The First Ten Years of Public-Key Cryptography",
(Proceedings of the IEEE, vol. 76, No. 5, May 1988).
Paul Fahn, "Answers to Frequently Asked Questions About Today's
Cryptography", (RSA Laboratories, 1992).
"Part I: Message Encryption and Authentication Procedures", (Privacy
Enhancement for Internet Electronic Mail, J. Linn (Network Working Group), Feb.,
1993.
"Part II: Certificate-Based Key Management", (Privacy Enhancement for
Internet Electronic Mail, S. Kent (Network Working Group), Feb., 1993.
"Part III: Algorithms, Modes, and Identifiers", (Privacy Enhancement
for Internet Electronic Mail), D. Balenson (Network Working Group), Feb., 1993.
"Part IV: Key Certification and Related Services" (Privacy Enhancement
for Internet Electronic Mail), B. Kaliski (Network Working Group), Feb., 1993.
Whitfield Diffie, Paul C. Van Oorschoot and Michael J. Wiener,
"Authentication and Authenticated Key Exchanges" (Designs, Codes and
Cryptography,
2-107-125 (1992), Kluwer Academic Publishers).
"The MD5 Message-Digest Algorithm"; MIT Laboratory for Computer Science
and RSA Data Security, Inc. (1992), R. Rivest (Network Working Group).
RSA Data Security, Inc. Technology Bulletin, copy undated.
Primary Examiner: Gregory; Bernarr E.
Attorney, Agent or Firm: Irell & Manella
Abstract
The present invention includes a first data processing device (node I)
coupled to a first private network and to a firewall server (FWA). Firewall
server FWA is in
turn coupled to a public network, such as the Internet. A second data
processing device (node J) is coupled to a second private network which is
coupled to the
Internet through a firewall server (FWB). Node I provides a data packet
including IP data and a destination address for the intended receiving node
J to firewall
FWA. Firewall FWA is provided with a secret value a, and a public value
.varies.(^a) mod p. Similarly, firewall FWB is provided with a secret value
b and a
public value .varies.(^b) mod p. The firewall FWA obtains a Diffie-Hellman
(DH) certificate for firewall FWB and determines the public value
.varies.(^b) mod p
from the DH certificate. Firewall FWA then computes the value of
.varies.(^ab) mod p, and derives a key K(ab) from the value .varies.(^ab)
mod p. A transient
key K(p) is randomly generated and is used to encrypt the data packet to be
transmitted by firewall FWA to firewall FWB. The encrypted data packet is then
encapsulated in a transmission packet by the firewall FWA. The transmission
packet includes an unencrypted destination address for the firewall FWB.
Firewall
FWA then sends the transmission packet to firewall FWB over the Internet.
Upon receipt of the transmission packet from firewall FWA, firewall FWB
obtains a
DH certificate for firewall FWA, and determines the public value of
.varies.(^a) mod p from the DH certificate. Firewall FWB computes the value
of .varies.(^ab)
mod p, and derives the key K(ab). Firewall B utilizes the key K(ab) to
decrypt the transient key K(p), and using the decrypted transient key K(p),
firewall FWB
decrypts the encrypted data packet received from FWA, thereby resulting in
the recovery of the original data sent by node I in unencrypted form to the
firewall
FWA. The firewall FWB then transmits the decrypted data packet to the
receiving node J over the second private network.
Ken Siegel
Switchblade Networks, Inc.
6 Lisa Drive
Nashua, NH 03062
Phone: (603) 891-1500
Internet: ksiegel@switchblade.com
URL: www.switchblade.com
Date: Fri, 30 Aug 1996 10:50:52 -0700
From: Glenn Scott <asdf@osmosys.incog.com>
Message-Id: <199608301750.KAA22206@ono-sendai.incog.com>
To: ipsec@TIS.COM
Subject: Re: Patents by Sun?
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
>I must admit I haven't yet tracked this down to confirm it (it might
>be a hoax) but it appears by the looks of it that Ashar has patented
>IPSEC. Again, I have to track down an independent copy to confirm
>it. If the claims listed are genuine, they are all on their face
>invalidated by prior art, but...
I actually have a copy of the whole patent and since I'm one of the
inventors I can at least state what we did: It's a way to use fake addressing
to do some tunneling and topology hiding.
This patent does not attempt to patent IPSEC. Having been through this
stuff before I caution any reader to judge a patent's defensibility or what
invalidates it by just its abstract.
This list is starting to read a bit like alt.conspiracy.
Glenn
Message-Id: <3.0b11.32.19960830143943.00a3ad48@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 30 Aug 1996 15:16:24 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Will the real PFS please stand up?
Cc: "David M. Balenson" <balenson@TIS.COM>, ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 10:59 AM 8/29/96 -0400, Bill Sommerfeld wrote:
>
>> >Now, if I and J are just host identities, this isn't interesting
>> >(because the same information is found in their IP addresses) but if
>> >SKIP gets extended to do per-user keying I think we have a potential
>> >problem.
>>
>> Huh? Please enlighten me.
>
>If the `name' in the certificate is just an IP address, then
>compromise of the contents of Cert_I and Cert_J reveals no information
>not already available to eavesdroppers, and skip-pfs's lack of PFS
>protection on the exchanged certificates is moot.
>
>If the `name' in the certificate contains something other than an IP
>address, or something more than an IP address, then skip-pfs's lack of
>PFS protection on the exchanged certificates becomes interesting.
AH HA! Ok, the certs that I see using will be either X.509 or SDSI. And
yes, I will not want even this exposure. The cert will say that this is Bob
Eaton currently over in Frankfurt. Whoa, no.
>As above.. if principal names are always IP addresses, there's no
>benefit in keeping them secret in the key mgt protocol because they're
>sent in the clear in every packet..
I expect to have x.509 certs for this and they will not be IP addressed.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Message-Id: <3.0b11.32.19960830151026.009cc120@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 30 Aug 1996 15:16:29 -0400
To: David Wheeler-P26179 <David_Wheeler-P26179@email.mot.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Everything degenerates to Key Management
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 01:03 PM 8/29/96 -0500, David Wheeler-P26179 wrote:
>I've been listening/reading the group's discussions for some time.It is
>clear
>that IPSEC, we, must produce and field a viable solution within the next
>year
>or be overcome by events. This truth, while brutal, I think can be
>confirmed
>independently by all of us.
OK People. On Sept 19th, the AIAG's ANX security wg will have its 2nd
meeting in Detroit. At this meeting we will be calling for interoperbility
testing to deliver products YE96 - 1Q97.
>I agree heartily with Mr. Harald Koch:
>>The people working on other protocols requiring security (TLS, L2TP, LDAP,
>>and probably others) have all been overheard saying the same thing:
>>
>> Wouldn't it be nice to have a single key negotiation protocol for
>> IPsec *and* for our protocols?
The AIAG's ANX EC messaging wg has been floating a secure EDI envelope on
the SMIME-DEV list. Guess what, X.509 again but HTTP protocol, LDAP or
SDSI? Gee we will want something commonized here.
>>how can my laptop get back through my company's
>>firewall in a safe and secure fashion?
Back then this was a noble goal. In today's environment there are solutions
you can buy to address this tactically. Yes the market overtook the group;
probably learned a lot from the group too. Today's business world is my
laptop connecting back to 3 company divisions and 2 trading partners at the
same time.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Message-Id: <3.0b11.32.19960830145003.012bad40@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 30 Aug 1996 15:16:27 -0400
To: caronni@tik.ee.ethz.ch, Robert Moskowitz <rgm3@chrysler.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Will the real PFS please stand up?
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 04:08 PM 8/29/96 +0200, Germano Caronni wrote:
>
>by the way:
>In my opinion escrowing communicated data is nuts anyway, you want key
>escrow for long term archived data, where key owners (and their secrets)
>may 'get lost'...
Agreed. Actually on escrowing I am mind-game playing. Determine a
methodology that meets business functional goals. show that it
'invalidates' key excrowing. Watch the fun start in the belt-way. sigh.
BTW, I THINK that all of these are vulnerable to man-in-the-middle attacks
where the private keys of both parties are know? I can see a business for
sniffers that can work in this way.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from relay.hq.tis.com by neptune.TIS.COM id aa29480;
30 Aug 96 16:38 EDT
Received: by relay.hq.tis.com; id QAA26519; Fri, 30 Aug 1996 16:41:40 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma026497; Fri, 30 Aug 96 16:41:11 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA05461; Fri, 30 Aug 96 16:40:30 EDT
Received: by relay.hq.tis.com; id QAA26494; Fri, 30 Aug 1996 16:41:10 -0400
Received: from panix.com(198.7.0.2) by relay.tis.com via smap (V3.1.1)
id xma026481; Fri, 30 Aug 96 16:41:02 -0400
Received: (from netsec@localhost) by panix.com (8.7.5/8.7/PanixU1.3) id QAA22359; Fri, 30 Aug 1996 16:42:38 -0400 (EDT)
Date: Fri, 30 Aug 1996 16:42:32 -0400 (EDT)
From: "M.C.Nelson" <netsec@panix.com>
To: "C. Harald Koch" <chk@border.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
In-Reply-To: <96Aug30.113128edt.18461-1@janus.border.com>
Message-Id: <Pine.SUN.3.91.960830162437.19361A-100000@panix.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
It is not true that if we cannot have a user-keyed network layer
mechanism we should throw our hands-up and leave the table. There
is a place in the network architecture for user keyed security.
But it is not in the lower layers.
Obviously, it is also not true that user oriented keying is orthogonal
to network stack layering (architecture).
We should provide appropriate security services using appropriate
mechanisms implemented in a manner consistent with existing
architecture. If user security is needed, there is at least one
right way to do it. Do it right - it will cost less, be easier to
implement, and work better.
Regards,
Mitch Nelson
netsec@panix.com
On Fri, 30 Aug 1996, C. Harald Koch wrote:
> In message <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>, "M.C.Nelson" writes:
> >
> > The transport layer doesn't have "user" either. Adding a "user" concept
> > in a new layer between the transport and network layer still breaks the
> > network architecture.
>
> Fine. I guess we should all throw our hands up in disgust and walk away from
> the table. The pristine purity of the ISO reference model must be preserved
> at all cost, right?
>
> Do you propose removing all user-based authentication from PPP (CHAP and
> PAP) also? After all, PPP is a link layer protocol, and the link layer
> doesn't have a "user" either. How about SSL, at the transport layer?
>
> User-oriented keying is useful, and works. The concept is orthogonal to
> network stack layering. If it voliates some holy "architecture design
> principles", then those principles should be changed.
>
> IMHO, of course.
>
> --
> Harald Koch
> chk@border.com
>
Message-Id: <199608302051.QAA12777@jekyll.piermont.com>
To: Glenn Scott <asdf@osmosys.incog.com>
Cc: ipsec@TIS.COM
Subject: Re: Patents by Sun?
In-Reply-To: Your message of "Fri, 30 Aug 1996 10:50:52 PDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 30 Aug 1996 16:51:40 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Glenn Scott writes:
> >I must admit I haven't yet tracked this down to confirm it (it might
> >be a hoax) but it appears by the looks of it that Ashar has patented
> >IPSEC. Again, I have to track down an independent copy to confirm
> >it. If the claims listed are genuine, they are all on their face
> >invalidated by prior art, but...
>
> I actually have a copy of the whole patent and since I'm one of the
> inventors I can at least state what we did: It's a way to use fake addressing
> to do some tunneling and topology hiding.
That isn't what the claims section I received (which I posted) says.
> This patent does not attempt to patent IPSEC. Having been through this
> stuff before I caution any reader to judge a patent's defensibility or what
> invalidates it by just its abstract.
The abstract isn't the important part. The claims are -- they are the
portion which is legally actionable. Were the claims posted the actual
ones, or was I sent an inaccurate set of claims? The claims there
appear to cover *any* IPSEC style mechanism. This is the set that I
have in my possession.
+ Ex Claim Text: A method for transmitting and receiving
+ packets of data via an internetwork from a first host
+ computer on a first computer network to a second host
+ computer on a second computer network, the first and
+ second computer networks including, respectively, first
+ and second bridge computers, each of said first and
+ second host computers and first and second bridge
+ computers including a processor and a memory for storing
+ instructions for execution by the processor, each of said
+ first and second bridge computers further including
+ memory storing at least one predetermined encryption/
+ decryption mechanism and information identifying a
+ predetermined plurality of host computers as hosts
+ requiring security for packets transmitted between them,
+ the method being carded out by means of the instructions
+ stored in said respective memories and including the
+ steps of:
+
+ (1) generating, by the first host computer, a first data
+ packet for transmission to the second host computer, a
+ portion of the data packet including information
+ representing an internetwork address of the first host
+ computer and an internetwork address of the second host
+ computer;
+
+ (2) in the first bridge computer, intercepting the first
+ data packet and determining whether the first and second
+ host computers are among the predetermined plurality of
+ host computers for which security is required, and if
+ not, proceeding to step 5, and if so, proceeding to step
+ 3;
+
+ (3) encrypting the first data packet in the first bridge
+ computer;
+
+ (4) in the first bridge computer, generating and
+ appending (4) in the first bridge computer, generating
+ and appending to the first data packet an enapsulation
+ header, including:
+
+ (a) key management information identifying the
+ predetermined encryption method, and
+
+ (b) a new address header representing the source and
+ destination for the data packet, thereby generating a
+ modified data packet;
+
+ (5) transmitting the data packet from the first bridge
+ computer via the internetwork to the second computer
+ network;
+
+ (6) intercepting the data packet at the second bridge
+ computer;
+
+ (7) in the second bridge computer, reading the
+ encapsulation header, and determining therefrom whether
+ the data packet was encrypted, and if not, proceeding to
+ step 10, and if so, proceeding to step 8;
+
+ (8) in the second bridge computer, determining which
+ encryption mechanism was used to encrypt the first data
+ packet;
+
+ (9) decrypting the first data packet by the second bridge
+ computer;
+
+ (10) transmitting the first data packet from the second
+ bridge computer to the second host computer; and
+
+ (11) receiving the unencrypted data packet at the second
+ host computer.
+
+ Assignee: Sun Microsystems, Inc.
+
+ Patent Number: 5548646
+
+ Issue Date: 1996 08 20
+
+ Inventor(s): Aziz, Ashar; Mulligan, Geoffrey; Patterson,
+ Martin; Scott, Glenn. State/Country CA
Received: from relay.hq.tis.com by neptune.TIS.COM id aa00964;
30 Aug 96 17:56 EDT
Received: by relay.hq.tis.com; id RAA28601; Fri, 30 Aug 1996 17:59:41 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma028597; Fri, 30 Aug 96 17:59:16 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA08753; Fri, 30 Aug 96 17:58:31 EDT
Received: by relay.hq.tis.com; id RAA28594; Fri, 30 Aug 1996 17:59:10 -0400
Received: from tik1.ethz.ch(129.132.119.131) by relay.tis.com via smap (V3.1.1)
id xma028592; Fri, 30 Aug 96 17:58:51 -0400
Received: from kom30.ethz.ch (kom30 [129.132.66.8]) by tik1.ethz.ch (8.7.5/8.7.3) with ESMTP id AAA09960; Sat, 31 Aug 1996 00:01:08 +0200 (MET DST)
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Received: (from caronni@localhost) by kom30.ethz.ch (8.7.5/8.7.3) id AAA07280; Sat, 31 Aug 1996 00:01:05 +0200 (MET DST)
Message-Id: <199608302201.AAA07280@kom30.ethz.ch>
Subject: Re: Patents by Sun?
To: Ken Siegel <ksiegel@switchblade.com>
Date: Sat, 31 Aug 1996 00:01:04 +0200 (MET DST)
Cc: rodney@sabletech.com, perry@piermont.com, ipsec@TIS.COM
In-Reply-To: <2.2.32.19960830191858.006ba480@tiac.net> from "Ken Siegel" at Aug 30, 96 03:18:58 pm
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Ken Siegel wrote:
> If it is true that it was granted it is not yet
> online. However, Ashar (and hence Sun) have been
> granted another patent (in 1995) that I found in
> the database. The returned abstract is listed
> below. Sorry if the formatting is bad but I cut
> and pasted from Netscape. This patent is certainly
> also relevant to IPSEC.
>
> Method and apparatus for key-management scheme for use with internet
> protocols at site firewalls
Well, it is none of my business, but _that_ patent has been placed in the
public domain a long while ago. I guess they did this so nobody else could
make a patent on that stuff and hinder their work.
Germano
----excerpt of blurb-----
Sun Microsystems, Inc., in the interest of promoting an open-systems,
standardized approach to key management for use on the Internet, is
taking the step of dedicating important intellectual property rights in
this area to the public.
Sun has submitted a proposed specification to the IETF entitled "Simple
Key Management Scheme for Internet Protocols (SKIP)". On June 10 1994,
Sun filed two patent applications with the United States Patent Office
relating to SKIP, entitled "Method and Apparatus for a Key Management
Scheme for Internet Protocols", Serial No. 08/258,272; and "Method and
Apparatus for Key Management Scheme for Use with Internet Protocols at
Site Firewalls", Serial No. 08/258,344. Sun wishes to dedicate its
rights under these two applications to the public, and to that end
hereby licenses all persons and companies to practice the SKIP
procedures claimed in these patent applications (and in the patents
resulting from the applications, when and if they issue). This license
is immediately effective, and requires no fee.
Received: from relay.hq.tis.com by neptune.TIS.COM id aa10175;
31 Aug 96 9:54 EDT
Received: by relay.hq.tis.com; id JAA03752; Sat, 31 Aug 1996 09:57:35 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1)
id xma003750; Sat, 31 Aug 96 09:57:10 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64)
id AA19611; Sat, 31 Aug 96 09:56:24 EDT
Received: by relay.hq.tis.com; id JAA03747; Sat, 31 Aug 1996 09:57:05 -0400
Received: from angus.asg.unb.ca(198.164.16.10) by relay.tis.com via smap (V3.1.1)
id xma003745; Sat, 31 Aug 96 09:57:03 -0400
Received: from opie.ASG.unb.ca by mailhub.ASG.unb.ca (AIX 3.2/UCB 5.64/4.03)
id AA50570; Fri, 30 Aug 1996 12:20:37 -0300
Date: Fri, 30 Aug 1996 12:20:37 -0300 (ADT)
From: Peter Howlett <phowlett@asg.unb.ca>
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security. reply to respondents.
In-Reply-To: <Pine.SUN.3.91.960830095654.26224C-100000@panix.com>
Message-Id: <Pine.A32.3.93.960830120814.15482A-100000@opie.ASG.unb.ca>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I have always thought about this from the point of view that the
user level does indeed sometimes have a direct influence on
lower layers in the stack. IP options for example can be
manipulated by a user to get particular attributes from a
mode of communication.
With IPv6, and those new headers that can be inserted between
the conventional layers of the stack, attributes of packets that
are sent out can be set by a user level application. Personally,
I do not believe this constitutes breaking the architecture, but
simply provides required control over the data (and corresponding
attributes) that are sent and received. I think IPSec falls into
this category.
On Fri, 30 Aug 1996, M.C.Nelson wrote:
> Bill,
>
> The transport layer doesn't have "user" either. Adding a "user" concept
> in a new layer between the transport and network layer still breaks the
> network architecture.
>
> Regards,
> Mitch Nelson
> netsec@panix.com
>
>
>
>
> On Thu, 29 Aug 1996, Bill Sommerfeld wrote:
>
> > Another way of looking at ipsec is that the transforms are really a
> > layer *in between* network and transport.
> >
> > You're not so much adding a "user" concept at the network layer as
> > adding a new layer next to the transport layer, which already has a
> > concept of "user".
> >
> > - Bill
> >
>
--------------------------------------------------------------------
Peter Howlett Atlantic Systems Group
E-Mail: Peter.Howlett@ASG.unb.ca Fredericton, N.B. Canada
http://www.ASG.unb.ca/personal/ph.html Phone: (506) 447-3050
PGP Key ID: 60F2EEC1 Fax: (506) 453-5004