Internet DRAFT - draft-krywaniuk-ipsec-properties
draft-krywaniuk-ipsec-properties
Internet Engineering Task Force Andrew Krywaniuk
IP Security Working Group Alcatel
Internet Draft July 9, 2001
Security Properties of the IPsec Protocol Suite
<draft-krywaniuk-ipsec-properties-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPsec) Working Group. Comments are solicited and should be addressed
to the working group mailing list (ipsec@lists.tislabs.com) or to the
editor.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
This document is a product of the IETF's IPsec Working Group.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Krywaniuk Expires February 9, 2002 [Page 1]
Internet Draft IPsec Properties July 12, 2001
Abstract
This document describes the "security properties" of the IPsec
architecture and protocols, including ESP, AH, and IKE.
By documenting these properties, we aim to provide a guide for users
who wish to understand the abilities and limitations of the IPsec
protocol suite. We also hope to provide motivation for future work in
this area.
IPsec Working Group [Page 2]
Internet Draft IPsec Properties July 12, 2001
Table of Contents
1. Introduction.................................................4
2. Specification of Requirements................................4
3. General Approach.............................................4
3.1 Terminology...................................................5
4. Confidentiality..............................................5
4.1 Encryption Coverage...........................................5
4.2 Traffic Flow..................................................6
4.3 Cryptographic Mumbo-Jumbo.....................................6
4.4 Identity Protection...........................................7
5. Authentication...............................................8
5.1 Authentication Coverage.......................................8
5.2 Cryptographic Mumbo-Jumbo.....................................8
5.3 Host Authentication...........................................9
5.4 User Authentication...........................................9
6. Key Generation...............................................9
6.1 Rekeying.....................................................10
6.2 Independence of Keying Material..............................10
6.3 Cryptographic Mumbo-Jumbo....................................10
6.4 Perfect Forward Secrecy......................................11
6.5 Weak Keys....................................................11
6.6 Ad Hoc Groups................................................12
6.7 Key Strength.................................................12
7. Denial of Service...........................................13
7.1 ESP Packet Spoofing..........................................13
7.2 Memory Consumption...........................................13
7.3 Time Consumption.............................................13
7.4 Synchronization..............................................14
8. Miscellaneous...............................................14
8.1 Replay.......................................................14
9. IANA Considerations.........................................15
10. Security Considerations.....................................15
11. References..................................................15
IPsec Working Group [Page 3]
Internet Draft IPsec Properties July 12, 2001
1. Introduction
Before you can know where you are going, you must first know where
you have been.
An analysis of IPsec by Counterpane researchers [Counterpane]
complained that IPsec has a lack of clearly expressed design goals,
and shows evidence of design by committee. We concur with these
observations, in the sense that some features appear incomplete or
are not used for the purpose for which they were intended. Part of
the confusion comes from the fact that [ISAKMP] defines a large set
of features; [IKE] only uses a subset of these features, but it does
not clearly state which ones.
The IPsec working group has undertaken a project to redesign the IKE
protocol in order to "simplify" it; there has also been talk of
reducing the number of IPsec usage permutations by deprecating AH
and/or tunnel mode. We believe that it is inappropriate to redesign a
protocol until the existing protocol is well understood.
Perhaps IPsec is well understood by some, but frequent questions on
the developers' mailing list confirm that one cannot become an IPsec
expert merely by reading the RFCs. Much valuable information is
buried deep in the list archives or in the minds of its designers.
Other protocol designers depend on IPsec for transport security; if
they cannot clearly understand what security properties IPsec
provides, they may use it incorrectly. The same could be said for
IPsec users.
2. Specification of Requirements
This document shall use the keywords "MUST", "MUST NOT",
"REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They
are to be interpreted as described in [Bradner].
3. General Approach
This document is not an introduction to IPsec, nor is it cryptography
101. It is merely a description of the security properties associated
with one particular security protocol, IPsec.
Our intention is merely to document what exists today. In the few
places where we discuss alternatives, they relate specifically to
IPsec Working Group [Page 4]
Internet Draft IPsec Properties July 12, 2001
known issues concerning the security properties of IPsec.
Some of this information in this memo is already available in the
RFCs, some is not; this document collects it all into one place.
Sometimes the RFCs are ambiguous, for example in the case where a
feature is described in ISAKMP, but not used in IKE; here, we attempt
to resolve that ambiguity.
The amount of space devoted to a particular property does not
necessarily reflect on the importance of that property in the context
of IPsec. For example, identity protection is discussed in some
detail, even though its applicability is limited, precisely because
the issues are complicated.
3.1 Terminology
For the purposes of this document, "the IPsec protocol suite" shall
consist of RFCs 2401 through 2412, plus any other documents which we
consider relevant. We assume the use of ESP and/or AH SAs, negotiated
by IKE, and used according to the rules prescribed by [ARCH]. We do
not cover specialized applications, such as multicast and alternate
key exchange protocols.
The "security properties" we discuss include properties such as
confidentiality, authentication, and resistance to DoS. We only
attempt to define properties that can be measured objectively. As
such, we do not discuss such issues as technical merit, ease of use,
or level of complexity. The document focuses more on IKE than on
ESP/AH, since IKE appears to have more intricate security properties.
4. Confidentiality
Traffic confidentiality is one of the main reasons for using IPsec.
For better or for worse, IPsec provides two completely independent
implementations of encryption: one in IKE and one in ESP.
Obviously, in a network scenario not all data can be encrypted.
Otherwise, it would be impossible to create SAs and route traffic.
What data is encrypted and what data is not is a matter of some
interest.
4.1 Encryption Coverage
ESP encryption covers protocol layers 4 and above (and, potentially,
some of the so-called layer 3.5 protocols). The IP header and any
IPsec Working Group [Page 5]
Internet Draft IPsec Properties July 12, 2001
additional lower-level headers are sent in the clear. If tunnel mode
is used, the data in the inner header can be concealed, but some of
that information will be copied into the outer header anyway, since
it is needed for routing.
In IKE, a large portion of the data must be sent in the clear, simply
to bootstrap the negotiation. For example, an attacker can see which
transforms are being used in IKE. Modern cryptological thinking
postulates that revealing this kind of data is not a security
weakness. Once the key exchange is complete, subsequent IKE data is
encrypted.
4.2 Traffic Flow
ESP hides such information as the layer 4 port and protocol, however
some information about the traffic flow is leaked due to packet
sizes. ESP allows an implementation to add padding to packets in
order to conceal packet lengths; this is constrained to a maximum of
255 bytes.
In tunnel mode, when an edge device is applying the encryption, a
snooper is generally unable to determine which end nodes the router
is proxying for.
4.3 Cryptographic Mumbo-Jumbo
Encryption in ESP and ISAKMP is typically deployed using the CBC
(Cipher Block Chaining) mode of operation. CBC uses the previous
block as an IV to the next block, which ensures that the IV is always
random. A random IV makes it next to impossible that two blocks of
ciphertext will be the same.
CBC does not have the infinite error propagation property, which
means that it is vulnerable to known-plaintext attacks. This is not
to say that IPsec is vulnerable to known-plaintext attacks; all it
means is that the chosen cipher must itself be secure against these
attacks.
Other modes of operation could be used and they would have different
security properties. Encryption should not be used as a substitute
for authentication. With block ciphers, an attacker is generally
prevented from making a predictable change to the plaintext. This is
not necessarily true for other types of ciphers, such as stream
ciphers.
IPsec Working Group [Page 6]
Internet Draft IPsec Properties July 12, 2001
4.4 Identity Protection
IKE main mode purports to deliver a feature called identity
protection, which means that the identities are not sent in the
clear. However, in order to complete the authentication, one side
must reveal its identity first. In main mode with public key
signatures, the initiator reveals his identity first; therefore, an
active attacker who impersonates the responder can determine the
initiatorĘs identity.
Even when the identity is protected, a host may need to send a
"certificate request" in order to force the sender to include a
certificate in a later message. The certificate request payload
typically contains the name of the CA to be used, which reveals some
limited information about the sender's identity to a passive snooper.
This limited form of identity protection can only be used with public
key signature authentication. Due to the particular construction of
SKEYID_e in the case of preshared keys, the identity must be sent in
the clear in order to generate the encryption key. In the case of
public key encryption, the initiator's identity is protected but the
responder's identity must be assumed in order to choose the correct
public key. (IKE specifies that a hash of the certificate may be sent
in order to identify the certificate, but this hash is an identity-
equivalent, in the sense that it uniquely correlates to an identity.)
In many cases, the IP address of the host implicitly describes the
identity (e.g. the identity can be found by a DNS lookup); in these
cases, identity protection is moot. Since the initiatorĘs identity is
less likely to be implicit from an IP address than the responderĘs
is, itĘs a shame that signature-based authentication provides higher
protection to the responderĘs id. However, if the host is a gateway
that is proxying for multiple end nodes, at least the identity of the
end host is protected by tunnel mode encapsulation.
In the case where the identity is sent in the clear, it could be a
random binary string; IKE allows the transmission of unformatted
identities using the ID_KEY_ID type. However, it would be desirable
that the obfuscated identity not be an identity-equivalent, so that
multiple logins by the same user could not be correlated. IKE does
not provide this feature.
IKE also provides a feature called Identity PFS, in which every quick
mode exchange uses a new phase 1 SA. [IKE] doesnĘt specify why one
might want to do this, but it does theoretically allow the host to
delete the identity of the peer from memory, thus ensuring that it is
not revealed even if the physical security of the box is compromised.
IPsec Working Group [Page 7]
Internet Draft IPsec Properties July 12, 2001
(Although it may be difficult to apply policy rules if the identity
of the peer is not remembered.)
5. Authentication
Traffic encryption is not much use if the user at the other end is
unknown or if the data could be forged. IPsec provides several types
of authentication: packet authentication, exchange authentication,
and host authentication.
5.1 Authentication Coverage
Each AH packet contains an HMAC; likewise for ESP, assuming that ESP
authentication is being used. ESP authentication covers the entire
payload of the IP packet. AH also covers the non-mutable fields in
the header.
When tunnel mode is being used, AH has the same effective coverage as
ESP, because the outer header is merely a transient routing header.
If AH is being used to ensure that the header of the IP packet
remains uncorrupted during transit, this is really only useful if any
of the intermediate routers which interpret the header are also privy
to the AH key.
The IKE phase 1 hash covers sufficient material to bind the identity
of the peer to unforgeable session data, such as the DH secret.
However, phase 1 does not have full authentication coverage (a
shortcoming which will most likely be fixed in a future version of
the protocol). Consequently, optional payloads, such as notify
messages and vendor ids, are not authenticated by the exchange. Even
if these payloads are part of an encrypted message, an attacker can
still corrupt them without being detected.
Phase 2 messages are fully authenticated by an HMAC, with the
exception of the ISAKMP header. Modifying the commit bit (in the
header) is a potential DoS vulnerability.
5.2 Cryptographic Mumbo-Jumbo
The HMAC that is used for packet authentication is truncated. This
limits the amount of information an attacker can gather by analyzing
the output.
The HMAC functions that are used in IKE are also used as PRFs.
Therefore, the output of the HMAC should always appear statistically
IPsec Working Group [Page 8]
Internet Draft IPsec Properties July 12, 2001
random.
5.3 Host Authentication
The host is authenticated in IKE phase 1 by the generation of a
public key signature, an HMAC signature, or by a proof of possession
of a decryption key. The obvious man in the middle attack is thwarted
by including the Diffie-Hellman public keys in the HASH_I/HASH_R
values which are generated, signed, or encrypted.
Authentication using public key signatures provides the non-
repudiation property, which means that one party could potentially
prove (possibly in a court of law) that a phase 1 negotiation between
the two parties took place. However, this does not prove to a third
party that any data sent with the negotiated keys is genuine. The
other authentication methods do not have this property.
When authenticating with preshared keys, the strength of the
authentication is based on the effective entropy of the secret. When
authenticating with public key encryption, the strength of the
authentication is based on the length of the public key. Likewise for
public key signatures, but as an additional wrinkle the strength of
the MAC algorithm is also important. Since all the inputs to the MAC
are sent on the wire except possibly the IDs (which can be guessed),
the strength of the PK signature is limited by the difficulty of
finding a collision in the MAC function.
5.4 User Authentication
While IKE provides a number of ways to identify the peer, this
identity is not communicated up to the application level. This means
that all traffic-level authorization must ultimately be applied to
IPs and ports.
The application layer will typically have to perform its own
authentication stage since there is no well-defined interface to
extract the authenticated id from the IKE process. The upside of this
limitation is that a simple username/password protocol is obviously
more secure when it is sent across an ESP tunnel than when it is
performed in the clear.
6. Key Generation
Key generation is the most important function of the quick mode
exchange. Key generation is also part of phase 1, since ISAKMP needs
IPsec Working Group [Page 9]
Internet Draft IPsec Properties July 12, 2001
its own session keys.
The properties of key generation are more complicated and harder to
explain than most other security properties. Nonetheless, we will
make an attempt.
6.1 Rekeying
One purpose of rekeying is to thwart cryptanalysis by limiting the
amount of ciphertext that an attacker can examine, but the main
purpose is simply to limit the consequences of a compromised key.
[IKE] defines two different types of lifetimes, time-based and
traffic-based. Time-based lifetimes protect against the possibility
that a key will be compromised by brute force; traffic-based
lifetimes guard against attacks based on gathering ciphertext.
[IKE] also proposes a third lifetime for phase 1 SAs, based on the
number of quick modes used with this SA. The justification given for
this lifetime is suspect because a PRF can provide keying material
for a large number of random keys, and these keys are not revealed to
an attacker for analysis. Nonetheless, this lifetime makes sense
because it correlates strongly with the volume of IPsec traffic.
6.2 Independence of Keying Material
The keys negotiated by IKE are derived from the Diffie-Hellman
secret, some random session data, and possibly a preshared key. This
information is run through a pseudo-random function in order to
generate a key.
The keys generated by IKE are never derived directly from each other,
nor are they reused for multiple purposes. Each encryption or
authentication key is created by an HMAC-based PRF, which is keyed by
a shared primitive key that is never revealed.
The PRF used in IKE must be a strong one-way function. This means
that even if one key is compromised, other keys created from the same
DH secret cannot be cracked unless the PRF is reversed.
6.3 Cryptographic Mumbo-Jumbo
All the components of the key material, including the DH secret are
HMAC'ed before they are used. This ensures that any analytical attack
IPsec Working Group [Page 10]
Internet Draft IPsec Properties July 12, 2001
on the key exchange function will not directly translate into an
analytical attack on the key generation function.
Wherever possible, the SKEYID is derived from a secret value other
than g^xy (this is not possible in the case of public key
signatures). In the case where keys are generated from each other
(e.g. SKEYID_d -> SKEYID_a -> SKEYID_e), g^xy is reintroduced at
every stage so that the key is always directly based on a shared
primitive.
A more detailed description of the motivation for SKEYID construction
is given in [Krawczyk].
6.4 Perfect Forward Secrecy
IKE also provides a mode called perfect forward secrecy, in which a
separate DH secret is generated during each quick mode exchange. The
term PFS is a bit misleading, since "forward secrecy" generally
refers to the property that compromise of the long-term credential
does not reveal the session keys; IKE phase 1 already provides
forward secrecy because the key is based on a DH secret.
Why might one want to use PFS?
a) If you donĘt fully trust the one-way property of the PRF.
b) In order to limit the consequences if the box is physically
compromised.
The point of item (b) above is that PFS does not significantly
increase the security of IKE against long-term cryptanalysis. An
attacker who can crack the phase 1 DH exchange can presumably crack a
second DH exchange with equivalent work.
PFS provides additional security, but the work factor is linear.
Alternate countermeasures, such as simply increasing the modulus of
the DH group from phase 1, would provide better than linear security.
What PFS does provide is a faster (but less secure) alternative to
phase 1 rekeying.
6.5 Weak Keys
IKE mandates the use of weak key checks. In practice, weak keys are
very unlikely to be generated randomly, and an attacker wonĘt be able
to detect them if they are used.
IPsec Working Group [Page 11]
Internet Draft IPsec Properties July 12, 2001
6.6 Ad Hoc Groups
IKE allows the negotiation of ad hoc groups, either during phase 1,
or after phase 1 using new group mode. To use new group mode, an
implementation would have to trust the phase 1 group enough to use it
in the short term, but not trust it for long term security.
According to [IKE], implementations are meant to verify the primality
of a proposed group before using it. The implications of this
statement are interesting. Presumably, this is to detect
implementation errors in the peer, rather than malfeasance.
Otherwise, it would also be pertinent to send an attribute describing
the algorithm by which the group was chosen (e.g. a seed, which is
hashed, and then used as the starting point in a search for a prime).
6.7 Key Strength
All keys in IKE are derived from a PRF output. A PRF provides a
theoretically completely random key. Assuming that the cipher
algorithm is strong against analysis, the most significant attack is
brute force. Therefore, the strength of a key is approximately
proportional to the key length.
But the length of a key is not the only factor in determining its
strength. The length of the encryption key must be large enough to
thwart a direct attack, but the length of the DH secret used to
generate the key is also important, as described in [Orman].
[Beaulieu] notes that a third factor comes into play if one attempts
to derive a large encryption key from a small hash output. As
described in [IKE], the key material for an ISAKMP SA may be
"stretched" using the following algorithm:
Ka = K1 | K2 | K3
and
K1 = prf(SKEYID_e, 0)
K2 = prf(SKEYID_e, K1)
K3 = prf(SKEYID_e, K2)
This definition does not fully utilize the entropy of the DH secret
and further constrains the strength of the key to the length of the
HMAC output. A similar limitation applies to the keys generated by
quick mode when PFS is not being used.
IPsec Working Group [Page 12]
Internet Draft IPsec Properties July 12, 2001
7. Denial of Service
IPsec provides some protection against denial of service attacks but
also creates some new holes.
7.1 ESP Packet Spoofing
IPsec ESP/AH authentication provides strong protection against DoS
because any spoofed packets will be identified and discarded. The
time lost to DoS is limited to the length of time required to verify
an HMAC. ESP without authentication has less DoS protection because
spoofed packets will pass IPsec processing.
The fact that SPIs are random, and therefore unknown to an
unprivileged attacker, provides additional protection against
spoofing. If an authenticated user sends encrypted packets which
cause DoS, the source of the attack will be obvious.
However, packets that are sent in the clear can still cause DoS.
Obviously, some packets, most notably the first few packets of IKE,
must still be sent in the clear.
7.2 Memory Consumption
ISAKMP reuses the stateless cookie idea from Photuris, but IKE does
not provide a mode in which they can be used. This is odd because the
elaborate construction of the phase 1 authentication hash is quite
clearly intended to facilitate stateless operation. (Anti-clogging
cookies are meant to prevent state clogging attacks akin to the TCP
SYN attack.)
[Huttunen] describes a proposal for enabling stateless operation
(without lengthening main mode) by requiring the initiator to include
an encrypted "state payload" which the responder generates in the
third message of phase 1.
7.3 Time Consumption
The key exchange and public key authentication operations of IKE
phase 1 provide the greatest vehicle for DoS. An attacker can
generate a fake key exchange or signature payload, forcing the
responder to perform a time-consuming modular exponentiation
operation (without significant work by the attacker).
IPsec Working Group [Page 13]
Internet Draft IPsec Properties July 12, 2001
IKE provides some protection against this attack in main mode by
requiring an initial cookie exchange. Even though the cookie cannot
be used for stateless operation, it performs a similar function as a
nonce, proving the liveness of the initiator.
Aggressive Mode is vulnerable because the signature must be generated
before the cookie exchange is complete. The DH exponentiation can be
delayed until the third packet is received, but at the cost of
latency. Quick mode with PFS has a similar vulnerability if the
exchange is replayed; again, the attack can be avoided (at the cost
of latency) by delaying the computation.
IKE does not provide protection against DDoS zombies. Countermeasures
such as client puzzles exist, but there is no mechanism for using
them with IKE.
7.4 Synchronization
The lack of full authentication coverage in some IKE messages can
allow an active attacker to exploit synchronization issues. For
example, he can set the commit bit in the ISAKMP header, causing one
side to wait for a CONNECTED notification that may never come.
Alternately, he could add a vendor id to an IKE phase 1 message that
would cause one side to enable a non-standard behaviour. Since the
vendor id is not authenticated, this could cause one host to behave
in a non-interoperable manner.
An attacker can potentially prevent the delivery of delete
notifications or forge invalid SPI/cookie messages, which could cause
one side to delete an SA or to believe that an SA has been deleted by
the peer. By forcing a connection to be repeatedly torn down, the
attacker can cause a host to waste CPU in frequent renegotiations, to
deny service to a legitimate user, or to waste memory maintaining an
SA after the peer has disconnected.
8. Miscellaneous
There are a few additional security properties that do not fall into
the above categories.
8.1 Replay
Replay of ESP data is a vulnerability that depends on the upper layer
protocol. Many session-based protocols will reject replayed data. ESP
IPsec Working Group [Page 14]
Internet Draft IPsec Properties July 12, 2001
and AH packets contain an anti-replay counter which may optionally be
checked. This counter is not time-based, so it does not prevent an
attacker from intercepting all packets, storing them, and then
selectively delivering them at a future time. Replay protection can
only be used in conjunction with packet authentication.
ISAKMP does not provide explicit replay protection. Replay protection
is accomplished in some exchanges (main mode, aggressive mode, quick
mode) by sending a random value (e.g. a nonce) to the peer and having
them return that value in a subsequent message. This technique is not
possible with 1 or 2 message exchanges (new group mode, info mode).
Also, replaying a quick mode exchange with PFS can cause DoS, as
noted in section 7.3.
It has been suggested that an implementation needs to remember all
message ids it receives in order to avoid replayed messages; we
believe that a better general-purpose solution is to add a message
counter to ISAKMP SAs as described in [REPLAY].
9. IANA Considerations
This document does not require any assigned numbers.
10. Security Considerations
The focus of this document is security; hence security considerations
permeate this specification.
11. References
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[Beaulieu] Beaulieu, S., "Generating 3DES keys from SKEYID_e",
http://www.vpnc.org/ietf-ipsec/00.ipsec/msg01288.html, July
2001.
[Bradner] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Counterpane] Ferguson, Niels, and Schneier, Bruce, "A Cryptographic
Evaluation of IPSec", http://www.counterpane.com, April 1999.
[Huttunen] Huttunen, A., "Re: Future ISAKMP Denial of Service
Vulnerablity Needs Addressing", http://www.vpnc.org/ietf-
IPsec Working Group [Page 15]
Internet Draft IPsec Properties July 12, 2001
ipsec/00.ipsec/msg00160.html, January 2000.
[ISAKMP]Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998
[Krawczyk] Krawczyk, H., "Rationale for the definitions of SKEYID",
http://www.vpnc.org/ietf-ipsec/mail-archive/msg00844.html,
June 2001.
[Orman] Orman, H., Hoffman, P., "Determining Strengths for Public
Keys Used For Exchanging Symmetric Keys", draft-orman-public-
key-lengths-02.txt, March 19, 2001 (work in progress)
[REPLAY]Krywaniuk, A., "Using Isakmp Message Ids for Replay
Protection", draft-krywaniuk-ipsec-antireplay-00.txt, July 9,
2001 (work in progress)
Authors' Addresses
Andrew Krywaniuk
Alcatel Networks Corporation
600 March Road
Kanata, ON
Canada, K2K 2E6
+1 (613) 784-4237
E-mail: andrew.krywaniuk@alcatel.com
The IPsec working group can be contacted via the IPsec working
group's mailing list (ipsec@lists.tislabs.com) or through its chairs:
Theodore Y. Ts'o
tytso@MIT.EDU
Massachusetts Institute of Technology
Barbara Fraser
byfraser@cisco.com
Cisco Systems
IPsec Working Group [Page 16]
Internet Draft IPsec Properties July 12, 2001
Expiration
This document expires February 9th, 2002.
IPsec Working Group [Page 17]