draft-ietf-radext-radsec-09.txt   draft-ietf-radext-radsec-10.txt 
RADIUS Extensions Working Group S. Winter RADIUS Extensions Working Group S. Winter
Internet-Draft RESTENA Internet-Draft RESTENA
Intended status: Experimental M. McCauley Intended status: Experimental M. McCauley
Expires: January 9, 2012 OSC Expires: July 12, 2012 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
July 8, 2011 January 9, 2012
TLS encryption for RADIUS TLS encryption for RADIUS
draft-ietf-radext-radsec-09 draft-ietf-radext-radsec-10
Abstract Abstract
This document specifies security on the transport layer (TLS) for the This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP. This enables dynamic RADIUS protocol when transmitted over TCP. This enables dynamic
trust relationships between RADIUS servers. trust relationships between RADIUS servers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 9, 2012. This Internet-Draft will expire on July 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.2. Ciphersuites and Compression Negotiation Considerations . 9 3.2. Ciphersuites and Compression Negotiation Considerations . 9
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10
4. Compatibility with other RADIUS transports . . . . . . . . . . 11 4. Compatibility with other RADIUS transports . . . . . . . . . . 11
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 17 Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18
1. Introduction 1. Introduction
The RADIUS protocol [RFC2865] is a widely deployed authentication and The RADIUS protocol [RFC2865] is a widely deployed authentication and
authorisation protocol. The supplementary RADIUS Accounting authorisation protocol. The supplementary RADIUS Accounting
specification [RFC2866] also provides accounting mechanisms, thus specification [RFC2866] also provides accounting mechanisms, thus
delivering a full AAA solution. However, RADIUS is experiencing delivering a full AAA solution. However, RADIUS is experiencing
several shortcomings, such as its dependency on the unreliable several shortcomings, such as its dependency on the unreliable
transport protocol UDP and the lack of security for large parts of transport protocol UDP and the lack of security for large parts of
its packet payload. RADIUS security is based on the MD5 algorithm, its packet payload. RADIUS security is based on the MD5 algorithm,
skipping to change at page 3, line 45 skipping to change at page 3, line 45
of overhead in terms of possible points of failure, longer of overhead in terms of possible points of failure, longer
transmission times as well as middleboxes through which transmission times as well as middleboxes through which
authentication traffic flows. These middleboxes may learn privacy- authentication traffic flows. These middleboxes may learn privacy-
relevant data while forwarding requests. The new features in RADIUS relevant data while forwarding requests. The new features in RADIUS
over TLS obsolete the use of IP addresses and shared MD5 secrets to over TLS obsolete the use of IP addresses and shared MD5 secrets to
identify other peers and thus allow the dynamic establishment of identify other peers and thus allow the dynamic establishment of
connections to peers that are not previously configured, and thus connections to peers that are not previously configured, and thus
makes it possible to avoid aggregation-only RADIUS proxies and reduce makes it possible to avoid aggregation-only RADIUS proxies and reduce
the number of middleboxes which can eavesdrop on traffic. One the number of middleboxes which can eavesdrop on traffic. One
mechanism to discover RADIUS over TLS peers with DNS is specified in mechanism to discover RADIUS over TLS peers with DNS is specified in
[I-D.winter-dynamic-discovery]. [I-D.ietf-radext-dynamic-discovery].
1.1. Requirements Language 1.1. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119. [RFC2119] interpreted as described in RFC 2119. [RFC2119]
1.2. Terminology 1.2. Terminology
skipping to change at page 9, line 19 skipping to change at page 9, line 19
(2) If a RADIUS/TLS server is in possession of multiple certificates (2) If a RADIUS/TLS server is in possession of multiple certificates
from different CAs (i.e. is part of multiple roaming consortia), it from different CAs (i.e. is part of multiple roaming consortia), it
will need to select one of its certificates to present to the RADIUS/ will need to select one of its certificates to present to the RADIUS/
TLS client. If the client sends the Trusted CA Indication, this hint TLS client. If the client sends the Trusted CA Indication, this hint
can make the server select the appropriate certificate and prevent a can make the server select the appropriate certificate and prevent a
handshake failure. Omitting this indication makes it impossible to handshake failure. Omitting this indication makes it impossible to
deterministically select the right certificate in this case. If deterministically select the right certificate in this case. If
there is no risk of confusing multiple roaming consortia, providing there is no risk of confusing multiple roaming consortia, providing
this indication in the handshake is not crucial. this indication in the handshake is not crucial.
(3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] (3) If dynamic peer discovery as per
is used, peer authentication alone is not sufficient; the peer must [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
also be authorised to perform user authentications. In these cases, alone is not sufficient; the peer must also be authorised to perform
the trust fabric cannot depend on peer authentication methods like user authentications. In these cases, the trust fabric cannot depend
DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be on peer authentication methods like DNSSEC to identify RADIUS/TLS
properly authorised. Typically, this can be achieved by adding nodes. The nodes also need to be properly authorised. Typically,
appropriate authorisation fields into a X.509 certificate. Such this can be achieved by adding appropriate authorisation fields into
fields include SRV authority [RFC4985], subjectAltNames, or a defined a X.509 certificate. Such fields include SRV authority [RFC4985],
list of certificate fingerprints. Operators of a RADIUS/TLS subjectAltNames, or a defined list of certificate fingerprints.
infrastructure should define their own authorisation trust model and Operators of a RADIUS/TLS infrastructure should define their own
apply this model to the certificates. The checks enumerated in authorisation trust model and apply this model to the certificates.
Section 2.3 provide sufficient flexibility for the implementation of The checks enumerated in Section 2.3 provide sufficient flexibility
authorisation trust models. for the implementation of authorisation trust models.
3.2. Ciphersuites and Compression Negotiation Considerations 3.2. Ciphersuites and Compression Negotiation Considerations
Not all TLS ciphersuites in [RFC5246] are supported by available TLS Not all TLS ciphersuites in [RFC5246] are supported by available TLS
tool kits, and licenses may be required in some cases. The existing tool kits, and licenses may be required in some cases. The existing
implementations of 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-
skipping to change at page 12, line 8 skipping to change at page 12, line 8
6. Security Considerations 6. Security Considerations
The computational resources to establish a TLS tunnel are The computational resources to establish a TLS tunnel are
significantly higher than simply sending mostly unencrypted UDP significantly higher than simply sending mostly unencrypted UDP
datagrams. Therefore, clients connecting to a RADIUS/TLS node will datagrams. Therefore, clients connecting to a RADIUS/TLS node will
more easily create high load conditions and a malicious client might more easily create high load conditions and a malicious client might
create a Denial-of-Service attack more easily. create a Denial-of-Service attack more easily.
In the case of dynamic peer discovery as per In the case of dynamic peer discovery as per
[I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
accept connections from a large, not previously known, group of able to accept connections from a large, not previously known, group
hosts, possibly the whole internet. In this case, the server's of hosts, possibly the whole internet. In this case, the server's
RADIUS/TLS port can not be protected from unauthorised connection RADIUS/TLS port can not be protected from unauthorised connection
attempts with measures on the network layer, i.e. access lists and attempts with measures on the network layer, i.e. access lists and
firewalls. This opens more attack vectors for Distributed Denial of firewalls. This opens more attack vectors for Distributed Denial of
Service attacks, just like any other service that is supposed to Service attacks, just like any other service that is supposed to
serve arbitrary clients (like for example web servers). serve arbitrary clients (like for example web servers).
In the case of dynamic peer discovery as per In the case of dynamic peer discovery as per
[I-D.winter-dynamic-discovery], X.509 certificates are the only proof [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
of authorisation for a connecting RADIUS/TLS nodes. Special care proof of authorisation for a connecting RADIUS/TLS nodes. Special
needs to be taken that certificates get verified properly according care needs to be taken that certificates get verified properly
to the chosen trust model (particularly: consulting CRLs, checking according to the chosen trust model (particularly: consulting CRLs,
critical extensions, checking subjectAltNames etc.) to prevent checking critical extensions, checking subjectAltNames etc.) to
unauthorised connections. prevent unauthorised connections.
Some TLS ciphersuites only provide integrity validation of their Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification forbids the payload, and provide no encryption. This specification forbids the
use of such ciphersuites. Since the RADIUS payload's shared secret use of such ciphersuites. Since the RADIUS payload's shared secret
is fixed and well-known, failure to comply with this requirement will is fixed to the well-known term "radsec" (see Section 2.3 (4) ) ,
expose the entire datagram payload in plain text, including User- failure to comply with this requirement will expose the entire
Password, to intermediate IP nodes. datagram payload in plain text, including User-Password, to
intermediate IP nodes.
If peer communication between two devices is configured for both If peer communication between two devices is configured for both
RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic
RADIUS security opens the way for a down-bidding attack if an RADIUS security opens the way for a down-bidding attack if an
adversary can maliciously close the TCP connection, or prevent it adversary can maliciously close the TCP connection, or prevent it
from being established. In this case, security of the packet payload from being established. In this case, security of the packet payload
is reduced from the selected TLS cipher suite packet encryption to is reduced from the selected TLS cipher suite packet encryption to
the classic MD5 per-attribute encryption. Such an attack can be the classic MD5 per-attribute encryption. Such an attack can be
mitigated by delisting the RADIUS/UDP client from the server mitigated by delisting the RADIUS/UDP client from the server
configuration after successfully migrating that client to RADIUS/TLS. configuration after successfully migrating that client to RADIUS/TLS.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
Funding and input for the development of this Internet Draft was Funding and input for the development of this Internet Draft was
provided by the European Commission co-funded project "GEANT2" provided by the European Commission co-funded project "GEANT2"
[geant2] and further feedback was provided by the TERENA Task Force [geant2] and further feedback was provided by the TERENA Task Force
Mobility [terena]. Mobility [terena].
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use
RFCs to Indicate Requirement in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Levels", BCP 14, RFC 2119,
March 1997. March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., [RFC2865] Rigney, C., Willens, S., Rubens,
and W. Simpson, "Remote A., and W. Simpson, "Remote
Authentication Dial In User Service Authentication Dial In User
(RADIUS)", 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, "Pre- [RFC4279] Eronen, P. and H. Tschofenig,
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- [RFC4785] Blumenthal, U. and P. Goel,
Shared Key (PSK) Ciphersuites with "Pre-Shared Key (PSK)
NULL Encryption for Transport Layer Ciphersuites with NULL
Security (TLS)", RFC 4785, Encryption for Transport Layer
January 2007. Security (TLS)", RFC 4785,
January 2007.
[RFC4985] Santesson, S., "Internet X.509 [RFC4985] Santesson, S., "Internet X.509
Public Key Infrastructure Subject Public Key Infrastructure
Alternative Name for Expression of Subject Alternative Name for
Service Name", RFC 4985, Expression of Service Name",
August 2007. RFC 4985, August 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, [RFC5280] Cooper, D., Santesson, S.,
S., Boeyen, S., Housley, R., and W. Farrell, S., Boeyen, S.,
Polk, "Internet X.509 Public Key Housley, R., and W. Polk,
Infrastructure Certificate and "Internet X.509 Public Key
Certificate Revocation List (CRL) Infrastructure Certificate and
Profile", RFC 5280, May 2008. Certificate Revocation List
(CRL) Profile", RFC 5280,
May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., [RFC5176] Chiba, M., Dommety, G., Eklund,
Mitton, D., and B. Aboba, "Dynamic M., Mitton, D., and B. Aboba,
Authorization Extensions to Remote "Dynamic Authorization
Authentication Dial In User Service Extensions to Remote
(RADIUS)", RFC 5176, January 2008. Authentication Dial In User
Service (RADIUS)", RFC 5176,
January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The [RFC5246] Dierks, T. and E. Rescorla, "The
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. Eronen, [RFC5247] Aboba, B., Simon, D., and P.
"Extensible Authentication Protocol Eronen, "Extensible
(EAP) Key Management Framework", Authentication Protocol (EAP)
RFC 5247, August 2008. Key Management Framework",
RFC 5247, August 2008.
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr
draft-ietf-radext-tcp-transport-09 aft-ietf-radext-tcp-transport-09
(work in progress), October 2010. (work in progress),
October 2010.
9.2. Informative References 9.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 in draft-ietf-radext-dtls-01 (work
progress), October 2010. in progress), October 2010.
[I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI- [I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley,
based Dynamic Peer Discovery for "NAI-based Dynamic Peer
RADIUS over TLS and DTLS", Discovery for RADIUS/TLS and
draft-winter-dynamic-discovery-00 RADIUS/DTLS", draft-ietf-radext-
(work in progress), February 2009. dynamic-discovery-03 (work in
progress), July 2011.
[RFC3588] Calhoun, P., Loughney, J., Guttman, [RFC3588] Calhoun, P., Loughney, J.,
E., Zorn, G., and J. Arkko, Guttman, E., Zorn, G., and J.
"Diameter Base Protocol", RFC 3588, Arkko, "Diameter Base Protocol",
September 2003. RFC 3588, September 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The [RFC4346] Dierks, T. and E. Rescorla, "The
Transport Layer Security (TLS) Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, Protocol Version 1.1", RFC 4346,
April 2006. April 2006.
[radsec-whitepaper] Open System Consultants, "RadSec - a [radsec-whitepaper] Open System Consultants, "RadSec
secure, reliable RADIUS Protocol", - a secure, reliable RADIUS
May 2005, <http://www.open.com.au/ Protocol", May 2005, <http://
radiator/radsec-whitepaper.pdf>. www.open.com.au/radiator/
radsec-whitepaper.pdf>.
[MD5-attacks] Black, J., Cochran, M., and T. [MD5-attacks] Black, J., Cochran, M., and T.
Highland, "A Study of the MD5 Highland, "A Study of the MD5
Attacks: Insights and Improvements", Attacks: Insights and
October 2006, <http:// Improvements", October 2006, <ht
www.springerlink.com/content/ tp://www.springerlink.com/
40867l85727r7084/>. content/40867l85727r7084/>.
[radsecproxy-impl] Venaas, S., "radsecproxy Project [radsecproxy-impl] Venaas, S., "radsecproxy Project
Homepage", 2007, <http:// Homepage", 2007, <http://
software.uninett.no/radsecproxy/>. software.uninett.no/
radsecproxy/>.
[eduroam] Trans-European Research and [eduroam] Trans-European Research and
Education Networking Association, Education Networking
"eduroam Homepage", 2007, Association, "eduroam Homepage",
<http://www.eduroam.org/>. 2007, <http://www.eduroam.org/>.
[geant2] Delivery of Advanced Network [geant2] Delivery of Advanced Network
Technology to Europe, "European Technology to Europe, "European
Commission Information Society and Commission Information Society
Media: GEANT2", 2008, and Media: GEANT2", 2008,
<http://www.geant2.net/>. <http://www.geant2.net/>.
[terena] TERENA, "Trans-European Research and [terena] TERENA, "Trans-European Research
Education Networking Association", and Education Networking
2008, <http://www.terena.org/>. Association", 2008,
<http://www.terena.org/>.
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.
 End of changes. 32 change blocks. 
122 lines changed or deleted 135 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/