draft-ietf-radext-radsec-05.txt   draft-ietf-radext-radsec-06.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 14, 2010 OSC Expires: September 6, 2010 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
July 13, 2009 March 05, 2010
TLS encryption for RADIUS over TCP (RadSec) TLS encryption for RADIUS
draft-ietf-radext-radsec-05 draft-ietf-radext-radsec-06
Abstract
This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP. This enables dynamic
trust relationships between RADIUS servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document specifies security on the transport layer (TLS) for the This document may contain material from IETF Documents or IETF
RADIUS protocol [RFC2865] when transmitted over TCP Contributions published or made publicly available before November
[I-D.dekok-radext-tcp-transport]. This enables dynamic trust 10, 2008. The person(s) controlling the copyright in some of this
relationships between RADIUS servers. material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 2.3. Connecting Client Identity . . . . . . . . . . . . . . . . 6
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7 2.4. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8
3.2. Ciphersuites and Compression Negotiation Considerations . 8 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 3.2. Ciphersuites and Compression Negotiation Considerations . 9
4. Compatibility with other RADIUS transports . . . . . . . . . . 9 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 4. Compatibility with other RADIUS transports . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 14
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 15
1. Introduction 1. Introduction
The RADIUS protocol [RFC2865] is a widely deployed authentication and The RADIUS protocol [RFC2865] is a widely deployed authentication and
authorisation protocol. The supplementary RADIUS Accounting authorisation protocol. The supplementary RADIUS Accounting
specification [RFC2866] also provides accounting mechanisms, thus specification [RFC2866] also provides accounting mechanisms, thus
delivering a full AAA solution. However, RADIUS is experiencing delivering a full AAA solution. However, RADIUS is experiencing
several shortcomings, such as its dependency on the unreliable several shortcomings, such as its dependency on the unreliable
transport protocol UDP and the lack of security for large parts of transport protocol UDP and the lack of security for large parts of
its packet payload. RADIUS security is based on the MD5 algorithm, its packet payload. RADIUS security is based on the MD5 algorithm,
which has been proven to be insecure. which has been proven to be insecure.
The main focus of RadSec is to provide a means to secure the The main focus of RADIUS over TLS 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 this specification lies in roaming environments
RADIUS packets need to be transferred through different where 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 RADIUS over
secure communication is "eduroam", see [eduroam]. TLS to secure communication is "eduroam", see [eduroam].
There are multiple known attacks on the MD5 algorithm which is used There are multiple known attacks on the MD5 algorithm which is used
in RADIUS to provide integrity protection and a limited in RADIUS to provide integrity protection and a limited
confidentiality protection. RadSec wraps the entire RADIUS packet confidentiality protection. RADIUS over TLS wraps the entire RADIUS
payload into a TLS stream and thus mitigates the risk of attacks on packet payload into a TLS stream and thus mitigates the risk of
MD5. attacks on MD5.
Because of the static trust establishment between RADIUS peers (IP Because of the static trust establishment between RADIUS peers (IP
address and shared secret) the only scalable way of creating a address and shared secret) the only scalable way of creating a
massive deployment of RADIUS-servers under control by different massive deployment of RADIUS-servers under control by different
administrative entities is to introduce some form of a proxy chain to administrative entities is to introduce some form of a proxy chain to
route the access requests to their home server. This creates a lot route the access requests to their home server. This creates a lot
of overhead in terms of possible points of failure, longer of overhead in terms of possible points of failure, longer
transmission times as well as middleboxes through which transmission times as well as middleboxes through which
authentication traffic flows. These middleboxes may learn privacy- authentication traffic flows. These middleboxes may learn privacy-
relevant data while forwarding requests. The new features in RadSec relevant data while forwarding requests. The new features in RADIUS
obsolete the use of IP addresses and shared MD5 secrets to identify over TLS obsolete the use of IP addresses and shared MD5 secrets to
other peers and thus allow the dynamic establishment of connections identify other peers and thus allow the dynamic establishment of
to peers that are not previously configured, and thus makes it connections to peers that are not previously configured, and thus
possible to avoid intermediate aggregation proxies. One mechanism makes it possible to avoid intermediate aggregation proxies. One
discover RadSec 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", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119. [RFC2119] RFC 2119. [RFC2119]
1.2. Terminology 1.2. Terminology
RadSec node: a RadSec client or server RADIUS/TLS node: a RADIUS over TLS client or server
RadSec Client: a RadSec instance which initiates a new connection. RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new
connection.
RadSec Server: a RadSec instance which listens on a RadSec port and RADIUS/TLS Server: a RADIUS over TLS instance which listens on a
accepts new connections RADIUS over TLS port and accepts new connections
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 over TCP
2.1. TCP port and packet types 2.1. TCP port and packet types
The default destination port number for RadSec is TCP/2083. There The default destination port number for RADIUS over TLS is TCP/2083.
are no separate ports for authentication, accounting and dynamic There are no separate ports for authentication, accounting and
authorisation changes. The source port is arbitrary. dynamic authorisation changes. The source port is arbitrary.
2.2. Connection Setup 2.2. Connection Setup
RadSec nodes RADIUS/TLS nodes
1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport]
2. negotiate TLS sessions according to [RFC5246] or its predecessor 2. negotiate TLS sessions according to [RFC5246] or its predecessor
TLS 1.1. The following restrictions apply: TLS 1.1. The following restrictions apply:
* The authentication MUST be mutual, i.e. both the RadSec server * The authentication MUST be mutual, i.e. both the RADIUS/TLS
and the RadSec client authenticate each other. server and the RADIUS/TLS client authenticate each other.
* The client MUST NOT negotiate cipher suites which only provide * The client MUST NOT negotiate cipher suites which only provide
integrity protection. integrity protection.
* The TLS session MAY use mutual PSKs for connection setup. * The TLS session MAY use mutual PSKs for connection setup.
* Negotiation of compression for the TLS session is OPTIONAL. * Negotiation of compression for the TLS session is OPTIONAL.
* RADSEC implementations MUST support the mandatory to implement * RADIUS/TLS implementations MUST support the mandatory to
cipher suites specified in TLS (i.e. implement cipher suites specified in TLS (i.e.
TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility
with some current deployments implementations SHOULD support with some current deployments implementations SHOULD support
TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
well (see Section 3.2 (1) ). well (see Section 3.2 (1) ).
3. If TLS is used in an X.509 certificate based operation mode, the 3. If TLS is used in an X.509 certificate based operation mode, the
following list of certificate validation options applies: following list of certificate validation options applies:
* Implementations MUST allow to configure a list of acceptable * Implementations MUST allow to configure a list of acceptable
Certification Authorities for incoming connections. Certification Authorities for incoming connections.
* Certificate validation MUST include the verification rules as * Certificate validation MUST include the verification rules as
per [RFC5280]. If service names as per [RFC4985] are present per [RFC5280], using information from trusted sources only
in the certificate and dynamic discovery utilizing SRVs in DNS (e.g. locally configured names). If service names as per
is used (see [I-D.winter-dynamic-discovery]) and the TLS [RFC4985] are present in the certificate and dynamic discovery
implementation supports evaluation of the extensions in utilizing SRVs in DNS is used (see
[RFC4985], the SRV entry MUST be validated. [I-D.winter-dynamic-discovery]) and the TLS implementation
supports evaluation of the extensions in [RFC4985], the SRV
entry MUST be validated. In cases where no DNS SRV resolution
took place to arrive at the TLS peer, subjectAltName:SRV
entries can be ignored.
* Implementations SHOULD indicate their acceptable Certification * Implementations SHOULD indicate their acceptable Certification
Authorities as per section 7.4.4 (server side) and x.y.z Authorities as per section 7.4.4 (server side) and x.y.z
["Trusted CA Indication"] (client side) of [RFC5246] (see ["Trusted CA Indication"] (client side) of [RFC5246] (see
Section 3.1) Section 3.1)
* Implementations SHOULD allow to configure a list of acceptable * Implementations SHOULD allow to configure a list of acceptable
certificates, identified via certificate fingerprint. When a certificates, identified via certificate fingerprint. When a
fingerprint configured, the fingerprint is prepended with an fingerprint configured, the fingerprint is prepended with an
ASCII label identifying the hash function followed by a colon. ASCII label identifying the hash function followed by a colon.
skipping to change at page 5, line 45 skipping to change at page 6, line 9
precedence over CN; for IP address validation, subjectAltName: precedence over CN; for IP address validation, subjectAltName:
iPAddr has precedence over CN. iPAddr has precedence over CN.
* 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.3. RADIUS Datagrams 2.3. Connecting Client Identity
In RADIUS/UDP, clients are uniquely identified by their IP address.
This does not permit to determine whether the connecting entity is a
NAS or a different server which proxies a request. When NAT is used
on the path to the server, it also does not permit to determine
whether there is more than one entity connecting from the same IP
address.
RADIUS/TLS makes it possible to preserve this traditional RADIUS
semantics by identifying a connecting client by the IP address which
initiated the TLS connection. In addition, it permits a much more
fine-grained identification. The parameters of 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
TLS connection which belongs to an incoming RADIUS packet as possible
to the application layer to allow the administrator to define the
identification criteria which are applicable to his desired
operational model. In X.509 certificate operation, at least the
following parameters of the TLS connection should be exposed:
o Originating IP address
o Certificate Fingerprint
o Issuer
o Subject
o all X509v3 Extended Key Usage
o all X509v3 Subject Alternative Name
o all X509v3 Certificate Policies
In TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed:
o Originating IP address
o TLS Identifier
2.4. RADIUS Datagrams
Authentication, Accounting and Authorization packets are sent Authentication, Accounting and Authorization packets are sent
according to the following rules: according to the following rules:
RadSec clients handle the following packet types from [RFC2865], RADIUS/TLS clients handle the following packet types from [RFC2865],
[RFC2866], [RFC5176] on the connection they initiated (see [RFC2866], [RFC5176] on the connection they initiated (see
Section 3.3 (3) and (4) ): Section 3.3 (3) and (4) ):
o send Access-Request o send Access-Request
o send Accounting-Request o send Accounting-Request
o send Status-Server o send Status-Server
o send Disconnect-ACK o send Disconnect-ACK
skipping to change at page 6, line 31 skipping to change at page 7, line 40
o receive Access-Accept o receive Access-Accept
o receive Access-Reject o receive Access-Reject
o receive Accounting-Response o receive Accounting-Response
o receive Disconnect-Request o receive Disconnect-Request
o receive CoA-Request o receive CoA-Request
RadSec servers handle the following packet types from [RFC2865], RADIUS/TLS servers handle the following packet types from [RFC2865],
[RFC2866], [RFC5176] on the connections they serve to clients: [RFC2866], [RFC5176] on the connections they serve to clients:
o receive Access-Request o receive Access-Request
o receive Accounting-Request o receive Accounting-Request
o receive Status-Server o receive Status-Server
o receive Disconnect-ACK o receive Disconnect-ACK
skipping to change at page 7, line 19 skipping to change at page 8, line 27
o send CoA-Request o send CoA-Request
3. Informative: Design Decisions 3. Informative: Design Decisions
This section explains the design decisions that led to the rules This section explains the design decisions that led to the rules
defined in the previous section. defined in the previous section.
3.1. X.509 Certificate Considerations 3.1. X.509 Certificate Considerations
(1) If a RadSec client is in possession of multiple certificates from (1) If a RADIUS/TLS client is in possession of multiple certificates
different CAs (i.e. is part of multiple roaming consortia) and from different CAs (i.e. is part of multiple roaming consortia) and
dynamic discovery is used, the discovery mechanism possibly does not dynamic discovery is used, the discovery mechanism possibly does not
yield sufficient information to identify the consortium uniquely yield sufficient information to identify the consortium uniquely
(e.g. DNS discovery). Subsequently, the client may not know by (e.g. DNS discovery). Subsequently, the client may not know by
itself which client certificate to use for the TLS handshake. Then itself which client certificate to use for the TLS handshake. Then
it is necessary for the server to signal which consortium it belongs it is necessary for the server to signal which consortium it belongs
to, and which certificates it expects. If there is no risk of to, and which certificates it expects. If there is no risk of
confusing multiple roaming consortia, providing this information in confusing multiple roaming consortia, providing this information in
the handshake is not crucial. the handshake is not crucial.
(2) If a RadSec server is in possession of multiple certificates from (2) If a RADIUS/TLS server is in possession of multiple certificates
different CAs (i.e. is part of multiple roaming consortia), it will from different CAs (i.e. is part of multiple roaming consortia), it
need to select one of its certificates to present to the RadSec will need to select one of its certificates to present to the RADIUS/
client. If the client sends the Trusted CA Indication, this hint can TLS client. If the client sends the Trusted CA Indication, this hint
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 [I-D.winter-dynamic-discovery]
is used, peer authentication alone is not sufficient; the peer must is used, peer authentication alone is not sufficient; the peer must
also be authorised to perform user authentications. In these cases, also be authorised to perform user authentications. In these cases,
the trust fabric cannot depend on peer authentication methods like the trust fabric cannot depend on peer authentication methods like
DNSSEC to identify RadSec nodes. The RadSec nodes also need to be DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be
properly authorised. Typically, this can be achieved by adding properly authorised. Typically, this can be achieved by adding
appropriate authorisation fields into a X.509 certificate. Such appropriate authorisation fields into a X.509 certificate. Such
fields include SRV authority (x.y.z... reference), subjectAltName: fields include SRV authority [RFC4985], subjectAltNames, or a defined
URI, or a defined list of certificate fingerprints. Operators of a list of certificate fingerprints. Operators of a RADIUS/TLS
RadSec infrastructure should define their own authorisation trust infrastructure should define their own authorisation trust model and
model and apply this model to the certificates. The checks apply this model to the certificates. The checks enumerated in
enumerated in Section 2.2 provide sufficient flexibility for the Section 2.2 provide sufficient flexibility for the implementation of
implementation of authorisation trust models. 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 RadSec use OpenSSL as cryptographic backend, which implementations of RADIUS/TLS use OpenSSL as cryptographic backend,
supports all of the ciphersuites listed in the rules in the normative which supports all of the ciphersuites listed in the rules in the
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-
implement according to [RFC5246] and thus has to be supported by implement according to [RFC5246] and thus has to be supported by
RadSec nodes. RADIUS/TLS nodes.
The two other ciphersuites in the normative section are widely The two other ciphersuites in the normative section are widely
implemented in TLS toolkits and are considered good practice to implemented in TLS toolkits and are considered good practice to
implement. implement.
3.3. RADIUS Datagram Considerations 3.3. RADIUS Datagram Considerations
(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 plain RADIUS, 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 RadSec 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. boundary.
(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
shared secret eliminates possible node misconfigurations. shared secret eliminates possible node misconfigurations.
(3) RADIUS [RFC2865] uses different UDP ports for authentication, (3) RADIUS [RFC2865] uses different UDP ports for authentication,
accounting and dynamic authorisation changes. RadSec allocates a accounting and dynamic authorisation changes. RADIUS/TLS allocates a
single port for all RADIUS packet types. Nevertheless, in RadSec the single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS
notion of a client which sends authentication requests and processes the notion of a client which sends authentication requests and
replies associated with it's users' sessions and the notion of a processes replies associated with it's users' sessions and the notion
server which receives requests, processes them and sends the of a server which receives requests, processes them and sends the
appropriate replies is to be preserved. The normative rules about appropriate replies is to be preserved. The normative rules about
acceptable packet types for clients and servers mirror the packet acceptable packet types for clients and servers mirror the packet
flow behaviour from RADIUS. flow behaviour from RADIUS/UDP.
(4) RADIUS [RFC2865] used negative ICMP responses to a newly (4) RADIUS [RFC2865] used negative ICMP responses to a newly
allocated UDP port to signal that a peer RADIUS server does not allocated UDP port to signal that a peer RADIUS server does not
support reception and processing of the packet types in [RFC5176]. support reception and processing of the packet types in [RFC5176].
These packet types are listed as to be received in RadSec These packet types are listed as to be received in 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.
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.dekok-radext-tcp-transport], RADIUS over DTLS
[I-D.dekok-radext-dtls] and the present document on RadSec. [I-D.dekok-radext-dtls] and this present document on RADIUS over TLS.
RadSec does not specify any inherent backwards compatibility to RADIUS/TLS does not specify any inherent backwards compatibility to
classic RADIUS or cross compatibility to the other transports, i.e. RADIUS/UDP or cross compatibility to the other transports, i.e. an
an implementation which implements RadSec 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 RadSec) will need wishes to serve clients using other transports than RADIUS/TLS) will
to implement the other transports and RadSec transport and be need to implement these other transports along with the RADIUS/TLS
prepared to send and receive on all implemented transports, which is transport and be prepared to send and receive on all implemented
called a multi-stack implementation. transports, which is called a multi-stack implementation.
If a given IP device is able to receive RADIUS payloads on multiple If a given IP device is able to receive RADIUS payloads on multiple
transports, this may or may not be the same instance of software, and transports, this may or may not be the same instance of software, and
it may or may not serve the same purposes. It is not safe to assume it may or may not serve the same purposes. It is not safe to assume
that both ports are interchangeable. In particular, it can not be that both ports are interchangeable. In particular, it can not be
assumed that state is maintained for the packet payloads between the assumed that state is maintained for the packet payloads between the
transports. Two such instances MUST be considered separate RADIUS transports. Two such instances MUST be considered separate RADIUS
server entities. server entities.
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 classic RADIUS is NOT RECOMMENDED, as it may lead to fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
down-bidding attacks on the peer communication. bidding attacks on the peer communication.
5. Diameter Compatibility 5. Diameter Compatibility
Since RadSec is only a new transport profile for RADIUS, Since RADIUS/TLS is only a new transport profile for RADIUS,
compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP
Diameter [RFC3588] is identical. The considerations regarding [RFC2865] - Diameter [RFC3588] is identical. The considerations
payload size in [I-D.dekok-radext-tcp-transport] apply. regarding payload size in [I-D.dekok-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 RadSec node will more datagrams. Therefore, clients connecting to a RADIUS/TLS node will
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 RadSec node needs to be able to [I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to
accept connections from a large, not previously known, group of 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 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.winter-dynamic-discovery], X.509 certificates are the only proof
of authorisation for a connecting RadSec nodes. Special care needs of authorisation for a connecting RADIUS/TLS nodes. Special care
to be taken that certificates get verified properly according to the needs to be taken that certificates get verified properly according
chosen trust model (particularly: consulting CRLs, checking critical to the chosen trust model (particularly: consulting CRLs, checking
extensions, checking subjectAltNames etc.) to prevent unauthorised critical extensions, checking subjectAltNames etc.) to prevent
connections. unauthorised connections.
Some TLS ciphersuites only provide integrity validation of their Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification forbids the payload, and provide no encryption. This specification forbids the
use of such ciphersuites. Since the RADIUS payload's shared secret use of such ciphersuites. Since the RADIUS payload's shared secret
is fixed and well-known, failure to comply with this requirement will is fixed and well-known, failure to comply with this requirement will
expose the entire datagram payload in plain text, including User- expose the entire datagram payload in plain text, including User-
Password, to intermediate IP nodes. Password, to intermediate IP nodes.
If peer communication between two devices is configured for both If peer communication between two devices is configured for both
RadSec and classic RADIUS, a failover from RadSec to classic RADIUS RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic
opens the way for a down-bidding attack if an adversary can RADIUS security opens the way for a down-bidding attack if an
maliciously close the TCP connection, or prevent it from being adversary can maliciously close the TCP connection, or prevent it
established. In this case, security of the packet payload is reduced from being established. In this case, security of the packet payload
from the selected TLS cipher suite packet encryption to the classic is reduced from the selected TLS cipher suite packet encryption to
MD5 per-attribute encryption. the classic MD5 per-attribute encryption.
The RadSec transport provides authentication and encryption between The RADIUS/TLS transport provides authentication and encryption
RADIUS peers. In the presence of proxies, the intermediate proxies between RADIUS peers. In the presence of proxies, the intermediate
can still inspect the individual RADIUS packets, i.e. "end-to-end" proxies can still inspect the individual RADIUS packets, i.e. "end-
encryption is not provided. Where intermediate proxies are to-end" encryption is not provided. Where intermediate proxies are
untrusted, it is desirable to use other RADIUS mechanisms to prevent untrusted, it is desirable to use other RADIUS mechanisms to prevent
RADIUS packet payload from inspection by such proxies. One common RADIUS packet payload from inspection by such proxies. One common
method to protect passwords is the use of EAP methods which utilize method to protect passwords is the use of EAP methods which utilize
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. No new RADIUS attributes or previously assigned by IANA for RadSec, an early implementation of
packet codes are defined. RADIUS/TLS. No new RADIUS attributes or packet codes are defined.
8. Acknowledgements 8. Acknowledgements
RadSec version 1 was first implemented by Open Systems Consultants, RADIUS over TLS was first implemented as "RADSec" by Open Systems
Currumbin Waters, Australia, for their "Radiator" RADIUS server Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS
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
skipping to change at page 12, line 26 skipping to change at page 13, line 34
August 2008. August 2008.
[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",
draft-dekok-radext-tcp-transport-01 draft-dekok-radext-tcp-transport-01
(work in progress), November 2008. (work in progress), November 2008.
9.2. Informative References 9.2. Informative References
[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport
Layer for RADIUS", Layer for RADIUS",
draft-dekok-radext-dtls-00 (work in draft-dekok-radext-dtls-01 (work in
progress), February 2007. progress), June 2009.
[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery
for RADIUS over TLD and DTLS", for RADIUS over TLD and DTLS",
draft-winter-dynamic-discovery-00 draft-winter-dynamic-discovery-00
(work in progress), February 2009. (work in progress), February 2009.
[RFC3588] Calhoun, P., Loughney, J., Guttman, [RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, "Diameter Base Protocol", RFC 3588,
September 2003. September 2003.
 End of changes. 50 change blocks. 
143 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/