draft-ietf-radext-radsec-01.txt   draft-ietf-radext-radsec-02.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: February 23, 2009 OSC Expires: April 27, 2009 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
August 22, 2008 October 24, 2008
TLS encryption for RADIUS over TCP (RadSec) TLS encryption for RADIUS over TCP (RadSec)
draft-ietf-radext-radsec-01 draft-ietf-radext-radsec-02
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 1, line 39 skipping to change at page 1, line 39
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 February 23, 2009. This Internet-Draft will expire on April 27, 2009.
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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 6 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 6
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6
3.2. Ciphersuites and Compression Negotiation Considerations . 8 3.2. Ciphersuites and Compression Negotiation Considerations . 8
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Informative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12 Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12
Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13 Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13
Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14 Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14
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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
of lookup mechanisms is out of scope of this document, but an of lookup mechanisms is out of scope of this document, but an
implementation of a DNS NAPTR lookup based mechanism exists and is implementation of a DNS NAPTR lookup based mechanism exists and is
described as an example lookup mechanism in Appendix A. 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
[RFC2119]. RFC 2119. [RFC2119]
1.2. Terminology 1.2. Terminology
RadSec node: a RadSec client or server RadSec node: a RadSec client or server
RadSec Client: a RadSec instance which initiates a new connection. RadSec Client: a RadSec instance which initiates a new connection.
RadSec Server: a RadSec instance which listens on a RadSec port and RadSec Server: a RadSec instance which listens on a RadSec port and
accepts new connections accepts new connections
skipping to change at page 4, line 32 skipping to change at page 4, line 32
2.2. Connection Setup 2.2. Connection Setup
RadSec nodes RadSec nodes
1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport]
2. negotiate TLS sessions according to [RFC5246] or its predecessor 2. negotiate TLS sessions according to [RFC5246] or its predecessor
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
and the RadSec client authenticate each other.
* When using X.509 certificates, RadSec servers SHOULD indicate * When using X.509 certificates, RadSec servers SHOULD indicate
their acceptable Certification Authorities as per section their acceptable Certification Authorities as per section
7.4.4 of [RFC5246] (see Section 3.1 (1) ) 7.4.4 of [RFC5246] (see Section 3.1 (1) )
* When using X.509 certificates, the TLS Extension "Trusted CA * When using X.509 certificates, the TLS Extension "Trusted CA
Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD
be used to indicate trusted CAs for the client (see be used to indicate trusted CAs for the client (see
Section 3.1 (2) ) Section 3.1 (2) )
* When using X.509 certificates, certificate validation is * When using X.509 certificates, certificate validation is
performed as per [RFC5280] or its TLS 1.1 predecessor. The performed as per [RFC5280] or its predecessor. The client MAY
client MAY perform additional checks to accomodate for perform additional checks to accomodate for different trust
different trust models. models.
* 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 cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be * The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
supported. supported.
* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and * The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
(1) ) (1) )
skipping to change at page 9, line 5 skipping to change at page 9, line 5
the Response Authenticator. In RADIUS accounting [RFC2866], the the Response Authenticator. In RADIUS accounting [RFC2866], the
shared secret is used in computation of both the Request shared secret is used in computation of both the Request
Authenticator and the Response Authenticator. Since TLS provides Authenticator and the Response Authenticator. Since TLS provides
integrity protection and encryption sufficient to substitute for integrity protection and encryption sufficient to substitute for
RADIUS application-layer security, it is not necessary to configure a RADIUS application-layer security, it is not necessary to configure a
RADIUS shared secret. The use of a fixed string for the obsolete RADIUS shared secret. The use of a fixed string for the obsolete
shared secret eliminates possible node misconfigurations. shared secret eliminates possible node misconfigurations.
(3) RADIUS [RFC2865] uses different UDP ports for authentication, (3) RADIUS [RFC2865] uses different UDP ports for authentication,
accounting and dynamic authorisation changes. RadSec allocates a accounting and dynamic authorisation changes. RadSec allocates a
single port for all RADIUS packet types. Also in RadSec, the notion single port for all RADIUS packet types. Nevertheless, in RadSec the
of a client which sends authentication requests and processes replies notion of a client which sends authentication requests and processes
associated with it's users' sessions and the notion of a server which replies associated with it's users' sessions and the notion of a
receives requests, processes them and sends the appropriate replies server which receives requests, processes them and sends the
is to be preserved. The normative rules about acceptable packet appropriate replies is to be preserved. The normative rules about
types for clients and servers mirror the packet flow behaviour from acceptable packet types for clients and servers mirror the packet
RADIUS. flow behaviour from RADIUS.
(4) RADIUS [RFC2865] used negative ICMP responses to a newly (4) RADIUS [RFC2865] used negative ICMP responses to a newly
allocated UDP port to signal that a peer RADIUS server does not allocated UDP port to signal that a peer RADIUS server does not
support reception and processing of the packet types in [RFC5176]. support reception and processing of the packet types in [RFC5176].
These packet types are listed as to be received in RadSec These packet types are listed as to be received in RadSec
implementations. Note well: it is not required for an implementation implementations. Note well: it is not required for an implementation
to actually process these packet types. It is sufficient that upon to actually process these packet types. It is sufficient that upon
receiving such a packet, an unconditional NAK is sent back to receiving such a packet, an unconditional NAK is sent back to
indicate that the action is not supported. indicate that the action is not supported.
skipping to change at page 9, line 46 skipping to change at page 9, line 46
In the case of dynamic peer discovery, a RadSec node needs to be able In the case of dynamic peer discovery, a RadSec node needs to be able
to accept connections from a large, not previously known, group of to accept connections from a large, not previously known, group of
hosts, possibly the whole internet. In this case, the server's hosts, possibly the whole internet. In this case, the server's
RadSec port can not be protected from unauthorised connection RadSec port can not be protected from unauthorised connection
attempts with measures on the network layer, i.e. access lists and attempts with measures on the network layer, i.e. access lists and
firewalls. This opens more attack vectors for Distributed Denial of firewalls. This opens more attack vectors for Distributed Denial of
Service attacks, just like any other service that is supposed to Service attacks, just like any other service that is supposed to
serve arbitrary clients (like for example web servers). serve arbitrary clients (like for example web servers).
In the case of dynamic peer discovery, X.509 certificates are the
only proof of authorisation for a connecting RadSec nodes. Special
care needs to be taken that certificates get verified properly
according to the chosen trust model (particularly: consulting CRL
lists, checking critical extensions, checking subjectAltNames etc.)
to prevent unauthorised connections.
Some TLS ciphersuites only provide integrity validation of their Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification forbids the payload, and provide no encryption. This specification forbids the
use of such ciphersuites. Since the RADIUS payload's shared secret use of such ciphersuites. Since the RADIUS payload's shared secret
is fixed and well-known, failure to comply with this requirement will is fixed and well-known, failure to comply with this requirement will
expose the entire datagram payload in plain text, including User- expose the entire datagram payload in plain text, including User-
Password, to intermediate IP nodes. Password, to intermediate IP nodes.
6. IANA Considerations 6. 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
skipping to change at page 10, line 24 skipping to change at page 10, line 31
Currumbin Waters, Australia, for their "Radiator" RADIUS server Currumbin Waters, Australia, for their "Radiator" RADIUS server
product (see [radsec-whitepaper]). product (see [radsec-whitepaper]).
Funding and input for the development of this Internet Draft was Funding and input for the development of this Internet Draft was
provided by the European Commission co-funded project "GEANT2" provided by the European Commission co-funded project "GEANT2"
[geant2] and further feedback was provided by the TERENA Task Force [geant2] and further feedback was provided by the TERENA Task Force
Mobility [terena]. Mobility [terena].
8. References 8. References
8.1. Informative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens,
A., and W. Simpson, "Remote
Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting",
RFC 2866, June 2000.
[RFC5280] Cooper, D., Santesson, S., Farrell,
S., Boeyen, S., Housley, R., and W.
Polk, "Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M.,
Mitton, D., and B. Aboba, "Dynamic
Authorization Extensions to Remote
Authentication Dial In User Service
(RADIUS)", RFC 5176, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246,
August 2008.
[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",
draft-dekok-radext-tcp-transport-00
(work in progress), July 2008.
8.2. Informative References
[RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588,
September 2003.
[radsec-whitepaper] Open System Consultants, "RadSec - [radsec-whitepaper] Open System Consultants, "RadSec -
a secure, reliable RADIUS a secure, reliable RADIUS
Protocol", May 2005, <http:// Protocol", May 2005, <http://
www.open.com.au/radiator/ www.open.com.au/radiator/
radsec-whitepaper.pdf>. radsec-whitepaper.pdf>.
[radiator-manual] Open System Consultants, "Radiator [radiator-manual] Open System Consultants, "Radiator
Radius Server - Installation and Radius Server - Installation and
Reference Manual", 2006, <http:// Reference Manual", 2006, <http://
www.open.com.au/radiator/ref.html>. www.open.com.au/radiator/ref.html>.
skipping to change at page 11, line 13 skipping to change at page 12, line 10
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/>.
8.2. Normative References
[RFC2865] Rigney, C., Willens, S., Rubens,
A., and W. Simpson, "Remote
Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting",
RFC 2866, June 2000.
[RFC5280] Cooper, D., Santesson, S., Farrell,
S., Boeyen, S., Housley, R., and W.
Polk, "Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M.,
Mitton, D., and B. Aboba, "Dynamic
Authorization Extensions to Remote
Authentication Dial In User Service
(RADIUS)", RFC 5176, January 2008.
[RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588,
September 2003.
[RFC5246] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246,
August 2008.
[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",
draft-dekok-radext-tcp-transport-00
(work in progress), July 2008.
Appendix A. DNS NAPTR Peer Discovery Appendix A. DNS NAPTR Peer Discovery
The following text is quoted from the file goodies/dnsroam.cfg in the The following text is paraphrased from the file goodies/dnsroam.cfg
Radiator distribution; further documentation of the <AuthBy DNSROAM> in the Radiator distribution; further documentation of the <AuthBy
feature in Radiator can be found at [radiator-manual]. It describes DNSROAM> feature in Radiator can be found at [radiator-manual]. It
an algorithm to retrieve the RadSec route information from the global describes an algorithm to retrieve the RadSec route information from
DNS using NAPTR and SRV records. The input of the algorithm is the the global DNS using NAPTR and SRV records. The input of the
realm part of the user name. algorithm is the realm part of the user name.
The following algorithm is used to discover a target server from a The following algorithm is used to discover a target server from a
Realm using DNS: Realm using DNS:
1. Look for NAPTR records for the Realm. 1. Look for NAPTR records for the Realm. If found, continue at step
2, otherwise continue at step 4.
2. For each NAPTR found record, examine the Service field and use 2. For each NAPTR found record, examine the Service field and use
that to determine the transport protocol and TLS requirements for that to determine the transport protocol and TLS requirements for
the server. The Service field starts with 'AAA' for insecure and the server. The Service field starts with 'AAA' for insecure and
'AAAS' for TLS secured. The Service field contains '+RADSECS' 'AAAS' for TLS secured. The Service field contains '+RADSECS'
for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS'
for RADIUS protocol over UDP. The most common Service field you for RADIUS protocol over UDP. The most common Service field you
will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP.
3. 3.
A. If the NAPTR has the 'S' flag, look for SRV records for the 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 name. For each SRV record found, note the Port number and
then look for A and AAAA records corresponding to the name in then look for A and AAAA records corresponding to the name in
the SRV record. the SRV record.
B. If the NAPTR has the 'A' flag, look for a A and AAAA records B. If the NAPTR has the 'A' flag, look for a A and AAAA records
for the name. for the name.
4. If no NAPTR records are found, look for A and AAAA records based 4. All A and AAAA records found are ordered according to their Order
directly on the realm name. For example, if the realm is
'examplerealm.edu', it looks for records such as
'_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu'
and '_radius._udp.examplerealm.edu',
5. All A and AAAA records found are ordered according to their Order
and Preference fields. The most preferable server address is and Preference fields. The most preferable server address is
used as the target server address, along with any other server used as the target server address, along with any other server
attributes discovered from DNS. If no SRV record was found for attributes discovered from DNS. If no SRV record was found for
the address, the DNSROAM configured Port is used. the address, the DNSROAM configured Port is used. Algorithm
terminates.
For example, if the User-Name realm was 'examplerealm.edu', and DNS 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: contained the following records:
examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" ""
_radsec._tcp.examplerealm.edu. _radsec._tcp.example.com.
_radsec._tcp.examplerealm.edu. IN SRV 0 10 2083 _radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com.
radsec.examplerealm.edu.
radsec.examplerealm.edu. IN AAAA 2001::202:44ff:fe0a:f704 radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704
Then the target selected would be a RadSec server on port 2083 at Then the target selected would be a RadSec server on port 2083 at
IPv6 address 2001::202:44ff:fe0a:f704. The connection would be made IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be
over TCP/IP, and TLS encryption would be used. This complete made over TCP/IP, and TLS encryption would be used. This complete
specification of the realm is the most flexible and is recommended. specification of the realm is the most flexible and is recommended.
Appendix B. Implementation Overview: Radiator 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
skipping to change at page 13, line 46 skipping to change at page 14, line 4
Radiator is compliant to version 2 of RadSec if the following options Radiator is compliant to version 2 of RadSec if the following options
are used: are used:
<AuthBy RADSEC> <AuthBy RADSEC>
* Protocol tcp * Protocol tcp
* UseTLS * UseTLS
* TLS_CertificateFile * TLS_CertificateFile
* Secret radsec
<ServerRADSEC> <ServerRADSEC>
* Protocol tcp * Protocol tcp
* UseTLS * UseTLS
* TLS_RequireClientCert * TLS_RequireClientCert
* 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 "mysecret" (without quotes). The implementation uses TCP is configurable and defaults to "mysecret" (without quotes). For
compliance with this document, this setting needs to be configured
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 C. 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
 End of changes. 26 change blocks. 
79 lines changed or deleted 96 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/