< draft-ietf-ipsec-isakmp-02.txt		draft-ietf-ipsec-isakmp-03.txt >
	IPSEC Working Group Douglas Maughan, Barbara Patrick, Mark Schertler		IPSEC Working Group Douglas Maughan, Mark Schertler
	INTERNET-DRAFT National Security Agency		INTERNET-DRAFT National Security Agency
	draft-ietf-ipsec-isakmp-02.txt, .ps October 31, 1995		draft-ietf-ipsec-isakmp-03.txt, .ps November 21, 1995
	Internet Security Association and Key Management Protocol (ISAKMP)		Internet Security Association and Key Management Protocol (ISAKMP)
	Abstract		Abstract
	This memo describes a protocol utilizing security concepts		This memo describes a protocol utilizing security concepts
	necessary for establishing Security Associations (SA) and crypto-		necessary for establishing Security Associations (SA) and crypto-
	graphic keys in an Internet environment. A Security Association		graphic keys in an Internet environment. A Security Association
	protocol that negotiates, establishes, modifies and deletes		protocol that negotiates, establishes, modifies and deletes
	Security Associations and their attributes is required for an		Security Associations and their attributes is required for an
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	To learn the current status of any Internet-Draft, please check the ``1id-		To learn the current status of any Internet-Draft, please check the ``1id-
	abstracts.txt'' listing contained in the Internet- Drafts Shadow Di-		abstracts.txt'' listing contained in the Internet- Drafts Shadow Di-
	rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe),		rectories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
	ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).		ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
	Distribution of this document is unlimited.		Distribution of this document is unlimited.
	Contents		Contents
	1 Introduction 4		1 Introduction 5
			1.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1.1Certificate Authorities . . . . . . . . . . . . . . . . . . . 6
			1.1.2Entity Naming . . . . . . . . . . . . . . . . . . . . . . . . 7
			1.1.3ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 7
			1.2 Security Associations and Management . . . . . . . . . . . . . . 8
			1.2.1Security Associations and Registration . . . . . . . . . . . . 8
			1.2.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 8
			1.3 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 9
			1.3.1Key Exchange Properties . . . . . . . . . . . . . . . . . . . 9
			1.3.2ISAKMP Requirements . . . . . . . . . . . . . . . . . . . . . 11
			1.4 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . . . . 11
			1.4.1Anti-Clogging (Denial of Service) . . . . . . . . . . . . . . 11
			1.4.2Connection Hijacking . . . . . . . . . . . . . . . . . . . . . 11
			1.4.3Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 11
			1.5 Multicast Communications . . . . . . . . . . . . . . . . . . . . 12
	1.2 Security Associations and Management . . . . . . . . . . . . . . 5		2 Description of the Protocol 12
			2.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 13
			2.1.1General Message Processing . . . . . . . . . . . . . . . . . . 15
			2.2 ISAKMP Packet Exchanges . . . . . . . . . . . . . . . . . . . . . 17
			2.2.1Base Exchange . . . . . . . . . . . . . . . . . . . . . . . . 17
			2.2.2Identity Protection Exchange . . . . . . . . . . . . . . . . . 17
			2.2.3Authentication Only Exchange . . . . . . . . . . . . . . . . . 18
			2.3 ISAKMP Details . . . . . . . . . . . . . . . . . . . . . . . . . 19
			2.3.1Security Association Attributes . . . . . . . . . . . . . . . 19
			2.3.2Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 21
			2.3.3RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 21
			2.3.4Anti-Clogging Token (``Cookie'') Creation . . . . . . . . . . 21
			2.3.5SA Flags Field . . . . . . . . . . . . . . . . . . . . . . . . 22
			3 Security Association Establishment 22
			3.1 Security Association Initialization . . . . . . . . . . . . . . . 22
			3.1.1SA Initialization Procedures . . . . . . . . . . . . . . . . . 24
			3.2 Authentication and Key Exchange . . . . . . . . . . . . . . . . . 25
			3.2.1Authentication Payload Format . . . . . . . . . . . . . . . . 26
			3.2.2Key Exchange Payload Format . . . . . . . . . . . . . . . . . 28
			3.2.3Authentication and Key Exchange Procedures . . . . . . . . . . 29
			3.3 Security Association Negotiation . . . . . . . . . . . . . . . . 30
			3.3.1SA Negotiation Procedures . . . . . . . . . . . . . . . . . . 31
			3.4 SA Negotiation Conclusion . . . . . . . . . . . . . . . . . . . . 34
			3.4.1SA Negotiation Conclusion Procedures . . . . . . . . . . . . . 34
	1.3 Public Key Cryptography . . . . . . . . . . . . . . . . . . . . . 5		4 Security Association Modification 36
			4.1 Modification Procedures . . . . . . . . . . . . . . . . . . . . . 36
			5 Security Association Deletion 36
			5.1 Deletion Procedures . . . . . . . . . . . . . . . . . . . . . . . 37
	1.4 Back Traffic Protection / Perfect Forward Secrecy . . . . . . . . 6		6 Notification Message 39
			6.1 Notification Procedures . . . . . . . . . . . . . . . . . . . . . 40
	1.5 Anti-Clogging . . . . . . . . . . . . . . . . . . . . . . . . . . 6		7 Conclusions 41
	1.5.1Anti-Clogging Token Creation . . . . . . . . . . . . . . . . . 7		A ISAKMP Scenarios 43
			A.1 Initial ISAKMP Daemon Scenerio . . . . . . . . . . . . . . . . . 43
			A.2 Virtual Private Network Scenario . . . . . . . . . . . . . . . . 44
			B Security Association Attributes 47
	1.6 Multicast Communications . . . . . . . . . . . . . . . . . . . . 7		C Security Association Examples 51
			C.1 ISAKMP SA Definition . . . . . . . . . . . . . . . . . . . . . . 51
			C.1.1ISAKMP SA Examples . . . . . . . . . . . . . . . . . . . . . . 52
			C.2 ESP SA and AH SA Definitions . . . . . . . . . . . . . . . . . . 53
			C.2.1ESP and AH SA Examples . . . . . . . . . . . . . . . . . . . . 54
			C.2.2Fortezza SA Examples . . . . . . . . . . . . . . . . . . . . . 55
	2 Description of the Protocol 8		1 Introduction
	2.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . 8		This document describes an Internet Security Association and Key Manage-
			ment Protocol (ISAKMP). ISAKMP combines the security concepts of authen-
			tication, key management, and security associations to establish the re-
			quired security for government, commercial, and private communications on
			the Internet. ISAKMP extends the assertion in [DOW92] that authentica-
			tion and key exchanges must be combined for better security to include se-
			curity association exchanges. The security required for communications
			depends on the individual network configurations and environments. Orga-
			nizations are setting up Virtual Private Networks (VPN) that will require
			one set of security functions for communications within the VPN and possi-
			bly many different security functions for communications outside the VPN
			to support geographically separate organizational components, customers,
			suppliers, sub-contractors (with their own VPNs), government, and others.
			Departments within large organizations may require a number of security
			associations to separate and protect data (e.g. personnel data, company
			proprietary data, medical) on internal networks and other security associ-
			ations to communicate inter-department. Nomadic users wanting to ``phone
			home'' represent another set of security requirements. These requirements
			must be tempered with bandwidth challenges. Smaller groups of people may
			meet their security requirements by setting up ``Webs of Trust''. ISAKMP
			exchanges provide these assorted networking communities the ability to
			present peers with the security functionality it supports in an authen-
			ticated and protected manner for agreement upon a common interoperable se-
			curity association.
	2.1.1General Message Processing . . . . . . . . . . . . . . . . . . 10		Security associations must support different encryption algorithms, au-
			thentication mechanisms, and key establishment algorithms for other secu-
			rity protocols, as well as IP Security. Security associations must also
			support host-oriented certificates for lower layer protocols and user-
			oriented certificates for higher level protocols. Algorithm and mecha-
			nism independence is required in applications such as e-mail, remote lo-
			gin, and file transfer, as well as in session oriented protocols, routing
			protocols, and link layer protocols. ISAKMP provides a common security
			association and key establishment protocol for this wide range of security
			protocols, applications, security requirements, and network environments.
	2.2 ISAKMP Details . . . . . . . . . . . . . . . . . . . . . . . . . 11		ISAKMP is not bound to any specific cryptographic algorithm, key gener-
			ation technique, or security mechanism. This flexibility is beneficial
			for a number of reasons. First, it supports the dynamic communications
			environment described above. Second, the independence from specific secu-
			rity mechanisms and algorithms provides a forward migration path to better
			mechanisms and algorithms. When improved security mechanisms are devel-
			oped or new attacks against current encryption algorithms, authentica-
			tion mechanisms and key exchanges are discovered, ISAKMP will allow the
			updating of the algorithms and mechanisms without having to develop a com-
			pletely new KMP or patch the current one.
	2.2.1Security Association Attributes . . . . . . . . . . . . . . . 11		ISAKMP has basic requirements for its authentication and key exchanges
			components. These requirements guard against denial of service, replay /
			reflection, man-in-the-middle, and connection hijacking attacks. This is
			important because these are the types of attacks that are targeted against
			protocols. Complete Security Association (SA) support, which provides
			mechanism and algorithm independence, and protection from protocol threats
			are the strengths of ISAKMP.
	2.2.2Transport Protocol . . . . . . . . . . . . . . . . . . . . . . 13		1.1 Authentication
	2.2.3RESERVED Fields . . . . . . . . . . . . . . . . . . . . . . . 14		A very important step in establishing secure network communications is au-
			thentication of the entity at the other end of the communication. Many
			authentication mechanisms are available. Authentication mechanisms fall
			into two catagories of strength - weak and strong. Passwords are an exam-
			ple of a mechanism that provides weak authentication. Reasons for this
			include the fact that most users pick easy to guess passwords and when
			used over an unprotected network are easily read by network sniffers.
			Digital signatures, such as the Digital Signature Standard (DSS) and the
			Rivest-Shamir-Adleman (RSA) signature, are public key based strong authen-
			tication mechanisms. When using digital signatures each entity requires a
			public and a private key. Certificates are an essential part of a digital
			signature authentication mechanism. Certificates bind a specific enti-
			ties identity (be it host, network, user, or application) to its public
			keys and possibly other security-related information such as privileges,
			clearances, and compartments. Authentication based on digital signatures
			requires a trusted third party or certificate authority to create, sign
			and properly distribute certificates. For more detailed information on
			digital signatures, such as DSS and RSA, and certificates see [Schn94].
	2.3 Security Association Establishment . . . . . . . . . . . . . . . 14		1.1.1 Certificate Authorities
	2.3.1Security Association Initialization . . . . . . . . . . . . . 14		Certificates require an infrastructure for generation, verification, man-
			agement and distribution. The Internet Policy Registration Authority
			(IPRA) [RFC-1422] has been established to direct this infrastructure for
			the IETF. The IPRA certifies Policy Certification Authorities (PCA). PCAs
			control Certificate Authorities (CA) which certify users and subordinate
			entities. Current certificate related work includes the Domain Name Sys-
			tem (DNS) Security Extensions [EK94] which will provide signed entity keys
			in the DNS. The Public Key Infrastucture (PKIX) working group is speci-
			fying an Internet profile for X.509 certificates. There is also work go-
			ing on in industry to develop X.500 Directory Services which would provide
			X.509 certificates to users. The U.S. Post Office is developing a (CA)
			hierarchy. The NIST Public Key Infrastructure Working Group has also been
			doing work in this area. The DOD Multi Level Information System Security
			Initiative (MISSI) program has begun deploying a certificate infrastruc-
			ture for the U.S. Government. Alternatively, if no infrastructure exists,
			the PGP Web of Trust certificates can be used to provide user authentica-
			tion and privacy in a community of users who know and trust each other.
	2.3.2Key and Authentication Phase . . . . . . . . . . . . . . . . . 16		1.1.2 Entity Naming
	2.3.3Security Association Negotiation Phase . . . . . . . . . . . . 22		An entity's name is its identity and is bound to its public keys in cer-
			tificates. The CA MUST define the naming semantics for the certificates
			it issues. See the UNINETT PCA Policy Statements [Berg] for an example
			of how a CA defines its naming policy. When the certificate is verified,
			the name is verified and that name will have meaning within the realm of
			that CA. An example is the DNS security extensions which make DNS servers
			CAs for the zones and nodes they serve. Resource records are provided for
			public keys and signatures on those keys. The names associatied with the
			keys are IP addresses and domain names which have meaning to entities ac-
			cessing the DNS for this information. A Web of Trust is another example.
			When webs of trust are set up, names are bound with the public keys. In
			PGP the name is usaully the entities e-mail address which has meaning to
			those, and only those, who understand e-mail (Do MCI and AOL e-mail ad-
			dresses tell the casual e-mailer anything about identity?). Another web
			could use an entirely different naming scheme.
	2.3.4Packet Exchanges . . . . . . . . . . . . . . . . . . . . . . . 25		1.1.3 ISAKMP Requirements
	2.4 Security Association Modification . . . . . . . . . . . . . . . . 26		Strong authentication MUST be provided on ISAKMP exchanges. Without being
			able to authenticate the entity at the other end, the Security Association
			(SA) and session key established are suspect. Without authentication you
			are unable to trust an entity's identification, this makes access control
			questionable. Encryption (e.g. ESP) and integrity (e.g. AH) will pro-
			tect subsequent communications from passive eavesdroppers, but the SA and
			key may be established with an adversary who performed an active man-in-
			the-middle attack and is now stealing all your personnal data.
	2.5 Security Association Deletion . . . . . . . . . . . . . . . . . . 27		A digital signature algorithm MUST be used within ISAKMP's authentication
			component. However, ISAKMP does not mandate a specific mechanism. ISAKMP
			allows an entity initiating communications to indicate which signature al-
			gorithms it supports. After selection of a common algorithm, the protocol
			provides the messages required to support the actual authentication ex-
			change. As an example, if the DSA is selected as the signature algorithm,
			then the protocol provides a facility for identification of different cer-
			tificate authorities, certificate types (e.g. X.509v1 certificates, PKCS
			#7), and the exchange of the certificates identified.
	2.6 Notification Message . . . . . . . . . . . . . . . . . . . . . . 28		ISAKMP utilizes digital signatures, based on public cryptography, for au-
			thentication. There are other strong authentication systems available,
			which could be specified as additional optional authentication mechanisms
			for ISAKMP. Some of these authentication systems rely on a trusted third
			party called a key distribution center (KDC) to distribute secret session
			keys. An example is Kerberos, where the trusted third party is the Ker-
			beros server, which holds secret keys for all clients and servers within
			it's network domain. A clients proof it holds it's secret key provides
			its authenticaton to a server.
	3 Conclusions 29		The ISAKMP specification does not specify the protocol for communicating
	A Key Exchange Examples 30		with the trusted third parties (TTP) or certificate directory services.
			These protocols are defined by the TTP and directory service themselves
			and are outside the scope of this specification.
	A.1 Photuris KE . . . . . . . . . . . . . . . . . . . . . . . . . . . 30		1.2 Security Associations and Management
	A.2 FORTEZZA Key Exchange Algorithm (KEA) . . . . . . . . . . . . . . 30		A Security Association (SA) is a relationship between two or more entities
			that describes how the entities will utilize security services to communi-
			cate securely. This relationship is represented by a set of information
			that can be considered a contract between the entities. 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 in-
			stantiation of the existing relationship. The existence of this relation-
			ship, represented by the information, is what provides the agreed upon se-
			curity information needed by entities to securely interoperate. All enti-
			ties must adhere to the SA for secure communications to be possible. When
			accessing SA attributes, entities use a pointer or identifier refered to
			as the Security Parameter Index (SPI).
	B Security Association Attributes 32		1.2.1 Security Associations and Registration
	1 Introduction
	This document describes an Internet Security Association and Key Manage-		The SA attributes required and recommended for the IP Security (AH, ESP)
	ment Protocol (ISAKMP). ISAKMP combines the security concepts of authenti-		are defined in [RFC-1825]. The attributes specified for an IP Security SA
	cation, key management, and security associations to establish the desired		include, but are not limited to, authentication mechanism, cryptographic
	security for government, commercial, and private communications on the In-		algorithm, algorithm mode, key length, and Initialization Vector (IV).
	ternet. ISAKMP does not bind itself to any specific cryptographic algo-		Other protocols that provide algorithm and mechanism independent security
	rithm, key generation technique, or security mechanism. This flexibility		MUST define their SA attributes requirements. The separation of ISAKMP
	is beneficial because new attacks are constantly being developed that make		from a specific SA definition is important to ensure ISAKMP can establish
	today's security certainties obsolete. ISAKMP will guard against denial		SAs for all possible security protocols and applications.
	of service, replay, and connection hijacking attacks. This is important
	because these are the types of attacks that are targeted against proto-
	cols. Independence from specific security mechanisms that will eventually
	be replaced by better ones and protection from protocol threats are the
	strengths of ISAKMP.
	1.1 Authentication		NOTE: See Appendix B for a discussion of SA attributes that should be con-
			sidered when defining a security protocol or application.
	A very important step in establishing secure communications is authentica-		In order to facilitate easy identification of specific attributes (e.g.
	tion of the entity at the other end of the communication. There are many		a specific encryption algorithm) among different network entites the at-
	authentication mechanisms for this purpose. An example of weak authen-		tributes must be assigned identifiers and these identifiers must be reg-
	tication is the use of passwords. Digital signatures such as the Digi-		istered by a central authority. The Internet Assigned Numbers Authority
	tal Signature Standard (DSS) and Rivest-Shamir-Adleman (RSA) signature are		(IANA) provides this function for the Internet.
	public key based strong authentication mechanisms that require a trusted
	third party to sign and properly distribute certificates. Kerberos is an
	example of an authentication system that relies on a trusted third party
	during the authentication. ISAKMP allows a party initiating communica-
	tions 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)		1.2.2 ISAKMP Requirements
	to public keys, privileges, clearances, compartments and other security-
	related information. Certificates are an essential part of strong authen-
	tication mechanisms. There must be an infrastructure available to verify,
	manage and distribute certificates. Currently, Domain Name System (DNS)
	Security Extensions [EK94] are being developed which will provide signed
	host keys in DNS. There is also work going on in industry to develop X.500
	Directory Services which would provide X.509 certificates to users. The
	NIST Public Key Infrastructure Working Group has also been doing work in
	this area. Alternatively, 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 (e.g.		Security Association (SA) establishment MUST be part of the key manage-
	X.509 certificates), but it must allow the identification of different		ment protocol defined for IP based networks. The SA concept is required
	certificate authorities and types and facilitate the exchange of the cho-		to support security protocols in a diverse and dynamic networking envi-
	sen certificate type. This protocol supports the use of a variety of dig-		ronment. Just as authentication and key exchange must be linked to pro-
	ital signatures to provide the strong authentication function. The DSS		vide assurance that the key is established with the authenticated party
	and RSA are examples of digital signatures which provide strong authenti-		[DOW92], SA establishment must be linked with the authentication and the
	cation. There are many others, as well. Details of DSS, RSA, and other		key exchange protocol.
	signature algorithms may be found in [Schn94].
	1.2 Security Associations and Management		ISAKMP provides the protocol exchanges to establish a security association
			between entities. First, an initial protocol exchange allows a basic set
			of security attributes to be agreed upon. This basic set provides protec-
			tion for subsequent ISAKMP exchanges. It also indicates the authentica-
			tion method and key exchange that will be performed as part of the ISAKMP
			protocol. If a basic set of security attributes is already in place on
			the communicating entities the initial ISAKMP exchange may be skipped and
			the key and authentication exchanges issued directly. After the basic set
			of security attributes has been agreed upon, initial identity authenti-
			cated, and required keys generated, another security attribute exchange
			takes place to establish the complete SA which will be used for subsequent
			communications by the entity that invoked ISAKMP. The basic set of SA at-
			tributes that MUST be implemented to provide ISAKMP interoperability are
			defined in Appendix C. *These atributes will be moved to a separate docu-
			ment to maintain separation of protocol and attributes.*
	A Security Association (SA) is a relationship between two or more enti-		1.3 Public Key Cryptography
	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 entities.
	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 en-
	tities to communicate securely. All entities must adhere to the SA for
	secure communications to be possible. The Security Parameter Index (SPI)
	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		Public key cryptography is the most flexible, scalable, and efficient way
	limited to, authentication mechanisms, cryptographic algorithms, algorithm		for users to obtain the shared secrets and session keys needed to support
	mode, key length, Initialization Vector (IV), integrity mechanisms, hash		the large number of ways Internet users will interoperate. Many key gen-
	algorithms, etc. . ISAKMP allows communicating entities to negotiate the		eration algorithms, that have different properties, are available to users
	information needed to create an SA. It includes the ability to establish,		(see [DOW92] and [ANSI94]). Properties of key exchange protocols include
	modify and delete an SA and negotiate the SA attributes.		the key establishment method, authentication, symmetry, perfect forward
			secrecy, and back traffic protection.
	NOTE: See Appendix B for example lists of SA attributes.		1.3.1 Key Exchange Properties
	1.3 Public Key Cryptography		Key Establishment (Key Generation / Key Transport) The two common methods
			of using public key cryptography for key establishment are key transport
			and key generation. An example of key transport is the use of the RSA al-
			gorithm to encrypt a randomly generated session key (for encrypting subse-
			quent communications) with the recipient's public key. The encrypted ran-
			dom key is then sent to the recipient, who decrypts it using his private
			key. At this point both sides have the same session key, however it was
			created based on input from only one side of the communications. The ben-
			efit of the key transport method is that it has less computational over-
			head then the following method. The Diffie-Hellman (D-H) algorithm illus-
			trates key generation using public key cryptography. The D-H algorithm is
			begun by two users exchanging public information. Each user then mathe-
			matically combines the other's public information along with their own se-
			cret information to compute a shared secret value. This secret value can
			be used as a session key or as a key encryption key for encrypting a ran-
			domly generated session key. This method generates a session key based on
			public and secret information held by both users. The benefit of the D-H
			algorithm is that the key used for encrypting messages is based on infor-
			mation held by both users. Assuming checks for weak values neither party
			can force the session key to a predetermined value. Detailed descrip-
			tions of these algorithms can be found in [Schn94]. There are a number
			of variations on these two key generation schemes and these variations do
			not necessarily interoperate.
	In an Internet environment with large numbers of users, there are many		Key Exchange Authentication Key exchanges may be authenticated during the
	ways those users can interconnect. There are also many key management		protocol or after protocol completion. Authentication of the key exchange
	techniques and algorithms available to the users of the network. All		during the protocol is provide when each party provides proof it has the
	users will not choose the same combination of capabilities. Therefore,		secret session key before the end of the protocol. Proof can be provided
	users need a way to determine the capabilities of the entities with which		by encrypting known data in the secret session key during the protocol ex-
	they want to communicate. ISAKMP is intended to provide that service.		change. Authentication after the protocol must occur in subsequent commu-
			nications. Authentication during the protocol is preferred so subsequent
			communications are not initiated if the secret session key is not estab-
			lished with the desired party.
	Because of the large number of different ways Internet users can connect,		Key Exchange Symmetry A key exchange provides symmetry if either party can
	the use of public key cryptography is the most flexible and efficient way		initiate the exchange and exchanged messages can cross in transit with-
	for users to obtain the keys they need.		out effecting the key that is generated. This is desirable so that com-
			putation of the keys does not require either party to know who initiated
			the exchange. While key exchange symmetry is desirable, symmetry in the
			entire KMP may provide a vulnerablity to reflection attacks. The entire
			ISAKMP SA establishment is asymetrical.
	There are two methods for using public key cryptography to place keys. In		Back Traffic Protection / Perfect Forward Secrecy Perfect forward secrecy
	the first method, user A generates a random key. The random key is then		is provided by a key exchange protocol if disclosure of long-term cryp-
	encrypted, using a public key algorithm (e.g. RSA), with user B's pub-		tographic keying material (e.g. public signature keys) does not compro-
	lic key. The encrypted random key is then sent to user B. In the second		mise previously generated keys. Back traffic protection is provided by
	method, users A and B use a public key algorithm (e.g. Diffie-Hellman) to		the independent generation of each key such that subsequent keys are not
	exchange public information. Then, they each use the other's public in-		dependent on any previous key. There is a subtle difference. Past ses-
	formation along with their own secret keys to compute the same value which		sion keys will NOT be obtainable is the long-term key is compromised in
	they use as the session key or the key encryption key for encrypting the		perfect forward secrecy; Past session keys will NOT be obtainable if the
	session key.		current session key is compromised in back traffic protecion.
	If public key cryptography is used in this way for exchanging or agree-		The difficulty of numerical factoring of large numbers has proven that
	ing upon a new key each time they communicate, then both back traffic pro-		cryptographic keys can protect information for a considerable length of
	tection and perfect forward secrecy will be provided. Each key is inde-		time. However, this is based on the assumption that keys used for protec-
	pendent and the compromise of one key will not automatically compromise		tion of communications are destroyed after use and not kept for any rea-
	any other keys. The second method described above is preferred as the key		son.
	used for encrypting messages is based on information held by both A and B.
	1.4 Back Traffic Protection / Perfect Forward Secrecy		1.3.2 ISAKMP Requirements
	The concept of back traffic protection is concerned with the cryptographic		An authenticate key exchange MUST be supported by ISAKMP. Users SHOULD
	protection of previous traffic, even when cryptographic keys used to en-		choose additional key establishment algorithms based on their require-
	crypt future traffic are compromised. The use of public key cryptography		ments. ISAKMP does not specify a specific key exchange. Requirements
	for the establishment of cryptographic keys provides back traffic protec-		that should be evaluated when choosing a key establishment algorithm in-
	tion. The difficulty of numerical factoring of large numbers has proven		clude establishment method (generation vs. transport), perfect forward
	that cryptographic keys can protect information for a considerable length		secrecy, back traffic protection, computational overhead, key escrow, and
	of time. However, this is based on the assumption that keys used for pro-		key strength. Based on user requirements, ISAKMP allows an entity initi-
	tection of communications are destroyed after use and not kept for any		ating communications to indicate which key exchanges it supports. After
	reason. This concept of back traffic protection is provided by the inde-		selection of a key exchange, the protocol provides the messages required
	pendent generation of each key such that subsequent keys are not dependent		to support the actual key establishment.
	on any previous key.
	The concept of perfect forward secrecy is aimed at guaranteeing future		1.4 ISAKMP Protection
	communications are cryptographically protected, even in the event of com-
	promise of current cryptographic keys. This concept of perfect forward
	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		1.4.1 Anti-Clogging (Denial of Service)
	Of the numerous security services available, protection against denial		Of the numerous security services available, protection against denial
	of service always seems to be one of the most difficult to address. Phil		of service always seems to be one of the most difficult to address. Phil
	Karn in his Internet-Draft [Karn95] has introduced a mechanism to provide		Karn in his Internet-Draft [Karn95] has introduced a mechanism to provide
	a measure of denial of service protection through the use of a ``cookie''		a measure of denial of service protection through the use of a ``cookie''
	exchange. This anti-clogging token (ACT) is aimed at protecting the com-		exchange. This anti-clogging token (ACT) is aimed at protecting the com-
	puting resources from attack without spending excessive CPU resources to		puting resources from attack without spending excessive CPU resources to
	determine its authenticity. As described in [Karn95], an exchange prior		determine its authenticity. As described in [Karn95], an exchange prior
	to CPU-intensive public key operations can thwart some denial of service		to CPU-intensive public key operations can thwart some denial of service
	attempts (e.g. simple flooding with bogus IP source addresses). As noted		attempts (e.g. simple flooding with bogus IP source addresses). As noted
	by Karn, absolute protection against denial of service is impossible, but		by Karn, absolute protection against denial of service is impossible, but
	this anti-clogging token provides a technique for making it easier to han-		this anti-clogging token provides a technique for making it easier to han-
	dle.		dle.
	1.5.1 Anti-Clogging Token Creation		1.4.2 Connection Hijacking
	Phil Karn's Internet Draft [Karn95] states that cookie generation is im-
	plementation dependent, but must satisfy some basic requirements:
	1. The cookie must depend on the specific parties. This prevents
	an attacker from obtaining a cookie using a real IP address and
	UDP port, and then using it to swamp the victim with Diffie-
	Hellman requests from randomly chosen IP addresses or ports.
	2. It must not be possible for anyone other than the issuing		ISAKMP prevents connection hijacking by linking the authentication, key
	entity to generate cookies that will be accepted by that		exchange and security association exchanges. This linking prevent an at-
	entity. This implies that the issuing entity must use local		tacker from allowing the authentication to complete and then jumping in
	secret information in the generation and subsequent		and impersonating one entity to the other during the key and security as-
	verification of a cookie. It must not be possible to deduce		sociation exchanges.
	this secret information from any particular cookie.
	3. The cookie generation function must be fast to thwart attacks		1.4.3 Man-in-the-Middle Attacks
	intended to sabotage CPU resources.
	Karn's suggested method for creating the cookie is to perform a fast hash		Man-in-the-Middle attacks include interception, insertion, deletion, and
	(e.g. MD5) over the IP Source and Destination Address, the UDP Source and		modification of messages, reflecting messages back at the sender, re-
	Destination Ports and a locally generated secret random value. ISAKMP		playing old messages and redirecting messages. ISAKMP features prevent
	requires that the cookie be unique for each SA establishment, SA modify		these types of attacks from being successful. The linking of the ISAKMP
	and SA delete to help prevent replay attacks, therefore we suggest adding		exchanges prevents the insertion of messages in the protocol exchange.
	the date and time to the information hashed.		The ISAKMP protocol state machine is defined so deleted messages will not
			cause a partial SA to be created, the state machine will clear all state
			and return to idle. The state machine also prevents reflection of a mes-
			sage from causing harm. The requirement for a new cookie with time vari-
			ant material for each new SA establishment prevents attacks that involve
			replaying old messages. The ISAKMP strong authentication requirement pre-
			vents an SA from being established with other then the intended party.
			Messages may be redirected to a different destination or modified but this
			will be detected and an SA will not be established. The ISAKMP specifica-
			tion defines where abnormal processing has occurred and recommends notify-
			ing the appropriate party of this abnormality.
	1.6 Multicast Communications		1.5 Multicast Communications
	While future communications will increasingly be of a multicast nature,		While future Internet communications will increasingly be of a multicast
	this document is presenting a security association and key management		nature, this document is presenting a security association and key man-
	protocol from the unicast point of view. It is expected that multicast		agement protocol from the unicast point of view. It is expected that mul-
	communications will require the same security services as unicast commu-		ticast communications will require the same security services as unicast
	nications and may introduce the need for additional security services.		communications and may introduce the need for additional security ser-
	The issues of distributing SPIs for multicast traffic are presented in		vices. The issues of distributing SPIs for multicast traffic are pre-
	[Atki95]. Upon agreement and implementation of a security association		sented in [RFC-1825]. Upon agreement and implementation of a security
	protocol for the Internet unicast environment, we fully intend to examine		association protocol for the Internet unicast environment, we fully intend
	any additional security requirements for multicast communications. For		to examine any additional security requirements for multicast communica-
	an introduction to the issues related to multicast security consult the		tions. For an introduction to the issues related to multicast security
	Internet Drafts, [Spar94a] and [Spar94b], describing Sparta's research in		consult the Internet Drafts, [Spar94a] and [Spar94b], describing Sparta's
	this area.		research in this area.
	2 Description of the Protocol		2 Description of the Protocol
	The Internet Security Association and Key Management Protocol (ISAKMP) de-		The Internet Security Association and Key Management Protocol (ISAKMP) de-
	fines procedures and packet formats to establish (including negotiate),		fines procedures and packet formats to establish, negotiate, modify and
	modify and delete Security Associations (SA). SAs contain all the infor-		delete Security Associations (SA). SAs contain all the information re-
	mation required for execution of IP security services, such as the IP Au-		quired for execution of IP security services, such as the IP Authentica-
	thentication Header (AH), the IP Encapsulating Security Payload (ESP), and		tion Header (AH), the IP Encapsulating Security Payload (ESP), and routing
	routing protocol authentication mechanisms. ISAKMP includes packet for-		protocol authentication mechanisms. ISAKMP includes packet formats for
	mats for exchanging key generation and authentication data. These formats		exchanging key generation and authentication data. These formats provide
	provide a consistent method of transferring key and authentication data		a consistent method of transferring key and authentication data that is
	that is independent of the key generation technique, encryption algorithm		independent of the key generation technique, encryption algorithm or au-
	or authentication mechanism. These generic packets provide flexibility by		thentication mechanism.
	allowing the protocol to be independent of key generation techniques and
	authentication mechanisms used to establish SAs.
	The following sections contain the details of ISAKMP. Sections 2.1 through		The following sections contain the details of ISAKMP. Sections 2.1 through
	2.2 cover details that are pertinent to the entire protocol. Sections 2.3		2.3 cover details that are pertinent to the entire protocol. Sections 3
	through 2.6 define the establishment, modification, and deletion services,		through 6 define the establishment, modification, and deletion services,
	defined as exchanges, offered by the protocol. The appendices provide		defined as exchanges, offered by the protocol. The appendices provide
	examples of SAs and key exchanges.		examples of SAs and key exchanges.
	2.1 ISAKMP Header Format		2.1 ISAKMP Header Format
	ISAKMP has a fixed header format. A fixed header simplifies parsing, pro-		ISAKMP has a fixed header format (shown in Figure 1) followed by a vari-
	viding the benefit of less complex and easier to implement parsing soft-		able length payload, optional digital signature, and optional padding. A
	ware. The fixed header contains the information required by the protocol		fixed header simplifies parsing, providing the benefit of protocol parsing
	to maintain state, process payloads and prevent attacks (e.g. denial of		software that is less complex and easier to implement. The fixed header
	service and replay). Based on the message type each header is followed by		contains the information required by the protocol to maintain state, pro-
	a payload specific to the message type. The payload for each message is		cess payloads and prevent attacks (e.g. denial of service and replay).
	define in sections 2.3 through 2.6.		Based on the message type, each header is followed by a payload specific
			to the message type. The payload for each message is defined in sections
			3 through 6. Following the payload portion of the ISAKMP packet is a dig-
			ital signature. This field is dependent on the negotiation of Security
			Association attributes and may not be present.
	0 1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Message Type ! Exchange ! Length !		! Message Type ! Exch ! Vers ! Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! SPI !		! Security Parameter Index (SPI) !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Initiator-Cookie !		! !
	~ ~		~ Initiator-Cookie ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Responder-Cookie !		! !
	~ ~		~ Responder-Cookie ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Payload !		! !
	~ ~		~ Payload ~
			! !
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			! !
			~ Digital Signature ~
			! !
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			! !
			~ Padding ~
	! !		! !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ISAKMP Header Format		Figure 1: ISAKMP Header Format
	o Message Type (1 octet) - Indicates the type of message. A suffix of		o Message Type (1 octet) - Indicates the type of message. A suffix of
	REQ denotes a message of type request and RESP suffix denotes a		REQ denotes a Request message type and an RESP suffix denotes a
	message of type response. The format and processing for each message		Response message type. The format and processing for each message is
	is defined in sections 2.3 through 2.6.		defined in sections 3 through 6.
	__ISAKMP_Message__Message_Type_		__ISAKMP_Message__Message_Type_
			RESERVED 0
	ISA_INIT_REQ 1		ISA_INIT_REQ 1
	ISA_INIT_RESP 2		ISA_INIT_RESP 2
	ISA_KE_REQ 3		ISA_KE_REQ 3
	ISA_KE_RESP 4		ISA_KE_RESP 4
	ISA_AUTH_REQ 5		ISA_AUTH_REQ 5
	ISA_AUTH_RESP 6		ISA_AUTH_RESP 6
	ISA_AUTH&KE_REQ 7		ISA_AUTH&KE_REQ 7
	ISA_AUTH&KE_RESP 8		ISA_AUTH&KE_RESP 8
	ISA_NEG_REQ 9		ISA_NEG_REQ 9
	ISA_NEG_RESP 10		ISA_NEG_RESP 10
	ISA_MODIFY_REQ 11		ISA_MODIFY_REQ 11
	ISA_MODIFY_RESP 12		ISA_MODIFY_RESP 12
	ISA_NOTIFY 13		ISA_NOTIFY 13
	ISA_DELETE 14		ISA_DELETE 14
	ISA_COMMIT 15		ISA_COMMIT 15
			IANA Use 16-127
			Future Use 128-255
	o Exchange (1 octet) - indicates the type of exchange, see Sections		o Exchange (4 bits) - indicates the type of exchange, see section 2.2
	2.3.4 and 2.3.4		for a description of the Message Types exchanged in each of these
			Exchange Types.
	___ISAKMP_Exchange___Exchange_Type__		___ISAKMP_Exchange___Exchange_Type__
			RESERVED 0
	Base 1		Base 1
	Identity Protection 2		Identity Protection 2
			Authentication Only 3
			Future Use 4 - 15
			o Version (4 bits) - indicates the version of the ISAKMP protocol in
			use.
	o Length (2 octets) - Length of total message (header + payload) in		o Length (2 octets) - Length of total message (header + payload) in
	octets.		octets.
	o SPI (4 octets) - Security Parameter Index. The receiving entity's		o SPI (4 octets) - Security Parameter Index. The receiving entity's
	SPI is always in this field, except for the ISA_INIT packets. The		SPI is always in this field, except for the ISA_INIT packets. The
	ISA_INIT packets contain the SPI the issuer expects to receive in all		ISA_INIT packets contain the SPI the initiator expects to receive in
	subsequest packets.		all subsequent packets.
	o Initiator Cookie (16 octets) - Cookie of entity that initiated SA		o Initiator Cookie (16 octets) - Cookie of entity that initiated SA
	establishment, SA modify or SA delete.		establishment, SA modify or SA delete.
	o Responder Cookie (16 octets) - Cookie of entity that is responding to		o Responder Cookie (16 octets) - Cookie of entity that is responding to
	SA establishment, SA modify or SA delete request		an SA establishment, SA modify or SA delete request.
	o Payload (variable) - The format of the payload is based on the		o Payload (variable) - The format of the payload is based on the
	message type and defined in sections 2.3 through 2.6.		message type. These are defined in sections 3 through 6.
			o Signature - The digital signature of the initiator of the ISAKMP
			message. This field will not be included on all packets and will be
			determined by the negotiated SA attributes.
			o Padding - This is an optional field that may be added depending on
			the type of encryption algorithm. If the encryption mechanism is
			based on block encryption, then this field may be necessary to ensure
			the packet is a specific size.
	2.1.1 General Message Processing		2.1.1 General Message Processing
	Every ISAKMP message has basic processing applied to insure protocol re-		Every ISAKMP message has basic processing applied to insure protocol re-
	liability and minimize threats, such as denial of service and replay at-		liability, and to minimize threats, such as denial of service and replay
	tacks.		attacks.
	When issuing an ISAKMP packet:		When transmitting an ISAKMP packet, the transmitting entity (initiator or
			responder) does the following:
	1. Sets a timer and initializes a retry counter		1. Sets a timer and initializes a retry counter.
	2. If timer expires the message is resent and the retry counter		2. If the timer expires, the ISAKMP packet is resent and the retry
	decremented.		counter is decremented.
	3. If the retry counter reaches zero (0), the event is logged in the		3. If the retry counter reaches zero (0), the event, RETRY LIMIT
	appropriate system file.		REACHED, is logged in the appropriate system audit file.
	4. Clears all state and return to IDLE.		4. The ISAKMP protocol machine clears all states and returns to IDLE.
	When an ISAKMP packet is received:		When an ISAKMP packet is received, the receiving entity (initiator or re-
			sponder) does the following:
	1. Verify the appropriate ``cookie''.		1. Verifies the Initiator and Responder ``cookies''. If the cookie
			validation fails, the message is discarded and the following actions
			are taken:
	2. Check exchange type and message fields to confirm they are valid		(a) The event, INVALID COOKIE, is logged in the appropriate system
	types.		audit file.
	3. Check SPI to ensure it is valid for the exchange being preformed.		(b) No response is sent to the initiating entity. This will cause
			the transmission timer of the initiating entity to expire and
			force retransmission of the message.
	4. If any of these fields fails its check, the message is discarded.		2. Check the Message Type field to confirm it is valid. If the Message
			Type field validation fails, the message is discarded and the
			following actions are taken:
	Log Event in the appropriate system file.		(a) The event, INVALID MESSAGE TYPE, is logged in the appropriate
			system audit file.
	No response is sent to the message orginator.		(b) No response is sent to the initiating entity. This will cause
			the transmission timer of the initiating entity to expire and
			force retransmission of the message.
	5. If all fields pass the checks, the message payload is processed.		3. Check the Exchange field to confirm it is valid for the Message Type
			requested. If the Exchange field validation fails, the message is
			discarded and the following actions are taken:
	Individual message processing (described in sections 2.3 through 2.6)		(a) The event, INVALID EXCHANGE TYPE, is logged in the appropriate
	may result in the message being invalidated, in which case:		system audit file.
	Log Event in the appropriate system file.		(b) No response is sent to the initiating entity. This will cause
			the transmission timer of the initiating entity to expire and
			force retransmission of the message.
	No response is sent to the message orginator.		4. Check SPI to ensure it is valid for the Message Type and Exchange
			being performed. If the SPI validation fails, the message is
			discarded and the following actions are taken:
	A valid message results in a response being sent to the message		(a) The event, INVALID SPI, is logged in the appropriate system audit
	orginator.		file.
	2.2 ISAKMP Details		(b) No response is sent to the initiating entity. This will cause
			the transmission timer of the initiating entity to expire and
			force retransmission of the message.
	2.2.1 Security Association Attributes		5. The message payload is processed. Individual message processing is
			described in sections 3 through 6. Depending on the Message Type, a
			valid message results in a response being sent to the transmitting
			entity (message originator). The procedures for sending these
			responses are also outline in sections 3 through 6.
	A Security Association (SA) is a relationship between two enities that		2.2 ISAKMP Packet Exchanges
			The Exchange field in the ISAKMP header currently has three values de-
			fined: the base exchange, the identity protection exchange, and the au-
			thentication only exchange. These exchanges define the flow of the ISAKMP
			packets during SA establishment. The diagrams in 2.2.1, 2.2.2, and 2.2.3
			show the packet exchange ordering for each exchange type and provide basic
			notes describing what has happened after each packet exchange.
			2.2.1 Base Exchange
			Sections 3.1 through 3.3 describe the three basic phases: SA Initial-
			ization, Key Exchange and Authentication, and SA Negotiation, that com-
			prise the base exchange. The base exchange contains the minimum number of
			packet exchanges in order to reduce latency associated with SA establish-
			ment.
			Base Exchange
			____Initiator____Direction_____Responder____ Note
			ISA_INIT_REQ =>
			<= ISA_INIT_RESP
			Basic SA selected
			ISA_AUTH&KE_REQ =>
			<= ISA_AUTH&KE_RESP
			Identity Verified
			Key Generated
			Encryption Begun
			ISA_NEG_REQ =>
			<= ISA_NEG_RESP SA Completed
			(optional) ISA_COMMIT =>
			2.2.2 Identity Protection Exchange
			The identity protection exchange starts and ends the same as the base ex-
			change, but separates the key exchange payload and the authentication pay-
			loads into separate packets. In this exchange, the key exchange is trans-
			mitted first followed by the strong authentication exchange. The benefit
			of this exchange is the ability to communicate with a person without dis-
			closing either party's identity to passive attackers on the network.
			The ISA_KE_REQ and ISA_KE_RESP packets used for the key exchange portion of
			this exchange contain an ISAKMP header followed by the key exchange pay-
			load. The ISA_AUTH_REQ and ISA_AUTH_RESP packet used for the authentication
			portion of this exchange contain an ISAKMP header followed by the authen-
			tication payload.
			Identity Protection Exchange
			__Initiator___Direction___Responder___ Note
			ISA_INIT_REQ =>
			<= ISA_INIT_RESP
			Basic SA selected
			ISA_KE_REQ =>
			<= ISA_KE_RESP
			Key Generated
			Encryption Begun
			ISA_AUTH_REQ =>
			<= ISA_AUTH_RESP
			Identity Verified
			ISA_NEG_REQ =>
			<= ISA_NEG_RESP SA Completed
			(optional) ISA_COMMIT =>
			2.2.3 Authentication Only Exchange
			The authentication only exchange starts and ends the same as the base ex-
			change. In this exchange, the authentication information is the only in-
			formation transmitted. The benefit of this exchange is the ability to
			perform only an authentication exchange without the computational expense
			of computing keys. Using this exchange, none of the transmitted informa-
			tion will be encrypted.
			The ISA_AUTH_REQ and ISA_AUTH_RESP packet used for the authentication only
			exchange contain an ISAKMP header followed by the authentication payload.
			Identity Protection Exchange
			__Initiator___Direction___Responder___ Note
			ISA_INIT_REQ =>
			<= ISA_INIT_RESP
			Basic SA selected
			ISA_AUTH_REQ =>
			<= ISA_AUTH_RESP
			Identity Verified
			ISA_NEG_REQ =>
			<= ISA_NEG_RESP SA Completed
			(optional) ISA_COMMIT =>
			2.3 ISAKMP Details
			2.3.1 Security Association Attributes
			A Security Association (SA) is a relationship between two entities that
	describes how they will utilize security services. This relationship is		describes how they will utilize security services. This relationship is
	represented by a collection of security related information. The SA At-		represented by a collection of security related information. The SA At-
	tributes are the individual elements that comprise all security relevant		tributes are the individual elements that comprise all security relevant
	information necessary to form the SA.		information necessary to form the SA.
	The following syntax encodes the security attributes to be exchanged by		The following syntax defines the security attributes to be exchanged by
	ISAKMP. This syntax is used in the ISA_INIT_REQ, ISA_INIT_RESP, ISA_NEG_REQ,		ISAKMP. This syntax is used in the ISA_INIT_REQ, ISA_INIT_RESP, ISA_NEG_REQ,
	ISA_NEG_RESP, ISA_MOD_REQ, and ISA_MOD_RESP messages. The syntax groups se-		ISA_NEG_RESP, ISA_MOD_REQ, and ISA_MOD_RESP messages. The syntax groups se-
	curity attributes needed to perform a security function into an SA set or		curity attributes needed to perform a security function into either an SA
	SA list format. The set format must be supported by ISAKMP implementa-		set or SA list format. The set format MUST be supported by ISAKMP imple-
	tions. The list format is an optional format.		mentations. The list format is an optional format.
	The set format groups all necessary attributes together. Each set has a		Security Associations Sets The set format groups all necessary attributes
	unique identifier (Set Number), supported security service (Supports),		together. Each set has a unique identifier (Set Number), supported secu-
	such as IP AH, IP ESP, OSPF authentication, and a list of Attribute		rity service (Supports), such as IP AH, IP ESP, OSPF authentication, and
	Classes and Attribute Types. The Attribute Class is the broad category		a list of Attribute Classes and Attribute Types. The Attribute Class is
	of Attribute Type, such as encryption algorithms. Attribute Type is a		the broad category of Attribute Type, such as encryption algorithms. At-
	specific attribute identifier. DES is an example of an attribute type		tribute Type is a specific attribute identifier. DES is an example of an
	for the encryption algorithm attribute class. A set has only one instance		attribute type for the encryption algorithm attribute class. A set has
	of an Attribute Class and one type for that class. This syntax maintains		only one instance of an Attribute Class and one type for that class. This
	flexibility by allowing many different (and some still undefined) types of		syntax maintains flexibility by allowing many different (and some still
	SA attributes to be exchanged.		undefined) types of SA attributes to be exchanged.
	The figure below depicts the syntax for exchanging security attributes us-		Figure 2 depicts the syntax for exchanging security attributes using
	ing the set format. It shows a single set from which multiple sets would		the set format. It shows a single set from which multiple sets would be
	be grouped for a specific message type.		grouped for a specific message type.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Set Number ! Supports ! Number of Attr !		! Set Number ! Supports ! Num of Attr !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Attribute Class ! Attribute Type !		! Attribute Class ! Attribute Type !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ..... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Attribute Class ! Attribute Type !		! Attribute Class ! Attribute Type !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Generic Set Exchange Format		Figure 2: Generic Set Exchange Format
	o Set number (1 octet) - Unique identifier for each proposed set		o Set number (1 octet) - Unique identifier for each proposed set
	o Supports (1 octet) - Security service proposed set supports.		o Supports (2 octets) - Security service proposed set supports.
	Examples are IP AH, IP ESP, and OSPF authentication		Examples are IP AH, IP ESP, and OSPF authentication
	o Number of Attributes (2 octets) - Number of attributes contained in		o Number of Attributes (1 octet) - Number of attribute classes
	the proposed set		contained in the proposed set
	o Attribute Class (2 octets) - examples are Encryption Algorithms, Key		o Attribute Class (2 octets) - examples are Encryption Algorithms, Key
	Exchange Algorithms		Exchange Algorithms, Authentication Mechanisms
	o Attribute Type (2 octets) - examples of attribute type for the		o Attribute Type (2 octets) - examples of attribute types for the
	encryption algorithms attribute class are DES, Triple DES, and IDEA.		encryption algorithms attribute class are DES, Triple DES, and IDEA.
	The size of a set formatted exchange is 4 octets + (Number of Attrs * 4		The size of a set formatted exchange is 4 octets + (Number of Attribute
	octets). Computing the size of a particular set allows determining the		Classes * 4 octets). Computing the size of a particular set allows the
	beginning of the next set without completely parsing the current set,		determination of the beginning of the next set without completely parsing
	should it not be an acceptable SA set.		the current set. This is necessary when it is determined that the current
			set is not an acceptable SA set. This will improve the performance of SA
			Attribute determination.
	The SA list format presents several attribute types for an attribute		Security Association Lists The SA list format presents several attribute
	class. Each type within the class is then ordered to indicate its prece-		types for an attribute class. Each type within the class is then ordered
	dence. Specifically, the first attribute type is the highest priority		to indicate its precedence. Specifically, the first attribute type is the
	type, followed by other choices. Each subsequent choice are listed in		highest priority type, followed by other choices. Each subsequent choice
	descending priority order. An attribute type must be chosen from each at-		is listed in descending priority order. An attribute type must be chosen
	tribute class to establish a complete SA.		for each attribute class to establish a complete SA.
	The figure below shows the sytax for the optional list exchange format.		Figure 3 shows the syntax for the optional list exchange format. The num-
	Note that multiple attribute types appear within an attribute class. The		ber of types is determined by the Count field. The number of Attribute
	number of types is determined from the Count field.		Types within an Attribute Class will depend on what is supported by the
			local machine.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Attribute Class ! Count !		! Attribute Class ! Count !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Attribute Type ! Attribute Type !		! Attribute Type ! Attribute Type !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Attribute Type ! Attribute Type !		! Attribute Type ! Attribute Type !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Generic List Exchange Format		Figure 3: Generic List Exchange Format
	o Attribute Class (2 octets) - Examples are Encryption Algorithms, Key		o Attribute Class (2 octets) - Examples are Encryption Algorithms, Key
	Exchange Algorithms		Exchange Algorithms
	o Count - Number of proposed types for a class		o Count - Number of proposed Attribute Types for the given Attribute
			Class
	o Attribute Type (2 octets) - Presented in priority order		o Attribute Type (2 octets) - Presented in descending priority order
	Appendix B presents an outline containing a more comprehensive set of SA		Appendix B presents an outline containing a comprehensive listing of SA
	attributes. These sets of attributes are initial definitions and are pre-		attributes. This listing of attributes are initial definitions and are
	sented to stimulate thought and discussion on SAs. The final set of SA		presented to stimulate thought and discussion on SAs. The final SA for
	attributes should be defined in a separate RFC so additions or modifica-		a protocol SHOULD be defined in that protocol so additions or modifica-
	tions to the attributes do not require a modification to the Internet Key		tions to the attributes do not require a modification to the Internet Key
	Management Protocol (IKMP) RFC and vice versa. An SA container object and		Management Protocol (IKMP) RFC and vice versa. For example, Appendix C
	SA attribute definitions should become part of the Management Information		describes the sample security associations for ISAKMP and IPSP ESP and AH.
	Base (MIB), see [RFC-1213], in a separate protected section called the Se-
	curity MIB. IKMP should emulate the SNMP concept of separate RFCs for the
	protocol and the information managed. SA attribute identifiers MAY be de-
	fined using the syntax in [RFC-1155] and [RFC-1212].
	2.2.2 Transport Protocol		2.3.2 Transport Protocol
	The User Datagram Protocol (UDP) is the transport protocol for ISAKMP. UDP		The User Datagram Protocol (UDP) is the transport protocol for ISAKMP. UDP
	checksumming discards UDP packets with an incorrect or zero (0) checksum.		checksumming discards UDP packets with an incorrect or zero (0) checksum.
	ISAKMP is unaware of the discard, but will resend the packet when its re-		ISAKMP is unaware of the discard, but will resend the packet when its re-
	send timer expires.		send timer expires.
	2.2.3 RESERVED Fields		2.3.3 RESERVED Fields
	All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a		The existence of RESERVED fields are strictly used to preserve byte
	packet is issued. The receiver SHOULD check the RESERVED fields for zero		alignement. All RESERVED fields in the ISAKMP protocol MUST be set to
	(0) and discard the packet if other values are found.		zero (0) when a packet is issued. The receiver SHOULD check the RESERVED
			fields for zero (0) and discard the packet if other values are found.
	2.3 Security Association Establishment		2.3.4 Anti-Clogging Token (``Cookie'') Creation
	SA Establishment is the process of agreeing upon and exchanging all the		Phil Karn's Internet Draft [Karn95] states that cookie generation is im-
	security information that is required in an SA. The following sections,		plementation dependent, but must satisfy some basic requirements:
	2.3.1 to 2.3.3, describe the three basic phases, -- SA Initialization,
	key and Authentication information exchange, and SA Negotiation --, that
	comprise SA Establishment.
	2.3.1 Security Association Initialization		1. The cookie must depend on the specific parties. This prevents
			an attacker from obtaining a cookie using a real IP address and
			UDP port, and then using it to swamp the victim with Diffie-
			Hellman requests from randomly chosen IP addresses or ports.
			2. It must not be possible for anyone other than the issuing
			entity to generate cookies that will be accepted by that
			entity. This implies that the issuing entity must use local
			secret information in the generation and subsequent
			verification of a cookie. It must not be possible to deduce
			this secret information from any particular cookie.
			3. The cookie generation function must be fast to thwart attacks
			intended to sabotage CPU resources.
			Karn's suggested method for creating the cookie is to perform a fast hash
			(e.g. MD5) over the IP Source and Destination Address, the UDP Source and
			Destination Ports and a locally generated secret random value. ISAKMP
			requires that the cookie be unique for each SA establishment, SA modify
			and SA delete to help prevent replay attacks, therefore the date and time
			MUST be added to the information hashed.
			2.3.5 SA Flags Field
			The SA Flags field may be set by the entity that initiated the negotia-
			tion to indicate that the ISA_COMMIT packet will follow the completion of
			the protocol exchange. The SA Flags field exists only in the ISA_INIT and
			ISA_NEG packets. If the initiating entity sets the flag, the responding
			entity cannot 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 ISA_COMMIT packet. If neither entity sets the flag, then the
			ISA_COMMIT packet will not be issued. To set the flag the Least Signifi-
			cant Bit (LSB) in the SA Flags field is set to one (1) . All other bits
			in the SA Flags field are zero (0).
			3 Security Association Establishment
			Security Association (SA) Establishment is the process of agreeing upon
			and exchanging all the security information that is required in an SA. The
			following sections, 3.1 to 3.3, describe the three basic phases that com-
			prise SA Establishment: SA Initialization, Key and Authentication infor-
			mation exchange, and SA Negotiation.
			3.1 Security Association Initialization
	The initialization exchange of SA establishment is composed of the		The initialization exchange of SA establishment is composed of the
	ISA_INIT_REQ and ISA_INIT_RESP packets. The ISA_INIT packets exchange		ISA_INIT_REQ and ISA_INIT_RESP packets shown in figure 4. The ISA_INIT pack-
	``cookies'', and options for a key generation technique, an encryption		ets exchange ``cookies'', and options for a key generation technique, an
	algorithm and an authentication mechanism. The ``cookies'' are used to		encryption algorithm and an authentication mechanism. The ``cookies''
	prevent replay and denial of service attacks. Authentication and encryp-		are used to prevent replay and denial of service attacks. Authentication
	tion for the ISAKMP exchanges is provided by the authentication mechanism		and encryption for the ISAKMP exchanges are provided by the authentication
	and encryption algorithm selected. The key generation technique selected		mechanism and encryption algorithm selected. The key generation technique
	creates keys for use by the authentication mechanism and encryption al-		selected creates keys for use by the authentication mechanism and encryp-
	gorithm. The keys may also be used either as the session keys, to create		tion algorithm. The keys may also be used as any of the following: ac-
	the session keys, or protect the exchange of the actual session keys for		tual session keys, to create the session keys, or to protect the exchange
	the SA. If the key, encryption algorithm, and authentication mechanism are		of the actual session keys for the SA. If the key, encryption algorithm,
	only used to protect ISAKMP exchanges then new options can be picked dur-		and authentication mechanism are only used to protect ISAKMP exchanges,
	ing the negotiation phase (described in Section 2.3.3) for use in protect-		then new options can be picked during the negotiation phase (described in
	ing the actual data communications. If encryption is not required for the		Section 3.3) for use in protecting the actual data communications. If en-
	SA the encryption algorithm options need not be exchanged.		cryption is not required for the SA, the encryption algorithm options are
			not exchanged.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ISAKMP Header ~		~ ISAKMP Header ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! SA Syntax Type! SA Flags ! Num of Sets ! RESERVED !		! SA Syntax Type! SA Flags ! # Sets/Lists ! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #1 ~		~ SA Attribute Set/List #1 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #2 ~		~ SA Attribute Set/List #2 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ... ~		~ ... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #N ~		~ SA Attribute Set/List #N ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ISA_INIT_REQ and ISA_INIT_RESP Packet Format		Figure 4: ISA_INIT_REQ and ISA_INIT_RESP Packet Format
	o SAKMP Header - Described in Section 2.1		o ISAKMP Header - Described in Section 2.1
	o SA Syntax Type (1 octet) - Presentation format of SAs		o SA Syntax Type (1 octet) - Presentation format of SAs
	_SA_Syntax__SA_Syntax_Type_		_SA_Syntax__SA_Syntax_Type_
			RESERVED 0
	Set 1		Set 1
	List 2		List 2
	o SA Flags (1 octet) - Flags specific to an SA service. The SA Flags		o SA Flags (1 octet) - Flags specific to an SA service. See section
	field is zero (0) for the ISA_INIT messages.		2.3.5 for details.
	o Number of Sets (1 octet) - Number of SA Attribute Sets being proposed		o Number of Sets (1 octet) - Number of SA Attribute Sets being proposed
			o SA Attributes (variable) - A list of SA Attributes. The SA Attribute
			specifications are discussed in Section 2.3.1.
	o SA Attributes (variable) - A list of SA Attributes. SA Attribute		3.1.1 SA Initialization Procedures
	specifications are discussed in Section 2.2.1.
	Initialization Procedures
	When issuing an ISA_INIT_REQ message:		When issuing an ISA_INIT_REQ message, the initiating entity does the fol-
			lowing:
	1. Create initiator cookie. See Section 1.5.1 for details.		1. Create initiator cookie. See Section 2.3.4 for details.
	2. Generate a unique pseudo-random SPI for future communications with		2. Generate a unique pseudo-random SPI. See Section 2.1 for details.
	the initiating host.
	3. Construct an ISA_INIT_REQ packet.		3. Construct an ISA_INIT_REQ packet. If the initiator will send an
			ISA_COMMIT message upon completion of the SA establishment, then the
			SA Flags field MUST be set (see section 2.3.5 and 3.4).
	4. Send the packet to the destination host as described in Section		4. Transmit the packet to the destination host as described in Section
	2.1.1.		2.1.1.
	When an ISA_INIT_REQ message is received:		When an ISA_INIT_REQ message is received, the receiving entity does the
			following:
	1. Check the ISAKMP header as described in Section 2.1.1.		1. Check the ISAKMP header as described in Section 2.1.1.
	2. Unpack ISA_INIT_REQ payload and determine the highest priority		2. Unpack the ISA_INIT_REQ payload and determine the highest priority
	attribute set supported.		attribute set (or attribute list) supported. If the proposed
			attribute set (or list) is rejected, then the protocol machine must
			clear all state and return to IDLE.
	3. Create responder cookie.		3. Create responder cookie. See Section 2.3.4 for details.
	4. Create a unique pseudo-random SPI for future communications with the		4. Generate a unique pseudo-random SPI. See Section 2.1 for details.
	responding host.
	5. Construct an ISA_INIT_RESP packet.		5. Construct an ISA_INIT_RESP packet. If the responder wants to request
			that an ISA_COMMIT message be sent upon completion of the SA
			establishment, then the SA Flags field MUST be set (see section 2.3.5
			and 3.4).
	6. Send the packet to the initiating host as described in Section 2.1.1.		6. Transmit the packet to the initiating host as described in Section
			2.1.1.
	When an ISA_INIT_RESP message is received:		When an ISA_INIT_RESP message is received, the receiving entity (original
			initiator) does the following:
	1. Check the ISAKMP header as described in Section 2.1.1.		1. Check the ISAKMP header as described in Section 2.1.1.
	2. Unpack ISA_INIT_RESP payload.		2. Unpack the ISA_INIT_RESP payload.
	3. Determine if attribute set selected is valid. If attribute set is		3. Determine if the attribute set (or list) selected by the responder is
	invalid or responder rejected all proposed attribute sets:		valid. If the attribute set (or list) is invalid or the responder
			rejected all proposed attribute sets (or lists), the receiving entity
			does the following:
	Log Event in the appropriate system file.		(a) The event, INVALID ATTRIBUTES, is logged in the appropriate
			system audit file.
	Clear all state and return to IDLE.		(b) Clear all state and return to IDLE. Any further communication
			must start the SA initialization procedures from the beginning.
	4. Configure protocol machine based on attribute set selected.		If the attribute set (or list) is valid, the receiving entity does
			the following:
	5. Transition to Key and Authentication Phase.		(a) Configure protocol machine based on attribute set selected.
	2.3.2 Key and Authentication Phase		(b) Transition to Authentication and Key Exchange (see Section 3.2).
	The authentication and key exchange phase exchange information required		3.2 Authentication and Key Exchange
	to confirm the identities of the parties wishing to establish the SA and
	establish a session key for use during the SA establishment. Based on
	user preferences the key may be used during data communications or a new
	one may be created/exchanged during the negotiation phase, described in
	section 2.3.3, for use in protecting the actual data communications.
	The authentication and key payloads are general formats which support many		During the authentication and key exchange phase, information required to
	types of key exchange and authentication. The detailed specification of		confirm the identities of the parties wishing to establish the SA and es-
	these fields are specified in companion RFCs. These companion RFCs will		tablish a session key for use during the SA establishment is exchanged.
	define the standard authentication and key exchange mechanisms that need		Depending on the key exchange algorithm, the original key may be used dur-
	to be implemented and assure compliance with this specification.		ing data communications or a new one may be created and exchanged during
			the negotiation phase (described in section 3.3). This original or new
			key would be used in protecting the actual data communications.
	The packets that carry the authentication and key exchange payloads have		The packets that carry the authentication and key exchange payloads have
	the format shown below. When the ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP pack-		the format shown in Figure 5. When the ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP
	ets are used the authentication payload SHOULD be processed first to		packets are used, the Authentication Payload SHOULD be processed first to
	strongly authenticate the packet issuer, before the key generation pro-		strongly authenticate the packet issuer, followed by the processing of
	cessing is executed. In the ISA_AUTH_REQ and ISA_AUTH_RESP packets the key		the Key Exchange Payload. The authentication and key exchange payloads
	exchange payload is not present. In the ISA_KE_REQ and ISA_KE_RESP packets		(shown in Figures 6 and 7) are general formats which support many types
	the authentication payload is not present.		of authentication and key exchange mechanisms. The detailed specification
			of these fields will be specified in companion RFCs. These companion RFCs
			will define the standard authentication and key exchange mechanisms that
			need to be implemented to assure compliance with this specification.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ISAKMP Header ~		~ ISAKMP Header ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	! Authentication Payload !		! Authentication Payload !
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	! Key Exchange Payload !		! Key Exchange Payload !
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP Packet Format		Figure 5: ISA_AUTH&KE_REQ and ISA_AUTH&KE_RESP Packet Format
	Strong Authentication Details		3.2.1 Authentication Payload Format
	This section specifies the encoding of the authentication payload for the		This section specifies the encoding of the authentication payload for the
	ISA_AUTH_REQ, ISA_AUTH_RESP, ISA_AUTH&KE_REQ, and ISA_AUTH&KE_RESP messages.		ISA_AUTH_REQ, ISA_AUTH_RESP, ISA_AUTH&KE_REQ, and ISA_AUTH&KE_RESP messages.
			As described in section 2.2.3, when the ISA_AUTH_REQ and ISA_AUTH_RESP pack-
			ets are transmitted alone, the key exchange payload is not present. The
			format of these messages is shown in Figure 6.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Authentication Authority ! Reserved !		! Authentication Authority ! Reserved !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Authentication Type ! Length !		! Authentication Type ! Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	! Authentication Data !		! Authentication Data !
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Authentication Payload Format		Figure 6: Authentication Payload Format
	o Authentication Authority (2 octets) - Indentifies the party that		o Authentication Authority (2 octets) - This field identifies the party
	generated the certificates used for authentication. Authorities must		that generated the certificates used for authentication. Authorities
	be assigned an identifier by the Internet Assigned Numbers Authority		must be assigned an identifier by the Internet Assigned Numbers
	(IANA). Before being assigned an identifier, an authority must		Authority (IANA). Before being assigned an identifier, an authority
	publish an RFC defining the authority's domain.		must publish an RFC defining the authority's domain. [RFC-1422]
			describes the Internet Policy Registration Authority (IPRA) and the
			procedures for achieving this registration.
	If PGP certificates, based on the ``web of trust'', are carried in		If PGP certificates, based on the ``web of trust'', are carried in
	the authentication payload the Authentication Authority value is one		the authentication payload the Authentication Authority value is one
	(1).		(1).
	Examples certificate authorities that would have to register for an		Example certificate authorities that would have to register for an
	identifier are:		identifier are:
	-- RSA Commercial Certificate Authority		-- RSA Commercial Certificate Authority
	(https://www_csc.rsa.com/netsite)		(http://www_csc.rsa.com/netsite)
	-- Stable Large E-mail Database (SLED) (http://www.four11.com)		-- Stable Large E-mail Database (SLED) (http://www.four11.com)
	-- U.S. Postal Service.		-- U.S. Postal Service.
	o Authentication Type (2 octets) - Indicates the authentication payload		o Authentication Type (2 octets) - This field indicates the
	format. This field is used by authentication authorities that		authentication payload format. This field is used by authentication
	support more than one certificate type. The authentication types		authorities that support more than one certificate type. The
	supported by an authentication authority must be defined in the RFC		authentication types supported by an authentication authority must be
	required for authentication authority registration. Examples are:		defined in the RFC required for authentication authority
			registration. Examples are:
	-- RSA certificates		-- RSA certificates
	-- PGP certificates		-- PGP certificates
	-- DSS certificates		-- DSS certificates
	-- DNS Signed Keys		-- DNS Signed Keys
	-- Kerberos Tokens		-- Kerberos Tokens
	-- X.509 certificates		-- X.509 certificates
	o Length (2 octets) - Length of the Authentication Data field in		o Length (2 octets) - Length of the Authentication Data field in
	octets.		octets.
	o Authentication Data (variable) - Actual authentication data. Type of		o Authentication Data (variable) - Actual authentication data. The
	certificate is indicated by the Authentication type field.		type of certificate is indicated by the Authentication Type field.
	Key Exchange Details		3.2.2 Key Exchange Payload Format
	A variety of key exchanges can be supported in the key exchange phase.		A variety of key exchanges can be supported in the key exchange phase.
	Some examples of key exchanges which may be used in this protocol are		Some examples of key exchanges which may be used in this protocol are
	Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in		Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in
	X9.42 [ANSI94], the key exchange on the FORTEZZA card, and the RSA-based		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 exchange used by PGP. This protocol will also support key exchanges
	key escrow requirement, but does not mandate its use.		that include key escrow or data recovery techniques, but does not mandate
			their use.
	The encoding of the key exchange payload is dependent on the specific key		The encoding of the key exchange payload is dependent on the specific key
	exchange and therefore is not specified in this Internet draft. There		exchange and, therefore, is not specified in this Internet draft. Each
	can be both public and private key generation techniques. Both types must		key exchange must define the following information: (a) System parame-
	register with IANA to obtain a Key Exchange Identifier (KEI). Before pub-		ters, (b) Key establishment algorithm, and (c) Key derivation procedure
	lic key exchanges can obtain a KEI, an RFC defining the key exchange pay-		(dependent on key exchange type).
	load format and key generation procedures MUST be submitted. Private key
	exchanges are not REQUIRED to provide an RFC when registering for a KEI.
	Example key exchange payload encodings are shown in Appendix A.		There can be both public and private key generation techniques. Both
			types must register with IANA to obtain a Key Exchange Identifier (KEI).
			Before published public key exchanges can obtain a KEI, an RFC defining
			the key exchange payload format and key generation procedures MUST be sub-
			mitted. Private key exchanges SHOULD be documented in an RFC when regis-
			tering for a KEI.
			As described in section 2.2.2, when the ISA_KE_REQ and ISA_KE_RESP packets
			are transmitted alone, the authentication payload is not present. Once
			the key exchange is completed, then the authentication payload is sent
			separately using the format described in section 3.2.1
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! KEI ! Length !		! KEI ! Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	! Key Exchange Payload !		! Key Exchange Payload !
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Key Exchange Payload Format		Figure 7: Key Exchange Payload Format
	KEI (2 octets) - Key Exchange Identifier		o KEI (2 octets) - Key Exchange Identifier
	Length (2 octets) - Length of payload in octets		o Length (2 octets) - Length of payload in octets
	Key Exchange Payload (variable) - Data (i.e. public values) required to		o Key Exchange Payload (variable) - Data (i.e. public values) required
	create session key.		to create session key.
	ISA_AUTH&KE Procedures		3.2.3 Authentication and Key Exchange Procedures
	When issuing an ISA_AUTH&KE_REQ packet:		When issuing an ISA_AUTH&KE_REQ packet, the initiating entity will do the
			following:
	1. Generate an authentication signature using the authentication		1. Create the ISAKMP Header.
	attributes and options selected in initialization phase.
	2. Create key exchange payload based on KEI.		2. Create the authentication payload.
	3. Construct an ISA_AUTH&KE_REQ packet.		3. Create the key exchange payload based on KEI.
	4. Send the packet to the responding host as described in Section 2.1.1.		4. Construct an ISA_AUTH&KE_REQ packet.
	When an ISA_AUTH&KE_REQ packet is received:		5. Generate an authentication signature using the authentication
			attributes and options selected in the initialization phase.
	1. Check the ISAKMP header as described in Section 2.1.1.		6. Transmit the packet to the responding host as described in Section
			2.1.1.
	2. Unpack ISA_AUTH&KE_REQ packet.		When an ISA_AUTH&KE_REQ packet is received, the receiving entity will do
			the following:
	3. Verify Initiator's signature.		1. Check the ISAKMP header as described in Section 2.1.1.
	If verification fails		2. Verify the initiator's signature. The ISA_AUTH&KE_REQ packet is
	Log Event in the appropriate system file.		processed and the calculated signature is compared to the signature
			contained in the ISA_AUTH&KE_REQ packet. If these signatures are not
			identical, the message is discarded and the following actions are
			taken:
	Terminate with error.		(a) The event, INVALID SIGNATURE, is logged in the appropriate system
			audit file.
	ELSE		(b) No response is sent to the initiating entity. This will cause
			the transmission timer of the initiating entity to expire and
			force retransmission of the message.
	Discard packet.		3. Unpack the ISA_AUTH&KE_REQ packet.
	Log Event in the appropriate system file.		4. Create the ISAKMP Header.
	RETURN to WAIT for ISA_AUTH&KE_REQ state.		5. Create the authentication payload.
	4. Generate an authentication signature, to authenticate responder to		6. Create the key exchange payload based on KEI.
	initiator, using the authentication attributes and options selected.
	5. Create key exchange payload for initiator based on KEI.		7. Construct an ISA_AUTH&KE_RESP packet.
	6. Construct an ISA_AUTH&KE_RESP packet.		8. Generate an authentication signature, to authenticate responder to
			initiator, using the authentication attributes and options selected.
	7. Send the packet to the initiating host as described in Section 2.1.1.		9. Transmit the packet to the initiating host as described in Section
			2.1.1.
	8. Begin key calculation in the background.		10. Begin key calculation in the background, if necessary.
	When an ISA_AUTH&KE_RESP message is received:		When an ISA_AUTH&KE_RESP message is received, the receiving entity (origi-
			nal initiator) will do the following:
	1. Check the ISAKMP header as described in Section 2.1.1.		1. Check the ISAKMP header as described in Section 2.1.1.
	2. Verify Responder's signature.		2. Verify the initiator's signature. The ISA_AUTH&KE_RESP packet is
			processed and the calculated signature is compared to the signature
			contained in the ISA_AUTH&KE_RESP packet. If these signatures are not
			identical, the message is discarded and the following actions are
			taken:
	If verification fails, either:		(a) The event, INVALID SIGNATURE, is logged in the appropriate system
			audit file.
	Log Event in the appropriate system file.		(b) No response is sent to the initiating entity. This will cause
			the transmission timer of the initiating entity to expire and
			force retransmission of the message.
	Terminate with error.		3. Calculate key, if necessary.
	ELSE		4. Transition to Security Association Negotiation.
	Discard packet.		3.3 Security Association Negotiation
	Log Event in the appropriate system file.		The SA Negotiation phase allows the initiating entity to present SA at-
			tributes that it wishes to use for secure communications to a respond-
			ing entity. These SA attributes may include additional options for the
			attributes agreed upon during the initialization phase, as well as ad-
			ditional attributes required for an SA. As an example, the SA parame-
			ters for the IP AH and IP ESP security mechanisms are cited in the Secu-
			rity Architecture for the Internet Protocol [RFC-1825]. The format for
			the ISA_NEG_REQ and ISA_NEG_RESP packets is the same as the ISA_INIT_REQ and
			ISA_INIT_RESP shown in Figure 4. All fields shown in Figure 4 exist for
			the ISA_NEG_REQ and ISA_NEG_RESP packets.
	RETURN to WAIT for ISA_AUTH&KE_RESP state.		3.3.1 SA Negotiation Procedures
	3. Calculate key.		When issuing an ISA_NEG_REQ packet, the initiating entity does the follow-
			ing:
	4. Transition to Security Association Negotiation Phase.		1. Determine SA attributes to be negotiated. This may include changing
			some attributes from the original SA initialization.
	2.3.3 Security Association Negotiation Phase		2. Construct an ISA_NEG_REQ packet. If the initiator will send an
			ISA_COMMIT message upon completion of the SA establishment, then the
			SA Flags field MUST be set (see section 2.3.5 and 3.4).
	The SA Negotiation phase allows the initiating entity to present SA at-		3. Depending on the SA Attributes established in the SA initialization
	tributes, that it wishes to use for secure communications, to a responding		phase, apply the agreed upon security services.
	entity. These SA attributes may included additional options for the at-
	tributes agreed upon during the initialization phase, as well as selection
	of the additional attributes required for an SA. The REQUIRED and REC-
	OMMENDED SA parameters for the IP AH and IP ESP security mechanisms are
	cited in the Security Architecture for the Internet Protocol [Atki95].
	1 2 3		(a) If the SA requires authentication, the ISA_NEG_REQ packet is pro-
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		cessed (or signed) and the signature placed as noted in Figure 1.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ISAKMP Header ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! SA Syntax Type! Num of Sets ! SA Flags ! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #1 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #2 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #N ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ISA_NEG_REQ and ISA_NEG_RESP Packet Format		(b) If the SA requires encryption and the encryption algorithm is a
			block encryption algorithm, then padding up to the block size
			MUST be placed as noted in Figure 1.
	o SA Msg Type (1 octet) - Defined in Section 2.3.1.		(c) If the SA requires encryption, the ISA_NEG_REQ payload and
			Signature are encrypted.
	o Num of Sets (1 octet) - Number of Attribute Sets being proposed		4. Transmit the packet to the responding host as described in Section
			2.1.1.
	o SA Flags (1 octet) - Flags specific to an SA service. See Section		When an ISA_NEG_REQ packet is received, the receiving entity does the fol-
	2.3.3 for flag settings in the ISA_NEG messages.		lowing:
	o SA Attributes (variable) - A list of SA attributes. SA Attribute		1. Check the ISAKMP header as described in Section 2.1.1.
	specifications are discussed in section 2.2.1.
	SA Negotiation Procedures		2. Depending on the SA Attributes, apply the agreed upon security
			services.
	When issuing an ISA_NEG_REQ packet:		(a) If the SA requires encryption, decrypt the ISA_NEG_REQ payload and
			Signature. If the decryption fails, the message is discarded and
			the following actions are taken:
	1. Determine SA attributes to be negotiated. This may include changing		i. The event, DECRYPTION FAILED, is logged in the appropriate
	or confirming the attributes from the SA initialization phase.		system audit file.
	2. Encrypt and/or sign ISA_NEG_REQ payload only (not header).		ii. No response is sent to the initiating entity. This will
			cause the transmission timer of the initiating entity to
			expire and force retransmission of the message.
	3. Construct an ISA_NEG_REQ packet.		(b) If the SA requires authentication, the ISA_NEG_REQ packet is
			processed and the calculated signature is compared to the
			signature contained in the ISA_NEG_REQ packet. If these signatures
			are not identical, the message is discarded and the following
			actions are taken:
	4. Send the packet to the responding host as described in Section 2.1.1.		i. The event, INVALID SIGNATURE, is logged in the appropriate
			system audit file.
	When an ISA_NEG_REQ packet is received:		ii. No response is sent to the initiating entity. This will
			cause the transmission timer of the initiating entity to
			expire and force retransmission of the message.
	1. Check the ISAKMP header as described in Section 2.1.1.		3. Unpack the ISA_NEG_REQ packet payload and determine the highest
			priority SA attributes supported. If none of the SA attribute
			options are supported, the ISA_NEG_RESP packet will have the value zero
			(0) in the Number of Sets field and an SA will not be established.
	2. Decrypt ISA_NEG_REQ payload and verify signature.		4. If the SA negotiation is requesting a key change or new
			authentication mechanism, then generate the appropriate information
			and include it as an attribute in the ISA_NEG_RESP payload.
	3. Unpack ISA_NEG_REQ packet payload and determine the highest priority SA		5. Construct an ISA_NEG_RESP packet. If the responder wants to request
	attributes supported.		that an ISA_COMMIT message be sent upon completion of the SA
			establishment, then the SA Flags field MUST be set (see section 2.3.5
			and 3.4).
	If none of the SA attribute options are supported, the ISA_NEG_RESP		6. Depending on the SA Attributes, apply the agreed upon security
	will have the value zero (0) in the Number of Sets field and an SA		services.
	will not be established.
	4. If the SA negotiation is requesting a key change or new		(a) If the SA requires authentication, the ISA_NEG_RESP packet is
	authentication mechanism, then, generate appropriate information and		processed and the signature placed as noted in Figure 1.
	include it as an attribute/option in the ISA_NEG_RESP payload.
	5. Encrypt and/or sign ISA_NEG_RESP payload only (not header).		(b) If the SA requires encryption and the encryption algorithm is a
			block encryption algorithm, then padding up to the block size
			MUST be placed as noted in Figure 1.
	6. Construct an ISA_NEG_RESP packet.		(c) If the SA requires encryption, the ISA_NEG_RESP payload and
			Signature are encrypted.
	7. Send the packet to the initiating host as described in Section 2.1.1.		7. Transmit the packet to the initiating host as described in Section
			2.1.1.
	8. If required, begin calculation of the new session key in the		8. If required, begin calculation of the new session key in the
	background.		background.
	9. Transition to SA Negotation Conclusion.		9. Transition to SA Negotation Conclusion (see Section 3.4).
	When an ISA_NEG_RESP message is received:		When an ISA_NEG_RESP message is received, the receiving entity (original
			initiator) does the following:
	1. Check the ISAKMP header as described in Section 2.1.1.		1. Check the ISAKMP header as described in Section 2.1.1.
	2. Decrypt ISA_NEG_RESP payload and verify signature.		2. Depending on the SA Attributes, apply the agreed upon security
			services.
	3. Unpack ISA_NEG_RESP payload and verify the SA attributes selected by		(a) If the SA requires encryption, decrypt the ISA_NEG_RESP payload and
	responder are valid.		Signature. If the decryption fails, the message is discarded and
			the following actions are taken:
	If response is invalid or responder rejected all proposed SA		i. The event, DECRYPTION FAILED, is logged in the appropriate
	Attributes:		system audit file.
	Log Event in the appropriate system file.		ii. No response is sent to the initiating entity. This will
			cause the transmission timer of the initiating entity to
			expire and force retransmission of the message.
	Clear all state and return to an IDLE.		(b) If the SA requires authentication, the ISA_NEG_RESP packet is
			processed and the calculated signature is compared to the
			signature contained in the ISA_NEG_RESP packet. If these
			signatures are not identical, the message is discarded and the
			following actions are taken:
	4. If required, begin calculation of the new session key in the		i. The event, INVALID SIGNATURE, is logged in the appropriate
	background.		system audit file.
	5. Transition to SA Negotiation Conclusion.		ii. No response is sent to the initiating entity. This will
			cause the transmission timer of the initiating entity to
			expire and force retransmission of the message.
	SA Negotiation Conclusion		3. Unpack the ISA_NEG_RESP payload and verify the SA attributes selected
			by responder are valid. If the attribute sets (or lists) are invalid
			or the responder rejected all proposed attribute sets (or lists), the
			receiving entity does the following:
	SA Commit Message The SA Commit message allows the initiating entity to		(a) The event, INVALID ATTRIBUTES, is logged in the appropriate
	inform the responding party that it has completed the processing required		system audit file.
	to set-up the SA and therefore, secure communications may begin.
	The Least Significant Bit (LSB) in the SA Flags field is set to one (1)		(b) Clear all state and return to IDLE.
	in the ISA_NEG packet if an ISA_COMMIT packet is issued and zero (0) if the
	ISA_COMMIT packet is not issued. All other bits in the SA Flags field are
	zero (0).
	The SA Flags field may be set by the entity that initiated the negotia-		If the attribute set (or list) is valid, the receiving entity does
	tion to indicate that the ISA_COMMIT packet will follow the negotiation		the following:
	exchange. If the initiating entity sets the flag the responding entity
	can not reset it. If the initiating entity does not set the flag the re-
	sponding entity may set it, thereby forcing the initiating entity to issue
	an ISA_COMMIT packet. If neither entity sets the flag then the ISA_COMMIT
	packet will not be issued.
	The ISA_COMMIT packet is the ISAKMP header with no payload.		(a) Configure the protocol machine based on the attribute set (or
			list) selected.
	The SPI is set to the Responder SPI.		4. If required, begin calculation of the new session key in the
			background.
	Transmiting ISA_COMMIT packet is optional and determined by the policy of		5. Transition to SA Negotiation Conclusion (see Section 3.4).
	the parties establishing the SA. All implementations MUST be able to gen-
	erate, transmit, and receive this message.
	SA_Negotiation Conclusion Procedures		3.4 SA Negotiation Conclusion
	1. Both initiator and responder place SA in appropriate database for the		The SA negotiation concludes with the transmittal of the optional
	security service it supports.		SA_COMMIT packet. This is determined by the setting of the SA Flags
			field. The SA_COMMIT message allows the initiating entity to inform the
			responding party that it has completed the processing required to set-up
			the SA and therefore, secure communications may begin. If the entity ini-
			tiating the SA establishment does not have the ability to queue incoming
			data it may receive prior to its completion of SA establishment process-
			ing, then it requires the responding entity to wait for an SA_COMMIT mes-
			sage before sending data. The transmittal of the ISA_COMMIT packet is op-
			tional and determined by the policy of the parties establishing the SA.
			All implementations MUST be able to generate, transmit, and receive this
			message.
	2. Based on the SA Flags field, the initiator constructs an ISA_COMMIT		The ISA_COMMIT packet is the ISAKMP header, described in section 2.1, with
	packet.		no payload.
	3. Initiator sends the packet to the responding host as described in		3.4.1 SA Negotiation Conclusion Procedures
	Section 2.1.1.
	4. When responder received ISA_COMMIT packet it checks the ISAKMP header		When issuing an ISA_COMMIT packet, the initiating entity does the follow-
	as described in Section 2.1.1.		ing:
	5. Clear all state and return to IDLE.		1. Construct an ISA_COMMIT packet (ISAKMP Header).
	2.3.4 Packet Exchanges		2. Depending on the SA Attributes established in the SA initialization
			phase, apply the agreed upon security services.
	The ``Exchange'' field in the ISAKMP header currently has two values de-		(a) If the SA requires authentication, the ISA_COMMIT packet is pro-
	fined, the base exchange (BASE) and the anonomous exchange (ANON). These		cessed (or signed) and the signature placed as noted in Figure 1.
	exchanges define the flow of the ISAKMP packets during SA establishment.
	The diagrams in 2.3.4 and 2.3.4 shows the packet exchange ordering for
	each exchange type and provides basic notes describing what has happened
	after each packet exchange.
	Base Exchange		(b) If the SA requires encryption and the encryption algorithm is a
			block encryption algorithm, then padding up to the block size
			MUST be placed as noted in Figure 1.
	The previous sections, 2.3.1 to 2.3.3, described the three basic phases,		(c) If the SA requires encryption, the ISA_COMMIT Signature is
	SA negotiation --, that comprise the BASE exchange. The base exchange		encrypted.
	contains the minimum number of packet exchanges in order to reduce latency
	associated with SA establishment.
	Base Exchange		3. Transmit the packet to the responding host as described in Section
	___Initiator___________Responder_____ Note		2.1.1.
	ISA_INIT_REQ =>
	<= ISA_INIT_RESP
	Basic SA selected
	ISA_AUTH&KE_REQ =>
	<= ISA_AUTH&KE_RESP
	Identity Verified
	Key Generated
	Encryption Begun
	ISA_NEG_REQ =>
	<= ISA_NEG_RESP SA Completed
	(optional) ISA_COMMIT =>
	Identity Protection SA Establishment Variation		4. Clear all state and return to IDLE.
	The identity protect exchange starts and ends the same as the base ex-		When an ISA_COMMIT packet is received, the receiving entity does the fol-
	change, but separates the key exchange payload and the authentication pay-		lowing:
	loads into separate packets. In this exchange the key exchange is trans-
	mited first followed by the strong authentication exchange. The benefit
	of this exchange is the ability to communicate with a person without dis-
	closing either party's identity to passive attackers on the network.
	The ISA_KE_REQ and ISA_KE_RESP packets used for the key exchange in this		1. Check the ISAKMP header as described in section 2.1.1.
	variation contain an ISAKMP header followed by the key exchange payload.
	The ISA_AUTH_REQ and ISA_AUTH_RESP packet used for the authentication ex-		2. Depending on the SA Attributes, apply the agreed upon security
	change in this variation contain an ISAKMP header followed by the authen-		services.
	tication payload.
	Identity Protection Exchange		(a) If the SA requires encryption, decrypt the ISA_COMMIT Signature.
	__Initiator________Responder___ Note		If the decryption fails, the message is discarded and the
	ISA_INIT_REQ =>		following actions are taken:
	<= ISA_INIT_RESP
	Basic SA selected
	ISA_KE_REQ =>
	<= ISA_KE_RESP
	Key Generated
	Encryption Begun
	ISA_AUTH_REQ =>
	<= ISA_AUTH_RESP
	Identity Verified
	ISA_NEG_REQ =>
	<= ISA_NEG_RESP SA Completed
	(optional) ISA_COMMIT =>
	2.4 Security Association Modification		i. The event, DECRYPTION FAILED, is logged in the appropriate
			system audit file.
	SA modification provides the ability to update attributes and parameters		ii. Because the ISA_COMMIT packet is a unidirectional message a
	within an existing SA. The most common use of this exchange will be to re-		retransmission will not be performed. Because the SA is
	key an SA.		established, we recommend that communications can proceed,
			however, the local security policy will dictate the
			procedures for continuing. We recommend that an ISA_NOTIFY
			packet with an Error Message Type (see Section 6) be sent to
			the originator of the ISA_COMMIT packet.
	1 2 3		(b) If the SA requires authentication, the ISA_COMMIT packet is
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		processed and the calculated signature is compared to the
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		signature contained in the ISA_COMMIT packet. If these signatures
	~ ISAKMP Header ~		are not identical, the message is discarded and the following
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		actions are taken:
	! SA Syntax Type! Num of Sets ! SA Flags ! RESERVED !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #1 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #2 ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ SA Attribute Set #N ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	ISA_MODIFY_REQ and ISA_MODIFY_RESP Packet Format		i. The event, INVALID SIGNATURE, is logged in the appropriate
			system audit file.
	o SA Syntax Type (1 octet) - Defined in Section 2.3.1.		ii. Because the ISA_COMMIT packet is a unidirectional message a
			retransmission will not be performed. Because the SA is
			established, we recommend that communications can proceed,
			however, the local security policy will dictate the
			procedures for continuing. We recommend that an ISA_NOTIFY
			packet with an Error Message Type (see Section 6) be sent to
			the originator of the ISA_COMMIT packet.
	o Num of Sets (1 octet) - Number of Attribute Sets being modified.		3. Clear all state and return to IDLE.
	o SA Flags (1 octet) - Flags specific to an SA service. Currently the		4 Security Association Modification
	SA Flags field is set to zero (0) for the ISA_MODIFY packets.
	o SA Attributes (variable) - A list of SA attributes. SA Attributes		Security Association modification provides the ability to update security
	field contains only those attributes being updated. SA Attribute		association attributes and parameters within an existing SA without having
	specifications are discussed in section 2.2.1.		to establish a new SA. The use of this exchange can provide performance
			benefits without sacrificing the security of the existing communication.
			The most common use of this exchange will be to re-key an existing SA.
			The format for the ISA_MODIFY packet is the same as the ISA_INIT_REQ and
			ISA_INIT_RESP shown in Figure 4. All fields shown in Figure 4 exist for
			the ISA_MODIFY packets.
			4.1 Modification Procedures
	The procedure for exchanging information to modify an SA are similiar to		The procedure for exchanging information to modify an SA are similiar to
	the SA negotiation exchange. The details of SA modification will be de-		the SA negotiation exchange. The details of SA modification will be de-
	scribed in this section as they are solidified during prototype develop-		scribed in this section as they are solidified during prototype develop-
	ment.		ment.
	2.5 Security Association Deletion		5 Security Association Deletion
	The ISA_DELETE packet provide a controlled method of informing a peer		During communications it is possible that hosts may be compromised or that
	entity that the initiating entity has deleted an SA(s). The ISA_DELETE		information may be intercepted during transmission. Determining whether
	packet provides for the deletion of any number of SAs. The receiving en-		this has occurred is not an easy task and is outside the scope of this
	tity SHOULD clean up its SA database. The receiving entity may be us-		Internet-Draft. However, if it is discovered that transmissions are being
	ing the SA for secure communications with more than one party and would		compromised, then it is necessary to delete the current SA and establish a
	not want to actually delete the SA from it's database, however, upon re-		new SA.
	ceipt of an ISA_DELETE packet the SAs in the packet can not be used with
	the initiating entity. The SA Establishment must be repeated to resume		The ISA_DELETE packet (shown in Figure 8) provides a controlled method of
	secure communications.		informing a peer entity that the initiating entity has deleted an SA(s).
			The ISA_DELETE packet allows for the deletion of any number of SAs with
			a single message. The receiving entity SHOULD clean up its local SA
			database. The receiving entity may be using the SA for secure communi-
			cations with more than one party and would not want to actually delete the
			SA from its database in this case. However, upon receipt of an ISA_DELETE
			packet the SAs listed in the SPIs field of the packet cannot be used with
			the initiating entity. The SA Establishment procedure must be invoked to
			re-establish secure communications.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ISAKMP Header ~		~ ISAKMP Header ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! SPI Count ! Length !		! SPI Count ! Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	! SPIs !		! SPIs !
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SA Delete Payload Format		Figure 8: SA Delete Payload Format
	o SPI Count - Number of security associations to be deleted		o SPI Count - Number of security associations to be deleted
	o Length - length of payload in octets		o Length - length of payload in octets
	o SPIs - Initiator's Security Parameter Index(s) to be deleted		o SPIs - Initiator's Security Parameter Index(s) to be deleted
	Deletion Procedures		5.1 Deletion Procedures
	When issuing an ISA_DELETE message:		When issuing an ISA_DELETE packet, the issuing entity (initiator or re-
			sponder) does the following:
	1. Create initiator cookie. See Section 1.5.1 for details.		1. Create initiator cookie. See Section 2.3.4 for details.
	2. Determine SPI of receiving entity.		2. Determine SPI of receiving entity.
	3. Construct ISA_DELETE packet.		3. Construct the ISA_DELETE packet.
	4. Send the packet to the destination host as described in Section		4. Depending on the SA Attributes, apply the agreed upon security
			services.
			(a) If the SA requires authentication, the ISA_DELETE packet is
			processed and the signature placed as noted in Figure 1.
			(b) If the SA requires encryption, the ISA_DELETE payload and
			Signature are encrypted.
			5. Transmit the packet to the destination host as described in Section
	2.1.1.		2.1.1.
	Upon receipt of an ISA_DELETE message:		6. Update the local SA database to reflect the SPI deletions.
			Upon receipt of an ISA_DELETE packet, the receiving entity (initiator or
			responder) does the following:
	1. Check the ISAKMP header as described in Section 2.1.1.		1. Check the ISAKMP header as described in Section 2.1.1.
	2. Unpack ISA_DELETE payload.		2. Depending on the SA Attributes, apply the agreed upon security
			services in the following order.
	2.6 Notification Message		(a) If the SA requires encryption, decrypt the ISA_DELETE payload and
			Signature. If the decryption fails, the message is discarded and
			the following actions are taken:
	ISAKMP ISA_NOTIFY packet contains information one party wants to send to		i. The event is logged in the appropriate system audit file.
	another. Notification information can be error messages specifying why a
	SA could not be established. It can also be status data that a process		ii. Because the ISA_DELETE packet is a unidirectional message a
	managing an SA database, such would be required on a security gateway,		retransmission will not be performed. The local security
	wishes to communicate with a peer process. The ISA_NOTIFY packet is uni-		policy will dictate the procedures for continuing. However,
	directional.		we recommend that the SPIs in the ISA_DELETE packet be checked
			to see if the originator was the communicating party. If so,
			then these SAs can be deleted from the local SA database. We
			also recommend that an ISA_NOTIFY packet with an Error Message
			Type (see Section 6) be sent to the originator of the
			ISA_DELETE packet. If the SPIs do not match those of the
			originator, then no further action should be taken.
			(b) If the SA requires authentication, the ISA_DELETE packet is
			processed and the calculated signature is compared to the
			signature contained in the ISA_DELETE packet. If these signatures
			are not identical, the message is discarded and the following
			actions are taken:
			i. The event is logged in the appropriate system audit file.
			ii. Because the ISA_DELETE packet is a unidirectional message a
			retransmission will not be performed. The local security
			policy will dictate the procedures for continuing. However,
			we recommend that the SPIs in the ISA_DELETE packet be checked
			to see if the originator was the communicating party. If so,
			then these SAs can be deleted from the local SA database. We
			also recommend that an ISA_NOTIFY packet with an Error Message
			Type (see Section 6) be sent to the originator of the
			ISA_DELETE packet. If the SPIs do not match those of the
			originator, then no further action should be taken.
			3. Unpack the ISA_DELETE payload.
			4. Update the local SA database to reflect the SPI deletions.
			6 Notification Message
			The ISAKMP ISA_NOTIFY packet contains information one party wants to send
			to another. Notification information can be error messages specifying
			why a SA could not be established. It can also be status data that a
			process managing an SA database wishes to communicate with a peer pro-
			cess. For example, a secure front end or security gateway may use the
			ISA_NOTIFY message to synchronize SA communication (see Appendix A.2).
			The ISA_NOTIFY packet is unidirectional.
	1 2 3		1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ISAKMP Header ~		~ ISAKMP Header ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	! Notify Message Type ! Length !		! Notify Message Type ! Length !
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	! Notify Payload !		! Notify Payload !
	~ ~		~ ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SA NOTIFY Payload Format		Figure 9: ISA NOTIFY Payload Format
	o Notify Message Type (2 octets)		o Notify Message Type (2 octets)
	_Notification__Notify_Message_Type_		_Notification__Notify_Message_Type_
	Error 1		Error 1
	Status 2		Status 2
	o Length (2 octets) - length of payload in octets		o Length (2 octets) - length of payload in octets
	o Notify Payload (variable) - Value dependent on the Notify Message		o Notify Payload (variable) - Value dependent on the Notify Message
	Type		Type
	3 Conclusions		6.1 Notification Procedures
	The ISAKMP provides the flexibility needed to support multiple key ex-		When issuing an ISA_NOTIFY message, the issuing entity (initiator or re-
	change techniques, encryption algorithms, authentication mechanisms, se-		sponder) does the following:
	curity services, and security attributes. These item may be publicly or
	privately defined. The added benefit of supporting multiple techniques is
	that as new techniques are developed they can easily be added to the pro-
	tocol. This provided a path for the growth of Internet security services.
	A Key Exchange Examples		1. Create initiator cookie. See Section 2.3.4 for details.
	Two key exchanges examples are presented to help illustrate the ISAKMP's		2. Determine SPI of receiving entity.
	ability to support multiple key exchanges.
	A.1 Photuris KE		3. Construct ISA_NOTIFY packet.
	Based on [Karn95] an example of how the Photuris Key Exchange could be		4. Depending on the SA Attributes, apply the agreed upon security
	accomplished in ISAKMP is presented.		services.
	1. Photuris ``groups'', K-Transform, and S-Transform would be exchanged		(a) If the SA requires authentication, the ISA_NOTIFY packet is
	in the ISA_INIT packets.		processed and the signature placed as noted in Figure 1.
	2. The following Photuris fields would be in the ISA_KE packets.		(b) If the SA requires encryption, the ISA_NOTIFY payload and
			Signature are encrypted.
	_ISAKMP_Packet__________Value__________		5. Transmit the packet to the destination host as described in Section
	ISA_KE_REQ Initiator-Public-Value		2.1.1.
	ISA_KE_RESP Responder-Public-Value
	3. The following Photuris fields would be in the ISA_AUTH packets.		Upon receipt of an ISA_NOTIFY message, the receiving entity (initiator or
			responder) does the following:
	_ISAKMP_Packet__________Value___________		1. Check the ISAKMP header as described in Section 2.1.1.
	ISA_AUTH_REQ Signature [Initiator]
	ISA_AUTH_REQ Certificate [Initiator]
	ISA_AUTH_RESP Signature [Responder]
	ISA_AUTH_RESP Certificate [Resonder]
	4. The session key would be created as described in [Karn95] after each		2. Depending on the SA Attributes, apply the agreed upon security
	key exchange payload is received.		services in the following order.
	5. Finally the Transforms, I-Transform and Parameters, R-Transform and		(a) If the SA requires encryption, decrypt the ISA_NOTIFY payload and
	Parameters, and Lifetime would be exchanged in the ISA_NEG packets.		Signature. If the decryption fails, the message is discarded and
			the following actions are taken:
	A.2 FORTEZZA Key Exchange Algorithm (KEA)		i. The event is logged in the appropriate system audit file.
	One of the benefits of ISAKMP is that it is not limited to one key ex-		ii. Because the ISA_NOTIFY packet is a unidirectional message a
	change. An example of how the FORTEZZA KEA is accomplished in ISAKMP is		retransmission will not be performed. The local security
	now presented.		policy will dictate the procedures for continuing.
	1. Options for Encryption algorithm, Authentication Authority and Key		(b) If the SA requires authentication, the ISA_NOTIFY packet is
	Exchange Algorithm would be exchanged in the ISA_INIT packets.		processed and the calculated signature is compared to the
			signature contained in the ISA_NOTIFY packet. If these signatures
			are not identical, the message is discarded and the following
			actions are taken:
	2. The following FORTEZZA fields would be in the ISA_AUTH&KE packets.		i. The event is logged in the appropriate system audit file.
	_____Packet_Payload__________________________FORTEZZA_Value_______________________		ii. Because the ISA_NOTIFY packet is a unidirectional message a
	Authentication Payload Signed Information [Initiator]		retransmission will not be performed. The local security
	Authentication Payload FORTEZZA Certificate [Initiator]		policy will dictate the procedures for continuing.
	Authentication Payload Signed Information [Responder]
	Authentication Payload FORTEZZA Certificate [Resonder]
	Key Exchange Payload Message Encryption Key encrypted in Token Encryption Key
	Key Exchange Payload Initiator-Random-Value
	Key Exchange Payload Responder-Random-Value
	3. The Token Encryption Key is generated.		3. Unpack the ISA_NOTIFY payload.
	4. Message Encryption Key is decrypted.		4. Depending on the Notify Message Type, additional processing may be
			necessary.
	5. Additional Fortezza attributes would be exchanged in the ISA_NEG		7 Conclusions
	packets.
	Another benefit of ISAKMP is that classified key exchanges, such as the		The Internet Security Association and Key Management Protocol (ISAKMP) is
	FORTEZZA KEA, can be performed using a public KMP without revealing the		a well designed protocol aimed at the Internet of the future. The massive
	algorithm. This is an important Department of Defense requirement.		growth of the Internet will lead to great diversity in network utiliza-
			tion, communications, and security requirements. ISAKMP contains all the
			features that will be needed for this dynamic and expanding communications
			environment.
			ISAKMP's Security Association (SA) feature coupled with authentication
			and key establishment provides the security and flexibility that will be
			needed for future growth and diversity. This security diversity of multi-
			ple key exchange techniques, encryption algorithms, authentication mecha-
			nisms, security services, and security attributes will allow users to se-
			lect the appropriate security for their network, communications, and secu-
			rity needs. The SA feature allows users to specify and negotiate security
			requirements with other users. An additional benefit of supporting multi-
			ple techniques in a single protocol is that as new techniques are devel-
			oped they can easily be added to the protocol. This provides a path for
			the growth of Internet security services. ISAKMP supports both publicly
			or privately defined SAs, making it ideal for government, commercial, and
			private communications.
			ISAKMP provides the ability to establish SAs for multiple security proto-
			cols and applications. These protocols and applications may be session-
			oriented or sessionless. Having one SA establishment protocol that sup-
			ports multiple security protocols eliminates the need for multiple, nearly
			identical authentication, key exchange and SA establishment protocols when
			more than one security protocol is in use or desired. Just as IP has pro-
			vided the common networking layer for the Internet, a common security es-
			tablishment protocol is needed if security is to become a reality on the
			Internet. ISAKMP provides the common base that allows all other security
			protocols to interoperate.
			ISAKMP follows good security design principles. It is not coupled to
			other insecure transport protocols, therefore it is not vulnerable or
			weakened by attacks on other protocols. Also, when more secure transport
			protocols are developed, ISAKMP can be easily migrated to them. ISAKMP
			also provides protection against protocol related attacks. This protec-
			tion provides the assurance that the SAs and keys established are with the
			desired party and not with an attacker.
			ISAKMP also follows good protocol design principles. Protocol specific
			information only is in the protocol header, following the design prin-
			ciples of IPv6. The data transported by the protocol is separated into
			functional payloads. As the Internet grows and evolves, new payloads to
			support new security functionality can be added without modifying the en-
			tire protocol.
			A ISAKMP Scenarios
			Examples scenerios are are presented to help illustrate the ISAKMP's abil-
			ity to support multiple authentication methods and key exchanges.
			A.1 Initial ISAKMP Daemon Scenerio
			This example steps through two ISAKMP daemons establishing an SA between
			themselves. This SA uses DNS Security Extentions [EK94] for authentica-
			tion and a Photuris [Karn95] compliant key exchange. Following the SA es-
			tablishment between the daemons, SAs are established for ESP and AH commu-
			nications between user processes.
			1. The initiating daemon sends an ISA_INIT_REQ messages with ISAKMP SA #3,
			#2, and #1 (in priority order). These SAs are defined in C.1.1.
			2. The responding daemon sends an ISA_INIT_RESP message indicating that
			ISAKMP SA #2 was selected, which requires DNS Signature and Key
			Records and a Photuris compliant key exchange [DOW92].
			3. The initiating daemon sends an ISA_KE_REQ packet with an index into
			well-known table of generator / prime pairs and it's public value.
			4. Upon receipt of ISA_KE_REQ packet the responding daemon computes the
			shared secret and session key.
			5. The responding daemon sends an ISA_KE_RESP packet with an its public
			value and both the initiator and responders public values signed
			using its Private (Signature) Key and encrypted in the session key
			created.
			6. Upon receipt of ISA_KE_REQ packet the initiating daemon computes the
			shared secret and session key.
			7. The initiating daemon sends an ISA_AUTH_REQ packet with both the
			initiator and responders public values signed using its Private
			(Signature) Key and it's DNS name and Public (Verification) Key
			signed by it nameserver. All encrypted in the session key created.
			8. The responding daemon sends an ISA_AUTH_RESP packet with it's DNS name
			and Public (Verification) signed by it Secure DNS nameserver and
			encrypted in the session key created.
			9. The initiating daemon sends an ISA_NEG_REQ packet with ESP SA #2, ESP
			SA #1, AH SA #1, and AH SA #2. These SAs are defined in C.2.1.
			10. The responding daemon sends an ISA_NEG_RESP packet indicating that ESP
			SA #2, and AH SA #1 was selected.
			A.2 Virtual Private Network Scenario
			This scenario show how ISAKMP can be used in a Virtual Public Network
			(VPN). The ability to establish SAs for more than just ESP and AH and one
			of the uses of the ISA_NOTIFY message are also illustrated.
			___________________________Virtual_Public_Network_Scenario_______________________
			End System#1 SFE#1 INTERNET SFE#2 End System #2
			_______ _______
			Establish ES#1 To | | | |
			SFE#1 Connection | | | |
			SYN | | | |
			===> | | | |
			| |Establish Connection Between SFEs | |
			| | | |
			| | SYN | |
			| | ===> | |
			| | SYN, ACK | |
			| | <======= | |
			| | ACK | |
			| | ===> | |
			| | | |
			| | Establish SA Between SFEs | |
			| | | |
			| | ISA_INIT_REQ | |
			| | ============> | |
			| | ISA_INIT_RESP | |
			| | <============ | |
			| | ISA_KE&AUTH_REQ | |
			| | ==============> | |
			| | ISA_KE&AUTH_RESP | |
			| | <=============== | |
			| | Secure Connection | |Establish SFE#2
			| | Between SFEs | |to ES#2 Connection
			| | | |
			| | | |SYN
			| | | |===>
			| | | |SYN, ACK
			| | | |<=======
			| | | |ACK
			| | | |===>
			| | ISA_NOTIFY(Status == Connected) | |
			SYN, ACK | | <==================== | |
			<======= | | | |
			ACK | | | |
			===> | | | |
			| | | |
			| | Protected Traffic | |
			| | ES#1 to ES#2 | |
			|_______| <==============> |_______|
			The diagram shows an End System (ES) using a connection oriented proto-
			col (we use TCP as an example) establishing a connection with another ES.
			Both ES are behind Secure Front Ends (SFE) (e.g. firewalls). The connec-
			tion establishment from End System #1 (ES#1) is intercepted by its Secure
			Front End (SFE #1). SFE#1 establishes a connection and then a Security
			Association (SA), using normal ISAKMP SA establishment procedures, with
			SFE #2. Next SFE #2 establishes a connection with ES #2. Upon successful
			completion SFE #2 sends an SA_NOTIFY with Status equal Connected. SFE #1
			completes it's connection with ES #1 and normal end to end communications
			takes place secured between SFE #1 and SFE #2. If SFE #2 had been unable
			to establish a connection with ES #2 it would have returned an SA_NOTIFY
			with Status equal Not Connected with an optional reason code.
	B Security Association Attributes		B Security Association Attributes
	This appendix is based upon an e-mail message [Kent94] to the IPSEC mail		This appendix contains a list of security attributes that should be con-
	list from Steve Kent and is reproduced here to start a discussion on SA		sidered when defining a Security Association (SA) for a security proto-
	attributes. The authors welcome input on what are meaningful security		col or application. As an example, the security attributes culled from
	attributes for an SA.		this list and required for an IP Security (AH, ESP) SA are defined in
			[RFC-1825]. The separation of ISAKMP from a specific SA definition is im-
			portant to ensure ISAKMP can establish SAs for all possible security func-
			tionality. Each security function will be required to maintain a database
			of current SAs. This list is based upon an e-mail message [Kent94] to the
			IPSEC mail list from Steve Kent.
	The following is a set of possible parameters for each security associ-		The authors welcome input on what are meaningful security attributes for
	ation (SA), e.g., candidate MIB data items where each SA has its own MIB		an SA.
	entry. They may be negotiated or pre-determined, but all are important
	for each SA in the most general case.
	1. SAID.INBOUND		1. SAID.INBOUND
	2. SAID.OUTBOUND		2. SAID.OUTBOUND
	3. ENCAPSULATION		3. ENCAPSULATION
	4. INBOUND-CRITERIA		4. INBOUND-CRITERIA
	(a) IP-DESTINATION-ADDRESS		(a) IP-DESTINATION-ADDRESS
	skipping to change at page 33, line 39 ¶		skipping to change at page 47, line 42 ¶
	(c) NEXT-PROTOCOL		(c) NEXT-PROTOCOL
	(d) IP-SECURITY-LABEL		(d) IP-SECURITY-LABEL
	(e) TRANSPORT-DESTINATION-PORT		(e) TRANSPORT-DESTINATION-PORT
	(f) TRANSPORT-SOURCE-PORT		(f) TRANSPORT-SOURCE-PORT
	5. PEER-ADDRESS		5. PEER-ADDRESS
	6. ENCRYPTION		6. AUTHENTICATION
			(a) ENABLED
			(b) MECHANISM
			o DIGITAL SIGNATURE
			i. KEY.INBOUND (Peer's Public Key)
			ii. KEY.OUTBOUND (Initator's Private Key)
			7. ENCRYPTION
	(a) ENABLED		(a) ENABLED
	(b) ALGORTIHM		(b) ALGORTIHM
	(c) KEY.INBOUND		(c) KEY.INBOUND
	(d) KEY.OUTBOUND		(d) KEY.OUTBOUND
	(e) IV.INBOUND		(e) IV.INBOUND
	skipping to change at page 34, line 4 ¶		skipping to change at page 48, line 19 ¶
	(a) ENABLED		(a) ENABLED
	(b) ALGORTIHM		(b) ALGORTIHM
	(c) KEY.INBOUND		(c) KEY.INBOUND
	(d) KEY.OUTBOUND		(d) KEY.OUTBOUND
	(e) IV.INBOUND		(e) IV.INBOUND
	(f) IV.OUTBOUND		(f) IV.OUTBOUND
	7. INTEGRITY		8. INTEGRITY
	(a) ENABLED		(a) ENABLED
	(b) PLAINTEXT		(b) PLAINTEXT
	(c) DIRECTION.ENABLED		(c) DIRECTION.ENABLED
	(d) DIRECTION.VALUE		(d) DIRECTION.VALUE
	(e) ALGORITHM		(e) ALGORITHM
	(f) KEY.OUTBOUND		(f) KEY.OUTBOUND
	(g) KEY.INBOUND		(g) KEY.INBOUND
	8. COMPRESSION		9. COMPRESSION
	(a) ENABLED		(a) ENABLED
	(b) ALGORITHM		(b) ALGORITHM
	9. REPLAY		10. REPLAY
	(a) ENABLED		(a) ENABLED
	(b) SIZE		(b) SIZE
	(c) NUMBER.OUTBOUND		(c) NUMBER.OUTBOUND
	(d) NUMBER.INBOUND		(d) NUMBER.INBOUND
	(e) WINDOW.SIZE		(e) WINDOW.SIZE
	(f) WINDOW		(f) WINDOW
	10. FRAGMENTATION		11. FRAGMENTATION
	(a) INBOUND		(a) INBOUND
	(b) OUTBOUND		(b) OUTBOUND
	11. KEY-MANAGEMENT		12. KEY-MANAGEMENT
	(a) NEGOTIATED		(a) NEGOTIATED
	(b) TECHNIQUE		(b) TECHNIQUE
	(c) PARAMETERS		(c) PARAMETERS
	(d) REKEY		(d) REKEY
	i. GRACE		o GRACE
	ii. NEXT-SA		o NEXT-SA
	iii. TIME-BASED		o TIME-BASED
	A. ENABLE		i. ENABLE
	B. TRIGGER		ii. TRIGGER
	iv. TRAFFIC-BASED		o TRAFFIC-BASED
	A. ENABLE		i. ENABLE
	B. PACKET-COUNT.INBOUND		ii. PACKET-COUNT.INBOUND
	C. PACKET-COUNT.OUTBOUND		iii. PACKET-COUNT.OUTBOUND
			iv. TRIGGER.INBOUND
	D. TRIGGER.INBOUND		v. TRIGGER.OUTBOUND
	E. TRIGGER.OUTBOUND		C Security Association Examples
			C.1 ISAKMP SA Definition
			The ISAKMP SA contains the SA attributes that are exchanged in the
			ISA_INIT messages.
			ISAKMP Security Association
			_______________________SA_Attributes_______________________Requirement__
			Peer ISAKMP Daemon Address REQUIRED
			Security Association Lifetime REQUIRED
			Certificate Authority REQUIRED
			Digital Signature Algorithm REQUIRED
			Signature Key(s) REQUIRED
			Security Association Lifetime REQUIRED
			Key Establishment Algorithm REQUIRED
			Cookie Generation Algorithm REQUIRED
			Sensitivity Level (e.g. Secret, Unclassified) RECOMMENDED
			Encryption Algorithm RECOMMENDED
			Encryption Mode RECOMMENDED
			Encryption Transform RECOMMENDED
			Encryption Key(s) RECOMMENDED
			Key Lifetime or Key Rollover RECOMMENDED
			Presence / Absence of cryptographic synchronization or IV RECOMMENDED
			Size of cryptographic synchronization or IV RECOMMENDED
			C.1.1 ISAKMP SA Examples
			ISAKMP SA #1
			_________________________SA_Class_________________________________SA_Type_________
			Peer ISAKMP Daemon Address N/A
			Security Association Lifetime 86400 seconds (1day)
			Certificate Authority DMS Root CAW
			Certificate Type X.509v1m
			Digital Signature Algorithm DSA
			Signature Key(s) N/A
			Security Association Lifetime 86400 seconds (1day)
			Key Establishment Algorithm Fortezza KEA
			Cookie Generation Algorithm SHA_1
			Sensitivity Level (e.g. Secret, Unclassified) Unclassified
			Encryption Algorithm Skipjack
			Encryption Mode CDC
			Encryption Transform NULL
			Encryption Key(s) N/A
			Key Lifetime or Key Rollover 3600 seconds (1 hour)
			Presence / Absence of cryptographic synchronization or IV Present
			Size of cryptographic synchronization or IV 64 bits
			ISAKMP SA #2
			_________________________SA_Class___________________________________SA_Type__________
			Peer ISAKMP Daemon Address N/A
			Security Association Lifetime 86400 seconds (1day)
			Certificate Authority DNSSEC janeway.ncsc.mil
			Certificate Type RR
			Digital Signature Algorithm RSA
			Signature Key(s) N/A
			Security Association Lifetime 86400 seconds (1day)
			Key Establishment Algorithm X9.42_STS
			Cookie Generation Algorithm MD5
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			Encryption Algorithm DES
			Encryption Mode CDC
			Encryption Transform RFC-1829
			Encryption Key(s) N/A
			Key Lifetime or Key Rollover 600 seconds (10 minutes)
			Presence / Absence of cryptographic synchronization or IV Present
			Size of cryptographic synchronization or IV 64 bits
			ISAKMP SA #3
			_________________________SA_Class___________________________________SA_Type__________
			Peer ISAKMP Daemon Address N/A
			Security Association Lifetime 86400 seconds (1day)
			Certificate Authority IPRA PCA UNINETT
			Certificate Type X.509v1
			Digital Signature Algorithm RSA
			Signature Key(s) N/A
			Security Association Lifetime 86400 seconds (1day)
			Key Establishment Algorithm STS
			Cookie Generation Algorithm MD5
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			Encryption Algorithm DES
			Encryption Mode CDC
			Encryption Transform RFC-1829
			Encryption Key(s) N/A
			Key Lifetime or Key Rollover 600 seconds (10 minutes)
			Presence / Absence of cryptographic synchronization or IV Present
			Size of cryptographic synchronization or IV 64 bits
			C.2 ESP SA and AH SA Definitions
			The following SAs are defined in [RFC-1825] and are presented here for
			comparative and completeness purposes.
			AH Security Association
			__________________SA_Attributes__________________Requirement_
			Authentication Algorithm REQUIRED
			Authentication Mode REQUIRED
			Authentication Key(s) REQUIRED
			Key Lifetime or Key Rollover RECOMMENDED
			Security Association Lifetime RECOMMENDED
			Sensitivity Level (e.g. Secret, Unclassified) RECOMMENDED
			ESP Security Association
			_______________________SA_Attributes_______________________Requirement__
			Encryption Algorithm REQUIRED
			Encryption Mode REQUIRED
			Encryption Transform REQUIRED
			Encryption Key(s) REQUIRED
			Presence / Absence of cryptographic synchronization or IV REQUIRED
			Size of cryptographic synchronization or IV REQUIRED
			Authentication Algorithm RECOMMENDED
			Authentication Mode RECOMMENDED
			Authentication Key(s) RECOMMENDED
			Key Lifetime or Key Rollover RECOMMENDED
			Security Association Lifetime RECOMMENDED
			Sensitivity Level (e.g. Secret, Unclassified) RECOMMENDED
			C.2.1 ESP and AH SA Examples
			AH SA #1
			____________________SA_Class_____________________________SA_Type__________
			Authentication Algorithm MD5
			Authentication Mode Keyed
			Authentication Key(s) Photuris
			Key Lifetime or Key Rollover 600 seconds (10 minutes)
			Security Association Lifetime 3600 seconds (1 hour)
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			AH SA #2
			____________________SA_Class_____________________________SA_Type__________
			Authentication Algorithm SHA
			Authentication Mode NULL
			Authentication Key(s) NULL
			Key Lifetime or Key Rollover 600 seconds (10 minutes)
			Security Association Lifetime 3600 seconds (1 hour)
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			ESP SA #1
			_________________________SA_Class___________________________________SA_Type__________
			Encryption Algorithm DES
			Encryption Mode CBC
			Encryption Transform RFC-1829
			Encryption Key(s) Phutoris Generated
			Presence / Absence of cryptographic synchronization or IV Present
			Size of cryptographic synchronization or IV 64 bits
			Authentication Algorithm NULL
			Authentication Mode NULL
			Authentication Key(s) NULL
			Key Lifetime or Key Rollover 600 seconds (10 minutes)
			Security Association Lifetime 3600 seconds (1 hour)
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			ESP SA #2
			_________________________SA_Class___________________________________SA_Type__________
			Encryption Algorithm DES
			Encryption Mode CBC
			Encryption Transform RFC-1829
			Encryption Key(s) X9.42_DH Generated
			Presence / Absence of cryptographic synchronization or IV Present
			Size of cryptographic synchronization or IV 64 bits
			Authentication Algorithm NULL
			Authentication Mode NULL
			Authentication Key(s) NULL
			Key Lifetime or Key Rollover 600 seconds (10 minutes)
			Security Association Lifetime 3600 seconds (1 hour)
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			C.2.2 Fortezza SA Examples
			Fortezza AH SA
			____________________SA_Class___________________________SA_Type________
			Authentication Algorithm SHA
			Authentication Mode NULL
			Authentication Key(s) DMS Root CAW
			Key Lifetime or Key Rollover 86400 seconds (1day)
			Security Association Lifetime 86400 seconds (1day)
			Sensitivity Level (e.g. Secret, Unclassified) N/A
			Fortezza ESP SA
			_________________________SA_Class__________________________________SA_Type_________
			Encryption Algorithm Skipjack
			Encryption Mode CBC
			Encryption Transform NULL
			Encryption Key(s) Fortezza KEA Generated
			Presence / Absence of cryptographic synchronization or IV Present
			Size of cryptographic synchronization or IV 64 bits
			Authentication Algorithm DSA
			Authentication Mode NULL
			Authentication Key(s) DMS Root CAW
			Key Lifetime or Key Rollover 3600 seconds (1 hour)
			Security Association Lifetime 86400 seconds (1day)
			Sensitivity Level (e.g. Secret, Unclassified) Unclassified
	Security Considerations		Security Considerations
	Cryptographic analysis techniques are improving at a steady pace. The		Cryptographic analysis techniques are improving at a steady pace. The
	continuing improvement in processing power makes once computational pro-		continuing improvement in processing power makes once computational pro-
	hibitive cryptographic attacks more realistic. New cryptographic algo-		hibitive cryptographic attacks more realistic. New cryptographic algo-
	rithms and public key generation techniques are also being developed at a		rithms and public key generation techniques are also being developed at a
	steady pace. New security services and mechanisms are being developed at		steady pace. New security services and mechanisms are being developed at
	an accelerated pace. A consistent method of choosing from a variety of		an accelerated pace. A consistent method of choosing from a variety of
	security services and mechanisms and to exchange attributes required by		security services and mechanisms and to exchange attributes required by
	the mechanisms is important to security in the complex structure of the		the mechanisms is important to security in the complex structure of the
	skipping to change at page 36, line 31 ¶		skipping to change at page 57, line 30 ¶
	but a key management protocol must be reliable, the reliability is built		but a key management protocol must be reliable, the reliability is built
	into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it		into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it
	doesn't soley rely on any UDP information (e.g. checksum, length) for its		doesn't soley rely on any UDP information (e.g. checksum, length) for its
	processing.		processing.
	Another issue that must be considered in the development of IKMP is the		Another issue that must be considered in the development of IKMP is the
	effect of firewalls on the protocol. Many firewalls filter out all UDP		effect of firewalls on the protocol. Many firewalls filter out all UDP
	packets, making reliance on UDP questionable in certian environments.		packets, making reliance on UDP questionable in certian environments.
	A number of very important security considerations are presented in		A number of very important security considerations are presented in
	[Atki95]. One bares repeating. Once a private session key is created it		[RFC-1825]. One bares repeating. Once a private session key is created
	must be safely stored. Failure to properly protect the private key from		it must be safely stored. Failure to properly protect the private key
	access both internal and external to the system completely nullifies any		from access both internal and external to the system completely nullifies
	protect provided by the IP Security services.		any protect provided by the IP Security services.
	Acknowledgements		Acknowledgements
	Marsha Gross, Mike Oehler, Mark Schneider, and Pete Sell provided signifi-		Marsha Gross, Bill Kutz, Mike Oehler, Mark Schneider, and Pete Sell pro-
	cant input and review to this document.		vided significant input and review to this document.
	Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX.		Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX.
	References		References
	[ANSI94] ANSI, X9.42: Public Key Cryptography Using Irreversible		[ANSI94] ANSI, X9.42: Public Key Cryptography for the Financial Services
	Algorithms for the Financial Services Industry -- Management of		Industry -- Establishment of Symmetric Algorithm Keys Using
	Symmetric Keys Using Diffie-Hellman, Draft, September, 1994.		Diffie-Hellman, Working Draft, October 26, 1995.
	[Atki95] Randell Atkinson, Security Architecture for the Internet		[DOW92] W. Diffie, M.Wiener, P. Van Oorschot, Authtication and
	Protocol, Internet-Draft, working in progress, 8 May, 1995.		Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2,
			107-125, Kluwer Academic Publishers, 1992.
	[EK94] Eastlake III, D. and c. Kaufman, Domain Name System Protocol Secu-		[Berg] Berge, N.H., UNINETT PCA Policy Statements, Internet-Draft, work
	rity Extensions, Internet-Draft, working in progress, March, 1994.		in progress, November, 1995.
			[EK94] Eastlake III, D. and C. Kaufman, Domain Name System Protocol
			Security Extensions, Internet-Draft, work in progress, Oct, 1995.
	[Karn95] Karn P. and B. Simpson, The Photuris Key Management Protocol,		[Karn95] Karn P. and B. Simpson, The Photuris Key Management Protocol,
	Internet-Draft, working in progress, March, 1995.		Internet-Draft, work in progress, November, 1995.
	[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10,		[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10,
	1994.		1994.
	[RFC-1155] Rose M. and K. McCloghrie, Structure and Identification of		[RFC-1155] Rose M. and K. McCloghrie, Structure and Identification of
	Management Information for TCP/IP-based Internets, RFC-1155, May,		Management Information for TCP/IP-based Internets, RFC-1155, May,
	1990.		1990.
	[RFC-1212] McCloghrie K. and M. Rose, Concise MIB Definitions, RFC-1212,		[RFC-1212] McCloghrie K. and M. Rose, Concise MIB Definitions, RFC-1212,
	March 26, 1991.		March 26, 1991.
	[RFC-1213] McCloghrie K. and M. Rose, Management Information Base for		[RFC-1213] McCloghrie K. and M. Rose, Management Information Base for
	Network Management of TCP/IP-based Internets: MIB-II, RFC-1213,		Network Management of TCP/IP-based Internets: MIB-II, RFC-1213,
	March 26, 1991.		March 26, 1991.
			[RFC-1422] Steve Kent, Privacy Enhancement for Internet Electronic Mail:
			Part II: Certificate-Based Key Management, RFC-1422, February 1993.
			[RFC-1825] Randell Atkinson, Security Architecture for the Internet
			Protocol, RFC-1825, August, 1995.
			[Secu] SECUREWARE INC., Peer Authentication and Key Management Protocol
			Specification, Version 2.2, October 27, 1995.
	[Schn94] Bruce Schneier, Applied Cryptography - Protocols, Algorithms,		[Schn94] Bruce Schneier, Applied Cryptography - Protocols, Algorithms,
	and Source Code in C, John Wiley & Sons, Inc., 1994.		and Source Code in C, John Wiley & Sons, Inc., 1994.
	[Spar94a] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management		[Spar94a] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management
	(GKMP) Architecture, SPARTA, Inc., Internet-Draft, September, 1994.		(GKMP) Architecture, SPARTA, Inc., Internet-Draft, September, 1994.
	[Spar94b] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management		[Spar94b] Harney H., C. Muckenhirn, and T. Rivers, Group Key Management
	(GKMP) Specification, SPARTA, Inc., Internet-Draft, September, 1994.		(GKMP) Specification, SPARTA, Inc., Internet-Draft, September, 1994.
	Addresses of Authors		Addresses of Authors
	The three authors are with:		The two authors are with:
	National Security Agency		National Security Agency
	ATTN: R2		ATTN: R23
	9800 Savage Road		9800 Savage Road
	Ft. Meade, MD. 20755-6000		Ft. Meade, MD. 20755-6000
	Douglas Maughan		Douglas Maughan
	Phone: 301-688-0847		Phone: 301-688-0847
	E-mail:wdmaugh@tycho.ncsc.mil		E-mail:wdmaugh@tycho.ncsc.mil
	Barbara Patrick
	Phone: 301-688-0298
	E-mail:bspatri@orion.ncsc.mil
	Mark Schertler		Mark Schertler
	Phone: 301-688-0849		Phone: 301-688-0849
	E-mail:mjs@tycho.ncsc.mil		E-mail:mjs@tycho.ncsc.mil
End of changes. 330 change blocks.
	734 lines changed or deleted		1580 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/