< draft-moskowitz-sspp-snmp-00.txt		draft-moskowitz-sspp-snmp-01.txt >
	Internet Draft R. Moskowitz		Internet Draft R. Moskowitz
	Document: draft-moskowitz-sspp-snmp-00.txt ICSAlabs		Document: draft-moskowitz-sspp-snmp-01.txt ICSAlabs
	Expires: July 2003 January 2003		Expires: May 2004 November 2003
	SSPP over SNMP		SSPP over SNMP
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [1].		all provisions of Section 10 of RFC2026 [1].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	Conventions used in this document		Conventions used in this document
	In examples, "C:" and "S:" indicate activities by the SSPP client		In examples, "C:" and "S:" indicate activities by the SSPP client
	and SSPP server respectively. "P:" indicate activities by the SSPP		and SSPP server respectively. "P:" indicate activities by the SSPP
	proxy.		proxy.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC-2119 [3].		this document are to be interpreted as described in RFC-2119 [3].
	SSPP over SNMP January 2003		SSPP over SNMP November 2003
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	1.1 Reasoning for using SNMP as an SSPP transport..............2		1.1 Reasoning for using SNMP as an SSPP transport..............2
	1.2 Terms and Protocol components..............................3		1.2 Terms and Protocol components..............................3
	1.3 Variables used.............................................4		1.3 Variables used.............................................4
	1.4 The MIB objects............................................4		1.4 The MIB objects............................................4
	2. The basic SNMP exchange........................................5		2. The basic SNMP exchange........................................5
	2.1 Validating the Diffie-Hellman Public Keys..................6		2.1 Timing to generate Shared Secret...........................6
			2.2 Validating the Diffie-Hellman Public Keys..................6
	3. Additional exchanges...........................................6		3. Additional exchanges...........................................6
	3.1 Changing a shared secret...................................6		3.1 Changing a shared secret...................................7
	3.2 Proxying SSPP through an established Client................7		3.2 Proxying SSPP through an established Client................7
	4. Application of SSPP over SNMP..................................8		4. Application of SSPP over SNMP..................................9
	4.1 EXAMPLE: RADIUS Client Secret..............................9		4.1 EXAMPLE: RADIUS Client Secret..............................9
	Security Considerations...........................................9		Security Considerations...........................................9
	References.......................................................10		References.......................................................10
	Acknowledgments..................................................10		Acknowledgments..................................................10
	Author's Addresses...............................................10		Author's Addresses...............................................11
	1. Introduction		1. Introduction
	The Shared Secret Provisioning Protocol (SSPP) provides the		The Shared Secret Provisioning Protocol (SSPP) provides the
	cryptographic functions and basic protocol for provisioning strong,		cryptographic functions and basic protocol for provisioning strong,
	shared secrets. For SSPP to be deployed, it needs a transport-layer		shared secrets. For SSPP to be deployed, it needs a transport-layer
	protocol. This document describes the use of SNMP for transporting		protocol. This document describes the use of SNMP for transporting
	SSPP.		SSPP. In this usage, SSPP is an application on top of SNMP.
	SSPP is presented in three forms. The principle form is the basic		SSPP is presented in three forms. The principal form is the basic
	exchange. An important adjunct form is the modified exchange for		exchange. An important adjunct form is the modified exchange for
	changing the shared secret where there already is a relationship		changing the shared secret where there already is a relationship
	between the client and server. Finally there is the proxy exchange		between the client and server. Finally there is the proxy exchange
	where the server's policy restricts it to only one client using the		where the server's policy restricts it to only one client using the
	basic exchange, but that client can act as a proxy to other clients.		basic exchange, but that client can act as a proxy to other clients.
	At this state in its development, SSPP over SNMP is very general.		At this state in its development, SSPP over SNMP is very general.
	It will evolve through reviews and its application in provisioning		It will evolve through reviews and its application in provisioning
	existing shared secrets like the shared secret between a RADIUS		existing shared secrets like the shared secret between a RADIUS
	Client and Server.		Client and Server.
	1.1 Reasoning for using SNMP as an SSPP transport		1.1 Reasoning for using SNMP as an SSPP transport
	There are many shared secrets that protect machine-to-machine or		There are many shared secrets that protect machine-to-machine or
	process-to-process datagrams. SNMP is a common protocol on the		process-to-process datagrams. SNMP is a common protocol on the
	systems that have these shared secrets, making it an attractive		systems that have these shared secrets, making it an attractive
	transport for SSPP. SNMP is attractive for transporting SSPP for		transport for SSPP. SNMP is attractive for transporting SSPP for
	the following additional reasons:		the following additional reasons:
	SSPP over SNMP January 2003		SSPP over SNMP November 2003
	Shared secrets are typically the first item to be configured in a		Shared secrets are typically the first item to be configured in a
	new deployment and at the 'out of the box' state, SNMP is ready to		new deployment and at the 'out of the box' state, SNMP is ready to
	use in most systems.		configure and use in most systems.
	The SSPP client needs to discover the SSPP server after the later		The SSPP client needs to discover the SSPP server after the later is
	is deployed. SNMP has a well-developed system discovery		deployed. SNMP has a well-developed system discovery methodology.
	methodology.
	SNMP is a very lightweight protocol to use in small headless		SNMP is a very lightweight protocol to use in small headless
	devices.		devices.
	1.2 Terms and Protocol components		1.2 Terms and Protocol components
	SSPP is a Client/Server protocol that can use a specialized proxy.		SSPP is a Client/Server protocol that can use a specialized proxy.
	In this standard, all references to Client, Server are SSPP		In this standard, all references to Client, Server are SSPP clients
	clients and servers unless specifically named (e.g. RADIUS		and servers unless specifically named (e.g. RADIUS Server). All
	Server). All references to a proxy are for an SSPP proxy. SNMP		references to a proxy are for an SSPP proxy. SNMP components are
	components are Agents and Managers as follows:		Agents and Managers as follows:
	SSPP SNMP		SSPP SNMP
	Client Manager		Client Manager
	Server Agent		Server Agent
	Proxy Agent to the SSPP client		Proxy Agent to the SSPP client
	Manager to the SSPP server		Manager to the SSPP server
	+-------------+ +-------------+		+-------------+ +-------------+
	| SSPP Client | | SSPP Server |		| SSPP Client | | SSPP Server |
	| | SSPP | |		| | SSPP | |
	| |<-------------------------->| |		| |<-------------------------->| |
	| SNMP Manager| SNMP | SNMP Agent |		| SNMP Manager| SNMP | SNMP Agent |
	| | | |		| | | |
	+-------------+ +-------------+		+-------------+ +-------------+
	Figure 1. Basic system flow		Figure 1. Basic system flow
	+-------------+ +-------------+ +-------------+		+-------------+ +-------------+ +-------------+
	| SSPP Client | | SSPP Proxy | | SSPP Server |		| SSPP Client | | SSPP Proxy | | SSPP Server |
	| | SSPP | | SSPP | |		| | SSPP | | SSPP | |
	| |<-------->| |<-------->| |		| |<-------->| |<-------->| |
	| SNMP Manager| SNMP | SNMP Agent/ | SNMP | SNMP Agent |		| SNMP Manager| SNMP | SNMP Agent/ | SNMP | SNMP Agent |
	| |<-+ | Manager| +->| |		| |<-+ | Manager| +->| |
	+-------------+ | +-------------+ | +-------------+		+-------------+ | +-------------+ | +-------------+
	| SSPP |		| SSPP |
	+-----------------------------+		+-----------------------------+
	SNMP		SNMP
	SSPP over SNMP January 2003		SSPP over SNMP November 2003
	Figure 2. Proxied system flow		Figure 2. Proxied system flow
	1.3 Variables used		1.3 Variables used
	AddressC The address of the Client, as chosen by the Client		AddressC The address of the Client, as chosen by the Client
	AddressP The address of the Proxy, as chosen by the Proxy		AddressP The address of the Proxy, as chosen by the Proxy
	AddressS The address of the Server, as chosen by the Server		AddressS The address of the Server, as chosen by the Server
	DHC The Client's Diffie-Hellman public key		DHC The Client's Diffie-Hellman public key
	DHS The Server's Diffie-Hellman public key		DHS The Server's Diffie-Hellman public key
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 4 ¶
	Shared Secret (MUST be protected from reading)		Shared Secret (MUST be protected from reading)
	The Server's Proxied Client table is a temporary table with objects:		The Server's Proxied Client table is a temporary table with objects:
	Proxy Address		Proxy Address
	Proxy Signature		Proxy Signature
	Client Address		Client Address
	Client Diffie-Hellman public key		Client Diffie-Hellman public key
	Client Nonce		Client Nonce
	Client Signature		Client Signature
	SSPP over SNMP January 2003		SSPP over SNMP November 2003
	Server Signature		Server Signature
	Shared Secret (MUST be protected from reading)		Shared Secret (MUST be protected from reading)
	The Proxy's Client table is a temporary table with objects:		The Proxy's Client table is a temporary table with objects:
	Client Address		Client Address
	Client Diffie-Hellman public key		Client Diffie-Hellman public key
	Client Nonce		Client Nonce
	Client Signature		Client Signature
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 4 ¶
	S: Generate NonceS		S: Generate NonceS
	C: GET Parms, DHS, NonceS, AddressS		C: GET Parms, DHS, NonceS, AddressS
	C: If the Server's Parms do not match Client's, stop		C: If the Server's Parms do not match Client's, stop
	If the Public key is not valid, stop		If the Public key is not valid, stop
	Else Generate NonceC, Shared Secret, SigC		Else Generate NonceC, Shared Secret, SigC
	C: SET AddressC, NonceC, DHC, SigC		C: SET AddressC, NonceC, DHC, SigC
	(note: setting the Signature starts the process on the Server)		(note: setting the Signature starts the process on the Server)
	S: set SigS as NULL, Generate Shared Secret		S: set SigS as NULL, Generate Shared Secret
	If SigC is not valid, set SigS as "Error" and stop		If SigC is not valid, set SigS as "Error" and stop
	SSPP over SNMP January 2003		SSPP over SNMP November 2003
	Else Generate SigS, New NonceS		Else Generate SigS, New NonceS
	C: GET SigS until not NULL		C: GET SigS until not NULL
	If SigS is "Error", stop		If SigS is "Error", stop
	2.1 Validating the Diffie-Hellman Public Keys		2.1 Timing to generate Shared Secret
			For keys of 128 bits and a 1 MIP machine that can do a
			multiplication in one cycle, it will take about 3 seconds for a 2048
			bit modulus and 7 seconds for a 3072 bit modulus Diffie-Hellman key
			derivation. These are extremely rough estimates, but they are
			seconds, not minutes. This also assumes that Client has precomputed
			g^a and Server has pre-computed g^b. If they haven't, then double
			the estimates.
			2.2 Validating the Diffie-Hellman Public Keys
	The SSPP client MUST present DHS to some form of validation process.		The SSPP client MUST present DHS to some form of validation process.
	This might be in a UI as a fingerprint of the public key for visual		This might be in a UI as a fingerprint of the public key for visual
	inspection. A recommended fingerprint of the public key is a SHA1		inspection. A recommended fingerprint of the public key is a SHA1
	hash. If 160 bits is too large for visual inspection an LTRUNC96		hash. If 160 bits is too large for visual inspection an LTRUNC96
	can be used to reduce the fingerprint to 96 bits. An X.509 Diffie-		can be used to reduce the fingerprint to 96 bits. An X.509 Diffie-
	Hellman certificate may be used instead of a raw public key for		Hellman certificate may be used instead of a raw public key for
	implementations where a PKI can be deployed.		implementations where a PKI can be deployed.
	SSPP does not require the server to validate DHC. This presents a		SSPP does not require the server to validate DHC. This presents a
	skipping to change at page 6, line 40 ¶		skipping to change at page 7, line 5 ¶
	server. If the intended implementation can have multiple clients		server. If the intended implementation can have multiple clients
	per server, the proxy method described below can be used for the		per server, the proxy method described below can be used for the
	additional clients.		additional clients.
	3. Additional exchanges		3. Additional exchanges
	There are two special forms of the SSPP exchange. One is to support		There are two special forms of the SSPP exchange. One is to support
	changing the shared secret and the other to proxy the SSPP exchange		changing the shared secret and the other to proxy the SSPP exchange
	through a client that already has a shared secret with the server.		through a client that already has a shared secret with the server.
			SSPP over SNMP November 2003
	3.1 Changing a shared secret		3.1 Changing a shared secret
	To change a shared secret, new pair of nonces are used with an		To change a shared secret, new pair of nonces are used with an
	existing set of Diffie-Hellman keys and addresses. The exchange is:		existing set of Diffie-Hellman keys and addresses. The exchange is:
	S: Generate NonceS		S: Generate NonceS
	C: GET NonceS		C: GET NonceS
	Generate NonceC, Shared Secret, SigC		Generate NonceC, Shared Secret, SigC
	C: SET AddressC, NonceC, DHC, SigC		C: SET AddressC, NonceC, DHC, SigC
	(note: setting the Signature starts the process on the Server)		(note: setting the Signature starts the process on the Server)
	S: If AddressC/DHC is already in the Client MIB table and the new		S: If AddressC/DHC is already in the Client MIB table and the new
	NonceC is different from the prior NonceC, set Change		NonceC is different from the prior NonceC, set Change
	SSPP over SNMP January 2003
	Flag in old table entry		Flag in old table entry
	set SigS as NULL, Generate Shared Secret		set SigS as NULL, Generate Shared Secret
	If SigC is not valid, set SigS as "Error", clear Change Flag in		If SigC is not valid, set SigS as "Error", clear Change Flag in
	old table entry and stop		old table entry and stop
	Else Generate SigS, New NonceS and delete the old		Else Generate SigS, New NonceS and delete the old
	AddressC/DHC table entry		AddressC/DHC table entry
	C: GET SigS until not NULL		C: GET SigS until not NULL
	If SigS is "Error", stop		If SigS is "Error", stop
	A successful exchange identifies the client as the owner of DHC and		A successful exchange identifies the client as the owner of DHC and
	skipping to change at page 7, line 42 ¶		skipping to change at page 8, line 4 ¶
	to 'authorize' the exchange. To prevent a hidden man-in-the-middle		to 'authorize' the exchange. To prevent a hidden man-in-the-middle
	attack by a rogue proxy, the principle signature is modified to		attack by a rogue proxy, the principle signature is modified to
	include the proxy's address. That is the client is aware of the		include the proxy's address. That is the client is aware of the
	proxy's role in the exchange.		proxy's role in the exchange.
	The datagram flow is:		The datagram flow is:
	C P S		C P S
	----------GET---------->		----------GET---------->
			SSPP over SNMP November 2003
	<-------Response--------		<-------Response--------
	---SET----->		---SET----->
	-----SET--->		-----SET--->
	---GET----->		---GET----->
	<-Responseù		<-Responseù
	----------GET---------->		----------GET---------->
	<-------Response--------		<-------Response--------
	The exchange and process are:		The exchange and process are:
	S: Generate NonceS		S: Generate NonceS
	C: GET from S - Parms, DHS, NonceS, AddressS		C: GET from S - Parms, DHS, NonceS, AddressS
	SSPP over SNMP January 2003
	(note the client already has AddressP)		(note the client already has AddressP)
	C: If the ServerÆs Parms do not match Client's, stop		C: If the ServerÆs Parms do not match Client's, stop
	If the Public key is not valid, stop		If the Public key is not valid, stop
	Else Generate NonceC, Shared Secret, SigC		Else Generate NonceC, Shared Secret, SigC
	(note SigC uses (Public key || AddressC || AddressP || NonceC))		(note SigC uses (Public key || AddressC || AddressP || NonceS))
	C: SET to P û AddressS, AddressC, NonceC, DHC, SigC		C: SET to P û AddressS, AddressC, NonceC, DHC, SigC
	(note: setting the Signature starts the process on the Proxy)		(note: setting the Signature starts the process on the Proxy)
	P: set ForwardFlag to Null		P: set ForwardFlag to Null
	If the Proxy does not have a Shared Secret with AddressS,		If the Proxy does not have a Shared Secret with AddressS,
	Set ForwardFlag to "Error" and stop		Set ForwardFlag to "Error" and stop
	Generate SigP		Generate SigP
	(note SigP uses (Public key || AddressC || AddressP || NonceC))		(note SigP uses (Public key || AddressC || AddressP || NonceS))
	P: SET to S û AddressP, AddressC, NonceC, DHC, SigC, SigP		P: SET to S û AddressP, AddressC, NonceC, DHC, SigC, SigP
	set ForwardFlag to AddressS		set ForwardFlag to AddressS
	(note: setting the Signature starts the process on the Server)		(note: setting the Signature starts the process on the Server)
	S: set SigS as NULL, Generate Shared Secret		S: set SigS as NULL, Generate Shared Secret
	If the Server does not have a Shared Secret with AddressP,		If the Server does not have a Shared Secret with AddressP,
	set SigS as "ErrorP" and stop		set SigS as "ErrorP" and stop
	If SigP is not valid, set SigS as "ErrorP" and stop		If SigP is not valid, set SigS as "ErrorP" and stop
	If SigC is not valid, set SigS as "Error" and stop		If SigC is not valid, set SigS as "Error" and stop
	Else Generate SigS, New NonceS		Else Generate SigS, New NonceS
	(note SigS uses (AddressS || AddressP || NonceS))		(note SigS uses (AddressS || AddressP || NonceC))
	C: GET from P - ForwardFlag until not NULL		C: GET from P - ForwardFlag until not NULL
	If ForwardFlag is "Error", stop		If ForwardFlag is "Error", stop
	C: GET from S - SigS until not NULL		C: GET from S - SigS until not NULL
	If SigS is "Error" or "ErrorP", stop		If SigS is "Error" or "ErrorP", stop
	The Client may start checking ForwardFlag as soon as it performs the		The Client may start checking ForwardFlag as soon as it performs the
	SET operation to the Proxy. Since the Proxy only acts as an		SET operation to the Proxy. Since the Proxy only acts as an
	'introducer' of the client to the server, the server checks SigC for		'introducer' of the client to the server, the server checks SigC for
	inclusion of AddressP, and the client gets SigS directly from the		inclusion of AddressP, and the client gets SigS directly from the
	Server, a rogue cannot insert itself between an SSPP client and		Server, a rogue cannot insert itself between an SSPP client and
	server and force a proxied exchange. Once a client has a shared		server and force a proxied exchange. Once a client has a shared
	secret with a server, it can directly change the shared secret and		secret with a server, it can directly change the shared secret and
	can itself be a proxy for another client.		can itself be a proxy for another client.
			SSPP over SNMP November 2003
	4. Application of SSPP over SNMP		4. Application of SSPP over SNMP
	SSPP over SNMP is well suited to provisioning shared secrets where		SSPP over SNMP is well suited to provisioning shared secrets where
	the SSPP server is 'headless'. That is where the server does not		the SSPP server is 'headless'. That is where the server does not
	have a UI. Traditionally these sorts of systems are either forced		have a UI. Traditionally these sorts of systems are either forced
	to have a server, like HTTP, implementation to support		to have a server, like HTTP, implementation to support
	configuration, or SNMP is used in an insecure method to configure		configuration, or SNMP is used in an insecure method to configure
	the secret, leaving it up to the deployer to deal with the risk of		the secret, leaving it up to the deployer to deal with the risk of
	secret theft. SSPP not only provides a secure provisioning		secret theft. SSPP not only provides a secure provisioning
	methodology, it produces strong shared secrets and provides for		methodology, it produces strong shared secrets and provides for
	managing those secrets.		managing those secrets.
	SSPP over SNMP January 2003
	4.1 EXAMPLE: RADIUS Client Secret		4.1 EXAMPLE: RADIUS Client Secret
	The RADIUS Client Secret is used to authenticate RADIUS exchanges		The RADIUS Client Secret is used to authenticate RADIUS exchanges
	between a RADIUS Server and its client(s). With the advent of IEEE		between a RADIUS Server and its client(s). With the advent of IEEE
	802.1x [4], RADIUS clients are proliferating in the form of 802.3		802.1x [4], RADIUS clients are proliferating in the form of 802.3
	switches and 802.11 access points. The problems in managing the		switches and 802.11 access points. The problems in managing the
	RADIUS Client Secret are broader than just getting a good secret and		RADIUS Client Secret are broader than just getting a good secret and
	managing it. This is detailed in RADIUS Client Kickstart [5], but		managing it. This is detailed in RADIUS Client Kickstart [5], but
	the general usage is as follows.		the general usage is as follows.
	skipping to change at page 9, line 42 ¶		skipping to change at page 10, line 5 ¶
	assurance that there is no man in the middle between the client and		assurance that there is no man in the middle between the client and
	server.		server.
	The former can be addressed by client system presenting in its UI		The former can be addressed by client system presenting in its UI
	the fingerprint of the public key. The operator would check the		the fingerprint of the public key. The operator would check the
	fingerprint with a copy obtained out-of-band (for example stamped on		fingerprint with a copy obtained out-of-band (for example stamped on
	the server). The later can be addressed by connecting the client		the server). The later can be addressed by connecting the client
	and server with a crossover cable or by trusting the deployed		and server with a crossover cable or by trusting the deployed
	cabling (as in a small office).		cabling (as in a small office).
			SSPP over SNMP November 2003
	The server is potentially open to establishing a shared secret with		The server is potentially open to establishing a shared secret with
	any system. Since the SSPP server is typically a client for all		any system. Since the SSPP server is typically a client for all
	other services, this could leave it open to attack through the		other services, this could leave it open to attack through the
	services that the shared secret is suppose to protect. As such a		services that the shared secret is suppose to protect. As such a
	server might have a policy to only allow one client to use the basic		server might have a policy to only allow one client to use the basic
	exchange and all additional clients must use the proxy exchange.		exchange and all additional clients must use the proxy exchange.
	Typically, the first client, while the server is in factory default		Typically, the first client, while the server is in factory default
	state, will be able to use the basic exchange. If a rogue client		state, will be able to use the basic exchange. If a rogue client
	intervened before the intended client established its shared secret,		intervened before the intended client established its shared secret,
	this would be discovered and the server could be reset to its		this would be discovered and the server could be reset to its
	factory default state.		factory default state.
	SSPP over SNMP January 2003
	The nonces are an important contributor to the shared secret		The nonces are an important contributor to the shared secret
	generation. The current cryptographic literature recommends that		generation. The current cryptographic literature recommends that
	the nonces be twice the length of the desired final key.		the nonces be twice the length of the desired final key.
	Additionally, it is the unique nonces that produce a unique key each		Additionally, it is the unique nonces that produce a unique key each
	time the Change Secret exchange occurs. The nonces MUST be unique		time the Change Secret exchange occurs. The nonces MUST be unique
	and random.		and random.
	References		References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP		1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.		9, RFC 2026, October 1996.
	2 Moskowitz, R., "The Shared Secret Provisioning Protocol",		2 Moskowitz, R., "The Shared Secret Provisioning Protocol",
	Internet Draft draft-moskowitz-shared-secret-provprotocol-00.txt,		Internet Draft draft-moskowitz-shared-secret-provprotocol-02.txt,
	December 2002.		November 2003.
	3 Bradner, S., "Key words for use in RFCs to Indicate Requirement		3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	4 IEEE Std 802.1X-2001, "Port-Based Network Access Control", June		4 IEEE Std 802.1X-2001, "Port-Based Network Access Control", June
	2001.		2001.
	5 Moskowitz, R., "RADIUS Client Kickstart", Internet Draft draft-		5 Moskowitz, R., "RADIUS Client Kickstart", Internet Draft draft-
	moskowitz-radius-client-kickstart-01.txt, January 2003.		moskowitz-radius-client-kickstart-02.txt, November 2003.
	Acknowledgments		Acknowledgments
	This document is the result of the first IETF Credential		This document is the result of the first IETF Credential
	provisioning workshop and extracted from the original RADIUS Client		provisioning workshop and extracted from the original RADIUS Client
	Kickstart Internet Draft. Bob Stewart helped explain how an SNMP		Kickstart Internet Draft. Bob Stewart helped explain how an SNMP
	SET can trigger internal processes and how the SNMP manager polls		SET can trigger internal processes and how the SNMP manager polls
	the SNMP agent for objects set as a result of such a process.		the SNMP agent for objects set as a result of such a process.
			SSPP over SNMP November 2003
	Author's Addresses		Author's Addresses
	Robert Moskowitz		Robert Moskowitz
	TruSecure/ICSAlabs		TruSecure/ICSAlabs
	1000 Bent Creek Blvd, Suite 200		1000 Bent Creek Blvd, Suite 200
	Mechanicsburg, PA		Mechanicsburg, PA
	Email: rgm@trusecure.com		Email: rgm@trusecure.com
End of changes. 35 change blocks.
	63 lines changed or deleted		75 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/