[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKMP rough draft
Attached is an initial rough draft for an internet key management
protocol. The main goal of this version is to examine the functions
and services, the types of exchange, and the types and contents
of IKMP PDUs. I haven't addressed specific algorithms and expect
that this structure can support a variety of choices (both
symmetric and asymmetric).
Dave
Internet Key Management Protocol
1.0 Introduction
The purpose of this draft is to present a first draft for an internet
key management protocol (IKMP). This proposal borrows heavily from
approaches taken within the SDNS KMP specification.
IKMP is invoked when a security protocol/application determines that a
key and associated control information is required. For example, in
the case of IPSP, a datagram arrives for IPSP processing. IPSP checks
its security association database for a match (at least on addresses,
possibly on other parameters) and uses a match if found. If not IKMP
is invoked to set up a security association that matches the
parameters.
The basic model for IKMP consists of an initial protocol exchange to
create a traffic key accompanied by a family of management PDUs to
support attribute negotiation, deleting a security association, error
reporting, and security association replacement.
IKMP PDUs are exchanged via UDP.
This description is oriented around a pairwise association management
model. These same tools can be used to manage multicast associations
or anycast using the replace security association facility. Robust
support for multiparty security associations will require additional
management functionality for each party joining in such an
association.
The PDU format portion of each description currently consists of a
list of fields, precise definitions will be developed in subsequent
drafts. It is expected that an IKMP PDU consists of initial fixed
fields for SAID and PDU type followed by Type/Length/Value (TLV)
encoding of the optional elements.
2.0 Initial Setup PDUs
2.1 Establish Security Association
This PDU is sent by the initiator of an SA to the peer entity to begin
creation of a security association. It contains the SAID (security
association identifier) that the initiator will use to reference the
security association, an identifier for the key management approach
being used, the key management information (including certificate
information), and an optional authenticator.
Where public key based algorithms are used, or where entity
information is contained in public key certificates, certificate
validation information may be included in this PDU. Certificate
validation information includes the complete certification path along
with current CRLs. An entity may include a subset of this information
if there is reason to believe that the peer already possesses some of
the information (e.g. if they share a common CA).
The Key Management (KM) algorithm is assumed to either have been
agreed, to be a default, or to have been negotiated previously.
PDU CONTENTS:
PDU Type
My SAID
KM Algorithm (Registered value or OID)
KM info (variable)
2.2 Security Association Establishment Response
This PDU is sent in response to an establish security association PDU.
It contains the corresponding key management information, if required,
the responder's SAID, and an optional authenticator. If the key
management algorithm requires more than two PDUs, multiple SAER PDUs
may be exchanged.
PDU CONTENTS:
PDU Type
My SAID
Your SAID
KM algorithm (registered value or OID)
KM information
3.0 SA Management PDUs
Security Association Management PDUs are sent to report problems or to
control attributes of security association. Services include
reporting the receipt of a IPSP PDU with an unrecognized SAID,
reporting the deletion of an SA, reporting the presence of an IPSP
intermediate system, replacing a security association and negotiation
attributes and options for IPSP or IKMP.
Management PDUs must be authenticated and may also require
confidentiality. This is achieved by either encrypting the PDU
contents or by signing the PDU. The signature (i.e., authenticator)
may include information needed to validate the digital signature (such
as a certification path) if that information is not otherwise present.
Encrypting the PDU is the preferred approach when the PDU refers to an
existing SA while signed management PDUs may be used for other cases.
The attribute negotiation PDU may also be used prior to SA
establishment to negotiation the key management algorithm to be used.
In this instance the PDU must be signed.
3.1 No Security Association
This PDU is used when IPSP receives a PDU with an unrecognized SAID.
If authenticated, this PDU is signed.
PDU CONTENTS:
PDU Type
Unrecognized SAID
Authenticator
3.2 Delete Security Association
This PDU is sent to notify the peer of a security association that one
party is terminating the association. The peer is expected to also
delete the SA. This PDU should be sent encrypted in the referenced
SA.
PDU CONTENTS:
PDU Type
Your SAID
Ciphertext {
PDU Type
Your SAID
My SAID
ICV }
(the encryption function is assumed to prepend any required IV and
to perform any necessary padding)
3.3 Peer Discovery
This PDU is sent when an intermediate system which performs IPSP
processing on behalf of entities behind the IS intercepts an SA PDU
intended for one of those entities. This PDU should be authenticated
and should, if possible, contain authenticated information confirming
that the IS is a valid surrogate for the intended destination.
PDU CONTENTS:
PDU Type
Your SAID
My ID
Intended Destination
Authenticated Delegation Information
3.4 Replace Security Association
This PDU is sent when one party to a SA wishes to replace the security
association. This may be required to support changing the traffic
key, changing a SA attribute, or changing the SAID. This PDU should
be sent encrypted in the referenced SA. The request indicates whether
to continue to use the existing attributes and key with the new SAID
or whether to invoke a new key management operation and/or renegotiate
attributes.
If the purpose of the new SA is to change the traffic key, the PDU may
also contain a new key encrypted with the old key.
PDU CONTENTS:
PDU Type
Your SAID
Ciphertext {
PDU Type
Your SAID
My SAID
My New SAID
New Attribute flag
New Key flag
New Key Data (optional)
ICV }
3.5 Attribute Negotiation
This PDU is sent to negotiate parameters and options for a security
association. This is the means of determining the specific algorithms
and options used by IPSP or by another security protocol/application
using IKMP (e.g. encryption algorithm, integrity algorithm, use of
labels, use of sequence numbers, protocol format).
Negotiation is performed through the exchange of option lists. Each
entry contains an option identifier, type, and option value(s). The
option identifier is a registered value indicating the option being
negotiated (e.g. security protocol ID, encryption algorithm). Options
may be of two types: preference lists and choices. Option values are
registered values indicating a specific choice for an option
identifier (e.g. IPSP version 1, DES-CBC).
For preference lists, the sender lists alternative option values in
order of preference. The responder must choose one. Examples of a
preference list might be encryption or key management algorithms.
Choices are characterized as a MANDATORY, PREFERRED, or SUPPORTED
capability. These options are compared with the attribute negotiation
PDU recipient's corresponding choices. Any Mandatory choice must be
used or the security association is terminated. A Preferred choice is
used if the recipient supports it. A Supported choice is used if the
recipient prefers or mandates it. An option mandated by the recipient
which is not present results in a terminated security association.
The attribute negotiation PDU may also be used to convey additional
authorization information about the entity used by IPSP processing.
Such information might include authenticated topology information or
authenticated attribute information.
If attribute negotiation takes place after SA establishment, the
negotiation PDU contents are encrypted. If it is used to negotiate
key management algorithms, it is authenticated.
Negotiation PDUs contain sequence numbers that are used to detect
replay of PDUs and to support acknowledgment/confirmation services.
3.5.1 SA Attribute Negotiation
PDU CONTENTS:
PDU Type
Your SAID
Ciphertext {
PDU Type
Sequence Number
Your SAID
My SAID
Option List
Option Identifier, Option Type, Option Value(s)
Additional Info
ICV }
3.5.2 KM Algorithm Negotiation
PDU CONTENTS:
PDU Type
Your SAID
PDU Type
Sequence Number
Your SAID
My SAID
Option List
Option Identifier, Option Type, Option Value(s)
Authenticator
3.6 Commit/Acknowledge
This PDU is sent to confirm the last change to a security association.
PDU CONTENTS:
PDU Type
Your SAID
Ciphertext {
PDU Type
Sequence Number
Last Received Sequence Number
Your SAID
My SAID
ICV }