draft-ietf-radext-radsec-12.txt   rfc6614.txt 
RADIUS Extensions Working Group S. Winter Internet Engineering Task Force (IETF) S. Winter
Internet-Draft RESTENA Request for Comments: 6614 RESTENA
Intended status: Experimental M. McCauley Category: Experimental M. McCauley
Expires: August 17, 2012 OSC ISSN: 2070-1721 OSC
S. Venaas S. Venaas
K. Wierenga K. Wierenga
Cisco Cisco
February 14, 2012 May 2012
Transport Layer Security (TLS) encryption for RADIUS Transport Layer Security (TLS) Encryption for RADIUS
draft-ietf-radext-radsec-12
Abstract Abstract
This document specifies a transport profile for RADIUS using This document specifies a transport profile for RADIUS using
Transport Layer Security (TLS) over TCP as the transport protocol. Transport Layer Security (TLS) over TCP as the transport protocol.
This enables dynamic trust relationships between RADIUS servers. This enables dynamic trust relationships between RADIUS servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 17, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6614.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material 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.
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 1.3. Document Status ............................................4
2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 5 2. Normative: Transport Layer Security for RADIUS/TCP ..............5
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 5 2.1. TCP port and Packet Types ..................................5
2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 5 2.2. TLS Negotiation ............................................5
2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 2.3. Connection Setup ...........................................5
2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 7 2.4. Connecting Client Identity .................................7
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 8 2.5. RADIUS Datagrams ...........................................8
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 10 3. Informative: Design Decisions ..................................10
3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 10 3.1. Implications of Dynamic Peer Discovery ....................10
3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 10 3.2. X.509 Certificate Considerations ..........................10
3.3. Ciphersuites and Compression Negotiation Considerations . 11 3.3. Ciphersuites and Compression Negotiation Considerations ...11
3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 11 3.4. RADIUS Datagram Considerations ............................11
4. Compatibility with other RADIUS transports . . . . . . . . . . 12 4. Compatibility with Other RADIUS Transports .....................12
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 13 5. Diameter Compatibility .........................................13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations ........................................13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations ............................................14
8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements ...............................................15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References .....................................................15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References ......................................15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References ....................................16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Implementation Overview: Radiator .....................18
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 18 Appendix B. Implementation Overview: radsecproxy ..................19
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 19 Appendix C. Assessment of Crypto-Agility Requirements .............20
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 20
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 authorization protocol. The supplementary RADIUS Accounting
specification [RFC2866] also provides accounting mechanisms, thus specification [RFC2866] provides accounting mechanisms, thus
delivering a full Authentication, Authorization, and Accounting (AAA) delivering a full Authentication, Authorization, and Accounting (AAA)
solution. However, RADIUS is experiencing several shortcomings, such solution. However, RADIUS is experiencing several shortcomings, such
as its dependency on the unreliable transport protocol UDP and the as its dependency on the unreliable transport protocol UDP and the
lack of security for large parts of its packet payload. RADIUS lack of security for large parts of its packet payload. RADIUS
security is based on the MD5 algorithm, which has been proven to be security is based on the MD5 algorithm, which has been proven to be
insecure. insecure.
The main focus of RADIUS over TLS 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 using TLS. The most important communication between RADIUS/TCP peers using TLS. The most important
use of this specification lies in roaming environments where RADIUS use of this specification lies in roaming environments where RADIUS
packets need to be transferred through different administrative packets need to be transferred through different administrative
domains and untrusted, potentially hostile networks. An example for domains and untrusted, potentially hostile networks. An example for
a world-wide roaming environment that uses RADIUS over TLS to secure a worldwide roaming environment that uses RADIUS over TLS to secure
communication is "eduroam", see [eduroam]. 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 that is used in
in RADIUS to provide integrity protection and a limited RADIUS to provide integrity protection and a limited confidentiality
confidentiality protection (see [MD5-attacks]). RADIUS over TLS protection (see [MD5-attacks]). RADIUS over TLS wraps the entire
wraps the entire RADIUS packet payload into a TLS stream and thus RADIUS packet payload into a TLS stream and thus mitigates the risk
mitigates the risk of attacks on MD5. of 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 the control of 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 use of more contemporary identify other peers and thus allow the use of more contemporary
trust models, e.g. checking a certificate by inspecting the issuer trust models, e.g., checking a certificate by inspecting the issuer
and other certificate properties. and other certificate properties.
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
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 that 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 that 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: a classic RADIUS transport over UDP as defined in
[RFC2865]
1.3. Document Status 1.3. Document Status
This document is an Experimental RFC. This document is an Experimental RFC.
It is one out of several approaches to address known cryptographic It is one out of several approaches to address known cryptographic
weaknesses of the RADIUS protocol (see also Section 4). The weaknesses of the RADIUS protocol (see also Section 4). The
specification does not fulfill all recommendations on a AAA transport specification does not fulfill all recommendations on a AAA transport
profile as per [RFC3539]; in particular, by being based on TCP as a profile as per [RFC3539]; in particular, by being based on TCP as a
transport layer, it does not prevent head-of-line blocking issues. transport layer, it does not prevent head-of-line blocking issues.
If this specification is indeed selected for advancement to standards If this specification is indeed selected for advancement to Standards
track, certificate verification options (section 2.3.2) need to be Track, certificate verification options (Section 2.3, point 2) need
refined. to be refined.
Another experimental characteristic of this specification is the Another experimental characteristic of this specification is the
question of key management between RADIUS/TLS peers. RADIUS/UDP only question of key management between RADIUS/TLS peers. RADIUS/UDP only
allowed for manual key management, i.e. distribution of a shared allowed for manual key management, i.e., distribution of a shared
secret between a client and a server. RADIUS/TLS allows manual secret between a client and a server. RADIUS/TLS allows manual
distribution of long-term proofs of peer identity as well (by using distribution of long-term proofs of peer identity as well (by using
TLS-PSK cipher suites, or identifying clients by a certificate TLS-PSK ciphersuites, or identifying clients by a certificate
fingerprint), but as a new feature enables use of X.509 certificates fingerprint), but as a new feature enables use of X.509 certificates
in a PKIX infrastructure. It remains to be seen if one of these in a PKIX infrastructure. It remains to be seen if one of these
methods prevail, or if both will find their place in real-life methods will prevail or if both will find their place in real-life
deployments. The authors can imagine pre-shared keys to be popular deployments. The authors can imagine pre-shared keys (PSK) to be
in small-scale deployments (SOHO or isolated enterprise deployments) popular in small-scale deployments (Small Office, Home Office (SOHO)
where scalability is not an issue and the deployment of a CA is or isolated enterprise deployments) where scalability is not an issue
considered too much a hassle; but can also imagine large roaming and the deployment of a Certification Authority (CA) is considered
consortia to make use of PKIX. Readers of this specification are too much of a hassle; however, the authors can also imagine large
encouraged to read the discussion of key management issus within roaming consortia to make use of PKIX. Readers of this specification
are encouraged to read the discussion of key management issues within
[RFC6421] as well as [RFC4107]. [RFC6421] as well as [RFC4107].
It has yet to be decided whether this approach is to be chosen for 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 Standards Track. One key aspect to judge whether the approach is
usable at large scale is by observing the uptake, usability and usable on a large scale is by observing the uptake, usability, and
operational behaviour of the protocol in large-scale, real-life operational behavior of the protocol in large-scale, real-life
deployments. deployments.
An example for a world-wide roaming environment that uses RADIUS over An example for a worldwide roaming environment that uses RADIUS over
TLS to secure communication is "eduroam", see [eduroam]. 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 authorization changes. The source port is arbitrary. See
section Section 3.4 for considerations regarding separation of Section 3.4 for considerations regarding the separation of
authentication, accounting and dynamic authorization traffic. authentication, accounting, and dynamic authorization 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 [RFC6613]. Failure to connect
Failure to connect leads to continuous retries, with leads to continuous retries, with exponentially growing intervals
exponentially growing intervals between every try. If multiple between every try. If multiple servers are defined, the node MAY
servers are defined, the node MAY attempt to establish a attempt to establish a connection to these other servers in
connection to these other servers in parallel, in order to 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 according to [RFC5246] or its predecessor TLS 1.1. The sessions according to [RFC5246] or its predecessor TLS 1.1. The
following restrictions apply: following restrictions apply:
* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 * Support for TLS v1.1 [RFC4346] or later (e.g., TLS 1.2
[RFC5246] ]) is REQUIRED. To prevent known attacks on TLS [RFC5246]) is REQUIRED. To prevent known attacks on TLS
versions prior to 1.1, implementations MUST NOT negotiate TLS versions prior to 1.1, implementations MUST NOT negotiate TLS
versions prior to 1.1. versions prior to 1.1.
* 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. Failure to comply well as integrity protection is REQUIRED. Failure to comply
with this requirement can lead to severe security problmes, with this requirement can lead to severe security problems,
like user passwords being recoverable by third parties. See like user passwords being recoverable by third parties. See
Section 6 for details. Section 6 for details.
* 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.3 ). TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3.
* 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.
3. Peer authentication can be performed in any of the following 3. Peer authentication can be performed in any of the following
three operation models: three operation models:
* TLS with X.509 certificates using PKIX trust models (this * TLS with X.509 certificates using PKIX trust models (this
model is mandatory to implement): model is mandatory to implement):
+ Implementations MUST allow to configure a list of trusted + Implementations MUST allow the configuration of a list of
Certification Authorities for incoming connections. trusted Certification Authorities for incoming connections.
+ Certificate validation MUST include the verification rules + Certificate validation MUST include the verification rules
as per [RFC5280]. as per [RFC5280].
+ Implementations SHOULD indicate their trusted Certification + Implementations SHOULD indicate their trusted Certification
Authorities (CAs). For TLS 1.2, this is done using Authorities (CAs). For TLS 1.2, this is done using
[RFC5246] section 7.4.4 "certificate authorities" (server [RFC5246], Section 7.4.4, "certificate_authorities" (server
side) and [RFC6066] Section 6 "Trusted CA Indication" side) and [RFC6066], Section 6 "Trusted CA Indication"
(client side). See also Section 3.2. (client side). See also Section 3.2.
+ Peer validation always includes a check on whether the + Peer validation always includes a check on whether the
locally configured expected DNS name or IP address of the locally configured expected DNS name or IP address of the
server that is contacted matches its presented certificate. server that is contacted matches its presented certificate.
DNS names and IP addresses can be contained in the Common DNS names and IP addresses can be contained in the Common
Name (CN) or subjectAltName entries. For verification, Name (CN) or subjectAltName entries. For verification,
only one of these entries is to be considered. The only one of these entries is to be considered. The
following precedence applies: for DNS name validation, following precedence applies: for DNS name validation,
subjectAltName:DNS has precedence over CN; for IP address subjectAltName:DNS has precedence over CN; for IP address
skipping to change at page 6, line 47 skipping to change at page 7, line 4
+ Peer validation always includes a check on whether the + Peer validation always includes a check on whether the
locally configured expected DNS name or IP address of the locally configured expected DNS name or IP address of the
server that is contacted matches its presented certificate. server that is contacted matches its presented certificate.
DNS names and IP addresses can be contained in the Common DNS names and IP addresses can be contained in the Common
Name (CN) or subjectAltName entries. For verification, Name (CN) or subjectAltName entries. For verification,
only one of these entries is to be considered. The only one of these entries is to be considered. The
following precedence applies: for DNS name validation, following precedence applies: for DNS name validation,
subjectAltName:DNS has precedence over CN; for IP address subjectAltName:DNS has precedence over CN; for IP address
validation, subjectAltName:iPAddr has precedence over CN. validation, subjectAltName:iPAddr has precedence over CN.
Implementors of this specification are advised to read Implementors of this specification are advised to read
[RFC6125] Section 6 for more details on DNS name [RFC6125], Section 6, for more details on DNS name
validation. validation.
+ Implementations MAY allow to configure a set of additional + Implementations MAY allow the configuration of a set of
properties of the certificate to check for a peer's additional properties of the certificate to check for a
authorisation to communicate (e.g. a set of allowed values peer's authorization to communicate (e.g., a set of allowed
in subjectAltName:URI or a set of allowed X509v3 values in subjectAltName:URI or a set of allowed X509v3
Certificate Policies) Certificate Policies).
+ When the configured trust base changes (e.g. removal of a + When the configured trust base changes (e.g., removal of a
CA from the list of trusted CAs; issuance of a new CRL for CA from the list of trusted CAs; issuance of a new CRL for
a given CA) implementations MAY re-negotiate the TLS a given CA), implementations MAY renegotiate the TLS
session to re-assess the connecting peer's continued session to reassess the connecting peer's continued
authorisation. authorization.
* TLS with X.509 certificates using certificate fingerprints * TLS with X.509 certificates using certificate fingerprints
(this model is optional to implement): Implementations SHOULD (this model is optional to implement): Implementations SHOULD
allow to configure a list of trusted certificates, identified allow the configuration of a list of trusted certificates,
via fingerprint of the DER encoded certificate octets. identified via fingerprint of the DER encoded certificate
Implementations MUST support SHA-1 as the hash algorithm for octets. Implementations MUST support SHA-1 as the hash
the fingerprint. To prevent attacks based on hash collisions, algorithm for the fingerprint. To prevent attacks based on
support for a more contemporary hash function such as SHA-256 hash collisions, support for a more contemporary hash function
is RECOMMENDED. such as SHA-256 is RECOMMENDED.
* TLS using TLS-PSK (this model is optional to implement) * TLS using TLS-PSK (this model is optional to implement).
4. start exchanging RADIUS datagrams (note Section 3.4 (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.4 (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 that is inherently insecure, as noted in [RFC5247].
RADIUS/TLS supports multiple operation modes. RADIUS/TLS supports multiple operation modes.
In TLS-PSK operation, a client is uniquely identified by its TLS In TLS-PSK operation, a client is uniquely identified by its TLS
identifier. identifier.
In TLS-X.509 mode using fingerprints, a client is uniquely identified In TLS-X.509 mode using fingerprints, a client is uniquely identified
by the fingerprint of the presented client certificate. by the fingerprint of the presented client certificate.
In TLS-X.509 mode using PKIX trust models, a client is uniquely In TLS-X.509 mode using PKIX trust models, a client is uniquely
identified by the tuple (serial number of presented client identified by the tuple (serial number of presented client
certificate;Issuer). certificate;Issuer).
Note well: having identified a connecting entity does not mean the Note well: having identified a connecting entity does not mean the
server necessarily wants to communicate with that client. E.g. if server necessarily wants to communicate with that client. For
the Issuer is not in a trusted set of Issuers, the server may decline example, if the Issuer is not in a trusted set of Issuers, the server
to perform RADIUS transactions with this client. may decline to perform RADIUS transactions with this client.
There are numerous trust models in PKIX environments, and it is There are numerous trust models in PKIX environments, and it is
beyond the scope of this document to define how a particular beyond the scope of this document to define how a particular
deployment determines whether a client is trustworthy. deployment determines whether a client is trustworthy.
Implementations which want to support a wide variety of trust models Implementations that want to support a wide variety of trust models
should expose as many details of the presented certificate to the should expose as many details of the presented certificate to the
administrator as possible so that the trust model can be implemented administrator as possible so that the trust model can be implemented
by the administrator. As a suggestion, at least the following by the administrator. As a suggestion, at least the following
parameters of the X.509 client certificate should be exposed: parameters of the X.509 client certificate should be exposed:
o Originating IP address o Originating IP address
o Certificate Fingerprint o Certificate Fingerprint
o Issuer o Issuer
skipping to change at page 8, line 40 skipping to change at page 8, line 46
In TLS-PSK operation, at least the following parameters of the TLS In TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed: connection should be exposed:
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, Authorization, and Accounting 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.4 (3) and they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and
(4) ). E.g. they send (4)). For example, 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
o Disconnect-NAK o Disconnect-NAK
o ... o ...
and they receive and they receive
skipping to change at page 9, line 23 skipping to change at page 9, line 27
o Access-Accept o Access-Accept
o Accounting-Response o Accounting-Response
o Disconnect-Request o Disconnect-Request
o ... o ...
RADIUS/TLS servers transmit the same packet types on connections they RADIUS/TLS servers transmit the same packet types on connections they
have accepted as a RADIUS/UDP server would. E.g. they send have accepted as a RADIUS/UDP server would. For example, they send
o Access-Challenge o Access-Challenge
o Access-Accept o Access-Accept
o Access-Reject o Access-Reject
o Accounting-Response o Accounting-Response
o Disconnect-Request o Disconnect-Request
skipping to change at page 9, line 50 skipping to change at page 10, line 6
o Accounting-Request o Accounting-Request
o Status-Server o Status-Server
o Disconnect-ACK o Disconnect-ACK
o ... o ...
Due to the use of one single TCP port for all packet types, it is Due to the use of one single TCP port for all packet types, it is
required for a RADIUS/TLS server to signal to a connecting peer which required that a RADIUS/TLS server signal which types of packets are
types of packets are supported on a server. See also section supported on a server to a connecting peer. See also Section 3.4 for
Section 3.4 for a discussion of signaling. a discussion of signaling.
o When receiving an unwanted packet of type 'CoA-Request' or o When an unwanted packet of type 'CoA-Request' or 'Disconnect-
'Disconnect-Request', it needs to be replied to with a 'CoA-NAK' Request' is received, a RADIUS/TLS server needs to respond with a
or 'Disconnect-NAK' respectively. The NAK SHOULD contain an 'CoA-NAK' or 'Disconnect-NAK', respectively. The NAK SHOULD
attribute Error-Cause with the value 406 ("Unsupported contain an attribute Error-Cause with the value 406 ("Unsupported
Extension"); see [RFC5176] for details. Extension"); see [RFC5176] for details.
o When receiving an unwanted packet of type 'Accounting-Request', o When an unwanted packet of type 'Accounting-Request' is received,
the RADIUS/TLS server SHOULD reply with an Accounting-Response the RADIUS/TLS server SHOULD reply with an Accounting-Response
containing an Error-Cause attribute with value 406 "Unsupported containing an Error-Cause attribute with value 406 "Unsupported
Extension" as defined in [RFC5176]. A RADIUS/TLS accounting Extension" as defined in [RFC5176]. A RADIUS/TLS accounting
client receiving such an Accounting-Response SHOULD log the error client receiving such an Accounting-Response SHOULD log the error
and stop sending Accounting-Request packets. and stop sending Accounting-Request packets.
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. Implications of Dynamic Peer Discovery 3.1. Implications of Dynamic Peer Discovery
One mechanism to discover RADIUS over TLS peers dynamically via DNS One mechanism to discover RADIUS-over-TLS peers dynamically via DNS
is specified in [I-D.ietf-radext-dynamic-discovery]. While this is specified in [DYNAMIC]. While this mechanism is still under
mechanism is still under development and therefore is not a normative development and therefore is not a normative dependency of RADIUS/
dependency of RADIUS/TLS, the use of dynamic discovery has potential TLS, the use of dynamic discovery has potential future implications
future implications that are important to understand. that are important to understand.
Readers of this document who are considering the deployment of DNS- Readers of this document who are considering the deployment of DNS-
based dynamic discovery are thus encouraged to read based dynamic discovery are thus encouraged to read [DYNAMIC] and
[I-D.ietf-radext-dynamic-discovery] and follow its future follow its future development.
development.
3.2. X.509 Certificate Considerations 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)
dynamic discovery is used, the discovery mechanism possibly does not and dynamic discovery is used, the discovery mechanism possibly
yield sufficient information to identify the consortium uniquely does not yield sufficient information to identify the consortium
(e.g. DNS discovery). Subsequently, the client may not know by uniquely (e.g., DNS discovery). Subsequently, the client may
itself which client certificate to use for the TLS handshake. Then not know by itself which client certificate to use for the TLS
it is necessary for the server to signal which consortium it belongs handshake. Then, it is necessary for the server to signal to
to, and which certificates it expects. If there is no risk of which consortium it belongs and which certificates it expects.
confusing multiple roaming consortia, providing this information in If there is no risk of confusing multiple roaming consortia,
the handshake is not crucial. providing this information in the handshake is not crucial.
(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
will need to select one of its certificates to present to the RADIUS/ consortia), it will need to select one of its certificates to
TLS client. If the client sends the Trusted CA Indication, this hint present to the RADIUS/TLS client. If the client sends the
can make the server select the appropriate certificate and prevent a Trusted CA Indication, this hint can make the server select the
handshake failure. Omitting this indication makes it impossible to appropriate certificate and prevent a handshake failure.
deterministically select the right certificate in this case. If Omitting this indication makes it impossible to
there is no risk of confusing multiple roaming consortia, providing deterministically select the right certificate in this case. If
this indication in the handshake is not crucial. there is no risk of confusing multiple roaming consortia,
providing this indication in the handshake is not crucial.
3.3. Ciphersuites and Compression Negotiation Considerations 3.3. 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 a 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 [RFC4346] and thus has to be supported by implement according to [RFC4346]; thus, it 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 tool kits and are considered good practice to
implement. implement.
3.4. 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
size can be determined by evaluating the size of the datagram that packet size can be determined by evaluating the size of the
arrived. Due to the stream nature of TCP and TLS, this does not hold datagram that arrived. Due to the stream nature of TCP and TLS,
true for RADIUS/TLS packet exchange. Instead, packet boundaries of this does not hold true for RADIUS/TLS packet exchange.
RADIUS packets that arrive in the stream are calculated by evaluating Instead, packet boundaries of RADIUS packets that arrive in the
the packet's Length field. Special care needs to be taken on the stream are calculated by evaluating the packet's Length field.
packet sender side that the value of the Length field is indeed Special care needs to be taken on the packet sender side that
correct before sending it over the TLS tunnel, because incorrect the value of the Length field is indeed correct before sending
packet lengths can no longer be detected by a differing datagram it over the TLS tunnel, because incorrect packet lengths can no
boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for longer be detected by a differing datagram boundary. See
more details. Section 2.6.4 of [RFC6613] for more details.
(2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding
of attributes such as User-Password, as well as in computation 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
integrity protection and encryption sufficient to substitute for provides integrity protection and encryption sufficient to
RADIUS application-layer security, it is not necessary to configure a substitute for RADIUS application-layer security, it is not
RADIUS shared secret. The use of a fixed string for the obsolete necessary to configure a RADIUS shared secret. The use of a
shared secret eliminates possible node misconfigurations. fixed string for the obsolete shared secret eliminates possible
node misconfigurations.
(3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, (3) RADIUS/UDP [RFC2865] uses different UDP ports for
accounting and dynamic authorisation changes. RADIUS/TLS allocates a authentication, accounting, and dynamic authorization changes.
single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS RADIUS/TLS allocates a single port for all RADIUS packet types.
the notion of a client which sends authentication requests and Nevertheless, in RADIUS/TLS, the notion of a client that sends
processes replies associated with it's users' sessions and the notion authentication requests and processes replies associated with
of a server which receives requests, processes them and sends the its users' sessions and the notion of a server that receives
appropriate replies is to be preserved. The normative rules about requests, processes them, and sends the appropriate replies is
acceptable packet types for clients and servers mirror the packet to be preserved. The normative rules about acceptable packet
flow behaviour from RADIUS/UDP. types for clients and servers mirror the packet flow behavior
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 the reception and processing of the packet types in
These packet types are listed as to be received in RADIUS/TLS [RFC5176]. These packet types are listed as to be received in
implementations. Note well: it is not required for an implementation RADIUS/TLS implementations. Note well: it is not required for
to actually process these packet types; it is only required to send an implementation to actually process these packet types; it is
the NAK as defined above. only required that the NAK be sent as defined above.
(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 the reception and processing of RADIUS Accounting
is no RADIUS datagram to signal an Accounting NAK. Clients may be packets. There is no RADIUS datagram to signal an Accounting
misconfigured to send Accounting packets to a RADIUS/TLS server which NAK. Clients may be misconfigured for sending Accounting
does not wish to process their Accounting packet. To prevent a packets to a RADIUS/TLS server that does not wish to process
regression of detectability of this situation, the Accounting- their Accounting packet. To prevent a regression of
Response + Error-Cause sgnaling was introduced. detectability of this situation, the Accounting-Response +
Error-Cause signaling was introduced.
4. Compatibility with other RADIUS transports 4. Compatibility with Other RADIUS Transports
Ongoing work in the IETF defines multiple alternative transports to The IETF defines multiple alternative transports to the classic UDP
the classic UDP transport model as defined in [RFC2865], namely transport model as defined in [RFC2865], namely RADIUS over TCP
RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over Datagram [RFC6613] and the present document on RADIUS over TLS. The IETF also
Transport Layer Security (DTLS) [I-D.ietf-radext-dtls] and this proposed RADIUS over Datagram Transport Layer Security (DTLS)
present document on RADIUS over TLS. [RADEXT-DTLS].
RADIUS/TLS does not specify any inherent backwards compatibility to RADIUS/TLS does not specify any inherent backward compatibility to
RADIUS/UDP or cross compatibility to the other transports, i.e. an RADIUS/UDP or cross compatibility to the other transports, i.e., an
implementation which implements RADIUS/TLS only will not be able to implementation that utilizes RADIUS/TLS only will not be able to
receive or send RADIUS packet payloads over other transports. An receive or send RADIUS packet payloads over other transports. An
implementation wishing to be backward or cross compatible (i.e. implementation wishing to be backward or cross compatible (i.e.,
wishes to serve clients using other transports than RADIUS/TLS) will wishes to serve clients using other transports than RADIUS/TLS) will
need to implement these other transports along with the RADIUS/TLS need to implement these other transports along with the RADIUS/TLS
transport and be prepared to send and receive on all implemented transport and be prepared to send and receive on all implemented
transports, which is called a multi-stack implementation. transports, which is called a "multi-stack implementation".
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 cannot 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.
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, the
compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP compatibility of RADIUS/TLS - Diameter [RFC3588] and 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 [RFC6613] 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.
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 plaintext, including User-Password, to
intermediate IP nodes. intermediate IP nodes.
By virtue of being based on TCP, there are several generic attack By virtue of being based on TCP, there are several generic attack
vectors to slow down or prevent the TCP connection from being vectors to slow down or prevent the TCP connection from being
established; see [RFC4953] for details. If a TCP connection is not established; see [RFC4953] for details. If a TCP connection is not
up when a packet is to be processed, it gets re-established, so such up when a packet is to be processed, it gets re-established, so such
attacks in general lead only to a minor performance degradation (the attacks in general lead only to a minor performance degradation (the
time it takes to re-establish the connection). There is one notable time it takes to re-establish the connection). There is one notable
exception where an attacker might create a bidding-down attack exception where an attacker might create a bidding-down attack
though: If peer communication between two devices is configured for though. If peer communication between two devices is configured for
both RADIUS/TLS (i.e TLS security over TCP as a transport, shared both RADIUS/TLS (i.e., TLS security over TCP as a transport, shared
secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security secret fixed to "radsec") and RADIUS/UDP (i.e., shared secret
with a secret manually configured by the administrator), and where security with a secret manually configured by the administrator), and
the RADIUS/UDP transport is the failover option if the TLS session the RADIUS/UDP transport is the failover option if the TLS session
cannot be established, a bidding-down attack can occur if an cannot be established, a bidding-down 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
from being established. Situations where clients are configured in being established. Situations where clients are configured in such a
such a way are likely to occur during a migration phase from RADIUS/ way are likely to occur during a migration phase from RADIUS/UDP to
UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker RADIUS/TLS. By preventing the TLS session setup, the attacker can
can reduce the security of the packet payload from the selected TLS reduce the security of the packet payload from the selected TLS
cipher suite packet encryption to the classic MD5 per-attribute ciphersuite packet encryption to the classic MD5 per-attribute
encryption. The situation should be avoided by disabling the weaker encryption. The situation should be avoided by disabling the weaker
RADIUS/UDP transport as soon as the new RADIUS/TLS connection is RADIUS/UDP transport as soon as the new RADIUS/TLS connection is
established and tested. Disabling can happen at either the RADIUS established and tested. Disabling can happen at either the RADIUS
client or server side: client or server side:
o Client side: de-configure the failover setup, leaving RADIUS/TLS o Client side: de-configure the failover setup, leaving RADIUS/TLS
as the only communication option as the only communication option
o Server side: de-configure the RADIUS/UDP client from the list of o Server side: de-configure the RADIUS/UDP client from the list of
valid RADIUS clients valid RADIUS clients
RADIUS/TLS provides authentication and encryption between RADIUS RADIUS/TLS provides authentication and encryption between RADIUS
peers. In the presence of proxies, the intermediate proxies can peers. In the presence of proxies, the intermediate proxies can
still inspect the individual RADIUS packets, i.e. "end-to-end" still inspect the individual RADIUS packets, i.e., "end-to-end"
encryption is not provided. Where intermediate proxies are 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 the Extensible method to protect passwords is the use of the Extensible
Authentication Protocol (EAP) and EAP methods which utilize TLS. Authentication Protocol (EAP) and EAP methods that utilize TLS.
When using certificate fingerprints to identify RADIUS/TLS peers, any When using certificate fingerprints to identify RADIUS/TLS peers, any
two certificates which produce the same hash value (i.e. which have a two certificates that produce the same hash value (i.e., that have a
hash collision) will be considered the same client. It is therefore hash collision) will be considered the same client. Therefore, it is
important to make sure that the hash function used is important to make sure that the hash function used is
cryptographically uncompromised so that an attacker is very unlikely cryptographically uncompromised so that an attacker is very unlikely
to be able to produce a hash collision with a certificate of his to be able to produce a hash collision with a certificate of his
choice. While this specification mandates support for SHA-1, a later choice. While this specification mandates support for SHA-1, a later
revision will likely demand support for more contemporary hash revision will likely demand support for more contemporary hash
functions because as of issuance of this document there are already functions because as of issuance of this document, there are already
attacks on SHA-1. attacks on SHA-1.
7. IANA Considerations 7. IANA Considerations
No new RADIUS attributes or packet codes are defined. IANA is No new RADIUS attributes or packet codes are defined. IANA has
requested to update the already-assigned TCP port number 2083 in the updated the already assigned TCP port number 2083 to reflect the
following ways: following:
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 o Reference: [RFC6614]
draft prior to publication. o Assignment Notes: 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 6614, Appendix A for details.
9. Acknowledgements 8. 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 document was provided
provided by the European Commission co-funded project "GEANT2" by the European Commission co-funded project "GEANT2" [geant2] and
[geant2] and further feedback was provided by the TERENA Task Force further feedback was provided by the TERENA Task Force on Mobility
Mobility [terena]. and Network Middleware [terena].
10. References 9. 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
in RFCs to Indicate Requirement Requirement Levels", BCP 14, RFC 2119, March 1997.
Levels", BCP 14, RFC 2119,
March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
A., and W. Simpson, "Remote "Remote Authentication Dial In User Service (RADIUS)",
Authentication Dial In User RFC 2865, June 2000.
Service (RADIUS)", RFC 2865,
June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
RFC 2866, June 2000.
[RFC4279] Eronen, P. and H. Tschofenig, [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
"Pre-Shared Key Ciphersuites for for Transport Layer Security (TLS)", RFC 4279,
Transport Layer Security (TLS)", December 2005.
RFC 4279, December 2005.
[RFC5280] Cooper, D., Santesson, S., [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Farrell, S., Boeyen, S., Aboba, "Dynamic Authorization Extensions to Remote
Housley, R., and W. Polk, Authentication Dial In User Service (RADIUS)", RFC 5176,
"Internet X.509 Public Key January 2008.
Infrastructure Certificate and
Certificate Revocation List
(CRL) Profile", RFC 5280,
May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
M., Mitton, D., and B. Aboba, (TLS) Protocol Version 1.2", RFC 5246, August 2008.
"Dynamic Authorization
Extensions to Remote
Authentication Dial In User
Service (RADIUS)", RFC 5176,
January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Transport Layer Security (TLS) Authentication Protocol (EAP) Key Management Framework",
Protocol Version 1.2", RFC 5246, RFC 5247, August 2008.
August 2008.
[RFC5247] Aboba, B., Simon, D., and P. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Eronen, "Extensible Housley, R., and W. Polk, "Internet X.509 Public Key
Authentication Protocol (EAP) Infrastructure Certificate and Certificate Revocation List
Key Management Framework", (CRL) Profile", RFC 5280, May 2008.
RFC 5247, August 2008.
[RFC6066] Eastlake, D., "Transport Layer [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
Extension Definitions",
RFC 6066, January 2011.
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
aft-ietf-radext-tcp-transport-09
(work in progress),
October 2010.
10.2. Informative References 9.2. Informative References
[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport [DYNAMIC] Winter, S. and M. McCauley, "NAI-based Dynamic Peer
Layer for RADIUS", Discovery for RADIUS/TLS and RADIUS/DTLS", Work
draft-ietf-radext-dtls-01 (work in Progress, July 2011.
in progress), October 2010.
[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, [MD5-attacks]
"NAI-based Dynamic Peer Black, J., Cochran, M., and T. Highland, "A Study of the
Discovery for RADIUS/TLS and MD5 Attacks: Insights and Improvements", October 2006,
RADIUS/DTLS", draft-ietf-radext- <http://www.springerlink.com/content/40867l85727r7084/>.
dynamic-discovery-03 (work in
progress), July 2011.
[RFC3539] Aboba, B. and J. Wood, [RADEXT-DTLS]
"Authentication, Authorization DeKok, A., "DTLS as a Transport Layer for RADIUS", Work
and Accounting (AAA) Transport in Progress, October 2010.
Profile", RFC 3539, June 2003.
[RFC3588] Calhoun, P., Loughney, J., [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Guttman, E., Zorn, G., and J. Accounting (AAA) Transport Profile", RFC 3539, June 2003.
Arkko, "Diameter Base Protocol",
RFC 3588, September 2003.
[RFC4107] Bellovin, S. and R. Housley, [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
"Guidelines for Cryptographic Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Key Management", BCP 107,
RFC 4107, June 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Transport Layer Security (TLS) Key Management", BCP 107, RFC 4107, June 2005.
Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4953] Touch, J., "Defending TCP [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Against Spoofing Attacks", (TLS) Protocol Version 1.1", RFC 4346, April 2006.
RFC 4953, July 2007.
[RFC6125] Saint-Andre, P. and J. Hodges, [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
"Representation and Verification RFC 4953, July 2007.
of Domain-Based Application
Service Identity within Internet
Public Key Infrastructure Using
X.509 (PKIX) Certificates in the
Context of Transport Layer
Security (TLS)", RFC 6125,
March 2011.
[RFC6421] Nelson, D., "Crypto-Agility [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Requirements for Remote Verification of Domain-Based Application Service Identity
Authentication Dial-In User within Internet Public Key Infrastructure Using X.509
Service (RADIUS)", RFC 6421, (PKIX) Certificates in the Context of Transport Layer
November 2011. Security (TLS)", RFC 6125, March 2011.
[radsec-whitepaper] Open System Consultants, "RadSec [RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote
- a secure, reliable RADIUS Authentication Dial-In User Service (RADIUS)", RFC 6421,
Protocol", May 2005, <http:// November 2011.
www.open.com.au/radiator/
radsec-whitepaper.pdf>.
[MD5-attacks] Black, J., Cochran, M., and T. [eduroam] Trans-European Research and Education Networking
Highland, "A Study of the MD5 Association, "eduroam Homepage", 2007,
Attacks: Insights and <http://www.eduroam.org/>.
Improvements", October 2006, <ht
tp://www.springerlink.com/
content/40867l85727r7084/>.
[radsecproxy-impl] Venaas, S., "radsecproxy Project [geant2] Delivery of Advanced Network Technology to Europe,
Homepage", 2007, <http:// "European Commission Information Society and Media:
software.uninett.no/ GEANT2", 2008, <http://www.geant2.net/>.
radsecproxy/>.
[eduroam] Trans-European Research and [radsec-whitepaper]
Education Networking Open System Consultants, "RadSec - a secure, reliable
Association, "eduroam Homepage", RADIUS Protocol", May 2005,
2007, <http://www.eduroam.org/>. <http://www.open.com.au/radiator/radsec-whitepaper.pdf>.
[geant2] Delivery of Advanced Network [radsecproxy-impl]
Technology to Europe, "European Venaas, S., "radsecproxy Project Homepage", 2007,
Commission Information Society <http://software.uninett.no/radsecproxy/>.
and Media: GEANT2", 2008,
<http://www.geant2.net/>.
[terena] TERENA, "Trans-European Research [terena] Trans-European Research and Education Networking
and Education Networking Association (TERENA), "Task Force on Mobility and Network
Association", 2008, Middleware", 2008,
<http://www.terena.org/>. <http://www.terena.org/activities/tf-mobility/>.
Appendix A. Implementation Overview: Radiator Appendix A. Implementation Overview: Radiator
Radiator implements the RadSec protocol for proxying requests with Radiator implements the RadSec protocol for proxying requests with
the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator
configuration file. configuration file.
The <AuthBy RADSEC> clause defines a RadSec client, and causes The <AuthBy RADSEC> clause defines a RadSec client, and causes
Radiator to send RADIUS requests to the configured RadSec server Radiator to send RADIUS requests to the configured RadSec server
using the RadSec protocol. using the RadSec protocol.
skipping to change at page 19, line 40 skipping to change at page 19, line 12
Once established, TLS connections are kept open throughout the server Once established, TLS connections are kept open throughout the server
instance lifetime. instance lifetime.
Appendix B. Implementation Overview: radsecproxy Appendix B. Implementation Overview: radsecproxy
The RADIUS proxy named radsecproxy was written in order to allow use The RADIUS proxy named radsecproxy was written in order to allow use
of RadSec in current RADIUS deployments. This is a generic proxy of RadSec in current RADIUS deployments. This is a generic proxy
that supports any number and combination of clients and servers, that supports any number and combination of clients and servers,
supporting RADIUS over UDP and RadSec. The main idea is that it can 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 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 RadSec is used on the wire; however, as a generic proxy, it can be
in other circumstances as well. used in other circumstances as well.
The configuration file consists of client and server clauses, where The configuration file consists of client and server clauses, where
there is one such clause for each client or server. In such a clause there is one such clause for each client or server. In such a
one specifies either "type tls" or "type udp" for RadSec or UDP clause, one specifies either "type tls" or "type udp" for TLS or UDP
transport. For RadSec the default shared secret "mysecret" (without transport. Versions prior to 1.6 used "mysecret" as a default shared
quotes), the same as Radiator, is used. For compliance with this secret for RADIUS/TLS; version 1.6 and onwards uses "radsec". For
document, this setting needs to be configured for the shared secret backwards compatibility with older versions, the secret can be
"radsec". A secret may be specified by putting say "secret changed (which makes the configuration not compliant with this
somesharedsecret" inside a client or server clause. specification).
In order to use TLS for clients and/or servers, one must also specify 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 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 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 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 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 multiple TLS clauses may be to present one certificate to clients and
another to servers. another to servers.
If any RadSec (TLS) clients are configured, the proxy will at startup If any RadSec (TLS) clients are configured, the proxy will, at
listen on port 2083, as assigned by IANA for the OSC RadSec startup, listen on port 2083, as assigned by IANA for the OSC RadSec
implementation. An alternative port may be specified. When a client implementation. An alternative port may be specified. When a client
connects, the client certificate will be verified, including checking connects, the client certificate will be verified, including checking
that the configured FQDN or IP address matches what is in the that the configured Fully Qualified Domain Name (FQDN) or IP address
certificate. Requests coming from a RadSec client are treated matches what is in the certificate. Requests coming from a RadSec
exactly like requests from UDP clients. client are treated exactly like requests from UDP clients.
The proxy will at startup try to establish a TLS connection to each At startup, the proxy will try to establish a TLS connection to each
(if any) of the configured RadSec (TLS) servers. If it fails to (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 connect to a server, it will retry regularly. There is some back-off
where it will retry quickly at first, and with longer intervals where it will retry quickly at first, and with longer intervals
later. If a connection to a server goes down it will also start later. If a connection to a server goes down, it will also start
retrying regularly. When setting up the TLS connection, the server retrying regularly. When setting up the TLS connection, the server
certificate will be verified, including checking that the configured certificate will be verified, including checking that the configured
FQDN or IP address matches what is in the certificate. Requests are FQDN or IP address matches what is in the certificate. Requests are
sent to a RadSec server just like they would to a UDP server. sent to a RadSec server, just like they would be to a UDP server.
The proxy supports Status-Server messages. They are only sent to a The proxy supports Status-Server messages. They are only sent to a
server if enabled for that particular server. Status-Server requests server if enabled for that particular server. Status-Server requests
are always responded to. are always responded to.
This RadSec implementation has been successfully tested together with This RadSec implementation has been successfully tested together with
Radiator. It is a freely available open-source implementation. For Radiator. It is a freely available, open-source implementation. For
source code and documentation, see [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 [RFC6421] defines numerous The RADIUS Crypto-Agility Requirements document [RFC6421] defines
classification criteria for protocols that strive to enhance the numerous classification criteria for protocols that strive to enhance
security of RADIUS. It contains mandatory (M) and recommended (R) the security of RADIUS. It contains mandatory (M) and recommended
criteria which crypto-agile protocols have to fulfill. The authors (R) criteria that crypto-agile protocols have to fulfill. The
believe that the following assessment about the crypto-agility authors believe that the following assessment about the crypto-
properties of RADIUS/TLS are true. agility properties of RADIUS/TLS are true.
By virtue of being a transport profile using TLS over TCP as a By virtue of being a transport profile using TLS over TCP as a
transport protocol, the cryptographically agile properties of TLS are transport protocol, the cryptographically agile properties of TLS are
inherited, and RADIUS/TLS subsequently meets the following points: inherited, and RADIUS/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
(M) define mandatory-to-implement cryptographic algorithms (M) define mandatory-to-implement cryptographic algorithms
(M) generate fresh session keys for use between client and server (M) generate fresh session keys for use between client and server
(R) support for Perfect Forward Secrecy in session keys (R) support for Perfect Forward Secrecy in session keys
skipping to change at page 21, line 14 skipping to change at page 20, line 34
(M) negotiation of cryptographic algorithms for encryption (M) negotiation of cryptographic algorithms for encryption
(M) replay protection (M) replay protection
(M) define mandatory-to-implement cryptographic algorithms (M) define mandatory-to-implement cryptographic algorithms
(M) generate fresh session keys for use between client and server (M) generate fresh session keys for use between client and server
(R) support for Perfect Forward Secrecy in session keys (R) support for Perfect Forward Secrecy in session keys
(R) support X.509 certificate based operation (R) support X.509 certificate-based operation
(R) support Pre-Shared keys (R) support Pre-Shared keys
(R) support for confidentiality of the entire packet (R) support for confidentiality of the entire packet
(M/R) support Automated Key Management (M/R) support Automated Key Management
The remainder of the requirements is discussed individually below in The remainder of the requirements is discussed individually below in
more detail: more detail:
(M) "avoid security compromise, even in situations where the (M) "...avoid security compromise, even in situations where the
existing cryptographic alogrithms used by RADIUS implementations existing cryptographic algorithms utilized by RADIUS
are shown to be weak enough to provide little or no security" - implementations are shown to be weak enough to provide little or
The existing algorithm, based on MD5, is not of any significance no security" [RFC6421]. The existing algorithm, based on MD5, is
in RADIUS/TLS; its compromise does not compromise the outer not of any significance in RADIUS/TLS; its compromise does not
transport security. compromise the outer transport security.
(R) mandatory-to-implement alogrithms are to be NIST-Acceptable (R) mandatory-to-implement algorithms are to be NIST-Acceptable
with no deprecation date - The mandatory-to-implement algorithm is with no deprecation date - The mandatory-to-implement algorithm is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three- TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three-
key 3DES operation, which is classified as Acceptable with no key 3DES operation, which is classified as Acceptable with no
known deprecation date by NIST. known deprecation date by NIST.
(M) demonstrate backward compatibility with RADIUS - There are (M) demonstrate backward compatibility with RADIUS - There are
multiple implementations supporting both RADIUS and RADIUS/TLS, multiple implementations supporting both RADIUS and RADIUS/TLS,
and the translation between them. and the translation between them.
(M) After legacy mechanisms have been compromised, secure (M) After legacy mechanisms have been compromised, secure
skipping to change at page 22, line 17 skipping to change at page 21, line 37
created exclusively based on this specification and is created exclusively based on this specification and is
interoperable with other RADIUS/TLS implementations. interoperable with other RADIUS/TLS implementations.
(M) apply to all packet types - RADIUS/TLS operates on the (M) apply to all packet types - RADIUS/TLS operates on the
transport layer, and can carry all packet types. transport layer, and can carry all packet types.
(R) message data exchanged with Diameter SHOULD NOT be affected - (R) message data exchanged with Diameter SHOULD NOT be affected -
The solution is Diameter-agnostic. The solution is Diameter-agnostic.
(M) discuss any inherent assumptions - The authors are not aware (M) discuss any inherent assumptions - The authors are not aware
of any implicit assumptions which would be yet-unarticulated in of any implicit assumptions that would be yet-unarticulated in the
the draft document.
(R) provide recommendations for transition - The Security (R) provide recommendations for transition - The Security
Considerations section contains a transition path. Considerations section contains a transition path.
(R) discuss legacy interoperability and potential for bidding-down (R) discuss legacy interoperability and potential for bidding-down
attacks - The Security Considerations section contains an attacks - The Security Considerations section contains a
corresponding discussion. corresponding discussion.
Summarizing, it is believed that this specification fulfills all the Summarizing, it is believed that this specification fulfills all the
mandatory and all the recommended requirements for a crypto-agile mandatory and all the recommended requirements for a crypto-agile
solution and should thus be considered UNCONDITIONALLY COMPLIANT. solution and should thus be considered UNCONDITIONALLY COMPLIANT.
Authors' Addresses Authors' Addresses
Stefan Winter Stefan Winter
Fondation RESTENA Fondation RESTENA
6, rue Richard Coudenhove-Kalergi 6, rue Richard Coudenhove-Kalergi
Luxembourg 1359 Luxembourg 1359
LUXEMBOURG Luxembourg
Phone: +352 424409 1 Phone: +352 424409 1
Fax: +352 422473 Fax: +352 422473
EMail: stefan.winter@restena.lu EMail: stefan.winter@restena.lu
URI: http://www.restena.lu. URI: http://www.restena.lu.
Mike McCauley Mike McCauley
Open Systems Consultants Open Systems Consultants
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
cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: stig@cisco.com EMail: stig@cisco.com
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: EMail: klaas@cisco.com
EMail: kwiereng@cisco.com URI: http://www.cisco.com
URI: http://www.cisco.com.
 End of changes. 133 change blocks. 
446 lines changed or deleted 377 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/