Efficient, DoS-resistant, secure key exchange for internet protocols.
We describe JFK, a new key exchange protocol, primarily designed for use in the IP Security Architecture. It is simple, efficient, and secure; we sketch a proof of the latter property. JFK also has a number of novel engineering parameters that permit a variety of trade-offs, most notably the ability to balance the need for perfect forward secrecy against susceptibility to denial-of-service attacks.
Simplicity: The resulting protocol must be as simple as possible,
within the constraints of the requirements.
The Security requirement is obvious enough (we use the security
model of [7, 8]). The rest, however, require some discussion.
The PFS property is perhaps the most controversial. (PFS is
an attribute of encrypted communications allowing for a long-term
key to be compromised without affecting the security of past session
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 ef?ciency or resistance to denial-of-service
attacks. In fact, this corresponds quite nicely to the reality of to-
day's Internet systems, where a compromise during the existence
of a security association will reveal the plaintext of any ongoing
transmissions. Our protocol has a forward secrecy interval; security
associations are protected against compromises that occur outside
of that interval. Speci?cally, we allow a party to reuse the same
secret Dif?e-Hellman exponents for multiple exchanges within a
time period; this may save a large number of costly modular
exponentiations.
The Privacy property means that the protocol must not reveal
the identity of a participant to any unauthorized party, including an
active attacker that attempts to act as the peer. Clearly, it is not
possible for a protocol to protect both the initator and the responder
against an active attacker; one of the participants must always
?go ?rst.? In general, we believe that the most appropriate choice
is to protect the initator, since the initator is typically a relatively
anonymous ?client,? while the responder's identity may already be
known. Conversely, protecting the responder's privacy may not be
of much value (except perhaps in peer-to-peer communication): in
many cases, the responder is a server with a ?xed address or characteristics
(e.g., well-known web server). One approach is to allow
for a protocol that allows the two parties to negotiate who needs
identity protection. In JFK, we decided against this
is unclear what, if any, metric can be used to determine which
party should receive identity protection; furthermore, this negotiation
could act as a loophole to make initiators reveal their identity
?rst. Instead, we propose two alternative protocols: one that protects
the initator against an active attack, and another that protects
the responder.
The Memory-DoS and Computation-DoS properties have become
more important in the context of recent Internet denial-of-service
attacks. Photuris[24] was the ?rst published key management protocol
for which DoS-resistance was a design consideration; we suggest
that these properties are at least as important today.
The Ef?ciency property is worth discussing. In many proto-
cols, key setup must be performed frequently enough that it can
become a bottleneck to communication. The key exchange protocol
must minimize computation as well total bandwidth and round
trips. Round trips can be an especially important factor when communicating
over unreliable media. Using our protocols, only two
round-trips are needed to set up a working security association.
This is a considerable saving in comparison with existing proto-
cols, such as IKE.
The Non-Negotiated property is necessary for several reasons.
Negotiations create complexity and round trips, and hence should
be avoided. Denial of service resistance is also relevant here; a
partially-negotiated security association consumes resources.
The Simplicity property is motivated by several factors. Ef?-
ciency is one; increased likelihood of correctness is another. But
our motivation is especially colored by our experience with IKE.
Even if the protocol is de?ned correctly, it must be implemented
correctly; as protocols become more complex, implementation and
interoperability errors occur more often. This hinders both security
and interoperability. Our design follows the traditional design
paradigm of successful internetworking protocols: keep individual
building blocks as simple as possible; avoid large, complex, monolithic
protocols. We have consciously chosen to omit support for
certain features when we felt that adding such support would cause
an increase in complexity that was disproportional to the bene?t
gained.
Protocol design is, to some extent, an engineering activity, and
we need to provide for trade-offs between different types of secu-
rity. There are trade-offs that we made during the protocol design,
and others, such as that between forward secrecy and computational
effort, that are left to the implementation and to the user, e.g., selected
as parameters during con?guration and session negotiation.
2. PROTOCOL DEFINITION
We present two variants of the JFK protocol. Both variants take
two round-trips (i.e., four messages) and both provide the same
level of DoS protection. The ?rst variant, denoted JFKi, provides
identity protection for the initiator even against active attacks. The
identity of the responder is not protected. This type of protection
is appropriate for a client-server scenario where the initiator (the
client) may wish to protect its identity, whereas the identity of the
responder (the server) is public. As discussed in Section 4, this
protocol uses the basic design of the ISO 9798-3 key exchange
protocol [20, 7], with modi?cations that guarantee the properties
discussed in the Introduction.
The second variant, JFKr, provides identity protection for the
responder against active adversaries. Furthermore, it protects both
sides' identities against passive eavesdroppers. This type of protection
is appropriate for a peer-to-peer scenario where the responder
may wish to protect its identity. Note that it is considerably easier
to mount active identity-probing attacks against the responder
than against the initiator. Furthermore, JFKr provides repudiability
on the key exchange, since neither side can prove to a third party
that their peer in fact participated in the protocol exchange with
them. (In contrast, JFKi authentication is non-repudiable, since
each party signs the other's identity along with session-speci?c information
such as the nonces). This protocol uses the basic design
of the Sign-and-MAC (SIGMA) protocol from [28], again with the
appropriate modi?cations.
2.1 Notation
First, some notation:
Hk(M) Keyed hash (e.g., HMAC[29]) of message M using key
k. We assume that H is a pseudorandom function. This
also implies that H is a secure message authentication
In some places we make a somewhat
stronger assumption relating H and discrete logarithms;
see more details within.
fMgKea Encryption using symmetric key Ke, followed by MAC
authentication with symmetric key Ka of message M.
The MAC is computed over the ciphertext, pre?xed with
the literal ASCII string "I" or "R", depending on who
the message sender is (initiator or responder).
Digital signature of message M with the private key belonging
to principal x (initiator or responder). It is assumed
to be a non-message-recovering signature.
The message components used in JFK are:
IPI Initiator's network address.
gx Dif?e-Hellman (DH) exponentials; also identifying the
group-ID.
Initiator's current exponential, (mod p).
gr Responder's current exponential, (mod p).
NI Initiator nonce, a random bit-string.
NR Responder nonce, a random bit-string.
IDI Initiator's certi?cates or public-key identifying information

IDR Responder's certi?cates or public-key identifying information

IDR0 An indication by the initiator to the responder as to what
authentication information (e.g., certi?cates) the latter
should use.
HKr A transient hash key private to the responder.
sa Cryptographic and service properties of the security association
(SA) that the initiator wants to establish. It
contains a Domain-of-Interpretation which JFK under-
stands, and an application-speci?c bit-string.
sa0 SA information the responder may need to give to the
initiator (e.g., the responder's SPI, in IPsec).
Kir Shared key derived from gir, NI , and NR used for protecting
the application (e.g., the IPsec SA).
Ke;Ka Shared keys derived from gir, NI , and NR, used to encrypt
and authenticate Messages (3) and (4) of the protocol

grpinfo All groups supported by the responder, the symmetric
R
algorithms used to protect Messages (3) and (4), and the
hash function used for key generation.
Both parties 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 their DH
exponential; the session key will be different between independent
runs of the protocol, as long as one of the nonces or exponentials
changes. HKR is a global parameter for the responder ? it stays
the same between protocol runs, but can change periodically.
2.2 The JFKi Protocol
The JFKi protocol consists of four messages (two round trips):
I
I
HHKR (gr;NR;NI ;IPI );
The keys used to protect Messages (3) and (4), Ke and Ka, are
computed as Hgir (NI ;NR; "1") and Hgir (NI ;NR; "2") respec-
tively. The session key passed to IPsec (or some other application),
Kir,isHgir (NI ;NR; "0"). (Note that there may be a difference
in the number of bits from the HMAC and the number produced by
the raw Dif?e-Hellman exchange; the 512 least-signi?cant bits are
of gir are used as the key in that case). If the key used by IPsec is
longer than the output of the HMAC, the key extension method of
IKE is used to generate more keying material.
Message (1) is straightforward; note that it assumes that the initiator
already knows a group and generator that are acceptable to
the responder. The initiator can reuse a gi 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 in a later section. This message also contains an indication
as to which ID the initiator would like the responder to use
to authenticate. IDR0 is sent in the clear; however, the responder's
ID in Message (2) is also sent in the clear, so there is no loss of
privacy.
Message (2) is more complex. Assuming that the responder accepts
the Dif?e-Hellman group in the initiator's message (rejections
are discussed in Section 2.5), he replies with a signed copy of his
own exponential (in the same group, also (mod p)), information
on what secret key algorithms are acceptable for the next message,
a random nonce, his identity (certi?cates or a string identifying his
public key), and an authenticator calculated from a secret, HKR,
known to the responder; the authenticator is computed over the re-
sponder's 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 inter-
val. 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 cryptographic
operation is a MAC calculation. If the responder is not under heavy
load, or if PFS is deemed important, the responder may generate
a new exponential and corresponding signature for use in this ex-
change; of course, this would require keeping some state (the secret
part of the responder's Dif?e-Hellman computation).
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 con?rms that the sender of the Message (3) used the
same address as in Message (1) ? this can be used to detect and
counter a ?cookie jar? DoS attack1. A valid authenticator indicates
to the responder that a roundtrip has been completed (between Messages
(1), (2), and (3)). 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 and authenticated under keys Ke
and Ka, as already described. The encryption and authentication
use algorithms speci?ed in grpinfo . The responder keeps a copy
R
of recently-received Messages (3), 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 HKR is changed. The responder's
exponential (gr) is re-sent by the initiator because the responder
may be generating a new gr for every new JFK protocol run (e.g.,
if the arrival rate of requests is below some threshold). It is important
that the responder deal with repeated Messages (3) as described
above. Responders that create new state for a repeated Message (3)
open the door to attacks against the protocol and/or underlying application
(IPsec).
Note that the signature is protected by the encryption. This is
necessary for identity protection, since everything signed is public
except the sa, and that is often guessable. An attacker could verify
guesses at identities if the signature were not encrypted.
Message (4) contains application-speci?c information (such as
the responder's IPsec SPI), and a signature on both nonces, both
exponentials, and the initiator's identity. Everything is encrypted
and authenticated by the same Ke and Ka used in Message (3),
which are derived from NI , NR, and gir. The encryption and authentication
algorithms are speci?ed in grpinfo .
R
2.3 Discussion
The design follows from our requirements. With respect to communication
ef?ciency, 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 initia-
1The ?cookie jar? DoS attack involves an attacker that is willing
to reveal the address of one subverted host so as to acquire a valid
cookie (or number of cookies) that can then be used by a large
number of other subverted hosts to launch a DDoS attack using the
valid cookie(s).
tor bears the initial computational burden and 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 limit the private information revealed by the initia-
she does not reveal her identity until she is sure that only the
responder can retrieve it. (An active attacker can replay an old
Message (2) as a response to the initiator's initial message, but he
cannot retrieve the initiator's identity from Message (3) because he
cannot complete the Dif?e-Hellman computation).
The initiator's ?rst message, Message (1), is a straightforward
Dif?e-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: ?rst, it allows 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 (in any case, we
assume that the underlying transport protocol, i.e., UDP, can handle
the demultiplexing by using different ports at the initiator).
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 a denial of service at-
tack; 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.
The responder may compute a new exponential gb (mod p) 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. One case when
both sides may reuse the same exponentials is when the initiator is
a low-power device (e.g., a cellphone) and the responder is a busy
server.
A simple way of addressing DoS is to periodically (e.g., once every
seconds) generate an (r; gr;HHKR (gr);SR[gr]) tuple and
place it in a FIFO queue. As requests arrive (in particular, as valid
Messages (3) are processed), the ?rst entry from the FIFO is re-
moved; thus, as long as valid requests arrive at under the generation
rate, PFS is provided for all exchanges. If the rate of valid protocol
requests exceeds the generating rate, a JFK implementation should
reuse the last tuple in the FIFO. Notice that in this scheme, the same
gr may be reused in different sessions, if these sessions are inter-
leaved. This does not violate the PFS or other security properties
of the protocol.
If the responder is willing to accept the group identi?ed in the
initiator's message, his exponential must be in the same group. Oth-
erwise, he may respond with an exponential from any group of his
own choosing. The ?eld grpinfo lists what groups the responder
R
?nds acceptable, if the initiator should wish to restart the proto-
col. This provides a simple mechanism for the initiator to discover
the groups currently allowed by the responder. That ?eld also lists
what encryption and MAC algorithms are acceptable for the next
two messages. 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 mes-
sage. If it is fraudulent, 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. The initiator 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.
Because the initiator can validate the responder's identity before
sending her own and because her identifying information (ignoring
her public key signature) is sent encrypted, her privacy is protected
from both passive and active attackers. An active attacker can replay
an old Message (2) as a response to the initiator's initial mes-
sage, but he cannot retrieve the initiator's identity from Message (3)
because he cannot complete the Dif?e-Hellman computation. The
service request is encrypted, too, since its disclosure might identify
the requester. The responder may wish to require a certain strength
of cryptographic algorithm for selected services.
Upon successful receipt and veri?cation of this message, 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 cer-
ti?cate chain. The authenticator (again requiring two hash opera-
tions) is suf?cient 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 Messages (3) in the cache is the authenticator;
this prevents DoS attacks where the attacker randomly modi?es 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
veri?es but there is some problem with the message (e.g., the
certi?cates 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 Messages (3) and authenticators can be
purged as soon as HKR is changed (since the authenticator will no
longer pass veri?cation).
Caching Message (3) and refraining from creating new state for
replayed instances of Message (3) also serves another security pur-
pose. If the responder were to create a new state and send a new
Message (4), and a new sa0 for a replayed Message (3), then an attacker
who 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
would be 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, in keeping this message cached for too
long: if the responder's machine is compromised during this pe-
riod, 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-
speci?c application data (e.g., the responder's IPsec SPI), along
with a signature on both nonces, both exponentials, and the ini-
tiator's identity. All the information is encrypted and authenticated
using keys derived from the two nonces, NI and NR, and
the Dif?e-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 The JFKr Protocol
Using the same notation as in JFKi, the JFKr protocol is:
I
I
As in JFKi, the keys used to protect Messages (3) and (4), Ke
and Ka, are respectively computed as Hgir (NI ;NR; "1") and
Hgir (NI ;NR; "2"). The session key passed to IPsec (or some
other application), Kir,isHgir (NI ;NR; "0").
Both parties send their identities encrypted and authenticated under
Ke and Ka respectively, providing both parties with identity
protection against passive eavesdroppers. In addition, the party that
?rst reveals its identity is the initiator. This way, the responder is
required to reveal its identity only after it veri?es the identity of the
initiator. This guarantees active identity protection to the responder.
We remark that it is essentially impossible, under current technology
assumptions, to have 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 ?rst 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 his identity in the second
message, without compromising his identity protection against passive
eavesdroppers. This means that the responder's identity must
be sent in the fourth (and last) message of the protocol. Conse-
quently, the initiator's identity must be sent before the responder's
identity is sent.
2.5 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
?eld grpinfo (which indicates what groups are acceptable), no explicit
rejection message is needed. (For ef?ciency's sake, the group
information could also be in the responder's long-lived certi?cate,
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 (initia-
tor), 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 anew; again, the responder does not create any state until after
a successful Message (3) receipt.
3. WHAT JFK AVOIDS
By intent, JFK does not do certain things. It is worth enumerating
them, if only to stimulate discussion about whether certain
protocol features are ever appropriate. In JFK, the ?missing? features
were omitted by design, in the interests of simplicity.
3.1 Multiple Authentication Options
The most obvious ?omission? is any form of authentication other
than by certi?cate chains trusted by the each party. We make no
provisions for shared secrets, token-based authentication, certi?-
cate discovery, or explicit cross-certi?cation of PKIs. In our view,
these are best accomplished by outboard protocols. Initiators that
wish to rely on any form of legacy authentication can use the protocols
being de?ned by the IPSRA[41] or SACRED[1, 14] IETF
working groups. While these mechanisms do add extra round trips,
the expense can be amortized across many JFK negotiations. Sim-
ilarly, certi?cate chain discovery (beyond the minimal capabilities
implicit in IDI and IDR) should be accomplished by protocols de-
?ned for that purpose. By excluding the protocols from JFK, we
can exclude them from our security analysis; the only interface between
the two is a certi?cate chain, which by de?nition is a stand-alone
secure object.
We also eliminate negotiation generally, 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
the need that state be kept by the responder; the initiator can either
accept the responder's desires or restart the protocol.
3.2 Phase II and Lack Thereof
JFK rejects the notion of two different phases. As will be discussed
in Section 5, the practical bene?ts of quick mode are limited.
Furthermore, we do not agree that frequent rekeying is necessary.
If the underlying block cipher is suf?ciently 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 encryption of 232 plaintext blocks. Using
AES instead of 3DES solves that problem without complicating the
exchange.
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.
We also feel that JFK is ef?cient enough that avoiding the overhead
of a full key exchange is not required. Rather than adding 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 Dif?e-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.3, a similar performance
optimization can be used on the certi?cate-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. Ours
requires that JFK endpoints implement the following rule: a new
negotiation that speci?es 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; simply negotiate a
new SA. To delete an SA without replacing it, negotiate a new SA
with a null ciphersuite.
3.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
traf?c, but would still accept traf?c 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 veri?cation operation in each direction, if both parties use the
same Dif?e-Hellman exponentials (in which case, the cached result
can be reused) and certi?cates: 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 certi?cate chain. A previously
veri?ed certi?cate chain is considered valid for the shortest
of its CRL re-validate time, certi?cate expiration time, OCSP result
validity time, etc. For each certi?cate 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
not 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 should be done by a separate protocol.
4. TOWARDS A PROOF OF SECURITY
This section very brie?y overviews our security analysis of the
JFK protocol. Full details are deferred to the full analysis paper.
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-veri?cation 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 fact
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, 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.
4.1 Core security
We use the modeling and treatment of [7], which in turn is based
on [6]; 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:
1. If party A generates a key KA associated with a session-
identi?er s and peer identity B, and party B generates a key
KB associated with the same session identi?er s and peer A,
then
2. No attacker can distinguish between the key exchanged in
a session between two unbroken parties and a truly random
value. 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 [7, 8]. 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, plus the security of
the signature scheme and the security of MAC as a pseudo-random
function. When a party reuses its DH value, the security is based
on a stronger intractability assumption involving both DH and the
HMAC pseudo-random function.
We ?rst analyze the protocols in the restricted case where the
parties do not reuse 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.
4.1.1 JFKi:
The basic cryptographic core of this protocol is the same as the
ISO 9798-3 protocol, which was analyzed and proven secure in [7].
This protocol can be brie?y summarized as follows:
A salient point about this protocol is that each party signs, in addition
to the nonces and the two public DH exponents, 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 ?ow 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 for the initiator.
Finally, we note that JFKi enjoys the following additional prop-
erty. Whenever a party P completes a JFKi exchange with peer
Q, it is guaranteed that Q has initiated an exchange with P and is
aware of P's existence. This property is not essential in the context
of IPsec (indeed, JFKr does not enjoy this property). Nonetheless,
it may be of use in other contexts.
4.1.2 JFKr:
The basic cryptographic core of this protocol follows the design
of the SIGMA protocol [28] (which also serves as the basis to the
signature mode of IKE). SIGMA was analyzed and proven secure
in [8]. This basic protocol can be brie?y summarized as follows:
HKa (NA;NB;B)
Here, neither party signs the identity of its peer. Instead, each
party includes a MAC, keyed with a key derived from gab, and applied
to its own identity (concatenated with NA and NB). JFKr enjoys
the same basic core security as this protocol. In addition, JFKr
adds a preliminary cookie mechanism for DoS protection (which
results in adding one ?ow 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. The identity protection against
passive adversaries 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 reused across sessions. This is done
by making stronger (but still reasonable) computational intractability
assumptions involving both the DH problem and the HMAC
pseudo-random function. We defer details to the full analysis paper

5. RELATED WORK
The basis for most key agreement protocols based on public-key
signatures has been the Station to Station (StS)[11] protocol. In its
simplest form, shown in Figure 1, this consists of a Dif?e-Hellman
exchange, followed by a public key signature authentication step,
typically using the RSA algorithm in conjunction with some certi?-
cate scheme such as X.509. In most implementations, the second
message is used to piggy-back the responder's authentication infor-
mation, resulting in a 3-message protocol, shown in Figure 2. Other
forms of authentication may be used instead of public key signatures
(e.g., Kerberos[37] tickets, or preshared secrets), but these
are typically applicable in more constrained environments. While
the short version of the protocol has been proven to be the most
ef?cient[13] in terms of messages and computation, it suffers from
some obvious DoS vulnerabilities.
5.1 Internet Key Exchange (IKE)
The Internet Key Exchange protocol (IKE)[15] is the current
IETF standard for key establishment and SA parameter negotiation.
initiator responder
Initiator Diffie-Hellman public value
Responder Diffie-Hell an public value
Initiator RSA signature and certificate(s)
Responder RSA signature and certificate(s)

Figure

1: 4-message Station to Station key agreement protocol.
IKE is based on the ISAKMP [33] framework, which provides encoding
and processing rules for a set of payloads commonly used
by security protocols, and the Oakley protocol, which describes an
adaptation of the StS protocol for use with IPsec.2 The public-key
encryption modes of IKE are based on SKEME [27].
IKE is a two-phase protocol: during the ?rst phase, a secure
channel between the two key management daemons is established.
Parameters such as an authentication method, encryption/hash al-
gorithms, and a Dif?e-Hellman group are negotiated at this point.
This set of parameters is called a ?Phase I SA.? Using this infor-
mation, the peers authenticate each other and compute key material
using the Dif?e-Hellman algorithm. Authentication can be
based on public key signatures, public key encryption, or preshared
passphrases. There are efforts to extend this to support Kerberos
tickets[37] and handheld authenticators. It should also be noted
that IKE can support other key establishment mechanisms (besides
Dif?e-Hellman), although none has been proposed yet.3
Furthermore, there are two variations of the Phase I message ex-
change, called ?main mode? and ?aggressive mode.? Main mode
provides identity protection, by transmitting the identities of the
peers encrypted, at the cost of three message round-trips (see Figure
3). Aggressive mode provides somewhat weaker guarantees,
but requires only three messages (see Figure 4).
As a result, aggressive mode is very susceptible to untraceable4
denial of service (DoS) attacks against both computational and memory
Main mode is also susceptible to untraceable
memory exhaustion DoS attacks, which must be compensated for
in the implementation using heuristics for detection and avoidance.
To wit:
2We remark, however, that the actual cryptographic core of IKE's
signature mode is somewhat different than Oakley. In Oakley the
peer authentication is guaranteed by having each party explicitly
sign the peer identity. In contrast, IKE guarantees peer authentication
by having each party MAC its own identity using a key derived
from the agreed Dif?e-Hellman secret. This method of peer
authentication is based on the Sign-and-Mac design [28].
3There is ongoing work (still in its early stages) in the IETF to
use IKE as a transport mechanism for Kerberos tickets, for use in
protecting IPsec traf?c.
4The attacker can use a forged address when sending the ?rst message
in the exchange.
initiator responder
Initiator Diffie-Hellman public value
Responder Diffie-Hell anadn cpeurbtilficicvatael(use)
Responder RSA signature
Initiator RSA signature and certificate(s)

Figure

2: 3-message Station to Station key agreement protocol.
The responder has to create state upon receiving the ?rst message
from the initiator, since the Phase I SA information is
exchanged at that point. This allows for a DoS attack on the
responder's memory, using random source-IP addresses to
send a ?ood of requests. To counter this, the responder could
employ mechanisms similar to those employed in countering
maintains no state at all
after receiving the ?rst message.
An initiator who is willing to go through the ?rst message
round-trip (and thus identify her address) can cause the responder
to do a Dif?e-Hellman exponential generation as
well as the secret key computation on reception of the third
message of the protocol. The initiator could do the same with
the ?fth message of the protocol, by including a large number
of bogus certi?cates, if the responder blindly veri?es all
signatures. JFK mitigates the effects of this attack by reusing
the same exponential across different sessions.
The second phase of the IKE protocol is commonly called ?quick
mode? and results in IPsec SAs being established between the two
negotiating parties, through a three-message exchange. Parameters
such as the IP security protocol to use (ESP/AH), security algo-
rithms, the type of traf?c that will be protected, etc. are negotiated
at this stage. Since the two parties have authenticated each other
and established a shared key during Phase I, quick mode messages
are encrypted and authenticated using that information. Further-
more, it is possible to derive the IPsec SA keying material from
the shared key established during the Phase I Dif?e-Hellman ex-
change. To the extent that multiple IPsec SAs between the same
two hosts are needed, this two-phase approach results in faster and
more lightweight negotiations (since the same authentication information
and keying material is reused).
Unfortunately, two hosts typically establish SAs protecting all
the traf?c between them, limiting the bene?ts of the two-phase
protocol to lightweight re-keying. If PFS is desired, this bene?t
is further diluted.
Another problem of the two-phase nature of IKE manifests itself
when IPsec is used for ?ne-grained access control to network
services. In such a mode, credentials exchanged in the IKE protocol
are used to authorize users when connecting to speci?c ser-
vices. Here, a complete Phase I & II exchange will have to be done
for each connection (or, more generally, traf?c class) to be pro-
initiator responder
Initiator cookie, proposed phase1 SA
Responder cookie, accepted Phase1 SA
Initiator Diffie-Hellman value & Nonce
Responder Diffie-Hellman value & Nonce
Initiator signature, certs & identity
Responder signature, certs & identity

Figure

3: IKE Main Mode exchange with certi?cates.
tected, since credentials, such as public key certi?cates, are only
exchanged during Phase I.
IKE protects the identities of the initiator and responder from
eavesdroppers.5 The identities include public keys, certi?cates, and
other information that would allow an eavesdropper to determine
which principals are trying to communicate. These identities can
be independent of the IP addresses of the IKE daemons that are
negotiating (e.g., temporary addresses acquired via DHCP, public
workstations with smartcard dongles, etc. However, since the initiator
her identity ?rst (in message 5 of Main Mode), an
attacker can pose as the responder until that point in the protocol.
The attackers cannot complete the protocol (since they do not possess
the responder's private key), but they can determine the initia-
tor's identity. This attack is not possible on the responder, since she
can verify the identity of the initiator before revealing her identity
(in message 6 of Main Mode). However, since most responders
would correspond to servers (?rewalls, web servers, etc.), the identity
protection provided to them seems not as useful as protecting
the initiator's identity.6 Fixing the protocol to provide identity protection
for the initiator would involve reducing it to 5 messages and
having the responder send the contents of message 6 in message 4,
with the positive side-effect of reducing the number of messages,
but breaking the message symmetry and protocol modularity.
Finally, thanks to the desire to support multiple authentication
mechanisms and different modes of operation (Aggressive vs. Main
mode, Phase I / II distinction), both the protocol speci?cation and
the implementations tend to be bulky and fairly complicated. These
are undesirable properties for a critical component of the IPsec architecture

Several works (including [12, 26, 25]) point out many de?cien-
cies in the IKE protocol, speci?cation, and common implemen-
5Identity protection is provided only in Main Mode (also known
as Protection Mode); Aggressive Mode does not provide
identity protection for the initiator.
6One case where protecting the responder's identity can be more
useful is in peer-to-peer scenarios.
initiator responder
Initiator cookie, proposed Phase 1 SA
m Diffie-Hell an value &
Responder cookie, accepted PhaIsde1nStiAty
Responder Diffie-Hell anavnadluceertificate(s)
Responder signature
Initiator signature and certificate(s)

Figure

4: IKE Aggressive Mode exchange with certi?cates.
tations. They suggest removing several features of the protocol
(e.g., aggressive mode, public key encryption mode, etc.), restore
the idea of stateless cookies, and protect the initiator's (instead of
the responder's) identity from an active attacker. They also suggest
some other features, such as one-way authentication (similar
to what is common practice when using SSL/TLS[10] on the web).
These major modi?cations would bring the IKE protocol closer to
JFK, although they would not completely address the DoS issues.
A measure of the complexity of IKE can be found in the analyses
done in [34, 36]. No less than 13 different sub-protocols are iden-
ti?ed in IKE, making understanding, implementation, and analysis
of IKE challenging. While the analysis did not reveal any attacks
that would compromise the security of the protocol, it did identify
various potential attacks (DoS and otherwise) that are possible under
some valid interpretations of the speci?cation and implementation
decisions.
Some work has been done towards addressing, or at least ex-
amining, the DoS problems found in IKE[31, 32] and, more gener-
ally, in public key authentication protocols[30, 21]. Various recommendations
on protocol design include use of client puzzles[23, 3],
stateless cookies[39], forcing clients to store server state, rearranging
the order of computations in a protocol[18], and the use of a
formal method framework for analyzing the properties of protocols
with respect to DoS attacks[35]. The advantages of being state-
less, at least in the beginning of a protocol run, were recognized in
the security protocol context in [22] and [2]. The latter presented
a 3-message version of IKE, similar to JFK, that did not provide
the same level of DoS protection as JFK does, and had no identity
protection.
5.2 IKEv2
IKEv2[16] is another proposal for replacing the original IKE
protocol. The cryptographic core of the protocol, as shown in Figure
5, is very similar to JFKr. The main differences between IKEv2
and JFKr are:
IKEv2 implements DoS protection by optionally allowing
the responder to respond to a Message (1) with a cookie,
which the sender has to include in a new Message (1). Under
normal conditions, the exchange would consist of the 4 messages
shown; however, if the responder detects a DoS attack,
it can start requiring the extra roundtrip. One claimed bene?t
of this extra roundtrip is the ability to avoid memory-based
initiator responder
Initiator Kcoeoykinieg aterial, Phase I SA,
aterial, Phase 1 SA,
Responder Keying
Responder cookie
Initiator authentication
Phase II SA, Traffic Selaencdtocres,rtIidfiecnatieti(ess)
Responder authentication andracfefrictifSicealetec(tso)rs
Accepted Phase II SA and T

Figure

5: IKEv2 protocol exchange.
DoS attacks against the fragmentation/reassembly part of the
networking stack. (Brie?y, the idea behind such an attack is
that an attacker can send many incomplete fragments that ?ll
out the reassembly queue of the responder, denying service
to other legitimate initiators. In IKEv2, because the ?large?
messages are the last two in the exchange, it is possible for
the implementation to instruct the operating system to place
fragments received from peers that completed a roundtrip to
a separate, reserved reassembly queue.)
IKEv2 supports a Phase II exchange, similar to the Phase
I/Phase II separation in the original IKE protocol. It supports
creating subsequent IPsec SAs with a single roundtrip,
as well as SA-teardown using this Phase II.
IKEv2 proposals contain multiple options that can be combined
in arbitrary ways; JFK, in contrast, takes the approach
of using ciphersuites, similar to the SSL/TLS protocols[10].
IKEv2 supports legacy authentication mechanisms (in par-
ticular, pre-shared keys). JFK does not, by design, support
other authentication mechanisms, as discussed in Section 3;
while it is easy to do so (and we have a variant of JFKr that
can do this without loss of security), we feel that the added
value compared to the incurred complexity does not justify
the inclusion of this feature in JFK.
Apart from these main differences, there are a number of super?-
cial ones (e.g., the ?wire? format) which are more a matter of taste
than of difference in protocol design philosophy. The authors of
the two proposals have helped create a joint draft[19], submitted
to the IETF IPsec Working Group. In that draft, a set of design
options re?ecting the differences in the two protocols is presented
to the working group. Concurrent with the writing of this paper,
and based on this draft, a uni?ed proposal is being written. This
uni?ed proposal combines properties from both JFK and IKEv2. It
adopts the approach of setting up a security association within two
round trips, while providing DoS protection for the responder (and,
in particular, allowing the responder to be almost completely state-less
between the sending of message 2 and the receipt of message
5.3 Other Protocols
The predecessor to IKE, Photuris[24], ?rst introduced the concept
of cookies to counter ?blind? denial of service attacks. The
protocol itself is a 6-message variation of the Station to Station
protocol. It is similar to IKE in the message layout and purpose,
except that the SA information has been moved to the third mes-
sage. For re-keying, a two-message exchange can be used to request
a uni-directional SPI (thus, to completely re-key, 4 messages
are needed). Photuris is vulnerable to the same computation-based
DoS attack as IKE, mentioned above. Nonetheless, one of the variants
of this protocol has 4 messages and provided DoS protection
via stateless cookies.
SKEME[27] shares many of the requirements for JFK, and many
aspects of its design were adopted in IKE. It serves more as a set of
protocol building blocks, rather than a speci?c protocol instance.
Depending on the speci?c requirements for the key management
protocol, these blocks could be combined in several ways. An interesting
aspect of SKEME is its avoidance of digital signatures;
public key encryption is used instead, to provide authentication as-
surances. The reason behind this was to allow both parties of the
protocol to be able to repudiate the exchange.
SKIP[5] was an early proposal for an IPsec key management
mechanism. It uses long-term Dif?e-Hellman public keys to derive
long-term shared keys between parties, which is used to distribute
session keys between the two parties. The distribution of the session
occurs in-band, i.e., the session key is encrypted with the
long-term key and is injected in the encrypted packet header. While
this scheme has good synchronization properties in terms of re-
keying, the base version lacks any provision for PFS. It was later
provided via an extension [4]. However, as the authors admit, this
extension detracts from the original properties of SKIP. Further-
more, there is no identity protection provided, since the certi?cates
used to verify the Dif?e-Hellman public keys are (by design) publicly
available, and the source/destination master identities are contained
in each packet (so that a receiver can retrieve the sender's
Dif?e-Hellman certi?cate). The latter can be used to mount a DoS
attack on a receiver, by forcing them to retrieve and verify a Dif?e-
Hellman certi?cate, and then compute the Dif?e-Hellman shared
secret.
The Host uses cryptographic public
keys as the host identi?ers, and introduces a set of protocols for establishing
SAs for use in IPsec. The HIP protocol is a four-packet
exchange, and uses client puzzles to limit the number of sessions
an attacker can initiate. HIP also allows for reuse of the Dif?e-
Hellman value over a period of time, to handle a high rate of ses-
sions. For re-keying, a HIP packet protected by an existing IPsec
session is used. HIP does not provide identity protection, and it depends
on the existence of an out-of-band mechanism for distributing
and certi?cates, or on extra HIP messages for exchanging
this information (thus, the message count is effectively 6, or even
8, for most common usage scenarios).
6. CONCLUSION
Over the years, many different key exchange protocols have been
proposed. Some have had security ?aws; others have not met certain
requirements.
JFK addresses the ?rst issue by simplicity, and by a proof of
correctness. (Again, full details of this are deferred to the analysis
paper.) We submit that proof techniques have advanced enough
that new protocols should not be deployed without such an anal-
ysis. We also note that the details of the JFK protocol changed in
order to accommodate the proof: tossing a protocol over the wall to
the theoreticians is not a recipe for success. But even a proof of correctness
is not a substitute for simplicity of design; apart from the
chance of errors in the formal analysis, a complex protocol implies
a complex implementation, with all the attendant issues of buggy
code and interoperability problems.
The requirements issue is less tractable, because it is not possible
to foresee how threat models or operational needs will change
over time. Thus, StS is not suitable for an environment where denial
of service attacks are a concern. Another comparatively-recent
requirement is identity protection. But the precise need ? whose
identity should be protected, and under what threat model ? is still
unclear, hence the need for both JFKi and JFKr.
Finally, and perhaps most important, we show that some attributes
often touted as necessities are, in fact, susceptible to a cost-bene?t
analysis. Everyone understands that cryptographic primitives are
not arbitrarily strong, and that cost considerations are often used in
deciding on algorithms, key lengths, block sizes, etc. We show that
DoS-resistance and perfect forward secrecy have similar character-
istics, and that it is possible to improve some aspects of a protocol
(most notably the number of round trips required) by treating others
as parameters of the system, rather than as absolutes.
7.

ACKNOWLEDGEMENTS

Ran Atkinson, Matt Crawford, Paul Hoffman, and Eric Rescorla
provided useful comments, and discussions with Hugo Krawczyk
proved very useful. Dan Harkins suggested the inclusion of IPI
in the authenticator. David Wagner made useful suggestions on the
format of Message (2) in JFKi. The design of the JFKr protocol
was in?uenced by the SIGMA and IKEv2 protocols.
8.


--R


The TLS protocol version 1.0.

A Cryptographic Evaluation of

Securely available credentials - credential server framework
The Internet Key Exchange (IKE).
Proposal for the IKEv2 Protocol.
Attack Class: Address Spoo?
Enhancing the resistance of a
Features of Proposed Successors to IKE.

Proofs of work and bread pudding protocols.
Scalability and
Client puzzles: A cryptographic countermeasure against connection depletion attacks.


Analysis of IKE.
SKEME: A Versatile Secure Key Exchange Mechanism for Internet.
The IKE-SIGMA Protocol
http://www.


Comments 2104
Towards network denial
of service resistant protocols.
International Information Security Conference (IFIP/SEC)
Resolution of ISAKMP/Oakley


Modi?ed aggressive mode of



Internet security association and key management protocol


Analysis of the Internet Key Exchange
protocol using the NRL protocol analyzer.
IEEE Symposium on Security and Privacy
A formal framework and evaluation method for
network denial of service.
Computer Security Foundations Workshop
Open issues in formal methods for
cryptographic protocol analysis.
Information Survivability Conference and Exposition


Kerberos Authentication and Authorization System.

The Host
Protecting key exchange and management
protocols against resource clogging attacks.
IFIP TC6 and TC11 Joint Working Conference on
Communications and Multimedia Security (CMS

Analysis of a denial of service attack on tcp.
IEEE Security and Privacy Conference


IKE/ISAKMP Considered Harmful.

--TR
Authentication and authenticated key exchanges
Entity authentication and key distribution
Stateless connections
Enhancing the Resistence of a Provably Secure Key Agreement Protocol to a Denial-of-Service Attack
Security Analysis of IKE''s Signature-Based Key-Exchange Protocol
Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels
Towards Network Denial of Service Resistant Protocols
DOS-Resistant Authentication with Client Puzzles
Protecting Key Exchange and Management Protocols Against Resource Clogging Attacks
Proofs of Work and Bread Pudding Protocols
A Formal Framework and Evaluation Method for Network Denial of Service
Scalability and Flexibility in Authentication Services
Analysis of a Denial of Service Attack on TCP

--CTR
Steven M. Bellovin , Matt Blaze , Ran Canetti , John Ioannidis , Angelos D. Keromytis , Omer Reingold, Just fast keying: Key agreement in a hostile internet, ACM Transactions on Information and System Security (TISSEC), v.7 n.2, p.242-273, May 2004
Suratose Tritilanunt , Colin Boyd , Ernest Foo , Juan Manuel Gonzlez Nieto, Cost-based and time-based analysis of DoS-resistance in HIP, Proceedings of the thirtieth Australasian conference on Computer science, p.191-200, January 30-February 02, 2007, Ballarat, Victoria, Australia
Kui Ren , Wenjing Lou , Kai Zeng , Feng Bao , Jianying Zhou , Robert H. Deng, Routing optimization security in mobile IPv6, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.50 n.13, p.2401-2419, 15 September 2006
Theodore Diament , Homin K. Lee , Angelos D. Keromytis , Moti Yung, The dual receiver cryptosystem and its applications, Proceedings of the 11th ACM conference on Computer and communications security, October 25-29, 2004, Washington DC, USA
Changhua He , John C. Mitchell, Analysis of the 802.11i 4-way handshake, Proceedings of the 2004 ACM workshop on Wireless security, October 01-01, 2004, Philadelphia, PA, USA
k-anonymous secret handshakes with reusable credentials, Proceedings of the 11th ACM conference on Computer and communications security, October 25-29, 2004, Washington DC, USA
Zhiguo Wan , Robert H. Deng , Feng Bao , Akkihebbal L. Ananda, Access control protocols with two-layer architecture for wireless networks, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.51 n.3, p.655-670, February, 2007
Martn Abadi , Bruno Blanchet , Cdric Fournet, Just fast keying in the pi calculus, ACM Transactions on Information and System Security (TISSEC), v.10 n.3, p.9-es, July 2007
Heng Yin , Haining Wang, Building an application-aware IPsec policy system, Proceedings of the 14th conference on USENIX Security Symposium, p.21-21, July 31-August 05, 2005, Baltimore, MD
Martn Abadi , Cdric Fournet, Private authentication, Theoretical Computer Science, v.322 n.3, p.427-476, 6 September 2004
Martn Abadi , Bruno Blanchet, Analyzing security protocols with secrecy types and logic programs, Journal of the ACM (JACM), v.52 n.1, p.102-146, January 2005
Angelos D. Keromytis , Janak Parekh , Philip N. Gross , Gail Kaiser , Vishal Misra , Jason Nieh , Dan Rubenstein , Sal Stolfo, A holistic approach to service survivability, Proceedings of the ACM workshop on Survivable and self-regenerative systems: in association with 10th ACM Conference on Computer and Communications Security, p.11-22, October 31-31, 2003, Fairfax, VA
Heng Yin , Haining Wang, Building an application-aware IPsec policy system, IEEE/ACM Transactions on Networking (TON), v.15 n.6, p.1502-1513, December 2007
Robert C. Chalmers , Kevin C. Almeroth, A Security Architecture for Mobility-Related Services, Wireless Personal Communications: An International Journal, v.29 n.3-4, p.247-261, June 2004
cryptography;denial of service attacks