draft-ietf-radext-radsec-03.txt		draft-ietf-radext-radsec-04.txt
	RADIUS Extensions Working Group S. Winter		RADIUS Extensions Working Group S. Winter
	Internet-Draft RESTENA		Internet-Draft RESTENA
	Intended status: Experimental M. McCauley		Intended status: Experimental M. McCauley
	Expires: August 15, 2009 OSC		Expires: September 7, 2009 OSC
	S. Venaas		S. Venaas
	UNINETT		UNINETT
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	February 11, 2009		March 06, 2009
	TLS encryption for RADIUS over TCP (RadSec)		TLS encryption for RADIUS over TCP (RadSec)
	draft-ietf-radext-radsec-03		draft-ietf-radext-radsec-04
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79. This document may contain material
			from IETF Documents or IETF Contributions published or made publicly
			available before November 10, 2008. The person(s) controlling the
			copyright in some of this material may not have granted the IETF
			Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
			the person(s) controlling the copyright in such materials, this
			document may not be modified outside the IETF Standards Process, and
			derivative works of it may not be created outside the IETF Standards
			Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents 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		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 15, 2009.		This Internet-Draft will expire on September 7, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	This document specifies security on the transport layer (TLS) for the		This document specifies security on the transport layer (TLS) for the
	RADIUS protocol [RFC2865] when transmitted over TCP		RADIUS protocol [RFC2865] when transmitted over TCP
	[I-D.dekok-radext-tcp-transport]. This enables dynamic trust		[I-D.dekok-radext-tcp-transport]. This enables dynamic trust
	relationships between RADIUS servers.		relationships between RADIUS servers.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Normative: Transport Layer Security for RADIUS over TCP . . . 4		2. Normative: Transport Layer Security for RADIUS over TCP . . . 4
	2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4		2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
	2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4		2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
	2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5		2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5
	3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7		3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7
	3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7		3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7
	3.2. Ciphersuites and Compression Negotiation Considerations . 7		3.2. Ciphersuites and Compression Negotiation Considerations . 8
	3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8		3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
	4. Compatibility with other RADIUS transports . . . . . . . . . . 9		4. Compatibility with other RADIUS transports . . . . . . . . . . 9
	5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9		5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 13		Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13
	Appendix B. Implementation Overview: Radiator . . . . . . . . . . 14		Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14
	Appendix C. Implementation Overview: radsecproxy . . . . . . . . 15
	1. Introduction		1. Introduction
	The RADIUS protocol [RFC2865] is a widely deployed authentication and		The RADIUS protocol [RFC2865] is a widely deployed authentication and
	authorisation protocol. The supplementary RADIUS Accounting		authorisation protocol. The supplementary RADIUS Accounting
	specification [RFC2866] also provides accounting mechanisms, thus		specification [RFC2866] also provides accounting mechanisms, thus
	delivering a full AAA solution. However, RADIUS is experiencing		delivering a full AAA solution. However, RADIUS is experiencing
	several shortcomings, such as its dependency on the unreliable		several shortcomings, such as its dependency on the unreliable
	transport protocol UDP and the lack of security for large parts of		transport protocol UDP and the lack of security for large parts of
	its packet payload. RADIUS security is based on the MD5 algorithm,		its packet payload. RADIUS security is based on the MD5 algorithm,
	skipping to change at page 3, line 42		skipping to change at page 3, line 42
	massive deployment of RADIUS-servers under control by different		massive deployment of RADIUS-servers under control by different
	administrative entities is to introduce some form of a proxy chain to		administrative entities is to introduce some form of a proxy chain to
	route the access requests to their home server. This creates a lot		route the access requests to their home server. This creates a lot
	of overhead in terms of possible points of failure, longer		of overhead in terms of possible points of failure, longer
	transmission times as well as middleboxes through which		transmission times as well as middleboxes through which
	authentication traffic flows. These middleboxes may learn privacy-		authentication traffic flows. These middleboxes may learn privacy-
	relevant data while forwarding requests. The new features in RadSec		relevant data while forwarding requests. The new features in RadSec
	obsolete the use of IP addresses and shared MD5 secrets to identify		obsolete the use of IP addresses and shared MD5 secrets to identify
	other peers and thus allow the dynamic establishment of connections		other peers and thus allow the dynamic establishment of connections
	to peers that are not previously configured, and thus makes it		to peers that are not previously configured, and thus makes it
	possible to avoid intermediate aggregation proxies. The definition		possible to avoid intermediate aggregation proxies. One mechanism
	of lookup mechanisms is out of scope of this document, but an		discover RadSec peers with DNS is specified in
	implementation of a DNS NAPTR lookup based mechanism exists and is		[I-D.winter-dynamic-discovery].
	described as an example lookup mechanism in Appendix A.
	1.1. Requirements Language		1.1. Requirements Language
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. The key words "MUST", "MUST NOT", "REQUIRED",		of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" in this document are to be interpreted as described in		and "OPTIONAL" in this document are to be interpreted as described in
	RFC 2119. [RFC2119]		RFC 2119. [RFC2119]
	1.2. Terminology		1.2. Terminology
	skipping to change at page 4, line 40		skipping to change at page 4, line 39
	TLS 1.1. The following restrictions apply:		TLS 1.1. The following restrictions apply:
	* The authentication MUST be mutual, i.e. both the RadSec server		* The authentication MUST be mutual, i.e. both the RadSec server
	and the RadSec client authenticate each other.		and the RadSec client authenticate each other.
	* The client MUST NOT negotiate cipher suites which only provide		* The client MUST NOT negotiate cipher suites which only provide
	integrity protection.		integrity protection.
	* The TLS session MAY use mutual PSKs for connection setup.		* The TLS session MAY use mutual PSKs for connection setup.
	* The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be		* RADSEC implementations MUST support he mandatory to implement
	supported.		cipher suites specified in TLS. For purposes of compatibility
			with some current deployments implementations SHOULD support
	* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and		TLS_RSA_WITH_RC4_128_SHA as well (see Section 3.2 (1) ).
	TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
	(1) )
	3. If TLS is used in an X.509 certificate based operation mode, the		3. If TLS is used in an X.509 certificate based operation mode, the
	following list of certificate validation options applies:		following list of certificate validation options applies:
	* Implementations MUST allow to configure a list of acceptable		* Implementations MUST allow to configure a list of acceptable
	Certification Authorities for incoming connections.		Certification Authorities for incoming connections.
	* Certificate validation MUST include the verification rules as		* Certificate validation MUST include the verification rules as
	per [RFC5280]. If an SRV entry is present in the certificate		per [RFC5280]. If service names as per [RFC4985] are present
	and dynamic discovery based on DNS is used, the SRV entry		in the certificate and dynamic discovery utilizing SRVs in DNS
	SHOULD be validated. refence x.y.z here.		is used (see [I-D.winter-dynamic-discovery]), the SRV entry
			SHOULD be validated.
	* Implementations SHOULD indicate their acceptable Certification		* Implementations SHOULD indicate their acceptable Certification
	Authorities as per section 7.4.4 (server side) and x.y.z		Authorities as per section 7.4.4 (server side) and x.y.z
	["Trusted CA Indication"] (client side) of [RFC5246] (see		["Trusted CA Indication"] (client side) of [RFC5246] (see
	Section 3.1 (1) )		Section 3.1 (1) )
	* Implementations SHOULD allow to configure a list of acceptable		* Implementations SHOULD allow to configure a list of acceptable
	certificates, identified via certificate fingerprint.		certificates, identified via certificate fingerprint. When a
			fingerprint configured, the fingerprint is prepended with an
			ASCII label identifying the hash function followed by a colon.
			Implementations MUST support SHA-1 as the hash algorithm and
			use the ASCII label "sha-1" to identify the SHA-1 algorithm.
			The length of a SHA-1 hash is 20 bytes and the length of the
			corresponding fingerprint string is 65 characters. An example
			certificate fingerprint is: sha-
			1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
	* Peer validation always includes a check on whether the DNS		* Peer validation always includes a check on whether the DNS
	name or the IP address of the server that is contacted matches		name or the IP address of the server that is contacted matches
	its certificate. DNS names and IP addresses can be contained		its certificate. DNS names and IP addresses can be contained
	in the Common Name (CN) or subjectAltName entries. For		in the Common Name (CN) or subjectAltName entries. For
	verification, only one these entries is to be considered. The		verification, only one these entries is to be considered. The
	following precedence applies: for DNS name validation,		following precedence applies: for DNS name validation,
	subjectAltName:DNS has precedence over CN; for IP address		subjectAltName:DNS has precedence over CN; for IP address
	validation, subjectAltName:iPAddr has precedence over CN.		validation, subjectAltName:iPAddr has precedence over CN.
	skipping to change at page 10, line 46		skipping to change at page 11, line 5
	Password, to intermediate IP nodes.		Password, to intermediate IP nodes.
	If peer communication between two devices is configured for both		If peer communication between two devices is configured for both
	RadSec and classic RADIUS, a failover from RadSec to classic RADIUS		RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
	opens the way for a down-bidding attack if an adversary can		opens the way for a down-bidding attack if an adversary can
	maliciously close the TCP connection, or prevent it from being		maliciously close the TCP connection, or prevent it from being
	established. In this case, security of the packet payload is reduced		established. In this case, security of the packet payload is reduced
	from the selected TLS cipher suite packet encryption to the classic		from the selected TLS cipher suite packet encryption to the classic
	MD5 per-attribute encryption.		MD5 per-attribute encryption.
			The RadSec transport provides authentication and encryption between
			RADIUS peers. In the presence of proxies, the intermediate proxies
			can still inspect the individual RADIUS packets, i.e. "end-to-end"
			encryption is not provided. Where intermediate proxies are
			untrusted, it is desirable to use other RADIUS mechanisms to prevent
			RADIUS packet payload from inspection by such proxies. One common
			method to protect passwords is the use of EAP methods which utilize
			TLS.
	7. IANA Considerations		7. IANA Considerations
	This document has no actions for IANA. The TCP port 2083 was already		This document has no actions for IANA. The TCP port 2083 was already
	previously assigned by IANA for RadSec. No new RADIUS attributes or		previously assigned by IANA for RadSec. No new RADIUS attributes or
	packet codes are defined.		packet codes are defined.
	8. Acknowledgements		8. Acknowledgements
	RadSec version 1 was first implemented by Open Systems Consultants,		RadSec version 1 was first implemented by Open Systems Consultants,
	Currumbin Waters, Australia, for their "Radiator" RADIUS server		Currumbin Waters, Australia, for their "Radiator" RADIUS server
	skipping to change at page 11, line 33		skipping to change at page 11, line 48
	March 1997.		March 1997.
	[RFC2865] Rigney, C., Willens, S., Rubens,		[RFC2865] Rigney, C., Willens, S., Rubens,
	A., and W. Simpson, "Remote		A., and W. Simpson, "Remote
	Authentication Dial In User Service		Authentication Dial In User Service
	(RADIUS)", RFC 2865, June 2000.		(RADIUS)", RFC 2865, June 2000.
	[RFC2866] Rigney, C., "RADIUS Accounting",		[RFC2866] Rigney, C., "RADIUS Accounting",
	RFC 2866, June 2000.		RFC 2866, June 2000.
			[RFC4985] Santesson, S., "Internet X.509
			Public Key Infrastructure Subject
			Alternative Name for Expression of
			Service Name", RFC 4985,
			August 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell,		[RFC5280] Cooper, D., Santesson, S., Farrell,
	S., Boeyen, S., Housley, R., and W.		S., Boeyen, S., Housley, R., and W.
	Polk, "Internet X.509 Public Key		Polk, "Internet X.509 Public Key
	Infrastructure Certificate and		Infrastructure Certificate and
	Certificate Revocation List (CRL)		Certificate Revocation List (CRL)
	Profile", RFC 5280, May 2008.		Profile", RFC 5280, May 2008.
	[RFC5176] Chiba, M., Dommety, G., Eklund, M.,		[RFC5176] Chiba, M., Dommety, G., Eklund, M.,
	Mitton, D., and B. Aboba, "Dynamic		Mitton, D., and B. Aboba, "Dynamic
	Authorization Extensions to Remote		Authorization Extensions to Remote
	skipping to change at page 12, line 13		skipping to change at page 12, line 34
	draft-dekok-radext-tcp-transport-01		draft-dekok-radext-tcp-transport-01
	(work in progress), November 2008.		(work in progress), November 2008.
	9.2. Informative References		9.2. Informative References
	[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport		[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport
	Layer for RADIUS",		Layer for RADIUS",
	draft-dekok-radext-dtls-00 (work in		draft-dekok-radext-dtls-00 (work in
	progress), February 2007.		progress), February 2007.
	[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery		[I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI-
	for RADIUS over TLD and DTLS",		based Dynamic Peer Discovery for
			RADIUS over TLS and DTLS",
	draft-winter-dynamic-discovery-00		draft-winter-dynamic-discovery-00
	(work in progress), February 2009.		(work in progress), February 2009.
	[RFC3588] Calhoun, P., Loughney, J., Guttman,		[RFC3588] Calhoun, P., Loughney, J., Guttman,
	E., Zorn, G., and J. Arkko,		E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588,		"Diameter Base Protocol", RFC 3588,
	September 2003.		September 2003.
	[radsec-whitepaper] Open System Consultants, "RadSec -		[radsec-whitepaper] Open System Consultants, "RadSec -
	a secure, reliable RADIUS		a secure, reliable RADIUS
	skipping to change at page 13, line 6		skipping to change at page 13, line 27
	Technology to Europe, "European		Technology to Europe, "European
	Commission Information Society and		Commission Information Society and
	Media: GEANT2", 2008,		Media: GEANT2", 2008,
	<http://www.geant2.net/>.		<http://www.geant2.net/>.
	[terena] TERENA, "Trans-European Research		[terena] TERENA, "Trans-European Research
	and Education Networking		and Education Networking
	Association", 2008,		Association", 2008,
	<http://www.terena.org/>.		<http://www.terena.org/>.
	Appendix A. DNS NAPTR Peer Discovery		Appendix A. Implementation Overview: Radiator
	The following text is paraphrased from the file goodies/dnsroam.cfg
	in the Radiator distribution; further documentation of the <AuthBy
	DNSROAM> feature in Radiator can be found at [radiator-manual]. It
	describes an algorithm to retrieve the RadSec route information from
	the global DNS using NAPTR and SRV records. The input of the
	algorithm is the realm part of the user name.
	The following algorithm is used to discover a target server from a
	Realm using DNS:
	1. Look for NAPTR records for the Realm. If found, continue at step
	2, otherwise continue at step 4.
	2. For each NAPTR record found, examine the Service field and use
	that to determine the transport protocol and TLS requirements for
	the server. The Service field starts with 'AAA' for insecure and
	'AAAS' for TLS secured. The Service field contains '+RADSECS'
	for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS'
	for RADIUS protocol over UDP. The most common Service field you
	will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP.
	3.
	A. If the NAPTR has the 'S' flag, look for SRV records for the
	name. For each SRV record found, note the Port number and
	then look for A and AAAA records corresponding to the name in
	the SRV record.
	B. If the NAPTR has the 'A' flag, look for a A and AAAA records
	for the name.
	4. All A and AAAA records found are ordered according to their Order
	and Preference fields. The most preferable server address is
	used as the target server address, along with any other server
	attributes discovered from DNS. If no SRV record was found for
	the address, the DNSROAM configured Port is used. Algorithm
	terminates.
	5. Look for A and AAAA records on the literal realm name, preceded
	by "_radsec._tcp.". For example, if the realm is 'example.com',
	it looks for the record '_radsec._tcp.example.com'. If more than
	one result is returned, no ordering is assumed. Algorithm
	terminates.
	For example, if the User-Name realm was 'example.com', and DNS
	contained the following records:
	example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" ""
	_radsec._tcp.example.com.
	_radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com.
	radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704
	Then the target selected would be a RadSec server on port 2083 at
	IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be
	made over TCP/IP, and TLS encryption would be used. This complete
	specification of the realm is the most flexible one and is
	recommended.
	Appendix B. Implementation Overview: Radiator
	Radiator implements the RadSec protocol for proxying requests with		Radiator implements the RadSec protocol for proxying requests with
	the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator		the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator
	configuration file.		configuration file.
	The <AuthBy RADSEC> clause defines a RadSec client, and causes		The <AuthBy RADSEC> clause defines a RadSec client, and causes
	Radiator to send RADIUS requests to the configured RadSec server		Radiator to send RADIUS requests to the configured RadSec server
	using the RadSec protocol.		using the RadSec protocol.
	The <ServerRADSEC> clause defines a RadSec server, and causes		The <ServerRADSEC> clause defines a RadSec server, and causes
	skipping to change at page 15, line 22		skipping to change at page 14, line 28
	* Secret radsec		* Secret radsec
	As of Radiator 3.15, the default shared secret for RadSec connections		As of Radiator 3.15, the default shared secret for RadSec connections
	is configurable and defaults to "mysecret" (without quotes). For		is configurable and defaults to "mysecret" (without quotes). For
	compliance with this document, this setting needs to be configured		compliance with this document, this setting needs to be configured
	for the shared secret "radsec". The implementation uses TCP		for the shared secret "radsec". The implementation uses TCP
	keepalive socket options, but does not send Status-Server packets.		keepalive socket options, but does not send Status-Server packets.
	Once established, TLS connections are kept open throughout the server		Once established, TLS connections are kept open throughout the server
	instance lifetime.		instance lifetime.
	Appendix C. Implementation Overview: radsecproxy		Appendix B. Implementation Overview: radsecproxy
	The RADIUS proxy named radsecproxy was written in order to allow use		The RADIUS proxy named radsecproxy was written in order to allow use
	of RadSec in current RADIUS deployments. This is a generic proxy		of RadSec in current RADIUS deployments. This is a generic proxy
	that supports any number and combination of clients and servers,		that supports any number and combination of clients and servers,
	supporting RADIUS over UDP and RadSec. The main idea is that it can		supporting RADIUS over UDP and RadSec. The main idea is that it can
	be used on the same host as a non-RadSec client or server to ensure		be used on the same host as a non-RadSec client or server to ensure
	RadSec is used on the wire, however as a generic proxy it can be used		RadSec is used on the wire, however as a generic proxy it can be used
	in other circumstances as well.		in other circumstances as well.
	The configuration file consists of client and server clauses, where		The configuration file consists of client and server clauses, where
End of changes. 20 change blocks.
	97 lines changed or deleted		64 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/