draft-ietf-radext-radsec-07.txt   draft-ietf-radext-radsec-08.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 13, 2011 OSC Expires: September 15, 2011 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
July 12, 2010 March 14, 2011
TLS encryption for RADIUS TLS encryption for RADIUS
draft-ietf-radext-radsec-07 draft-ietf-radext-radsec-08
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 13, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 25 skipping to change at page 2, line 25
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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/TCP . . . . . . 4
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8
3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.2. Ciphersuites and Compression Negotiation Considerations . 9
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9
4. Compatibility with other RADIUS transports . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 14 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 15 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16
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 51 skipping to change at page 3, line 51
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.winter-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", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
and "OPTIONAL" in this document are to be interpreted as described in RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
RFC 2119. [RFC2119] interpreted as described in RFC 2119. [RFC2119]
1.2. Terminology 1.2. Terminology
RADIUS/TLS node: a RADIUS over TLS client or server RADIUS/TLS node: a RADIUS over TLS client or server
RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new
connection. connection.
RADIUS/TLS Server: a RADIUS over TLS instance which listens on a RADIUS/TLS Server: a RADIUS over TLS instance which listens on a
RADIUS over TLS port and accepts new connections RADIUS over TLS port and accepts new connections
RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]
2. Normative: Transport Layer Security for RADIUS over TCP 2. Normative: Transport Layer Security for RADIUS/TCP
2.1. TCP port and packet types 2.1. TCP port and packet types
The default destination port number for RADIUS over TLS is TCP/2083. The default destination port number for RADIUS over TLS is TCP/2083.
There are no separate ports for authentication, accounting and There are no separate ports for authentication, accounting and
dynamic authorisation changes. The source port is arbitrary. dynamic authorisation changes. The source port is arbitrary. See
section Section 3.3 (4) and (5) for considerations regarding
separation of authentication, accounting and dynauth traffic.
2.2. TLS negotiation 2.2. TLS negotiation
RADIUS has no notion of negotiating TLS in an established connection. RADIUS/TLS has no notion of negotiating TLS in an established
Servers and clients need to be preconfigured to use RADIUS/TLS for a connection. Servers and clients need to be preconfigured to use
given endpoint. RADIUS/TLS for a given endpoint.
2.3. Connection Setup 2.3. Connection Setup
RADIUS/TLS nodes RADIUS/TLS nodes
1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport].
Failure to connect leads to continuous retries, with
exponentially growing intervals between every try. If multiple
servers are defined, the node MAY attempt to establish a
connection to these other servers in parallel, in order to
implement quick failover.
2. immediately negotiate TLS sessions. The following restrictions 2. after completing the TCP handshake, immediately negotiate TLS
apply: according to [RFC5246] or its predecessor TLS 1.1. The sessions. The following restrictions apply: according to
following restrictions apply: [RFC5246] or its predecessor TLS 1.1. The following restrictions
apply:
* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2
[RFC5246]]) is REQUIRED. [RFC5246] ]) is REQUIRED.
* Support for certificate-based mutual authentication is * Support for certificate-based mutual authentication is
REQUIRED. REQUIRED.
* Negotiation of mutual authentication is REQUIRED. * Negotiation of mutual authentication is REQUIRED.
* Negotiation of a ciphersuite providing for confidentiality as * Negotiation of a ciphersuite providing for confidentiality as
well as integrity protection is REQUIRED. well as integrity protection is REQUIRED.
* Support for and negotiation of compression is OPTIONAL. * Support for and negotiation of compression is OPTIONAL.
skipping to change at page 5, line 19 skipping to change at page 5, line 27
* RADIUS/TLS implementations MUST at a minimum support * RADIUS/TLS implementations MUST at a minimum support
negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD
support TLS_RSA_WITH_RC4_128_SHA and support TLS_RSA_WITH_RC4_128_SHA and
TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ).
* In addition, RADIUS/TLS implementations MUST support * In addition, RADIUS/TLS implementations MUST support
negotiation of the mandatory-to-implement ciphersuites negotiation of the mandatory-to-implement ciphersuites
required by the versions of TLS that they support. required by the versions of TLS that they support.
* RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL
encryption (e.g. [RFC4785]).
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]. per [RFC5280].
* Implementations SHOULD indicate their acceptable Certification * Implementations SHOULD indicate their acceptable Certification
skipping to change at page 6, line 15 skipping to change at page 6, line 26
* Implementations SHOULD allow to configure a set of acceptable * Implementations SHOULD allow to configure a set of acceptable
values for subjectAltName:URI. values for subjectAltName:URI.
4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The
shared secret to compute the (obsolete) MD5 integrity checks and shared secret to compute the (obsolete) MD5 integrity checks and
attribute encryption MUST be "radsec" (see Section 3.3 (2) ). attribute encryption MUST be "radsec" (see Section 3.3 (2) ).
2.4. Connecting Client Identity 2.4. Connecting Client Identity
In RADIUS/UDP, clients are uniquely identified by their IP address. In RADIUS/UDP, clients are uniquely identified by their IP address.
The IP address alone does not permit the server to determine whether Since the shared secret is associated with the origin IP address, if
the connecting entity is a NAS or a different server which proxies a more than one RADIUS client is associated with the same IP address,
request. When NAT is used on the path to the server, it also does then those clients also must utilize the same shared secret, a
not permit to determine whether there is more than one entity practice which is inherently insecure as noted in [RFC5247]..
connecting from the same IP address.
RADIUS/TLS makes it possible to preserve this traditional RADIUS RADIUS/TLS makes it possible to preserve this traditional RADIUS
semantics by identifying a connecting client by the IP address which semantics by identifying a connecting client by the IP address which
initiated the TLS connection. In addition, it permits a much more initiated the TLS connection. In addition, it permits a much more
fine-grained identification. The parameters of the TLS connection fine-grained identification. The parameters of the TLS connection
can be attributed to the RADIUS packets inside the TLS connection. can be attributed to the RADIUS packets inside the TLS connection.
An implementation of RADIUS/TLS should expose as many details of the An implementation of RADIUS/TLS should expose as many details of the
TLS connection which belongs to an incoming RADIUS packet as possible TLS connection which belongs to an incoming RADIUS packet as possible
to the application layer to allow the administrator to define the to the application layer to allow the administrator to define the
identification criteria which are applicable to his desired identification criteria which are applicable to his desired
skipping to change at page 9, line 44 skipping to change at page 10, line 7
(1) After the TLS session is established, RADIUS packet payloads are (1) After the TLS session is established, RADIUS packet payloads are
exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet
size can be determined by evaluating the size of the datagram that size can be determined by evaluating the size of the datagram that
arrived. Due to the stream nature of TCP and TLS, this does not hold arrived. Due to the stream nature of TCP and TLS, this does not hold
true for RADIUS/TLS packet exchange. Instead, packet boundaries of true for RADIUS/TLS packet exchange. Instead, packet boundaries of
RADIUS packets that arrive in the stream are calculated by evaluating RADIUS packets that arrive in the stream are calculated by evaluating
the packet's Length field. Special care needs to be taken on the the packet's Length field. Special care needs to be taken on the
packet sender side that the value of the Length field is indeed packet sender side that the value of the Length field is indeed
correct before sending it over the TLS tunnel, because incorrect correct before sending it over the TLS tunnel, because incorrect
packet lengths can no longer be detected by a differing datagram packet lengths can no longer be detected by a differing datagram
boundary. See section 2.6.4 of [I-D.dekok-radext-tcp-transport] for boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for
more details. more details.
(2) Within RADIUS [RFC2865], a shared secret is used for hiding (2) Within RADIUS [RFC2865], a shared secret is used for hiding
of attributes such as User-Password, as well as in computation of of attributes such as User-Password, as well as in computation of
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
skipping to change at page 10, line 28 skipping to change at page 10, line 39
(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 RADIUS/TLS These packet types are listed as to be received in RADIUS/TLS
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.
(5) RADIUS [RFC2865] used negative ICMP responses to a newly
allocated UDP port to signal that a peer RADIUS server does not
support reception and processing of RADIUS Accounting packets. There
is no RADIUS datagram to signal an Accounting NAK. Clients may be
misconfigured to send Accounting packets to a RADIUS/TLS server which
does not wish to process their Accounting packet. The server will
need to silently drop the packet. The client will need to deduce
from the absence of replies that it is misconfigured; no negative
ICMP response will reveal this.
4. Compatibility with other RADIUS transports 4. Compatibility with other RADIUS transports
Ongoing work in the IETF defines multiple alternative transports to Ongoing work in the IETF defines multiple alternative transports to
the classic UDP transport model as defined in [RFC2865], namely the classic UDP transport model as defined in [RFC2865], namely
RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS
[I-D.dekok-radext-dtls] and this present document on RADIUS over TLS. [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS.
RADIUS/TLS does not specify any inherent backwards compatibility to RADIUS/TLS does not specify any inherent backwards compatibility to
RADIUS/UDP or cross compatibility to the other transports, i.e. an RADIUS/UDP or cross compatibility to the other transports, i.e. an
implementation which implements RADIUS/TLS only will not be able to implementation which implements RADIUS/TLS only will not be able to
receive or send RADIUS packet payloads over other transports. An receive or send RADIUS packet payloads over other transports. An
implementation wishing to be backward or cross compatible (i.e. implementation wishing to be backward or cross compatible (i.e.
wishes to serve clients using other transports than RADIUS/TLS) will wishes to serve clients using other transports than RADIUS/TLS) will
need to implement these other transports along with the RADIUS/TLS need to implement these other transports along with the RADIUS/TLS
transport and be prepared to send and receive on all implemented transport and be prepared to send and receive on all implemented
transports, which is called a multi-stack implementation. transports, which is called a multi-stack implementation.
skipping to change at page 11, line 15 skipping to change at page 11, line 40
As a consequence, the selection of transports to communicate from a As a consequence, the selection of transports to communicate from a
client to a server is a manual administrative action. An automatic client to a server is a manual administrative action. An automatic
fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
bidding attacks on the peer communication. bidding attacks on the peer communication.
5. Diameter Compatibility 5. Diameter Compatibility
Since RADIUS/TLS is only a new transport profile for RADIUS, Since RADIUS/TLS is only a new transport profile for RADIUS,
compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP
[RFC2865] - Diameter [RFC3588] is identical. The considerations [RFC2865] - Diameter [RFC3588] is identical. The considerations
regarding payload size in [I-D.dekok-radext-tcp-transport] apply. regarding payload size in [I-D.ietf-radext-tcp-transport] apply.
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
skipping to change at page 12, line 28 skipping to change at page 13, line 7
TLS. 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, an early implementation of previously assigned by IANA for RadSec, an early implementation of
RADIUS/TLS. No new RADIUS attributes or packet codes are defined. RADIUS/TLS. No new RADIUS attributes or packet codes are defined.
8. Acknowledgements 8. Acknowledgements
RADIUS over TLS was first implemented as "RADSec" by Open Systems RADIUS/TLS was first implemented as "RADSec" by Open Systems
Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS
server product (see [radsec-whitepaper]). server 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].
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 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, [RFC2865] Rigney, C., Willens, S., Rubens, A.,
A., and W. Simpson, "Remote 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.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre- [RFC4279] Eronen, P. and H. Tschofenig, "Pre-
Shared Key Ciphersuites for Shared Key Ciphersuites for
Transport Layer Security (TLS)", Transport Layer Security (TLS)",
RFC 4279, December 2005. RFC 4279, December 2005.
[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.
[RFC4985] Santesson, S., "Internet X.509 [RFC4785] Blumenthal, U. and P. Goel, "Pre-
Public Key Infrastructure Subject Shared Key (PSK) Ciphersuites with
Alternative Name for Expression of NULL Encryption for Transport Layer
Service Name", RFC 4985, Security (TLS)", RFC 4785,
August 2007. January 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, [RFC4985] Santesson, S., "Internet X.509
S., Boeyen, S., Housley, R., and W. Public Key Infrastructure Subject
Polk, "Internet X.509 Public Key Alternative Name for Expression of
Infrastructure Certificate and Service Name", RFC 4985,
Certificate Revocation List (CRL) August 2007.
Profile", RFC 5280, May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., [RFC5280] Cooper, D., Santesson, S., Farrell,
Mitton, D., and B. Aboba, "Dynamic S., Boeyen, S., Housley, R., and W.
Authorization Extensions to Remote Polk, "Internet X.509 Public Key
Authentication Dial In User Service Infrastructure Certificate and
(RADIUS)", RFC 5176, January 2008. Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The [RFC5176] Chiba, M., Dommety, G., Eklund, M.,
Transport Layer Security (TLS) Mitton, D., and B. Aboba, "Dynamic
Protocol Version 1.2", RFC 5246, Authorization Extensions to Remote
August 2008. Authentication Dial In User Service
(RADIUS)", RFC 5176, January 2008.
[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", draft [RFC5246] Dierks, T. and E. Rescorla, "The
-ietf-dekok-radext-tcp-transport-08 Transport Layer Security (TLS)
(work in progress), July 2010. Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen,
"Extensible Authentication Protocol
(EAP) Key Management Framework",
RFC 5247, August 2008.
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",
draft-ietf-radext-tcp-transport-09
(work in progress), October 2010.
9.2. Informative References 9.2. Informative References
[I-D.dekok-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-dekok-radext-dtls-02 (work in draft-ietf-radext-dtls-01 (work in
progress), March 2010. progress), October 2010.
[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
draft-winter-dynamic-discovery-00 RADIUS over TLS and DTLS",
(work in progress), February 2009. draft-winter-dynamic-discovery-00
(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
a secure, reliable RADIUS secure, reliable RADIUS Protocol",
Protocol", May 2005, <http:// May 2005, <http://www.open.com.au/
www.open.com.au/radiator/ radiator/radsec-whitepaper.pdf>.
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 Attacks: Insights and Improvements",
Improvements", October 2006, <http: October 2006, <http://
//www.springerlink.com/content/ www.springerlink.com/content/
40867l85727r7084/>. 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 Association,
"eduroam Homepage", 2007, "eduroam Homepage", 2007,
<http://www.eduroam.org/>. <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 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
and Education Networking Education Networking Association",
Association", 2008, 2008, <http://www.terena.org/>.
<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. 41 change blocks. 
116 lines changed or deleted 146 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/