From ipsec-request@ans.net Thu Dec 14 16:55:43 1995
Date: Thu, 14 Dec 1995 15:23:02 -0800
From: Ashar Aziz (ashar@osmosys.incog.com (Ashar Aziz))
To: ipsec@ans.net ( ipsec@ans.net)
Subject: forward secrecy
X-Sun-Charset: US-ASCII
Xref: Re: forward secrecy Hilarie Orman
Xref: Re: forward secrecy Phil Karn
Xref subject next
Folks,
I would like to raise a few issues regarding forward secrecy
that, I believe, have received insufficient discussion to date.
First of all, the attack scenario that a typical "perfect forward
secrecy" protocol using ephemeral Diffie-Hellman guards against
has always been implicit, and not explicit. I would like to
make the assumptions of this attack more explicit, and discuss
other attacks of a different nature that also affect forward
secrecy.
The attack that an ephemeral DH exchange guards against is compromise
of a long-term secret. If long-term secrets are properly guarded (e.g.
tamper resist token devices, encrypted under passwords etc.) then such an
attack to compromise the long-term secret is an active attack, and in
cases of tamper resist hardware token devices it is an active physical
attack.
It is important to observe that an ephemeral Diffie-Hellman
exchange needs to be efficient, (since it happens interactively in
real time) and in order to be efficient the sizes of the DH
parameters have to be chosen carefully. With Diffie-Hellman there is a
clear tradeoff between efficiency and security. The greater the
sizes of the DH parameters (exponent, modulus) the greater the
security but the slower the speed of the operation.
Another observation is that the DH problem, over time,
becomes more tractable. Let's take as an example an ephemeral
DH protocol that might have been used 10 years ago. For
reasons of efficiency the modulus size for such a
DH exchange would very likely have been 512 bits. Clearly now,
10 years later, it is possible to mount attacks on a 512
bit DH problem, especially for well funded adversaries.
Now assume the adversary is someone like the NSA. For
purposes of this discussion, this could also be the foreign
equivalents of the NSA. The NSA is primarily a signals
intelligence agency. If the NSA performs field operations,
they are probably of a very limited nature. The same is
true of the foreign equivalents of the NSA. Such agencies
operate primarily using *passive* attacks.
What the NSA (and their foreign equivalents) are far more
likely to do is to record all cipherbits, and if necessary,
store them for a few years/decades, until they can be
broken. A recently disclosed case of such a passive
attack revealed that the NSA saved ciphertext for 40+
years, waiting for the moment it could be broken.
I would like to argue that this passive attck a more likely
form of attack, especially considering signals intelligence
agencies as the enemy. What the ephemeral DH exchange is
doing is hardening against the active attack (I argue, a less
likely scenario) while *weakening* the protocol
(for practical efficiency reasons) against a passive
sit-on-it-until-it-can-be-crunched form of attack.
To summarize: There are two forms of attacks that
pertain to forward secrecy. The active attack, and a passive
time delayed attack, mountable by tenacious and well-funded
adversaries. So far, the discussion on forward secrecy has
focused on the active attack.
The forward secrecy solution that I described on this
list and presented at Dallas (pre-certified short lived
Diffie-Hellman keys), in the context of SKIP, has the advantage
that none of the DH operations needs to be performed in real
time. They can all be precomputed. This makes it feasible
to use much larger DH parameters, say 4000 bit DH
exponents/modulus, than is practical today with an
interactive ephemeral DH exchange.
This provides much more effective hardening against a time
delayed passive attack.
Now, one could argue, that with lots of ephemeral DH
exchanges, occurring every few minutes/hours, the enemy doesn't
have to break just one DH exchange, there are many such exchanges
to break. Unfortunately, the work factor of a time delayed
passive attack only goes up by a small linear factor, even with
many ephemeral DH exchanges. With a much larger DH exponent/modulus,
the work factor goes up in a super-polynomial fashion, assuming
Number Field Sieve as the best attack on classic DH. (Again
taking the 512 bit DH case as an example, if the NSA can break
one of these, it could also break a few thousand of these.
On the other hand, breaking a single 1024 bits DH today is
probably infeasible).
Therefore, I argue that we need to provide hardening against
*both* the active and the passive attack. The question is
what attack should the protocol be better hardened against,
since there is a clear tradeoff involved.
If we believe that the active attack is a more
likely form of attack, then frequent ephemeral DH exchanges
(e.g. as in Photuris) provide a better forward secrecy solution.
However, if we believe that the passive attack is more likely,
then the pre-certified short lived DH keys, in conjunction with
much larger DH parameters, provides a better forward secrecy
solution. I hesitate to use the term "perfect", since this
is an overstatement in either case. (The only way to get
really perfect forward secrecy is to use a one-time pad,
which is destroyed after use).
[There are other issues, apart from forward secrecy, that could
be considered, such as the real-time response to a large number of
simultaneous connection attempts, etc., but this discussion can focus
solely on forward secrecy issues.]
Comments?
Ashar.
From ipsec-request@ans.net Wed Dec 20 12:40:26 1995
Date: Wed, 20 Dec 1995 11:02:27 -0800
From: Ran Atkinson (Ran Atkinson -rja@cisco.com-)
To: ipsec@ans.net ( ipsec@ans.net)
Subject: ADMIN: Dallas IETF Minutes for IP Security WG
Xref subject next
All,
Appended below are the written minutes for the IP Security WG that were
submitted to CNRI for inclusion in the written proceedings.
Special thanks are due to Richard Graveman (Bellcore) who once again
provided the co-chairs with his clearly written notes on the meetings
and did so very shortly after each session. Our minutes are almost
entirely his words.
Ran Atkinson Paul Lambert
rja@cisco.com palamber@us.oracle.com
--------------------- cut here ---------------------------------
Minutes for IP Security Working Group
34th IETF, Dallas, TX, December 1995.
These minutes are largely based on the notes taken by Richard
Graveman during the meetings. The WG chairs
thank him for his assistance in taking good notes during the meeting.
Co-chair Paul Lambert was the floor moderator
for most of this session. He was assisted by Randall Atkinson
. Paul noted that both of the co-chairs recently
changed employers and so have new email addresses.
IP Security WG mailing list is likely to be rehomed early
in 1996. If it moves, the change will be announced on the main ietf
mailing list. The current (as of December 1995) mailing list addresses are:
Postings: ipsec@ans.net
Admin: ipsec-request@ans.net
IP Security (IPSEC) Session 1, December 4th, 1995:
--------------------------------------------------
RFC 1825 through RFC-1829 define the IP Encapsulating Security
Payload (ESP) and the IP Authentication Header (AH). These were issued
as Proposed Standard RFCs this past August. The discussions during
the first IPsec meeting were focused on these specifications.
LIAISONS:
Ran noted that options in IPv6 are handled differently from
IPv4. A bag of Hop-By-Hop options may follow the base IPv6 header.
After these may come Destination Options and then the upper layer
protocol (e.g. ICMP, TCP, or UDP). Destination Options are only
handled by specifically listed destination systems for the IPv6
packet, while Hop-By-Hop options are handled by each intermediate
system and end system (host or router). It might be useful to
consider specifying AH for IPv6 as either a Hop-By-Hop Option or
Destination Option rather than as a separate header. One advantage is
that if AH were specified in this new way, the semantics of AH
processing might be more clear for IPv6 implementations and two
different semantics could be supported. Another possible advantage is
to force AH to be parsed first at the destination(s), even though would
not be handled at the routers. This is expected to be discussed
more during the IPng WG meetings later this week.
AH/ESP IMPLEMENTATION STATUS:
Ran posed the following questions for all implementers:
Whose implementation ?
Implemented in what (host router, etc) ?
Is it commercial or freely available?
Which transforms were implemented ?
It is known to interoperate with ?
Which key distribution techniques are implemented ?
Ran:
The freely distributable NRL implementation covers IPv4 and
IPv6 for hosts and routers, is based on 4.4-Lite BSD, Implements Keyed
MD5 and DES-CBC, works with Karn and Morningstar, and has manual key
management. A particular feature is that this implementation includes
a Key Management Socket (PF_KEY) that permits key management daemons
to be implemented outside the kernel in a portable manner. It is
likely that NRL will document PF_KEY in an Informational RFC during
the next few months. Additional transforms are easy to add to this
implementation. Configured secure tunnels, dynamic tunnel-mode
encryption, and transport-mode encryption are all supported using
extensions to the widely used BSD network Sockets API. Applications
that support use of IPsec via command-line options are also included
in the distribution.
See Dan McDonald or Bao Phan
for more information. This implementation is
freely available (modulo US Export Controls) and is reportedly online
at ftp://ftp.c2.org MIT is expected to be the official archive site
for the NRL software, but is still working on getting the software
online. Enhancements to the NRL software are underway and will also
become freely distributable. A paper on the details of this
implementation will be presented at the January 1995 USENIX
Conference.
John Ioannidis ("JI") :
This implementation was implemented in Greece, runs on BSDI, and will
be freely available. It implements keyed MD5 and DES CBC, uses manual key
distribution or Photuris (also implemented outside US) key distribution,
and handles multiple transformations in any order with built in tunneling.
Contact JI at for more information.
Phil Karn:
KA9Q implementation for hosts and routers based on MS-DOS,
does encapsulation separately, will be distributable, uses keyed MD5,
DES, and 3DES (IDEA perhaps next). It talks to at least Morningstar and
NRL, and has manual key management. Photuris is planned for the future.
Contact Phil Karn for more information.
Mark Linehan:
IBM's Pau-Chen Cheng has an implementation that runs on AIX,
will be in a commercial firewall product. Mark indicated that they
will have an exportable version, and uses manual key distribution.
Pau-Chen has a copy of the implementation at the IETF so that
interoperability testing can occur this week. Contact Pau-Chen
for more information.
Steve Bellovin:
Two implementations were done last summer by David Wagner (UC
Berkeley) while he was at AT&T Bell Labs. The first implementation
runs on BSDI and uses keyed MD5 and DES. This AH is known to not
interoperate with other implementations.
The second implementation runs on MSDOS, uses keyed MD5 for AH,
looks like a packet driver, so it can work with many boards and IP
stacks. This has been tested with ftp Software and a paper on this
implementation will be presented at ISOC in February. Contact
Steve Bellovin for more information.
Hilarie Orman:
This implementation was done in the "x-kernel" research
operating system at the University of Arizona. It is a user process
in MACH, implements AH with keyed MD5, and implements ESP with DES CBC
and 3DES. It has ping and ftp clients. Tools for manual key
distribution exist. A Photuris implementation also exists. Will be
freely distributable with the x-kernel software. Contact Hilarie
Orman for more information.
Ashar Aziz:
Sun has implementations of ESP and AH with SKIP for SunOS
4.1.3 (kernel driver source), and Solaris 2.x (binaries only).
Contact Ashar Aziz at for more information.
Swiss Federal Institute of Technology:
Runs on Solaris 2.x, IRIS, and NetBSD, freely distributable,
implements AH and ESP with a fixed SPI (i.e. only works with SKIP key
distribution). Key distribution is manual or with SKIP.
Rob Glenn:
NIST and NSA have an implementation of ESP and AH with MD5 and
DES-CBC. It runs on BSDI, SunOS 4.1.x, FreeBSD, and NetBSD. They
brought a FreeBSD implementation for interoperability testing and are
working to make the implementation freely distributable within the US.
Their implementation can use ISAKMP and was designed to support multiple
security policies. Contact Rob Glenn for more
information.
Other:
Two other implementations were mentioned without much detail.
Jeff Kramer of Raptor has implemented some of IPsec. Antonio
Fernandez of Bellcore has an AH implementation. Interoperability
testing will occur in a hotel meeting room on Tuesday afternoon,
thanks to Tim Matthews who arranged for the room.
OPEN ISSUES:
Where do current RFCs need clarification?
The current RFCs will be cleaned up and reissued as Internet
Drafts before the next IETF. Then everyone should send comments (preferably
with replacement text) on confusing portions of the current specs so that
the specifications can be cleared up prior to moving to Draft Standard
RFC. We already meet the interoperability requirements to move to
Draft Standard.
Paul Lambert solicited implementor comments on AH/ESP RFCs and
also on the DES, MD5, 3DES, and SHA tranforms RFCs:
Bellovin and others asked which fields in the IPv4 header
should be zeroed. There was consensus that this is the biggest
problem with AH/ESP. Ran responded that the next version of the AH
spec will specifically enumerate which IPv4 options and header fields
are included in AH calculations and which are zeroed. A note to the
IPsec WG mailing list late last August enumerated these in more detail
than was present in the RFCs.
The options important to include in the Authentication Data
calculation are IPSO (RFC-1108)and CIPSO (no public specification
exists). JI suggested adding sequence numbers to AH. It is in the
Photuris extensions draft and would use the 16 bits of reserved AH
header. Bob Moscowitz brought up concerns about interactions with
firewalls. Perry Metzger brought up need for ways to use (fast)
stream ciphers (synchronization problem).
Bill Simpson asked for comments on the transform RFCs. The
main comment was that many implementers have been confused on how
to perform the MD5 padding. Hilarie Orman suggested including example
C source code in an informational Appendix to the MD5 transform draft
in order to make this more clear.
NEW TRANSFORMS:
Hugo from IBM discussed an alternate approach to Keyed MD5.
RFC 1828 specifies: MD5(K pad x K).
New nested mode: MD5(K padsub2 MD5(K padsub1 x))
|K| = 16 bytes
padsub1 = 0x36 repeated 48 times
padsub2 = 0x5C repeated 48 times
Hugo's Comparison:
- is still MD5 based (available, unrestricted, good performance)
- is replaceable (SHA, MD6, ...)
- no performance degradation
- short keys, simple setup
- MD5 unchanged
- better security:
* improved analysis
* weaker assumptions about hash function
* tighter security: MAC as secure as underlying hash function
* double key effect
He asserted that to break the new MD5 transform, either the
output of the MD5 compression is predictable or MD5 collisions can be
found even when the IV is secret and random. Both of these are
believed to be untrue for MD5.
The underlying construction considers MD5 with the IV set to
K. Only one K is needed but the pads have to be different. Also, for
added efficiency, implementations can compute the first block once and
use each time with a given key.
Much discussion followed. Perry Metzger, Bill Simpson,
Hilarie Orman, JI, Steve Bellovin, Ted Ts'o, Bob Moscowitz, Phil Karn,
and Jeff Schiller had comments on this. Simpson suggested using
Hugo's approach with SHA and not MD5. Hilarie asked where Hugo's
analysis could be obtained and noted the need for outside
cryptographic and mathematical review of Hugo's proposal.
WG Consensus seemed to be:
Put this new transform out as a Proposed Standard (Elective)
in its own RFC with a new transform identifier. Advertise that either
1828 or this new transform might become the required future transform
when we move to Draft Standard. In order to move the new transform
to Draft Standard, at least 2 independent interoperable implementations
must exist and be demonstrated interoperating.
OTHER TRANSFORMS:
Paul Lambert noted that there might be other transforms (e.g.
DES-CBC integrated with MD5 for use with ESP) needed. He solicited
volunteers to write up additional drafts. Only Bill Simpson and Perry
Metzger volunteered. Other volunteers are still solicited by the WG
chairs. Volunteers should write up their proposed transforms and put
them out as Internet Drafts (filenames of the form
draft-LASTNAME-TRANSFORM_NAME-*.txt should be used) and mention the
published I-Ds on the WG list.
IP Security WG, Session 2, 6 December 1995:
-------------------------------------------
This session was mostly focused on key management and related issues.
Paul Lambert showed the matrix of AH and ESP interoperability
testing. The grid was about half filled in. Ran observed that not
all combinations of implementations had been tested, so a blank space
was not necessarily indicative of non-interoperability. A number of
implementation bugs were found and fixed on Tuesday during the
information interoperability testing session. Two SKIP
implementations worked together. Two Photuris implementations worked
together. The group was pleasantly surprised at the rapid progress
towards interoperability and the unexpectedly large number of
independent implementations.
LIAISONS:
ANSI:
John Kennedy discussed ANSI X9F. There are two drafts:
X9.52 for Triple-DES (3DES) is near working draft status.
Contact Bill Latin +1 (408) 735-6679 or via email at
for more information on X9.F2.
X9.42 is on Diffie-Hellman (DH). Contact John Kennedy
at +1 (408) 735-5885 or via email to kennedy@cylink.com for more
information.
Also ANSI X9.55 is tracking the X.509 Public Key certificate
standards work; see Russ Housley or Warwick Ford for more information.
IEEE Microprocessor standards:
This group covers RSA, DH, and related techniques. Burt Kaliski
is the Chair. See ftp://ftp.rsa.com for more information.
Elliptic curve (EC) implementation of discrete log systems is
going to ballot within IEEE. The patent situation is different for EC
than DH. Other sections on RSA, DH, and random number generation. The
next meeting of this IEEE group is the two days before ISOC Security
Symposium that will be held during February in San Diego.
The usual comments about the need for no-cost on-line availability
of these non-IETF specifications followed.
PATENT ISSUES:
Paul Lambert noted that many of the technologies discussed
by the IPsec WG might be affected by patent claims. He then tried to
summarise all known patent claims that might be issues.
Ashar noted that the Sun patents relating to SKIP are
available for use at no cost. Patents claimed by NeXT are reportedly
under negotiation. Hugo noted that IBM issued an RFC on use of one of
their patents. UUNET has a US patent claim on all network encryption.
Novell has a claim on the use of Message Authentication Codes such as
Keyed MD5. Motorola has patent claims on certain compression techniques.
Paul solicited information on non-US patents, but no one had any
information on this. It was suggested that any other known patent
claims be mentioned on the IPsec mailing list.
For Cylink: see http://www.cylink.com or telephone Bob
Fougner at +1 (408) 735-5893.
For RSA, see http://www.rsa.com or telephone Paul
Livesay at +1 (415) 595-8782.
For UUNET, contact Rick Adams
ELLIPTICAL CURVE PRESENTATION:
Hilarie Orman presented an argument for using Elliptical
Curves instead of Modular Exponentiation with Public-key technology.
She showed a graph illustrating that to get more key bits, DH
compute time increases rapidly even using Karatsuba multiplication and
Montgomery reduction.
For DH modulus M, |M| = 512-2048 bits and exponent E,
|E| = 128-256 bits, compute time is |E| |M|^1.6.
Strength depends on:
minimum(E/2, 2.5M^(1/3), log(M)^((2/3)-15)).
Using |E| = 128, |M| = 512 really only yields 53 bits of equivalent
DES key strength. This estimate used an interpolation into an
asymptotic bound for the number field sieve based on the factoring of
a 119 digit number with that method.
ECs give equivalent strength with 155 bits over a field of
characteristic 2. More information on this subject is available at
http://www.cs.arizona.edu/xkernel/www/ipsec/ipsec.html.
Hugo questioned some of the conclusions that Hilarie drew.
The WG was very interested in Hilarie's presentation but no consensus
either way was obvious. The matter remains open for further study
and discussion.
ALTERNATIVE ENCRYPTION ALGORITHM:
John Kennedy presented Jim Massey's "Safer SK" algorithm.
This is a 64 bit block cipher with 40, 64, or 128 bit keys. It is
freely available and robust against differential and linear
cryptanalysis. He suggested that this might be of interest. It was
suggested that he document an ESP transform for this as an Internet
Draft so that the WG could discuss this proposal in more concrete
terms. It was also suggested that an Informational RFC documenting
the cryptographic algorithm would be helpful.
KEY MANAGMENT:
Paul then turned discussion towards the currently available
Internet Drafts on Key Management technology. There are 3 documents
online at present, namely Photuris, SKIP, and ISAKMP.
Photuris:
Phil Karn presented the changes to Photuris. Interchangeable
parts of the protocol may lead to weaknesses (exchange, key
generation, signature). Two implementations exist today that
interoperate: JI (University of Crete) and HO (University of Arizona).
Also work is underway or contemplated at NRL (on top of PF_KEY), and
by Simon Spero and Phil Karn. Phil expects a "bottom up" deployment
from AH and ESP to cases where a public key already exists, say in a
password file, and access control is being enforced.
Two questions were posed:
How to support multiple ESP transforms ?
How to support user-to-user keying ?
Phil Karn then solicited issues from the WG and came up with
the following list:
1. Are options for the station-to-station (STS) phase necessary ?
2. What is the public key certificate infrastructure ?
3. Security association attribute negotiation is needed.
4. Document is too long and hard to comprehend.
5. Session key from shared secret: use of dependent keys.
6. Should encryption for privacy in STS really be mandatory ?
7. Is there potential for convergence with SKIP ?
SKIP:
Ashar Aziz presented SKIP to the Working Group. Since Danvers
there have been several major changes such that the current draft is
not compatible with older SKIP implementations. Specifically,
- The SKIP header now only performs key management and ESP/AH
are used for IP authentication or encryption.
The new structure is:
[IP header][SKIP header][AH or ESP][upper-layer protocol]
- A public-key Certificate Discovery Protocol based on UDP
was developed in order to obtain long-term keys.
This allows multiple certificate types (PGP, X.509, etc.)
and can be run bilaterally or with a central server.
One effect of this change is that SKIP now has some state.
Ran Atkinson asked to move this protocol into a separate draft
from SKIP so that it could be used more generally rather than
only for SKIP. Ashar agreed to make this change. Phil
Zimmermann stated that this protocol will work with a new
release of PGP expected in January 1996.
- A "SKIP Algorithm Discovery Protocol" based on ICMP has
been added. This message is authenticated but is sent
in the clear. This addition also adds state into SKIP.
- Naming is now disassociated from source and destination
IP addressees: This helps support mobile hosts with dynamic
IP addresses better.
- A specification bug relating to IP multicasting was fixed.
Two "SKIP with ESP and DES-CBC and certificate discovery"
implementations interoperate. Raised hands from the audience indicate
that other implementations of this are being considered.
ISAKMP:
Mark Schertler presented the ISAKMP specification. Their goal
is to have a single key management protocol that is usable by ESP/AH
and also other protocols (e.g. SSL, PCT, RIP-II, 802.10 SDE, TLS,
OSPF). They seek independence from security policy, mechanism, and
algorithm. All approaches that have been proposed in the WG allow
protocol as well as crypto attacks. The focus of his work has been on
resolving the protocol attacks.
The main changes are:
1. User Negotiation protected by server established SA,
2. Situation (usage policy),
3. Authentication only mode,
4. Version number.
They brought a prototype demonstration on DTOS microkernel that was
shown afterwards in the hallway. This implementation could be moved
to BSD with little difficulty. They have the TIS version of DNS
Security (DNSsec) running on SunOS 4.1.3, and they can extract
certificates from Fortezza tokens and may use PGP certificates in the
future. The implementation is not copyrighted and available to US
citizens or government agencies. They are willing do interoperability
testing with independent implementations from outside the US.
Mark then commented on the other key management protocols:
SKIP works best with connectionless protocols and does
not support security association management.
Photuris is ESP and AH specific and not compatible
with security tokens (this was challenged by
Simpson and was deferred for further discussion).
WORKING GROUP SUMMARY:
Paul observed that SKIP is now in WG last call for Proposed
Standard (Elective). Jeff Schiller asked whether SKIP meets the WG
charter? What about perfect forward secrecy? At Ran's request, Jeff
then summarised the property of Perfect Forward Secrecy and why it is
important.
Jeff then described the IETF standards process.
Hugo asked whether perfect forward secrecy is still a consensus goal
for a mandatory standard? Ashar responded by explaining the limited
forward secrecy possible with SKIP. Karn stated that Perfect Forward
Secrecy should be at least available. Bob Moscowitz stated that Perfect
Forward Secrecy is sometimes necessary in a business environment.
Perry Metzger mentioned need to support multiple mechanisms.
WG CONSENSUS:
There was very clear working group consensus that Perfect
Forward Secrecy remains a requirement for any specification moving
forward as a mandatory-to-implement IETF standard. SKIP does not
claim to provide this property, while Photuris claims to provide it.
ISAKMP can support a session-key exchange that provides this property
but does not currently specify any session-key exchange algorithm.
From ipsec-request@ans.net Wed Dec 20 16:12:35 1995
Date: 20 Dec 95 13:06:35 -0800
From: PALAMBER.US.ORACLE.COM ("PALAMBER.US.ORACLE.COM" -PALAMBER@us.oracle.com-)
To: daw@cs.berkeley.edu, ipsec@ans.net ( daw@cs.berkeley.edu, ipsec@ans.net)
Subject: Re: ICMP Security Failures
X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:daw@cs.berkeley.edu's message of 20-Dec-95 03:27
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=Boundary-2422669-0-0
Xref: Re: ICMP Security Failures Bill Sommerfeld
Xref subject previous
Xref subject next
--Boundary-2422669-0-0
>Tunnelling is a very useful mode. It's most useful for routers,
>bump-in-the-stack encryptors, IP forwarding (e.g. IP
>``remailers''), and perhaps also firewalls...but I don't
>think the utility is limited to those situations.
>It's important that implementors realize they must support this mode
>of operation.
The intent has always been to mandate support in all implementations of both
"end-system" and "router-like" (a.k.a. firewalls, intermediate systems, etc.)
signaling. Several approaches are viable to support the necessary remapping
of addresses and the group has had a strong consensus on the use of the
"tunneling" (e.g. IP/ESP/IP) to provide this functionality.
Obviously minor tweaks in the next release of the specification could help
clarify these interoperability requirements.
Paul
PS - Implementations that allow multiple encapsulation (ESP/ESP/IP, or
ESP/ESP/ESP/IP, etc.) may not be exportable as a product from the US.
Exportable implementations may be required to block ESP over ESP :-(
--------------------------------------------------------------
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
--------------------------------------------------------------
--Boundary-2422669-0-0
Content-Type: message/rfc822
Date: 20 Dec 95 02:26:20
From:"David Wagner"
To: Phil,Karn,karn@qualcomm.com
Subject: Re: ICMP Security Failures
Cc: ipsec@ans.net
X-Sender: mpwagner@hiway1.exit109.com
X-Mailer: Windows Eudora Version 1.4.3
X-Orcl-Application: Mime-Version: 1.0
X-Orcl-Application: Content-Type: text/plain; charset="us-ascii"
>
>I'd like to expunge use of the terms "transport-mode" and
>"tunnel-mode" from IPSEC documents. Not because the modes they
>describe aren't useful, but because I really consider them completely
>orthogonal to the security mechanisms IPSEC provides.
>
Hrmm, I don't have any comments on the wisdom of this change, but...
Even if the words "transport-mode" and "tunnel-mode" are expunged,
I hope the documents will clearly explain this type of usage and its
importance somewhere.
Tunnelling is a very useful mode. It's most useful for routers,
bump-in-the-stack encryptors, IP forwarding (e.g. IP ``remailers''),
and perhaps also firewalls...but I don't think the utility is limited
to those situations.
It's important that implementors realize they must support this mode
of operation. The tunnel/transport modes aren't orthogonal, from
the implementation perspective: to support tunnel-mode, the IPSEC
modules must be re-entrant, and must deal with remembered security
state when processing IP headers. Implementors probably won't think
to support all this if it's not described explicitly in the spec.
--Boundary-2422669-0-0--
From ipsec-request@ans.net Wed Dec 20 16:34:29 1995
Date: 20 Dec 95 13:31:06 -0800
From: PALAMBER.US.ORACLE.COM ("PALAMBER.US.ORACLE.COM" -PALAMBER@us.oracle.com-)
To: ipsec@ans.net ( ipsec@ans.net)
Subject: Fwd: Proposed PAR for 802.10i
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=Boundary-2423781-0-0
--Boundary-2423781-0-0
The attached "PAR" is loosely related to ipsec issues for the support of
multicast. SAIDs/SPIs are normally locally unique (for a recipient). Some
approaches for multicast support may require additional restrictions to be
placed on SAIDs/SPIs.
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
--------------------------------------------------------------
--Boundary-2423781-0-0
Content-Type: message/rfc822
Date: 20 Dec 95 17:10:15
From:"Alonge Ken"
To: sils@mintaka.orion.ncsc.mil
Subject: Proposed PAR for 802.10i
X-Mailer: Mail*Link SMTP-MS 3.0.2
All-
Attached below is the proposed PAR for 802.10i that we came up with at our ad
hoc meeting yesterday. Please let me know ASAP if you have any problem with the
wording of the PAR. This refinement of the SAID field will also support the
VLAN folks needs. This PAR will have to be approved at our Salt Lake meeting,
so that it can be forwarded to the LMSC Exec for approval in March.
Ken
**************************************************
ATTACHED PAR
**************************************************
1. Date of Request: 14 March 1996
2. Assigned Project #: 802.10i
3. Does this PAR revise a previously approved PAR: No
4. Description of Proposed Document:
Revision of Standard IEEE Std 802.10-1992; Full Use
5. Project Title:
Revised Standard for Interoperable LAN Security (SILS) Part B - Secure Data
Exchange (802.10b)
6. Scope of Proposed Standard:
To refine the Security Association Identifier (SAID) field of the current
Standard to support Multicast Key Center identification. Neither the SDE PDU
format, nor the elements of procedure are changed by this refinement.
7. Prupose of Proposed Standard:
To allow independent Multicast Key Centers to assign unique SAIDs. The current
Standard requires a global MKC, or coordination among all MKCs to prevent re-use
of the same SAID.
Add Figure here.
8. Sponsor: LMSC
9. Name of group that will write the Standard:
IEEE 802.10 Working Group
10. Target Completion Date: November 1996
11. Proposed Coordination:
SCC10 (Dictionary) - Circulation of Drafts
X3S3 - Circulation of Drafts
IEEE 802.1 - Circulation of Drafts
12. Are you aware of any patent, copyright, or trademark issues? No
13. Copyright Agreement for IEEE Standards
I hereby acknowledge my appointment as Official Reporter to the IEEE 802.10
Committee to write/revise a Standards Publication (entitled or to be entitled)
Standard for Interoperable LAN Security (SILS) Part B - Secure Data Exchange
(IEEE 802.10b)
In consideration of my appointment and the publication of the
Standards Publication identifying me, at my option, as an Official
Reporter, I agree to avoid *knowingly* incorporating any
copyrighted or proprietary material of another without such
other's consent and acknowledge that the Standards Publication
shall constitute a "work made for hire" as defined by the
Copyright Act, and, that as to any work not so defined, I agree
and do hereby transfer any right or interest I may have in the
copyright to said Standards Publication to IEEE.
Name Kenneth G. Alonge _______________________
(signature of chair of working group)
Title Chair, IEEE Project 802.10 Working Group
Date March 14, 1996
14. Person delegated to receive communications and conduct liaison
with interested bodies:
(This is normally the chair of the working group. If not, please
indicated IEEE position.)
Name Kenneth G. Alonge Telephone 703-883-8603
Company PRC Inc M/S ????? Fax 708-556-3528
Address 1500 PRC Dr Telex
City McLean, Virginia Zip 22102
E Mail alonge_ken@po.gis.prc.com
15. Submitted By:
(This is normally the sponsor's liaison to the Standards Board.
If not, please indicate IEEE position and relationship to the
sponsor.)
Name Donald C. Loughry Telephone 408-447-2454
Company Hewlett-Packard Company Fax 408-447-2247
Address 19420 Holmstead Rd. M/S 43UC Telex
City Cupertino CA Zip 95014
E Mail loughry@cup.hp.com
Name D. C. Loughry ________________________
(signature of submitter)
Title Chair, LMSC
Date March 1996
--Boundary-2423781-0-0--