draft-ietf-radext-radsec-10.txt   draft-ietf-radext-radsec-11.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: July 12, 2012 OSC Expires: July 30, 2012 OSC
S. Venaas S. Venaas
UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
January 9, 2012 January 27, 2012
TLS encryption for RADIUS TLS encryption for RADIUS
draft-ietf-radext-radsec-10 draft-ietf-radext-radsec-11
Abstract Abstract
This document specifies security on the transport layer (TLS) for the This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP. This enables dynamic RADIUS protocol when transmitted over TCP. This enables dynamic
trust relationships between RADIUS servers. trust relationships between RADIUS servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2012. This Internet-Draft will expire on July 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 24
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5
2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9
3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 3.3. Ciphersuites and Compression Negotiation Considerations . 10
3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10
4. Compatibility with other RADIUS transports . . . . . . . . . . 11 4. Compatibility with other RADIUS transports . . . . . . . . . . 11
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18
1. Introduction 1. Introduction
The RADIUS protocol [RFC2865] is a widely deployed authentication and The RADIUS protocol [RFC2865] is a widely deployed authentication and
authorisation protocol. The supplementary RADIUS Accounting authorisation protocol. The supplementary RADIUS Accounting
specification [RFC2866] also provides accounting mechanisms, thus specification [RFC2866] also provides accounting mechanisms, thus
delivering a full AAA solution. However, RADIUS is experiencing delivering a full AAA solution. However, RADIUS is experiencing
skipping to change at page 3, line 40 skipping to change at page 3, line 40
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 RADIUS relevant data while forwarding requests. The new features in RADIUS
over TLS obsolete the use of IP addresses and shared MD5 secrets to over TLS obsolete the use of IP addresses and shared MD5 secrets to
identify other peers and thus allow the dynamic establishment of identify other peers and thus allow the use of more contemporary
connections to peers that are not previously configured, and thus trust models, e.g. checking a certificate by inspecting the issuer
makes it possible to avoid aggregation-only RADIUS proxies and reduce and other certificate properties.
the number of middleboxes which can eavesdrop on traffic. One
mechanism to discover RADIUS over TLS peers with DNS is specified in
[I-D.ietf-radext-dynamic-discovery].
1.1. Requirements Language 1.1. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119. [RFC2119] interpreted as described in RFC 2119. [RFC2119]
1.2. Terminology 1.2. Terminology
skipping to change at page 4, line 18 skipping to change at page 4, line 17
RADIUS/TLS node: a RADIUS over TLS client or server RADIUS/TLS node: a RADIUS over TLS client or server
RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new
connection. connection.
RADIUS/TLS Server: a RADIUS over TLS instance which listens on a RADIUS/TLS Server: a RADIUS over TLS instance which listens on a
RADIUS over TLS port and accepts new connections RADIUS over TLS port and accepts new connections
RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]
1.3. Document Status
This document is an Experimental RFC.
It is one out of several approaches to address known cryptographic
weaknesses of the RADIUS protocol (see also Section 4). The
specification does not fulfill all recommendations on a AAA transport
profile as per [RFC3539]; in particular, by being based on TCP as a
transport layer, it does not prevent head-of-line blocking issues.
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.
An example for a world-wide roaming environment that uses RADIUS over
TLS to secure communication is "eduroam", see [eduroam].
2. Normative: Transport Layer Security for RADIUS/TCP 2. Normative: Transport Layer Security for RADIUS/TCP
2.1. TCP port and packet types 2.1. TCP port and packet types
The default destination port number for RADIUS over TLS is TCP/2083. The default destination port number for RADIUS over TLS is TCP/2083.
There are no separate ports for authentication, accounting and There are no separate ports for authentication, accounting and
dynamic authorisation changes. The source port is arbitrary. See dynamic authorisation changes. The source port is arbitrary. See
section Section 3.3 (4) and (5) for considerations regarding section Section 3.4 for considerations regarding separation of
separation of authentication, accounting and dynauth traffic. authentication, accounting and dynauth traffic.
2.2. TLS negotiation 2.2. TLS negotiation
RADIUS/TLS has no notion of negotiating TLS in an established RADIUS/TLS has no notion of negotiating TLS in an established
connection. Servers and clients need to be preconfigured to use connection. Servers and clients need to be preconfigured to use
RADIUS/TLS for a given endpoint. RADIUS/TLS for a given endpoint.
2.3. Connection Setup 2.3. Connection Setup
RADIUS/TLS nodes RADIUS/TLS nodes
1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport].
Failure to connect leads to continuous retries, with Failure to connect leads to continuous retries, with
exponentially growing intervals between every try. If multiple exponentially growing intervals between every try. If multiple
servers are defined, the node MAY attempt to establish a servers are defined, the node MAY attempt to establish a
connection to these other servers in parallel, in order to connection to these other servers in parallel, in order to
implement quick failover. implement quick failover.
2. after completing the TCP handshake, immediately negotiate TLS 2. after completing the TCP handshake, immediately negotiate TLS
sessions. The following restrictions apply: according to sessions according to [RFC5246] or its predecessor TLS 1.1. The
[RFC5246] or its predecessor TLS 1.1. The following restrictions following restrictions apply:
apply:
* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2
[RFC5246] ]) is REQUIRED. [RFC5246] ]) is REQUIRED.
* Support for certificate-based mutual authentication is * Support for certificate-based mutual authentication is
REQUIRED. REQUIRED.
* Negotiation of mutual authentication is REQUIRED. * Negotiation of mutual authentication is REQUIRED.
* Negotiation of a ciphersuite providing for confidentiality as * Negotiation of a ciphersuite providing for confidentiality as
well as integrity protection is REQUIRED. well as integrity protection is REQUIRED.
* Support for and negotiation of compression is OPTIONAL. * Support for and negotiation of compression is OPTIONAL.
* Support for TLS-PSK mutual authentication [RFC4279] is * Support for TLS-PSK mutual authentication [RFC4279] is
OPTIONAL. OPTIONAL.
* RADIUS/TLS implementations MUST at a minimum support * RADIUS/TLS implementations MUST at a minimum support
negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD
support TLS_RSA_WITH_RC4_128_SHA and support TLS_RSA_WITH_RC4_128_SHA and
TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 (1) ).
* In addition, RADIUS/TLS implementations MUST support * In addition, RADIUS/TLS implementations MUST support
negotiation of the mandatory-to-implement ciphersuites negotiation of the mandatory-to-implement ciphersuites
required by the versions of TLS that they support. required by the versions of TLS that they support.
* RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL
encryption (e.g. [RFC4785]). encryption (e.g. [RFC4785]).
3. If TLS is used in an X.509 certificate based operation mode, the 3. If TLS is used in an X.509 certificate based operation mode, the
following list of certificate validation options applies: following list of certificate validation options applies:
* Implementations MUST allow to configure a list of acceptable * Implementations MUST allow to configure a list of acceptable
Certification Authorities for incoming connections. Certification Authorities for incoming connections.
* Certificate validation MUST include the verification rules as * Certificate validation MUST include the verification rules as
per [RFC5280]. per [RFC5280].
* Implementations SHOULD indicate their acceptable Certification * Implementations SHOULD indicate their acceptable Certification
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.2)
* 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.
Implementations MUST support SHA-1 as the hash algorithm and Implementations MUST support SHA-1 as the hash algorithm and
use the ASCII label "sha-1" to identify the SHA-1 algorithm. 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 The length of a SHA-1 hash is 20 bytes and the length of the
corresponding fingerprint string is 65 characters. An example corresponding fingerprint string is 65 characters. An example
certificate fingerprint is: sha- certificate fingerprint is: sha-
skipping to change at page 6, line 19 skipping to change at page 6, line 37
IP addresses can be contained in the Common Name (CN) or IP addresses can be contained in the Common Name (CN) or
subjectAltName entries. For verification, only one of these subjectAltName entries. For verification, only one of these
entries is to be considered. The following precedence entries is to be considered. The following precedence
applies: for DNS name validation, subjectAltName:DNS has applies: for DNS name validation, subjectAltName:DNS has
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.4 (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.4 (2) ).
2.4. Connecting Client Identity 2.4. Connecting Client Identity
In RADIUS/UDP, clients are uniquely identified by their IP address. In RADIUS/UDP, clients are uniquely identified by their IP address.
Since the shared secret is associated with the origin IP address, if Since the shared secret is associated with the origin IP address, if
more than one RADIUS client is associated with the same IP address, more than one RADIUS client is associated with the same IP address,
then those clients also must utilize the same shared secret, a then those clients also must utilize the same shared secret, a
practice which is inherently insecure as noted in [RFC5247]. practice which is inherently insecure as noted in [RFC5247].
RADIUS/TLS supports multiple operation modes. RADIUS/TLS supports multiple operation modes.
skipping to change at page 7, line 36 skipping to change at page 8, line 4
o Originating IP address o Originating IP address
o TLS Identifier o TLS Identifier
2.5. RADIUS Datagrams 2.5. 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:
RADIUS/TLS clients transmit the same packet types on the connection RADIUS/TLS clients transmit the same packet types on the connection
they initiated as a RADIUS/UDP client would (see Section 3.3 (3) and they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and
(4) ). E.g. they send (4) ). E.g. they send
o Access-Request o Access-Request
o Accounting-Request o Accounting-Request
o Status-Server o Status-Server
o Disconnect-ACK o Disconnect-ACK
skipping to change at page 8, line 34 skipping to change at page 9, line 4
o ... o ...
and they receive and they receive
o Access-Request o Access-Request
o Accounting-Request o Accounting-Request
o Status-Server o Status-Server
o Disconnect-ACK o Disconnect-ACK
o ... o ...
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. Implications of Dynamic Peer Discovery
One mechanism to discover RADIUS over TLS peers dynamically via DNS
is specified in [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.
Readers of this document who are considering the deployment of DNS-
based dynamic discovery are thus encouraged to read
[I-D.ietf-radext-dynamic-discovery] and follow its future
development.
3.2. X.509 Certificate Considerations
(1) If a RADIUS/TLS client is in possession of multiple certificates (1) If a RADIUS/TLS client is in possession of multiple certificates
from 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
skipping to change at page 9, line 19 skipping to change at page 10, line 5
(2) If a RADIUS/TLS server is in possession of multiple certificates (2) If a RADIUS/TLS server is in possession of multiple certificates
from different CAs (i.e. is part of multiple roaming consortia), it from different CAs (i.e. is part of multiple roaming consortia), it
will need to select one of its certificates to present to the RADIUS/ will need to select one of its certificates to present to the RADIUS/
TLS client. If the client sends the Trusted CA Indication, this hint TLS client. If the client sends the Trusted CA Indication, this hint
can make the server select the appropriate certificate and prevent a can make the server select the appropriate certificate and prevent a
handshake failure. Omitting this indication makes it impossible to handshake failure. Omitting this indication makes it impossible to
deterministically select the right certificate in this case. If deterministically select the right certificate in this case. If
there is no risk of confusing multiple roaming consortia, providing there is no risk of confusing multiple roaming consortia, providing
this indication in the handshake is not crucial. this indication in the handshake is not crucial.
(3) If dynamic peer discovery as per 3.3. Ciphersuites and Compression Negotiation Considerations
[I-D.ietf-radext-dynamic-discovery] is used, peer authentication
alone is not sufficient; the peer must also be authorised to perform
user authentications. In these cases, the trust fabric cannot depend
on peer authentication methods like DNSSEC to identify RADIUS/TLS
nodes. The nodes also need to be properly authorised. Typically,
this can be achieved by adding appropriate authorisation fields into
a X.509 certificate. Such fields include SRV authority [RFC4985],
subjectAltNames, or a defined list of certificate fingerprints.
Operators of a RADIUS/TLS infrastructure should define their own
authorisation trust model and apply this model to the certificates.
The checks enumerated in Section 2.3 provide sufficient flexibility
for the implementation of authorisation trust models.
3.2. Ciphersuites and Compression Negotiation Considerations
Not all TLS ciphersuites in [RFC5246] are supported by available TLS Not all TLS ciphersuites in [RFC5246] are supported by available TLS
tool kits, and licenses may be required in some cases. The existing tool kits, and licenses may be required in some cases. The existing
implementations of RADIUS/TLS use OpenSSL as cryptographic backend, implementations of RADIUS/TLS use OpenSSL as cryptographic backend,
which supports all of the ciphersuites listed in the rules in the which supports all of the ciphersuites listed in the rules in the
normative section. normative section.
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
implement according to [RFC5246] and thus has to be supported by implement according to [RFC5246] and thus has to be supported by
RADIUS/TLS 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.4. 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 RADIUS/UDP, the packet exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet
size can be determined by evaluating the size of the datagram that size can be determined by evaluating the size of the datagram that
arrived. Due to the stream nature of TCP and TLS, this does not hold arrived. Due to the stream nature of TCP and TLS, this does not hold
true for RADIUS/TLS packet exchange. Instead, packet boundaries of true for RADIUS/TLS packet exchange. Instead, packet boundaries of
RADIUS packets that arrive in the stream are calculated by evaluating RADIUS packets that arrive in the stream are calculated by evaluating
the packet's Length field. Special care needs to be taken on the the packet's Length field. Special care needs to be taken on the
packet sender side that the value of the Length field is indeed packet sender side that the value of the Length field is indeed
correct before sending it over the TLS tunnel, because incorrect correct before sending it over the TLS tunnel, because incorrect
skipping to change at page 10, line 47 skipping to change at page 11, line 14
acceptable packet types for clients and servers mirror the packet acceptable packet types for clients and servers mirror the packet
flow behaviour from RADIUS/UDP. flow behaviour from RADIUS/UDP.
(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
allocated UDP port to signal that a peer RADIUS server does not allocated UDP port to signal that a peer RADIUS server does not
support reception and processing of the packet types in [RFC5176]. support reception and processing of the packet types in [RFC5176].
These packet types are listed as to be received in RADIUS/TLS These packet types are listed as to be received in RADIUS/TLS
implementations. Note well: it is not required for an implementation implementations. Note well: it is not required for an implementation
to actually process these packet types. It is sufficient that upon to actually process these packet types. It is sufficient that upon
receiving such a packet, an unconditional NAK is sent back to receiving such a packet, an unconditional NAK is sent back to
indicate that the action is not supported. indicate that the action is not supported. The NAK SHOULD contain an
attribute Error-Cause with the value 406 ("Unsupported Extension");
see [RFC5176] for details.
(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly (5) RADIUS/UDP [RFC2865] uses 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 RADIUS Accounting packets. There support reception and processing of RADIUS Accounting packets. There
is no RADIUS datagram to signal an Accounting NAK. Clients may be is no RADIUS datagram to signal an Accounting NAK. Clients may be
misconfigured to send Accounting packets to a RADIUS/TLS server which misconfigured to send Accounting packets to a RADIUS/TLS server which
does not wish to process their Accounting packet. The server will does not wish to process their Accounting packet. The server will
need to silently drop the packet. The client will need to deduce need to silently drop the packet. The client will need to deduce
from the absence of replies that it is misconfigured; no negative from the absence of replies that it is misconfigured; no negative
ICMP response will reveal this. ICMP response will reveal this.
skipping to change at page 11, line 35 skipping to change at page 12, line 5
transports, which is 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
client to a server is a manual administrative action. An automatic
fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
bidding attacks on the peer communication.
5. Diameter Compatibility 5. Diameter Compatibility
Since RADIUS/TLS is only a new transport profile for RADIUS, Since RADIUS/TLS is only a new transport profile for RADIUS,
compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP
[RFC2865] - Diameter [RFC3588] is identical. The considerations [RFC2865] - Diameter [RFC3588] is identical. The considerations
regarding payload size in [I-D.ietf-radext-tcp-transport] apply. regarding payload size in [I-D.ietf-radext-tcp-transport] apply.
6. Security Considerations 6. Security Considerations
The computational resources to establish a TLS tunnel are The computational resources to establish a TLS tunnel are
significantly higher than simply sending mostly unencrypted UDP significantly higher than simply sending mostly unencrypted UDP
datagrams. Therefore, clients connecting to a RADIUS/TLS node will datagrams. Therefore, clients connecting to a RADIUS/TLS node will
more easily create high load conditions and a malicious client might more easily create high load conditions and a malicious client might
create a Denial-of-Service attack more easily. create a Denial-of-Service attack more easily.
In the case of dynamic peer discovery as per
[I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
able to accept connections from a large, not previously known, group
of hosts, possibly the whole internet. In this case, the server's
RADIUS/TLS port can not be protected from unauthorised connection
attempts with measures on the network layer, i.e. access lists and
firewalls. This opens more attack vectors for Distributed Denial of
Service attacks, just like any other service that is supposed to
serve arbitrary clients (like for example web servers).
In the case of dynamic peer discovery as per
[I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
proof of authorisation for a connecting RADIUS/TLS nodes. Special
care needs to be taken that certificates get verified properly
according to the chosen trust model (particularly: consulting CRLs,
checking critical extensions, checking subjectAltNames etc.) to
prevent unauthorised connections.
Some TLS ciphersuites only provide integrity validation of their Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification forbids the payload, and provide no encryption. This specification forbids the
use of such ciphersuites. Since the RADIUS payload's shared secret use of such ciphersuites. Since the RADIUS payload's shared secret
is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , is fixed to the well-known term "radsec" (see Section 2.3 (4) ) ,
failure to comply with this requirement will expose the entire failure to comply with this requirement will expose the entire
datagram payload in plain text, including User-Password, to datagram payload in plain text, including User-Password, to
intermediate IP nodes. intermediate IP nodes.
If peer communication between two devices is configured for both If peer communication between two devices is configured for both
RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic RADIUS/TLS transport (i.e TLS security on the transport layer, shared
RADIUS security opens the way for a down-bidding attack if an 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 adversary can maliciously close the TCP connection, or prevent it
from being established. In this case, security of the packet payload from being established. Situations where clients are configured in
is reduced from the selected TLS cipher suite packet encryption to such a way are likely to occur during a migration phase from RADIUS/
the classic MD5 per-attribute encryption. Such an attack can be UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker
mitigated by delisting the RADIUS/UDP client from the server can reduce the security of the packet payload from the selected TLS
configuration after successfully migrating that client to RADIUS/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:
o Client side: de-configure the failover setup, leaving RADIUS/TLS
as the only communication option
o Server side: de-configure the RADIUS/UDP client from the list of
valid RADIUS clients
The RADIUS/TLS transport provides authentication and encryption The RADIUS/TLS transport provides authentication and encryption
between RADIUS peers. In the presence of proxies, the intermediate between RADIUS peers. In the presence of proxies, the intermediate
proxies can still inspect the individual RADIUS packets, i.e. "end- proxies can still inspect the individual RADIUS packets, i.e. "end-
to-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 No new RADIUS attributes or packet codes are defined. IANA is
previously assigned by IANA for RadSec, an early implementation of requested to update the already-assigned TCP port number 2083 in the
RADIUS/TLS. No new RADIUS attributes or packet codes are defined. following ways:
8. Acknowledgements o Reference: list the RFC number of this document as the reference
o 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),
Appendix A for details."
8. Notes to the RFC Editor
[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 [I-D.ietf-radext-tcp-transport] should be changed to
references to the corresponding RFC prior to publication.
This section, "Notes to the RFC Editor" should be deleted from the
draft prior to publication.
9. Acknowledgements
RADIUS/TLS was first implemented as "RADSec" by Open Systems RADIUS/TLS was first implemented as "RADSec" by Open Systems
Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS
server product (see [radsec-whitepaper]). server product (see [radsec-whitepaper]).
Funding and input for the development of this Internet Draft was Funding and input for the development of this Internet Draft was
provided by the European Commission co-funded project "GEANT2" provided by the European Commission co-funded project "GEANT2"
[geant2] and further feedback was provided by the TERENA Task Force [geant2] and further feedback was provided by the TERENA Task Force
Mobility [terena]. Mobility [terena].
9. References 10. References
10.1. Normative References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use [RFC2119] Bradner, S., "Key words for use
in RFCs to Indicate Requirement in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, [RFC2865] Rigney, C., Willens, S., Rubens,
A., and W. Simpson, "Remote A., and W. Simpson, "Remote
Authentication Dial In User Authentication Dial In User
Service (RADIUS)", RFC 2865, Service (RADIUS)", RFC 2865,
skipping to change at page 13, line 52 skipping to change at page 14, line 32
Transport Layer Security (TLS)", Transport Layer Security (TLS)",
RFC 4279, December 2005. RFC 4279, December 2005.
[RFC4785] Blumenthal, U. and P. Goel, [RFC4785] Blumenthal, U. and P. Goel,
"Pre-Shared Key (PSK) "Pre-Shared Key (PSK)
Ciphersuites with NULL Ciphersuites with NULL
Encryption for Transport Layer Encryption for Transport Layer
Security (TLS)", RFC 4785, Security (TLS)", RFC 4785,
January 2007. January 2007.
[RFC4985] Santesson, S., "Internet X.509
Public Key Infrastructure
Subject Alternative Name for
Expression of Service Name",
RFC 4985, August 2007.
[RFC5280] Cooper, D., Santesson, S., [RFC5280] Cooper, D., Santesson, S.,
Farrell, S., Boeyen, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, Housley, R., and W. Polk,
"Internet X.509 Public Key "Internet X.509 Public Key
Infrastructure Certificate and Infrastructure Certificate and
Certificate Revocation List Certificate Revocation List
(CRL) Profile", RFC 5280, (CRL) Profile", RFC 5280,
May 2008. May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, [RFC5176] Chiba, M., Dommety, G., Eklund,
skipping to change at page 14, line 42 skipping to change at page 15, line 17
Eronen, "Extensible Eronen, "Extensible
Authentication Protocol (EAP) Authentication Protocol (EAP)
Key Management Framework", Key Management Framework",
RFC 5247, August 2008. RFC 5247, August 2008.
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr
aft-ietf-radext-tcp-transport-09 aft-ietf-radext-tcp-transport-09
(work in progress), (work in progress),
October 2010. October 2010.
9.2. Informative References 10.2. Informative References
[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport
Layer for RADIUS", Layer for RADIUS",
draft-ietf-radext-dtls-01 (work draft-ietf-radext-dtls-01 (work
in progress), October 2010. in progress), October 2010.
[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley,
"NAI-based Dynamic Peer "NAI-based Dynamic Peer
Discovery for RADIUS/TLS and Discovery for RADIUS/TLS and
RADIUS/DTLS", draft-ietf-radext- RADIUS/DTLS", draft-ietf-radext-
dynamic-discovery-03 (work in dynamic-discovery-03 (work in
progress), July 2011. progress), July 2011.
[RFC3539] Aboba, B. and J. Wood,
"Authentication, Authorization
and Accounting (AAA) Transport
Profile", RFC 3539, June 2003.
[RFC3588] Calhoun, P., Loughney, J., [RFC3588] Calhoun, P., Loughney, J.,
Guttman, E., Zorn, G., and J. Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", Arkko, "Diameter Base Protocol",
RFC 3588, September 2003. RFC 3588, September 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The [RFC4346] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS) Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, Protocol Version 1.1", RFC 4346,
April 2006. April 2006.
[RFC6421] Nelson, D., "Crypto-Agility
Requirements for Remote
Authentication Dial-In User
Service (RADIUS)", RFC 6421,
November 2011.
[radsec-whitepaper] Open System Consultants, "RadSec [radsec-whitepaper] Open System Consultants, "RadSec
- a secure, reliable RADIUS - a secure, reliable RADIUS
Protocol", May 2005, <http:// Protocol", May 2005, <http://
www.open.com.au/radiator/ www.open.com.au/radiator/
radsec-whitepaper.pdf>. radsec-whitepaper.pdf>.
[MD5-attacks] Black, J., Cochran, M., and T. [MD5-attacks] Black, J., Cochran, M., and T.
Highland, "A Study of the MD5 Highland, "A Study of the MD5
Attacks: Insights and Attacks: Insights and
Improvements", October 2006, <ht Improvements", October 2006, <ht
skipping to change at page 16, line 23 skipping to change at page 17, line 8
using the RadSec protocol. using the RadSec protocol.
The <ServerRADSEC> clause defines a RadSec server, and causes The <ServerRADSEC> clause defines a RadSec server, and causes
Radiator to listen on the configured port and address(es) for Radiator to listen on the configured port and address(es) for
connections from <Authby RADSEC> clients. When an <Authby RADSEC> connections from <Authby RADSEC> clients. When an <Authby RADSEC>
client connects to a <ServerRADSEC> server, the client sends RADIUS client connects to a <ServerRADSEC> server, the client sends RADIUS
requests through the stream to the server. The server then handles 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 the request in the same way as if the request had been received from
a conventional UDP RADIUS client. a conventional UDP RADIUS client.
Radiator is compliant to version 2 of RadSec if the following options Radiator is compliant to RADIUS/TLS if the following options are
are used: used:
<AuthBy RADSEC> <AuthBy RADSEC>
* Protocol tcp * Protocol tcp
* UseTLS * UseTLS
* TLS_CertificateFile * TLS_CertificateFile
* Secret radsec * Secret radsec
skipping to change at page 18, line 11 skipping to change at page 18, line 46
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 [radsecproxy-impl]. source code and documentation, see [radsecproxy-impl].
Appendix C. Assessment of Crypto-Agility Requirements Appendix C. Assessment of Crypto-Agility Requirements
The RADIUS Crypto-Agility Requirements (link to RFC once issued here) The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous
defines numerous classification criteria for protocols that strive to classification criteria for protocols that strive to enhance the
enhance the security of RADIUS. It contains mandatory (M) and security of RADIUS. It contains mandatory (M) and recommended (R)
recommended (R) criteria which crypto-agile protocols have to criteria which crypto-agile protocols have to fulfill. The authors
fulfill. The authors believe that the following assessment about the believe that the following assessment about the crypto-agility
crypto-agility properties of RADIUS/TLS are true. properties of RADIUS/TLS are true.
By virtue of operating on the transport layer with TLS, the By virtue of operating on the transport layer with TLS, the
cryptographically agile properties of TLS are inherited, and RADIUS/ cryptographically agile properties of TLS are inherited, and RADIUS/
TLS subsequently meets the following points: TLS subsequently meets the following points:
(M) negotiation of cryptographic algorithms for integrity and auth (M) negotiation of cryptographic algorithms for integrity and auth
(M) negotiation of cryptographic algorithms for encryption (M) negotiation of cryptographic algorithms for encryption
(M) replay protection (M) replay protection
skipping to change at page 20, line 30 skipping to change at page 21, line 17
9 Bulbul Place 9 Bulbul Place
Currumbin Waters QLD 4223 Currumbin Waters QLD 4223
AUSTRALIA AUSTRALIA
Phone: +61 7 5598 7474 Phone: +61 7 5598 7474
Fax: +61 7 5598 7070 Fax: +61 7 5598 7070
EMail: mikem@open.com.au EMail: mikem@open.com.au
URI: http://www.open.com.au. URI: http://www.open.com.au.
Stig Venaas Stig Venaas
UNINETT cisco Systems
Abels gate 5 - Teknobyen Tasman Drive
Trondheim 7465 San Jose, CA 95134
NORWAY USA
Phone: +47 73 55 79 00 EMail: stig@cisco.com
Fax: +47 73 55 79 01
EMail: stig.venaas@uninett.no
URI: http://www.uninett.no.
Klaas Wierenga Klaas Wierenga
Cisco Systems International BV Cisco Systems International BV
Haarlerbergweg 13-19 Haarlerbergweg 13-19
Amsterdam 1101 CH Amsterdam 1101 CH
The Netherlands The Netherlands
Phone: +31 (0)20 3571752 Phone: +31 (0)20 3571752
Fax: Fax:
EMail: kwiereng@cisco.com EMail: kwiereng@cisco.com
 End of changes. 39 change blocks. 
111 lines changed or deleted 140 lines changed or added

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