< draft-ietf-ipsec-skip-05.txt		draft-ietf-ipsec-skip-06.txt >
	Internet Engineering Task Force Ashar Aziz		IPSEC Working Group Ashar Aziz
	INTERNET-DRAFT Sun Microsystems, Inc.		INTERNET-DRAFT Tom Markson
	Expires in six months November 27, 1995		Hemma Prafullchandra
			Sun Microsystems, Inc.
			Expires in six months December 21, 1995
	Simple Key-Management For Internet Protocols (SKIP)		Simple Key-Management For Internet Protocols (SKIP)
	<draft-ietf-ipsec-skip-05.txt>		<draft-ietf-ipsec-skip-06.txt>
	Status of this Memo		Status of this Memo
			This document is a submission to the IETF Internet Protocol Security
			(IPSEC) Working Group. Comments are solicited and should be addressed to
			to the working group mailing list (ipsec@ans.net) or to the authors.
	This document is an Internet-Draft. Internet Drafts are working		This document is an Internet-Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas, and		documents of the Internet Engineering Task Force (IETF), its areas, and
	its working Groups. Note that other groups may also distribute working		its working Groups. Note that other groups may also distribute working
	documents as Internet Drafts. Future revisions of this document are		documents as Internet Drafts.
	intended to become a standards track RFC in the area of key-management
	for Internet protocols and applications. Comments should be sent to the
	IP Security WG mailing list (ipsec@ans.net).
	Internet-Drafts draft documents are valid for a maximum of six months		Internet-Drafts draft documents are valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference material		time. It is inappropriate to use Internet-Drafts as reference material
	or to cite them other than as "work in progress."		or to cite them other than as "work in progress."
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
	ftp.isi.edu (US West Coast).		ftp.isi.edu (US West Coast).
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Abstract		Abstract
	There are occasions where it is advantageous to put authenticity and		There are occasions where it is advantageous to put authenticity and
	privacy features at the network layer. The vast majority of the privacy		privacy features at the network layer. The vast majority of the privacy
	and authentication protocols in the literature deal with session		and authentication protocols in the literature deal with session
	oriented key-management schemes. However, many of the commonly used		oriented key-management schemes. However, many of the commonly used
	network layer protocols (for example, IP and IPv6) are session-less		network layer protocols (for example, IPv4 and IPv6) are session-less
	datagram oriented protocols. We describe a key-management scheme that is		datagram oriented protocols. We describe a key-management scheme that is
	particularly well suited for use in conjunction with a session-less		particularly well suited for use in conjunction with a session-less
	datagram protocol like IP or IPv6.		datagram protocol like IPv4 or IPv6.
	We also describe a simple extension of this protocol to provide scalable		SKIP has been designed to work with the IP Security Protocols AH and ESP
	group key-management for Internet multicasting protocols. SKIP has been		[8, 9, 10] which are specified for both IPv4 and IPv6.
	designed to work with the IP Security Protocols AH and ESP [8,9,10]
	which are specified for both IPv4 and IPv6.
	1. Overview		CONTENTS
	Any key-management scheme that can scale to the number of nodes possible		Status of this Memo................................. 1
	in the Internet must be based on an underlying authenticated public key
	based infrastructure. These public keys may be authenticated using a
	variety of mechanisms, such as public key certificates, a secure
	directory server and so on. ITU standard X.509 provides an example of
	authenticating public keys using certificates. Secure DNS [11] provides
	an example of authenticating public keys (and other resources) using a
	secure directory service. Still another example of authenticating public
	keys is the web-of-trust "introducer" model, best exemplified in the
	Pretty Good Privacy (PGP) secure e-mail software package.
	All of these mechanisms essentially provide a secure binding between an		Abstract............................................ 2
	entity's name (or identifier) and its public key. Most of the existing
	applications assume that the key being authenticated is a key for a
	public key cryptosystem, such as RSA [7].
	There are two ways authenticated RSA public keys can be used to provide		1. Simple Key-Management for Internet Protocols........ 3
	authenticity and privacy for a datagram protocol, such as IP. The first
	is to use out-of-band establishment of an authenticated session key,
	using one of several session key establishment protocols prior to
	communication [2,3]. This session key is then used to
	encrypt/authenticate IP data traffic.
	Such a scheme has the disadvantage of having to establish and (securely)		1.1 Manual distribution of Kij.................... 5
	manage a pseudo session layer underneath IP, which is a session-less
	protocol. The IP source would need to first communicate with the IP
	destination in order to acquire this session key. Also, as and when the
	session key needs to be changed, the IP source and the IP destination
	need to communicate again in order to make this happen. Each such
	communication could involve the use of a computationally expensive
	public key operation.
	This secure management of the pseudo session state is further		1.2 Zero-Message Master Key Update Algorithm...... 5
	complicated by crash recovery considerations. If one side crashes, and
	loses all session state, then mechanisms need to exist to securely
	remove the half-open session state on the side that did not crash.
	These mechanisms need to be secure because insecure (unauthenticated)
	removal of half-open sessions would open the door to a trivial denial of
	service attack.
	Performing session oriented key-management at the IP layer has another		1.3 Independence from Cryptographic
	major drawback. An important feature of the IP protocol is recovery from		Algorithms.................................... 7
	intermediate node or link failures, by dynamically re-routing around
	failed intermediate links and nodes. Indeed, a basic motivation for the
	design of the IP layer was to help build a network that could repair
	itself from failure due to destruction of partial network assets under a
	military attack. In the commercial environment, this same requirement
	exists for reasons of high availability of network access and services.
	IP facilitates this failure recovery by not requiring intermediate nodes		1.4 High Availability and Load Balancing using
	to maintain any kind of state on a per communications instance basis.		SKIP.......................................... 7
	Each IP packet is independently routable. This permits simple re-routing
	of IP traffic around failed routers/links. In addition to re-routing for
	reasons of router/link failure, IP protocols also perform dynamic
	routing to better utilize the network's capacity, by performing load
	balancing of network traffic. For example, if equal cost routes exist to
	a destination, the OSPF [16] routing protocol will split the traffic
	among those equal cost routes, thereby load balancing IP traffic among
	several different routers/links.
	Performing session oriented key-management for IP defeats these		1.5 Intermediate Authentication with End-to-End
	properties of IP. For example, if encryption is being performed at some		security using SKIP........................... 8
	intermediate point (e.g. encrypting router or firewall) then session
	oriented key-management makes dynamic re-routing of encrypted IP traffic
	for reasons of failed or congested nodes/links far more complicated than
	the straightforward fail-over/re-routing mechanisms that exist for
	unencrypted IP traffic. This is because, in essence, a stateful
	connection has been created to an intermediate point. A packet is no
	longer an independent entity; it now requires information from a
	security association establishment phase, namely the session key, in
	order to be properly processed. Rerouting encrypted traffic for
	decryption by another intermediate node either for fail-over or load-
	balancing considerations is not practical with session oriented key-
	management. This is because it is not practical to simply and securely
	share transient session keys, which exist only on a pairwise basis, with
	many other intermediate nodes. Without knowledge of the transient
	session key with which the packets are protected, another intermediate
	node is not able to decrypt/authenticate re-routed IP traffic. Thus,
	session oriented key-management, implemented at the IP layer, breaks
	many of the properties which have made IP successful as an internet
	protocol.
	This motivates considering key-management schemes that operate in a		1.6 Attacks that the protocol guards against...... 9
	session-less and stateless manner.
	An alternative design could utilize authenticated RSA public keys in a		1.6.1 Intruder in the Middle Attacks 9
	stateless key-management scheme. This might work through in-band
	signaling of the packet encryption key, where the packet encryption key
	is encrypted in the recipient's RSA public key. This is the way, for
	example, Privacy Enhanced Mail (PEM) [6] and other secure mail programs
	perform message encryption. Although this avoids the session state
	establishment requirement and prior out-of-band communication in order
	to set up and change packet encryption keys, this scheme has the
	disadvantage of having to carry the packet encryption key encrypted in
	the recipient's public key in each IP packet.
	Since an RSA encrypted key would minimally need to be 64 bytes, and can		1.6.2 Known Key Attacks 9
	be 128 bytes, this scheme incurs the overhead of 64 to 128 bytes of
	keying information in every packet. (As time progresses, the RSA block
	size would need to be closer to or greater than 128 bytes simply for
	security reasons.) Also, when the packet encryption key changes a public
	key operation would need to be performed in order to recover the new
	packet encryption key. Thus both the protocol and computational overhead
	of such a scheme is very high.
	Use of authenticated Diffie-Hellman (DH) [4] public values can avoid the		1.6.3 Clogging Defense 10
	need for pseudo session state management between two ends in order to
	acquire and change packet encrypting keys. Authenticated DH public
	values serve as the basis for a very simple, efficient and stateless
	key-management scheme that does not entail any of the drawbacks noted
	above. Apart from being exceedingly simple to implement, this stateless
	key-management scheme provides straightforward and scalable solutions to
	permit dynamic re-routing of protected IP traffic through alternate
	encrypting intermediate nodes for crash-recovery/fail-over/load-
	balancing scenarios.
	1.1 Simple Key-Management for Internet Protocols		1.7 Naming, Name Spaces and Master Key-IDs........ 10
	We stipulate that each IP based source and destination shall have an		1.8 The SKIP Header............................... 13
	authenticated Diffie-Hellman public value. This public value may be
	authenticated in numerous ways. One mechanism (described here and in
	section 4.2) is by the use of X.509 certificate format [6]. Another
	mechanism, described in section 4.1, relies on naming principals using
	the message digest of their DH public value.
	The X.509 certificates can be signed using any signature algorithm, such		1.9 Deriving Keys for Packet Encryption and
	as RSA or DSA. The subject Distinguished Name (DN) in the X.509		Authentication................................ 16
	certificate is the numeric string representation of a list of IP
	addresses or equivalent identifier for principals in the network.		1.10 SKIP for Authentication....................... 17
	Examples of principals in the network are IP nodes, or users. In the
	discussion below we focus on IP nodes, although user oriented keying is		1.10.1 Scope of MAC computation 18
	possible and is further described in section 1.9.
			1.11 SKIP for Encryption........................... 18
			1.12 SKIP with combined transforms................. 18
			- i -
			1.13 Generic use of SKIP header.................... 18
			2. Security Considerations............................. 19
			2.1 Generating Random Keys........................ 19
			2.2 Key Update.................................... 19
			2.3 Choosing Key Strengths........................ 20
			2.4 Forward Secrecy............................... 20
			3. Informational Section............................... 20
			3.1 SKIP with AH.................................. 21
			3.2 SKIP with ESP................................. 22
			3.3 SKIP with AH and ESP.......................... 23
			4. Assigned Numbers.................................... 24
			4.1 SKIP protocol number.......................... 24
			4.2 SKIP SPI value................................ 25
			4.3 Name Space Identifier (NSID) Assignments...... 25
			4.4 Assigned Algorithm Numbers.................... 25
			5. Recommended Parameters and Implementation Notes..... 26
			5.1 n Update Frequency............................ 26
			5.2 SKIP with the Certificate Discovery
			Protocol...................................... 27
			5.3 Recommended g & p values...................... 27
			5.3.1 Prime generation method 27
			5.3.2 Diffie-Hellman Parameters for 1024
			bits Modulus 28
			- ii -
			5.3.3 Diffie-Hellman Parameters for 2048
			bits Modulus: 29
			6. Conclusions......................................... 30
			Acknowledgements.................................... 31
			References.......................................... 32
			Author's Address(es)................................ 34
			- iii -
			1. Simple Key-Management for Internet Protocols
			In order to implement SKIP each IP based source and destination shall
			have an authenticated Diffie-Hellman (DH) [4] public value. This public
			value may be authenticated in numerous ways. Some possibilities for
			authenticating DH public values is by the use of X.509 certificates [6],
			Secure DNS [11], and PGP certificates [24].
			These certificates can be signed using any signature algorithm, such as
			RSA or DSA. In case of X.509 certificates, the subject Distinguished
			Name (DN) in the X.509 certificate is the numeric string representation
			of a list of IP addresses or equivalent identifier for principals in the
			network. Examples of principals in the network are IP nodes, or users. A
			detailed description of this may be found in [23]. In the discussion
			below we focus on IP nodes, although user oriented keying is possible
			and is further described in section 1.7.
	Thus each IP source or destination I has a secret value i, and a public		Thus each IP source or destination I has a secret value i, and a public
	value g^i mod p. Similarly, IP node J has a secret value j and a public		value g^i mod p. Similarly, IP node J has a secret value j and a public
	value g^j mod p.		value g^j mod p.
	Once n certificates are assigned to n IP nodes, O(n^2) mutually		Once n certificates are assigned to n IP nodes, O(n^2) mutually
	authenticated pairwise keys arise, simply as a result of the public		authenticated pairwise keys arise, simply as a result of the public
	value authentication process. This is because each pair of IP source		value authentication process. This is because each pair of IP source
	and destination I and J can acquire a mutually authenticated shared		and destination I and J can acquire a mutually authenticated shared
	secret g^ij mod p. The symmetric keys derivable from these shared		secret g^ij mod p. The symmetric keys derivable from these shared
	secrets require no setup overhead, except for the authenticated public		secrets require no setup overhead, except for the authenticated public
	value distribution process itself.		value distribution process itself.
	All that is required for each party to compute the pairwise symmetric		All that is required for each party to compute the pairwise symmetric
	key is to know the other party's authenticated public value. Since there		key is to know the other party's authenticated public value. Since there
	is nothing secret about DH public values, one natural way to discover		is nothing secret about DH public values, one natural way to discover
	the relevant authenticated public value is to distribute these using a		the relevant authenticated public value is to distribute these using a
	directory service.		directory service or the Certificate Discovery Protocol [19].
	This computable shared secret is used as the basis for a key-		This computable shared secret is used as the basis for a key-
	encrypting-key to provide IP packet based authentication and encryption.		encrypting-key to provide IP packet based authentication and encryption.
	Thus we call g^ij mod p the long-term secret, and derive from it a key		Thus we call g^ij mod p the long-term secret, and derive from it a key
	Kij. Kij is used as the key for a block Symmetric Key CryptoSystem		Kij. Kij is used as the key for a block Symmetric Key CryptoSystem
	(SKCS) like DES, RC2, IDEA, and such. Since Kij is used for key-		(SKCS) like DES, RC2, IDEA, and such.
	encryption, one MUST NOT use a stream cipher for this purpose.
	Kij is derived from g^ij mod p by taking the low order key-size bits of		Kij is derived from g^ij mod p by taking the low order key-size bits of
	g^ij mod p. Since g^ij mod p should minimally be 512 bits and for		g^ij mod p. Since g^ij mod p should minimally be 512 bits and for
	greater security should be 1024 bits or more, we can always derive		greater security should be 1024 bits or more, we can always derive
	enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are		enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are
	typically in the range of 40-256 bits.		typically in the range of 40-256 bits.
	The important point here is that Kij is an implicit pairwise shared key.		The important point here is that Kij is an implicit pairwise shared key.
	It does not need to be sent in ANY packet or negotiated out-of-band. The		It does not need to be sent in ANY packet or negotiated out-of-band. The
	destination IP node can compute this shared key (Kij) simply by knowing		destination IP node can compute this shared key (Kij) simply by knowing
	skipping to change at page 7, line 15 ¶		skipping to change at page 4, line 31 ¶
	transient keys in this long-term key, and use the transient keys (Kp) to		transient keys in this long-term key, and use the transient keys (Kp) to
	encrypt/authenticate IP data traffic. This limits the amount of data		encrypt/authenticate IP data traffic. This limits the amount of data
	protected using the long-term key to a relatively small amount even over		protected using the long-term key to a relatively small amount even over
	a long period of time, since keys (Kp) represent a relatively small		a long period of time, since keys (Kp) represent a relatively small
	amount of data. Because Kij is used to only encrypt other keys, and not		amount of data. Because Kij is used to only encrypt other keys, and not
	traffic, it is referred to as a master key.		traffic, it is referred to as a master key.
	[Note: For the sake of simplicity, the key Kp is described in this		[Note: For the sake of simplicity, the key Kp is described in this
	section as a packet encryption and/or authentication key. Actually, Kp		section as a packet encryption and/or authentication key. Actually, Kp
	is used to derive two separate keys, one for encryption and another for		is used to derive two separate keys, one for encryption and another for
	authentication. This is further described in section 1.12]		authentication. This is further described in section 1.9]
	The first time a source I, which has a secret value i, needs to		The first time a source I, which has a secret value i, needs to
	communicate with destination J, which has a public value g^j mod p, it		communicate with destination J, which has a public value g^j mod p, it
	computes the shared secret g^ij mod p. It then derives from this shared		computes the shared secret g^ij mod p. It then derives from this shared
	secret the master key Kij. The source I then generates a random key Kp		secret the master key Kij. The source I then generates a random key Kp
	and encrypts this key using Kij. The Kij and Kp keys are used as keys		and encrypts this key using Kij. The Kij and Kp keys are used as keys
	for a symmetric key algorithm.		for a symmetric key algorithm.
	Note: In order to prepare this packet for transmission to node J, no		Note: In order to prepare this packet for transmission to node J, no
	communication was necessary with node J. When node J receives this		communication was necessary with node J. When node J receives this
	skipping to change at page 7, line 43 ¶		skipping to change at page 5, line 14 ¶
	If the source node (I in this case) changes the packet encryption key		If the source node (I in this case) changes the packet encryption key
	(Kp), the receiving IP node J can discover this fact without having to		(Kp), the receiving IP node J can discover this fact without having to
	perform a public key operation. It uses the cached value Kij to decrypt		perform a public key operation. It uses the cached value Kij to decrypt
	the encrypted packet key Kp. Thus, without requiring communication		the encrypted packet key Kp. Thus, without requiring communication
	between transmitting and receiving ends, and without necessitating the		between transmitting and receiving ends, and without necessitating the
	use of a computationally expensive public key operation, the packet		use of a computationally expensive public key operation, the packet
	encrypting/authenticating keys can be changed by the transmitting side		encrypting/authenticating keys can be changed by the transmitting side
	and discovered by the receiving side.		and discovered by the receiving side.
	Since the authenticated public values are Diffie-Hellman public values,		1.1 Manual distribution of Kij
	the nodes themselves have no public-key signature algorithm. This is not
	a problem, since signing on a per-packet basis using a public-key
	cryptosystem is too cumbersome. The integrity of the packets is
	determined using a symmetrically keyed Message Authentication Code
	(MAC).
	1.2 Manual distribution of Kij
	As an interim measure, in the absence of an authenticated public key		As an interim measure, in the absence of an authenticated public key
	distribution infrastructure, nodes may wish to employ manual		distribution infrastructure, nodes may wish to employ manual
	distribution of keying information. To handle such cases, the master key		distribution of keying information. To handle such cases, the master key
	Kij SHOULD be the key that is manually established.		Kij SHOULD be one of the keys that that are manually established when
			SKIP is being used.
	Since manual re-keying is a slow and awkward process, it still makes		Since manual re-keying is a slow and awkward process, it still makes
	sense to use the two level keying structure, and encrypt the packet		sense to use the two level keying structure, and encrypt the packet
	encryption key Kp using the manually established master key Kij. This		encryption key Kp using the manually established master key Kij. This
	has the same benefit as before, namely it avoids over-exposing the		has the same benefit as before, namely it avoids over-exposing the
	master key, since it is advantageous to maintain the master key over		master key, since it is advantageous to maintain the master key over
	relatively long periods of time. This is particularly true for high-		relatively long periods of time. This is particularly true for high-
	speed network links, where it is easy to encrypt large amounts of data		speed network links, where it is easy to encrypt large amounts of data
	over a short period of time.		over a short period of time.
	Because of the separation of master keys (the key Kij) and traffic		Because of the separation of master keys (the key Kij) and traffic
	encryption keys (packet encryption key Kp), the SKIP scheme makes it		encryption keys (packet encryption key Kp), the SKIP scheme makes it
	possible to automatically update traffic encryption keys even when		possible to automatically update traffic encryption keys even when
	relying on manual master key distribution.		relying on manual master key distribution.
	1.3 Zero-Message Master Key Update Algorithm		1.2 Zero-Message Master Key Update Algorithm
	The implicit pairwise master keys in the previous sections can be used		The implicit pairwise master keys in the previous sections can be used
	to generate an arbitrary number of implicit master keys, by making the		to generate an arbitrary number of implicit master keys, by making the
	master keys be a function of a counter, which is denoted as "n". The		master keys be a function of a counter, which is denoted as "n". The
	counter value n is only incremented and never decremented. It is used to		counter value n is only incremented and never decremented. It is used to
	prevent re-use of compromised traffic authentication keys as well as to		prevent re-use of compromised traffic authentication keys as well as to
	provide coarse-grain playback protection of data traffic. In the event		provide coarse-grain playback protection of data traffic. In the event
	that a particular traffic authentication key is compromised (for		that a particular traffic authentication key is compromised (for
	whatever reason) its re-use is prevented by updating the implicit master		whatever reason) its re-use is prevented by updating the implicit master
	key Kij and by never re-using a master key.		key Kij and by never re-using a master key.
	skipping to change at page 9, line 7 ¶		skipping to change at page 6, line 17 ¶
	certificates, in order to check certificate validity information.		certificates, in order to check certificate validity information.
	Recommended time units/counter update frequency and the agreed upon		Recommended time units/counter update frequency and the agreed upon
	start time is specified later in the document.		start time is specified later in the document.
	Once the counter has moved forward, packets encrypted with the help of		Once the counter has moved forward, packets encrypted with the help of
	counter values that differ by more than 1 from the local n MUST be		counter values that differ by more than 1 from the local n MUST be
	rejected.		rejected.
	This counter value is passed in the field labeled "n" following the		This counter value is passed in the field labeled "n" following the
	version and next header fields of the SKIP header, which is described in		version and next header fields of the SKIP header, which is described in
	Section 1.10.		section 1.8.
	The counter n is computed as described in Section 6.3. The n'th master		The counter n is computed as described in section 5.1. The n'th master
	key is computed using the following function:		key is computed using the following function:
	Kijn = h(Kij | n | 01h) | h(Kij | n | 00h)		Kijn = h(Kij | n | 01h) | h(Kij | n | 00h)
	where h() is a pseudo-random, one-way hash function, for example, MD5		where h() is a pseudo-random, one-way hash function, for example, MD5
	[13]. For this version of SKIP, the one-way function MUST be MD5. The		[13]. For version 1 of SKIP, the one-way function MUST be MD5. The "|"
	"|" represents concatenation, and the high order bits are on the left		represents concatenation, and the high order bits are on the left side.
	side. The low order bits of this operation are used for Kijn. The 00h,		The low order bits of this operation are used for Kijn. The 00h, and 01h
	and 01h are one byte values containing 0 and 1 respectively. The counter		are one byte values containing 0 and 1 respectively. The counter "n"
	"n" MUST be in network order for purposes of this computation.		MUST be in network order for purposes of this computation.
			When using public key agreement or manual key agreement to establish
			Kij, Kij MUST be 256 bits long. This means that if Kij is derived from
			g^ij mod p, then the low order 256 bits are used as the input to the
			Kijn calculation. When manually establishing Kij, the Kij length MUST be
			256 bits.
	A pictorial representation of the above operation using MD5 is as follows:		A pictorial representation of the above operation using MD5 is as follows:
	+-----------------+-------------+--+ MD5 hash +------------------------+		+-----------------+-------------+--+ MD5 hash +------------------------+
	| Kij (MSB first) | n (32 bits) |00| ========> | Low 128 bits of Kijn |		| Kij (MSB first) | n (32 bits) |00| ========> | Low 128 bits of Kijn |
	+-----------------+-------------+--+ +------------------------+		+-----------------+-------------+--+ +------------------------+
	+-----------------+-------------+--+ MD5 hash +------------------------+		+-----------------+-------------+--+ MD5 hash +------------------------+
	| Kij (MSB first) | n (32 bits) |01| ========> | High 128 bits of Kijn |		| Kij (MSB first) | n (32 bits) |01| ========> | High 128 bits of Kijn |
	+-----------------+-------------+--+ +------------------------+		+-----------------+-------------+--+ +------------------------+
	1.4 Independence from Cryptographic Algorithms		1.3 Independence from Cryptographic Algorithms
	Although the descriptions above have been presented using the		Although the descriptions above have been presented using the
	cryptographic constructions of classic Diffie-Hellman (exponentiations		cryptographic constructions of classic Diffie-Hellman (exponentiations
	over a prime field) the protocols are completely generalizable to any		over a prime field) the protocols can be generalized to any public key
	public key agreement system. In this context a public key agreement		agreement system. In this context a public key agreement system is
	system is defined as a system where one combines another's public and		defined as a system where one combines another's public and one's own
	one's own private value to compute a pairwise shared secret. Here we		private value to compute a pairwise shared secret. Here we distinguish
	distinguish between a public key agreement system and a public key		between a public key agreement system and a public key cryptosystem
	cryptosystem which has the trapdoor property (for example, RSA).		which has the trapdoor property (for example, RSA).
	Examples of cryptographic constructions, other than exponentiation over		Examples of cryptographic constructions, other than exponentiation over
	a prime field, that can be used to provide the same public key agreement		a prime field, that can be used to provide the same public key agreement
	property are constructions that employ elliptic curves over finite		property are constructions that employ elliptic curves over finite
	fields [17] and schemes that utilize exponentiation using composite		fields [17] and schemes that utilize exponentiation using composite
	moduli.		moduli.
	Essentially, all aspects of the key-management protocol described above		Essentially, all aspects of the key-management protocol described above
	can be generalized to public and private values of the public key		can be generalized to public and private values of the public key
	agreement type.		agreement type.
	The public key agreement algorithm is specified by the algorithm		The public key agreement algorithm is specified by the algorithm
	identifier used to identify the public key in the public key certificate		identifier used to identify the public key in the public key certificate
	or equivalent mechanism (e.g. secure DNS).		or equivalent mechanism (e.g. secure DNS).
	1.5 Storage of Cryptographic Keys		1.4 High Availability and Load Balancing using SKIP
	Since the Kijn values need to be cached for efficiency, reasonable
	safeguards need to be taken to protect these keys.
	One possible way to do this is to utilize a hardware device to compute,
	store and perform operations using these keys. This device can ensure
	that there are no interfaces to extract the keys from the device. Such
	devices can be in the form of tamper-proof smart cards, PCMCIA devices,
	and so on.
	A full discussion of system-level protection of cryptographic keys,
	while an important issue, is beyond the scope of this document.
	1.6 High Availability and Load Balancing using SKIP
	Since the SKIP protocol as described above is completely stateless, it		Using the SKIP protocol, it is straightforward to construct highly-
	is straightforward to construct highly-available and load-balanced		available and load-balanced protected IP configurations.
	protected IP configurations.
	To support a redundant configuration, a set of intermediate nodes are		To support a redundant configuration, a set of intermediate nodes are
	set up to share the same long-term Diffie-Hellman secret/public value		set up to share the same long-term Diffie-Hellman secret/public value
	pair. These nodes may all have different IP addresses, as long as the		pair. These nodes may all have different IP addresses, as long as the
	destination Master Key-ID is the same, since that is what is used to		destination Master Key-ID is the same, since that is what is used to
	identify the master keys. Note: it is far easier and simpler to		identify the master keys. Note: it is far easier and simpler to
	configure a set of nodes to share the same long-term secret, than it is		configure a set of nodes to share the same long-term secret, than it is
	to dynamically share transient session keys between a set of nodes.		to dynamically share transient session keys between a set of nodes.
	[The notion of Master Key-IDs, and how they differ from the source and		[The notion of Master Key-IDs, and how they differ from the source and
	destination IP addresses, is explained in Section 1.9].		destination IP addresses, is explained in section 1.7].
	Once a set of nodes share the same long-term secret, they can act		Once a set of nodes share the same long-term secret, they can act
	naturally in a redundant highly available and load balanced		naturally in a redundant highly available and load balanced
	configuration for encrypted/authenticated IP traffic. The standard		configuration for encrypted/authenticated IP traffic. The standard
	dynamic IP routing facilities provide for high-availability and load-		dynamic IP routing facilities provide for high-availability and load-
	balancing. No new protocol is required in order to achieve these goals.		balancing. No new protocol is required in order to achieve these goals.
	Should one of these intermediate nodes (or their associated network		Should one of these intermediate nodes (or their associated network
	links) fail, IP will automatically route packets through the remaining		links) fail, IP will automatically route packets through the remaining
	set of nodes, and these re-routed IP packets will remain decryptable by		set of nodes, and these re-routed IP packets will remain decryptable by
	the other members of the redundant set. There is no limit to the number		the other members of the redundant set. There is no limit to the number
	of nodes/links that can be configured in such a redundant configuration.		of nodes/links that can be configured in such a redundant configuration.
	Thus high-availability and load-balancing simply fall out from the basic		1.5 Intermediate Authentication with End-to-End security using SKIP
	stateless SKIP design, without requiring an additional (and complex) set
	of protocols to deal with these issues.
	1.7 Intermediate Authentication with End-to-End security using SKIP
	It is sometimes desirable to authenticate end-to-end protected IP		It is sometimes desirable to authenticate end-to-end protected IP
	traffic at an intermediate node [9], e.g. a site firewall. Such		traffic at an intermediate node [9], e.g. a site firewall. Such
	intermediate authentication is typically not practical with conventional		intermediate authentication is typically not practical with conventional
	session oriented key-management, since it isn't practical to dynamically		session oriented key-management, since it isn't practical to dynamically
	share end-to-end transient session keys with an intermediate node.		share end-to-end transient session keys with an intermediate node.
	Using SKIP, intermediate authentication of end-to-end protected IP		Using SKIP, intermediate authentication of end-to-end protected IP
	traffic MAY be realized, if participating principals can share their		traffic MAY be realized, if participating principals can share their
	long-term private keys with the intermediate node. This may not be		long-term private keys with the intermediate node. This may not be
	skipping to change at page 12, line 5 ¶		skipping to change at page 9, line 5 ¶
	perimeter defined by the intermediate device (e.g. a site's network		perimeter defined by the intermediate device (e.g. a site's network
	boundary).		boundary).
	Note: With knowledge of another principal's long term private key, the		Note: With knowledge of another principal's long term private key, the
	intermediate device is also in a position to decrypt the end-to-end		intermediate device is also in a position to decrypt the end-to-end
	protected traffic, or forge traffic for principals whose keys it knows.		protected traffic, or forge traffic for principals whose keys it knows.
	If this is not desirable, then this kind of long term private key		If this is not desirable, then this kind of long term private key
	sharing should not take place, by foregoing either intermediate		sharing should not take place, by foregoing either intermediate
	authentication or end-to-end protection.		authentication or end-to-end protection.
	1.8 Attacks that the protocol guards against		1.6 Attacks that the protocol guards against
	It is not possible to list all possible attacks on a cryptographic		It is not possible to list all possible attacks on a cryptographic
	protocol in a short space. Instead we describe a well known category of		protocol in a short space. Instead we describe a well known category of
	attacks on cryptographic protocols, and show how SKIP defeats those		attacks on cryptographic protocols, and show how SKIP defeats those
	attacks.		attacks.
	1.8.1 Intruder in the Middle Attacks		1.6.1 Intruder in the Middle Attacks
	Unauthenticated Diffie-Hellman is susceptible to an intruder in the		Unauthenticated Diffie-Hellman is susceptible to an intruder in the
	middle attack. To overcome this, authenticated Diffie-Hellman schemes		middle attack. To overcome this, authenticated Diffie-Hellman schemes
	have been proposed, that include a signature operation with the parties'		have been proposed, that include a signature operation with the parties'
	private signature keys.		private signature keys.
	SKIP is not susceptible to intruder in the middle types of attacks. This		SKIP is not susceptible to intruder in the middle types of attacks. This
	is because the Diffie-Hellman public parameters are long-term and		is because the Diffie-Hellman public parameters are long-term and
	authenticated. Intruder in the middle attacks on Diffie-Hellman assume		authenticated. Intruder in the middle attacks on Diffie-Hellman assume
	that the parties cannot determine who the public Diffie-Hellman keys		that the parties cannot determine who the public Diffie-Hellman keys
	belong to. Authenticated Diffie-Hellman public values eliminate this		belong to. Authenticated Diffie-Hellman public values eliminate this
	possibility, without requiring any exchange of messages between the two		possibility, without requiring any exchange of messages between the two
	parties or incurring the computational overhead of large exponent		parties or incurring the computational overhead of large exponent
	exponentiations (for example, RSA signatures).		exponentiations (for example, RSA signatures).
	1.8.2 Known Key Attacks		1.6.2 Known Key Attacks
	If the in-band traffic keys Kp used for packet authentication are ever		If the in-band traffic keys Kp used for packet authentication are ever
	compromised, (for whatever reason) then the master key update algorithm		compromised, (for whatever reason) then the master key update algorithm
	described above precludes the re-use of compromised keys to send forged		described above precludes the re-use of compromised keys to send forged
	traffic.		traffic.
	This is because even if a particular traffic key Kp is compromised, this		This is because even if a particular traffic key Kp is compromised, this
	does not tell an attacker anything about the current implicit key Kijn,		does not tell an attacker anything about the current implicit key Kijn,
	and therefore the attacker would not be able to compute the encryption		and therefore the attacker would not be able to compute the encryption
	of Kp in Kijn. Without knowing the encryption of Kp under the Kijn, an		of Kp in Kijn. Without knowing the encryption of Kp under the Kijn, an
	attacker cannot re-use past compromised keys Kp to any advantage.		attacker cannot re-use past compromised keys Kp to any advantage.
	Also, even if all the packet encryption/authentication keys (Kp)		Also, even if all the packet encryption/authentication keys (Kp)
	encrypted in a given Kijn are are compromised, then this doesn't help		encrypted in a given Kijn are compromised, then this doesn't help an
	and an attacker learn any other Kp, since knowing any number of keys Kp		attacker learn any other Kp, since knowing any number of keys Kp does
	does not allow an attacker to learn Kijn. Knowing or even choosing Kp		not allow an attacker to learn Kijn. Knowing or even choosing Kp keys,
	keys, and using that to learn Kijn is equivalent to a known or chosen		and using that to learn Kijn is equivalent to a known or chosen plain-
	plain-text attack on a Kijn, and that should be infeasible even given a		text attack on a Kijn, and that should be infeasible even given a very
	very large number of known/chosen Kp keys as long as the key-encryption		large number of known/chosen Kp keys as long as the key-encryption
	algorithm is (for practical purposes) immune to a known/chosen text		algorithm is practically secure against a known/chosen text attack. To
	attack, which should be the case for properly chosen encryption		the extent that the key-encryption algorithm is secure against a
	algorithms. Thus SKIP is immune to known or chosen key attacks of this		known/chosen text attack, SKIP is secure against a known/chosen key
	variety.		attack.
	1.8.3 Anti-Clogging Defense		1.6.3 Clogging Defense
	An attacker may attempt to mount a denial-of-service attack on a node		An attacker may attempt to mount a denial-of-service attack on a node
	implementing SKIP, by trying to force it to perform an unacceptably high		implementing SKIP, by trying to force it to perform an unacceptably high
	number of computationally expensive operations, e.g. the Diffie-Hellman		number of computationally expensive operations, e.g. the Diffie-Hellman
	computation.		computation.
	In order to prevent denial-of-service attacks on the SKIP scheme		In order to prevent denial-of-service attacks on the SKIP scheme
	described above, a recommended solution is to pre-compute and cache		described above, a recommended solution is to pre-compute and cache
	master keys Kij, based either on usage patterns of the machine or		master keys Kij, based either on usage patterns of the machine or
	through administrative action. In case a clogging attack occurs, the IP		through administrative action. In case a clogging attack occurs, the IP
	skipping to change at page 13, line 30 ¶		skipping to change at page 10, line 30 ¶
	master keys. This allows business as usual activities to carry on, even		master keys. This allows business as usual activities to carry on, even
	while a clogging attack occurs, since there are no computationally		while a clogging attack occurs, since there are no computationally
	expensive (e.g. public key) operations required to key or re-key with an		expensive (e.g. public key) operations required to key or re-key with an
	IP node once the master key Kij has been computed.		IP node once the master key Kij has been computed.
	The keys belonging to administrators SHOULD always be in the pre-compute		The keys belonging to administrators SHOULD always be in the pre-compute
	cache used to prevent this form of denial-of-service attack. This allows		cache used to prevent this form of denial-of-service attack. This allows
	the administrator to securely add more principals to the pre-compute		the administrator to securely add more principals to the pre-compute
	cache, even during a clogging attack.		cache, even during a clogging attack.
	1.8.4 Non-Goal: Perfect Forward Secrecy		1.7 Naming, Name Spaces and Master Key-IDs
	Although perfect forward secrecy as described in [3], is a desirable and
	appealing goal for a key-distribution protocol, there are no known
	practical and scalable techniques for achieving perfect forward secrecy
	for a stateless message based protocol. Here a message based protocol is
	contrasted with a stateful session based protocol. Common examples of
	message based protocols include secure e-mail protocols such as PEM and
	PGP. There are no known techniques for providing perfect forward secrecy
	of encrypted data for these stateless message based protocols.
	In support of dynamic IP routing, IP is more accurately modeled as a
	message based protocol. For these reasons, SKIP does not attempt to
	provide perfect forward secrecy of encrypted IP traffic. Only a stateful
	session oriented key distribution protocol can provide perfect forward
	secrecy, but such a scheme breaks the basic properties of IP as noted
	above, vastly complicating (or making impossible) highly available and
	load-balanced protected IP configurations.
	1.9 Naming, Name Spaces and Master Key-IDs
	SKIP uses two 1 byte fields in the SKIP header, Source Name Space ID		SKIP uses two 1 byte fields in the SKIP header, Source Name Space ID
	(NSID) and Destination NSID, to indicate that Master Key-IDs will be		(NSID) and Destination NSID, to indicate that Master Key-IDs will be
	used for looking up authenticated public values instead of the source		used for looking up authenticated public values instead of the source
	and/or destination IP addresses. These fields also identify which name		and/or destination IP addresses. These fields also identify which name
	space is being used for Master Key-IDs.		space is being used for Master Key-IDs.
	[Note: The term Master Key-ID is used instead of certificate ID, since		[Note: The term Master Key-ID is used instead of certificate ID, since
	the SKIP protocol allows manual master key setup. Master Key-ID is a		the SKIP protocol allows manual master key setup. Master Key-ID is a
	generic term used to identify a particular Kij, whether it is obtained		generic term used to identify a particular Kij, whether it is obtained
	skipping to change at page 14, line 37 ¶		skipping to change at page 11, line 19 ¶
	the SKIP header. The first NSID byte refers to the name space of the		the SKIP header. The first NSID byte refers to the name space of the
	source Master Key-ID, and the second NSID refers to the name space of		source Master Key-ID, and the second NSID refers to the name space of
	the destination Master Key-ID.		the destination Master Key-ID.
	The length of the Master Key ID is implicit in the choice of the NSID.		The length of the Master Key ID is implicit in the choice of the NSID.
	There are two commonly used lengths, 32 bits and 128 bits. A 32 bit		There are two commonly used lengths, 32 bits and 128 bits. A 32 bit
	Master Key-ID may be used to identify, e.g., IPv4 addresses or		Master Key-ID may be used to identify, e.g., IPv4 addresses or
	XOPEN/POSIX user ids. A 128 bit Master Key-ID may be used to refer to an		XOPEN/POSIX user ids. A 128 bit Master Key-ID may be used to refer to an
	IPv6 address.		IPv6 address.
	The usage of NSIDs also allows many different name spaces (up to 256) to		The usage of NSIDs also allows many different name spaces (up to 255) to
	be used with SKIP, by letting the Master Key-ID be the message digest of		be used with SKIP. One way of deriving the Master Key-ID is to define it
	the name in its native name space. Examples of name or identifier spaces		to be the message digest of the name in its native name space. Examples
	that can be accommodated in this manner are DNS names, ISO Distinguished		of name or identifier spaces that can be accommodated in this manner are
	Names, U.S. Social Security numbers, Bank Account numbers, etc.		DNS names, ISO Distinguished Names, etc. Another way is to use some
			unique identifier as the keyid. Examples of this include POSIX/XOPEN
			User Ids or 802.x MAC addresses.
	If the names have associated privacy concerns, then employing the		If the names have associated privacy concerns, then employing the
	message digest scheme can potentially protect these sensitive names, due		message digest scheme can potentially protect these sensitive names, due
	to the one-way property of a message digest. It is important to note		to the one-way property of a message digest. It is important to note
	that this privacy aspect of protecting names using their message-digest		that this privacy aspect of protecting names using their message-digest
	is only possible if the name space is large enough to resist an		is only possible if the name space is large enough to resist an
	exhaustive search attack. If the name space is too small then this		exhaustive search attack. If the name space is too small then this
	allows an attack which compares all the names in the name space to their		allows an attack which compares all the names in the name space to their
	message digests. Names which are sensitive and taken from a small name		message digests. Names which are sensitive and taken from a small name
	space SHOULD NOT be used with this message digest representation.		space SHOULD NOT be used with this message digest representation.
	skipping to change at page 15, line 17 ¶		skipping to change at page 11, line 47 ¶
	It is also possible for this identifier to be the message digest of a		It is also possible for this identifier to be the message digest of a
	principal's DH public value, since some principals may wish to be known		principal's DH public value, since some principals may wish to be known
	by their public values alone. If the public value is used as an		by their public values alone. If the public value is used as an
	identification mechanism, it simplifies the distribution of		identification mechanism, it simplifies the distribution of
	authenticated public values, since there is an algorithmic and		authenticated public values, since there is an algorithmic and
	cryptographic binding between a name and its public value. This is the		cryptographic binding between a name and its public value. This is the
	same purpose that certificates serve, so this can potentially simplify		same purpose that certificates serve, so this can potentially simplify
	the distribution of public values in communities that choose this naming		the distribution of public values in communities that choose this naming
	mechanism, because it eliminates the need for a third party (e.g.		mechanism, because it eliminates the need for a third party (e.g.
	Certifying Authority, secure directory server, trusted introducer, etc.)		Certifying Authority, secure directory server, trusted introducer, etc.)
	to ensure a secure binding between a name and a public value.		to ensure a secure binding between a name and a public value. The
			encoding for unsigned DH public values is beyond the scope of this
			document and is defined separately [20].
	There is a separate NSID byte for source and destination, so it is		There is a separate NSID byte for source and destination, so it is
	possible for entities identified using different name spaces to		possible for entities identified using different name spaces to
	communicate as long as the two parties can understand both name spaces.		communicate as long as the two parties can understand both name spaces.
	Principals in the network will need to be able to reverse lookup a		Principals in the network will need to be able to reverse lookup a
	certificate (or equivalent information) using the Master Key ID. There		certificate (or equivalent information) using the Master Key ID. There
	are no security issues in the binding between a name in its native name		are no security issues in the binding between a name in its native name
	space, and the message digest derived Master Key ID, since there is a		space, and the message digest derived Master Key ID, since there is a
	cryptographic binding between two. The collision resistance property of		cryptographic binding between two. The collision resistance property of
	skipping to change at page 16, line 19 ¶		skipping to change at page 13, line 4 ¶
	Similarly Destination Master Key-IDs can serve many purposes as well.		Similarly Destination Master Key-IDs can serve many purposes as well.
	When the Destination Master Key-ID refers to an IP address, it can be		When the Destination Master Key-ID refers to an IP address, it can be
	used to pass end-to-end encrypted SKIP packets through an encrypting		used to pass end-to-end encrypted SKIP packets through an encrypting
	intermediate node. Without a destination Master Key-ID, an intermediate		intermediate node. Without a destination Master Key-ID, an intermediate
	node which is encrypting/decrypting SKIP packets for multiple machines		node which is encrypting/decrypting SKIP packets for multiple machines
	would have no way of knowing whether a received packet should be		would have no way of knowing whether a received packet should be
	uncompressed/decrypted/authenticated or just forwarded. A destination		uncompressed/decrypted/authenticated or just forwarded. A destination
	Master Key-ID enables an encrypting intermediate node (e.g., router or		Master Key-ID enables an encrypting intermediate node (e.g., router or
	firewall) to determine whether to process a packet or simply forward it.		firewall) to determine whether to process a packet or simply forward it.
	The destination Master Key-ID is present when the Destination NSID is		The destination Master Key-ID is present when the Destination NSID is
	non-zero.		non-zero.
	On an end node, the Destination Master Key-ID can be used to distinguish		On an end node, the Destination Master Key-ID can be used to distinguish
	between multiple users on the same IP node.		between multiple users on the same IP node.
	If the Source NSID is non-zero, the source Master Key-ID MUST be used		If the Source NSID is non-zero, the source Master Key-ID MUST be used
	for public value lookups and the source IP address MUST NOT be used. If		for public value lookups and the source IP address MUST NOT be used. If
	the Destination NSID is non-zero, the destination Master Key-ID MUST be		the Destination NSID is non-zero, the destination Master Key-ID MUST be
	used for public value lookups and the destination IP address MUST NOT be		used for public value lookups and the destination IP address MUST NOT be
	used.		used.
	Note: A node MUST NOT process a packet which has a destination Master		Note: A node MUST NOT process a packet which has a destination Master
	Key-ID that does not match a local Master Key-ID even if the destination		Key-ID that does not match a local Master Key-ID even if the destination
	IP address matches.		IP address matches.
	Some commonly used name spaces have been assigned NSIDs. These are		Some commonly used name spaces have been assigned NSIDs. These are
	specified in section 5.3 in the "Assigned Numbers" section below. More		specified in section 4.3 in the "Assigned Numbers" section below. More
	name spaces will be registered through IANA.		name spaces will be registered through Internet Assigned Numbers
			Authority (IANA).
	1.10 The SKIP Header		1.8 The SKIP Header
	A SKIP header communicates the in-band keying, algorithms and next		A SKIP header communicates the in-band keying, algorithms and next
	protocol used in the packet. The SKIP header is illustrated below.		protocol used in the packet. The SKIP header is illustrated below.
	Fields are transmitted left to right. All 32 bit quantities in the SKIP		Fields are transmitted left to right. All value fields in the SKIP
	header are transmitted in network order.		header are transmitted in network order.
	SKIP Header		SKIP Header
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Ver | Rsvd | Source NSID | Dest NSID | NEXT HEADER |		| Ver | Rsvd | Source NSID | Dest NSID | NEXT HEADER |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Counter n |		| Counter n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kij Alg | Crypt Alg | MAC Alg | Comp Alg |		| Kij Alg | Crypt Alg | MAC Alg | Comp Alg |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kp encrypted in Kijn... (typically 8-16 bytes)		| Kp encrypted in Kijn... (typically 8-16 bytes)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Master Key-ID (If Source NSID is non-zero)		| Source Master Key-ID (If Source NSID is non-zero)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination Master Key-ID (If Dest NSID is non-zero)		| Destination Master Key-ID (If Dest NSID is non-zero)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The first field of the SKIP header is the Version (Ver). The protocol		The first field of the SKIP header is the Version (Ver). The protocol
	described in this document is 1. The 4 bits following the version are		described in this document is 1. The 4 bits following the version are
	reserved for future versions of SKIP, and will be set to zero by all		reserved for future versions of SKIP, and will be set to zero by all
	SKIP v1 implementations. A non-zero Source NSID indicates that a packet		SKIP v1 implementations and ignored. A non-zero Source NSID indicates
	contains a source Master Key-ID. The value of the Source NSID indicates		that a packet contains a source Master Key-ID. The value of the Source
	the name space from which the Master Key-ID is derived. A non-zero Dest		NSID indicates the name space from which the Master Key-ID is derived. A
	NSID indicates the SKIP header contains a destination Master Key-ID. The		non-zero Dest NSID indicates the SKIP header contains a destination
	value of the Dest NSID indicates the name space from which the Master		Master Key-ID. The value of the Dest NSID indicates the name space from
	Key-ID is derived.		which the Master Key-ID is derived.
	Following the NSID bytes in the SKIP header, the NEXT HEADER field is		Following the NSID bytes in the SKIP header, the NEXT HEADER field is
	used to indicate which protocol follows the SKIP header. This field will		used to indicate which protocol follows the SKIP header. This field will
	usually indicate ESP or AH. But the NEXT HEADER may be any protocol		usually indicate ESP or AH. But the NEXT HEADER may be any protocol
	which requires keying material. Examples of protocols other than AH/ESP		which requires keying material. Examples of protocols other than AH/ESP
	that may use SKIP are given later.		that may use SKIP are given later.
	The "Counter n" field is a 32 bit field which is used for coarse grain		The "Counter n" field is a 32 bit field which is used for coarse grain
	playback protection and to prevent compromised key re-use.		playback protection and to prevent compromised key re-use.
	skipping to change at page 18, line 20 ¶		skipping to change at page 15, line 20 ¶
	length of Kp is derived from knowledge of the encryption/MAC algorithms.		length of Kp is derived from knowledge of the encryption/MAC algorithms.
	The low order key-length bits of the decrypted output are used as Kp.		The low order key-length bits of the decrypted output are used as Kp.
	The Crypt Alg and MAC Alg specify algorithms used by the interior		The Crypt Alg and MAC Alg specify algorithms used by the interior
	protocol for encryption and authentication. These algorithms are		protocol for encryption and authentication. These algorithms are
	specific to the protocol which will use them and the transforms it		specific to the protocol which will use them and the transforms it
	specifies. In general, the MAC Alg specifies the algorithm used to		specifies. In general, the MAC Alg specifies the algorithm used to
	calculate a MAC and the Crypt Alg specifies the algorithm used to		calculate a MAC and the Crypt Alg specifies the algorithm used to
	encrypt the packet. This is not an absolute, however. For instance, it		encrypt the packet. This is not an absolute, however. For instance, it
	is possible to have a Crypt Alg which provides both encryption and MAC		is possible to have a Crypt Alg which provides both encryption and MAC
	computation. This is further described in section 1.15.2.		computation.
	The Comp Alg field specifies the algorithm that was used to compress		The Comp Alg field specifies the algorithm that was used to compress
	packets prior to encryption/authentication. A non-zero Comp Alg field		packets prior to encryption/authentication. A non-zero Comp Alg field
	indicates that compression was performed on the plaintext, prior to		indicates that compression was performed on the plaintext, prior to
	encryption/authentication. The value of the Comp Alg field indicates the		encryption/authentication. The value of the Comp Alg field indicates the
	compression algorithm that was employed.		compression algorithm that was employed.
	The values for the algorithm fields will be described later in this		The values for the algorithm fields will be described later in this
	document.		document.
	skipping to change at page 18, line 43 ¶		skipping to change at page 15, line 43 ¶
	The source Master Key-ID field contains the Master Key-ID of the sender.		The source Master Key-ID field contains the Master Key-ID of the sender.
	This field is only present if the Source NSID is non-zero.		This field is only present if the Source NSID is non-zero.
	The destination Master Key-ID field contains the Master Key-ID of the		The destination Master Key-ID field contains the Master Key-ID of the
	intended SKIP receiver. This field is only present if the Dest NSID is		intended SKIP receiver. This field is only present if the Dest NSID is
	non-zero.		non-zero.
	In a specific use of the SKIP header, a field may not be relevant, and		In a specific use of the SKIP header, a field may not be relevant, and
	its value will be denoted as RESERVED. All RESERVED fields MUST be set		its value will be denoted as RESERVED. All RESERVED fields MUST be set
	to zero in the SKIP header.		to zero in the SKIP header and ignored.
	1.11 The relative order of compression, encryption and authentication
	The protocol allows three potential transforms to be performed, namely
	compression, encryption and authentication. The order in which these
	transforms are performed is very important. It is desirable for
	encryption to follow compression, because encrypted data is not
	(generally) compressible. Authentication must follow encryption and/or
	compression.
	Therefore SKIP compliant implementations MUST use the following order.
	For outgoing IP packets, a) IF compression is to be performed then the
	data is first compressed b) and IF encryption is to be performed, then
	the output of step a) is encrypted, c) and IF authentication is to be
	performed, then the output of step b) is authenticated. If, for example,
	all three transforms are being performed, then first data gets
	compressed, compressed data gets encrypted, and the compressed-encrypted
	data is authenticated.
	Received packets MUST be transformed using the reverse order. If
	authentication is being used then the packets will be checked for
	authenticity first. Only if the packets pass the authentication phase
	will they be decrypted if encryption was performed, and then
	uncompressed if compression was performed.
	1.12 Deriving Keys for Packet Encryption and Authentication		1.9 Deriving Keys for Packet Encryption and Authentication
	In general, packets may be both encrypted and authenticated. An		In general, packets may be both encrypted and authenticated. An
	important issue when performing both authentication and encryption is		important issue when performing both authentication and encryption is
	key separation. Namely, the authentication and encryption keys MUST be		key separation. Conforming SKIP implementations MUST derive
	different. This allows, for example, encryption keys to be short		authentication and encryption keys originating via SKIP in the manner
	(possibly to satisfy export control laws) while keeping the		specified below.
	authentication key as long as necessary. Furthermore, it must be
	infeasible to derive either one of the authentication key or the
	encryption key, should one of them be compromised.
	This is accomplished as follows. The Kp that is decrypted from the		The Kp that is decrypted from the packet header is not used directly to
	packet header is not used directly to encrypt/decrypt or authenticate		encrypt/decrypt or authenticate the packet. Rather, it is used to derive
	the packet. Rather, it is used to derive two separate keys named E_kp		two separate keys named E_kp and A_kp, where A_kp is used as the
	and A_kp, where A_kp is used as the authentication key and E_kp is used		authentication key and E_kp is used as the encryption key. E_kp and
	as the encryption key. E_kp and A_kp are related to the Kp decrypted		A_kp are related to the Kp decrypted from the packet header as follows:
	from the packet header as follows:
	E_kp = h(Kp | 01h) | h(Kp | 00h)		E_kp = h(Kp | Crypt Alg | 02h) | h(Kp | Crypt Alg | 00h)
	A_kp = h(Kp | 03h) | h(Kp | 02h)		A_kp = h(Kp | MAC Alg | 03h) | h(Kp | MAC Alg| 01h)
	where h() is a pseudo-random, one-way hash function, for example, MD5.		where h() is a pseudo-random, one-way hash function, for example, MD5.
	For this version of SKIP, the one-way function MUST be MD5. The "|"		For this version of SKIP, the one-way function MUST be MD5. The "|"
	above specifies concatenation, in the same manner as described in		above specifies concatenation, in the same manner as described in
	Section 1.3 above. The construction above has the property that knowing		section 1.2 above. Crypt Alg and MAC Alg are the 1 byte fields from the
			SKIP header. The construction above has the property that knowing
	either one of E_kp or A_kp does not compromise any information about the		either one of E_kp or A_kp does not compromise any information about the
	other key, because of the one-way property of MD5. This allows, e.g.,		other key, because of the one-way property of MD5. This allows, e.g.,
	weak encryption keys to be used with strong authentication keys. Should		weak encryption keys to be used with strong authentication keys. Should
	E_kp be compromised, nothing at all is revealed about A_kp, and vice		E_kp be compromised, nothing at all is revealed about A_kp, and vice
	versa.		versa.
	The actual number of key bits used is algorithm dependent. If the		The actual number of key bits used is algorithm dependent. If the
	algorithms require less than 256 bits, then the low order key-size bits		algorithms require less than 256 bits, then the low order key-size bits
	of the output of the pseudo-random one-way functions are used as the		of the output of the pseudo-random one-way functions are used as the
	actual keys. If less than 128 bits of encryption key is required, then		actual keys. If less than 128 bits of encryption key is required, then
	only the MD5(Kp | 00h) function needs to be computed, because this		only the MD5(Kp | 00h) function needs to be computed, because this
	provides the low order 128 bits of E_kp. Similarly, if only 128 bits or		provides the low order 128 bits of E_kp. Similarly, if only 128 bits or
	less are required for the authentication key A_kp, only the MD5(Kp |		less are required for the authentication key A_kp, only the MD5(Kp | MAC
	02h) function needs to be computed.		Alg | 01h) function needs to be computed.
	When using MD5, the function specified above provides a total of 256		When using MD5, the function specified above provides a total of 256
	bits, which is a sufficient number of key bits for the expected		bits, which is a sufficient number of key bits for the expected
	encryption and authentication algorithms that will be used with SKIP.		encryption and authentication algorithms that will be used with SKIP.
	An implementation will use the maximum of the key-lengths indicated by		An implementation will use the maximum of the key-lengths indicated by
	Crypt Alg and MAC Alg when determining the length of the actual Kp that		Crypt Alg and MAC Alg when determining the length of the actual Kp that
	will be decrypted from the SKIP header. For example, if Crypt Alg		will be decrypted from the SKIP header. For example, if Crypt Alg
	specifies a 64-bit encryption key length, the MAC algorithm specifies a		specifies a 64-bit encryption key length, the MAC algorithm specifies a
	128-bit authentication key length, then the length of Kp will be 128		128-bit authentication key length, then the length of Kp will be 128
	skipping to change at page 21, line 23 ¶		skipping to change at page 17, line 38 ¶
	decoding.		decoding.
	The key separation function described above is ALWAYS used, irrespective		The key separation function described above is ALWAYS used, irrespective
	of whether only one or the other of authentication or encryption is		of whether only one or the other of authentication or encryption is
	being performed. Namely, even if encryption is being done in the absence		being performed. Namely, even if encryption is being done in the absence
	of authentication or authentication is being done in the absence of		of authentication or authentication is being done in the absence of
	encryption, the keys used for encryption and/or authentication MUST be		encryption, the keys used for encryption and/or authentication MUST be
	derived separately as specified above. Kp is NEVER used directly to		derived separately as specified above. Kp is NEVER used directly to
	authenticate or encrypt traffic.		authenticate or encrypt traffic.
	1.13 SKIP for Authentication		1.10 SKIP for Authentication
	Note: Packet authentication and packet integrity are used		This section describes how SKIP compliant implementations use SKIP
	interchangeably in this document, since there is no meaningful		originated keys to achieve packet authentication.
	cryptographic distinction between the two.
	In order to achieve authentication in the absence of privacy, SKIP		In order to achieve authentication in the absence of privacy, SKIP
	compliant implementations use the key A_kp to compute a Message		compliant implementations use the key A_kp to compute a Message
	Authentication Code (MAC) over the packet and invariant clear header		Authentication Code (MAC) over the packet and invariant clear header
	fields. The term "MAC" is synonymous with the term "Authentication Data"		fields. The term "MAC" is synonymous with the term "Authentication Data"
	in RFC 1826.		in RFC 1826.
	The MAC Alg field in the SKIP header MUST be used to lookup a specific		The MAC Alg field in the SKIP header MUST be used to lookup a specific
	authentication transform. The key A_kp is used as a key to compute a MAC		authentication transform. The key A_kp is used as a key to compute a MAC
	using, for example, Keyed MD5. The MAC is inserted into the encapsulated		using, for example, Keyed MD5. The MAC is inserted into the encapsulated
	protocol in whatever way the encapsulated protocol defines.		protocol in whatever way the encapsulated protocol defines.
	As always, Kij Alg identifies the encryption algorithm used to encrypt		As always, Kij Alg identifies the encryption algorithm used to encrypt
	Kp.		Kp.
	1.13.1 SKIP with AH		1.10.1 Scope of MAC computation
			All non-reserved SKIP header fields MUST be included in the IP
			Authentication Header's calculation of Authentication Data. The
			RESERVED fields in the SKIP header are zeroed for the purpose of IP
			Authentication Header's Authentication Data calculation.
			1.11 SKIP for Encryption
			When SKIP is used to supply keying material for encryption only, the
			Crypt Alg indicates the packet encryption algorithm. E_kp is used as a
			key to the Crypt Alg. The Crypt Alg will be mapped to standard
			transforms such as [15]. These transforms will also contain information
			such as Initialization Vectors (IVs) or Message Indicators (MIs).
			As always, Kij Alg identifies the encryption algorithm used to encrypt
			Kp.
			1.12 SKIP with combined transforms
			For transforms which combine encryption and authentication such as ESP
			using Keyed MD5 with DES-CBC, only an one header, ESP in this case, is
			needed. The Crypt Alg in the SKIP header will indicate the transform
			and A_kp would be used for authentication and the E_kp (as discussed in
			section 1.9) would be used for encryption. The MAC Alg field MUST
			contain the same value as the Crypt Alg field, since this would be a
			combined authentication/encryption transform.
			1.13 Generic use of SKIP header
			The SKIP header may be used for any protocol which requires keying
			material. The next header in the SKIP header would specify this
			protocol. A protocol being encapsulated SHOULD have a reserved value
			which indicates that the keying material to be used is in the SKIP
			header. An example of this kind of reserved value is SKIP_SPI which is
			used by the AH and ESP protocols. The protocol will define how the
			Crypt, MAC and Compression algorithms will be used. Kijn will be used to
			encrypt Kp.
			2. Security Considerations
			2.1 Generating Random Keys
			One of the most important considerations in a software only
			implementation of SKIP is to design an unpredictable pseudo-random
			number generation procedure. Weak and unpredictable sources of random
			number generation would be catastrophic to the security of SKIP or
			indeed any scheme that implements cryptography, no matter what the
			length of key and choice of encryption algorithm might be.
			In particular, common mistakes that MUST be avoided in implementing this
			unpredictable random number generator is to use values like the current
			process id, the host id or ethernet address, the current time of day or
			some simple combination of these as the sole input to generate a
			cryptographic key. These values are really not all that unpredictable.
			It must be ensured that there are at least as many truly random bits
			used in the key production phase as are specified in the chosen key
			length for that algorithm. None of these commonly used sources by
			themselves provide sufficiently many random bits for commonly used
			cryptographic algorithms.
			For more information on the subject of generating random keys, RFC 1750
			[12] is recommended reading.
			2.2 Key Update
			The best way to frustrate cryptanalysis of encryption and authentication
			keys is to periodically update the key used to encrypt or authenticate
			packets. Whereas the exact frequency with which keys are updated SHOULD
			be configurable based on site policies, some recommended parameters are
			provided.
			The traffic encryption/authentication key SHOULD be updated for every 10
			Mbytes of protected traffic, or once every 2 minutes, which ever one
			results in a more frequent update policy.
			The traffic encryption/authentication key (derived using Kp) MUST be
			updated every time a Kijn is updated. In addition, in case multiple
			Kijn's exist on a given node, then Kp MUST NOT be shared among different
			Kijns. Kp MUST be randomly generated for each end destination, and for
			different principals on the same node.
			2.3 Choosing Key Strengths
			When implementing different key-encryption, traffic encryption, and
			key-agreement algorithms, a consistent set of key strengths MUST be
			chosen. This means that if a traffic key is, say 128 bits strength, then
			the key encryption key MUST be of strength 128-bits or greater. It isn't
			sensible to choose strong traffic protection algorithms and then encrypt
			the keys using weaker algorithms.
			Similarly, when using 128-bit symmetric keys, the modulus lengths for
			classic Diffie-Hellman (used to derive the master keys) MUST be 1024
			bits or greater. The exponent size for classic Diffie-Hellman for
			symmetric master key sizes of 128 bits MUST be 256 bits or greater.
			Also, when 128-bit keyed MD5 is used, then the key-encryption algorithms
			SHOULD have strength equal to or greater than 128-bits. For
			interoperability purposes, use of Algorithm #2 (3 key triple DES-EDE-
			CBC) is deemed mandatory to implement for key encryption (Kij Alg), when
			also implementing keyed MD5 as specified in RFC 1829 for traffic
			authentication purposes, or any 128-bit strength traffic encryption
			algorithm (e.g. 2 or 3 key triple DES or IDEA).
			2.4 Forward Secrecy
			Perfect forward secrecy as described in [3] is not addressed by the base
			protocol described in this document. The protocol as described has a
			small amount of bilateral state. The risk of compromise of past
			encrypted traffic due to future compromise of long-term keying material
			may be minimized by minimizing the longevity of any particular master
			key. Future extensions to the base SKIP protocol may address forward
			secrecy by either having short lived certified DH public values, or by
			introducing an ephemeral DH component into the master key computation.
			Doing the latter would introduce greater bilateral state and overhead
			than is in the base SKIP protocol.
			3. Informational Section
			This section gives examples of how SKIP is used with various IP security
			encapsulation protocols such as AH and ESP.
			3.1 SKIP with AH
	The AH Protocol [9] is used to provide authentication for IP datagrams.		The AH Protocol [9] is used to provide authentication for IP datagrams.
	The SKIP header precedes the AH header and follows the IP header as		The SKIP header precedes the AH header and follows the IP header as
	shown below:		shown below:
	+-------------+----------+----------+-------------------------------+		+-------------+----------+----------+-------------------------------+
	| IPv4 Header | SKIP Hdr | Auth Hdr |Inner Protocol(e.g.IP, TCP,UDP)|		| IPv4 Header | SKIP Hdr | Auth Hdr |Inner Protocol(e.g.IP, TCP,UDP)|
	+-------------+----------+----------+-------------------------------+		+-------------+----------+----------+-------------------------------+
	IPv4 with SKIP/AH Example		IPv4 with SKIP/AH Example
	The detailed protocol encoding for SKIP followed by an AH header is		The detailed protocol encoding for SKIP followed by an AH header is
	shown below.		shown below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Clear IP Header protocol = SKIP... (typically 20-bytes)		| Clear IP Header protocol = SKIP... (typically 20-bytes)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=AH | |		| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=AH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Counter n |		| Counter n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP hdr		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP hdr
	| Kij Alg | RESERVED | MAC Alg | Comp Alg |		| Kij Alg | RESERVED | MAC Alg | Comp Alg |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Kp encrypted in Kijn... (typically 8-16 bytes) |		| Kp encrypted in Kijn... (typically 8-16 bytes) |
	skipping to change at page 23, line 5 ¶		skipping to change at page 22, line 5 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Authentication Data computed using A_kp (variable Length | |		| Authentication Data computed using A_kp (variable Length | |
	+---------------+---------------+ ---		+---------------+---------------+ ---
	The SPI field in the AH header is filled with SKIP_SPI to indicate that		The SPI field in the AH header is filled with SKIP_SPI to indicate that
	keying material and algorithm information is present in the preceding		keying material and algorithm information is present in the preceding
	SKIP header. The authentication data and location of the computed MAC is		SKIP header. The authentication data and location of the computed MAC is
	defined by the specific transforms. See, e.g., RFC 1828 [14], as an		defined by the specific transforms. See, e.g., RFC 1828 [14], as an
	example of an authentication transform.		example of an authentication transform.
	1.13.2 Scope of MAC computation		3.2 SKIP with ESP
	The scope of the MAC computation is the entire packet, including the
	outer clear IP header, followed by the SKIP header, followed by AH
	header, and finally, the payload of the AH header.
	RFC 1826 describes the scope of the MAC computation and the treatment of
	fields in the AH header as well as IP header fields that may change in
	transit. SKIP implementations MUST follow the MAC computation procedure
	as defined in RFC 1826. In addition to inclusion of the IP and AH
	headers as specified in RFC 1826, SKIP implementations MUST include the
	SKIP header for purposes of MAC computation. For purposes of MAC
	computation, all SKIP header fields MUST be treated as containing the
	values that a SKIP receiver will see. Any RESERVED values in the SKIP
	header MUST be treated as zero for purposes of MAC computation.
	1.14 SKIP for Encryption
	When SKIP is used to supply keying material for encryption only, the
	Crypt Alg indicates the packet encryption algorithm. E_kp is used as a
	key to the Crypt Alg. The Crypt Alg will be mapped to standard
	transforms such as [15]. These transforms will also contain information
	such as Initialization Vectors or Message Indicators.
	As always, Kij Alg identifies the encryption algorithm used to encrypt
	Kp.
	1.14.1 SKIP with ESP
	An example of use of SKIP for encryption is SKIP combined with the ESP		An example of use of SKIP for encryption is SKIP combined with the ESP
	protocol [10]. The ESP protocol can be used to provide confidentiality		protocol [10]. The ESP protocol can be used to provide confidentiality
	of entire IP datagrams or the payload of IP datagrams, depending on		of entire IP datagrams or the payload of IP datagrams, depending on
	whether ESP is operating in tunnel or transport mode respectively. The		whether ESP is operating in tunnel or transport mode respectively. The
	SKIP header follows the IP header and precedes the ESP header as shown		SKIP header follows the IP header and precedes the ESP header as shown
	below:		below:
	+-------------+----------+----------+-------------------------------+		+-------------+----------+----------+-------------------------------+
	| IPv4 Header | SKIP Hdr | ESP Hdr |Inner Protocol (e.g.IP,TCP,UDP)|		| IPv4 Header | SKIP Hdr | ESP Hdr |Inner Protocol (e.g.IP,TCP,UDP)|
	+-------------+----------+----------+-------------------------------+		+-------------+----------+----------+-------------------------------+
	IPv4 with SKIP/ESP Example		IPv4 with SKIP/ESP Example
	The detailed protocol encoding of SKIP combined with ESP is illustrated		The detailed protocol encoding of SKIP combined with ESP is illustrated
	below:		below:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Clear IP Header protocol = SKIP... (typically 20-bytes)		| Clear IP Header protocol = SKIP... (typically 20-bytes)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=ESP| |		| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=ESP| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Counter n |		| Counter n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
	| Kij Alg | Crypt Alg | RESERVED | Comp Alg |		| Kij Alg | Crypt Alg | RESERVED | Comp Alg |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Kp encrypted in Kijn... (typically 8-16 bytes) |		| Kp encrypted in Kijn... (typically 8-16 bytes) |
	skipping to change at page 24, line 41 ¶		skipping to change at page 23, line 13 ¶
	Key-IDs are absent.		Key-IDs are absent.
	The Opaque transform data is defined by the particular transform (such		The Opaque transform data is defined by the particular transform (such
	as DES-CBC in RFC 1829). This data will normally contain the encrypted		as DES-CBC in RFC 1829). This data will normally contain the encrypted
	data and transform specific information such as the IV.		data and transform specific information such as the IV.
	Kij Alg identifies the encryption algorithm used to encrypt Kp. Kp is		Kij Alg identifies the encryption algorithm used to encrypt Kp. Kp is
	used to derive the key E_kp (as specified above) which is used to		used to derive the key E_kp (as specified above) which is used to
	encrypt the payload.		encrypt the payload.
	1.15 SKIP for Authentication and Encryption		3.3 SKIP with AH and ESP
	There are two ways to provide authentication and encryption using SKIP.
	One is to combine the use of the AH & ESP headers, where AH provides
	authentication and ESP provides encryption. The other is to use an ESP
	transform that provides both authentication and encryption. The
	difference between the two is the scope of the authentication algorithm.
	AH includes the outer IP header in the authentication algorithm. A
	combined authentication/encryption ESP transform would encrypt and
	authenticate only the ESP payload, and not the headers outside of ESP.
	1.15.1 SKIP with AH and ESP
	SKIP can be used with combined AH/ESP modes. The Next protocol field in		SKIP can be used with combined AH/ESP modes. The Next protocol field in
	the SKIP header would be AH and the Next protocol field in AH header		the SKIP header would be AH and the Next protocol field in AH header
	would ESP.		would ESP.
	+----------+----------+----------+---------+------------------------------+		+----------+----------+----------+---------+------------------------------+
	| IPv4 Hdr | SKIP Hdr | Auth Hdr | ESP Hdr |Inner Protocol(e.g.IP,TCP,UDP)|		| IPv4 Hdr | SKIP Hdr | Auth Hdr | ESP Hdr |Inner Protocol(e.g.IP,TCP,UDP)|
	+----------+----------+----------+---------+------------------------------+		+----------+----------+----------+---------+------------------------------+
	IPv4 with SKIP/AH/ESP Example		IPv4 with SKIP/AH/ESP Example
	A_Kp would be used for authentication and E_kp (as discussed in section		A_Kp would be used for authentication and E_kp (as discussed in section
	1.12) would be used for encryption.		1.9) would be used for encryption.
	The following is an example of SKIP with AH and ESP. In Addition, the		The following is an example of SKIP with AH and ESP. In Addition, the
	use of Master Key-ID's is also demonstrated.		use of Master Key-ID's is also demonstrated.
	SKIP Header		SKIP Header
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Clear IP Header protocol = SKIP... (typically 20-bytes)		| Clear IP Header protocol = SKIP... (typically 20-bytes)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=AH | |		| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=AH | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Counter n | |		| Counter n | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Kij Alg | Crypt Alg | MAC ALG | Comp Alg |		| Kij Alg | Crypt Alg | MAC ALG | Comp Alg |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
	| Kp encrypted in Kijn... (typically 8-16 bytes)		| Kp encrypted in Kijn... (typically 8-16 bytes)
	skipping to change at page 26, line 35 ¶		skipping to change at page 24, line 35 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SKIP_SPI | Auth Hdr		| SKIP_SPI | Auth Hdr
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Variable Length AH MAC, computed using A_kp |		| Variable Length AH MAC, computed using A_kp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| SKIP_SPI |		| SKIP_SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr
	| ESP transform data (e.g. IV), payload encrypted using E_kp | |		| ESP transform data (e.g. IV), payload encrypted using E_kp | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	1.15.2 SKIP with combined ESP transforms		4. Assigned Numbers
	For ESP transforms which combine encryption and authentication (for
	instance: Keyed MD5 with DES-CBC), only an ESP header is needed. The
	Crypt Alg in the SKIP header will indicate the transform and A_kp would
	be used for authentication and the E_kp (as discussed in section 1.12)
	would be used for encryption. The MAC Alg field MUST contain the same
	value as the Crypt Alg field, since this would be a combined
	authentication/encryption transform.
	1.16 Generic use of SKIP header
	The SKIP header may be used for any protocol which requires keying
	material. The next header in the SKIP header would specify this
	protocol. A protocol being encapsulated SHOULD have a reserved value
	which indicates that the keying material to be used is in the SKIP
	header. An example of this kind of reserved value is SKIP_SPI which is
	used by the AH and ESP protocols. The protocol will define how the
	Crypt, MAC and Compression algorithms will be used. Kijn will be used to
	encrypt Kp.
	In particular it is possible to pass SKIP in the payload of a TCP/UDP
	packet. This allows the key-management and encryption/authentication to
	be performed in the application protocol (above TCP/UDP), and there may
	be times where it is advantageous to do so.
	2. SKIP for Multicast IP
	We describe multicast key distribution in two specific contexts. The
	first is in the context of a transient multicast group, where an
	application, such as video/audio conferencing, dynamically allocates a
	multicast address or addresses, uses it for a period of time, and then
	relinquishes these multicast addresses.
	The second is in the context of permanent multicast groups, where a
	fixed set of well known multicast addresses is used by participants of
	the protocol. An example of this is routing protocols that use well
	known multicast addresses in order to propagate routing information in
	the network.
	Broadcast IP may be considered a special case of the second context,
	where a set of well known IP addresses serve as broadcast addresses for
	a subnetwork.
	2.1 Transient Multicast Groups
	A simple extrapolation of SKIP for unicast IP gives a scalable key-
	management scheme for IP multicast applications. In order to achieve
	secure transient multicast groups, key-management awareness needs to
	exist in the multicast group-join process.
	Furthermore, in order to distribute multicast keying material, the
	notion of a group owner needs to exist. How the identity of the group
	owner is established and communicated to the participating nodes is left
	to the application layer. However, this also needs to be done in a
	secure fashion, otherwise the underlying key-management can be defeated.
	When secure multicasting to multicast address M is required, a group
	membership creation primitive will establish the group key Kg and the
	membership list of addresses that are allowed to transmit and receive
	encrypted multicast datagrams to and from group address M. This action
	will be taken by the group owner.
	An important point is that the group key Kg is not used as a packet
	encryption key, but rather as the Group Interchange Key (GIK). Namely,
	Kg is used as a key-encrypting-key, similar to way the master keys Kij
	are used in SKIP for unicast IP.
	Nodes wishing to transmit/receive encrypted datagrams to multicast
	address M need to acquire the GIK Kg. This is done by sending an
	encrypted/authenticated request-to-join primitive to the group owner. If
	the requesting node's address is part of the group's authorized
	membership list, then the group owner will send the GIK Kg, algorithm
	identifier, associated lifetime information and key-change policy in an
	encrypted packet, using the unicast SKIP protocol described in Section 1
	above.
	The packet formats for the GIK request/response is given below. This
	describes the payload portion of either a TCP or UDP packet, which has
	been enhanced using SKIP unicast procedures. If using UDP, multiple
	requests may need to be sent, in case of packet losses of earlier
	requests/response messages. The request is sent to TCP/UDP port #
	skip-mc-gikreq (which is specified in section 5.7). It is sent to the
	group owner's unicast IP address.
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version = 1 | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP Multicast Address M |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The first field specifies the version of this protocol, which is 1. It
	is followed by the actual IP multicast address for which the GIK is
	being requested. The request packet that is sent must have the minimal
	enhancement of source-origin authentication, which is accomplished using
	the AH protocol. The group owner's response is an encrypted packet
	containing the GIK Kg. The response is sent to the requestor's
	ephemeral TCP/UDP port at the requester's unicast IP address. The packet
	format is as follows, and as before, it defines the data-portion of a
	TCP or UDP packet.
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Version = 1 | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IP Multicast Address M |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Expiry time (low 32-bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Expiry time (high 32-bits |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Recommended Key Change Interval (in seconds) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Recommended Key Change Interval (in bytes) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kg Alg | Crypt Alg | MAC Alg | Comp Alg |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kg .... (length dependent on Kg Alg)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The 64-bit expiry time specifies when the multicast key is considered to
	have expired. This is in terms of seconds since, 0h Jan 1, 1995,
	expressed in GMT. The Recommended Key-Change interval is what every
	source of encrypted traffic to the multicast group uses to determine the
	key-change policy. There are two ways of specifying key-change policy.
	One is in terms of elapsed time since last key-change. This is specified
	by the "Recommended Key Change Interval (in seconds)" field, which
	specifies the number of seconds to wait before changing keys. The other
	is in terms of the amount of data encrypted in a given packet encryption
	key. This is specified using the "Recommended Key Change Interval (in
	bytes)" field. Each source of encrypted traffic MUST use whichever of
	these determines the more frequent key-change policy, whether this is in
	terms of amount of traffic encrypted in a given key, or in terms of
	elapsed time (in seconds) since the last key change.
	Kg Alg refers to the algorithm used for multicast traffic key
	encryption. Crypt Alg, MAC Alg and Comp Alg refer to the multicast
	traffic encryption, authentication and compression algorithms,
	respectively. These are the algorithms that sources of protected traffic
	to the multicast group MUST use for multicast traffic.
	The key Kg is updated using the zero-message master key update procedure
	described in section 1.3. Instead of using Kij as the input to
	generating the n'th master key Kijn, the multicast key Kg shall be used
	to generate the n'th level GIK, labeled Kgn.
	To precisely define the master key update procedure in the context of
	broadcast/multicast groups:
	Kgn = h(Kg | n | 01H) | h(Kg | n | 00H)
	where h() is a pseudo-random, one-way hash function, for example, MD5.
	For this version of SKIP, the one-way function MUST be MD5. The "|"
	represents concatenation. The low order bits of the output of this
	operation are used for Kgn. Kgn is then used to encrypt packet keys,
	analogous to how packet keys are protected for unicast IP using Kijn.
	Transmitting nodes to group address M will randomly generate packet
	encryption keys Kp, and encrypt these keys using Kgn. The packet
	structure is similar to the structure used for encrypted unicast SKIP
	packets, except that the packet keys Kp are not encrypted in the
	pairwise keys Kijn, but instead are encrypted using the GIK Kgn. An
	example encrypted multicast packet using ESP for packet encryption, is
	shown below.
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Clear IP Header protocol = SKIP... (typically 20-bytes)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Counter n |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
	| Reserved | Crypt Alg | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Kp encrypted in GIK Kgn... (typically 8-16 bytes) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| SPI=SKIP_SPI | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ESP Hdr
	| Opaque Transform Data, variable Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	The destination IP address will be used by the receiver to determine
	whether to use unicast or multicast key-processing procedures on a
	received IP packet. In case the destination address is an IP multicast
	address, it will use the GIK Kgn to decrypt the packet encryption key
	Kp. An implementation of this protocol MUST use the destination IP
	multicast address to lookup the GIK Kgn. (In this case the Destination
	NSID MUST be zero).
	There are two distinct advantages of this scheme. First, every member
	of the multicast group can update packet encryption keys as often as it
	needs (in line with the policy set by the group owner), without
	involving key-setup communications overhead involving every member of
	the group. This can be extremely frequent, e.g. once every few seconds
	even with very large multicast groups, because there is no extra
	communications overhead for updating packet encryption keys.
	Second, since all the packet encryption keys are randomly generated, and
	hence different, there is no problem in using stream-ciphers with
	multicast. This is because each source of encrypted traffic when using a
	stream cipher would use a different key-stream and thus there is no
	key-stream reuse problem. If all members of the multicast group used the
	same packet encryption key, then certain stream ciphers could not be
	used with multicast IP, because of problems related to key-stream reuse.
	2.2 Broadcast/Permanent Multicast Groups
	For broadcast and permanent multicast groups, the key distribution
	scheme is similar to the one described above for transient multicast
	groups, except that Kg is permanent and has no expiry date and may be
	manually distributed between authorized members of the group (multicast
	or broadcast).
	As for the case of transient multicast groups, the GIK Kgn is updated
	using the procedure described above for transient multicast groups. This
	allows for a simple, automated and scalable way of updating the master
	key used for the permanent group, which further frustrates cryptanalysis
	of the master key. Since n is a 32-bit number, the time it will take to
	overflow this counter, based on hourly updates of the master key, is
	sufficiently long to be a non-issue.
	Even when relying on manual key distribution to initialize a protected
	multicast/broadcast group, both the master and the traffic protection
	keys are automatically updated in a completely scalable manner, using
	the procedures described above.
	2.2.1 SKIP and RIPv2
	As an example of both how SKIP can be used to supply keys for protocols
	other than AH/ESP, and use of SKIP in the context of permanent multicast
	groups, we describe SKIP for RIPv2 [RFC 1388]. The RIP protocol
	specifies a field for authentication type and how to compute and
	distribute a MAC for authenticated RIP information.
	The authentication type of the first RIP entry would be set to a value
	which we will assign the symbolic name SKIP. The Authentication field
	would contain the MAC. The scope of authentication is identical to that
	of AH.
	Since RIP is a broadcast protocol, keying semantics are different than
	with unicast (as described in section 2.2).
	The following is an example of SKIP combined with RIP V2.
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Clear IP Header protocol = SKIP... (typically 20-bytes)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| Ver | Rsvd. | Source NSID | Dest NSID |NEXT HEADER=RIP| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Counter n | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SKIP Hdr
	| Kij Alg | RESERVED | MAC Alg | RESERVED | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Kp encrypted in Kgn ... (typically 8-16 bytes) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	| Command | Version | Routing Domain | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Address Family=0xFFFF | Authentication Type=SKIP_AUTH| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RIP Hdr
	| AUTHENTICATION (MAC) | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| ....Authenticated RIP Entries |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
	Here the packet authentication keys are encrypted using Kgn. Kgn is
	computed using procedures described in section 2.1 above.
	This use of SKIP to supply keys for non AH/ESP protocols is intended to
	be illustrative, and not exhaustive. Other protocols can similarly be
	used with SKIP, either in the context of unicast, or transient/permanent
	multicast and broadcast group communications.
	2.3 Multicast/Broadcast Authentication
	It is worth noting that all members of a group are considered equivalent
	from the point of view of multicast/broadcast authentication. There are
	no practical and efficient techniques to achieve multicast/broadcast
	authentication, where the authentication mechanism distinguishes between
	members of the same multicast group. Digital signatures is a technology
	that may be used for broadcast authentication, except all known
	signature techniques are too computationally expensive to be performed
	on a per packet basis.
	3. Algorithm Discovery
	An optional protocol is described for discovering the appropriate
	algorithms to use for various packet transformations, such as
	encryption, authentication, compression etc. Algorithm discovery is in
	many ways analogous to algorithm negotiation in conventional session
	oriented key setup. However, "negotiation" is a misnomer as applied to
	most existing protocols that accommodate this feature. This is because
	in essence there is no negotiation, simply a statement of capabilities
	on both sides. The sides agree to pick a common subset of their
	capabilities.
	SKIP allows the same statement of capabilities to occur in a stateless
	manner, entirely analogous to how the IP protocol performs path MTU
	discovery. A SKIP implementation is free to choose a set of algorithms
	with a particular node. If it chooses incorrectly, it will discover this
	through an authenticated ICMP message, which is in effect a statement of
	capabilities and preferences for that node.
	Keyed MD5 for authentication has been deemed mandatory to implement. The
	ICMP message MUST be authenticated using the algorithm specified in RFC
	1828 [14], which MUST be supported by all SKIP nodes that support this
	optional ICMP protocol.
	If a node (or communications end point) receives a SKIP packet which
	specifies algorithms it does not support (or prefer), it SHOULD send an
	authenticated ICMP message indicating this failure and specifying which
	algorithms it supports. The ICMP Packet MUST be encapsulated using SKIP
	and AH with keyed MD5 used as the algorithm. Any received algorithm
	discovery ICMP message that is not authenticated MUST be ignored.
	The Algorithm discovery ICMP message:
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TYPE=SKIP_ICMP| CODE | CHECKSUM |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RESERVED | Protocol | Port Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| nKij | nCrypt | nmac | ncomp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Current Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| n update Frequency (in seconds) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kij Algorithms (0-255), 1 byte each
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Crypt Algorithms (0-255), 1 byte each
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MAC Algorithms (0-255), 1 byte each
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Compression Algorithms (0-255), 1 byte each
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	CODE should be interpreted as a bit field in the following way:
	7 6 5 4 3 2 1 0
	+-+-+-+-+-+-+-+-+
	|I|P|M|C|N|R| |
	+-+-+-+-+-+-+-+-+
	I is set if the Kij algorithm in the SKIP packet is unsupported.
	P is set if the Crypt algorithm in the SKIP packet is unsupported.
	M is set if the MAC algorithm in the SKIP packet is unsupported.
	C is set if the compression algorithm in the SKIP packet is
	unsupported.
	N is set if an invalid n counter was sent in the packet
	R is set if replay protection is required but wasn't used
	in the SKIP packet. In case a replay protection mechanism
	is defined, this bit MAY be used to request replay protection.
	bits 0-1 are reserved and MUST be set to 0.
	The ICMP type field SKIP_ICMP is specified later in this document.
	The time field, Current Time, is set to the system's concept of current
	time in seconds since 0h Jan 1, 1995. This is analogous to the Integer
	portion of the NTP timestamp (except for the start time).
	The field "n update Frequency" is set with the value representing the
	number of seconds between increments of the n counter. For example, if
	the n counter is updated once an hour, this field would contain 3600.
	The next two fields "Protocol" and "Port Number", indicate if this
	algorithm discovery is to be applied only for a particular protocol/port
	# pair. This allows different communication end-points on an IP node to
	use different algorithms. An example of the protocol field could be the
	TCP protocol, followed by the port # which would identify a TCP end-
	point. If the Protocol field is non-zero, then the algorithm discovery
	packet MUST be applied ONLY for the specified communications end-point,
	as identified by the (Protocol, Port Number) fields.
	If the algorithms are to be used on a per Master Key-ID, rather than a
	per communications end-point basis, then the "Protocol" field MUST be
	zero. If the "Protocol" field is zero, the Port Number field MUST be
	ignored. In this case, the algorithms SHOULD be used on a per Master
	Key-ID basis, where the Master Key-ID is the Source Master Key-ID in the
	SKIP_ICMP SKIP header. If the source Master Key-ID is absent from the
	SKIP header, then the algorithms SHOULD be used on a per node basis,
	using the source IP address of SKIP_ICMP message as the node identifier.
	The RESERVED byte following "Protocol" and "Port Number" is unused and
	MUST be zero.
	The nKij, nKp, nmac and ncomp fields should be filled in with the number
	of Kij, Kp, MAC and Compression algorithms the system supports,
	respectively.
	The Kij, Kp, MAC and Compression algorithms fields should be filled in
	sequentially with the one byte identifiers for each of the algorithms
	that the system supports. The algorithms should be an ordered list with
	the most desirable algorithms first and the least desirable last.
	For instance, if the system supports 5 Kij algorithms, nKij would be set
	to 5 and the Kij Algorithms field would be 5 bytes long (one byte for
	each algorithm supported).
	A host may elicit a SKIP_ICMP message by sending a SKIP packet to the
	remote host with Kij Alg set to zero.
	4. Distribution of authenticated public values
	As mentioned earlier, a variety of mechanisms can be employed to
	authenticate public values, such as, X.509 certificates, PGP
	certificates, Secure DNS resource records and use of the message digest
	of a public value as the name of a principal.
	We define the encodings of the public values for the case where a
	principal's name is the message digest of its DH public value, and for
	use with signed X.509 certificates.
	4.1 Encoding of an Unsigned DH public value
	This encoding scheme is used to authenticate/distribute a DH public
	value, for cases where the principal's name is the message digest of the
	public value. Although the public value is distributed in an unsigned
	manner, there is still a strong binding between a name and the public
	value, given the collision resistance properties of a message digest.
	The principal's names need to be securely distributed out of band.
	The following is how the public value is encoded for purposes
	of message digest computation and distribution in the network.
	All 16/32 bit values are in network order.
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Not Valid before ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Not Valid After ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PrimeLen | Prime (p) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ..... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| GenLen | Generator (g) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ..... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PublicValueLen | Public Value (g^i mod p) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ..... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	"Not Valid Before" is the time which the public value becomes valid. It
	is in NTP time format (the Integer portion). "Not Valid After" is the
	time which the public value expires. It is in NTP time format (the
	Integer portion).
	PrimeLen is Length of the DH Prime (p) in bytes. Prime contains the
	binary representation of the DH prime with most significant byte first.
	GenLen is the length of the Generator (g) in bytes. Generator is the
	binary representation of g with most significant byte first.
	PublicValueLen is the Length of the Public Value (g^i mod p) in bytes.
	PublicValue is the binary representation of the DH public value with
	most significant byte first.
	Although, strictly speaking, an unsigned DH public value is not a
	certificate, this value is distributed using the optional certificate
	discovery protocol specified later. Certificate verification in this
	instance means verifying that the message digest of the Unsigned DH
	public value (encoded as specified above) is the same as the (securely
	known) name of the principal. When using this instead of signed
	certificates, certificate verification MUST be performed by performing
	the message digest computation. A message digest type that has been
	assigned a certificate type is the MD5 algorithm.
	IMPORTANT NOTE: The unsigned DH public value can ONLY be used when
	principals are named using the message digest of their DH public value,
	AND these names are securely communicated. Unsigned DH public values
	MUST NOT be used instead of signed DH certificates when principals are
	named using something other than the message digest of their public
	value, since this opens up the possibility of an intruder-in-the-middle
	attack, described in Section 1.8.1 above. In order to use other naming
	schemes, signed certificates such as X.509, Secure DNS, PGP, etc.
	should be used instead.
	4.2 X.509 encoding of DH public values
	The X.509 certificate format is defined by the following ASN.1 syntax:
	Certificate ::= SIGNED SEQUENCE {
	version [0] Version DEFAULT v1988,
	serialNumber CertificateSerialNumber,
	signature AlgorithmIdentifier,
	issuer Name,
	validity Validity,
	subject Name,
	subjectPublicKeyInfo SubjectPublicKeyInfo
	}
	Version ::= INTEGER { v1988(0) }
	CertificateSerialNumber ::= INTEGER
	Validity ::= SEQUENCE {
	notBefore UTCTime,
	notAfter UTCTime
	}
	SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm AlgorithmIdentifier,
	subjectPublicKey BIT STRING
	}
	AlgorithmIdentifier ::= SEQUENCE {
	algorithm OBJECT IDENTIFIER,
	parameters ANY DEFINED BY algorithm OPTIONAL
	}
	The encoding of a Diffie-Hellman public value in an X.509 certificate
	will be in the form of an INTEGER. The algorithm identifier will be as
	defined in PKCS #3 [7]. Thus,
	DHPublicKey ::= INTEGER
	AlgorithmIdentifier ::= SEQUENCE {
	algorithm OBJECT IDENTIFIER
	SEQUENCE {
	prime INTEGER, -- p
	base INTEGER, -- g
	privateValueLength INTEGER OPTIONAL
	}
	}
	with the OBJECT IDENTIFIER value being,
	dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840)
	rsadsi(113549) pkcs(1) 3 1 }
	The DHPublicKey gets encapsulated as the BIT STRING in
	SubjectPublicKeyInfo of an X.509 certificate in the following manner.
	First the DHPublicKey is encoded as an INTEGER, and then this INTEGER is
	encoded as the payload of the BIT STRING.
	The certificate and Certificate Revocation List (CRL) encoding is the
	same as in RFC 1422. CRLs can be used with SKIP in accordance with each
	site's certificate/CRL management policies.
	4.2.1 Encoding of the Distinguished Name (DN)
	When the name space is the IP address space, a certificate is allowed to
	bind multiple IP addresses to a single public value to accommodate cases
	where a single IP node has multiple IP addresses. The SEQUENCE-OF
	construct in a DN readily allows for this. What is needed is an ASN.1
	OBJECT IDENTIFIER for an AttributeType specifying an IP address.
	This is defined here as,
	ipAddress ATTRIBUTE
	WITH ATTRIBUTE-SYNTAX
	PrintableString (SIZE(1 .. ub-ipAddress))
	::= { 1, 3, 6, 1, 4, 1, 42, 2, 11, 2, 1 }
	ub-ipAddress ::= 256
	The DN in the certificate can contain multiple of these by iterating on
	the SEQUENCE-OF construct of the Relative Distinguished Name Sequence.
	The PrintableString contains either the hexadecimal representation or
	standard dot notation representation of an IP address.
	When individual users are identified using DNs, then the certificate
	naturally contains their DNs. Section 1.9 above describes how DNs may be
	used with SKIP, by identifying the DN name space using the Source and
	destination NSID bytes in the SKIP header.
	4.3 Certificate Discovery Protocol
	An optional protocol is described to enable communicating IP-nodes to
	discover each other's certificate(s). This obviates the need for an on-
	line certificate directory server.
	A number of certificate types currently exist, for example, X.509, PGP
	DNS-SIG, Unsigned DH pub value. This protocol allows for all of these
	types. Also note, that a particular principal may have more than one
	certificate. A principal could have the same Diffie-Hellman public
	value in different certificate formats, or have multiple Diffie-Hellman
	public values each in a separate certificate or have the same Diffie-
	Hellman public value certified by different Certifying Authorities, and
	so on. In all these possible certificates the identity of the principal
	remains constant. An algorithm for choosing a particular certificate
	(essentially a Diffie-Hellman public value) when more than one exist is
	described later.
	All certificate discovery protocol communication use the User Datagram
	Protocol (UDP). The initiator binds to port skip-cert-send (6456) and
	sends a certificate request to port skip-cert-recv (6455). The
	responder binds to port skip-cert-recv and sends the response to port
	skip-cert-send. Two separate ports are used to allow for multiple
	certificate requests to be made without waiting for the response to be
	received, (that means, one port is used to simply send requests out and
	the other port is used to receive responses). A simple cache of the
	Master Key-ID and the IP address to which the request was sent is all
	that is required to manage outstanding certificate requests.
	Implementation Note: Considering that a node may be pre-configured to
	allow only encrypted/authenticated communication with any other node, a
	certificate request would be rejected. It is suggested that the two
	ports (skip-cert-send and skip-cert-recv) be treated as a "by-pass"
	channel for encryption/authentication. As only certificates requests are
	satisfied on these ports the window for vulnerability is limited.
	The certificate discovery packet:
	0 1 2 3
	0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| VERS |ACTION | STATUS | MKID NSID |NUMBER-OF-CERTS|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MKID ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CERT-TYPE | NSID | CERT-LENGTH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Certificate ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CERT-TYPE | NSID | CERT-LENGTH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Certificate ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ..... ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| CERT-TYPE | NSID | CERT-LENGTH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Certificate ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	VERS indicates protocol version #. VERS = 1 for this protocol.
	ACTION indicates the type of message. Possible values are:
	1 (Request) - request for remote parties certificate(s).
	2 (Response) - response to a certificate request.
	STATUS is used only in responses (i.e. ACTION = 2). Possible values are:
	0 (OK) - process the certificates sent. NUMBER-OF-CERTS must not
	be zero.
	1 (Unknown Error) - an error has occurred.
	2 (Unknown Master Key-ID) - no certificates for the requested Master
	Key-ID can be found in the local certificate
	database.
	3 (Unsupported NSID) - The NSID in the certificate request is unsupported.
	MKID NSID - identifies the namespace that the Master Key-ID belongs
	to. The values of this field are described in the assigned
	numbers portion of this document.
	NUMBER-OF-CERTS - if 0 then no certificates are present in the message
	and the message is simply a request for all certificates
	for the specified Master Key-ID or a response where the
	STATUS octet indicates an error.
	MKID (Master Key-ID) - this is the identifier as described in the section
	1.9. It's length is dependent on the value of the NSID
	field.
	CERT-TYPE - specifies the certificate type of the certificate that
	is to follow. Some well known types have been assigned
	values below in the Assigned Numbers section 5.4.
	NSID - Identifies the name space of the MKID in the following
	certificate. In a certificate request, the per certificate
	NSID value is used to identify the name spaces for the
	requestor's own certificate(s). In a response to a
	certificate request, this value SHOULD be the same as
	the MKID NSID.
	CERT-LENGTH - specifies the length of the certificate in bytes
	CERTIFICATE - the actual certificate.
	Note that this allows for the initiator to not only request for all
	certificates for a particular Master Key-ID but also send in the same
	message all the certificates of the requestor. As certificates
	either directly contain the Master Key-ID, or this information
	is derivable from the certificate and its NSID, there is no
	need to separately send the Master Key-ID per certificate
	in the certificate request/response messages.
	The Certificate Discovery Protocol allows certificate requests to be
	made to any arbitrary IP-node. This feature allows the initiator to send
	requests to, say, an IP-node which is acting as a certificate server
	(and hence would have many certificates stored in its local certificate
	database). In case requests are being made to a certificate server, and
	the server's authenticated DH public values are known to the requestor
	and vice versa, then this allows the elimination of the bypass channel
	mentioned above. This is because with knowledge of the server's public
	values, the certificate request/response pair can also be encrypted and
	authenticated using SKIP.
	4.4 Algorithm to determine which Diffie-Hellman public value to use
	There may be instances when an IP-node has more than one Diffie-Hellman
	public value, or also support other key agreement algorithms (for
	example, elliptic curves). In these situations the choice of the key
	agreement algorithm and/or the choice of public value to use is
	basically made by determining the fastest and the strongest
	algorithm/value respectively.
	For example, assume an IP-node I supports the Diffie-Hellman Key
	Agreement algorithm and has two certificates issued by the same CA but
	containing different public values. Assume that one certificate
	(cert512) has a 512 bit modulus and the other certificate (cert1024) has
	1024 bit modulus. Now, it wishes to communicate with an IP-node J. IP-
	node J also uses Diffie-Hellman key agreement algorithm and has two
	certificates one of 512 bit modulus and other with 1024 bit modulus. The
	shared secret between the two nodes should be based on the stronger
	value, that means, the Kij is calculated using the public values with
	the 1024 bit modulus.
	5. Assigned Numbers
	5.1 SKIP protocol number		4.1 SKIP protocol number
	SKIP has been assigned the protocol number 57 by IANA. This is what will		SKIP has been assigned the protocol number 57 by the Internet Assigned
	be in the "protocol" field in the IP header, when the SKIP header		Numbers Authority (IANA). This is what will be in the "protocol" field
	follows the IP header.		in the IP header, when the SKIP header follows the IP header.
	5.2 SKIP SPI value		4.2 SKIP SPI value
	For use with the AH & ESP protocols, the value of 1 has been assigned by		For use with the AH & ESP protocols, the value of 1 has been assigned by
	IANA for use with SKIP. Therefore SKIP_SPI as used in earlier sections		IANA for use with SKIP. Therefore SKIP_SPI as used in earlier sections
	should be treated as equal to 1. This will be the value used in the SPI		should be treated as equal to 1. This will be the value used in the SPI
	fields of the AH & ESP protocols.		fields of the AH & ESP protocols.
	5.3 Name Space Identifier (NSID) Assignments		4.3 Name Space Identifier (NSID) Assignments
	Some of the name spaces that may be used with SKIP are assigned		Some of the name spaces that may be used with SKIP are assigned
	identifiers here. Other name space identifiers will be assigned by IANA.		identifiers here. Other name space identifiers will be assigned by IANA.
	NSID Value Name Space Master Key ID length		NSID Value Name Space Master Key ID length
	1 IPv4 Address Space 32-bits		1 IPv4 Address Space 32-bits
	2 POSIX/XOPEN User Ids 32-bits		2 POSIX/XOPEN User Ids 32-bits
	3 IPv6 Address Space 128-bits		3 IPv6 Address Space 128-bits
	4 MD5 of DNS Names 128-bits		4 MD5 of DNS Names 128-bits
	5 MD5 of ISO DN ASN.1 encoding 128-bits		5 MD5 of ISO DN ASN.1 encoding 128-bits
	6 MD5 of U.S. Social Security # 128-bits		6 MD5 of Arbitrary ASCII string 128-bits
	7 802.x MAC Address 48-bits		7 802.x MAC Address 48-bits
	8 MD5 of Principal's DH Pub Val 128-bits		8 MD5 of Principal's DH Pub Val 128-bits
	9 MD5 of RFC-822 Mailbox Address 128-bits		9 MD5 of RFC-822 Mailbox Address 128-bits
	10 MD5 of Bank Account # 128-bits		10 MD5 of Bank Account # 128-bits
	11 MD5 of NIS Name 128-bits		11 MD5 of NIS Name 128-bits
	IANA will assign NSIDs in the range 20-250. The range 250-255 will		NSID values 1 through 11 are assigned as is described above. NSID
	remain reserved for private use to implement proprietary naming schemes,		values 12 through 259 inclusive are reserved to IANA for future
	and will not be assigned by IANA. NSIDs in the range 250-255 will only		allocation as Assigned Numbers. Such future allocation by IANA will
	have local uniqueness properties.		normally require that a public specification exist for the Name Space
			obtaining such allocation. NSIDs in the range 250 through 255 inclusive
			are reserved for private use among consenting parties. NSIDs in the
			range 250 through 255 inclusive will hence only have local uniqueness
			properties.
	5.4 Assigned Algorithm/Certificate Type Numbers		4.4 Assigned Algorithm Numbers
	SKIP uses the following algorithms identifiers. Algorithm and type		SKIP uses the following algorithms identifiers. Algorithm and type
	identifiers are specified for each place in the protocol where algorithm		identifiers are specified for each place in the protocol where algorithm
	or type indicators are needed.		or type indicators are needed.
	These fall into five categories. Algorithms for key-encryption (Kij		These fall into four categories. Algorithms for key-encryption (Kij
	Alg), traffic encryption (Crypt Alg), traffic authentication (MAC Alg),		Alg), traffic encryption (Crypt Alg), traffic authentication (MAC Alg),
	traffic compression (Comp. Alg) and certificate types (CERT-TYPE) used		and traffic compression (Comp. Alg).
	by the certificate discovery protocol.
	Key-Encryption Algorithms (Kij Alg)		Key-Encryption Algorithms (Kij Alg)
	1 DES-CBC (IV = 0, random fill up to multiple of 64-bits)		1 DES-CBC (IV = 0, random fill up to multiple of 64-bits)
	2 3 key Triple DES-EDE-CBC (IV = 0, random fill upto multiple of 64-bits)		2 3 key Triple DES-EDE-CBC (IV = 0, random fill upto multiple of 64-bits)
	3 IDEA-CBC (IV = 0, random fill up to multiple of 64-bits)		3 IDEA-CBC (IV = 0, random fill up to multiple of 64-bits)
	Traffic Encryption Algorithms (Crypt Alg)		Traffic Encryption Algorithms (Crypt Alg)
	1 DES-CBC (specified in RFC 1829)		1 DES-CBC (specified in RFC 1829)
	skipping to change at page 46, line 26 ¶		skipping to change at page 26, line 27 ¶
	MAC Algorithms (MAC Alg)		MAC Algorithms (MAC Alg)
	1 128-bit Keyed MD5 (RFC 1828)		1 128-bit Keyed MD5 (RFC 1828)
	2 DES-CBC MAC		2 DES-CBC MAC
	3 Keyed SHA (RFC 1852)		3 Keyed SHA (RFC 1852)
	Compression Algorithms (Comp Alg)		Compression Algorithms (Comp Alg)
	Reserved to IANA		Reserved to IANA
	Certificate Type (CERT-TYPE)		IANA will assign the range 10-250 for the algorithm identifiers above.
			The range 250-255 will remain reserved for use with proprietary
	1 X.509		algorithms and will not be assigned by IANA. These values will only have
	2 PGP		local uniqueness properties.
	3 Secure DNS
	4 Unsigned DH Public Value (*)
	(*) Unsigned DH Public Value encoding as specified in Section 4.1
	IANA will assign the range 10-250 for the algorithm and certificate type
	identifiers above. The range 250-255 will remain reserved for use with
	proprietary algorithms and will not be assigned by IANA. These values
	will only have local uniqueness properties.
	For interoperability purposes, RFCs 1828 and 1829 have been deemed as		For interoperability purposes, RFCs 1828 and 1829 have been deemed as
	mandatory to implement.		mandatory to implement.
	When implementing different key-encryption, traffic encryption, and		5. Recommended Parameters and Implementation Notes
	key-agreement algorithms, a consistent set of key strengths MUST be
	chosen. This means that if a traffic key is, say 128 bits strength, then
	the key encryption key MUST be of strength 128-bits or greater. It isn't
	sensible to choose strong traffic protection algorithms and then encrypt
	the keys using weaker algorithms. Similarly, when using 128-bit
	symmetric keys, the modulus lengths for classic Diffie-Hellman (used to
	derive the master keys) MUST be 1024 bits or greater. The exponent size
	for classic Diffie-Hellman for symmetric master key sizes of 128 bits
	MUST be 256 bits or greater.
	Also, when 128-bit keyed MD5 is used, then the key-encryption algorithms
	MUST have strength equal to or greater than 128-bits. For
	interoperability purposes, use of Algorithm #2 (3 key triple DES-EDE-
	CBC) is deemed mandatory to implement for key encryption (Kij Alg), when
	also implementing keyed MD5 as specified in RFC 1829 for traffic
	authentication purposes, or any 128-bit strength traffic encryption
	algorithm (e.g. 2 or 3 key triple DES or IDEA).
	5.5 SKIP ICMP message (SKIP_ICMP)
	The SKIP algorithm discovery ICMP message has been assigned the type 39
	(SKIP_ICMP) by IANA.
	5.6 SKIP Certificate Discovery Protocol
	The SKIP Certificate Discovery Protocol uses two UDP ports to exchange
	certificates. "skip_cert_send" and "skip_cert_recv" have been assigned
	the values 6456, 6455 respectively by IANA.
	5.7 SKIP Multicast GIK request port
	The SKIP multicast security protocol uses this port for sending the
	request for the multicast GIK. This has been assigned the the value 1660
	(skip-mc-gikreq) by IANA.
	6. Recommended Parameters and Implementation Notes
	6.1 Generating Random Keys
	One of the most important considerations in a software only
	implementation of SKIP is to design an unpredictable pseudo-random
	number generation procedure. Weak and unpredictable sources of random
	number generation would be catastrophic to the security of SKIP or
	indeed any scheme that implements cryptography, no matter what the
	length of key and choice of encryption algorithm might be.
	In particular, common mistakes that MUST be avoided in implementing this
	unpredictable random number generator is to use values like the current
	process id, the host id or ethernet address, the current time of day or
	some simple combination of these as the sole input to generate a
	cryptographic key. These values are really not all that unpredictable.
	It must be ensured that there are at least as many truly random bits
	used in the key production phase as are specified in the chosen key
	length for that algorithm. None of these commonly used sources by
	themselves provide sufficiently many random bits for commonly used
	cryptographic algorithms.
	For more information on the subject of generating random keys, RFC 1750
	[12] is recommended reading.
	6.2 Key Update
	The best way to frustrate cryptanalysis of encryption and authentication
	keys is to periodically update the key used to encrypt or authenticate
	packets. Whereas the exact frequency with which keys are updated SHOULD
	be configurable based on site policies, some recommended parameters are
	provided.
	The traffic encryption/authentication key SHOULD be updated for every 10
	Mbytes of protected traffic, or once every 2 minutes, which ever one
	results in a more frequent update policy.
	The traffic encryption/authentication key (derived using Kp) MUST be
	updated every time a Kijn is updated. In addition, in case multiple
	Kijn's exist on a given node, then Kp MUST NOT be shared among different
	Kijns. Kp MUST be randomly generated for each end destination, and for
	different principals on the same node.
	6.3 n Update Frequency		5.1 n Update Frequency
	Updating the counter "n" updates the master key. For interoperability,		Updating the counter "n" updates the master key. For interoperability,
	a standard start time and n update frequency are specified here. As		a standard start time and n update frequency are specified here. As
	noted above, this prevents reuse of compromised packet authentication		noted above, this prevents reuse of compromised packet authentication
	keys.		keys.
	The start time for computing "n" is 0h Jan 1, 1995. The time units of n		The start time for computing "n" is Jan 1, 1995 00:00:00 UTC. The time
	are hours since this start time. Therefore the "n" counter is		units of n are hours since this start time. Therefore the "n" counter is
	incremented once every hour.		incremented once every hour.
	Symbolically, n is computed locally as		Symbolically, n is computed locally as
	local n = (current time) - (start time) normalized to hours		local n = (current time) - (start time) normalized to hours
	A sending node uses the above method to compute (and update) n, and		A sending node uses the above method to compute (and update) n, and
	using this value of n it computes the Kijn value, as specified in		using this value of n it computes the Kijn value, as specified in
	Section 1.3 above. A receiving node will independently compute n, and		section 1.2 above. A receiving node will independently compute n, and
	check this against the value of n in the received SKIP header. If they		check this against the value of n in the received SKIP header. If they
	do not differ by more than 1, the packet is accepted. If they differ by		do not differ by more than 1, the packet is accepted. If they differ by
	more than 1, the packet MUST be rejected, as this may be an attempt to		more than 1, the packet MUST be rejected, as this may be an attempt to
	reuse a past compromised authentication key.		reuse a past compromised authentication key.
	Since n is a 32 bit quantity, there is no practical danger of overflow		Since n is a 32 bit quantity, there is no practical danger of overflow
	of n, and hence there is no need to ever reset n. n is a monotonically		of n, and hence there is no need to ever reset n. n is a monotonically
	increasing number, even across certificate updates.		increasing number, even across certificate updates.
	Note that this doesn't require the use of fine-grain synchronized clocks		Note that this doesn't require the use of fine-grain synchronized clocks
	or a secure clock synchronization protocol. Nodes should by default have		or a secure clock synchronization protocol. Nodes should by default have
	clocks synchronized within an hour of each other. If they are not		clocks synchronized within an hour of each other. If they are not
	synchronized even in this coarse-grain manner, then validating		synchronized even in this coarse-grain manner, then validating
	certificates and CRLs becomes problematic.		certificates and CRLs becomes problematic.
	Should future implementations of SKIP ever decide to use a different		5.2 SKIP with the Certificate Discovery Protocol
	update frequency for n, say once every 10 minutes, then this can be
	communicated in a pairwise basis using the algorithm discovery ICMP
	message specified above. All this requires for interoperability is that
	SKIP implementations that use different n update frequency values also
	support the use of the ICMP algorithm discovery message, to indicate the
	use of their preferred n update frequency.
	In case a principal should choose to change its n update frequency, then		The Certificate Discovery Protocol [19] may be used to exchange SKIP
	the update rate can only be increased, and NEVER decreased. Decreasing		certificates. The Name field in the Name Record of Certificate
	the n update rate would cause the n counter to move backwards which MUST		Discovery Protocol is the concatenation of the NSID and MKID values,
	be avoided. For example, if a principal updates n every hour, it can at		respectively. For example, for NSID=01, MKID=7f000001, the name would
	some future time update n every half-hour (since this is a faster update		be 017f000001.
	rate) but it cannot choose to update n every 2 hours, since this will
	cause n to move back, if n is computed using the (current time - start
	time) normalized to update rate units expression.
	6.4 Recommended g & p values		5.3 Recommended g & p values
	For interoperability, the values g and p in g^i mod p are specified		For interoperability, the values g and p in g^i mod p are specified
	here, for various modulus lengths.		here, for various modulus lengths.
	6.4.1 Prime generation method		5.3.1 Prime generation method
	The primes given below were generated using the following algorithm.		The primes given below were generated using the following algorithm.
	The prime generation method is given so it is possible to independently		The prime generation method is given so it is possible to independently
	verify how the primes were generated.		verify how the primes were generated.
	The prime generator is based on SHA.1, the FIPS 180.1 secure hash		The prime generator is based on SHA.1, the FIPS 180.1 secure hash
	algorithm. This takes the given seed as input and produces a 160-bit		algorithm. This takes the given seed as input and produces a 160-bit
	output sequence in 20 bytes. These bytes are taken as a big-endian		output sequence in 20 bytes. These bytes are taken as a big-endian
	number to produce a number n0 from 0 to 2^160-1.		number to produce a number n0 from 0 to 2^160-1.
	skipping to change at page 51, line 8 ¶		skipping to change at page 28, line 43 ¶
	problem for, this ensures that the chance of choosing a prime p which is		problem for, this ensures that the chance of choosing a prime p which is
	a member of that class is no better than random chance, regardless of		a member of that class is no better than random chance, regardless of
	malice on the part of the party generating the prime.		malice on the part of the party generating the prime.
	The seed chosen is arbitrary, so was chosen for aesthetic reasons. It		The seed chosen is arbitrary, so was chosen for aesthetic reasons. It
	is the 79 bytes of the ASCII representation of a quote by Gandhi:		is the 79 bytes of the ASCII representation of a quote by Gandhi:
	"Whatever you do will be insignificant, but it is very important that		"Whatever you do will be insignificant, but it is very important that
	you do it."		you do it."
	6.4.2 Diffie-Hellman Parameters for 1024 bits Modulus		5.3.2 Diffie-Hellman Parameters for 1024 bits Modulus
	Base (g):		Base (g):
	0x02		0x02
	Modulus (p) (MSB first):		Modulus (p) (MSB first):
	0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD,		0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD,
	0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B,		0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B,
	0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C,		0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C,
	0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6,		0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6,
	0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B,		0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B,
	0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D,		0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D,
	skipping to change at page 51, line 31 ¶		skipping to change at page 29, line 25 ¶
	0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,		0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,
	0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,		0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,
	0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,		0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,
	0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,		0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,
	0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,		0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,
	0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,		0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,
	0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,		0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,
	0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,		0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,
	0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x2F, 0x78, 0xC7		0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x2F, 0x78, 0xC7
	6.4.3 Diffie-Hellman Parameters for 2048 bits Modulus:		5.3.3 Diffie-Hellman Parameters for 2048 bits Modulus:
	Base (g):		Base (g):
	0x02		0x02
	Modulus (p) (MSB first):		Modulus (p) (MSB first):
	0xF6, 0x42, 0x57, 0xB7, 0x08, 0x7F, 0x08, 0x17,		0xF6, 0x42, 0x57, 0xB7, 0x08, 0x7F, 0x08, 0x17,
	0x72, 0xA2, 0xBA, 0xD6, 0xA9, 0x42, 0xF3, 0x05,		0x72, 0xA2, 0xBA, 0xD6, 0xA9, 0x42, 0xF3, 0x05,
	0xE8, 0xF9, 0x53, 0x11, 0x39, 0x4F, 0xB6, 0xF1,		0xE8, 0xF9, 0x53, 0x11, 0x39, 0x4F, 0xB6, 0xF1,
	0x6E, 0xB9, 0x4B, 0x38, 0x20, 0xDA, 0x01, 0xA7,		0x6E, 0xB9, 0x4B, 0x38, 0x20, 0xDA, 0x01, 0xA7,
	0x56, 0xA3, 0x14, 0xE9, 0x8F, 0x40, 0x55, 0xF3,		0x56, 0xA3, 0x14, 0xE9, 0x8F, 0x40, 0x55, 0xF3,
	skipping to change at page 52, line 42 ¶		skipping to change at page 30, line 42 ¶
	0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,		0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,
	0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,		0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,
	0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,		0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,
	0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,		0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,
	0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,		0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,
	0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,		0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,
	0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,		0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,
	0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,		0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,
	0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x32, 0x0B, 0x3B		0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x32, 0x0B, 0x3B
	7. Conclusions		6. Conclusions
	We have described a scheme, Simple Key-Management for Internet Protocols		We have described a scheme, Simple Key-Management for Internet Protocols
	(SKIP) that is particularly well suited for use with connectionless		(SKIP) that is particularly well suited for use with connectionless
	datagram protocols like IP and its replacement candidate IPv6. Both the		datagram protocols like IP and its replacement candidate IPv6. Both the
	protocol and computational overheads of this scheme are relatively low.		protocol and computational overheads of this scheme are relatively low.
	In-band signaled keys incur only the length overhead of the block size		In-band signaled keys incur only the length overhead of the block size
	of a shared-key cipher. Also, establishing and changing packet		of a shared-key cipher. Also, establishing and changing packet
	encrypting keys involves only a shared-key cipher operation. Yet the		encrypting keys involves only a shared-key cipher operation. Yet the
	scheme has the scalability and robustness of an authenticated public-key		scheme has the scalability and robustness of an authenticated public-key
	based infrastructure.		based infrastructure. In addition, there are no complicated crash
			recovery considerations for intermediate or end nodes.
	A major advantage of this scheme is that establishing and changing
	packet encrypting keys requires no prior communication between sending
	and receiving nodes. In addition, no establishment of a pseudo-session
	state between the two sides is required. This design permits
	straightforward configurations that allow highly available and load-
	balanced, protected IP communications. In addition, there are no
	complicated crash recovery considerations for intermediate or end nodes.
	High availability of network services, load balancing to better utilize
	the network's capacity and simple crash recovery considerations on
	intermediate/end nodes are among some of the properties that have made
	IP successful as an internet protocol. SKIP preserves all these
	properties of IP.
	We have also described how this scheme may be used in conjunction with
	datagram multicast protocols, both for transient and permanent multicast
	groups. The SKIP multicast key-management scheme allows extreme
	flexibility in terms of updating multicast traffic
	encryption/authentication keys even for very large multicast groups. It
	also allows all possible traffic encryption algorithms for multicast
	data, including all stream ciphers.
	Acknowledgements		Acknowledgements
	I would like to thank all of the people who helped make this draft		I would like to thank all of the people who helped make this draft
	possible. (Any errors and shortcomings are only attributable to the		possible. (Any errors and shortcomings are only attributable to the
	author.)		author.)
	Whitfield Diffie for many helpful discussions on this subject. Geoff		Whitfield Diffie for many helpful discussions on this subject. Geoff
	Mulligan and Bill Danielson for reviewing this draft and providing		Mulligan and Bill Danielson for reviewing this draft and providing
	constructive suggestions. Martin Patterson for reviewing this draft, and		constructive suggestions. Martin Patterson for reviewing this draft, and
	providing feedback and input based on extensive implementation and		providing feedback and input based on extensive implementation and
	testing.		testing.
	Marc Dye for suggesting using name spaces other than IP addresses with		Marc Dye for suggesting using name spaces other than IP addresses with
	SKIP, and for the notion of a name space identifier.		SKIP, and for the notion of a name space identifier.
	Tom Markson and Hemma Prafullchandra contributed substantial pieces of
	this draft, and provided entensive critique and feedback of this, in
	addition to doing sanity checks of the draft by implementing major
	pieces of it.
	Bob Hinden provided valuable suggestions, and created the first skeleton		Bob Hinden provided valuable suggestions, and created the first skeleton
	SKIP document in the format of an Internet-Draft.		SKIP document in the format of an Internet-Draft.
	Hilarie Orman suggested the encapsulation scheme which is reflected in		Hilarie Orman suggested the encapsulation scheme which is reflected in
	this draft and provided other valuable input. Cheryl Madson suggested		this draft and provided other valuable input. Cheryl Madson suggested
	using SKIP to encapsulate protocols such as OSPF and RIP and other		using SKIP to encapsulate protocols such as OSPF and RIP and other
	protocols that may need keying material well as other valuable input and		protocols that may need keying material well as other valuable input and
	critique.		critique.
			Ran Atkinson provided detailed critique and feedback, and helped greatly
			in making this document consistent with the IP security encapsulation
			and security architecture documents.
	Jeff Schiller suggested improvements to the draft in order to facilitate		Jeff Schiller suggested improvements to the draft in order to facilitate
	building interoperable implementations, and his comments on ipsec		building interoperable implementations.
	motivated the scheme to use the message digest of a public key as a
	principal's name.
	Two separate groups independently "cleanroom" implemented SKIP based on		Two separate groups independently "cleanroom" implemented SKIP based on
	early drafts and provided invaluable feedback: Michael Hauber and		early drafts and provided invaluable feedback: Michael Hauber and
	Christian Schneider in Switzerland and Kanat Alimjanov, Alex Vopilov,		Christian Schneider in Switzerland and Kanat Alimjanov, Alex Vopilov,
	Nick Tzarev and Roman Sagalev in Russia deserve special credit for their		Nick Tzarev and Roman Sagalev in Russia deserve special credit for their
	efforts.		efforts.
	Germano Caronni suggested many useful SKIP protocol enhancements, and		Germano Caronni suggested many useful SKIP protocol enhancements, and
	also led the independent implementation of SKIP in Switzerland.		also led the independent implementation of SKIP in Switzerland.
	Phillip Zimmermann and Colin Plumb provided valuable information on		Phillip Zimmermann and Colin Plumb provided valuable information on
	integrating a web-of-trust certification model, as exemplified in the		integrating a web-of-trust certification model, as exemplified in the
	PGP secure mail package, with SKIP style certificates.		PGP secure mail package, with SKIP style certificates.
	Colin Plumb provided the prime generation software and algorithm		Colin Plumb provided the prime generation software and algorithm
	description given in the recommended primes section. The choice of the		description given in the recommended primes section. The choice of the
	quote used to seed the primes is due to Phillip Zimmermann and Colin		quote used to seed the primes is due to Phillip Zimmermann and Colin
	Plumb.		Plumb.
			Joseph Reveane, Rich Skrenta and Ben Stoltz reviewed this draft and
			provided constructive suggestions.
	In addition the protocol has benefited greatly from discussions on the		In addition the protocol has benefited greatly from discussions on the
	ipsec mailing list. Many valuable improvements to the draft have come as		ipsec mailing list. Many valuable improvements to the draft have come as
	a result of this. Noteworthy contributions have come from the following		a result of this. Noteworthy contributions have come from the following
	individuals: Amir Herzberg, Hugo Krawcyk, Steve Bellovin, Dragan		individuals: Amir Herzberg, Hugo Krawcyk, Steve Bellovin, Dragan
	Grebovich, Charles Lynn, Russ Housely.		Grebovich, Charles Lynn, Russ Housely.
	References		References
	[1] RFCs 1421-1424, Privacy Enhanced Mail		[1] RFCs 1421-1424, Privacy Enhanced Mail
	[2] A Aziz, W Diffie, "Privacy and Authentication for Wireless LANs",		[2] A Aziz, W Diffie, "Privacy and Authentication for Wireless LANs",
	IEEE Personal Communications, Feb 1994.		IEEE Personal Communications, Feb 1994.
	[3] W. Diffie, M. Wiener, P. Oorschot, "Authentication and Authenticated		[3] W. Diffie, M. Wiener, P. Van Oorschot, "Authentication and
	Key Exchanges.", in Designs Codes and Cryptography, Kluwer Academic		Authenticated Key Exchanges.", in Designs Codes and Cryptography,
	Publishers, 1991.		Kluwer Academic Publishers, 1991.
	[4] W. Diffie, M. Hellman, "New Directions in Cryptography", IEEE		[4] Diffie, W., Hellman, M., "New Directions in Cryptography", IEEE
	Transactions on Information Theory, Vol IT-22, Nov 1976, pp. 644-654		Transactions on Information Theory, Vol IT-22, Nov 1976, pp. 644-654
	[5] S. E. Deering, "Host extensions for IP multicasting", RFC 1112		[5] Deering, S. E., "Host extensions for IP multicasting", RFC 1112
	[6] S. Kent, "Certificate Based Key Management", RFC 1422		[6] Kent, S., "Certificate Based Key Management", RFC 1422
	[7] "Public Key Cryptography Standards", PKCS#s 1-10 from RSA Data		[7] "Public Key Cryptography Standards", PKCS#s 1-10 from RSA Data
	Security Inc., Redwood City, CA, ftp://ftp.rsa.com/pub/pkcs		Security Inc., Redwood City, CA, ftp://ftp.rsa.com/pub/pkcs
	[8] Atkinson, R., "Security Architecture for the Internet Protocol", RFC		[8] Atkinson, R., "Security Architecture for the Internet Protocol", RFC
	1825, August 1995		1825, August 1995
	[9] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995		[9] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995
	[10] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995		[10] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August 1995
	[11] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D		[11] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D
	draft-ietf-dnssec-secext-04.txt), Work In Progress		draft-ietf-dnssec-secext-04.txt), Work In Progress
	[12] D. Eastlake, S. Crocker, J. Schiller, "Randomness Recommendations		[12] D. Eastlake, S. Crocker, J. Schiller, "Randomness Recommendations
	for Security", RFC 1750, December 1994		for Security", RFC 1750, December 1994
	[13] R. Rivest, "The MD5 Message Digest Algorithm", RFC 1321, April 1992		[13] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
			1992
	[14] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC		[14] P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", RFC
	1828, August 1995		1828, August 1995
	[15] P. Karn, P. Metzger, W. Simpson, "The ESP DES-CBC Transform", RFC		[15] P. Karn, P. Metzger, W. Simpson, "The ESP DES-CBC Transform", RFC
	1829, August 1995		1829, August 1995
	[16] J. Moy, "OSPF Version 2", RFC 1583, March 1994		[16] J. Moy, "OSPF Version 2", RFC 1583, March 1994
	[17] A. Menezes, "Elliptic Curve Public Key Cryptosystems", Kluwer		[17] A. Menezes, "Elliptic Curve Public Key Cryptosystems", Kluwer
	Academic Publishers, 1993		Academic Publishers, 1993
	[18] R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, October,		[18] R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, October,
	1993		1993
	Author Information:		[19] Aziz, A., Markson, T., Prafullchandra, H., "Certificate Discovery
	Ashar Aziz		Protocol", (I-D draft-ietf-ipsec-cdp-00.txt), Work in Progress
	Distinguished Engineer
	Sun Microsystems, Inc.
	M/S PAL1-550
	2550 Garcia Ave.,
	Mountain View, CA 94043
	e-mail: ashar.aziz@Eng.Sun.COM
	alternate e-mail address: ashar@incog.com
	CONTENTS
	Status of this Memo................................. 1
	Abstract............................................ 2
	1. Overview............................................ 3
	1.1 Simple Key-Management for Internet
	Protocols..................................... 5
	1.2 Manual distribution of Kij.................... 8
	1.3 Zero-Message Master Key Update Algorithm...... 8
	1.4 Independence from Cryptographic
	Algorithms.................................... 9
	1.5 Storage of Cryptographic Keys................. 10
	1.6 High Availability and Load Balancing using
	SKIP.......................................... 10
	1.7 Intermediate Authentication with End-to-End
	security using SKIP........................... 11
	1.8 Attacks that the protocol guards against...... 12
	1.8.1 Intruder in the Middle Attacks 12
	1.8.2 Known Key Attacks 12
	1.8.3 Anti-Clogging Defense 13
	1.8.4 Non-Goal: Perfect Forward Secrecy 13
	1.9 Naming, Name Spaces and Master Key-IDs........ 14
	1.10 The SKIP Header............................... 16
	1.11 The relative order of compression, encryption
	and authentication............................ 19
	- i -
	1.12 Deriving Keys for Packet Encryption and
	Authentication................................ 19
	1.13 SKIP for Authentication....................... 21
	1.13.1 SKIP with AH 22
	1.13.2 Scope of MAC computation 23
	1.14 SKIP for Encryption........................... 23
	1.14.1 SKIP with ESP 23
	1.15 SKIP for Authentication and Encryption........ 24
	1.15.1 SKIP with AH and ESP 25
	1.15.2 SKIP with combined ESP transforms 26
	1.16 Generic use of SKIP header.................... 27
	2. SKIP for Multicast IP............................... 27
	2.1 Transient Multicast Groups.................... 27
	2.2 Broadcast/Permanent Multicast Groups.......... 32
	2.2.1 SKIP and RIPv2 32
	2.3 Multicast/Broadcast Authentication............ 33
	3. Algorithm Discovery................................. 34
	4. Distribution of authenticated public values......... 37
	4.1 Encoding of an Unsigned DH public value....... 37
	4.2 X.509 encoding of DH public values............ 38
	4.2.1 Encoding of the Distinguished Name
	(DN) 40
	4.3 Certificate Discovery Protocol................ 41
	- ii -
	4.4 Algorithm to determine which Diffie-Hellman
	public value to use........................... 44
	5. Assigned Numbers.................................... 44
	5.1 SKIP protocol number.......................... 44
	5.2 SKIP SPI value................................ 45
	5.3 Name Space Identifier (NSID) Assignments...... 45
	5.4 Assigned Algorithm/Certificate Type
	Numbers....................................... 45
	5.5 SKIP ICMP message (SKIP_ICMP)................. 47
	5.6 SKIP Certificate Discovery Protocol........... 47
	5.7 SKIP Multicast GIK request port............... 47
	6. Recommended Parameters and Implementation Notes..... 47		[20] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned
			Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh-
			00.txt), Work in Progress
	6.1 Generating Random Keys........................ 47		[21] Aziz, A., Markson, T., Prafullchandra, H., "SKIP Algorithm
			Discovery Protocol", (I-D draft-ietf-ipsec-skip-adp-00.txt), Work in
			Progress
	6.2 Key Update.................................... 48		[22] Aziz, A., Markson, T., Prafullchandra, H., "SKIP Extensions for IP
			Multicast", (I-D draft-ietf-ipsec-skip-mc-00.txt), Work in Progress
	6.3 n Update Frequency............................ 48		[23] Aziz, A., Markson, T., Prafullchandra, H., "X.509 Encoding of
			Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-x509-
			00.txt), Work in Progress
	6.4 Recommended g & p values...................... 49		[24] Atkins, D., Stallings, W., Zimmerman, P., "PGP Message Exchange
			Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress
	6.4.1 Prime generation method 50		Author's Address(es)
	6.4.2 Diffie-Hellman Parameters for 1024		Ashar Aziz
	bits Modulus 51		Sun Microsystems, Inc.
			M/S PAL1-550
			2550 Garcia Avenue
			Mountain View, CA 94043
	6.4.3 Diffie-Hellman Parameters for 2048		Email: ashar.aziz@eng.sun.com
	bits Modulus: 51		Alternate email address: ashar@incog.com
	7. Conclusions......................................... 52		Tom Markson
			Sun Microsystems, Inc.
			M/S PAL1-550
			2550 Garcia Avenue
			Mountain View, CA 94043
	Acknowledgements.................................... 53		Email: markson@incog.com
			Alternate email address: markson@eng.sun.com
	References.......................................... 55		Hemma Prafullchandra
			Sun Microsystems, Inc.
			M/S PAL1-550
			2550 Garcia Avenue
			Mountain View, CA 94043
	- iii -		Email: hemma@eng.sun.com
			Alternate email address: hemma@incog.com
End of changes. 117 change blocks.
	1352 lines changed or deleted		434 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/