draft-ietf-radext-radsec-00.txt   draft-ietf-radext-radsec-01.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: December 19, 2008 OSC Expires: February 23, 2009 OSC
S. Venaas S. Venaas
UNINETT UNINETT
June 17, 2008 K. Wierenga
Cisco
August 22, 2008
TLS encryption for RADIUS over TCP (RadSec) TLS encryption for RADIUS over TCP (RadSec)
draft-ietf-radext-radsec-00 draft-ietf-radext-radsec-01
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 37 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 December 19, 2008. This Internet-Draft will expire on February 23, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 [2] when transmitted over TCP [9]. This enables RADIUS protocol [RFC2865] when transmitted over TCP
dynamic trust relationships between RADIUS servers. [I-D.dekok-radext-tcp-transport]. This enables dynamic trust
relationships between RADIUS servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Transport Layer Security . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4
2.2. Ciphersuites and Compression Negotiation . . . . . . . . . 6 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
2.3. RADIUS Shared Secret Usage in RadSec . . . . . . . . . . . 6 2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
3. Comparison of Diameter vs. RadSec . . . . . . . . . . . . . . 7 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5
4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 7 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3.2. Ciphersuites and Compression Negotiation Considerations . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9
8.1. Informative References . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.2. Normative References . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Implementation Overview: Radiator . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix C. Implementation Overview: radsecproxy . . . . . . . . 12 8.1. Informative References . . . . . . . . . . . . . . . . . . 10
8.2. Normative References . . . . . . . . . . . . . . . . . . . 11
Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12
Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13
Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14
1. Introduction 1. Introduction
The RADIUS protocol [2] 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 [3] 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. its packet payload. RADIUS security is based on the MD5 algorithm,
which has been proven to be insecure.
Several enhancements have been proposed to overcome RADIUS'
limitations. An IETF Standards Track protocol, Diameter [6], has
been designed to provide an AAA protocol that should deprecate
RADIUS. However, given that current implementations of Diameter are
either not freely accessible, or do not provide the flexibility of
current RADIUS deployments, or both, an intermediate solution that is
based on RADIUS but provides mechanisms to overcome many of its
drawbacks has been implemented by several vendors. These
implementations are interoperable and deployed in a world-wide
wireless roaming infrastructure. The protocol is called RadSec.
This document describes version 2 of the RadSec protocol. Version 1
of RadSec is defined in the RadSec whitepaper [10]. The two
currently existing implementations of RadSec version 2 are described
in Appendix B and Appendix C.
The main focus of RadSec is to provide a means to secure the The main focus of RadSec is to provide a means to secure the
communication between RADIUS/TCP peers on the transport layer. The communication between RADIUS/TCP peers on the transport layer. The
most important use of RadSec lies in roaming environments where most important use of RadSec lies in roaming environments where
RADIUS packets need to be transferred through different RADIUS packets need to be transferred through different
administrative domains and untrusted, potentially hostile networks. administrative domains and untrusted, potentially hostile networks.
An example for a world-wide roaming environment that uses RadSec to An example for a world-wide roaming environment that uses RadSec to
secure communication is "eduroam", see [15]. secure communication is "eduroam", see [eduroam].
The new features in RadSec obsolete the use of IP addresses and
shared secrets to identify other peers and thus allow the dynamic
establishment of connections to peers that are not previously
configured. The definition of lookup mechanisms is out of scope of
this document, but an implementation of a DNS NAPTR lookup based
mechanism exists and is described as an example lookup mechanism in
Appendix A.
Transitioning from a plain RADIUS infrastructure to a RadSec There are multiple known attacks on the MD5 algorithm which is used
infrastructure is very easy, since the RADIUS packet payload is in RADIUS to provide integrity protection and a limited
identical in both protocols. Enabling RadSec can be done on a per- confidentiality protection. RadSec wraps the entire RADIUS packet
server basis. Unlike in Diameter, the learning curve for a new payload into a TLS stream and thus mitigates the risk of attacks on
protocol does not exist, which makes it almost trivial for an MD5.
experienced RADIUS server administrator to switch to a RadSec-secured
transport for RADIUS packets.
The security layer does not require any new assignments of codepoints Because of the static trust establishment between RADIUS peers (IP
for the RADIUS protocol. No new attributes are defined and no new address and shared secret) the only scalable way of creating a
packet codes are used. massive deployment of RADIUS-servers under control by different
administrative entities is to introduce some form of a proxy chain to
route the access requests to their home server. This creates a lot
of overhead in terms of possible points of failure, longer
transmission times as well as middleboxes through which
authentication traffic flows. These middleboxes may learn privacy-
relevant data while forwarding requests. The new features in RadSec
obsolete the use of IP addresses and shared MD5 secrets to identify
other peers and thus allow the dynamic establishment of connections
to peers that are not previously configured, and thus makes it
possible to avoid intermediate aggregation proxies. The definition
of lookup mechanisms is out of scope of this document, but an
implementation of a DNS NAPTR lookup based mechanism exists and is
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
[1]. [RFC2119].
2. Transport Layer Security 1.2. Terminology
2.1. Operation RadSec node: a RadSec client or server
Once the TCP connection between two RadSec nodes is established, a RadSec Client: a RadSec instance which initiates a new connection.
TLS session is established. At least TLSv1.1 [7] is used. Both
nodes either mutually present a X.509 certificate which is verified
according to [5] or use a shared key authentication for TLS which
needs to be pre-configured out-of-band prior to the connection
attempt.
The list of Certification Authorities that a node which acts as a RadSec Server: a RadSec instance which listens on a RadSec port and
server is willing to accept SHOULD be sent during the Certificate accepts new connections
Request message in the CertificateRequest struct (section 7.4.4 of
[7]). Rationale: If a RadSec node acts as a client and is in
possession of multiple certificates from different CAs (i.e. is part
of multiple roaming consortia) and dynamic discovery is used, and the
dynamic discovery mechanism does not provide sufficient meta
information to identify the server's roaming consortium, then it is
necessary to signal which consortium it is connecting to.
The list of Certification Authorities that a node which acts as a 2. Normative: Transport Layer Security for RADIUS over TCP
client is willing to accept can not be signaled within the TLS 1.1
handshake. This makes it impossible to select the right certificate
if a RadSec node which is acting as a server for multiple roaming
consortia (in possession of multiple certificates from different CAs)
is contacted by a client. This situation is likely to change in TLS
1.2, according to [8]. "Trusted CA Indication" as in [8], section 6,
SHOULD be used.
When using X.509 certificate validation, peer validation always 2.1. TCP port and packet types
The default destination port number for RadSec is TCP/2083. There
are no separate ports for authentication, accounting and dynamic
authorisation changes. The source port is arbitrary.
2.2. Connection Setup
RadSec nodes
1. establish TCP connections as per [I-D.dekok-radext-tcp-transport]
2. negotiate TLS sessions according to [RFC5246] or its predecessor
TLS 1.1. The following restrictions apply:
* When using X.509 certificates, RadSec servers SHOULD indicate
their acceptable Certification Authorities as per section
7.4.4 of [RFC5246] (see Section 3.1 (1) )
* When using X.509 certificates, the TLS Extension "Trusted CA
Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD
be used to indicate trusted CAs for the client (see
Section 3.1 (2) )
* When using X.509 certificates, certificate validation is
performed as per [RFC5280] or its TLS 1.1 predecessor. The
client MAY perform additional checks to accomodate for
different trust models.
* The client MUST NOT negotiate cipher suites which only provide
integrity protection.
* The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
supported.
* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
(1) )
3. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The
shared secret to compute the (obsolete) MD5 integrity checks and
attribute encryption MUST be "radsec" (see Section 3.3 (2) ).
2.3. RADIUS Datagrams
Authentication, Accounting and Authorization packets are sent
according to the following rules:
RadSec clients handle the following packet types from [RFC2865],
[RFC2866], [RFC5176] on the connection they initiated (see
Section 3.3 (3) and (4) ):
o send Access-Request
o send Accounting-Request
o send Status-Server
o send Disconnect-ACK
o send Disconnect-NAK
o send CoA-ACK
o send CoA-NAK
o receive Access-Challenge
o receive Access-Accept
o receive Access-Reject
o receive Accounting-Response
o receive Disconnect-Request
o receive CoA-Request
RadSec servers handle the following packet types from [RFC2865],
[RFC2866], [RFC5176] on the connections they serve to clients:
o receive Access-Request
o receive Accounting-Request
o receive Status-Server
o receive Disconnect-ACK
o receive Disconnect-NAK
o receive CoA-ACK
o receive CoA-NAK
o send Access-Challenge
o send Access-Accept
o send Access-Reject
o send Accounting-Response
o send Disconnect-Request
o send CoA-Request
3. Informative: Design Decisions
This section explains the design decisions that led to the rules
defined in the previous section.
3.1. X.509 Certificate Considerations
(1) If a RadSec client is in possession of multiple certificates from
different CAs (i.e. is part of multiple roaming consortia) and
dynamic discovery is used, the discovery mechanism possibly does not
yield sufficient information to identify the consortium uniquely
(e.g. DNS discovery). Subsequently, the client may not know by
itself which client certificate to use for the TLS handshake. Then
it is necessary to for the server to signal which consortium it
belongs to, and which certificates it expects. If there is no risk
of confusing multiple roaming consortia, providing this information
in the handshake is not crucial.
(2) If a RadSec server is in possession of multiple certificates from
different CAs (i.e. is part of multiple roaming consortia), it will
need to select one of its certificates to present to the RadSec
client. If the client sends the Trusted CA Indication, this hint can
make the server select the appropriate certificate and prevent a
handshake failure. Omitting this indication makes it impossible to
deterministically select the right certificate in this case. If
there is no risk of confusing multiple roaming consortia, providing
this indication in the handshake is not crucial.
(3) When using X.509 certificate validation, peer validation always
includes a check on whether the DNS name or the IP address of the includes a check on whether the DNS name or the IP address of the
server that is contacted matches its certificate. When a RadSec peer server that is contacted matches its certificate. When a RadSec peer
establishes a new connection (acts as a client) to another peer, the establishes a new connection (acts as a client) to another peer, the
following rules of precedence are used during validation: following rules of precedence are used during validation:
o If the client expects a certain fully qualified domain name (FQDN) o If the client expects a certain fully qualified domain name (FQDN)
and the presented certificate contains both at least one instance and the presented certificate contains both at least one instance
of the subjectAltName field with type dNSName and a Common Name, of the subjectAltName field with type dNSName and a Common Name,
then the certificate is considered a match if any one of those then the certificate is considered a match if any one of those
subjectAltName fields matches the expected FQDN. The Common Name subjectAltName fields matches the expected FQDN. The Common Name
skipping to change at page 5, line 11 skipping to change at page 7, line 20
server that is contacted matches its certificate. When a RadSec peer server that is contacted matches its certificate. When a RadSec peer
establishes a new connection (acts as a client) to another peer, the establishes a new connection (acts as a client) to another peer, the
following rules of precedence are used during validation: following rules of precedence are used during validation:
o If the client expects a certain fully qualified domain name (FQDN) o If the client expects a certain fully qualified domain name (FQDN)
and the presented certificate contains both at least one instance and the presented certificate contains both at least one instance
of the subjectAltName field with type dNSName and a Common Name, of the subjectAltName field with type dNSName and a Common Name,
then the certificate is considered a match if any one of those then the certificate is considered a match if any one of those
subjectAltName fields matches the expected FQDN. The Common Name subjectAltName fields matches the expected FQDN. The Common Name
field is not evaluated in this case. field is not evaluated in this case.
o If the client expects a certain fully qualified domain name (FQDN) o If the client expects a certain fully qualified domain name (FQDN)
and the presented certificate does not contain any subjectAltName and the presented certificate does not contain any subjectAltName
field with type dNSName, then the certificate is considered a field with type dNSName, then the certificate is considered a
match if the Common Name field matches the expected FQDN. match if the Common Name field matches the expected FQDN.
o If the client expects a certain IP address and the presented o If the client expects a certain IP address and the presented
certificate contains both at least one instance of the certificate contains both at least one instance of the
subjectAltName field with type iPAddr and a Common Name, then the subjectAltName field with type iPAddr and a Common Name, then the
certificate is considered a match if any one of those certificate is considered a match if any one of those
subjectAltName fields matches the expected IP address. The Common subjectAltName fields matches the expected IP address. The Common
Name field is not evaluated in this case. Name field is not evaluated in this case.
o If the client expects a certain IP address and the presented o If the client expects a certain IP address and the presented
certificate does not contain any subjectAltName field with type certificate does not contain any subjectAltName field with type
iPAddr, then the certificate is considered a match if the Common iPAddr, then the certificate is considered a match if the Common
Name field matches the expected IP address. Name field matches the expected IP address.
Further restrictions on the certificate MAY be verified, depending on
the trust fabric of the peering agreement.
If dynamic peer resolution is used, the above verification steps MAY
not be sufficient to ensure that a connecting peer is authorised to
perform user authentications. In these cases, the trust fabric
SHOULD NOT depend on untrusted peer resolution methods like DNS to
identify and authorise nodes. Instead, the operators of the RadSec
infrastructure SHOULD define their own trust model and apply this
model to the certificates after they have passed the standard
validity checks above. Current RadSec implementations offer varying
degrees of versatility for defining criteria which certificates to
accept.
NOTE WELL: None of the current implementations provide configuration
options for using TLS with pre-shared keys. However, the underlying
libraries support it, so support for that should be implementable
easily.
After the TLS session is established, RADIUS packet payloads are (4) If dynamic peer resolution is used, the above verification steps
exchanged over the encrypted TLS tunnel. In plain RADIUS, the packet may not be sufficient to ensure that a connecting peer is authorised
size can be determined by evaluating the size of the datagram that to perform user authentications. In these cases, the trust fabric
arrived. Due to the stream nature of TCP and TLS, this does not hold cannot depend on peer authentication methods like DNSSEC to identify
true for RadSec packet exchange. Instead, packet boundaries of RadSec nodes. The RadSec nodes also need to be properly authorised.
RADIUS packets that arrive in the stream are calculated by evaluating Operators of a RadSec infrastructure should define their own
the packet's Length field. Special care MUST be taken on the packet authorisation trust model and apply this model to the certificates
sender side that the value of the Length field is indeed correct after they have passed the standard validity checks above. Current
before sending it over the TLS tunnel, because incorrect packet RadSec implementations offer varying degrees of versatility for
lengths can no longer be detected by a differing datagram boundary. defining criteria which certificates to accept.
2.2. Ciphersuites and Compression Negotiation 3.2. Ciphersuites and Compression Negotiation Considerations
RadSec implementations need not necessarily support all TLS RadSec implementations need not necessarily support all TLS
ciphersuites listed in [7]. Not all TLS ciphersuites are supported by ciphersuites listed in [RFC5246]. Not all TLS ciphersuites
available TLS tool kits and licenses may be required in some cases. are supported by available TLS tool kits and licenses may be required
The existing implementations of RadSec use OpenSSL as cryptographic in some cases. The existing implementations of RadSec use OpenSSL as
backend, which supports all of the ciphersuites listed in the rules cryptographic backend, which supports all of the ciphersuites listed
below: in the rules in the normative section.
To ensure interoperability, RadSec clients and servers MUST
support the TLS [7] mandatory-to-implement ciphersuite:
TLS_RSA_WITH_3DES_EDE_CBC_SHA.
In addition, RadSec servers SHOULD support and be able to
negotiate all of the following TLS ciphersuites:
o TLS_RSA_WITH_RC4_128_MD5
o TLS_RSA_WITH_RC4_128_SHA
o TLS_RSA_WITH_AES_128_CBC_SHA
In addition, RadSec clients SHOULD support the following
TLS ciphersuites [4]:
o TLS_RSA_WITH_AES_128_CBC_SHA
o TLS_RSA_WITH_RC4_128_SHA
Since TLS supports ciphersuite negotiation, peers completing the
TLS negotiation will also have selected a ciphersuite, which
includes encryption and hashing methods.
TLS also supports compression as well as ciphersuite
negotiation. During the RadSec conversation the client and server MAY
negotiate compression. However, a peer MUST continue the
conversation even if the other peer rejects compression.
2.3. RADIUS Shared Secret Usage in RadSec
Within RADIUS [2], a shared secret is used for hiding of attributes The TLS cphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
such as User-Password, as well as in computation of the Response implement according to [RFC5246] and thus has to be supported by
Authenticator. In RADIUS accounting [3], the shared secret is used RadSec nodes.
in computation of both the Request Authenticator and the Response
Authenticator.
Since in RADIUS a shared secret is used to provide confidentiality The two other ciphersuites in the normative section
as well as integrity protection and authentication, the use of TLS (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are
ciphers which encrypt the stream payload in RadSec can provide widely implemented in TLS toolkits and are considered good practice
security services sufficient to substitute for RADIUS application- to implement.
layer security. Therefore, where TLS ciphers that provide encryption
are used, it will not be necessary to configure a RADIUS shared
secret.
Then, the secret shared between two RadSec peers MAY not TLS also supports compression. Compression is an optional
be configured. In this case, the shared secret defaults to "radsec" feature. During the RadSec conversation the client and server may
(without the quotes). However, if the RadSec nodes negotiated a TLS negotiate compression, but must continue the conversation even if the
cipher that provides integrity assurance only, the connection MUST be other peer rejects compression.
configured with a non-default RADIUS shared secret.
3. Comparison of Diameter vs. RadSec 3.3. RADIUS Datagram Considerations
The feature set in the Diameter Base Protocol is almost a superset of (1) After the TLS session is established, RADIUS packet payloads are
the features present in RadSec. Sophisticated mechanisms for exchanged over the encrypted TLS tunnel. In plain RADIUS, the packet
keepalive, reliable transmission and payload security exist. The size can be determined by evaluating the size of the datagram that
reason for specifying a short-term intermediate solution as opposed arrived. Due to the stream nature of TCP and TLS, this does not hold
to using Diameter at the moment are the lack of suitable, publicly true for RadSec packet exchange. Instead, packet boundaries of
available and versatile implementations. RADIUS packets that arrive in the stream are calculated by evaluating
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
correct before sending it over the TLS tunnel, because incorrect
packet lengths can no longer be detected by a differing datagram
boundary.
Typically, RADIUS servers do not only support the RADIUS protocol (2) Within RADIUS [RFC2865], a shared secret is used for hiding
itself, but also provide interfaces to a wide variety of backends of attributes such as User-Password, as well as in computation of
(credential stores) to actually verify a user's credentials. In the Response Authenticator. In RADIUS accounting [RFC2866], the
highly heterogeneous environments like eduroam, where a lot of shared secret is used in computation of both the Request
different backends are in use by the participating home servers Authenticator and the Response Authenticator. Since TLS provides
(OpenLDAP, Novell eDirectory, ActiveDirectory, SQL databases or plain integrity protection and encryption sufficient to substitute for
text files, just to name a few), such versatility is a requirement. RADIUS application-layer security, it is not necessary to configure a
Current Diameter server implementations focus on the validation of a RADIUS shared secret. The use of a fixed string for the obsolete
small set of EAP methods (mostly EAP-SIM and EAP-TLS) and shared secret eliminates possible node misconfigurations.
consequently on a small set of backends to verify these credentials.
A further requirement in environments like eduroam is affordability. (3) RADIUS [RFC2865] uses different UDP ports for authentication,
Public institutions like schools and universities often face tight accounting and dynamic authorisation changes. RadSec allocates a
budgets, and so an open source implementation of Diameter would be single port for all RADIUS packet types. Also in RadSec, the notion
desirable (just as FreeRADIUS is for the RADIUS protocol). of a client which sends authentication requests and processes replies
Unfortunately, the few Open Source Software implementations of the associated with it's users' sessions and the notion of a server which
Diameter protocol like OpenDiameter [12] or JDiameter [13] only receives requests, processes them and sends the appropriate replies
provide a set of libraries, but no server at all. is to be preserved. The normative rules about acceptable packet
types for clients and servers mirror the packet flow behaviour from
RADIUS.
Diameter's ability to resolve peers dynamically is limited to using (4) RADIUS [RFC2865] used negative ICMP responses to a newly
either SLPv2 or DNS, whereas RadSec allows arbitrary peer resolution allocated UDP port to signal that a peer RADIUS server does not
mechanisms. This greater amount of flexibility can pay off in many support reception and processing of the packet types in [RFC5176].
roaming federations. In eduroam's case, a central SAML-based meta These packet types are listed as to be received in RadSec
data repository ("eduGAIN-MDS") is in place which is able to provide implementations. Note well: it is not required for an implementation
peer addresses. Using RadSec it is possible to resolve a peer's to actually process these packet types. It is sufficient that upon
address through such a meta data system, whereas with Diameter it is receiving such a packet, an unconditional NAK is sent back to
not possible to use this repository natively. indicate that the action is not supported.
4. Diameter Compatibility 4. Diameter Compatibility
Since RadSec is only a new transport profile for RADIUS, Since RadSec is only a new transport profile for RADIUS,
compatibility of RadSec - Diameter vs. RADIUS - Diameter is compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] -
identical. The considerations regarding payload size in [9] apply. Diameter [RFC3588] is identical. The considerations regarding
payload size in [I-D.dekok-radext-tcp-transport] apply.
5. Security Considerations 5. 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 RadSec node will more datagrams. Therefore, clients connecting to a RadSec node will more
easily create high load conditions and a malicious client might 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, 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).
Some TLS ciphersuites only provide integrity validation of their Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. When such ciphersuites are payload, and provide no encryption. This specification forbids the
negotiated in a RadSec TLS handshake, the only means of protecting use of such ciphersuites. Since the RADIUS payload's shared secret
sensitive payload contents is the RADIUS shared secret. If the is fixed and well-known, failure to comply with this requirement will
RADIUS shared secret is set to the default "radsec" and a non- expose the entire datagram payload in plain text, including User-
encrypting TLS ciphersuite is used, implementations should either Password, to intermediate IP nodes.
forbid transmitting payload over this connection completely or at
least issue a warning to whatever logging destination is configured
by the administrator.
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
previously assigned by IANA for RadSec. The Status-Server packet was previously assigned by IANA for RadSec. No new RADIUS attributes or
already assigned by IANA for [2]. packet codes are defined.
7. Acknowledgements 7. 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
product. 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" [16] provided by the European Commission co-funded project "GEANT2"
and further feedback was provided by the TERENA Task Force Mobility [geant2] and further feedback was provided by the TERENA Task Force
[17]. Mobility [terena].
8. References 8. References
8.1. Informative References 8.1. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in
Levels", RFC 2119, March 1997. RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
8.2. Normative References March 1997.
[2] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[3] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [radsec-whitepaper] Open System Consultants, "RadSec -
Transport Layer Security (TLS)", RFC 3268, June 2002. a secure, reliable RADIUS
Protocol", May 2005, <http://
www.open.com.au/radiator/
radsec-whitepaper.pdf>.
[5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, [radiator-manual] Open System Consultants, "Radiator
R., and T. Polk, "Internet X.509 Public Key Infrastructure Radius Server - Installation and
Certificate and Certificate Revocation List (CRL) Profile", Reference Manual", 2006, <http://
RFC 5280, May 2008. www.open.com.au/radiator/ref.html>.
[6] Calhoun, P., Laughney, J., Arkko, J., Guttman, E., and G. Zorn, [radsecproxy-impl] Venaas, S., "radsecproxy Project
"Diameter Base Protocol", RFC 3588, September 2003. Homepage", 2007, <http://
software.uninett.no/radsecproxy/>.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [eduroam] Trans-European Research and
Protocol Version 1.1", RFC 4346, April 2006. Education Networking Association,
"eduroam Homepage", 2007,
<http://www.eduroam.org/>.
[8] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: [geant2] Delivery of Advanced Network
Extension Definitions", February 2008, <http://www.ietf.org/ Technology to Europe, "European
internet-drafts/draft-ietf-tls-rfc4366-bis-02.txt>. Commission Information Society and
Media: GEANT2", 2008,
<http://www.geant2.net/>.
[9] Winter, S., "Reliable Transport Profile for RADIUS", July 2008, [terena] TERENA, "Trans-European Research
<http://www.ietf.org/internet-drafts/ and Education Networking
draft-ietf-radext-radius-tcp-00.txt>. Association", 2008,
<http://www.terena.org/>.
[10] Open System Consultants, "RadSec - a secure, reliable RADIUS 8.2. Normative References
Protocol", May 2005,
<http://www.open.com.au/radiator/radsec-whitepaper.pdf>.
[11] Open System Consultants, "Radiator Radius Server - Installation [RFC2865] Rigney, C., Willens, S., Rubens,
and Reference Manual", 2006, A., and W. Simpson, "Remote
<http://www.open.com.au/radiator/ref.html>. Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[12] Open Diameter Project, "Open Diameter", 2006, [RFC2866] Rigney, C., "RADIUS Accounting",
<http://www.opendiameter.org/>. RFC 2866, June 2000.
[13] Svenson, E., "JDiameter Project Homepage", 2006, [RFC5280] Cooper, D., Santesson, S., Farrell,
<https://jdiameter.dev.java.net/>. 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.
[14] Venaas, S., "radsecproxy Project Homepage", 2007, [RFC5176] Chiba, M., Dommety, G., Eklund, M.,
<http://software.uninett.no/radsecproxy/>. Mitton, D., and B. Aboba, "Dynamic
Authorization Extensions to Remote
Authentication Dial In User Service
(RADIUS)", RFC 5176, January 2008.
[15] Trans-European Research and Education Networking Association, [RFC3588] Calhoun, P., Loughney, J., Guttman,
"eduroam Homepage", 2007, <http://www.eduroam.org/>. E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588,
September 2003.
[16] Delivery of Advanced Network Technology to Europe, "European [RFC5246] Dierks, T. and E. Rescorla, "The
Commission Information Society and Media: GEANT2", 2008, Transport Layer Security (TLS)
<http://www.geant2.net/>. Protocol Version 1.2", RFC 5246,
August 2008.
[17] TERENA, "Trans-European Research and Education Networking [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",
Association", 2008, <http://www.terena.org/>. 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 quoted from the file goodies/dnsroam.cfg in the
Radiator distribution; further documentation of the <AuthBy DNSROAM> Radiator distribution; further documentation of the <AuthBy DNSROAM>
feature in Radiator can be found at [11]. It describes an algorithm feature in Radiator can be found at [radiator-manual]. It describes
to retrieve the RadSec route information from the global DNS using an algorithm to retrieve the RadSec route information from the global
NAPTR and SRV records. The input of the algorithm is the realm part DNS using NAPTR and SRV records. The input of the algorithm is the
of the user name. 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.
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. If no NAPTR records are found, look for A and AAAA records based
directly on the realm name. For example, if the realm is directly on the realm name. For example, if the realm is
'examplerealm.edu', it looks for records such as 'examplerealm.edu', it looks for records such as
'_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu' '_radsec._tcp.examplerealm.edu', '_radsec._sctp.examplerealm.edu'
and '_radius._udp.examplerealm.edu', and '_radius._udp.examplerealm.edu',
5. All A and AAAA records found are ordered according to their Order 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.
For example, if the User-Name realm was 'examplerealm.edu', and DNS For example, if the User-Name realm was 'examplerealm.edu', and DNS
contained the following records: contained the following records:
examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" examplerealm.edu. IN NAPTR 50 50 "s" "AAAS+RADSECT" ""
_radsec._tcp.examplerealm.edu. _radsec._tcp.examplerealm.edu.
_radsec._tcp.examplerealm.edu. IN SRV 0 10 2083 _radsec._tcp.examplerealm.edu. IN SRV 0 10 2083
radsec.examplerealm.edu. radsec.examplerealm.edu.
radsec.examplerealm.edu. IN AAAA 2001::202:44ff:fe0a:f704 radsec.examplerealm.edu. IN AAAA 2001::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::202:44ff:fe0a:f704. The connection would be made
over TCP/IP, and TLS encryption would be used. This complete 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.
skipping to change at page 13, line 7 skipping to change at page 15, line 14
certificate will be verified, including checking that the configured certificate will be verified, including checking that the configured
FQDN or IP address matches what is in the certificate. Requests are FQDN or IP address matches what is in the certificate. Requests are
sent to a RadSec server just like they would to a UDP server. sent to a RadSec server just like they would to a UDP server.
The proxy supports Status-Server messages. They are only sent to a The proxy supports Status-Server messages. They are only sent to a
server if enabled for that particular server. Status-Server requests server if enabled for that particular server. Status-Server requests
are always responded to. are always responded to.
This RadSec implementation has been successfully tested together with This RadSec implementation has been successfully tested together with
Radiator. It is a freely available open-source implementation. For Radiator. It is a freely available open-source implementation. For
source code and documentation, see [14]. source code and documentation, see [radsecproxy-impl].
Authors' Addresses Authors' Addresses
Stefan Winter Stefan Winter
Fondation RESTENA Fondation RESTENA
6, rue Richard Coudenhove-Kalergi 6, rue Richard Coudenhove-Kalergi
Luxembourg 1359 Luxembourg 1359
LUXEMBOURG LUXEMBOURG
Phone: +352 424409 1 Phone: +352 424409 1
skipping to change at page 14, line 5 skipping to change at page 16, line 16
UNINETT UNINETT
Abels gate 5 - Teknobyen Abels gate 5 - Teknobyen
Trondheim 7465 Trondheim 7465
NORWAY NORWAY
Phone: +47 73 55 79 00 Phone: +47 73 55 79 00
Fax: +47 73 55 79 01 Fax: +47 73 55 79 01
EMail: stig.venaas@uninett.no EMail: stig.venaas@uninett.no
URI: http://www.uninett.no. URI: http://www.uninett.no.
Klaas Wierenga
Cisco Systems International BV
Haarlerbergweg 13-19
Amsterdam 1101 CH
The Netherlands
Phone: +31 (0)20 3571752
Fax:
EMail: kwiereng@cisco.com
URI: http://www.cisco.com.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
skipping to change at page 14, line 45 skipping to change at page 17, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgements Acknowledgement
Funding for the RFC Editor function is provided by the IETF This document was produced using xml2rfc v1.33 (of
Administrative Support Activity (IASA). This document was produced http://xml.resource.org/) from a source in RFC-2629 XML format.
using xml2rfc v1.32 (of http://xml.resource.org/) from a source in
RFC-2629 XML format.
 End of changes. 71 change blocks. 
264 lines changed or deleted 366 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/