[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.