One document matched: draft-ietf-radext-radsec-11.xml
<?xml version = '1.0'?>
<?rfc rfcedstyle='yes'?>
<?rfc rfcprocack='yes'?>
<?rfc toc='yes'?>
<?rfc symrefs='yes'?>
<!DOCTYPE rfc SYSTEM "../xml2rfc-1.36/rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' '../rfc-bib/reference.RFC.2119.xml'>
<!ENTITY rfc2865 PUBLIC '' '../rfc-bib/reference.RFC.2865.xml'>
<!ENTITY rfc2866 PUBLIC '' '../rfc-bib/reference.RFC.2866.xml'>
<!ENTITY rfc3268 PUBLIC '' '../rfc-bib/reference.RFC.3268.xml'>
<!ENTITY rfc5176 PUBLIC '' '../rfc-bib/reference.RFC.5176.xml'>
<!ENTITY rfc3539 PUBLIC '' '../rfc-bib/reference.RFC.3539.xml'>
<!ENTITY rfc3588 PUBLIC '' '../rfc-bib/reference.RFC.3588.xml'>
<!ENTITY rfc4279 PUBLIC '' '../rfc-bib/reference.RFC.4279.xml'>
<!ENTITY rfc4346 PUBLIC '' '../rfc-bib/reference.RFC.4346.xml'>
<!ENTITY rfc4785 PUBLIC '' '../rfc-bib/reference.RFC.4785.xml'>
<!ENTITY rfc5246 PUBLIC '' '../rfc-bib/reference.RFC.5246.xml'>
<!ENTITY rfc5247 PUBLIC '' '../rfc-bib/reference.RFC.5247.xml'>
<!ENTITY rfc5280 PUBLIC '' '../rfc-bib/reference.RFC.5280.xml'>
<!ENTITY rfc6421 PUBLIC '' '../rfc-bib/reference.RFC.6421.xml'>
<!ENTITY radius-tcp PUBLIC ''
'../i-d-bib/reference.I-D.ietf-radext-tcp-transport.xml'>
<!ENTITY radius-dtls PUBLIC ''
'../i-d-bib/reference.I-D.ietf-radext-dtls.xml'>
<!ENTITY dyn-disc PUBLIC ''
'../i-d-bib/reference.I-D.ietf-radext-dynamic-discovery.xml'>
]>
<rfc ipr='pre5378Trust200902' docName='draft-ietf-radext-radsec-11'
category='exp'>
<front>
<title abbrev="RADIUS over TLS" >TLS encryption for RADIUS</title>
<author fullname="Stefan Winter" initials="S." surname="Winter" >
<organization abbrev="RESTENA" >
Fondation RESTENA
</organization>
<address>
<postal>
<street>6, rue Richard Coudenhove-Kalergi</street>
<city>Luxembourg</city>
<code>1359</code>
<country>LUXEMBOURG</country>
</postal>
<phone>+352 424409 1</phone>
<facsimile>+352 422473</facsimile>
<email>stefan.winter@restena.lu</email>
<uri>http://www.restena.lu.</uri>
</address>
</author>
<author fullname="Mike McCauley" initials="M." surname="McCauley" >
<organization abbrev="OSC" >
Open Systems Consultants
</organization>
<address>
<postal>
<street>9 Bulbul Place</street>
<city>Currumbin Waters</city>
<code>QLD 4223</code>
<country>AUSTRALIA</country>
</postal>
<phone>+61 7 5598 7474</phone>
<facsimile>+61 7 5598 7070</facsimile>
<email>mikem@open.com.au</email>
<uri>http://www.open.com.au.</uri>
</address>
</author>
<author fullname="Stig Venaas" initials="S." surname="Venaas" >
<organization abbrev="Cisco" >
cisco Systems
</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose, CA</city>
<code>95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email>
</address>
</author>
<author fullname="Klaas Wierenga" initials="K." surname="Wierenga" >
<organization abbrev="Cisco" >
Cisco Systems International BV
</organization>
<address>
<postal>
<street>Haarlerbergweg 13-19</street>
<city>Amsterdam</city>
<code>1101 CH</code>
<country>The Netherlands</country>
</postal>
<phone>+31 (0)20 3571752</phone>
<facsimile></facsimile>
<email>kwiereng@cisco.com</email>
<uri>http://www.cisco.com.</uri>
</address>
</author>
<date day="27" month="January" year="2012" />
<area>Operations and Management Area</area>
<workgroup>RADIUS Extensions Working Group</workgroup>
<keyword>RADIUS</keyword>
<keyword>AAA</keyword>
<keyword>Security</keyword>
<keyword>Reliability</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The RADIUS protocol <xref target="RFC2865" /> is a widely deployed
authentication and authorisation protocol. The supplementary RADIUS Accounting
specification <xref target="RFC2866" /> also provides accounting mechanisms,
thus delivering a full AAA solution. However, RADIUS is experiencing several
shortcomings, such as its dependency on the unreliable transport protocol UDP
and the lack of security for large parts of its packet payload. RADIUS security
is based on the MD5 algorithm, which has been proven to be insecure.</t>
<t>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 most
important use of this specification lies in roaming environments where RADIUS packets need
to be transferred through different administrative domains and untrusted,
potentially hostile networks. An example for a world-wide roaming environment
that uses RADIUS over TLS to secure communication is "eduroam", see <xref
target="eduroam"/>.</t>
<t>There are multiple known attacks on the MD5 algorithm which is used
in RADIUS to provide integrity protection and a limited confidentiality
protection (see <xref target="MD5-attacks" />). RADIUS over TLS wraps the entire RADIUS packet payload into a TLS stream and
thus mitigates the risk of attacks on MD5.</t>
<t>Because of the static trust establishment between RADIUS peers (IP
address and shared secret) the only scalable way of creating a 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 RADIUS over TLS obsolete the use of IP
addresses and shared MD5 secrets to identify other peers and thus allow the
use of more contemporary trust models, e.g. checking a certificate by inspecting the
issuer and other certificate properties.</t>
<section title="Requirements Language" anchor="reqlang">
<t>In this document, several words are used to signify the
requirements of the specification. The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
<xref target="RFC2119" /></t>
</section>
<section title="Terminology" anchor="terms">
<t>RADIUS/TLS node: a RADIUS over TLS client or server</t>
<t>RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new
connection.</t>
<t>RADIUS/TLS Server: a RADIUS over TLS instance which listens on a RADIUS over TLS
port and accepts new connections</t>
<t>RADIUS/UDP: classic RADIUS transport over UDP as defined in <xref target="RFC2865" /></t>
</section>
<section title="Document Status" anchor="status">
<t>This document is an Experimental RFC.</t>
<t>It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also <xref target="radius-compat"/>). The specification does not fulfill all recommendations on a AAA transport profile as per <xref target="RFC3539"/>; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues.</t>
<t>It has yet to be decided whether this approach is to be chosen for standards track. One key aspect to judge whether the approach is usable at large scale is by observing the uptake, usability and operational behaviour of the protocol in large-scale, real-life deployments.</t>
<t>An example for a world-wide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see <xref target="eduroam"/>.</t>
</section>
</section>
<section title="Normative: Transport Layer Security for RADIUS/TCP"
anchor="TLS">
<section title="TCP port and packet types" anchor="ports">
<t>The default destination port number for RADIUS over TLS is TCP/2083.
There are no separate ports for authentication, accounting and dynamic
authorisation changes. The source port is arbitrary. See section <xref target="design-radius" /> for considerations regarding separation of authentication, accounting and dynauth traffic.</t>
</section>
<section title="TLS negotiation" anchor="starttls">
<t>RADIUS/TLS has no notion of negotiating TLS in an established connection. Servers and clients need to be preconfigured to use RADIUS/TLS for a given endpoint.</t>
</section>
<section title="Connection Setup" anchor="conn-setup">
<t>RADIUS/TLS nodes
<list style = "numbers">
<t>establish TCP connections as per <xref
target="I-D.ietf-radext-tcp-transport" />. Failure to connect leads to continuous retries, with exponentially growing intervals between every try. If multiple servers are defined, the node MAY attempt to establish a connection to these other servers in parallel, in order to implement quick failover.</t>
<t>after completing the TCP handshake, immediately negotiate TLS sessions according to <xref target="RFC5246" /> or its predecessor TLS 1.1. The following restrictions apply:
<list style="symbols">
<t>Support for TLS v1.1 <xref target="RFC4346"/> or later (e.g. TLS 1.2 <xref target="RFC5246"/> ]) is REQUIRED.</t>
<t>Support for certificate-based mutual authentication is REQUIRED.</t>
<t>Negotiation of mutual authentication is REQUIRED.</t>
<t>Negotiation of a ciphersuite providing for confidentiality as well as integrity protection is REQUIRED.</t>
<t>Support for and negotiation of compression is OPTIONAL.</t>
<t>Support for TLS-PSK mutual authentication <xref target="RFC4279"/> is OPTIONAL.</t>
<t>RADIUS/TLS implementations MUST at a minimum support negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well (see <xref target="design-cipher" /> (1) ).</t>
<t>In addition, RADIUS/TLS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support.</t>
<t>RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL encryption (e.g. <xref target="RFC4785" />).</t>
</list>
</t>
<t>
If TLS is used in an X.509 certificate
based operation mode, the following list of certificate validation options
applies: <list style="symbols">
<t>Implementations MUST allow to configure a list of acceptable Certification Authorities for incoming connections. </t>
<t>Certificate validation MUST include the verification rules as per <xref target="RFC5280" />.</t>
<t>Implementations SHOULD indicate their acceptable Certification Authorities as per section 7.4.4 (server side) and x.y.z ["Trusted CA Indication"] (client side) of <xref target="RFC5246" /> (see <xref target="design-cert" />) </t>
<t>
Implementations SHOULD
allow to configure a list of acceptable certificates, identified via certificate
fingerprint. When a fingerprint configured, the fingerprint is prepended with an
ASCII label identifying the hash function followed by a colon. Implementations
MUST support SHA-1 as the hash algorithm and use the ASCII label "sha-1" to
identify the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the
length of the corresponding fingerprint string is 65 characters. An example
certificate fingerprint is:
sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
</t>
<t>
Peer validation always
includes a check on whether the locally configured expected DNS name or IP
address of the server that is contacted matches its presented certificate. DNS
names and IP addresses can be contained in the Common Name (CN) or
subjectAltName entries. For verification, only one of these entries is to be
considered. The following precedence applies: for DNS name validation,
subjectAltName:DNS has precedence over CN; for IP address validation,
subjectAltName:iPAddr has precedence over CN.
</t>
<t>
Implementations SHOULD
allow to configure a set of acceptable values for subjectAltName:URI.
</t>
</list>
</t>
<t>
start exchanging RADIUS datagrams. Note
<xref target="design-radius" /> (1) ). The shared secret to compute the
(obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see
<xref target="design-radius" /> (2) ).
</t>
</list>
</t>
</section>
<section title="Connecting Client Identity">
<t>In RADIUS/UDP, clients are uniquely identified by their IP
address. Since the shared secret is associated with the origin IP address,
if more than one RADIUS client is associated with the same IP
address, then those clients also must utilize the same shared secret,
a practice which is inherently insecure as noted in <xref target="RFC5247" />.
</t>
<t>RADIUS/TLS supports multiple operation modes.</t>
<t>In TLS-PSK operation, a client is uniquely identified by its TLS identifier.</t>
<t>In TLS-X.509 mode using fingerprints, a client is uniquely identified by the fingerprint of the presented client certificate.</t>
<t>In TLS-X.509 with PKI infrastructure, a client is uniquely identified by the serial number of the tuple (presented client certificate;Issuer).</t>
<t>Note well: having identified a connecting entity does not mean the server necessarily wants to communicate with that client. E.g. if the Issuer is not in a trusted set of Issuers, the server may decline to perform RADIUS transactions with this client.</t>
<t>There are numerous trust models in PKI environments, and it is beyond the scope of this document to define how a particular deployment determines whether a client is trustworthy.
Implementations which want to support a wide variety of trust models should expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator. As a suggestion, at least the following parameters of the X.509 client certificate should be exposed:
<list style= "symbols">
<t>Originating IP address</t>
<t>Certificate Fingerprint</t>
<t>Issuer</t>
<t>Subject</t>
<t>all X509v3 Extended Key Usage</t>
<t>all X509v3 Subject Alternative Name</t>
<t>all X509v3 Certificate Policies</t>
</list>
In TLS-PSK operation, at least the following parameters of the TLS connection should be exposed:
<list style= "symbols">
<t>Originating IP address</t>
<t>TLS Identifier</t>
</list>
</t>
</section>
<section title="RADIUS Datagrams">
<t>Authentication, Accounting and Authorization packets are sent
according to the following rules:</t>
<t>RADIUS/TLS clients transmit the same packet types on the connection they initiated as a RADIUS/UDP client would (see <xref target="design-radius" /> (3) and (4) ). E.g. they send
<list style= "symbols">
<t>Access-Request</t>
<t>Accounting-Request</t>
<t>Status-Server</t>
<t>Disconnect-ACK</t>
<t>Disconnect-NAK</t>
<t>...</t>
</list>and they receive
<list style="symbols">
<t>Access-Accept</t>
<t>Accounting-Response</t>
<t>Disconnect-Request</t>
<t>...</t>
</list></t>
<t>RADIUS/TLS servers transmit the same packet types on connections they have accepted as a RADIUS/UDP server would. E.g. they send
<list style= "symbols">
<t>Access-Challenge</t>
<t>Access-Accept</t>
<t>Access-Reject</t>
<t>Accounting-Response</t>
<t>Disconnect-Request</t>
<t>...</t>
</list>and they receive
<list style= "symbols">
<t>Access-Request</t>
<t>Accounting-Request</t>
<t>Status-Server</t>
<t>Disconnect-ACK</t>
<t>...</t>
</list></t>
</section>
</section>
<section title="Informative: Design Decisions" anchor="design">
<t>This section explains the design decisions that led to the
rules defined in the previous section.</t>
<section title="Implications of Dynamic Peer Discovery">
<t>One mechanism to discover RADIUS over TLS peers dynamically via DNS is specified in <xref target="I-D.ietf-radext-dynamic-discovery" />. While this mechanism is still under development and therefore is not a normative dependency of RADIUS/TLS, the use of dynamic discovery has potential future implications that are important to understand.</t>
<t>Readers of this document who are considering the deployment of DNS-based dynamic discovery are thus encouraged to read <xref target="I-D.ietf-radext-dynamic-discovery" /> and follow its future development.</t>
</section>
<section title="X.509 Certificate Considerations"
anchor="design-cert">
<t>
(1) If a RADIUS/TLS 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 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.
</t>
<t>
(2) If a RADIUS/TLS 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
RADIUS/TLS 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.
</t>
</section>
<section title="Ciphersuites and Compression Negotiation
Considerations" anchor="design-cipher">
<t>Not all TLS ciphersuites in <xref target="RFC5246"/>
are supported by available TLS tool kits, and licenses may be required in some
cases. The existing implementations of RADIUS/TLS use OpenSSL as cryptographic
backend, which supports all of the ciphersuites listed in the rules in the
normative section.</t>
<t>The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is
mandatory-to-implement according to <xref target="RFC5246"/> and thus has to be
supported by RADIUS/TLS nodes.</t>
<t>The two other ciphersuites in the normative section
are widely implemented in TLS toolkits and are considered good practice to
implement.</t>
</section>
<section title="RADIUS Datagram Considerations"
anchor="design-radius">
<t>(1) After the TLS session is established, RADIUS packet
payloads are exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the
packet 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 true for
RADIUS/TLS packet exchange. Instead, packet boundaries of 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. See
section 2.6.4 of <xref target="I-D.ietf-radext-tcp-transport" /> for more details.</t>
<t>(2) Within RADIUS/UDP <xref target="RFC2865"/>, a shared
secret is used for hiding of attributes such as User-Password, as well as in
computation of the Response Authenticator. In RADIUS accounting <xref
target="RFC2866"/>, the shared secret is used in computation of both the Request
Authenticator and the Response Authenticator. Since TLS provides integrity
protection and encryption sufficient to substitute for RADIUS application-layer
security, it is not necessary to configure a RADIUS shared secret. The use of a
fixed string for the obsolete shared secret eliminates possible node
misconfigurations.</t>
<t>(3) RADIUS/UDP <xref target="RFC2865" /> uses different UDP
ports for authentication, accounting and dynamic authorisation changes. RADIUS/TLS
allocates a single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS the
notion of a client which sends authentication requests and processes replies
associated with it's users' sessions and the notion of a server which receives
requests, processes them and sends the appropriate replies is to be preserved.
The normative rules about acceptable packet types for clients and servers mirror
the packet flow behaviour from RADIUS/UDP.</t>
<t>(4) RADIUS/UDP <xref target="RFC2865" /> uses negative ICMP
responses to a newly allocated UDP port to signal that a peer RADIUS server does
not support reception and processing of the packet types in <xref
target="RFC5176" />. These packet types are listed as to be received in RADIUS/TLS
implementations. Note well: it is not required for an implementation to actually
process these packet types. It is sufficient that upon receiving such a packet,
an unconditional NAK is sent back to indicate that the action is not
supported. The NAK SHOULD contain an attribute Error-Cause with the value 406
("Unsupported Extension"); see <xref target="RFC5176" /> for details.</t>
<t>(5) RADIUS/UDP <xref target="RFC2865" /> uses negative ICMP
responses to a newly allocated UDP port to signal that a peer RADIUS server does
not support reception and processing of RADIUS Accounting packets. There is no RADIUS
datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a
RADIUS/TLS server which does not wish to process their Accounting packet. The server
will need to silently drop the packet. The client will need to deduce from the absence
of replies that it is misconfigured; no negative ICMP response will reveal this.</t>
</section>
</section>
<section title="Compatibility with other RADIUS transports"
anchor="radius-compat">
<t>
Ongoing work in the IETF defines multiple alternative
transports to the classic UDP transport model as defined in <xref
target="RFC2865" />, namely RADIUS over TCP <xref
target="I-D.ietf-radext-tcp-transport" />, RADIUS over DTLS <xref
target="I-D.ietf-radext-dtls" /> and this present document on RADIUS over TLS.</t>
<t>
RADIUS/TLS does not specify any inherent backwards compatibility
to RADIUS/UDP or cross compatibility to the other transports, i.e. an
implementation which implements RADIUS/TLS only will not be able to receive or send
RADIUS packet payloads over other transports. An implementation wishing to be
backward or cross compatible (i.e. wishes to serve clients using other
transports than RADIUS/TLS) will need to implement these other transports along with the RADIUS/TLS
transport and be prepared to send and receive on all implemented transports,
which is called a multi-stack implementation.
</t>
<t>
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
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 assumed that state is
maintained for the packet payloads between the transports. Two such instances
MUST be considered separate RADIUS server entities.
</t>
</section>
<section title="Diameter Compatibility" anchor="compat">
<t>
Since RADIUS/TLS is only a new transport profile for RADIUS,
compatibility of RADIUS/TLS - Diameter <xref target="RFC3588" /> vs. RADIUS/UDP <xref
target="RFC2865" /> - Diameter <xref target="RFC3588" /> is identical. The
considerations regarding payload size in <xref
target="I-D.ietf-radext-tcp-transport" /> apply.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>
The computational resources to establish a TLS tunnel are
significantly higher than simply sending mostly unencrypted UDP datagrams.
Therefore, clients connecting to a RADIUS/TLS node will more easily create high load
conditions and a malicious client might create a Denial-of-Service attack more
easily.</t>
<t>
Some TLS ciphersuites only provide integrity validation of
their payload, and provide no encryption. This specification forbids the use of
such ciphersuites. Since the RADIUS payload's shared secret is fixed to the well-known term "radsec"
(see Section 2.3 (4) ) , failure to comply with this requirement will expose the entire
datagram payload in plain text, including User-Password, to intermediate IP
nodes.
</t>
<t>
If peer communication between two devices is configured for
both RADIUS/TLS transport (i.e TLS security on the transport layer, shared secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret
security with a secret manually configured by the administrator), and where
the RADIUS/UDP transport is the failover option if the TLS session cannot be established,
a down-bidding attack can occur if an adversary can maliciously close the TCP connection,
or prevent it from being established. Situations where clients are
configured in such a way are likely to occur during a migration phase from
RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the
packet payload from the selected TLS cipher suite packet encryption
to the classic MD5 per-attribute encryption. The situation should be avoided by
disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport
is established and tested. Disabling can happen at either the RADIUS client or
server side:
<list style="symbols">
<t>Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option</t>
<t>Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients</t>
</list>
</t>
<t>
The RADIUS/TLS transport provides authentication and encryption
between RADIUS peers. In the presence of proxies, the intermediate proxies can
still inspect the individual RADIUS packets, i.e. "end-to-end" encryption is not
provided. Where intermediate proxies are untrusted, it is desirable to use other
RADIUS mechanisms to prevent RADIUS packet payload from inspection by such
proxies. One common method to protect passwords is the use of EAP methods which
utilize TLS.
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>No new RADIUS attributes or packet codes are defined. IANA is requested to update the already-assigned TCP port number 2083 in the following ways:
<list style= "symbols">
<t>Reference: list the RFC number of this document as the reference</t>
<t>Assignment Notes: add the text "The TCP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC. This early implementation can be configured to be compatible to RADIUS/TLS as specified by the IETF. See RFC (RFC number of this document), <xref target="radiator" /> for details."</t>
</list>
</t>
</section>
<section title="Notes to the RFC Editor" anchor="editor">
<t><xref target="I-D.ietf-radext-tcp-transport"/> is currently in the publication queue because it has a normative reference on this draft; it has no other blocking dependencies. The two drafts should be published as an RFC simultaneously, ideally with consequtive numbers. The references in this draft to <xref target="I-D.ietf-radext-tcp-transport"/> should be changed to references to the corresponding RFC prior to publication.</t>
<t>This section, "Notes to the RFC Editor" should be deleted from the draft prior to publication.</t>
</section>
<section title="Acknowledgements" anchor="acks">
<t>RADIUS/TLS was first implemented as "RADSec" by Open Systems
Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS
server product (see <xref target="radsec-whitepaper" />).</t>
<t>Funding and input for the development of this Internet Draft was
provided by the European Commission co-funded project "GEANT2" <xref
target="geant2" /> and further feedback was provided by the TERENA Task Force
Mobility <xref target="terena" />.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2865;
&rfc2866;
<!-- &rfc3268; -->
&rfc4279;
&rfc4785;
&rfc5280;
&rfc5176;
&rfc5246;
&rfc5247;
<!-- <reference anchor="RFC4513">
<front>
<title>Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms</title>
<author initials="R." surname="Harrison"
fullname="Roger Harrison">
<organization abbrev="Novell">Novell,
Inc.</organization>
</author>
<date month="June" year="2006"/>
</front>
<seriesInfo name="RFC" value="4513" />
<format type="TXT" />
</reference> -->
<!--<reference anchor="draft-status-server"
target="http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-01.
txt">
<front>
<title>Use of Status-Server Packets in
RADIUS</title>
<author initials="A." surname="DeKok"
fullname="Alan DeKok">
<organization abbrev="FreeRADIUS">The
FreeRADIUS Server Project</organization>
</author>
<date month="February" year="2007"/>
</front>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-dekok-radius-status-server-01.
txt"/>
</reference>-->
&radius-tcp;
</references>
<references title="Informative References">
&radius-dtls;
&dyn-disc;
&rfc3539;
&rfc3588;
&rfc4346;
&rfc6421;
<reference anchor="radsec-whitepaper"
target="http://www.open.com.au/radiator/radsec-whitepaper.pdf">
<front>
<title>RadSec - a secure, reliable RADIUS
Protocol</title>
<author>
<organization abbrev="OSC">Open System
Consultants</organization>
</author>
<date month="May" year="2005"/>
</front>
<format type="TXT"
target="http://www.open.com.au/radiator/radsec-whitepaper.pdf"/>
</reference>
<reference anchor="MD5-attacks" target="http://www.springerlink.com/content/40867l85727r7084/">
<front>
<title>A Study of the MD5 Attacks: Insights and Improvements</title>
<author initials="J." surname="Black" fullname="John Black">
<organization abbrev="Colorado">University of Colorado at Boulder, USA</organization>
</author>
<author initials="M." surname="Cochran" fullname="Martin Cochran">
<organization abbrev="UColorado">University of Colorado at Boulder, USA</organization>
</author>
<author initials="T." surname="Highland" fullname="Trevor Highland">
<organization abbrev="UTexas">University of Texas at Austin, USA</organization>
</author>
<date month="October" year="2006"/>
</front>
<format type="TXT" target="http://www.springerlink.com/content/40867l85727r7084/"/>
</reference>
<!-- <reference anchor="radiator-manual"
target="http://www.open.com.au/radiator/ref.html">
<front>
<title>Radiator Radius Server - Installation and
Reference Manual</title>
<author>
<organization abbrev="OSC">Open System
Consultants</organization>
</author>
<date year="2006"/>
</front>
<format type="TXT"
target="http://www.open.com.au/radiator/ref.html"/>
</reference> -->
<!-- <reference anchor="opendiameter" target="http://www.opendiameter.org/">
<front>
<title>Open Diameter</title>
<author>
<organization abbrev="ODP">Open Diameter
Project</organization>
</author>
<date year="2006"/>
</front>
<format type="TXT" target="http://www.opendiameter.org/"/>
</reference>
<reference anchor="jdiameter" target="https://jdiameter.dev.java.net/">
<front>
<title>JDiameter Project Homepage</title>
<author initials="E." surname="Svenson" fullname="Erik
Svenson">
<organization/>
</author>
<date year="2006"/>
</front>
<format type="TXT" target="https://jdiameter.dev.java.net/"/>
</reference> -->
<reference anchor="radsecproxy-impl"
target="http://software.uninett.no/radsecproxy/">
<front>
<title>radsecproxy Project Homepage</title>
<author initials="S." surname="Venaas" fullname="Stig
Venaas">
<organization
abbrev="UNINETT">UNINETT</organization>
</author>
<date year="2007"/>
</front>
<format type="TXT"
target="http://software.uninett.no/radsecproxy/"/>
</reference>
<reference anchor="eduroam" target="http://www.eduroam.org/">
<front>
<title>eduroam Homepage</title>
<author>
<organization abbrev="TERENA">Trans-European
Research and Education Networking Association</organization>
</author>
<date year="2007"/>
</front>
<format type="TXT" target="http://www.eduroam.org/"/>
</reference>
<reference anchor="geant2" target="http://www.geant2.net/">
<front>
<title>European Commission Information Society and
Media: GEANT2</title>
<author>
<organization abbrev="Dante">Delivery of
Advanced Network Technology to Europe</organization>
</author>
<date year="2008"/>
</front>
<format type="TXT" target="http://www.geant2.net/"/>
</reference>
<reference anchor="terena" target="http://www.terena.org/">
<front>
<title>Trans-European Research and Education Networking
Association</title>
<author>
<organization
abbrev="TERENA">TERENA</organization>
</author>
<date year="2008"/>
</front>
<format type="TXT" target="http://www.terena.org/"/>
</reference>
</references>
<section title="Implementation Overview: Radiator" anchor="radiator">
<t>Radiator implements the RadSec protocol for proxying requests
with the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator
configuration file.</t>
<t>The <AuthBy RADSEC> clause defines a RadSec client, and
causes Radiator to send RADIUS requests to the configured RadSec server using
the RadSec protocol.</t>
<t>The <ServerRADSEC> clause defines a RadSec server, and
causes Radiator to listen on the configured port and address(es) for connections
from <Authby RADSEC> clients. When an <Authby RADSEC> client
connects to a <ServerRADSEC> server, the client sends RADIUS requests
through the stream to the server. The server then handles the request in the
same way as if the request had been received from a conventional UDP RADIUS
client.</t>
<t>Radiator is compliant to RADIUS/TLS if the following
options are used:
<list style="empty">
<t><AuthBy RADSEC>
<list style="symbols">
<t>Protocol tcp</t>
<t>UseTLS</t>
<t>TLS_CertificateFile</t>
<t>Secret radsec</t>
</list>
</t>
<t><ServerRADSEC>
<list style="symbols">
<t>Protocol tcp</t>
<t>UseTLS</t>
<t>TLS_RequireClientCert</t>
<t>Secret radsec</t>
</list>
</t>
</list>
As of Radiator 3.15, the default shared secret for RadSec
connections is configurable and defaults to "mysecret" (without quotes). For
compliance with this document, this setting needs to be configured for the
shared secret "radsec". The implementation uses TCP keepalive socket options,
but does not send Status-Server packets. Once established, TLS connections are
kept open throughout the server instance lifetime.
</t>
</section>
<section title="Implementation Overview: radsecproxy" anchor="radsecproxy">
<t>The RADIUS proxy named radsecproxy was written in order to allow
use of RadSec in current RADIUS deployments. This is a generic proxy that
supports any number and combination of clients and servers, supporting RADIUS
over UDP and RadSec. The main idea is that it can be used on the same host as a
non-RadSec client or server to ensure RadSec is used on the wire, however as a
generic proxy it can be used in other circumstances as well.</t>
<t>The configuration file consists of client and server clauses,
where there is one such clause for each client or server. In such a clause one
specifies either "type tls" or "type udp" for RadSec or UDP transport. For
RadSec the default shared secret "mysecret" (without quotes), the same as
Radiator, is used. For compliance with this document, this setting needs to be
configured for the shared secret "radsec". A secret may be specified by putting
say "secret somesharedsecret" inside a client or server clause.</t>
<t>In order to use TLS for clients and/or servers, one must also
specify where to locate CA certificates, as well as certificate and key for the
client or server. This is done in a TLS clause. There may be one or several TLS
clauses. A client or server clause may reference a particular TLS clause, or
just use a default one. One use for multiple TLS clauses may be to present one
certificate to clients and another to servers.</t>
<t>If any RadSec (TLS) clients are configured, the proxy will at
startup listen on port 2083, as assigned by IANA for the OSC RadSec
implementation. An alternative port may be specified. When a client connects,
the client certificate will be verified, including checking that the configured
FQDN or IP address matches what is in the certificate. Requests coming from a
RadSec client are treated exactly like requests from UDP clients.
</t>
<t>The proxy will at startup try to establish a TLS connection to
each (if any) of the configured RadSec (TLS) servers. If it fails to connect to
a server, it will retry regularly. There is some back-off where it will retry
quickly at first, and with longer intervals later. If a connection to a server
goes down it will also start retrying regularly. When setting up the TLS
connection, the server certificate will be verified, including checking that the
configured 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.</t>
<t>The proxy supports Status-Server messages. They are only sent to
a server if enabled for that particular server. Status-Server requests are
always responded to.</t>
<t>This RadSec implementation has been successfully tested together
with Radiator. It is a freely available open-source implementation. For source
code and documentation, see <xref target="radsecproxy-impl" />.</t>
</section>
<section title="Assessment of Crypto-Agility Requirements" anchor="crypto-agility">
<t>The RADIUS Crypto-Agility Requirements <xref target="RFC6421"/> defines
numerous classification criteria for protocols that strive to enhance the security
of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile
protocols have to fulfill. The authors believe that the following assessment
about the crypto-agility properties of RADIUS/TLS are true.</t>
<t>By virtue of operating on the transport layer with TLS, the cryptographically agile
properties of TLS are inherited, and RADIUS/TLS subsequently meets the following points:
<list>
<t>(M) negotiation of cryptographic algorithms for integrity and auth</t>
<t>(M) negotiation of cryptographic algorithms for encryption</t>
<t>(M) replay protection</t>
<t>(M) define mandatory-to-implement cryptographic algorithms</t>
<t>(M) generate fresh session keys for use between client and server</t>
<t>(R) support for Perfect Forward Secrecy in session keys</t>
<t>(R) support X.509 certificate based operation</t>
<t>(R) support Pre-Shared keys</t>
<t>(R) support for confidentiality of the entire packet</t>
<t>(M/R) support Automated Key Management</t>
</list>
</t>
<t>The remainder of the requirements is discussed individually below in more detail:
<list>
<t>(M) "avoid security compromise, even in situations where the existing cryptographic alogrithms used by RADIUS implementations are shown to be weak enough to provide little or no security" - The existing algorithm, based on MD5, is not of any significance in RADIUS/TLS; its compromise does not compromise the outer transport security.</t>
<t>(R) mandatory-to-implement alogrithms are to be NIST-Acceptable with no deprecation date - The mandatory-to-implement algorithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three-key 3DES operation, which is classified as Acceptable with no known deprecation date by NIST.</t>
<t>(M) demonstrate backward compatibility with RADIUS - There are multiple implementations supporting both RADIUS and RADIUS/TLS, and the translation between them.</t>
<t>(M) After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible - In RADIUS, communication between client and server is always a manual configuration; after a compromise, the legacy client in question can be de-configured by the same manual configuration.</t>
<t>(M) indicate a willingness to cede change control to the IETF - Change control of this protocol is with the IETF.</t>
<t>(M) be interoperable between implementations based purely on the information in the specification - At least one implementation was created exclusively based on this specification and is interoperable with other RADIUS/TLS implementations.</t>
<t>(M) apply to all packet types - RADIUS/TLS operates on the transport layer, and can carry all packet types.</t>
<t>(R) message data exchanged with Diameter SHOULD NOT be affected - The solution is Diameter-agnostic.</t>
<t>(M) discuss any inherent assumptions - The authors are not aware of any implicit assumptions which would be yet-unarticulated in the draft</t>
<t>(R) provide recommendations for transition - The Security Considerations section contains a transition path.</t>
<t>(R) discuss legacy interoperability and potential for bidding-down attacks - The Security Considerations section contains an corresponding discussion.</t>
</list>
</t>
<t>Summarizing, it is believed that this specification fulfills all the mandatory and all the recommended requirements for a crypto-agile solution and should thus be considered UNCONDITIONALLY COMPLIANT.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:14 |