[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC KM Requirements
At the last meeting I offered to try to document the KM requirements
as a means of moving forward/looking at alternatives. This is a first
cut at that summary. I think we need to reach some form of agreement
on our goals, particularly if we are going to consider other on-going
key management efforts. In addition to the functional areas, I think
other topics include general format orientation (e.g. ASN), use of
X.509 certificates for identification, and other "customers" besides
IPSP.
Dave
The purpose of this note is to summarize requirements for
an Internet Key Management Protocol (IKMP), based largely
on discussions during the last IETF IPSEC working group. The
basic functions of the IKMP are to create, manage, and
remove security associations used by the IP Security
Protocol (IPSP) or other similar security protocols. A
security association consists of the key(s) used for that
association as well as attributes guiding the operation
of the associated protocol. In particular, the IKMP is
expected to handle negotiation of cryptographic
algorithms, protocol format, and protocol options (e.g.
security labels, integrity checks).
IKMP is a management application invoked by a security
protocol when it is determined that no existing security
association exists which matches processing of for a PDU.
Matching for IPSP may be based on a combination of
addresses, security labels, and requested security
services.
IKMP may need to support two slightly different
instances: an IKMP light which performs only the key
management function for cases where the peers have
already established (or assume) all the other attributes;
and a full IKMP which supports negotiation of attributes
and association maintenance functions.
Functional requirements for IKMP include:
Security Association ID (SAID) assignment (or Security Association
Creation) - The SAID is the identifier used to refer to the security
association. Its main use is in the clear portion of the security
protocol to indicate to the receiver how to process the security PDU
(e.g. what key to use). A distinct SAID exists for each direction of
a security association and is generally assigned by the receiver.
SAIDs are unique only for a specific receiver. The granularity of a
security association depends upon the details of the security
protocol, network topology, and security association attributes.
An SAID may provide additional semantics such as
indicating the format of the security protocol or use
with multi-party (more than two) associations.
Key generation/distribution - The primary function of
IKMP is to establish the key(s) used by the security
protocol for encryption (or other cryptographic
functions). Depending upon the algorithms used, this
function might transfer a key from one party to another
or might support a distributed key generation process.
IKMP should support both symmetric key distribution
algorithms as well as asymmetric/distributed key
management.
The key management functions of IKMP are the basis for
establishing data origin authentication services within
the associated security protocol. Consequently, the IKMP processing
needs to include a form of peer entity authentication.
Attribute Negotiation - IKMP needs to establish the
attributes used by the security protocol as well as attributes
which are implicitly bound to use of the key. Attributes
might include an implicit security label; protocol
options (e.g. sequence numbers, integrity check
functions); choice of cryptographic algorithm;
association lifetime; or source/destination addresses.
These exchanges may also be used to determine
authorization and identification information used as part
of an access control decision made either by IKMP or by
IPSP (or other associated security protocol). The
specific attributes to be negotiated will depend upon the
specification of IPSP or other protocols which use IKMP.
Terminate/Delete Association - When one party decides to
delete the security association information, IKMP can be
used to inform the other party(s). This is important
when used with a connectionless protocol like IP and IPSP
to coordinate termination.
Security Association Maintenance - Maintenance functions
for a security association include changing a key or
changing attributes during the lifetime of an
association. Such functions could be implemented either
by changing the information while keeping the same SAID
or by spawning a new security association. The latter
option (creating new SAIDs) is far more robust and is
strongly recommended.
Peer Discovery and Authentication - When IPSP operates at
an intermediate system, a peer IPSP entity may attempt to
form a security association with an entity behind the
secure IS. IKMP must include a facility whereby the
initiator of the security association learns the identity
of the secure IS; verifies that the intended end system
is served by that particular IS; and forms or uses an
appropriate security association.
Recovery - IKMP needs to be able to clean up and recover
from cases where the parties to a security association
detect a failure (note: the detection or a failure is the
responsibility of the security protocol or other
protocol). The most common case is where one party has
deleted the key and other security association
information while the other party continues to send PDUs
using that key. Mechanisms which support this recovery
must be carefully reviewed with respect to denial of
service concerns.
Protocol Profile - To support interoperability, the
protocols used by IKMP for peer exchanges need to be
defined. Support might be included for both in-band and
external (application level) interactions.
Multiparty Associations - IKMP should support the
establishment of associations between more than two
parties. This might be used to support multicast,
anycast, or multiple route scenarios. There are two
primary implications of multiparty support: the ability
to transfer SA information to multiple parties and the
assignment of SAIDs. Transferring information to
multiple parties can be achieved by repeating the
pairwise model multiple times. The problem with SAIDs is
that the general model calls for receiver generated
identifiers. If there are multiple receivers, then an
additional facility is needed to manage unique IDs among
several parties.