draft-ietf-radext-radsec-09.txt | draft-ietf-radext-radsec-10.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: January 9, 2012 OSC | Expires: July 12, 2012 OSC | |||
S. Venaas | S. Venaas | |||
UNINETT | UNINETT | |||
K. Wierenga | K. Wierenga | |||
Cisco | Cisco | |||
July 8, 2011 | January 9, 2012 | |||
TLS encryption for RADIUS | TLS encryption for RADIUS | |||
draft-ietf-radext-radsec-09 | draft-ietf-radext-radsec-10 | |||
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 when transmitted over TCP. This enables dynamic | RADIUS protocol when transmitted over TCP. This enables dynamic | |||
trust relationships between RADIUS servers. | trust relationships between RADIUS servers. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 37 | skipping to change at page 1, line 37 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
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." | |||
This Internet-Draft will expire on January 9, 2012. | This Internet-Draft will expire on July 12, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2012 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 43 | skipping to change at page 2, line 43 | |||
3.2. Ciphersuites and Compression Negotiation Considerations . 9 | 3.2. Ciphersuites and Compression Negotiation Considerations . 9 | |||
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 | 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 | |||
4. Compatibility with other RADIUS transports . . . . . . . . . . 11 | 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 | |||
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 | 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15 | Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 | |||
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16 | Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 | |||
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 17 | Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 | |||
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 45 | skipping to change at page 3, line 45 | |||
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 RADIUS | relevant data while forwarding requests. The new features in RADIUS | |||
over TLS obsolete the use of IP addresses and shared MD5 secrets to | over TLS obsolete the use of IP addresses and shared MD5 secrets to | |||
identify other peers and thus allow the dynamic establishment of | identify other peers and thus allow the dynamic establishment of | |||
connections to peers that are not previously configured, and thus | connections to peers that are not previously configured, and thus | |||
makes it possible to avoid aggregation-only RADIUS proxies and reduce | makes it possible to avoid aggregation-only RADIUS proxies and reduce | |||
the number of middleboxes which can eavesdrop on traffic. One | the number of middleboxes which can eavesdrop on traffic. One | |||
mechanism to discover RADIUS over TLS peers with DNS is specified in | mechanism to discover RADIUS over TLS peers with DNS is specified in | |||
[I-D.winter-dynamic-discovery]. | [I-D.ietf-radext-dynamic-discovery]. | |||
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", "NOT | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT | |||
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | |||
interpreted as described in RFC 2119. [RFC2119] | interpreted as described in RFC 2119. [RFC2119] | |||
1.2. Terminology | 1.2. Terminology | |||
skipping to change at page 9, line 19 | skipping to change at page 9, line 19 | |||
(2) If a RADIUS/TLS server is in possession of multiple certificates | (2) If a RADIUS/TLS server is in possession of multiple certificates | |||
from different CAs (i.e. is part of multiple roaming consortia), it | from different CAs (i.e. is part of multiple roaming consortia), it | |||
will need to select one of its certificates to present to the RADIUS/ | will need to select one of its certificates to present to the RADIUS/ | |||
TLS client. If the client sends the Trusted CA Indication, this hint | TLS client. If the client sends the Trusted CA Indication, this hint | |||
can make the server select the appropriate certificate and prevent a | can make the server select the appropriate certificate and prevent a | |||
handshake failure. Omitting this indication makes it impossible to | handshake failure. Omitting this indication makes it impossible to | |||
deterministically select the right certificate in this case. If | deterministically select the right certificate in this case. If | |||
there is no risk of confusing multiple roaming consortia, providing | there is no risk of confusing multiple roaming consortia, providing | |||
this indication in the handshake is not crucial. | this indication in the handshake is not crucial. | |||
(3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] | (3) If dynamic peer discovery as per | |||
is used, peer authentication alone is not sufficient; the peer must | [I-D.ietf-radext-dynamic-discovery] is used, peer authentication | |||
also be authorised to perform user authentications. In these cases, | alone is not sufficient; the peer must also be authorised to perform | |||
the trust fabric cannot depend on peer authentication methods like | user authentications. In these cases, the trust fabric cannot depend | |||
DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be | on peer authentication methods like DNSSEC to identify RADIUS/TLS | |||
properly authorised. Typically, this can be achieved by adding | nodes. The nodes also need to be properly authorised. Typically, | |||
appropriate authorisation fields into a X.509 certificate. Such | this can be achieved by adding appropriate authorisation fields into | |||
fields include SRV authority [RFC4985], subjectAltNames, or a defined | a X.509 certificate. Such fields include SRV authority [RFC4985], | |||
list of certificate fingerprints. Operators of a RADIUS/TLS | subjectAltNames, or a defined list of certificate fingerprints. | |||
infrastructure should define their own authorisation trust model and | Operators of a RADIUS/TLS infrastructure should define their own | |||
apply this model to the certificates. The checks enumerated in | authorisation trust model and apply this model to the certificates. | |||
Section 2.3 provide sufficient flexibility for the implementation of | The checks enumerated in Section 2.3 provide sufficient flexibility | |||
authorisation trust models. | for the implementation of authorisation trust models. | |||
3.2. Ciphersuites and Compression Negotiation Considerations | 3.2. Ciphersuites and Compression Negotiation Considerations | |||
Not all TLS ciphersuites in [RFC5246] are supported by available TLS | Not all TLS ciphersuites in [RFC5246] are supported by available TLS | |||
tool kits, and licenses may be required in some cases. The existing | tool kits, and licenses may be required in some cases. The existing | |||
implementations of RADIUS/TLS use OpenSSL as cryptographic backend, | implementations of RADIUS/TLS use OpenSSL as cryptographic backend, | |||
which supports all of the ciphersuites listed in the rules in the | which supports all of the ciphersuites listed in the rules in the | |||
normative section. | normative section. | |||
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- | The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- | |||
skipping to change at page 12, line 8 | skipping to change at page 12, line 8 | |||
6. Security Considerations | 6. Security Considerations | |||
The computational resources to establish a TLS tunnel are | The computational resources to establish a TLS tunnel are | |||
significantly higher than simply sending mostly unencrypted UDP | significantly higher than simply sending mostly unencrypted UDP | |||
datagrams. Therefore, clients connecting to a RADIUS/TLS node will | datagrams. Therefore, clients connecting to a RADIUS/TLS node will | |||
more easily create high load conditions and a malicious client might | more easily create high load conditions and a malicious client might | |||
create a Denial-of-Service attack more easily. | create a Denial-of-Service attack more easily. | |||
In the case of dynamic peer discovery as per | In the case of dynamic peer discovery as per | |||
[I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to | [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be | |||
accept connections from a large, not previously known, group of | able to accept connections from a large, not previously known, group | |||
hosts, possibly the whole internet. In this case, the server's | of hosts, possibly the whole internet. In this case, the server's | |||
RADIUS/TLS port can not be protected from unauthorised connection | RADIUS/TLS 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 as per | In the case of dynamic peer discovery as per | |||
[I-D.winter-dynamic-discovery], X.509 certificates are the only proof | [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only | |||
of authorisation for a connecting RADIUS/TLS nodes. Special care | proof of authorisation for a connecting RADIUS/TLS nodes. Special | |||
needs to be taken that certificates get verified properly according | care needs to be taken that certificates get verified properly | |||
to the chosen trust model (particularly: consulting CRLs, checking | according to the chosen trust model (particularly: consulting CRLs, | |||
critical extensions, checking subjectAltNames etc.) to prevent | checking critical extensions, checking subjectAltNames etc.) to | |||
unauthorised connections. | 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 to the well-known term "radsec" (see Section 2.3 (4) ) , | |||
expose the entire datagram payload in plain text, including User- | failure to comply with this requirement will expose the entire | |||
Password, to intermediate IP nodes. | datagram payload in plain text, including User-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 | |||
RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic | RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic | |||
RADIUS security opens the way for a down-bidding attack if an | RADIUS security opens the way for a down-bidding attack if an | |||
adversary can maliciously close the TCP connection, or prevent it | adversary can maliciously close the TCP connection, or prevent it | |||
from being established. In this case, security of the packet payload | from being established. In this case, security of the packet payload | |||
is reduced from the selected TLS cipher suite packet encryption to | is reduced from the selected TLS cipher suite packet encryption to | |||
the classic MD5 per-attribute encryption. Such an attack can be | the classic MD5 per-attribute encryption. Such an attack can be | |||
mitigated by delisting the RADIUS/UDP client from the server | mitigated by delisting the RADIUS/UDP client from the server | |||
configuration after successfully migrating that client to RADIUS/TLS. | configuration after successfully migrating that client to RADIUS/TLS. | |||
skipping to change at page 13, line 26 | skipping to change at page 13, line 26 | |||
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]. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in | [RFC2119] Bradner, S., "Key words for use | |||
RFCs to Indicate Requirement | in 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., | [RFC2865] Rigney, C., Willens, S., Rubens, | |||
and W. Simpson, "Remote | A., and W. Simpson, "Remote | |||
Authentication Dial In User Service | Authentication Dial In User | |||
(RADIUS)", RFC 2865, June 2000. | Service (RADIUS)", RFC 2865, | |||
June 2000. | ||||
[RFC2866] Rigney, C., "RADIUS Accounting", | [RFC2866] Rigney, C., "RADIUS Accounting", | |||
RFC 2866, June 2000. | RFC 2866, June 2000. | |||
[RFC4279] Eronen, P. and H. Tschofenig, "Pre- | [RFC4279] Eronen, P. and H. Tschofenig, | |||
Shared Key Ciphersuites for | "Pre-Shared Key Ciphersuites for | |||
Transport Layer Security (TLS)", | Transport Layer Security (TLS)", | |||
RFC 4279, December 2005. | RFC 4279, December 2005. | |||
[RFC4785] Blumenthal, U. and P. Goel, "Pre- | [RFC4785] Blumenthal, U. and P. Goel, | |||
Shared Key (PSK) Ciphersuites with | "Pre-Shared Key (PSK) | |||
NULL Encryption for Transport Layer | Ciphersuites with NULL | |||
Security (TLS)", RFC 4785, | Encryption for Transport Layer | |||
January 2007. | Security (TLS)", RFC 4785, | |||
January 2007. | ||||
[RFC4985] Santesson, S., "Internet X.509 | [RFC4985] Santesson, S., "Internet X.509 | |||
Public Key Infrastructure Subject | Public Key Infrastructure | |||
Alternative Name for Expression of | Subject Alternative Name for | |||
Service Name", RFC 4985, | Expression of Service Name", | |||
August 2007. | RFC 4985, August 2007. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, | [RFC5280] Cooper, D., Santesson, S., | |||
S., Boeyen, S., Housley, R., and W. | Farrell, S., Boeyen, S., | |||
Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, | |||
Infrastructure Certificate and | "Internet X.509 Public Key | |||
Certificate Revocation List (CRL) | Infrastructure Certificate and | |||
Profile", RFC 5280, May 2008. | Certificate Revocation List | |||
(CRL) Profile", RFC 5280, | ||||
May 2008. | ||||
[RFC5176] Chiba, M., Dommety, G., Eklund, M., | [RFC5176] Chiba, M., Dommety, G., Eklund, | |||
Mitton, D., and B. Aboba, "Dynamic | M., Mitton, D., and B. Aboba, | |||
Authorization Extensions to Remote | "Dynamic Authorization | |||
Authentication Dial In User Service | Extensions to Remote | |||
(RADIUS)", RFC 5176, January 2008. | Authentication Dial In User | |||
Service (RADIUS)", RFC 5176, | ||||
January 2008. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The | [RFC5246] Dierks, T. and E. Rescorla, "The | |||
Transport Layer Security (TLS) | Transport Layer Security (TLS) | |||
Protocol Version 1.2", RFC 5246, | Protocol Version 1.2", RFC 5246, | |||
August 2008. | August 2008. | |||
[RFC5247] Aboba, B., Simon, D., and P. Eronen, | [RFC5247] Aboba, B., Simon, D., and P. | |||
"Extensible Authentication Protocol | Eronen, "Extensible | |||
(EAP) Key Management Framework", | Authentication Protocol (EAP) | |||
RFC 5247, August 2008. | Key Management Framework", | |||
RFC 5247, August 2008. | ||||
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", | [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr | |||
draft-ietf-radext-tcp-transport-09 | aft-ietf-radext-tcp-transport-09 | |||
(work in progress), October 2010. | (work in progress), | |||
October 2010. | ||||
9.2. Informative References | 9.2. Informative References | |||
[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport | [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport | |||
Layer for RADIUS", | Layer for RADIUS", | |||
draft-ietf-radext-dtls-01 (work in | draft-ietf-radext-dtls-01 (work | |||
progress), October 2010. | in progress), October 2010. | |||
[I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI- | [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, | |||
based Dynamic Peer Discovery for | "NAI-based Dynamic Peer | |||
RADIUS over TLS and DTLS", | Discovery for RADIUS/TLS and | |||
draft-winter-dynamic-discovery-00 | RADIUS/DTLS", draft-ietf-radext- | |||
(work in progress), February 2009. | dynamic-discovery-03 (work in | |||
progress), July 2011. | ||||
[RFC3588] Calhoun, P., Loughney, J., Guttman, | [RFC3588] Calhoun, P., Loughney, J., | |||
E., Zorn, G., and J. Arkko, | Guttman, E., Zorn, G., and J. | |||
"Diameter Base Protocol", RFC 3588, | Arkko, "Diameter Base Protocol", | |||
September 2003. | RFC 3588, September 2003. | |||
[RFC4346] Dierks, T. and E. Rescorla, "The | [RFC4346] Dierks, T. and E. Rescorla, "The | |||
Transport Layer Security (TLS) | Transport Layer Security (TLS) | |||
Protocol Version 1.1", RFC 4346, | Protocol Version 1.1", RFC 4346, | |||
April 2006. | April 2006. | |||
[radsec-whitepaper] Open System Consultants, "RadSec - a | [radsec-whitepaper] Open System Consultants, "RadSec | |||
secure, reliable RADIUS Protocol", | - a secure, reliable RADIUS | |||
May 2005, <http://www.open.com.au/ | Protocol", May 2005, <http:// | |||
radiator/radsec-whitepaper.pdf>. | www.open.com.au/radiator/ | |||
radsec-whitepaper.pdf>. | ||||
[MD5-attacks] Black, J., Cochran, M., and T. | [MD5-attacks] Black, J., Cochran, M., and T. | |||
Highland, "A Study of the MD5 | Highland, "A Study of the MD5 | |||
Attacks: Insights and Improvements", | Attacks: Insights and | |||
October 2006, <http:// | Improvements", October 2006, <ht | |||
www.springerlink.com/content/ | tp://www.springerlink.com/ | |||
40867l85727r7084/>. | content/40867l85727r7084/>. | |||
[radsecproxy-impl] Venaas, S., "radsecproxy Project | [radsecproxy-impl] Venaas, S., "radsecproxy Project | |||
Homepage", 2007, <http:// | Homepage", 2007, <http:// | |||
software.uninett.no/radsecproxy/>. | software.uninett.no/ | |||
radsecproxy/>. | ||||
[eduroam] Trans-European Research and | [eduroam] Trans-European Research and | |||
Education Networking Association, | Education Networking | |||
"eduroam Homepage", 2007, | Association, "eduroam Homepage", | |||
<http://www.eduroam.org/>. | 2007, <http://www.eduroam.org/>. | |||
[geant2] Delivery of Advanced Network | [geant2] Delivery of Advanced Network | |||
Technology to Europe, "European | Technology to Europe, "European | |||
Commission Information Society and | Commission Information Society | |||
Media: GEANT2", 2008, | and Media: GEANT2", 2008, | |||
<http://www.geant2.net/>. | <http://www.geant2.net/>. | |||
[terena] TERENA, "Trans-European Research and | [terena] TERENA, "Trans-European Research | |||
Education Networking Association", | and Education Networking | |||
2008, <http://www.terena.org/>. | Association", 2008, | |||
<http://www.terena.org/>. | ||||
Appendix A. Implementation Overview: Radiator | Appendix A. 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. | |||
End of changes. 32 change blocks. | ||||
122 lines changed or deleted | 135 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |