[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04
Network Working Group W. Aiello
Internet Draft S.M. Bellovin
draft-ietf-ipsec-jfk-04.txt M. Blaze
Expires in 6 months R. Canetti
J. Ioannidis
A.D. Keromytis
O. Reingold
Just Fast Keying (JFK)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 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.
Abstract
This draft discusses JFK, a key management protocol.
1. Introduction
Many public-key-based key setup and key agreement protocols already
exist and have been implemented for a variety of applications and
environments. Several have been proposed for the IPsec protocol,
and one, IKE [RFC2409], is the current standard. IKE has a number
of deficiencies, the three most important being that the number of
rounds is high, that it is vulnerable to denial-of-service attacks,
and the complexity of its specification. (This complexity has led
to interoperability problems, so much so that, several years after
its initial adoption by the IETF, there are still completely
non-interoperating implementations.)
While it may be possible to ``patch'' the protocol to fix some of
these problems, we would prefer to replace IKE with something
better. With that in mind, we set out to engineer a new key
exchange protocol specifically for Internet security applications.
With a view toward its possible role as a successor to IKE, we call
our new protocol ``JFK,'' which stands for ``Just Fast Keying.''
1.1 Design Goals
We seek a protocol with the following characteristics (in no
particular order):
o Security: The resulting key should be cryptographically secure,
according to standard measures of cryptographic security for
key-exchange.
o Simplicity: It must be as simple as possible.
o Memory-DoS: It must resist memory exhaustion attacks on the
responder.
o Computation-DoS: It must resist CPU exhaustion attacks on the
responder.
o Privacy: It must provide protection for the privacy of the parties.
(Different variants are considered within.)
o Efficiency: It must be efficient with respect to computation,
bandwidth, and number of rounds.
o Non-Negotiated: It must avoid complex negotiations over
capabilities.
o PFS: It must approach perfect forward secrecy.
The Security property is obvious enough; the rest, however, require
some discussion.
The Simplicity property is motivated by several factors.
Efficiency is one; increased likelihood of correctness is another.
But our motivation is especially colored by our experience with
IKE. Even if the protocol is defined correctly, it must be
implemented correctly; if a protocol definition is too complex,
implementors will get it wrong. This hinders both security and
interoperability.
Let us highlight two ways in which the simplicity requirement is
met by the proposed protocol. First, we avoid the complex two-phase
structure of IKE. This buys us a great deal in terms of simplicity,
with little to no cost in terms of functionality. (See more details
within.) Second, we restrict the protocol to a small and fixed number
of rounds: two rounds trips, always, with no optional additional
rounds. This results in greater simplicity in implementation,
debugging, customization, and operation.
The Memory-DoS and Computation-DoS properties have become more
important in the context of recent Internet denial-of-service
attacks. Photuris [RFC2522] was the first published key management
protocol for which DoS-resistance was a design consideration; we
suggest that these properties are at least as important today.
Photuris first introduced the concept of cookies to counter
``blind'' denial of service attacks. Although the concept of the
cookie was adopted by IKE, its use in that protocol did not follow
the guidelines established by Photuris and left it open to DoS
attacks.
The Privacy property means that the protocol does not reveal the
identities of the parties to an attacker. There are several variants
here: First, the protection can cover the initiator, or the responder
or both. Second, the protection can be valid either against active
attackers or alternatively only against passive eavesdroppers. We
present two protocol variants: One variant provides identity protection
for the initiator against active attacks, and no protection for the
responder. This variant seems more suitable for a client-server scenario
where the initiator (the client) needs full identity protection while
the responder (the server) needs no identity protection. The other
variant protects the identity of the responder from active attackers,
and in addition protects the identity of the initiator from
eavesdroppers. This variant seems more suitable for peer-to-peer
scenarios where both parties need identity protection but the
responder is more vulnerable to active attacks. We leave it to the
working group to choose the variant that best suites the needs of
IPSEC. (Potentially, one could design a protocol where the parties
negotiate whose identity needs to be protected against active
attackers. However we believe this would result in an unnecessarily
complex protocol.)
The Efficiency property is worth discussing. In many protocols,
key setup is must be performed frequently enough that it can become
a bottleneck to communication. The key exchange protocol must
minimize both computation as well total bandwidth and round trips.
Round trips can be an especially important factor over unreliable
media.
The Non-Negotiation property is necessary for several reasons. The
first, of course, is as a corollary to Simplicity and Efficiency.
Negotiations create complexity and round trips, and hence should be
avoided. Denial of service resistance is also relevant here; a
partially-negotiated security association is consuming resources.
The PFS property is perhaps the most controversial. Rather than
assert that ``we must have perfect forward secrecy at all costs'',
we treat the amount of forward secrecy as an engineering parameter
that can be traded off against other necessary functions, such as
resistance to denial-of-service attacks. In fact, this corresponds
quite nicely to the reality of today's Internet systems, where a
compromise during the existence of a security association will
reveal the plaintext of any ongoing transmissions. JFK has the
concept of a ``forward secrecy interval''; associations are
protected against compromises that occur outside of that interval.
Protocol design is, to some extent, an engineering activity, and we
need to provide for trade-offs between different types of security.
There are trade-offs that we made during the protocol design, and
others, such as the trade-off between forward secrecy and
computational effort, that are left to the implementation and to
the user, e.g., selected as parameters during configuration and
session negotiation.
We present two protocols (or, rather, two variants of the protocol).
The variants, denoted JFKi and JFKr, are very similar in many respects,
with two main differences: JFKi provides active identity protection for
the initiator and no identity protection for the responder, whereas
JFKr provides active identity protection for the responder and passive
identity protection for the initiator. In addition, JFKi contains
an additional (amortizable) signature. We note that the cryptographic
core of JFKr follows that of SIGMA [K01] and IKEv2 [IKEv2].
2. The JFK Protocol
2.1 Notation
E{K}(M): encryption of M with symmetric key K.
HMAC{K}(M): keyed hash of M using key K in an HMAC scheme [RFC2104].
SIG{x}(M): digital signature of M using the private key belonging
to principal x (Initiator or Responder). It is not
assumed to be a message-recovering signature (but it can
be).
The message components used in JFK are as follows:
g^x: Diffie-Hellman exponentials, also identifying the group-ID.
The Diffie-Hellman groups identified in [RFC2409] are used.
g^i, g^r: Initiator and Responder exponentials.
Ni: Initiator nonce, a random bit-string. The Initiator MUST pick
a fresh nonce at each invocation of the JFK protocol. The
first few bytes (2 or 4, for IPv4 or IPv6 respectively) of this
nonce may contain a cookie used by the Responder to help the
Initiator avoid fragmentation-based DoS attacks (see Appendix
B).
IPi: The Initiator's network identifier (IPv4 or IPv6 address). It
is used by the Responder to counter a "cookie-jar" attack, when
verifying the authenticator upon receipt of Message 3.
Nr: Responder nonce, a random bit-string. The Responder MUST pick
a fresh nonce at each invocation of the JFK protocol. The
nonces are used in the session key computation, to provide key
independence when one or both parties reuse the same
Diffie-Hellman exponential; the session key will be different
different between independent runs of the protocol, as long as
one of the nonces or exponentials changes. The first few bytes
(2 or 4, for IPv4 or IPv6 respectively) of this nonce may
contain a cookie used by the Initiator to help the Responder
avoid fragmentation-based DoS attacks (see Appendix B).
sa: Defines the cryptographic and other properties of the Security
Association (SA) the Initiator wants to establish. It contains
a Domain-of-Interpretation, which JFK understands, and an
application-specific bit-string.
sa': Any information that the Responder needs to provide to the
Initiator with respect to the application SA (e.g., the
Responder's SPI, in IPsec).
HKr: A transient hash key private to the Responder; this is a
global parameter for the Responder (i.e., it is not different
for every different protocol run), which changes periodically:
the Responder must pick a new g^r every time HKr changes. The
use of HKr and the implications of changing it periodically
will be explained later in this section.
Kir: A shared key derived from g^ir, Ni, and Nr, used as part of
the application SA (e.g., IPsec SA).
Ke: A shared key derived from g^ir, Ni, and Nr, used to protect the
secrecy of messages 3 and 4 of the protocol. Although the
input parameters are the same with Kir, a different key
derivation mechanism is used to ensure key independence.
Ka: A shared key derived from g^ir, Ni, and Nr, used to
integrity-protect messages 3 and 4 of the protocol. Although
the input parameters are the same with Kir and Ke, a different
key derivation mechanism is used to ensure key independence.
Ks: A shared key derived from g^ir, Ni, and Nr, used to
authenticate subsequent runs of the protocol. Although the
input parameters are the same with Kir, Ke, and Ka, a different
key derivation mechanism is used to ensure key independence.
IDi, IDr: Initiator and Responder certificates, or public-key
identifying information, or previous-state identifying
information. Multiple such payloads may appear in a
message, to indicate multiple certificates, CRLs, etc.
For simplicity and clarity, the notation in this draft
shows only one such payload per message.
IDr': an indication by the Initiator to the Responder as to what
identity (and corresponding key material) the latter should use
to authenticate to the former. The Responder may ignore this
hint. This field may contain the certificate of a CA trusted
by the Initiator (which means that the Initiator is requesting
that the Responder authenticate with a certificate chain
"rooted" at that CA), or the certificate of the Responder
(effectively identifying the public, and corresponding private,
key of the Responder).
GRPINFOr: A list of all Diffie-Hellman groups supported by the
Responder, the symmetric algorithm used to protect
messages 3 and 4, and the hash function used for key
generation.
2.2 Protocol JFKr
This variant of the JFK protocol provides the same DoS protection
and identity protection against passive attackers for both the
Initiator and the Responder, but no protection against active
identity discovery attacks for the Initiator (the Responder is
protected against active identity discovery).
Using the same notation as in section 2, the JFKr protocol is:
Message 1, I->R: Ni, g^i
Message 2, R->I: Ni, Nr, g^r, GRPINFOr,
HMAC{HKr}(g^r, Nr, Ni, IPi)
Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi),
E{Ke}(IDi, IDr' sa, SIG{i}(Ni, Nr, g^i, g^r, GRPINFOr)),
HMAC{Ka}('I', E{Ke}(IDi, IDr', sa, SIG{i}(Ni, Nr, g^i, g^r, GRPINFOr)))
Message 4, R->I: Ni, Nr, E{Ke}(IDr, sa', SIG{r}(g^r, Nr, g^i, Ni)),
HMAC{Ka}('R', E{Ke}(IDr, sa', SIG{r}(g^r, Nr, g^i, Ni)))
The keys used to protect Messages (3) and (4), Ke and Ka, are
computed as HMAC{g^ir}(Ni, Nr, 1) and HMAC{g^ir}(Ni, Nr, 2)
respectively. The session key used by IPsec (or any other
application), Kir, is HMAC{g^ir}(Ni, Nr, 0). Key Ks, used for
lightweight mode authentication (see Section 3), is computed as
HMAC{g^ir}{Ni, Nr, 3}.
If more key material is needed, the same mechanism for "key
stretching" as specified in [IKEv2] may be used.
Message (1) is straightforward; note that it assumes that the
Initiator already knows a group and generator that is acceptable to
the Responder. The Initiator can reuse a g^i value in multiple
instances of the protocol with the Responder or other responders
that accept the same group, for as long as she wishes her forward
secrecy interval to be. We discuss how the Initiator can discover
what groups to use later.
In Message (2), the Responder replies with his own exponential (in
the same group), information on what secret key algorithms are
acceptable for the next message, a random nonce, and an
authenticator calculated from a secret, HKr, known to the
Responder; the authenticator is computed over the Responder
exponential, the two nonces, and the Initiator's network address.
The Responder's exponential may also be reused; again, it is
regenerated according to the Responder's forward secrecy interval.
Finally, note that the Responder does not need to generate any
state at this point, and the only ``expensive'' operation is a MAC
calculation.
Message (3) echoes back the data sent by the Responder, including
the authenticator. The authenticator is used by the Responder to
verify the authenticity of the returned data. The authenticator
also confirms that the sender of Message (3) uses the same address
as in Message (1) --- this can be used to detect and counter a
``cookie jar'' DDoS attack. The message also includes the
Initiator's identity and service request, and a signature computed
over the nonces, the Responder's identity, and the two
exponentials. This latter information is all encrypted under a key
derived from the Diffie-Hellman computation and the nonces Ni and
Nr. The encryption and authentication use algorithms specified in
GRPINFOr. The Responder keeps a copy of recently-received Message
(3)'s, and their corresponding Message (4). Receiving a duplicate
(or replayed) Message (3) causes the Responder to simply retransmit
the corresponding Message (4), without creating new state or
invoking IPsec (or other application using JFKr as the key
establishment protocol). This cache of messages can be reset as
soon as HKr is changed. The Responder's exponential (g^r)
is re-sent by the Initiator because the Responder may be generating
a new g^r for every new JFK protocol run (e.g., if the arrival rate
of requests is below some threshold). Note: It is important that
the responder deals with repeated Message (3)'s as described above.
Responders that create new state for a repeated Message (3) open
the door to attacks against the protocol. The message is also
protected by an MAC (such as HMAC), using a key derived from the
Diffie-Hellman computation and the nonces Ni and Nr. Notice that
this key is different form the one used for encrypting the message.
Message (4) contains application-specific information (such as the
Responder's IPsec SPI), and a signature on both nonces and both
exponentials. Everything is encrypted by Ke, which is derived from
Ni, Nr, and g^ir (the result of the Diffie-Hellman
computation). As in Message (3), this message is also protected by
a MAC using key Ka.
We remark that the core cryptographic design of JFKr follows that
of SIGMA [K01] and IKEv2 [IKEv2].
2.3 Discussion
The design follows from our requirements. With respect to
communication efficiency, observe that the protocol requires only
two round trips. The protocol is optimized to protect the
Responder against denial of service attacks on state or
computation. The Initiator must establish round-trip communication
with the Responder before the latter is required to perform
expensive operations. At the same time, the protocol is designed
to protect both parties from revealing their identities in the
clear. An active attacker can determine the Initiator's identity
by performing a man-in-the-middle attack, since the Initiator must
authenticate to the Responde first (this is a consequence of the
4-message exchange combined with the "liveness" requirement for
DDoS prevention).
The Initiator's initial message, Message (1), is a straight-forward
Diffie-Hellman exponential. Note that this is assumed to be
encoded in a self-identifying manner, i.e., it contains a tag
indicating which modulus and base was used. The nonce Ni serves two
purposes: first, to allow the Initiator to reuse the same
exponential across different sessions (with the same or different
Responders, within the Initiator's forward secrecy interval) while
ensuring that the resulting session key will be
different. Secondly, it can be used to differentiate between
different parallel sessions.
Message (2) must require only minimal work for the Responder, since
at that point he has no idea whether the Initiator is a legitimate
correspondent or, e.g., a forged message from an denial of service
attack; no round trip has yet occurred with the Initiator.
Therefore, it is important that the Responder not be required at
this point to perform expensive calculations or create state.
Here, the Responder's cost will be a single authentication
operation, the cost of which (for HMAC) is dominated by two
invocations of a cryptographic hash function, plus generation of a
random nonce Nr. Notice that, if the Responder is reusing the
same g^r across multiple Initiators, the beginning of the HMAC
computation can be cached along with g^r.
The Responder may compute a new exponential g^r for each
interaction. This is an expensive option, however, and at times of
high load (or attack) it would be inadvisable. The nonce prevents
two successive session keys from being the same, even if both the
Initiator and the Responder are reusing exponentials.
A simple way of dealing with DDoS is to periodically (e.g., once
every 30 seconds) generate an (r, g^r, HMAC(HKr){g^r}) tuple and
place it in a FIFO queue. As requests arrive (in particular, as
valid Message (3)'s are processed), the first entry from the FIFO
is removed. If the rate of requests exceeds the generating rate, a
JFKr implementation should reuse the last tuple in the FIFO.
Notice that in this scheme, the same g^r may be reused in different
sessions, if those sessions are interleaved. This does not violate
the PFS or other security properties of the protocol.
If the Responder is willing to accept the group identified in the
Initiator's message, his exponential must be in the same group.
Otherwise, he may respond with an exponential from any group of his
own choosing. The field GRPINFOr lists what groups the Responder
finds acceptable, if the Initiator should wish to restart the
protocol. This provides a simple mechanism for the Initiator to
discover the groups currently allowed by the Responder. That field
also lists what encryption algorithm is acceptable for the next
message. This is not negotiated; the Responder has the right to
decide what strength encryption is necessary to use his services.
Note that the Responder creates no state when sending this message.
If it is bogus --- that is, if the Initiator is non-existent or
intent on perpetrating a denial-of-service attack --- the Responder
will not have committed any storage resources.
In Message (3), the Initiator echoes content from the Responder's
message, including the authenticator. The authenticator allows the
Responder to verify that he is in round-trip communication with a
legitimate potential correspondent. She also uses the key derived
from the two exponentials and the two nonces to encrypt her
identity and service request. (The Initiator's nonce is used to
ensure that this session key is unique, even if both the Initiator
and the Responder are reusing their exponentials and the Responder
has ``forgotten'' to change nonces.) The key used to protect
Messages (3) and (4), Ke, is computed as HMAC{g^ir}{Ni, Nr, 1}. The
session key used by IPsec (or any other application), Kir, is
HMAC{g^ir}(Ni, Nr, 0). The message authentication key, Ka, is
computed as HMAC{g^ir}{Ni, Nr, 2}. For this computation, the
values '0', '1', and '2' correspond to a single-byte decimal value
(so the HMAC computation is over the two nonces and one extra byte,
with the corresponding value).
In JFKr, the parties obtain a shared encryption key, Ke, before any
of the parties send their identities. Therefore, both parties send
their identities encrypted with Ke, thus providing both parties
with identity protection against passive eavesdroppers. In
addition, the party that first reveals its identity is the
initiator. This way, the responder is required to reveal its
identity only after it verifies the identity of the initiator.
This guarantees active identity protection to the responder.
The service request (sa payload) is encrypted too, since its
disclosure might identify the requester. The Responder may wish to
require a certain strength of cryptographic algorithm for certain
services.
We remark that it is essentially impossible, using current
technology, to provide a two-round-trip protocol that provides DOS
protection for the responder, passive identity protection for both
parties, and active identity protection for the initiator. An
informal argument proceeds as follows: If DoS protection is in
place, then the responder must be able to send his first message
before he computes any shared key. (This is so since computing a
shared key is a relatively costly operation in current technology.)
This means that the responder cannot send its identity in the
second message, without compromising its identity protection
against passive eavesdroppers. This means that the responder's
identity must be sent in the fourth (and last) message of the
protocol. Consequently, the initiator's identity must be sent
before the responder's identity is sent.
Upon successful receipt and verification of message (3), the
Responder has a shared key with a party known to be the Initiator.
The Responder further knows what service the Initiator is
requesting. At this point, he may accept or reject the request.
The Responder's processing on receipt of Message (3) requires
verifying an authenticator and --- if that is successful ---
performing several public key operations to verify the Initiator's
signature and certificate chain. The authenticator (again
requiring two hash operations) is sufficient defense against
forgery; replays, however, could cause considerable computation.
The defense against this is to cache the corresponding Message (4);
if a duplicate Message (3) is seen, the cached response is
retransmitted; the Responder does not create any new state or
notify the application (e.g., IPsec). The key for looking up
Message 3's in the cache is the authenticator; this prevents
DoS attacks where the attacker randomly modifies the encrypted
blocks of a valid message, causing a cache miss and thus more
processing to be done at the Responder. Further, if the
authenticator verifies but there is some problem with the message
(e.g., the certificates do not verify), the responder can cache the
authenticator along with an indication as to the failure (or the
actual rejection message), to avoid unnecessary processing (which
may be part of a DoS attack). This cache of Message(3)'s and
authenticators can be purged as soon as HKr is changed (since the
authenticator will no longer pass verification).
Caching Message (3) and refraining from creating new state for
replayed instances of Message (3) serves also another security
purpose. If the Responder were to create a new state and send a
new Message (4), and a new sa' for a replayed Message (3), then an
attacker that compromised the Initiator could replay a recent
session with the Responder. That is, by replaying Message (3) from
a recent exchange between the Initiator and the Responder, the
attacker could establish a session with the Responder where the
session-key is identical to the key of the previous session (which
took place when the Initiator was not yet compromised). This could
compromise the Forward Security of the Initiator.
There is a risk, however, to keeping this message cached for too
long: if the Responder's machine is compromised during this period,
perfect forward secrecy is compromised. We can tune this by
changing the MAC key HKr more frequently. The cache can be reset
when a new HKr is chosen.
In Message (4), the Responder sends to the Initiator any
Responder-specific application data (e.g., the Responder's IPsec
SPI), along with a signature on both nonces, both exponentials, and
the Initiator's identity. All the information is encrypted using a
key derived the two nonces, Ni and Nr, and the Diffie-Hellman
result. The Initiator can verify that the Responder is present and
participating in the session, by decrypting the message and
verifying the enclosed signature.
2.4 Rejection Messages
Instead of sending Messages (2) or (4), the Responder can send a
'rejection' instead. For Message (2), this rejection can only be
on the grounds that he does not accept the group that the Initiator
has used for her exponential. Accordingly, the reply should
indicate what groups are acceptable. Since Message (2) already
contains the field GRPINFOr (which indicates what groups are
acceptable), no explicit rejection message is needed. (For
efficiency sake, the group information could also be in the
Responder's long-lived certificate, which the Initiator may already
have.)
Message (4) can be a rejection for several reasons, including lack
of authorization for the service requested. But it could also be
caused by the Initiator requesting cryptographic algorithms that
the Responder regards as inappropriate, given the requester
(Initiator), the service requested, and possibly other information
available to the Responder, such as the time of day or the
Initiator's location as indicated by the network. In these cases,
the Responder's reply should list acceptable cryptographic
algorithms, if any. The Initiator would then send a new Message
(3), which the Responder would accept de novo; again, the Responder
does not create any state until after a successful Message (3)
receipt.
2.5 What JFK Avoids
By intent, JFK does not do certain things. It is worth enumerating
them, if only to forestall later attempts to add them in. The
``missing'' items were omitted by design, in the interests of
simplicity.
In our view, any form of authentication other than certificate
chain trusted by the other party is best accomplished by outboard
protocols. Initiators that wish to rely on any form of legacy
authentication can use the protocols being defined by the IPSRA or
SACRED working groups. While these mechanisms do add extra round
trips, the expense can be amortized across many JFK negotiations.
Similarly, certificate chain discovery (beyond the minimal
capabilities implicit in IDi and IDr) should be accomplished by
protocols defined for that purpose. By excluding these protocols
for JFK, we can exclude them from our security analysis; the only
interface between the two is a certificate chain, which by
definition is a stand-alone secure object. However, it is possible
to use the lightweight JFK mode, as described in Section 3, to
perform shared-secret based authentication.
We also eliminate negotiation, in favor of ukases issued by the
Responder. The Responder is providing a service; it is entitled to
set its own requirements for that service. Any cryptographic
primitive mentioned by the Responder is acceptable; the Initiator
can choose any it wishes. We thus eliminate complex rules for
selecting the ``best'' choice from two different sets. We also
eliminate state to be kept by the Responder; the Initiator can
either accept the Responder's desires or restart the protocol.
Finally, we reject the notion of two different phases. The
practical benefits of quick mode are limited. Furthermore, we do
not agree that frequent rekeying is necessary. If the underlying
block cipher is sufficiently limited as to bar long-term use of any
one key, the proper solution is to replace that cipher. For
example, 3DES is inadequate for protection of very high speed
transmissions, because the probability of collision in CBC mode
becomes too high after less than encryption of $2^{32}$ plaintext
blocks. Using AES instead of 3DES solves that problem without
complication the key exchange. Should low-cost rekeying be
necessary, the JFK protocol itself can be run in ``lightweight''
mode, as we describe in Section 3.
2.6 Phase II and the Lack Thereof
Phase II of IKE is used for several things. We do not regard any
of them as necessary.
One is generating the actual keying material used for security
associations. It is expected that this will be done several
times, to amortize the expense of the Phase I negotiation.
A second reason for this is to permit very frequent rekeying.
Finally, it permits several separate security associations to
be set up, with different parameters.
We do not think these apply. First, with modern ciphers, such as
AES, there is no need for frequent key changes. AES keys are long
enough that brute force attacks are infeasible. Its longer block
size protects against CBC limitations when encrypting many blocks
[BDJR97].
We also feel that JFK is efficient enough that avoiding the
overhead of a full key exchange is not required. Rather than add
new SAs to an existing Phase I SA, we suggest that a full JFK
exchange be initiated instead. We note that the initiator can also
choose to reuse its exponential, it if wishes to trade perfect
forward secrecy for computation time. If state already exists
between the initiator and the responder, they can simply check that
the Diffie-Hellman exponentials are the same; if so, the result of
the previous exponentiation can be reused. As long as one of the
two parties uses a fresh nonce in the new protocol exchange, the
resulting cryptographic keys will be fresh and not subject to a
related key (or other, similar) attack. As we discuss in Section
3, a similar performance optimization can be used on the
certificate chain validation.
A second major reason for Phase II is dead peer detection. IPsec
gateways often need to know if the other end of a security
association is dead, both to free up resources and to avoid "black
holes". In JFK, this is done by noting the time of the last packet
received. A peer that wishes to elicit a packet may send a "ping".
Such hosts MAY decline any proposed security associations that do
not permit such "ping" packets.
A third reason for Phase II is general security association
control, and in particular SA deletion. While such a desire is not
wrong, we prefer not to burden the basic key exchange mechanism
with extra complexity. There are a number of possible approaches.
Our requires that JFK endpoints implement the following rule: a new
negotiation that specifies an SPD identical to the SPD of an
existing SA overwrites it. To some extent, this removes any need
to delete an SA if black hole avoidance is the concern; you simply
negotiate a new one. If you wish to delete an SA without replacing
it, negotiate a new SA with the ESP_BYPASS, AH_BYPASS or
IPCOMP_BYPASS ciphersuite.
3. Rekeying
When a negotiated SA expires (or shortly before it does), the JFK
protocol is run again. It is up to the application to select the
appropriate SA to use among many valid ones. In the case of IPsec,
implementations should switch to using the new SA for outgoing
traffic, but would still accept traffic on the old SA (as long as
that SA has not expired).
To address performance considerations, we should point out that,
properly implemented, rekeying only requires one signature and one
verification operation in each direction, if both parties use the
same Diffie-Hellman exponentials (in which case the cached result
can be reused) and certificates: the receiver of an ID payload
compares its hash with those of any cached ID payloads received
from the same peer. While this is an implementation detail, a
natural location to cache past ID payloads is along with already
established SAs (a convenient fact, as rekeying will likely occur
before existing SAs are allowed to expire --- so the ID information
will be readily available). If a match is found and the result has
not "expired" yet, then we do not need to re-validate the
certificate chain. A previously verified certificate chain is
considered valid for the shortest of its CRL re-validate time,
certificate expiration time, OCSP result validity time, etc. For
each certificate chain, there is one such value associated (the
time when one of its components becomes invalid or needs to be
checked again).
Notice that an implementation does need to cache the actual ID
payloads; all that is needed is the hash and the expiration time.
That said, if for some reason fast rekeying is needed for some
application domain, it can be done by re-using the JFKr protocol
itself, using an ID payload identifying a previous exchange (and
thus a corresponding secret key generated during that exchange) and
an HMAC instead of a public-key signature for authentication.
Message 1, I->R: Ni, g^i
Message 2, R->I: Ni, Nr, g^r, GRPINFOr,
HMAC{HKr}(g^r, Nr, Ni, IPi)
Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi),
E{Ke}(IDi, IDr' sa, HMAC{Ks}(Ni, Nr, g^i, g^r, GRPINFOr)),
HMAC{Ka}('I', E{Ke}(IDi, IDr', sa, HMAC{Ks}(Ni, Nr, g^i, g^r, GRPINFOr)))
Message 4, R->I: Ni, Nr, E{Ke}(IDr, sa', HMAC{Ks}(g^r, Nr, g^i, Ni)),
HMAC{Ka}('R', E{Ke}(IDr, sa', HMAC{Ks}(g^r, Nr, g^i, Ni)))
The only difference from the basic JFKr protocol is the use of an
HMAC in messages 3 and 4 for peer authentication. The HMAC is
computed over the same fields as the public key signature in the
basic protocol. The shared key, Ks, is either statically
configured (when JFKr is used for shared-secret based
authentication) or is derived from a previous exchange.
Payloads IDi and IDr identify the secret key in use. For
shared-secret authentication, these are free-form strings that are
configured by the administrator (or otherwise provided through
means outside the JFK protocol's scope).
When Ks is derived from a previous JFKr exchange, the IDi and IDr
payloads contain unique identifiers provider by the Responder and
the Initiator respectively in the previous protocol exchange, and
are used to identify the shared-secret. These identifiers should
be treated as opaque bitstrings by the receiver. Effectively, at
each protocol run, each party provides their peer with a cookie.
This cookie can be used by the peer in subsequent rounds to
identify the shared secret to use for authentication.
When run in lightweight mode, and if both parties reuse the
exponentials g^i and g^r, new application (e.g., IPsec) SAs can be
established without any public-key operations. If PFS is desired,
then both parties have to perform one modular exponentiation
operation (for the Diffie-Hellman computation). No signature or
certificate verification is require for this mode.
4. Wire Format
This section describes a proposal for the specific protocol
elements for the protocol described in this document. The authors
of the document are not strongly attached to these proposed
elements. More detail on the protocol elements will be added in
later drafts.
The protocol will be run over UDP on a port to be assigned later by
IANA. UDP is chosen to avoid well-known TCP attacks, although
running JFK over UDP may cause some problems with packet
fragmentation and reordering. For pre-standards testing purposes,
UDP port 1024 which is reserved by IANA and will *not* be the
eventual port for JFK.
Implementors of IKE have long complained that the specification
required or strongly suggested too many algorithms that had
essentially the same properties. Because of this, JFK only lists
one option for each type of algorithm below. In the future,
additional options might be added (which is why there are algorithm
identifiers in the protocol), but they should only be added if
there is a strong security requirement for them. Two such
requirements would be the compromise of one of the listed
algorithms or the adoption of a much stronger or much more capable
algorithm. Additional algorithms can only be added by a
standards-track RFC.
4.1 Structure
Each message is a string of tag-length-value elements concatenated
together. Tags are one octet. Lengths are two octets, and specify
the number of octets of the value. Values are always integral
numbers of octets. All octets are in big-endian order.
The values for the tags are:
Tag Value (in decimal)
Ni 1
Nr 2
g^i 3
g^r 4
GRPINFOr 5
IDi 6
IDr, IDr' 7
Signature 8
HashedInfo 9
encrypt_i 10
encrypt_r 11
sa, sa' 12
rejectinfo_to_msg3 13
4.2 Description of the values for each tag
Nonces Ni and Nr MUST be 8 octets or longer.
g^i and g^r are expressed as a single octet specifying the group
number, followed by value of Diffie-Hellman exponential. The group
number is the same as the group numbers used in [RFC2409].
GRPINFOr is expressed as a string of at least four octets. The
first octet is the encryption algorithm ID, the second octet is the
signature algorithm ID, and the third octet is the hash function
used for session key derivation. Each remaining octet specifies an
acceptable group number.
IDi, IDr, and IDr' are expressed as a single octet specifying the
type of ID used, followed by the ID material. The following ID
types are specified.
ID tag Meaning
1 PKIX certificate
2 CRL
3 OCSP response
Signatures are expressed as one octet specifying the signature
algorithm followed by the octets of the signature.
HashedInfo is expressed as one octet specifying the keyed hash
algorithm followed y the octets of the hash.
encrypt_i and encrypt_r are expressed as one octet specifying the
encryption algorithm followed by the encrypted content. When using
a block cipher with chaining, requiring an Initialization Vector
(IV), the IV is prepended to the ciphertext and constitutes the
first block of the payload.
sa and sa' are expressed by one octet specifying the SA type
followed by the SA itself. The following SA types are specified.
SA tag Meaning
1 IPsec SA, as described below.
2 Opaque identifier for lightweight mode
authentication. Contents should be treated as a bit-string
and passed as is to the peer on subsequent rounds of
the protocols, to identify the correct key Ks to use for
the HMAC computation.
Both types (1 and 2) of sa payload may appear in messages 3 and 4.
rejectinfo_to_msg3 has the same structure as grpInfo.
Encryption algorithm IDs (for use in JFK only)
3DES 1
Signature algorithm IDs (for use in JFK only)
RSA 1
Hash algorithm IDs (for use in JFK only)
SHA-1 1
5. Security Associations and the Security Policy Database
Security Association in JFK follows the two primary principles
of JFK: simplicity and lack of negotiation. The latter
is straightforward: an initiator proposes an SA; the
responder may either accept it or reject it with a reason.
The myriad combinations of cipher and authentication suites
available in IKE contributed in no small measure to
interoperability problems. We follow the suggestion put forth by
an early IKEv2 draft: the acceptable combinations are denoted by
16-bit, unstructured integers. The integers may happen to be
assigned according to some structuring principle, but
implementations MUST NOT treat them as other than opaque values.
The initial set of algorithms that MUST be supported is:
ESP-AES-CBC with HMAC-SHA1
ESP-3DES-CBC with HMAC-MD5
ESP-3DES-CBC with HMAC-SHA1
ESP-NULL with HMAC-MD5
ESP-NULL with HMAC-SHA1
ESP_BYPASS
AH with HMAC-MD5
AH with HMAC-SHA1
AH_BYPASS
IPCOMP_DEFLATE
IPCOMP_BYPASS
The 3DES choices are for backwards compatibility. We do not
specify a DES variant -- DES was demonstrated to be insecure
several years ago, and implementors have had time to upgrade.
We do support MD5, but recommend that it not be used.
The *_BYPASS entries are used to indicate that existing SAs of
that type that have previously been negotiated between the two
peers should be deleted.
Following the algorithm choice is a 4-byte value containing the
sender's SPI, in network byte order (big endian format).
Following the SPI are two lists of zero or more SPD elements, the
list of source addresses followed by the list of destination
addresses.
JFK supports two different address types: a list of IPv4 address
ranges, and a list of IPv6 address ranges. A single address is a
range where the starting and ending elements are the same.
Subnets are converted to range format. The notion of "all
addresses" is expressed as the pair (0, 0xFFFFFFFF) for IPv4; v6
is handled similarly.
Port numbers are also expressed as pairs; again, the concept
of "all ports" is represented as (0, 0xFFFF). The same is
done for protocols.
An SPD element has the following format:
Address family version v4/v6 (2 bytes)
Transport protocol range (TCP, UDP, etc.) (2 bytes)
Number of address ranges (2 bytes)
address ranges...
Number of port number ranges (2 bytes)
port number ranges...
An SPD source or destination specification consists of a two-byte
counter for the number of SPD elements, followed by each element.
The simplest entry -- all protocols, all ports, all addresses, for
IPv4 -- would look like this:
Bytes
1 2
----
0001 Number of SPD elements (1 element)
0004 Address family (IPv4 addresses)
00FF Protocol range (all transport protocols)
0001 One address range
0000,0000 (4 bytes, 0.0.0.0)
FFFF,FFFF (4 bytes, 255.255.255.255)
0001 Number of port ranges (1 port range)
0000 Beginning of transport protocol port range (port 0)
FFFF End of port range (port 65535)
Two specifications are contained in the sa and sa' payloads, one
for the source range followed by one for the destination range.
When transmitted on the wire, all values are sent in big endian
format.
6. Security Considerations
This section very briefly overviews our security analysis of the
JFK protocol. Full details are deferred to the full analysis paper.
In general, there are currently two main approaches to analyzing
security of protocols. One is the formal-methods approach, where
the cryptographic components of a protocol are modeled by "ideal
boxes" and automatic theorem-verification tools are used to verify
the validity of the high-level design (assuming ideal
cryptography). The other is the cryptographic approach, which
accounts for the facts that cryptographic components are imperfect
and may potentially interact badly with each other. Here security
of protocols is proven based on some underlying computational
intractability assumptions (such as the hardness of factoring large
numbers, or computing discrete logarithms modulo a large prime, or
inverting a cryptographic hash function). The formal-methods
approach, being automated, has the advantage that it is less
susceptible to human errors and oversights in analysis. On the
other hand, the cryptographic approach provides better soundness
since it considers the overall security of the protocol, and in
particular accounts for the imperfections of the cryptographic
components.
Our analysis follows the cryptographic approach. We welcome any
additional analysis. In particular, analysis based on formal
methods would be a useful complement to the analysis described
here.
We separate the analysis of the "core security" of the protocol
(which is rather tricky) from the analysis of added security
features such as DoS protection and identity protection (which is
much more straightforward). The rest of this section concentrates
on the "core security" of the protocol. DoS and Identity protection
were discussed in previous sections.
6.1 Core security
We use the modeling and treatment of [CK01], which in turn is based
on [BR93]. See there for more references and comparisons with other
analytical work. Very roughly, the "core security" of a key exchange
protocol boils down to two requirements:
* If party A generates a key Ka associated with a
session-identifier S and peer identity B, and party B generates
a key Kb associated with the same session identifier S and peer
A, then Ka=Kb.
* No attacker can distinguish between the key exchanged in a session
between two unbroken parties and a truly random secret. This holds
even if the attacker has total control over the communication, can
invoke multiple sessions, and is told the keys generated in all
other sessions.
We stress that this is only a rough sketch of the requirement.
For full details see [CK01,CK02]. We show that both JFKi and
JFKr satisfy the above requirement. When these protocols are
run with perfect forward secrecy, the security is based on a
standard intractability assumption of the DH problem. When a
party reuses its DH value, the security is based on a stronger
assumption intractability assumption involving both DH and the
HMAC pseudo random function.
We first analyze the protocols in the restricted case where the
parties do not re-use the private DH exponents for multiple sessions.
(This is the bulk of the work.) Here the techniques for demonstrating
the security of the two protocols are quite different. Specifically:
(I) JFKi: The basic cryptographic core of this protocol is the same as
the ISO 9798-3 protocol, which was analyzed and proven secure
in [CK01]. This protocol can be briefly summarized as follows:
A->B: A,N_a,g^a
B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,A)
A->B: SIG_a(N_a,N_b,g^a,g^b,B)
A salient point about this protocol is that each party signs, in
addition to the nonces and the two public DH exponents, also the
identity of the peer. (If the peer's identity is not signed then
the protocol is completely broken.) JFKi inherits the same basic core
security. In addition, JFKi adds a preliminary cookie mechanism
for DoS protection (which results in adding one flow to the protocol
and having the *responder* in JFKi play the role of A), and encrypts
the last two messages in order to provide identity protection to
the initiator.
(II) JFKr: The basic cryptographic core of this protocols is the
same as that of the signature mode of IKE and SIGMA [K01],
which was analyzed and proven secure in [CK02]. This basic protocol
can be briefly summarized as follows:
A->B: N_a,g^a
B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b),MAC_{Ka}(Na,Nb,B)
A->B: A,SIG_a(N_a,N_b,g^a,g^b),MAC_{Ka}(Na,Nb,A)
Here neither party signs the identity of its peer. Instead, each
party includes a MAC, keyed with a key derived from g^ab, and
applied to its own identity (concatenated with Na and Nb).
JFKr inherits the same basic core security as this protocol.
In addition, JFKr adds a preliminary cookie mechanism
for DoS protection (which results in adding one flow to the
protocol and having the *responder* in JFKr play the role of A),
and encrypts the last two messages in order to provide identity
protection. (Here the identity protection covers both parties,
since the identities are sent only in the last two messages.)
The next step in the analysis is to generalize to the case
where the private DH exponents are re-used across sessions. This
is done by making stronger (but still reasonable) computational
intractability assumptions involving both DH problem and the HMAC
pseudo random function. We defer details to the full analysis paper.
7. IANA Considerations
IANA is asked to assign a UDP port for JFK at the time that this
draft becomes an RFC. Also, the algorithm identifiers will need to
be kept in an IANA registry. These two requests will be described
in more detail in a future version of this draft.
8. Acknowledgments
We would like to thank Paul Hoffman for suppling us with the draft
text in Section 4 (Wire Format), and his constant prodding us in
getting this document done. Ran Atkinson, Matt Crawford, and Eric
Rescorla provided useful comments, and discussions with Hugo
Krawczyk proved very useful. Dan Harkins suggested the inclusion
of IPi in the authenticator.
Appendix A. Protocol JFKi
In the following, "I->R" means a message from the Initiator to the
Responder and "R->I" means the opposite direction.
Message 1, I->R: Ni, g^i, IDr'
Message 2, R->I: Ni, Nr, g^r, GRPINFOr, IDr,
SIG{r}(g^r, GRPINFOr),
HMAC{HKr}(g^r, Nr, Ni, IPi)
Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(g^r, Nr, Ni, IPi),
E{Ke}(IDi, sa, SIG{i}(Ni, Nr, g^i, g^r, IDr, sa))
Message 4, R->I: Ni, Nr,
E{Ke}(SIG{r}(Ni, Nr, g^i, g^r, IDi, sa, sa'), sa')
The key used to protect Messages (3) and (4), Ke, is computed as
HMAC{g^ir}(Ni, Nr, 1). The session key used by IPsec (or any other
application), Kir, is HMAC{g^ir}(Ni, Nr, 0).
If more key material is needed, the same mechanism for "key
stretching" as specified in [IKEv2] may be used.
Message (1) is straightforward; note that it assumes that the
Initiator already knows a group and generator that is acceptable to
the Responder. The Initiator can reuse a g^i value in multiple
instances of the protocol with the Responder or other responders
that accept the same group, for as long as she wishes her forward
secrecy interval to be. We discuss how the Initiator can discover
what groups to use later. This message also contains an indication
as to which ID the Initiator would like the Responder to use to
authenticate. In contrast to JFKr, IDr' is sent in the clear;
however, notice that the responder's ID in Message (2) is also sent
in the clear, so there is no loss of privacy in this respect.
Message (2) is more complex. Assuming that the Responder accepts
the Diffie-Hellman group in the Initiator's message (rejections are
discussed elsewhere in this document), he replies with a signed
copy of his own exponential (in the same group), information on
what secret key algorithms are acceptable for the next message, a
random nonce, his identity (certificates or a bit-string
identifying his public key), and an authenticator calculated from a
secret, HKr, known to the Responder; the authenticator is computed
over the two exponentials and nonces, and the Initiator's network
address. The authenticator key is changed at least as often as
g^r, thus preventing replays of stale data. The Responder's
exponential may also be reused; again, it is regenerated according
to the Responder's forward secrecy interval. The signature on the
exponential needs to be calculated at the same rate as the
Responder's forward secrecy interval (when the exponential itself
changes). Finally, note that the Responder does not need to
generate any state at this point, and the only ``expensive''
operation is a MAC calculation.
Message (3) echoes back the data sent by the Responder, including
the authenticator. The authenticator is used by the Responder to
verify the authenticity of the returned data. The authenticator
also confirms that the sender of Message (3) uses the same address
as in Message (1) --- this can be used to detect and counter a
``cookie jar'' DDoS attack. The message also includes the
Initiator's identity and service request, and a signature computed
over the nonces, the Responder's identity, and the two
exponentials. This latter information is all encrypted under a key
derived from the Diffie-Hellman computation and the nonces Ni and
Nr. The encryption and authentication use algorithms specified in
GRPINFOr. The Responder keeps a copy of recently-received Message
(3)'s, and their corresponding Message (4). Receiving a duplicate
(or replayed) Message (3) causes the Responder to simply retransmit
the corresponding Message (4), without creating new state or
invoking IPsec. This cache of messages can be reset as soon as g^r
or HKr are changed. The Responder's exponential (g^r) is re-sent
by the Initiator because the Responder may be generating a new g^r
for every new JFK protocol run (e.g., if the arrival rate of
requests is below some threshold). Note: It is important that the
responder deals with repeated Message (3)'s as described above.
Responders that create new state for a repeated Message (3) open
the door to attacks against the protocol.
Note that the signature is protected by the encryption. This is
necessary, since everything signed is public except the sa, and
that is often guessable. An attacker could verify guesses at
identities, were it not encrypted.
Message (4) contains application-specific information (such as the
Responder's IPsec SPI), and a signature on both nonces, both
exponentials, and the Initiator's identity. Everything is encrypted
by Ke, which is derived from Ni, Nr, and g^ir (the result of the
Diffie-Hellman computation).
Appendix B. Avoiding Fragmentation-based DoS Attacks
Since Message (3) contains certificates, it may be larger than the
MTU and thus require fragmentation (with most common certificate
formats, this will be the case only if there are more than 2
certificates included in the payload). Thus, it is possible for an
attacker to send partial fragments of a Message (3) packet in an
attempt to saturate the Responder's reassembly queue and thus deny
service to legitimate Initiators. Similar considerations hold for
Message (4).
To avoid this, we propose that the following mechanism be used by
the underlying operating system:
- The operating system periodically selects a secret value (16 bits
for IPv4, 32 bits for IPv6). This value is also provided to the
JFK implementation.
- The operating system also maintains two reassembly queues: one
for fragments that contain the correct cookie in the ip_id field
(for IPv4 packets) or the ip6f_ident field (for IPv6 packets, in
the fragmentation header). Both queues are of fixed size. While
the privileged queue may be larger (to accomodate higher traffic
volumes), this is not strictly necessary.
- The cookie is encoded in the first 16 (or 32) bits of the Nonce
of the appropriate party (Ni or Nr). These should be copied
verbatim (i.e., without any byte-swapping etc.) to the
appropriate field in the IPv4 header or the IPv6 fragmentation
header.
- The cookie is computed by applying a hash function on the peer's
IP address and the host secret, then taking the first 16 or 32
bits. Both the operating system and the JFK implementation can
perform this computation. The actual algorithm used to compute
the cookie is left up to the implementation; a fast keyed hash or
equivalent algorithm should be used.
Notice that if multiple retransmissions of the same packet are
performed, all fragments of all instances of the same packet will
have the same identification number (whereas they are supposed to
have different values). Since, however, no field of Message (3) or
(4) changes between retransmissions, this poses no problem even if
the sender's network stack fragments the packets in different
ways.
Finally, notice that no changes are required on the protocol, and
the Initiator's and Responder's operating systems may or may not
implement this functionality independently, without affecting
interoperability.
References:
[BDJR97] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of
Symmetric Encryption: Analysis of the DES Modes of Operation",
1997, http://www-cse.ucsd.edu/users/mihir/.
[BR93] Bellare and Rogaway, "Entity authentication and key
distribution", Crypto '93. Available at
http://www-cse.ucsd.edu/users/mihir.
[CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols
and Their Use for Building Secure Channels", Eurocrypt 01.
Available at http://eprint.iacr.org/2001/040.
[CK02] Canetti and Krawczyk, "Security Analysis of IKE's Signature-
based Key-Exchange Protocol", manuscript, 2002.
[IKEv2] Harkins, Kaufman, Kent, Kivinen, Perlman, "Proposal for
the IKEv2 Protocol", draft-ietf-ipsec-ikev2-01.txt.
February 2002. Work in Progress.
[K01] Krawczyk, "The IKE-SIGMA Protocol". Available at
http://tiger.technion.ac.il/~hugo/
draft-krawczyk-ipsec-ike-sigma-00.txt. Nov 2001. Work
in progress.
[RFC2104] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
Message Authentication. RFC 2104. February 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2522] Karn, Simpson, "Photuris: Session-Key Management Protocol",
RFC 2522, March 1999.
Authors' addresses:
The authors as a group can be reached by email at jfk@crypto.com
William Aiello
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0971
Email: aiello@research.att.com
Steven M. Bellovin
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0971
Email: smb@research.att.com
Matt Blaze
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0971
Email: mab@research.att.com
Ran Canetti
IBM T.J. Watson Research Center
30 Saw Mill Rover Road
Hawthorne, New York 10532
Email: canetti@watson.ibm.com
John Ioannidis
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0971
Email: ji@research.att.com
Angelos D. Keromytis
Columbia University, CS Department
515 CS Building
1214 Amsterdam Avenue, Mailstop 0401
New York, New York 10027-7003
Phone: +1 212 939 7095
Email: angelos@cs.columbia.edu
Omer Reingold
AT&T Labs - Research
180 Park Avenue
Florham Park, New Jersey 07932-0971
Email: omer@research.att.com
Expiration and File Name
This draft expires in September 2002
Its file name is draft-ietf-ipsec-jfk-04.txt
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/