[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Security AD Statement on IPSEC Key Management
-----BEGIN PGP SIGNED MESSAGE-----
Introduction
Standardized security technology is urgently needed on the Internet
today. The IPSEC Working Group has been working to provide solutions
applicable to the IP Layer of the protocol stack. Over a year ago,
consensus was reached on the packet formats necessary to provide data
authentication, integrity and confidentiality. However the mechanism to
exchange required cryptographic material was not yet ready for
standardization.
Since then the IPSEC Working Group has been struggling with several
competing key management proposals. To have competing proposals within
an IETF working group is neither new nor novel. However the time comes
when either the proponents of the various proposals come to consensus
(along with the rest of the working group) or a decision among them
has to be made. That time is now.
In Montreal (at the June IETF meeting) I saw several factions at work
in the IPSEC working group. There were people supporting each of the
proposed key management solutions and a larger number of people who
were looking for a single solution to emerge, but who themselves were
not in a position to have a technical opinion one way or the other. But
one thing was clear, they wanted a solution and they wanted it then.
Shortly after the meeting I was approached by several people offering
to have a "design team" meeting with the principals behind the various
proposals. The goal of the team was to come up with a compromise that
all could live with. I considered this very good news, but I was also
cautious. The last thing I wanted was to have a working group meeting
at the December 1996 IETF and still be where we were in Montreal,
namely without a solution! To this end I established a time limit. The
charge to the design team was to come up with a compromise solution
(or enough progress on a compromise) by September 1. After September
1, if the working group could not decide upon a course of action, then
I would step in as Security Area Director and propose one myself.
As those of you on the IPSEC list already know, the design team failed
in their effort to come up with a compromise. I am both saddened and
disappointed by this outcome.
The purpose of this document is to end the controversy and establish
a productive direction for future work.
History
To understand the situation requires a bit of history and explanation.
Although most Internet problems can be solved by a single protocol, this
doesn't always have to be the case. For example, we have TCP and UDP
which both provide a transport service, but with very different
characteristics to address different problem domains. Similarly we have
both the RIP and OSPF routing protocols. Each protocol has features
different from the other, and each has its appropriate domain of
applicability.
Why is IPSEC different? To understand this we have to go back to the
original decision reached by the IETF in the IPv6 selection process.
Specifically the IETF decided that security, namely IPSEC, was a
mandatory requirement for a compliant implementation of IPv6. This was
decided upon because the community felt that without such a mandatory
feature, security would not be implemented in a lot of products, even
though there is a pressing need for security on the Internet. The
reasons for this belief are many and varied and beyond the scope of this
document. Suffice it to say that IPSEC technology is mandatory in IPv6.
The mandatory nature of IPSEC means that for its various protocols,
several variants may exist, but one of each class of protocol will
need to be designated as mandatory to provide guidance to vendors
wishing to build IPv6 compliant versions of products.
The mandatory to implement protocols may not necessarily be the ideal
solution for any particular problem. Instead they are selected to
provide two basic requirements:
o Strong Security
o Interoperability
The goal is for two compliant implementations of IPSEC to be able to
communicate securely because they, at a minimum, have the mandatory to
implement protocols common between them. They may have other protocols,
such as other Authentication Header (AH) and Encapsulated Security
Protocol (ESP) transforms, in common which they may negotiate the use of
instead of the mandatory protocols.
The mandatory transforms may not always be the ideal approach for a
particular network application. For example, the mandatory ESP
transform involves the use of the U.S. Data Encryption Standard
(DES). This encryption algorithm is widely regarded as being secure
enough for most applications. It is also commonly recognized that DES
is a slow algorithm and applications requiring high speed data
transfer (in the absence of high speed DES hardware) may elect to use
a faster cipher such as the International Data Encryption Algorithm
(IDEA) or RSA Data Security's RC2 or RC4 ciphers.
Analysis
Keeping in mind that the primary goal of the mandatory protocols is to
provide strong security and interoperability, I have read and evaluated
the approaches in the two main contenders for the IPSEC key management
mandatory standard, SKIP and ISAKMP/Oakley.
ISAKMP/Oakley
ISAKMP defines a Security Association management protocol for
establishing security contexts and keys between a pair of hosts on the
Internet. By itself it does not define a key management function. Oakley
provides a key management function which can operate within the ISAKMP
protocol. The combination provides for complete security association and
cryptographic key material management.
Oakley itself provides several protocol variations which trade-off
between protocol overhead (the number of messages sent between
communicating hosts) and services provided (such as identity
confidentiality).
ISAKMP/Oakley imposes a cost of several packet exchanges between host
pairs before secure communication can take place. There is no per-packet
overhead to use ISAKMP/Oakley (other then the AH and ESP header overhead
itself) once associations are in place. For a set of hosts which
communicate with each other on a frequent basis, it is expected that
associations will remain in place and the overhead of setting new ones
up will not be a significant factor.
The primary disadvantage of the ISAKMP/Oakley approach is that it
imposes significant overhead in the case where hosts communicate
infrequently as it is likely that associations will not exist when
needed and will have to be setup.
If either party to a security association looses or changes state, so
that existing associations are no longer operative, then a new set of
security associations can be established. Messages, protected by the new
associations, can communicate the demise of the failed associations.
SKIP
The SKIP proposal is based on in-line keying. Each packet is encrypted
in a key which is provided in the packet itself, encrypted in a key that
is setup between the communicating host pair. SKIP's advantage is that
the protocol for setting up inter-host keys is fairly lightweight. If
both hosts already have the other hosts public key certificate, no
packet exchanges are required as the arriving data packet will contain
sufficient information for the receiving host to compute the shared key
and respond accordingly.
Computing the shared key requires significant computation
(exponentiation). However a communicating host pair can choose to cache
their shared keys to avoid this computational overhead. There is a
trade-off between computation of shared keys and secure storage to hold
already computed keys.
In SKIP if a received packet cannot be decrypted, there is little
fallback available as SKIP does not naturally support multiple security
associations. Put another way, the lightweight key management does not
have a heavyweight fallback in the event that key management fails for
any reason. The result is that messages must be sent without security
enhancements to indicate the failure. However such messages will be
indistinguishable from forged messages originated by an attacker for the
purpose of disrupting communication.
The implication of the lightweight approach of SKIP is that no
significant negotiation of algorithms, certificates and other options
are possible. The assumption is that certain parameters, such as the
Diffie Hellman prime and generator will be constant among members of a
community of hosts using SKIP. Among a small community of hosts, e.g.,
within an autonomous system (AS), such parameters need not be negotiated
in real-time, but rather can be configured in advance in the hosts. If
at some future point they need to be changed, the amount of management
overhead necessary is bounded by the size of the AS.
SKIP will also likely be faster at recovery from normal system failure
(reboot) when a host communicates with a significant number of peers. In
this situation the lightweight approach provides for faster
re-establishment of secure communication.
Note: Some features of SKIP, including Certificate Discovery and
Algorithm Discovery improve its ability to cope with some classes of
failures. However this additional mechanism comes at the cost of
additional packet exchanges and protocol complexity. It is my opinion
that SKIP could be further modified to deal with these issues as well as
ISAKMP/Oakley does. However I believe such a modified protocol will be
as complicated if not more so then the ISAKMP/Oakley protocol
combination.
Conclusion
I had hoped that the design team would have recognized that each of the
two proposals above have domains where they are particularly well
suited. It is conceivable to this author that a merged mechanism could
exist that provides the benefits of SKIP within an AS (or similar
community) and ISAKMP/Oakley when more protocol negotiation is required.
A simple (from my point of view) solution would be to require both SKIP
and ISAKMP/Oakley be implemented in a compliant IPv6 protocol stack.
However it is clear to me that there is significant overlap of
functionality between these two protocols and without a compromise
(presumably a compromise protocol would result in a lot of shared
mechanism and code in implementations) implementors would have to write
a lot of excess code.
Therefore we have to pick one approach as the mandatory solution. This
does not mean that the other approach cannot become an ELECTIVE Internet
Standard.
Going back to my original view of the goal behind the "mandatory"
approach leads me to conclude that if we must pick between ISAKMP/Oakley
and SKIP, then ISAKMP/Oakley should be the mandatory standard. My
rationale is simple. It is my belief that given an arbitrarily chosen
pair of hosts, it is likelier that an ISAKMP/Oakley approach will result
in a working security association than SKIP. Furthermore going back to
the original working group charter, the ISAKMP/Oakley approach more
closely follows the goals established in the charter to the IKMP portion
of the IPSEC work.
I would like to see the IPSEC working group create three sets of RFCs.
o A Set of RFCs which fully define the ISAKMP/Oakley approach. These
RFCs will follow the normal IETF standards track ultimately resulting in
a protocol that is ELECTIVE for IPv4 and is MANDATORY for IPv6.
o A Set of RFCs which fully define the SKIP approach. These RFCs will
follow the normal IETF standards tack ultimately resulting in a protocol
that is ELECTIVE for IPv4 and is ELECTIVE for IPv6.
o One or more RFCs that describe the application domain for
ISAKMP/Oakley and SKIP.
Although I believe that ISAKMP/Oakley should become the IPv6 Mandatory
protocol, I also believe that there exist significant domains of
application where the SKIP approach makes more sense. I would like the
working group to address this.
Recommendation
I formally recommend, as Security Area Director, that the charter for
the IPSEC working group be amended to charge the working group with the
tasks above. The arguments between the ISAKMP/Oakley and SKIP factions
should no longer be considered appropriate discussion for the working
group, either at its in person meetings or on the working group mailing
list. If some people would like to continue that line of discussion they
are welcome to form a separate mailing list, not part of the IETF.
Proposed New Charter (with change bars)
IP Security Protocol (ipsec) Charter
Chair(s)
* Ran Atkinson <rja@cisco.com>
* Paul Lambert <palamber@us.oracle.com>
Security Area Director(s):
* Jeffrey Schiller <jis@mit.edu>
Mailing List Information
* General Discussion:ipsec@tis.com
* To Subscribe: ipsec-request@tis.com
* Archive: ftp://ftp.tis.com/pub/lists/ipsec
Description of Working Group
Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support
combinations of authentication, integrity, access control, and
confidentiality.
The protocol formats for the IP Authentication Header (AH) and IP
Encapsulating Security Payload (ESP) will be independent of the
cryptographic algorithm. The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and
host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed to
support the key management requirements of the network layer
security. The Internet Key Management Protocol (IKMP) will be
specified as an application layer protocol that is independent of the
| lower layer security protocol. The protocol will be based on the
| ISAKMP/Oakley work begun in:
|
| <draft-ietf-ipsec-isakmp-05.txt>,
| <draft-ietf-ipsec-oakley-01.txt> and
| <draft-ietf-ipsec-isakmp-oakley-00.txt>.
|
| A follow on work item may incorporate mechanisms based on SKIP as
| defined in:
|
| <draft-ietf-ipsec-skip-07.txt>
|
| and related documents. Flexibility in the protocol will allow
| eventual support of Key Distribution Centers (KDC), such as are used
| by Kerberos.
Goals and Milestones
Done
Submit Internet-Draft of Internet Key Management Protocol to the IESG
for consideration as a Proposed Standard.
Done
Post as an Internet-Draft the IP Security Protocol.
Done
Post as an Internet-Draft the specification for Internet key
management.
Done
Conduct initial interoperability testing of Encapsulating Security
payload (ESP) and Authentication Header (AH).
| Done
Submit revised Internet-Drafts for ESP, AH, and IP Security
Architecture.
| Dec 96
Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH
to the IESG for consideration as Draft Standards.
| Jan 97
| Submit Internet-Draft of the Internet Key Management Protocol (IKMP).
| based on ISAKMP/Oakley to the IESG for consideration as a Proposed
| Standard.
| Jul 97
| Submit IKMP to IESG for consideration as a Draft Standard.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMkHj78UtR20Nv5BtAQEiAgP/XTqrl8Wn4jFpOgtukCbIgDUrsqzKiMDy
HCl6pX4BbXGpdiHlayCdhS1g5zbdwRa4J4TQg8sESbDkD49Zcs4a9bIDjY31gIB4
HnP7twW1/sEls5Rp/j9vBHTDHQIMJFVWluuJOrQQfPxcLAEFjH+3enfFRAJXQVmo
SOwHCHPmW7I=
=mr47
-----END PGP SIGNATURE-----
Subject: Re: The WG's inability to choose is good in this case.
To: ipsec@TIS.COM
Date: Thu, 19 Sep 1996 15:04:33 -0700 (PDT)
In-Reply-To: <199609191532.LAA567568@mailhub1.watson.ibm.com> from
"HUGO@watson.ibm.com" at Sep 19, 96 10:29:34 am
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
From: ipsec-approval@neptune.tis.com
Message-ID: <9609200726.aa21498@neptune.TIS.COM>
> One personal clarification regarding (2): in my opinion, there is a
> strong technical basis to require key exchange/refreshment via authenticated
> handshakes as supported by Oakley (even if in-line keying is also supported
> by the protocol).
Doesn't IBM have a patent on this?
--tom
Subject: Re: IPsec Minutes from Montreal
To: ipsec@TIS.COM
Date: Thu, 19 Sep 1996 14:59:46 -0700 (PDT)
In-Reply-To: <9609191751.AA18970@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Sep
19, 96 01:51:59 pm
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
From: ipsec-approval@neptune.tis.com
Message-ID: <9609200726.aa21481@neptune.TIS.COM>
> Well, the problem is that any time the minutes say anything good or bad
> about either protocol, people are going to claim that the minutes aren't
> "fair".
The problem is that the minutes don't describe what happened at the
meeting, which is what they're supposed to do. We're more than happy
to debate the merits of our protocol, but minutes should accurately and
fairly records what happens at the meetings -- not provide the chair's
opinions.
The minutes are not a forum where differences of opinion are somehow
resolved. They're supposed to be an accurate record of what took place
at the meeting.
> According to the ISAKMP camp, saying that SKIP "only" takes 2
> messages is a skewed, slanted view.
If someone had presented that at the meeting, yes, that should be in
the minutes.
Date: Thu, 19 Sep 1996 17:24:26 -0400
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>, ipsec@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: resistance to swamping attacks.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609200725.aa21463@neptune.TIS.COM>
At 12:30 PM 9/19/96 -0400, Bill Sommerfeld wrote:
>
>There have been a number of press reports about swamping attacks on
>TCP using forged source addresses. Some of these press reports have
>suggested that IPv6 will solve all this by requiring authentication.
>
This is from the End-to-End list:
Date: Wed, 18 Sep 1996 14:32:14 -0600
From: vjs@mica.denver.sgi.com (Vernon Schryver)
To: end2end-interest@ISI.EDU
Subject: SYN bombing defense
Sender: owner-end2end-interest@ISI.EDU
As reported here, in article <vxjiv9hkmcb.fsf_-_@dominator.eecs.harvard.edu>
in comp.protocols.tcp-ip, Robert Morris <rtm@dominator.eecs.harvard.edu>
wrote:
>Perhaps TCP's listen queue should use random early drop (RED), a
>technique used by routers to prevent any one source from monopolizing
>a queue. See http://www-nrg.ee.lbl.gov/floyd/abstracts.html#FJ93 or
>rfc1254.
> ...
I've just hacked IRIX 6.3 to do random-drop when sonewconn() in
tcp_input.c fails. It works great! An IP22 receiving 1200 bogus
SYN's per second directed to port 23 continues to answer requests
for new telnet as if nothing is happening.
I don't think that random <<Early>> drop is necessary or desirable.
It is not as if we're trying to drop packets early to trigger
slow start in the sources.
As I figure it, as long as the length of the queue is longer than RTT
of the real telnet client times the rate of bogus SYNs, the real
clients have an excellent probability of getting through on their
first attempt. For example, at 1200 bogus SYNs/sec and the IRIX 6.3
telnet listen queue of 383, there should be no trouble with peers
with RTT up to about 300 milliseconds. I've tested with a telnet
client 250 milliseconds away while simultaneously bombing the machine
from nearby with ~1200 SYNs/sec, and see no telnet TCP retransmissions.
Vernon Schryver, vjs@sgi.com
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
To: ipsec@TIS.COM, gnu@toad.com
Subject: Re: Request For Prior Art For U.S. Patent Number 5,548,646
In-Reply-To: <199609190047.RAA10525@iplaw.Corp.Sun.COM>
Date: Thu, 19 Sep 1996 16:31:54 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609200727.aa21519@neptune.TIS.COM>
I have updated the "Network Encryption - history and patents" web page
with Sun's request for prior art, a copy of the DEC patent they mention,
and Greg Ahronian's message about the dangers of letting companies
review prior art claims in private with the Patent Office. See
http://www.cygnus.com/~gnu/netcrypt.html.
John
To: Bill Sommerfeld <sommerfeld@apollo.hp.com>
Cc: ipsec@TIS.COM, gnu@toad.com
Subject: Re: resistance to swamping attacks.
In-Reply-To: <199609191630.MAA00380@thunk.orchard.medford.ma.us>
Date: Thu, 19 Sep 1996 17:00:04 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609200728.aa21538@neptune.TIS.COM>
Bill Sommerfeld wrote:
> If a system has a normal communications bandwidth of X, and recieves
> an incoming storm from forged source addresses with a bandwidth of Y
> (less than X), it should be able to continue to use at least half of
> the remaining bandwith (X-Y) constructively to communicate with
> arbitrary legitimate peers, including peers which had never before
> communicated with it.
It's great to see protocol goals structured this way. Can we do all
of them like this?
Let's see if we can refine this one a bit to something we believe we
can implement!
Systems have inbound bandwidth and outbound bandwidth, and we will
have to distinguish among them, because an incoming storm will only
directly affect the incoming bandwidth.
Also, your goal assumes a non-interactive attack, that is, that the
attacker cannot see any of the outgoing traffic in response to the
attack. It's a much harder problem if the attacker is positioned
on the network so that they can snatch some of the cookies off the
ether, and send them back as part of the attack.
So, my attempt:
Resistance to non-interactive flood attacks:
Assume a system has a normal incoming communications bandwidth of
IX, a normal outgoing communications bandwidth of OX, and the
ability to set up N new connections to peers per second. Assume
the system is attacked by a flood of incoming packets consuming
bandwidth IY, responds to the flood with response packets
consuming bandwidth OY, and also receives ICMP messages resulting
from bouncing response packets consuming incoming bandwidth IZ.
Assume that the attacker is unable to read any of the response
packets. Then:
The system MUST be able to constructively use IX-IY-IZ of the
incoming bandwidth, and
The system MUST be able to constructively use OX-OY
of the outgoing bandwidth, and
The system MUST be able to set up at least N/2 new
connections per second.
"Constructively use" means that the bandwidth is available for
communication with arbitrary legitimate peers, including peers which
had never before communicated with the system.
John