[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Key Management Requirements
Key Management Requirements
>In an earlier note, Perry mentioned that you had a list of
>requirements for an Internet key management protocol.
>I was only able to attend one of the ipsec meetings, and
>I did not hear your list of requirements. If it is not
>too much typing, would you consider sending out your list
>for the consideration of others on this list (e.g, me)?
>
>Thanks,
>Charlie P.
Here are our Key Management requirements.
>To: ipsec@ans.net
>Cc: solo@BBN.COM
>Subject: IPSEC KM Requirements
>Date: Sun, 06 Feb 94 17:25:28 -0500
>From: solo@BBN.COM
>
>
>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.