draft-ietf-radext-radsec-11.txt   draft-ietf-radext-radsec-12.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 30, 2012 OSC Expires: August 17, 2012 OSC
S. Venaas S. Venaas
K. Wierenga K. Wierenga
Cisco Cisco
January 27, 2012 February 14, 2012
TLS encryption for RADIUS Transport Layer Security (TLS) encryption for RADIUS
draft-ietf-radext-radsec-11 draft-ietf-radext-radsec-12
Abstract Abstract
This document specifies security on the transport layer (TLS) for the This document specifies a transport profile for RADIUS using
RADIUS protocol when transmitted over TCP. This enables dynamic Transport Layer Security (TLS) over TCP as the transport protocol.
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 30, 2012. This Internet-Draft will expire on August 17, 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 25
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 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 5
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 5
2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5
2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 7
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 8
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 10
3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 10
3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 10
3.3. Ciphersuites and Compression Negotiation Considerations . 10 3.3. Ciphersuites and Compression Negotiation Considerations . 11
3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 11
4. Compatibility with other RADIUS transports . . . . . . . . . . 11 4. Compatibility with other RADIUS transports . . . . . . . . . . 12
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 18
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 19
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 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 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 Authentication, Authorization, and Accounting (AAA)
several shortcomings, such as its dependency on the unreliable solution. However, RADIUS is experiencing several shortcomings, such
transport protocol UDP and the lack of security for large parts of as its dependency on the unreliable transport protocol UDP and the
its packet payload. RADIUS security is based on the MD5 algorithm, lack of security for large parts of its packet payload. RADIUS
which has been proven to be insecure. security is based on the MD5 algorithm, which has been proven to be
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 on the transport layer. The communication between RADIUS/TCP peers using TLS. The most important
most important use of this specification lies in roaming environments use of this specification lies in roaming environments where RADIUS
where RADIUS packets need to be transferred through different packets need to be transferred through different administrative
administrative domains and untrusted, potentially hostile networks. domains and untrusted, potentially hostile networks. An example for
An example for a world-wide roaming environment that uses RADIUS over a world-wide roaming environment that uses RADIUS over TLS to secure
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 which is used
in RADIUS to provide integrity protection and a limited in RADIUS to provide integrity protection and a limited
confidentiality protection (see [MD5-attacks]). RADIUS over TLS confidentiality protection (see [MD5-attacks]). RADIUS over TLS
wraps the entire RADIUS packet payload into a TLS stream and thus wraps the entire RADIUS packet payload into a TLS stream and thus
mitigates the risk of attacks on MD5. mitigates the risk 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 control by different
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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
track, certificate verification options (section 2.3.2) need to be
refined.
Another experimental characteristic of this specification is the
question of key management between RADIUS/TLS peers. RADIUS/UDP only
allowed for manual key management, i.e. distribution of a shared
secret between a client and a server. RADIUS/TLS allows manual
distribution of long-term proofs of peer identity as well (by using
TLS-PSK cipher suites, or identifying clients by a certificate
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
methods prevail, or if both will find their place in real-life
deployments. The authors can imagine pre-shared keys to be popular
in small-scale deployments (SOHO or isolated enterprise deployments)
where scalability is not an issue and the deployment of a CA is
considered too much a hassle; but can also imagine large roaming
consortia to make use of PKIX. Readers of this specification are
encouraged to read the discussion of key management issus within
[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 at large scale is by observing the uptake, usability and
operational behaviour of the protocol in large-scale, real-life operational behaviour 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 world-wide 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 authorisation changes. The source port is arbitrary. See
section Section 3.4 for considerations regarding separation of section Section 3.4 for considerations regarding separation of
authentication, accounting and dynauth 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
skipping to change at page 5, line 21 skipping to change at page 5, line 40
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 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. [RFC5246] ]) is REQUIRED. To prevent known attacks on TLS
versions prior to 1.1, implementations MUST NOT negotiate TLS
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. well as integrity protection is REQUIRED. Failure to comply
with this requirement can lead to severe security problmes,
like user passwords being recoverable by third parties. See
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 (1) ). 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.
* RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL 3. Peer authentication can be performed in any of the following
encryption (e.g. [RFC4785]). three operation models:
3. If TLS is used in an X.509 certificate based operation mode, the * TLS with X.509 certificates using PKIX trust models (this
following list of certificate validation options applies: model is mandatory to implement):
* Implementations MUST allow to configure a list of acceptable + Implementations MUST allow to configure a list of trusted
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
per [RFC5280]. as per [RFC5280].
* Implementations SHOULD indicate their acceptable Certification + Implementations SHOULD indicate their trusted Certification
Authorities as per section 7.4.4 (server side) and x.y.z Authorities (CAs). For TLS 1.2, this is done using
["Trusted CA Indication"] (client side) of [RFC5246] (see [RFC5246] section 7.4.4 "certificate authorities" (server
Section 3.2) side) and [RFC6066] Section 6 "Trusted CA Indication"
(client side). See also Section 3.2.
* Implementations SHOULD allow to configure a list of acceptable + Peer validation always includes a check on whether the
certificates, identified via certificate fingerprint. When a locally configured expected DNS name or IP address of the
fingerprint configured, the fingerprint is prepended with an server that is contacted matches its presented certificate.
ASCII label identifying the hash function followed by a colon. DNS names and IP addresses can be contained in the Common
Implementations MUST support SHA-1 as the hash algorithm and Name (CN) or subjectAltName entries. For verification,
use the ASCII label "sha-1" to identify the SHA-1 algorithm. only one of these entries is to be considered. The
The length of a SHA-1 hash is 20 bytes and the length of the following precedence applies: for DNS name validation,
corresponding fingerprint string is 65 characters. An example subjectAltName:DNS has precedence over CN; for IP address
certificate fingerprint is: sha- validation, subjectAltName:iPAddr has precedence over CN.
1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D Implementors of this specification are advised to read
[RFC6125] Section 6 for more details on DNS name
validation.
* Peer validation always includes a check on whether the locally + Implementations MAY allow to configure a set of additional
configured expected DNS name or IP address of the server that properties of the certificate to check for a peer's
is contacted matches its presented certificate. DNS names and authorisation to communicate (e.g. a set of allowed values
IP addresses can be contained in the Common Name (CN) or in subjectAltName:URI or a set of allowed X509v3
subjectAltName entries. For verification, only one of these Certificate Policies)
entries is to be considered. The following precedence
applies: for DNS name validation, subjectAltName:DNS has
precedence over CN; for IP address validation, subjectAltName:
iPAddr has precedence over CN.
* Implementations SHOULD allow to configure a set of acceptable + When the configured trust base changes (e.g. removal of a
values for subjectAltName:URI. CA from the list of trusted CAs; issuance of a new CRL for
a given CA) implementations MAY re-negotiate the TLS
session to re-assess the connecting peer's continued
authorisation.
4. start exchanging RADIUS datagrams. Note Section 3.4 (1) ). The * TLS with X.509 certificates using certificate fingerprints
(this model is optional to implement): Implementations SHOULD
allow to configure a list of trusted certificates, identified
via fingerprint of the DER encoded certificate octets.
Implementations MUST support SHA-1 as the hash algorithm for
the fingerprint. To prevent attacks based on hash collisions,
support for a more contemporary hash function such as SHA-256
is RECOMMENDED.
* TLS using TLS-PSK (this model is optional to implement)
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 which 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 with PKI infrastructure, a client is uniquely identified In TLS-X.509 mode using PKIX trust models, a client is uniquely
by the serial number of the tuple (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. E.g. if
the Issuer is not in a trusted set of Issuers, the server may decline the Issuer is not in a trusted set of Issuers, the server may decline
to perform RADIUS transactions with this client. to perform RADIUS transactions with this client.
There are numerous trust models in PKI environments, and it is beyond There are numerous trust models in PKIX environments, and it is
the scope of this document to define how a particular deployment beyond the scope of this document to define how a particular
determines whether a client is trustworthy. Implementations which deployment determines whether a client is trustworthy.
want to support a wide variety of trust models should expose as many Implementations which want to support a wide variety of trust models
details of the presented certificate to the administrator as possible should expose as many details of the presented certificate to the
so that the trust model can be implemented by the administrator. As administrator as possible so that the trust model can be implemented
a suggestion, at least the following parameters of the X.509 client by the administrator. As a suggestion, at least the following
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
o Subject o Subject
o all X509v3 Extended Key Usage o all X509v3 Extended Key Usage
skipping to change at page 9, line 4 skipping to change at page 9, line 44
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 ...
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
types of packets are supported on a server. See also section
Section 3.4 for a discussion of signaling.
o When receiving an unwanted packet of type 'CoA-Request' or
'Disconnect-Request', it needs to be replied to with a 'CoA-NAK'
or 'Disconnect-NAK' respectively. The NAK SHOULD contain an
attribute Error-Cause with the value 406 ("Unsupported
Extension"); see [RFC5176] for details.
o When receiving an unwanted packet of type 'Accounting-Request',
the RADIUS/TLS server SHOULD reply with an Accounting-Response
containing an Error-Cause attribute with value 406 "Unsupported
Extension" as defined in [RFC5176]. A RADIUS/TLS accounting
client receiving such an Accounting-Response SHOULD log the error
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 [I-D.ietf-radext-dynamic-discovery]. While this
mechanism is still under development and therefore is not a normative mechanism is still under development and therefore is not a normative
skipping to change at page 10, line 14 skipping to change at page 11, line 21
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 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 [RFC4346] 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.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 packet
skipping to change at page 11, line 12 skipping to change at page 12, line 20
of a server which receives requests, processes them and sends the of a server which receives requests, processes them and sends the
appropriate replies is to be preserved. The normative rules about appropriate replies is to be preserved. The normative rules about
acceptable packet types for clients and servers mirror the packet acceptable packet types for clients and servers mirror the packet
flow behaviour from RADIUS/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 only required to send
receiving such a packet, an unconditional NAK is sent back to the NAK as defined above.
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. To prevent a
need to silently drop the packet. The client will need to deduce regression of detectability of this situation, the Accounting-
from the absence of replies that it is misconfigured; no negative Response + Error-Cause sgnaling was introduced.
ICMP response will reveal this.
4. Compatibility with other RADIUS transports 4. Compatibility with other RADIUS transports
Ongoing work in the IETF defines multiple alternative transports to Ongoing work in the IETF defines multiple alternative transports to
the classic UDP transport model as defined in [RFC2865], namely the classic UDP transport model as defined in [RFC2865], namely
RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over Datagram
[I-D.ietf-radext-dtls] and this present document on RADIUS over TLS. Transport Layer Security (DTLS) [I-D.ietf-radext-dtls] and this
present document on RADIUS over TLS.
RADIUS/TLS does not specify any inherent backwards compatibility to RADIUS/TLS does not specify any inherent backwards 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 which implements RADIUS/TLS only will not be able to
receive or send RADIUS packet payloads over other transports. An receive or send RADIUS packet payloads over other transports. An
implementation wishing to be backward or cross compatible (i.e. implementation wishing to be backward or cross compatible (i.e.
wishes to serve clients using other transports than 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.
skipping to change at page 12, line 28 skipping to change at page 13, line 32
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 plain text, including User-Password, to
intermediate IP nodes. intermediate IP nodes.
If peer communication between two devices is configured for both By virtue of being based on TCP, there are several generic attack
RADIUS/TLS transport (i.e TLS security on the transport layer, shared vectors to slow down or prevent the TCP connection from being
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
attacks in general lead only to a minor performance degradation (the
time it takes to re-establish the connection). There is one notable
exception where an attacker might create a bidding-down attack
though: If peer communication between two devices is configured for
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 security
with a secret manually configured by the administrator), and where with a secret manually configured by the administrator), and where
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 down-bidding 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 being established. Situations where clients are configured in from being established. Situations where clients are configured in
such a way are likely to occur during a migration phase from RADIUS/ such a way are likely to occur during a migration phase from RADIUS/
UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker
can reduce the security of the packet payload from the selected TLS can reduce the security of the packet payload from the selected TLS
cipher suite packet encryption to the classic MD5 per-attribute cipher suite 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 transport 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
The RADIUS/TLS transport provides authentication and encryption RADIUS/TLS provides authentication and encryption between RADIUS
between RADIUS peers. In the presence of proxies, the intermediate peers. In the presence of proxies, the intermediate proxies can
proxies can still inspect the individual RADIUS packets, i.e. "end- still inspect the individual RADIUS packets, i.e. "end-to-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 EAP methods which utilize method to protect passwords is the use of the Extensible
TLS. Authentication Protocol (EAP) and EAP methods which utilize TLS.
When using certificate fingerprints to identify RADIUS/TLS peers, any
two certificates which produce the same hash value (i.e. which have a
hash collision) will be considered the same client. It is therefore
important to make sure that the hash function used is
cryptographically uncompromised so that an attacker is very unlikely
to be able to produce a hash collision with a certificate of his
choice. While this specification mandates support for SHA-1, a later
revision will likely demand support for more contemporary hash
functions because as of issuance of this document there are already
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 is
requested to update the already-assigned TCP port number 2083 in the requested to update the already-assigned TCP port number 2083 in the
following ways: following ways:
o Reference: list the RFC number of this document as the reference o Reference: list the RFC number of this document as the reference
o Assignment Notes: add the text "The TCP port 2083 was already o Assignment Notes: add the text "The TCP port 2083 was already
skipping to change at page 14, line 25 skipping to change at page 15, line 51
June 2000. 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 for "Pre-Shared Key Ciphersuites for
Transport Layer Security (TLS)", Transport Layer Security (TLS)",
RFC 4279, December 2005. RFC 4279, December 2005.
[RFC4785] Blumenthal, U. and P. Goel,
"Pre-Shared Key (PSK)
Ciphersuites with NULL
Encryption for Transport Layer
Security (TLS)", RFC 4785,
January 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 15, line 12 skipping to change at page 16, line 30
Transport Layer Security (TLS) Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[RFC5247] Aboba, B., Simon, D., and P. [RFC5247] Aboba, B., Simon, D., and P.
Eronen, "Extensible Eronen, "Extensible
Authentication Protocol (EAP) Authentication Protocol (EAP)
Key Management Framework", Key Management Framework",
RFC 5247, August 2008. RFC 5247, August 2008.
[RFC6066] Eastlake, D., "Transport Layer
Security (TLS) Extensions:
Extension Definitions",
RFC 6066, January 2011.
[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.
10.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
skipping to change at page 15, line 41 skipping to change at page 17, line 16
[RFC3539] Aboba, B. and J. Wood, [RFC3539] Aboba, B. and J. Wood,
"Authentication, Authorization "Authentication, Authorization
and Accounting (AAA) Transport and Accounting (AAA) Transport
Profile", RFC 3539, June 2003. 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.
[RFC4107] Bellovin, S. and R. Housley,
"Guidelines for Cryptographic
Key Management", BCP 107,
RFC 4107, June 2005.
[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.
[RFC4953] Touch, J., "Defending TCP
Against Spoofing Attacks",
RFC 4953, July 2007.
[RFC6125] Saint-Andre, P. and J. Hodges,
"Representation and Verification
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 [RFC6421] Nelson, D., "Crypto-Agility
Requirements for Remote Requirements for Remote
Authentication Dial-In User Authentication Dial-In User
Service (RADIUS)", RFC 6421, Service (RADIUS)", RFC 6421,
November 2011. 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/
skipping to change at page 19, line 5 skipping to change at page 20, line 46
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 [RFC6421] defines numerous
classification criteria for protocols that strive to enhance the classification criteria for protocols that strive to enhance the
security of RADIUS. It contains mandatory (M) and recommended (R) security of RADIUS. It contains mandatory (M) and recommended (R)
criteria which crypto-agile protocols have to fulfill. The authors criteria which crypto-agile protocols have to fulfill. The authors
believe that the following assessment about the crypto-agility believe that the following assessment about the 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 being a transport profile using TLS over TCP as a
cryptographically agile properties of TLS are inherited, and RADIUS/ transport protocol, the cryptographically agile properties of TLS are
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
 End of changes. 42 change blocks. 
122 lines changed or deleted 212 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/