As per Relevance of the word exchange, we have this rfc below:
Network Working Group H.
Request for Comments: 2412 Department of Computer
Category: Informational University of
November 1998
The OAKLEY Key Determination
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes a protocol, named OAKLEY, by which
authenticated parties can agree on secure and secret keying material
The basic mechanism is the Diffie-Hellman key exchange algorithm
The OAKLEY protocol supports Perfect Forward Secrecy,
with the ISAKMP protocol for managing security associations, user
defined abstract group structures for use with the Diffie-
algorithm, key updates, and incorporation of keys distributed
out-of-band mechanisms
1.
Key establishment is the heart of data protection that relies
cryptography, and it is an essential component of the
protection mechanisms described in [RFC2401], for example.
scalable and secure key distribution mechanism for the Internet is
necessity. The goal of this protocol is to provide that mechanism
coupled with a great deal of cryptographic strength
The Diffie-Hellman key exchange algorithm provides such a mechanism
It allows two parties to agree on a shared value without
encryption. The shared value is immediately available for use
encrypting subsequent conversation, e.g. data transmission and/
authentication. The STS protocol [STS] provides a demonstration
how to embed the algorithm in a secure protocol, one that
that in addition to securely sharing a secret, the two parties can
sure of each other's identities, even when an active attacker exists
Orman Informational [Page 1]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
Because OAKLEY is a generic key exchange protocol, and because
keys that it generates might be used for encrypting data with a
privacy lifetime, 20 years or more, it is important that
algorithms underlying the protocol be able to ensure the security
the keys for that period of time, based on the best
capabilities available for seeing into the mathematical future.
protocol therefore has two options for adding to the
faced by an attacker who has a large amount of recorded key
traffic at his disposal (a passive attacker). These options
useful for deriving keys which will be used for encryption
The OAKLEY protocol is related to STS, sharing the similarity
authenticating the Diffie-Hellman exponentials and using them
determining a shared key, and also of achieving Perfect
Secrecy for the shared key, but it differs from the STS protocol
several ways
The first is the addition of a weak address validation
("cookies", described by Phil Karn in the Photuris key
protocol work in progress) to help avoid denial of
attacks
The second extension is to allow the two parties to
mutually agreeable supporting algorithms for the protocol:
encryption method, the key derivation method, and
authentication method
Thirdly, the authentication does not depend on encryption
the Diffie-Hellman exponentials; instead, the
validates the binding of the exponentials to the identities of
parties
The protocol does not require the two parties compute the
exponentials prior to authentication
This protocol adds additional security to the derivation of
meant for use with encryption (as opposed to authentication)
including a dependence on an additional algorithm. The
of keys for encryption is made to depend not only on the Diffie
Hellman algorithm, but also on the cryptographic method used
securely authenticate the communicating parties to each other
Finally, this protocol explicitly defines how the two parties
select the mathematical structures (group representation
operation) for performing the Diffie-Hellman algorithm; they
use standard groups or define their own. User-defined
provide an additional degree of long-term security
Orman Informational [Page 2]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
OAKLEY has several options for distributing keys. In addition to
classic Diffie-Hellman exchange, this protocol can be used to
a new key from an existing key and to distribute an
derived key by encrypting it
The protocol allows two parties to use all or some of the anti
clogging and perfect forward secrecy features. It also permits
use of authentication based on symmetric encryption or non-
algorithms. This flexibility is included in order to allow
parties to use the features that are best suited to their
and performance requirements
This document draws extensively in spirit and approach from
Photuris work in progress by Karn and Simpson (and from
with the authors), specifics of the ISAKMP document by Schertler
al. the ISAKMP protocol document, and it was also influenced
papers by Paul van Oorschot and Hugo Krawcyzk
2. The Protocol
2.1 General
The OAKLEY protocol is used to establish a shared key with
assigned identifier and associated authenticated identities for
two parties. The name of the key can be used later to
security associations for the RFC 2402 and RFC 2406 protocols (AH
ESP) or to achieve other network security goals
Each key is associated with algorithms that are used
authentication, privacy, and one-way functions. These are
algorithms for OAKLEY; their appearance in subsequent
association definitions derived with other protocols is
required nor prohibited
The specification of the details of how to apply an algorithm to
is called a transform. This document does not supply the
definitions; they will be in separate RFC's
The anti-clogging tokens, or "cookies", provide a weak form of
address identification for both parties; the cookie exchange can
completed before they perform the computationally expensive part
the protocol (large integer exponentiations).
It is important to note that OAKLEY uses the cookies for
purposes: anti-clogging and key naming. The two parties to
protocol each contribute one cookie at the initiation of
establishment; the pair of cookies becomes the key
(KEYID), a reusable name for the keying material. Because of
Orman Informational [Page 3]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
dual role, we will use the notation for the concatenation of
cookies ("COOKIE-I, COOKIE-R") interchangeably with the
"KEYID".
OAKLEY is designed to be a compatible component of the
protocol [ISAKMP], which runs over the UDP protocol using a well
known port (see the RFC on port assignments, STD02-RFC-1700).
only technical requirement for the protocol environment is that
underlying protocol stack must be able to supply the Internet
of the remote party for each message. Thus, OAKLEY could, in theory
be used directly over the IP protocol or over UDP, if
protocol or port number assignments were available
The machine running OAKLEY must provide a good random
generator, as described in [RANDOM], as the source of random
required in this protocol description. Any mention of a "nonce
implies that the nonce value is generated by such a generator.
same is true for "pseudorandom" values
2.2
The section describes the notation used in this document for
sequences and content
2.2.1 Message
The protocol exchanges below are written in an abbreviated
that is intended to convey the essential elements of the exchange
a clear manner. A brief guide to the notation follows. The
formats and assigned values are given in the appendices
In order to represent message exchanges succinctly, this
uses an abbreviated notation that describes each message in terms
its source and destination and relevant fields
Arrows ("->") indicate whether the message is sent from the
to the responder, or vice versa ("<-").
The fields in the message are named and comma separated.
protocol uses the convention that the first several fields
a fixed header format for all messages
For example, consider a HYPOTHETICAL exchange of messages involving
fixed format message, the four fixed fields being two "cookies",
third field being a message type name, the fourth field being
multi-precision integer representing a power of a number
Orman Informational [Page 4]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
Initiator
-> Cookie-I, 0, OK_KEYX, g^x ->
<- Cookie-R, Cookie-I, OK_KEYX, g^y <-
The notation describes a two message sequence. The initiator
by sending a message with 4 fields to the responder; the first
has the unspecified value "Cookie-I", second field has the
value 0, the third field indicates the message type is OK_KEYX,
fourth value is an abstract group element g to the x'th power
The second line indicates that the responder replies with
"Cookie-R" in the first field, a copy of the "Cookie-I" value in
second field, message type OK_KEYX, and the number g raised to
y'th power
The value OK_KEYX is in capitals to indicate that it is a
constant (constants are defined in the appendices).
Variable precision integers with length zero are null values for
protocol
Sometimes the protocol will indicate that an entire payload (
the Key Exchange Payload) has null values. The payload is
present in the message, for the purpose of simplifying parsing
2.2.2 Guide to
Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-
numbers. The generation method must ensure with high
that the numbers used for each IP remote address are unique over
time period, such as one hour
KEYID is the concatenation of the initiator and responder cookies
the domain of interpretation; it is the name of keying material
sKEYID is used to denote the keying material named by the KEYID.
is never transmitted, but it is used in various
performed by the two parties
OK_KEYX and OK_NEWGRP are distinct message types
IDP is a bit indicating whether or not material after the
boundary (see appendix B), is encrypted. NIDP means not encrypted
g^x and g^y are encodings of group elements, where g is a
group element indicated in the group description (see Appendix A)
g^x indicates that element raised to the x'th power. The type of
encoding is either a variable precision integer or a pair of
Orman Informational [Page 5]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
integers, as indicated in the group operation in the
description. Note that we will write g^xy as a short-hand
g^(xy). See Appendix F for references that describe
large integer computations and the relationship between various
definitions and basic arithmetic operations
EHAO is a list of encryption/hash/authentication choices. Each
is a pair of values: a class name and an algorithm name
EHAS is a set of three items selected from the EHAO list, one
each of the classes for encryption, hash, authentication
GRP is a name (32-bit value) for the group and its
parameters: the size of the integers, the arithmetic operation,
the generator element. There are a few pre-defined GRP's (for 768
bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp
155-bit and 210-bit elliptic curves, see Appendix E),
participants can share other group descriptions in a later
stage (see the section NEW GROUP). It is important to
notion of the GRP from the group descriptor (Appendix A); the
is a name for the latter
The symbol vertical bar "|" is used to denote concatenation of
strings. Fields are concatenated using their encoded form as
appear in their payload
Ni and Nr are nonces selected by the initiator and responder
respectively
ID(I) and ID(R) are the identities to be used in authenticating
initiator and responder respectively
E{x}Ki indicates the encryption of x using the public key of
initiator. Encryption is done using the algorithm associated
the authentication method; usually this will be RSA
S{x}Ki indicates the signature over x using the private key (
key) of the initiator. Signing is done using the
associated with the authentication method; usually this will be
or DSS
prf(a, b) denotes the result of applying pseudo-random function "a
to data "b". One may think of "a" as a key or as a value
characterizes the function prf; in the latter case it is the
into a family of functions. Each function in the family provides
"hash" or one-way mixing of the input
prf(0, b) denotes the application of a one-way function to data "b".
Orman Informational [Page 6]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The similarity with the previous notation is deliberate and
that a single algorithm, e.g. MD5, might will used for both purposes
In the first case a "keyed" MD5 transform would be used with key "a";
in the second case the transform would have the fixed key value zero
resulting in a one-way function
The term "transform" is used to refer to functions defined
auxiliary RFC's. The transform RFC's will be drawn from
defined for IPSEC AH and ESP (see RFC 2401 for the
architecture encompassing these protocols).
2.3 The Key Exchange Message
The goal of key exchange processing is the secure establishment
common keying information state in the two parties. This
information is a key name, secret keying material, the
of the two parties, and three algorithms for use
authentication: encryption (for privacy of the identities of the
parties), hashing (a pseudorandom function for protecting
integrity of the messages and for authenticating message fields),
authentication (the algorithm on which the mutual authentication
the two parties is based). The encodings and meanings for
choices are presented in Appendix B
The main mode exchange has five optional features: stateless
exchange, perfect forward secrecy for the keying material,
for the identities, perfect forward secrecy for identity secrecy,
of signatures (for non-repudiation). The two parties can use
combination of these features
The general outline of processing is that the Initiator of
exchange begins by specifying as much information as he wishes in
first message. The Responder replies, supplying as much
as he wishes. The two sides exchange messages, supplying
information each time, until their requirements are satisfied
The choice of how much information to include in each message
on which options are desirable. For example, if stateless
are not a requirement, and identity secrecy and perfect
secrecy for the keying material are not requirements, and if non
repudiatable signatures are acceptable, then the exchange can
completed in three messages
Additional features may increase the number of roundtrips needed
the keying material determination
ISAKMP provides fields for specifying the security
parameters for use with the AH and ESP protocols. These
Orman Informational [Page 7]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
association payload types are specified in the ISAKMP memo;
payload types can be protected with OAKLEY keying material
algorithms, but this document does not discuss their use
2.3.1 The Essential Key Exchange Message
There are 12 fields in an OAKLEY key exchange message. Not all
fields are relevant in every message; if a field is not relevant
can have a null value or not be present (no payload).
CKY-I originator cookie
CKY-R responder cookie
MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ
ISA_KE&AUTH_REP; for new group definitions
will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_
GRP the name of the Diffie-Hellman group used
the
g^x (or g^y) variable length integer representing a power
group
EHAO or EHAS encryption, hash, authentication functions
offered and selectedj,
IDP an indicator as to whether or not encryption
g^xy follows (perfect forward secrecy for ID's
ID(I) the identity for the
ID(R) the identity for the
Ni nonce supplied by the
Nr nonce supplied by the
The construction of the cookies is implementation dependent.
Karn has recommended making them the result of a one-way
applied to a secret value (changed periodically), the local
remote IP address, and the local and remote UDP port. In this way
the cookies remain stateless and expire periodically. Note that
OAKLEY, this would cause the KEYID's derived from the secret value
also expire, necessitating the removal of any state
associated with it
In order to support pre-distributed keys, we recommend
implementations reserve some portion of their cookie space
permanent keys. The encoding of these depends only on the
implementation
The encryption functions used with OAKLEY must be
transforms which guarantee privacy and integrity for the
data. Merely using DES in CBC mode is not permissible.
MANDATORY and OPTIONAL transforms will include any that satisfy
criteria and are defined for use with RFC 2406 (ESP).
Orman Informational [Page 8]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The one-way (hash) functions used with OAKLEY must be
transforms which can be used as either keyed hash (pseudo-random)
non-keyed transforms. The MANDATORY and OPTIONAL transforms
include any that are defined for use with RFC 2406 (AH).
Where nonces are indicated, they will be variable precision
with an entropy value that matches the "strength" attribute of
GRP used with the exchange. If no GRP is indicated, the nonces
be at least 90 bits long. The pseudo-random generator for the
material should start with initial data that has at least 90 bits
entropy; see RFC 1750.
2.3.1.1 Exponent
Ideally, the exponents will have at least 180 bits of entropy
every key exchange. This ensures complete independence of
material between two exchanges (note that this applies if only one
the parties chooses a random exponent). In practice,
may wish to base several key exchanges on a single base value
180 bits of entropy and use one-way hash functions to guarantee
exposure of one key will not compromise others. In this case, a
recommendation is to keep the base values for nonces and
separate from the base value for exponents, and to replace the
value with a full 180 bits of entropy as frequently as possible
The values 0 and p-1 should not be used as exponent values
implementors should be sure to check for these values, and
should also refuse to accept the values 1 and p-1 from remote
(where p is the prime used to define a modular exponentiation group).
2.3.2 Mapping to ISAKMP Message
All the OAKLEY message fields correspond to ISAKMP message
or payload components. The relevant payload fields are the
payload, the AUTH payload, the Certificate Payload, the Key
Payload. The ISAKMP protocol framwork is a work in progress at
time, and the exact mapping of Oakley message fields to
payloads is also in progress (to be known as the
document).
Some of the ISAKMP header and payload fields will have
values when used with OAKLEY. The exact values to be used will
published in a Domain of Interpretation document accompanying
Resolution document
In the following we indicate where each OAKLEY field appears in
ISAKMP message structure. These are recommended only; the
document will be the final authority on this mapping
Orman Informational [Page 9]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
CKY-I ISAKMP
CKY-R ISAKMP
MSGTYPE Message Type in ISAKMP
GRP SA payload, Proposal
g^x (or g^y) Key Exchange Payload, encoded as a
precision
EHAO and EHAS SA payload, Proposal
IDP A bit in the RESERVED field in the AUTH
ID(I) AUTH payload, Identity
ID(R) AUTH payload, Identity
Ni AUTH payload, Nonce
Nr AUTH payload, Nonce
S{...}Kx AUTH payload, Data
prf{K,...} AUTH payload, Data
2.4 The Key Exchange
The exact number and content of messages exchanged during an
key exchange depends on which options the Initiator and
want to use. A key exchange can be completed with three or
messages, depending on those options
The three components of the key determination protocol are
1. cookie exchange (optionally stateless
2. Diffie-Hellman half-key exchange (optional, but essential
perfect forward secrecy
3. authentication (options: privacy for ID's, privacy for ID'
with PFS, non-repudiatable
The initiator can supply as little information as a bare
request, carrying no additional information. On the other hand
initiator can begin by supplying all of the information necessary
the responder to authenticate the request and complete the
determination quickly, if the responder chooses to accept
method. If not, the responder can reply with a minimal amount
information (at the minimum, a cookie).
The method of authentication can be digital signatures, public
encryption, or an out-of-band symmetric key. The three
methods lead to slight variations in the messages, and the
are illustrated by examples in this section
The Initiator is responsible for retransmitting messages if
protocol does not terminate in a timely fashion. The Responder
therefore avoid discarding reply information until it is
by Initiator in the course of continuing the protocol
Orman Informational [Page 10]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The remainder of this section contains examples demonstrating how
use OAKLEY options
2.4.1 An Aggressive
The following example indicates how two parties can complete a
exchange in three messages. The identities are not secret,
derived keying material is protected by PFS
By using digital signatures, the two parties will have a proof
communication that can be recorded and presented later to a
party
The keying material implied by the group exponentials is not
for completing the exchange. If it is desirable to defer
computation, the implementation can save the "x" and "g^y" values
mark the keying material as "uncomputed". It can be computed
this information later
Initiator
--------- ---------
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ->
ID(I), ID(R), Ni, 0,
S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP
ID(R), ID(I), Nr, Ni
S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, ->
ID(I), ID(R), Ni, Nr
S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}
NB "NIDP" means that the PFS option for hiding identities is not used
i.e., the identities are not encrypted using a key based on g^
NB Fields are shown separated by commas in this document; they
concatenated in the actual protocol messages using their
forms as specified in the ISAKMP/Oakley Resolution document
The result of this exchange is a key with KEYID = CKY-I|CKY-R
sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
The processing outline for this exchange is as follows
Orman Informational [Page 11]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The Initiator generates a unique cookie and associates it with
expected IP address of the responder, and its chosen
information: GRP (the group identifier), a pseudo-
selected exponent x, g^x, EHAO list, nonce, identities. The
authentication choice in the EHAO list is an algorithm
supports digital signatures, and this is used to sign the ID's
the nonce and group id. The Initiator
notes that the key is in the initial state of "unauthenticated",
sets a timer for possible retransmission and/or termination of
request
When the Responder receives the message, he may choose to ignore
the information and treat it as merely a request for a cookie
creating no state. If CKY-I is not already in use by the
address in the IP header, the responder generates a unique cookie
CKY-R. The next steps depend on the Responder's preferences.
minimal required response is to reply with the first cookie field
to zero and CKY-R in the second field. For this example we
assume that the responder is more aggressive (for the alternatives
see section 6) and accepts the following
group with identifier GRP
first authentication choice (which must be the digital
method used to sign the Initiator message),
lack of perfect forward secrecy for protecting the identities
identity ID(I) and identity ID(R
In this example the Responder decides to accept all the
offered by the initiator. It validates the signature over the
portion of the message, and associate the pair (CKY-I, CKY-R)
the following state information
the source and destination network addresses of the
key state of "unauthenticated
the first algorithm from the authentication
group GRP, a "y" exponent value in group GRP, and g^x from
the nonce Ni and a pseudorandomly selected value
Orman Informational [Page 12]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
a timer for possible destruction of the state
The Responder computes g^y, forms the reply message, and then
the ID and nonce information with the private key of ID(R) and
it to the Initiator. In all exchanges, each party should make
that he neither offers nor accepts 1 or g^(p-1) as an exponential
In this example, to expedite the protocol, the Responder
accepts the first algorithm in the Authentication class of the
list. This because he cannot validate the Initiator
without accepting the algorithm for doing the signature.
Responder's EHAS list will also reflect his acceptance
The Initiator receives the reply message
validates that CKY-I is a valid association for the
address of the incoming message
adds the CKY-R value to the state for the pair (CKY-I,
address), and associates all state information with the
(CKY-I, CKY-R),
validates the signature of the responder over the
information (should validation fail, the message is discarded
adds g^y to its state information
saves the EHA selections in the state
optionally computes (g^y)^x (= g^xy) (this can be deferred
after sending the reply message),
sends the reply message, signed with the public key of ID(I),
marks the KEYID (CKY-I|CKY-R) as authenticated
and composes the reply message and signature
When the Responder receives the Initiator message, and if
signature is valid, it marks the key as being in the
state. It should compute g^xy and associate it with the KEYID
Note that although PFS for identity protection is not used, PFS
the derived keying material is still present because the Diffie
Hellman half-keys g^x and g^y are exchanged
Even if the Responder only accepts some of the Initiator information
the Initiator will consider the protocol to be progressing.
Initiator should assume that fields that were not accepted by
Orman Informational [Page 13]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
Responder were not recorded by the Responder
If the Responder does not accept the aggressive exchange and
another algorithm for the A function, then the protocol will
continue using the signature algorithm or the signature value
the first message
2.4.1.1 Fields Not
If the Responder does not accept all the fields offered by
Initiator, he should include null values for those fields in
response. Section 6 has guidelines on how to select fields in
"left-to-right" manner. If a field is not accepted, then it and
following fields must have null values
The Responder should not record any information that it does
accept. If the ID's and nonces have null values, there will not be
signature over these null values
2.4.1.2 Signature via Pseudo-Random
The aggressive example is written to suggest that public
technology is used for the signatures. However, a
function can be used, if the parties have previously agreed to such
scheme and have a shared key
If the first proposal in the EHAO list is an "existing key" method
then the KEYID named in that proposal will supply the keying
for the "signature" which is computed using the "H"
associated with the KEYID
Suppose the first proposal in EHAO
EXISTING-KEY, 32
and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation
The keying material is some string of bits, call it sK32. Then
the first message in the aggressive exchange, where the
S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}
is indicated, the signature computation would be performed
MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^
| g^y | EHAO) (The exact definition of the algorithm
to "MD5-HMAC- func" will appear in the RFC defining that transform).
The result of this computation appears in the Authentication payload
Orman Informational [Page 14]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
2.4.2 An Aggressive Example With Hidden
The following example indicates how two parties can complete a
exchange without using digital signatures. Public key
hides the identities during authentication. The group
are exchanged and authenticated, but the implied keying
(g^xy) is not needed during the exchange
This exchange has an important difference from the previous
scheme --- in the first message, an identity for the responder
indicated as cleartext: ID(R'). However, the identity hidden
the public key cryptography is different: ID(R). This
because the Initiator must somehow tell the Responder
public/private key pair to use for the decryption, but at the
time, the identity is hidden by encryption with that public key
The Initiator might elect to forgo secrecy of the Responder identity
but this is undesirable. Instead, if there is a well-known
for the Responder node, the public key for that identity can be
to encrypt the actual Responder identity
Initiator
--------- ---------
-> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, ->
ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP
E{ID(R), ID(I), Nr}Ki
prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <-
-> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP
prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) ->
Kir = prf(0, Ni | Nr
NB "NIDP" means that the PFS option for hiding identities is not used
NB The ID(R') value is included in the Authentication payload
described in Appendix B
The result of this exchange is a key with KEYID = CKY-I|CKY-R
value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R).
The processing outline for this exchange is as follows
The Initiator generates a unique cookie and associates it with
expected IP address of the responder, and its chosen
information: GRP, g^x, EHAO list. The first authentication
in the EHAO list is an algorithm that supports public
Orman Informational [Page 15]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
encryption. The Initiator also names the two identities to
used for the connection and enters these into the state. A well
known identity for the responder machine is also chosen, and
public key for this identity is used to encrypt the nonce Ni
the two connection identities. The Initiator
notes that the key is in the initial state of "unauthenticated",
sets a timer for possible retransmission and/or termination of
request
When the Responder receives the message, he may choose to ignore
the information and treat it as merely a request for a cookie
creating no state
If CKY-I is not already in use by the source address in the
header, the Responder generates a unique cookie, CKY-R. As before
the next steps depend on the responder's preferences. The
required response is a message with the first cookie field set
zero and CKY-R in the second field. For this example we will
that responder is more aggressive and accepts the following
group GRP, first authentication choice (which must be the
key encryption algorithm used to encrypt the payload), lack
perfect forward secrecy for protecting the identities,
ID(I), identity ID(R
The Responder must decrypt the ID and nonce information, using
private key for the R' ID. After this, the private key for the R
will be used to decrypt the nonce field
The Responder now associates the pair (CKY-I, CKY-R) with
following state information
the source and destination network addresses of the
key state of "unauthenticated
the first algorithm from each class in the EHAO (encryption-hash
authentication algorithm offers)
group GRP and a y and g^y value in group
the nonce Ni and a pseudorandomly selected value
a timer for possible destruction of the state
Orman Informational [Page 16]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The Responder then encrypts the state information with the public
of ID(I), forms the prf value, and sends it to the Initiator
The Initiator receives the reply message
validates that CKY-I is a valid association for the
address of the incoming message
adds the CKY-R value to the state for the pair (CKY-I,
address), and associates all state information with the
(CKY-I, CKY-R),
decrypts the ID and nonce
checks the prf calculation (should this fail, the message
discarded
adds g^y to its state information
saves the EHA selections in the state
optionally computes (g^x)^y (= g^xy) (this may be deferred),
sends the reply message, encrypted with the public key of ID(R),
and marks the KEYID (CKY-I|CKY-R) as authenticated
When the Responder receives this message, it marks the key as
in the authenticated state. If it has not already done so, it
compute g^xy and associate it with the KEYID
The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I |
CKY-R
Note that although PFS for identity protection is not used, PFS
the derived keying material is still present because the Diffie
Hellman half-keys g^x and g^y are exchanged
2.4.3 An Aggressive Example With Private Identities and Without Diffie
Considerable computational expense can be avoided if perfect
secrecy is not a requirement for the session key derivation. The
parties can exchange nonces and secret key parts to achieve
authentication and derive keying material. The long-term privacy
data protected with derived keying material is dependent on
private keys of each of the parties
Orman Informational [Page 17]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
In this exchange, the GRP has the value 0 and the field for the
exponential is used to hold a nonce value instead
As in the previous section, the first proposed algorithm must be
public key encryption system; by responding with a cookie and a non
zero exponential field, the Responder implicitly accepts the
proposal and the lack of perfect forward secrecy for the
and derived keying material
Initiator
--------- ---------
-> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, ->
ID(R'), E{ID(I), ID(R), sKi}Kr',
<- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP
E{ID(R), ID(I), sKr}Ki, Nr
prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <-
-> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP
prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) ->
Kir = prf(0, sKi | sKr
NB The sKi and sKr values go into the nonce fields. The change
notation is meant to emphasize that their entropy is critical
setting the keying material
NB "NIDP" means that the PFS option for hiding identities is
used
The result of this exchange is a key with KEYID = CKY-I|CKY-R
value sKEYID = prf(Kir, CKY-I | CKY-R).
2.4.3 A Conservative
In this example the two parties are minimally aggressive; they
the cookie exchange to delay creation of state, and they use
forward secrecy to protect the identities. For this example,
use public key encryption for authentication; digital signatures
pre-shared keys can also be used, as illustrated previously.
conservative example here does not change the use of nonces, prf's
etc., but it does change how much information is transmitted in
message
The responder considers the ability of the initiator to repeat CKY-
as weak evidence that the message originates from a "live
correspondent on the network and the correspondent is associated
the initiator's network address. The initiator makes
assumptions when CKY-I is repeated to the initiator
Orman Informational [Page 18]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
All messages must have either valid cookies or at least one
cookie. If both cookies are zero, this indicates a request for
cookie; if only the initiator cookie is zero, it is a response to
cookie request
Information in messages violating the cookie rules cannot be used
any OAKLEY operations
Note that the Initiator and Responder must agree on one set of
algorithms; there is not one set for the Responder and one for
Initiator. The Initiator must include at least MD5 and DES in
initial offer
Fields not indicated have null values
Initiator
--------- ---------
-> 0, 0, OK_KEYX ->
<- 0, CKY-R, OK_KEYX <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO ->
<- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <-
-> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*,
ID(I), ID(R), E{Ni}Kr, ->
<- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <-
E{Nr, Ni}Ki, ID(R), ID(I),
prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS )
-> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP
prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) ->
Kir = prf(0, Ni | Nr
* when IDP is in effect, authentication payloads are encrypted
the selected encryption algorithm using the keying material prf(0,
g^xy). (The transform defining the encryption algorithm
define how to select key bits from the keying material.)
encryption is in addition to and after any public key encryption
See Appendix B
Note that in the first messages, several fields are omitted
the description. These fields are present as null values
The first exchange allows the Responder to use stateless cookies;
the responder generates cookies in a manner that allows him
validate them without saving them, as in Photuris, then this
possible. Even if the Initiator includes a cookie in his
request, the responder can still use stateless cookies by
omitting the CKY-I from his reply and by declining to record
Initiator cookie until it appears in a later message
Orman Informational [Page 19]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
After the exchange is complete, both parties compute the shared
material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf"
the pseudo-random function in class "hash" selected in the EHA list
As with the cookies, each party considers the ability of the
side to repeat the Ni or Nr value as a proof that Ka, the public
of party a, speaks for the remote party and establishes its identity
In analyzing this exchange, it is important to note that although
IDP option ensures that the identities are protected with
ephemeral key g^xy, the authentication itself does not depend
g^xy. It is essential that the authentication steps validate the g^
and g^y values, and it is thus imperative that the authentication
involve a circular dependency on them. A third party could
with a "man-in-middle" scheme to convince the initiator and
to use different g^xy values; although such an attack might result
revealing the identities to the eavesdropper, the
would fail
2.4.4 Extra Strength for Protection of Encryption
The nonces Ni and Nr are used to provide an extra dimension
secrecy in deriving session keys. This makes the secrecy of the
depend on two different problems: the discrete logarithm problem
the group G, and the problem of breaking the nonce encryption scheme
If RSA encryption is used, then this second problem is
equivalent to factoring the RSA public keys of both the initiator
responder
For authentication, the key type, the validation method, and
certification requirement must be indicated
2.5 Identity and
2.5.1
In OAKLEY exchanges the Initiator offers Initiator and Responder ID'
-- the former is the claimed identity for the Initiator, and
latter is the requested ID for the Responder
If neither ID is specified, the ID's are taken from the IP
source and destination addresses
If the Initiator doesn't supply a responder ID, the Responder
reply by naming any identity that the local policy allows.
Initiator can refuse acceptance by terminating the exchange
Orman Informational [Page 20]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The Responder can also reply with a different ID than the
suggested; the Initiator can accept this implicitly by continuing
exchange or refuse it by terminating (not replying).
2.5.2
The authentication of principals to one another is at the heart
any key exchange scheme. The Internet community must decide on
scalable standard for solving this problem, and OAKLEY must make
of that standard. At the time of this writing, there is no
standard, though several are emerging. This document attempts
describe how a handful of standards could be incorporated
OAKLEY, without attempting to pick and choose among them
The following methods can appear in OAKLEY offers
a. Pre-shared
When two parties have arranged for a trusted method
distributing secret keys for their mutual authentication, they
be used for authentication. This has obvious scaling problems
large systems, but it is an acceptable interim solution for
situations. Support for pre-shared keys is REQUIRED
The encryption, hash, and authentication algorithm for use with
pre-shared key must be part of the state information
with the key itself
The pre-shared keys have a KEYID and keying material sKEYID;
KEYID is used in a pre-shared key authentication option offer
There can be more than one pre-shared key offer in a list
Because the KEYID persists over different invocations of
(after a crash, etc.), it must occupy a reserved part of the
space for the two parties. A few bits can be set aside in
party's "cookie space" to accommodate this
There is no certification authority for pre-shared keys. When
pre-shared key is used to generate an authentication payload,
certification authority is "None", the Authentication Type
"Preshared", and the payload
the KEYID, encoded as two 64-bit quantities, and the result
applying the pseudorandom hash function to the message
with the sKEYID forming the key for the
Orman Informational [Page 21]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
b. DNS public
Security extensions to the DNS protocol [DNSSEC] provide
convenient way to access public key information, especially
public keys associated with hosts. RSA keys are a requirement
secure DNS implementations; extensions to allow optional DSS
are a near-term possibility
DNS KEY records have associated SIG records that are signed by
zone authority, and a hierarchy of signatures back to the
server establishes a foundation for trust. The SIG
indicate the algorithm used for forming the signature
OAKLEY implementations must support the use of DNS KEY and
records for authenticating with respect to IPv4 and IPv6
and fully qualified domain names. However, implementations
not required to support any particular algorithm (RSA, DSS, etc.).
c. RSA public keys w/o certification authority signature
[Zimmerman] uses public keys with an informal method
establishing trust. The format of PGP public keys and
methods will be described in a separate RFC. The RSA
can be used with PGP keys for either signing or encryption;
authentication option should indicate either RSA-SIG or RSA-ENC
respectively. Support for this is OPTIONAL
d.1 RSA public keys w/ certificates There are various formats
naming conventions for public keys that are signed by one or
certification authorities. The Public Key Interchange
discusses X.509 encodings and validation. Support for this
OPTIONAL
d.2 DSS keys w/ certificates Encoding for the Digital
Standard with X.509 is described in draft-ietf-ipsec-dss-cert
00.txt. Support for this is OPTIONAL; an ISAKMP
Type will be assigned
2.5.3 Validating Authentication
The combination of the Authentication algorithm, the
Authority, the Authentication Type, and a key (usually public)
how to validate the messages with respect to the claimed identity
The key information will be available either from a pre-shared key
or from some kind of certification authority
Generally the certification authority produces a certificate
the entity name to a public key. OAKLEY implementations must
prepared to fetch and validate certificates before using the
key for OAKLEY authentication purposes
Orman Informational [Page 22]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The ISAKMP Authentication Payload defines the
Authority field for specifying the authority that must be apparent
the trust hierarchy for authentication
Once an appropriate certificate is obtained (see 2.4.3),
validation method will depend on the Authentication Type; if it
PGP then the PGP signature validation routines can be called
satisfy the local web-of-trust predicates; if it is RSA with X.509
certificates, the certificate must be examined to see if
certification authority signature can be validated, and if
hierarchy is recognized by the local policy
2.5.4 Fetching Identity
In addition to interpreting the certificate or other data
that contains an identity, users of OAKLEY must face the task
retrieving certificates that bind a public key to an identifier
also retrieving auxiliary certificates for certifying authorities
co-signers (as in the PGP web of trust).
The ISAKMP Credentials Payload can be used to attach
certificates to OAKLEY messages. The Credentials Payload is
in Appendix B
Support for accessing and revoking public key certificates via
Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations
Other retrieval methods can be used when the AUTH class indicates
preference
The Public Key Interchange Protocol discusses a full protocol
might be used with X.509 encoded certificates
2.6 Interface to Cryptographic
The keying material computed by the key exchange should have at
90 bits of entropy, which means that it must be at least 90 bits
length. This may be more or less than is required for keying
encryption and/or pseudorandom function transforms
The transforms used with OAKLEY should have auxiliary
which take a variable precision integer and turn it into
material of the appropriate length. For example, a DES
could take the low order 56 bits, a triple DES algorithm might
the following
K1 = low 56 bits of md5(0|sKEYID
K2 = low 56 bits of md5(1|sKEYID
K3 = low 56 bits of md5(2|sKEYID
Orman Informational [Page 23]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The transforms will be called with the keying material encoded as
variable precision integer, the length of the data, and the block
memory with the data. Conversion of the keying material to
transform key is the responsibility of the transform
2.7 Retransmission, Timeouts, and Error
If a response from the Responder is not elicited in an
amount of time, the message should be retransmitted by the Initiator
These retransmissions must be handled gracefully by both parties;
Responder must retain information for retransmitting until
Initiator moves to the next message in the protocol or completes
exchange
Informational error messages present a problem because they cannot
authenticated using only the information present in an
exchange; for this reason, the parties may wish to establish
default key for OAKLEY error messages. A possible method
establishing such a key is described in Appendix B, under the use
ISA_INIT message types
In the following the message type is OAKLEY Error, the KEYID
the H algorithm and key for authenticating the message contents;
value is carried in the Sig/Prf payload
The Error payload contains the error code and the contents of
rejected message
Orman Informational [Page 24]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Initiator-Cookie ~
/ ! !
KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! !
~ Responder-Cookie ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message Type ! Exch ! Vers ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (unused) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (unused) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Error Payload !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sig/prf
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The error message will contain the cookies as presented in
offending message, the message type OAKLEY_ERROR, and the reason
the error, followed by the rejected message
Error messages are informational only, and the correctness of
protocol does not depend on them
Error reasons
TIMEOUT exchange has taken too long, state
AEH_ERROR an unknown algorithm appears in an
GROUP_NOT_SUPPORTED GRP named is not
EXPONENTIAL_UNACCEPTABLE exponential too large/small or is +-1
SELECTION_NOT_OFFERED selection does not occur in
NO_ACCEPTABLE_OFFERS no offer meets host
AUTHENTICATION_FAILURE signature or hash function
RESOURCE_EXCEEDED too many exchanges or too much state
NO_EXCHANGE_IN_PROGRESS a reply received with no request in
Orman Informational [Page 25]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
2.8 Additional Security for Privacy Keys: Private
If the two parties have need to use a Diffie-Hellman
determination scheme that does not depend on the standard
definitions, they have the option of establishing a private group
The authentication need not be repeated, because this stage of
protocol will be protected by a pre-existing authentication key.
an extra security measure, the two parties will establish a
name for the shared keying material, so even if they use exactly
same group to communicate with other parties, the re-use will not
apparent to passive attackers
Private groups have the advantage of making a widespread
attack much harder by increasing the number of groups that would
to be exhaustively analyzed in order to recover a large number
session keys. This contrasts with the case when only one or
groups are ever used; in that case, one would expect that years
years of session keys would be compromised
There are two technical challenges to face: how can a particular
create a unique and appropriate group, and how can a second
assure himself that the proposed group is reasonably secure
The security of a modular exponentiation group depends on the
prime factor of the group size. In order to maximize this, one
choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and
are prime. However, if P = kQ + 1, where k is small, then
strength of the group is still considerable. These groups are
as Schnorr subgroups, and they can be found with much
computational effort than Sophie-Germaine primes
Schnorr subgroups can also be validated efficiently by using
prime tests
It is also fairly easy to find P, k, and Q such that the
prime factor can be easily proven to be Q
We estimate that it would take about 10 minutes to find a new
of about 2^1024 elements, and this could be done once a day by
scheduled process; validating a group proposed by a remote
would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz
machine
We note that validation is done only between previously
authenticated parties, and that a new group definition always
and is protected by a key established using a well-known group
There are five points to keep in mind
Orman Informational [Page 26]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
a. The description and public identifier for the new group
protected by the well-known group
b. The responder can reject the attempt to establish the
group, either because he is too busy or because he cannot
the largest prime factor as being sufficiently large
c. The new modulus and generator can be cached for long periods
time; they are not security critical and need not be
with ongoing activity
d. Generating a new g^x value periodically will be more
if there are many groups cached; however, the importance
frequently generating new g^x values is reduced, so the
period can be lengthened correspondingly
e. All modular exponentiation groups have subgroups that
weaker than the main group. For Sophie Germain primes, if
generator is a square, then there are only two elements in
subgroup: 1 and g^(-1) (same as g^(p-1)) which we have
recommended avoiding. For Schnorr subgroups with k not equal
2, the subgroup can be avoided by checking that the exponential
not a kth root of 1 (e^k != 1 mod p).
2.8.1 Defining a New
This section describes how to define a new group. The description
the group is hidden from eavesdroppers, and the identifier
to the group is unique to the two parties. Use of the new group
Diffie-Hellman key exchanges is described in the next section
The secrecy of the description and the identifier increases
difficulty of a passive attack, because if the group descriptor
not known to the attacker, there is no straightforward and
way to gain information about keys calculated using the group
Only the description of the new group need be encrypted in
exchange. The hash algorithm is implied by the OAKLEY session
by the group. The encryption is the encryption function of
OAKLEY session
The descriptor of the new group is encoded in the new group payload
The nonces are encoded in the Authentication Payload
Data beyond the encryption boundary is encrypted using the
named by the KEYID
Orman Informational [Page 27]
RFC 2412 The OAKLEY Key Determination Protocol November 1998
The following messages use the ISAKMP Key Exchange Identifier
New Group
To define a new modular exponentiation group
Initiator
--------- ----------
-> KEYID, ->
INEWGRP
Desc(New Group),
prf(sKEYID, Desc(New Group) | Na
<- KEYID
INEWGRPRS
Na,
prf(sKEYID, Na | Nb | Desc(New Group)) <-
-> KEYID
prf(sKEYID, Nb | Na | Desc(New Group)) ->
These messages are encrypted at the encryption boundary using the
indicated. The hash value is placed in the "digital signature"
(see Appendix B).
New GRP identifier = trunc16(Na) | trunc16(Nb
(trunc16 indicates truncation to 16 bits; the initiator
