IPSEC Working Group Douglas Maughan, Barbara Patrick, Mark Schertler
INTERNET-DRAFT National Security Agency
draft-nsa-isakmp-00.txt,.ps March 20, 1995
Internet Security Association and Key Management Protocol (ISAKMP)
Abstract
This memo describes a combination of security concepts and
protocols for establishing Security Associations (SA) and
cryptographic keys in an Internet environment. A Security
Association Protocol which negotiates, establishes, modifies
and deletes Security Associations and their attributes is
required for an evolving Internet, where there will be numerous
security mechanisms and several options for each security
mechanism. The key management protocol must be robust in order
to handle public key generation for the Internet community at
large and private key requirements for those enclaves with that
requirement.
The Internet Security Association and Key Management Protocol
(ISAKMP) defines the procedures for authenticating a
communicating peer, creation and management of Security
Associations, key generation techniques, and an anti-clogging
mechanism, all of which are necessary to establish and maintain
secure communications (via IPSP or any other security protocol)
in an Internet environment.
Status of this memo
This document is being submitted to the IETF Internet Protocol Security
(IPSEC) Working Group for consideration as a method for the establish-
ment and management of security associations and their appropriate se-
curity attributes. Additionally, this document proposes a method for
key management to support IPSP and IPv6. Publication of this document
does not imply acceptance of the concepts discussed by the IPSEC Working
Group. Comments are solicited and should be addressed to the authors
and/or the working group mailing list at ipsec@ans.net.
This document is an Internet Draft. Internet Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), it Areas, and its
Working Groups. Note that other groups may also distribute working doc-
uments as Internet Drafts.
INTERNET-DRAFT ISAKMP March 20, 1995
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other doc-
uments at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as ``working draft'' or
``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this document is unlimited.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 2]
INTERNET-DRAFT ISAKMP March 20, 1995
1 Introduction
This document describes the use of a combination of security concepts
and protocols to provide the desired security for government, commer-
cial, and private users of the Internet. We identify the necessary com-
ponents to provide security for communications in the Internet, provide
detailed descriptions of each of these components along with the algo-
rithms and mechanisms to realize the expected security associated with
these components, and outline possible scenarios that include these com-
ponents.
1.1 Authentication
A very important step in establishing secure communications is authenti-
cation of the entity at the other end of the communication. There are
many authentication mechanisms for this purpose. An example of weak au-
thentication is the use of passwords. Digital signatures such as the
Digital Signature Standard (DSS) and Rivest-Shamir-Adleman (RSA) sig-
nature are public key based strong authentication mechanisms that re-
quire a trusted third party to sign and properly distribute certifi-
cates. Kerberos is an example of an authentication system that relies
on a trusted third party during the authentication. ISAKMP must al-
low a party initiating communications to indicate which authentication
mechanism it is using and support the message exchanges required by that
mechanism.
Certificates bind a specific identity (host, network, user, application)
to public keys, privileges, clearances, compartments and other security-
related information. Certificates are an essential part of strong au-
thentication mechanisms. There must be an infrastructure available to
verify, manage and distribute certificates. There is currently work
going on in industry to develop X.500 Directory Services which would
provide X.509 certificates to users. There has also been work done in
this area by the NIST Public Key Infrastructure Working Group. Alter-
natively, if no infrastructure exists, the PGP Web of Trust could be
used to provide user authentication in a community of users who know and
trust each other.
ISAKMP does not specify a specific certificate authority or type (i.e.
X.509 certificates), but it must allow the identification of different
certificate authorities and types and facilitate the exchange of the
chosen certificate type. This protocol will support the use of a vari-
ety of digital signatures to provide the strong authentication function.
The DSS and RSA are examples of digital signatures which will provide
that strong authentication. There are many others, as well. Details of
DSS, RSA, and other signature algorithms may be found in [Schn94].
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 3]
INTERNET-DRAFT ISAKMP March 20, 1995
1.2 Security Associations and Management
A Security Association (SA) is a relationship between two or more enti-
ties. The relationship describes how the entities will utilize security
services to communicate securely. This relationship is represented by
a set of information that can be considered a contract between the en-
tities. The information must be agreed upon and shared between all the
entities. Sometimes the information alone is referred to as an SA, but
this is just a physical instantiation of the existing relationship. The
existence of the relationship, represented by the information, is what
allows the entities to communicate securely. All entities must adhere
to the SA for secure communications to be possible. The Security Asso-
ciation Identifier (SAID) is a pointer or identifier an entity uses to
name the SA.
The types of information needed to represent an SA include, but are not
limited to, authentication mechanisms, cryptographic algorithms, al-
gorithm mode, key length, Initialization Vector (IV), integrity mech-
anisms, hash algorithms, etc. . ISAKMP allows communicating entities to
negotiate the information needed to create an SA. The protocol includes
the ability to establish, modify and delete an SA and negotiate the SA
attributes.
NOTE: See Appendix B for initial list of SA attributes.
1.3 Public Key Cryptography
In an Internet environment with large numbers of users, there are many
ways those users can interconnect. There are also many key management
techniques and algorithms available to the users of the network. All
users will not choose the same combination of capabilities. There-
fore, users need a way to determine the capabilities of the entities
with which they want to communicate. ISAKMP is intended to provide that
service.
Because of the large number of different ways Internet users can con-
nect, the use of public key cryptography is the most flexible and effi-
cient way for users to obtain the keys they need.
There are two methods for using public key cryptography to place keys.
In the first method, user A generates a random key. The random key is
then encrypted, using a public key algorithm (e.g. RSA), with user B's
public key. The encrypted random key is then sent to user B. In the
second method, users A and B use a public key algorithm (e.g. Diffie-
Hellman) to exchange public information. They then each use the other's
public information along with their own secret keys to compute the same
value which they use as the session key or the key encryption key for
encrypting the session key.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 4]
INTERNET-DRAFT ISAKMP March 20, 1995
If public key cryptography is used in this way for exchanging or agree-
ing upon a new key each time they communicate, then both back traffic
protection and perfect forward secrecy will be provided. Each key is
independent and the compromise of one key will not automatically com-
promise any other keys. The second method described above is preferred
as the key used for encrypting messages is based on information held by
both A and B.
1.4 Back Traffic Protection / Perfect Forward Secrecy
The concept of back traffic protection is concerned with the crypto-
graphic protection of previous traffic, even when cryptographic keys
used to encrypt future traffic are compromised. The use of public key
cryptography for the establishment of cryptographic keys provides back
traffic protection. The difficulty of numerical factoring of large num-
bers has proven that cryptographic keys can protect information for a
considerable length of time. However, this is based on the assumption
that keys used for protection of communications are destroyed after use
and not kept for any reason. This concept of back traffic protection is
provided by the independent generation of each key such that subsequent
keys are not dependent on any previous key.
The concept of perfect forward secrecy is aimed at guaranteeing future
communications are cryptographically protected, even in the event of
compromise of current cryptographic keys. This concept of perfect for-
ward secrecy is provided by the independent generation of each key such
that subsequent keys are not dependent on any previous key.
1.5 Anti-Clogging
Of the numerous security services available, protection against denial
of service always seems to be one of the most difficult to address.
Phil Karn in his Internet-Draft [Karn94] has introduced a mechanism to
provide a measure of denial of service protection through the use of a
''cookie'' exchange. This anti-clogging token exchange (ACTE) is aimed
at protecting the computing resources from attack without spending ex-
cessive CPU resources to determine its authenticity. As described in
[Karn94], an exchange prior to CPU-intensive public key operations can
thwart some denial of service attempts (e.g. simple flooding with bo-
gus IP source addresses). As noted by Karn, absolute protection against
denial of service is impossible, but this anti-clogging token exchange
provides a technique for making it easier to handle.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 5]
INTERNET-DRAFT ISAKMP March 20, 1995
1.6 Multicast Communications
While it is envisioned that future communications will increasingly be
of a multicast nature, this document is addressing security and key man-
agement for unicast communications. It is expected that multicast com-
munications will require the same security services as unicast commu-
nications and may introduce the need for additional security services.
Upon agreement and implementation of security mechanisms for the uni-
cast Internet community, we fully intend to examine any additional se-
curity requirements for multicast communications. For an introduction
to the issues related to multicast security consult the Internet Drafts,
[Spar94a] and [Spar94b], describing Sparta's research in this area.
2 Description of the Protocol
The Internet Security Association and Key Management Protocol (ISAKMP)
is not a single protocol, but a combination of cryptographic techniques,
mechanisms, and protocols. This coalition is designed to provide max-
imum flexibility, while providing the requisite security. The ISAKMP
consists of four components that can be applied in various combinations
to provide security services according to a stated requirement. The
four components of the ISAKMP are listed below in no particular order:
o A strong authentication exchange.
o An anti-clogging token exchange (ACTE) similar to the work
presented in [Karn94].
o A Security Association Management Protocol (SAMP) based on the IEEE
Key Management Protocol (KMP).
o A public key exchange to establish a session key for communications
using conventional encryption.
The ordering of these ISAKMP components to create a specific protocol
exchange is called a scenario. Scenarios depicting possible component
orderings are given in section 8 with a high-level state diagram given
in appendix A.
2.1 General Packet Format
ISAKMP has a specific header format, described below, followed by the
component dependent payload formats.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 6]
INTERNET-DRAFT ISAKMP March 20, 1995
__________________
|____SAID_(32)____|
|__Scenario_(8)___|
|Payload_Type_(8)_|
|_____Payload_____|
ISAKMP Packet Format
1. SAID - The SAID field indicates a predefined SAID that is used to
determine the key generation and/or the authentication method in
those scenarios that require this information prior to SA
negotiation. For scenarios that start with an SA negotiation this
field is set to a default of TBD.
2. Scenerio - The scenario indicator is encoded in this field.
(a) Authenticated Clear Setup: 01h.
(b) Authenticated Protected Setup: 02h.
(c) Negotiated Clear Setup: 03h.
(d) Anonymous Setup: 04h.
3. Payload Type - The component of the ISAKMP exchange is encoded in
this field.
(a) Authentication: 01h.
(b) SAMP: 02h
(c) Key Exchange: 03h.
(d) Anti-clogging token: 04h.
4. Payload - The format of the payload as defined in the following
sections.
The following sections describe the details of each component of the
ISAKMP.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 7]
INTERNET-DRAFT ISAKMP March 20, 1995
3 Strong Authentication Details
This section specifies the encoding of the payload of the ISAKMP PDU for
the authentication component.
_______________________________
|_Authentication_Authority_(16)_|
|____Authentication_Type_(8)___ |
|__________Length_(8)__________ |
|______Authentication_Data_____ |
Authentication Payload Format
1. Authentication Authority - This field encodes the party that
generated the certificates used for authentication.
PGP certificates based on the ''web of trust'' have a standard en-
coding. Other third party certificate authorities must be assigned
an identifier by the Internet Assigned Numbers Authority (IANA).
PGP certificate - 0001h
Examples of third party certificate authorities that would have
to register for an identifier are RSA Commercial Certificate
Authority (https://www_csc.rsa.com/netsite), the Stable Large E-mail
Database (SLED) (http://www.four11.com) and the U.S. Postal
Service.
2. Authentication Type - This field indicates the authentication
payload format.
RSA certificates
PGP certificates
DSS certificates
X.509 certificates
Other certificate formats
3. Length - Length of the Authentication Data field in bytes.
4. Authentication Data - This field contains the actual authentication
data. The certificates as indicated by the Authentication type
field. Examples are RSA, PGP, and DSS certificates.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 8]
INTERNET-DRAFT ISAKMP March 20, 1995
4 Anti-Clogging Token Exchange Details
This section will detail the Anti-Clogging Token Exchange (ACTE) out-
lined in Phil Karn's Internet Draft [Karn94].
5 Security Association Management Protocol
This section describes the SAMP component of ISAKMP and payload format
for each SA service. The SAMP component provides the ability to estab-
lish (including negotiation), modify, and delete Security Associations
and their attributes. The SAMP services are listed below:
1. SA Negotiation.
2. SA Commit.
3. SA Modify.
4. SA Delete.
The SAMP payload format is the same for all the SAMP services, but de-
pending on the type of SA service provided all the fields may not be
present. Those fields not present for a service are defined in sections
5.1 through 5.4.
_____________________
|__SA_Indicator_(4)__ |
|____SA_Flags_(4)____ |
|_SAID_Initiator_(32)_|
|_SAID_Responder_(32)_|
|____SA_Attributes___ |
SAMP Payload Format
1. SA Indicator - This field encodes the SA service carried in the
SAMP payload.
(a) SA Negotiation: 1h.
(b) SA Commit: 2h.
(c) SA Modify: 3h.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 9]
INTERNET-DRAFT ISAKMP March 20, 1995
(d) SA Delete: 4h.
2. SA Flags - This field encodes flags specific to an SA service.
3. SAID Initiator - The SAID used by the initiating entity to uniquely
identify an SA within its local system.
4. SAID Responder - The SAID used by the responding entity to uniquely
identify an SA within its local system.
5. SA Attributes - A list of SA attributes. SA Attribute
specifications are discussed in section 5.1.1.
5.1 SA Negotiation
The SA negotiation service allows the initiating entity to present a
series of SA attributes, that it wishes to use for secure communica-
tions, to a responding entity. Each attribute may contain a number of
options presented in priority order. The responding entity must choose
the highest priority option it can support for each attribute. The re-
sponding entity sends back the SA attribute list with the option it has
chosen for each attribute.
Example:
(Letters are SA Attributes and Numbers are options for the attributes.)
Initiating entity sends (A:1,2,3; B:1,2; C:2,3,4) to responding entity.
Responding entity sends back (A:3; B:1; C:3) to initiating entity.
Another option for exchanging SA Attributes for negotiation is to
present the sets of attributes with a single option that would represent
the SA. The sets are presented in priority order. The responding entity
would choose the highest priority set of which it can support the option
for each attribute. This method of presenting SA Attributes for nego-
tiation has the possibility of having a number of sets presented that
differ only slightly. The advantage to this presentation method is that
SA Attribute combinations that are illegal cannot be choosen by the re-
sponding entity.
Example:
(Letters are SA Attributes and Numbers are the option for the at-
tribute.)
Initiating entity sends (A2,B2,C4; A3,B1,C3; A1,B2,C2) to responding
entity.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 10]
INTERNET-DRAFT ISAKMP March 20, 1995
Responding entity sends back (A3,B1,C3) to initiating entity.
If the responding entity cannot support any option for a particular at-
tribute, it can respond with a NULL and an SA will not be established.
The responding entity may also provide a single alternative for any of
the SA attributes for which it can't support the offered options. The
initiating entity may choose to accept the alternative offered using the
SA Commit service, see section 5.2. If the initiating party does not
accept the alternative offered by the responding entity an SA is not es-
tablished.
The SA Negotiation must use all fields in the SAMP payload.
The SAID Initiator field is set by the initiating entity on the first
negotiation exchange. The responding entity cannot change this field.
The SAID Responder field is set by the responding entity on the second
negotiation exchange. The initiating entity cannot change this field.
The SA Flags field can be set by the entity that initiates the negotia-
tion to indicate that the SA commit service will be performed following
negotiation. If the initiating entity sets the flag the responding en-
tity may not reset it. If the initiating entity does not set the flag
the responding entity may set it, thereby forcing the initiating entity
to issue an SA Commit. If neither entity sets the flag then the SA Com-
mit service shall not be invoked.
5.1.1 SA Attributes
SA attributes are listed in Appendix B. This is an initial set of at-
tributes to begin discussion. The final set of SA attributes should
be defined in a separate RFC so additions or modifications to the at-
tributes do not require a modification to the protocol RFC and visa
versa. An SA object and SA attributes should become part of the MIB,
see [RFC-1213], on a special branch called the SMIB. This puts ISAKMP
in line with the SNMP concept of separate RFCs for the protocol and the
information managed. SA attributes will be defined using the syntax in
[RFC-1155] and [RFC-1212].
5.2 SA Commit
The SA Commit service allows an initiating entity to send a commitment
to the responding entity after negotiations are complete. This informs
the responding party that the initiating party agrees to the SA and se-
cure communications can begin. This service is optional when the re-
sponding entity selected the options offered by the initiating party.
It is required when the responding party request this service when it
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 11]
INTERNET-DRAFT ISAKMP March 20, 1995
presents alternatives to the SA attributes offered. Section 5.1 con-
tains the details on how to set the SA Flags field within an SA Negotia-
tion payload in order to request this service.
The SA Flags field is set to a NOT USED default of TBD.
The SAID Initiator field and SAID Responder field must contain the re-
spective SAIDs set during the SA Negotiation Service.
The SA Commit service will not have the SA Attributes field in the SAMP
payload.
5.3 SA Modify
The SA Modify service provides the ability to update an existing SA.
The SA Modify must use all fields in the SAMP payload.
The SAID Initiator field and SAID Responder field must contain the re-
spective SAIDs that are being modified.
The SA Attributes field contains only those attributes being updated.
5.4 SA Delete
The SA Delete service informs the remote entity that the SA within the
local system of the initiating entity is being deleted.
The SAID Initiator field and SAID Responder field must contain the SAIDs
that correspond to the SA being deleted.
The SA Delete service will not have the SA Attributes field in the SAMP
payload.
6 Key Exchange Details
A variety of key exchanges can be supported by this protocol. Some ex-
amples of key exchanges which may be used in this protocol are Diffie-
Hellman, the enhanced Diffie-Hellman key exchange described in X9.42
[ANSI94], the key exchange on the FORTEZZA card, and the RSA-based key
exchange used by PGP. This protocol will also support the government key
escrow requirement, but does not mandate its use.
The encoding of the ISAKMP payload for the key exchange is dependent on
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 12]
INTERNET-DRAFT ISAKMP March 20, 1995
the specific key exchange and therefore is not specified in this Inter-
net draft. When a key exchange is registered in the SMIB, see 5.1.1,
its field specifications must also be registered so the appropriate
parsers can be constructed to process the exchange.
7 Concatenation Details
The Authentication and Key Exchange payloads can be concatenated to-
gether in the scenarios described in sections 8.2.2, 8.2.3, and 8.2.4.
This requires an additional payload type (SAUTH-KE) in the ISAKMP
header. This is provided to limit the number of exchanges and speed-up
SA establishment. Additional concatenations of components will be con-
sidered as long as they do not compromise security or negate the benefit
of a set-up scenario.
8 Protocol Scenarios
8.1 Introduction
Sections 3 through 6 provide the details of the four components of
ISAKMP. This section describes a number of scenarios or exchanges that
can be built from these four components. The scenarios highlight the
positive aspect of having 4 protocol components whose order of exchange
is flexible. Each scenario provides a different type of protection and
security attribute negotiation and each is suitable for a different sit-
uation. The benefits and constraints to each scenario are also pre-
sented. There are three categories of exchanges: SA Establishment or
Setup, SA Modification and SA Deletion. The SA Establishment category
presents six basic protocol component exchanges orderings that are pos-
sible using the four components. The SA Modification and SA Deletion
categories each have one scenario. None of these scenarios is mandated.
All of these scenarios have positive aspects that make them preferable
under circumstances that benefit from their strengths.
8.2 SA Establishment Scenarios
8.2.1 Authenticated Clear Setup
This scenario provides the capability to do a strong authentication ex-
change prior to establishing any additional security relevant informa-
tion. Once the authentication is complete, the SAMP is initiated to es-
tablish the security association attributes and key exchange parameters
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 13]
INTERNET-DRAFT ISAKMP March 20, 1995
for the ensuing communications. The Key Exchange is then performed us-
ing these negotiated parameters (e.g. Algorithm ID, algorithm mode, key
length, etc.).
The benefit of this scenario is that it allows the negotiation of the
security association and key exchange parameters in a strongly authenti-
cated mode.
The constraint to this scenario is that the authentication mechanism
must be known prior to communications and the security attribute estab-
lishment is not encrypted. Once the is SA established it can be used to
renegotiate security attributes which are encrypted.
To Be Done: SAuth -> SAMP -> KE State Table
8.2.2 Authenticated Protected Setup
This scenario provides the capability to do a strong authentication ex-
change and key exchange prior to establishing any additional security
relevant information. Upon successful completion of both the authen-
tication and key exchange, the security attributes are negotiated using
the SAMP.
The benefit of this scenario is that the negotiation of the security as-
sociation attributes is both strongly authenticated and cryptographi-
cally protected.
The constraint to this scenario is that the authentication mechanism and
key exchange parameters must be known prior to communications.
To Be Done: SAuth -> KE -> SAMP State Table
8.2.3 Negotiated Clear Setup
This scenario allows the negotiation of security relevant information,
including the authentication mechanism and key exchange technique, using
the SAMP. After the negotiation of the security attributes, the strong
authentication and key exchange are performed. Once the strong authen-
tication and key exchange are complete the SA Commit service of the SAMP
component may be re-issued to provide cryptographically protected con-
firmation of the SA attributes.
This scenario allows all attributes of the future communication to be
negotiated. The benefit of this scenario is that two entities who both
are capable of providing security, but have never ''met'' before, can
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 14]
INTERNET-DRAFT ISAKMP March 20, 1995
establish an SA. When connecting to a remote entity with which there is
no pre-placed SA, to allow authentication or key exchange, this scenario
provides the ability to attempt to establish an SA in-band, rather than
having to use an out-of-band method such as the telephone, fax, or mail.
The constraint to this scenario is that the SAMP negotiation is com-
pletely unprotected and the actual identity of the communicating peer
is not known until the authentication is performed.
To Be Done: SAMP -> SAuth -> KE State Table
8.2.4 Negotiated Clear Setup with Anti-Clogging
This scenario adds the anti-clogging technique to the beginning of the
scenario presented in section 8.2.3.
The added benefit of this scenario is the protection against denial of
service, provided by the anti-clogging technique, prior to the negotia-
tion phase.
The additional constraint to this scenario is the added exchange to
perform the anti-clogging technique. Additionally, this anti-clogging
technique provides only limited denial of service protection.
To Be Done: ACTE -> SAMP -> SAuth -> KE State Table
8.2.5 Anonymous Setup
This scenario performs the key exchange technique followed by the strong
authentication mechanism prior to any SAMP negotiation. This scenario
provides anonymity for the initiating entity and full cryptographic pro-
tection of all exchanges as well as strongly authenticated communica-
tions.
The benefit of this scenario is the ability to communicate with a per-
son with whom you've pre-established encryption and authentication at-
tributes without disclosing your or their identity to passive attack-
ers on the network. Also, the security attribute negotiation is crypto-
graphically protected.
The constraint to this scenario is that the authentication mechanism and
key exchange parameters must be known prior to communications.
To Be Done: KE -> SAuth -> SAMP State Table
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 15]
INTERNET-DRAFT ISAKMP March 20, 1995
8.2.6 Anonymous Setup with Anti-Clogging
This scenario adds the anti-clogging technique to the beginning of the
scenario presented in section 8.2.5.
The added benefit of this scenario is the protection against denial of
service, provided by the anti-clogging technique, prior to the key ex-
change technique.
The additional constraint to this scenario is the added exchange to
perform the anti-clogging technique. Additionally, this anti-clogging
technique provides only limited denial of service protection.
To Be Done: ACTE -> KE -> SAuth -> SAMP State Table
8.3 SA Modification Scenario
The procedure for modifying an SA using the ISAKMP components will be
described in this section.
8.4 SA Deletion Scenario
The procedure for deleting an SA using the ISAKMP components will be
described in this section.
9 Conclusions
A Protocol State Diagram
B Security Association Attributes
This appendix is an exact copy of an e-mail message [Kent94] to the
IPSEC mail list from Steve Kent and is reproduced here to start a dis-
cussion on SA attributes. Inclusion in this appendix is not a wholesale
endorsement.
The following is a set of possible parameters for each security
association (SA), e.g., candidate MIB data items where each SA
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 16]
INTERNET-DRAFT ISAKMP March 20, 1995
has its own MIB entry. They may be negotiated or pre-determined,
but all are important for each SA in the most general case.
SAID.INBOUND
SAID.OUTBOUND
These variables contain the SAIDs for this SA and thus are
used to select this MIB entry for IPSP protected traffic.
ENCAPSULATION
This Boolean indicates whether IPSP is used to encapsulate
packets on this SA. If TRUE, then encapsulation is employed,
otherwise packets are not encapsulated.
INBOUND-CRITERIA
This data structure specifies the checking applied to
inbound packet received on this SA before releasing the packets
to the client. Each data item is either null, or is a value
against which the inbound packet is checked. If encapsulation is
employed, the checks are applied to the encapsulated header(s),
otherwise the checks are applied to the outer header(s). {needs
work, e.g., to express star names}
IP-DESTINATION-ADDRESS
IP-SOURCE-ADDRESS
NEXT-PROTOCOL
IP-SECURITY-LABEL
TRANSPORT-DESTINATION-PORT
TRANSPORT-SOURCE-PORT
PEER-ADDRESS
This variable specifies the IP address of the IPSPE that
defines the other end of the SA. For a multicast SA, this is an
IP multicast address.
ENCRYPTION
This data structure provides the parameters required for
provision of a connectionless confidentiality service, if
employed for this SA.
ENABLED
This is a Boolean and is TRUE if encryption is to be
employed for this SA.
ALGORTIHM
This is a structured, IANA-registered algorithm ID that
also specifies the mode of use, e.g., DES-CBC or DES-EDE2-CBC, or
DES-CFB-8.
KEY.INBOUND
KEY.OUTBOUD
If the same key is used for encryption in both
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 17]
INTERNET-DRAFT ISAKMP March 20, 1995
directions, then the values are the same for both of these
variables, otherwise different values must be present. (For some
algorithms and modes, this value may be an interchange key, and
the key to be used to decrypt an individual packet may encrypted
by this key and carried in the packet in the manner of an IV.)
The size of the key is determined by ENCRYPTION.ALGORITHM and if
a multi-key algorithm mode is employed, e.g., DES-EDE, all of the
keys for a given direction are stored in the appropriate
variable, and the algorithm mode specifies how each key is
extracted from the variable.
IV.INBOUND
IV.OUTBOUND
If the algorithm and mode require use of an IV, and if
the IV (or a portion thereof) is constant for the SA, then these
per-SA values are stored here. The size of these variable and
the portion used in forming an IV is determined by
ENCRYPTION.ALGORITHM.
INTEGRITY
This data structure contains all of the parameters required
for provision of a connectionless integrity service, if employed
for this SA.
ENABLED
This is a Boolean that is TRUE if an integrity
transformation is applied for this SA.
PLAINTEXT
This value is TRUE if the integrity transformation is
applied to plaintext, and is FALSE if it is applied to
ciphertext; FALSE may be selected only if ENCRYPTION.ENABLED =
TRUE
DIRECTION.ENABLED
This is a Boolean that is TRUE if a direction flag is used
in packets.
DIRECTION.VALUE
This is a Boolean that specifies the one-bit direction
flag value inserted into outbound packets. The value is
meaningful only if INTEGRITY.DIRECTION.ENABLED is TRUE.
ALGORITHM
This is a structured, IANA-registered algorithm ID that
specifies the integrity algorithm employed and the mode of use,
e.g., MD5, MD5-keyed, SHA, DES-MAC, etc.
KEY.OUTBOUND
KEY.INBOUND
These items have meaning only if a keyed integrity
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 18]
INTERNET-DRAFT ISAKMP March 20, 1995
function is employed, as defined in INTEGRITY.ALGORITHM. If
ENCRYPTION.ENABLED = FALSE, then a keyed integrity function must
be employed, if INTEGRITY.ENABLED = TRUE. If the same key is used
in both directions, then these variables have the same value,
otherwise different values must be present. The size of key is a
function of the algorithm selected in INTEGRITY.ALGORIHTM and if
a multi-key algorithm mode is employed, all of the keys for a
given direction are stored in the appropriate variable, and the
algorithm mode specifies how each key is extracted from the
variable.
COMPRESSION
This data structure provides parameters required for
provision of compression (and corresponding decompression) of
plaintext data.
ENABLED
This Boolean is TRUE if compression is to be applied to
traffic on this SA.
ALGORITHM
This is a structured, IANA-registered algorithm ID that
specifies the compression algorithm employed.
REPLAY
This data structure provides the parameters required for
provision of replay countermeasures, if employed for this SA.
ENABLED
This Boolean is TRUE if a sequence number is included
in each outbound packet and is checked on each inbound packet for
this SA.
SIZE
This item defines the size of sequence number,
expressed in 16-bit words. {we could bound this at 64 bits}
NUMBER.OUTBOUND
This is the value of the sequence number to be assigned
to next outbound packet. The size of this variable is determined
by REPLAY.SIZE.
NUMBER.INBOUND
This is the sequence number expected in next inbound
packet; if an integrity checked packet arrives with a sequence
number greater than or equal to this value, the variable is
updated to be one greater than that received value, and
REPLAY.WINDOW is updated to reflect the received packet sequence
number.
WINDOW.SIZE
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 19]
INTERNET-DRAFT ISAKMP March 20, 1995
This is the size of the window within which late
arriving packets will be checked for duplication. {we could fix
this value, or allow it to be only one of a few small values,
e.g., 32/64/128, rather than allowing arbitrary window sizes}
WINDOW
This is logically an array of packet sequence numbers
for packets received within the current window. Its dimension is
REPLAY.WINDOW.SIZE. It may be implemented as a bit map, rather
than an array of sequence numbers, using OR operations and end-
off shifts to efficiently manage the list. It is checked only
when a packet arrives with a sequence number less than
REPLAY.NUMBER.INBOUND and greater than REPLAY.NUMBER.INBOUND -
REPLAY.WINDOW.SIZE + 1 (since all sequence numbers less than this
are, by definition, too old). It is updated every time a
sequence numbered packet is received
FRAGMENTATION
This data structure provides the parameters required for
provision of denial of service protection with regard to attacks
exploiting the fragmentation features of IP.
INBOUND
If FALSE, no fragments are accepted on inbound traffic,
otherwise fragments are acceptable for inbound traffic.
OUTBOUND
If FALSE, no fragments may be transmitted by the IPSPE
(unless encapsulated), otherwise fragments may be transmitted.
KEY-MANAGEMENT
This data structure provides the key management parameters
associated with this SA.
NEGOTIATED
If TRUE, then IKMP is used to negotiate the key
management technique for this SA. If FALSE, a pre-defined key
management technique is used.
TECHNIQUE
This variable specifies the key management technique
used for this SA. The identifier used here is structured, e.g.,
to specify symmetric vs. asymmetric techniques, and is IANA
registered.
PARAMETERS
Technique-specific parameters ???
REKEY
This data structure indicates what criteria are used to
determine when a new key must be established for this traffic
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 20]
INTERNET-DRAFT ISAKMP March 20, 1995
flow. When a new key is established, the traffic will be
migrated to a new SA, identified by the NEXT.SA pointer below.
GRACE
This is the time value (in seconds) that incoming
traffic is permitted to be processed on the old SA after a new SA
has been established, in response to a rekey.
NEXT-SA
This is a pointer to the data structure for the
new SA to which traffic will be routed when the rekey is
complete.
TIME-BASED
This data structure contains variables for time
based rekey management.
ENABLE
This Boolean is TRUE if time-based rekey
management is employed.
TRIGGER
This is a local time value that specifies
when a new key and SAID should be created, after which the
traffic for this SA will be transferred to the new SAI. This
variable should be zero unless this IPSPE initiated the SA and
unless REKEY.TIME-BASED.ENABLE is TRUE. {is this an acceptable
simplification, or should either end be able to initiate a
rekey?}
TRAFFIC-BASED
This structure contains parameters for traffic-
based rekey control.
ENABLE
This Boolean is TRUE if traffic-based rekey
management is employed.
PACKET-COUNT.INBOUND
PACKET-COUNT.OUTBOUND
These are counters for traffic that will be
used to trigger a rekey. They are maintained only if
REKEY.TRAFFIC-BASED.ENABLE is TRUE.
TRIGGER.INBOUND
TRIGGER.OUTBOUND
These are values that are compared against
the packet counters to trigger a rekey. They are non-zero only if
REKEY.TRAFFIC-BASED.ENABLE is TRUE.
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 21]
INTERNET-DRAFT ISAKMP March 20, 1995
Security Considerations
This Internet Draft presents a Security Association and Key Management
Protocol. Cryptographic mechanisms require keys to provide data con-
fidentiality and authentication services on a network. Secure communi-
cations may utilize a variety of security services and mechanisms. The
ability to choose from a variety of security services and mechanisms and
to exchange attributes required by the mechanisms is important to secu-
rity in the complex structure of the Internet. Therefore it is essen-
tial to secure communications to provide a Security Association Protocol
capability on the Internet.
Acknowledgements
Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with La-
TeX.
References
[ANSI94] ANSI, X9.42: Public Key Cryptography Using Irreversible
Algorithms for the Financial Services Industry -- Management of
Symmetric Keys Using Diffie-Hellman, Draft, September, 1994.
[Karn94] Phil Karn, The Photuris Key Management Protocol,
Internet-Draft, December, 1994.
[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10,
1994.
[RFC-1155] Rose M. and K. McCloghrie, Structure and Identification of
Management Information for TCP/IP-based Internets, RFC-1155, May,
1990.
[RFC-1212] McCloghrie K. and M. Rose, Concise MIB Definitions,
RFC-1212-, March 26, 1991.
[RFC-1213] McCloghrie K. and M. Rose, Management Information Base for
Network Management of TCP/IP-based Internets: MIB-II, RFC-1213,
March 26, 1991.
[Schn94] Bruce Schneier, Applied Cryptography - Protocols, Algorithms,
and Source Code in C, John Wiley & Sons, Inc., 1994.
[Spar94a] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management
(GKMP) Architecture, SPARTA, Inc., Internet-Draft, September,
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 22]
INTERNET-DRAFT ISAKMP March 20, 1995
1994.
[Spar94b] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management
(GKMP) Specification, SPARTA, Inc., Internet-Draft, September,
1994.
Addresses of Authors
The three authors are with:
National Security Agency
ATTN: R2
9800 Savage Road
Ft. Meade, MD. 20755-6000
Douglas Maughan
Phone: 301-688-0847
E-mail:wdmaugh@tycho.ncsc.mil
Barbara Patrick
Phone: 301-688-0298
E-mail:bspatri@orion.ncsc.mil
Mark Schertler
Phone: 301-688-0849
E-mail:mjs@tycho.ncsc.mil
Maughan/Patrick/Schertler draft-nsa-isakmp-00.txt,.ps [Page 23]