draft-ietf-radext-radsec-03.txt   draft-ietf-radext-radsec-04.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: August 15, 2009 OSC Expires: September 7, 2009 OSC
S. Venaas S. Venaas
UNINETT UNINETT
K. Wierenga K. Wierenga
Cisco Cisco
February 11, 2009 March 06, 2009
TLS encryption for RADIUS over TCP (RadSec) TLS encryption for RADIUS over TCP (RadSec)
draft-ietf-radext-radsec-03 draft-ietf-radext-radsec-04
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2009. This Internet-Draft will expire on September 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 [RFC2865] when transmitted over TCP RADIUS protocol [RFC2865] when transmitted over TCP
[I-D.dekok-radext-tcp-transport]. This enables dynamic trust [I-D.dekok-radext-tcp-transport]. This enables dynamic trust
relationships between RADIUS servers. relationships between RADIUS servers.
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
2. Normative: Transport Layer Security for RADIUS over TCP . . . 4 2. Normative: Transport Layer Security for RADIUS over TCP . . . 4
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5 2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7
3.2. Ciphersuites and Compression Negotiation Considerations . 7 3.2. Ciphersuites and Compression Negotiation Considerations . 8
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
4. Compatibility with other RADIUS transports . . . . . . . . . . 9 4. Compatibility with other RADIUS transports . . . . . . . . . . 9
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 13 Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13
Appendix B. Implementation Overview: Radiator . . . . . . . . . . 14 Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14
Appendix C. Implementation Overview: radsecproxy . . . . . . . . 15
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 42 skipping to change at page 3, line 42
massive deployment of RADIUS-servers under control by different massive deployment of RADIUS-servers under control by different
administrative entities is to introduce some form of a proxy chain to administrative entities is to introduce some form of a proxy chain to
route the access requests to their home server. This creates a lot route the access requests to their home server. This creates a lot
of overhead in terms of possible points of failure, longer of overhead in terms of possible points of failure, longer
transmission times as well as middleboxes through which transmission times as well as middleboxes through which
authentication traffic flows. These middleboxes may learn privacy- authentication traffic flows. These middleboxes may learn privacy-
relevant data while forwarding requests. The new features in RadSec relevant data while forwarding requests. The new features in RadSec
obsolete the use of IP addresses and shared MD5 secrets to identify obsolete the use of IP addresses and shared MD5 secrets to identify
other peers and thus allow the dynamic establishment of connections other peers and thus allow the dynamic establishment of connections
to peers that are not previously configured, and thus makes it to peers that are not previously configured, and thus makes it
possible to avoid intermediate aggregation proxies. The definition possible to avoid intermediate aggregation proxies. One mechanism
of lookup mechanisms is out of scope of this document, but an discover RadSec peers with DNS is specified in
implementation of a DNS NAPTR lookup based mechanism exists and is [I-D.winter-dynamic-discovery].
described as an example lookup mechanism in Appendix A.
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", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119. [RFC2119] RFC 2119. [RFC2119]
1.2. Terminology 1.2. Terminology
skipping to change at page 4, line 40 skipping to change at page 4, line 39
TLS 1.1. The following restrictions apply: TLS 1.1. The following restrictions apply:
* The authentication MUST be mutual, i.e. both the RadSec server * The authentication MUST be mutual, i.e. both the RadSec server
and the RadSec client authenticate each other. and the RadSec client authenticate each other.
* The client MUST NOT negotiate cipher suites which only provide * The client MUST NOT negotiate cipher suites which only provide
integrity protection. integrity protection.
* The TLS session MAY use mutual PSKs for connection setup. * The TLS session MAY use mutual PSKs for connection setup.
* The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be * RADSEC implementations MUST support he mandatory to implement
supported. cipher suites specified in TLS. For purposes of compatibility
with some current deployments implementations SHOULD support
* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_RC4_128_SHA as well (see Section 3.2 (1) ).
TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
(1) )
3. If TLS is used in an X.509 certificate based operation mode, the 3. If TLS is used in an X.509 certificate based operation mode, the
following list of certificate validation options applies: following list of certificate validation options applies:
* Implementations MUST allow to configure a list of acceptable * Implementations MUST allow to configure a list of acceptable
Certification Authorities for incoming connections. Certification Authorities for incoming connections.
* Certificate validation MUST include the verification rules as * Certificate validation MUST include the verification rules as
per [RFC5280]. If an SRV entry is present in the certificate per [RFC5280]. If service names as per [RFC4985] are present
and dynamic discovery based on DNS is used, the SRV entry in the certificate and dynamic discovery utilizing SRVs in DNS
SHOULD be validated. refence x.y.z here. is used (see [I-D.winter-dynamic-discovery]), the SRV entry
SHOULD be validated.
* Implementations SHOULD indicate their acceptable Certification * Implementations SHOULD indicate their acceptable Certification
Authorities as per section 7.4.4 (server side) and x.y.z Authorities as per section 7.4.4 (server side) and x.y.z
["Trusted CA Indication"] (client side) of [RFC5246] (see ["Trusted CA Indication"] (client side) of [RFC5246] (see
Section 3.1 (1) ) Section 3.1 (1) )
* Implementations SHOULD allow to configure a list of acceptable * Implementations SHOULD allow to configure a list of acceptable
certificates, identified via certificate fingerprint. certificates, identified via certificate fingerprint. When a
fingerprint configured, the fingerprint is prepended with an
ASCII label identifying the hash function followed by a colon.
Implementations MUST support SHA-1 as the hash algorithm and
use the ASCII label "sha-1" to identify the SHA-1 algorithm.
The length of a SHA-1 hash is 20 bytes and the length of the
corresponding fingerprint string is 65 characters. An example
certificate fingerprint is: sha-
1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
* Peer validation always includes a check on whether the DNS * Peer validation always includes a check on whether the DNS
name or the IP address of the server that is contacted matches name or the IP address of the server that is contacted matches
its certificate. DNS names and IP addresses can be contained its certificate. DNS names and IP addresses can be contained
in the Common Name (CN) or subjectAltName entries. For in the Common Name (CN) or subjectAltName entries. For
verification, only one these entries is to be considered. The verification, only one 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.
skipping to change at page 10, line 46 skipping to change at page 11, line 5
Password, to intermediate IP nodes. 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
RadSec and classic RADIUS, a failover from RadSec to classic RADIUS RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
opens the way for a down-bidding attack if an adversary can opens the way for a down-bidding attack if an adversary can
maliciously close the TCP connection, or prevent it from being maliciously close the TCP connection, or prevent it from being
established. In this case, security of the packet payload is reduced established. In this case, security of the packet payload is reduced
from the selected TLS cipher suite packet encryption to the classic from the selected TLS cipher suite packet encryption to the classic
MD5 per-attribute encryption. MD5 per-attribute encryption.
The RadSec transport provides authentication and encryption between
RADIUS peers. In the presence of proxies, the intermediate proxies
can still inspect the individual RADIUS packets, i.e. "end-to-end"
encryption is not provided. Where intermediate proxies are
untrusted, it is desirable to use other RADIUS mechanisms to prevent
RADIUS packet payload from inspection by such proxies. One common
method to protect passwords is the use of EAP methods which utilize
TLS.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. The TCP port 2083 was already This document has no actions for IANA. The TCP port 2083 was already
previously assigned by IANA for RadSec. No new RADIUS attributes or previously assigned by IANA for RadSec. No new RADIUS attributes or
packet codes are defined. packet codes are defined.
8. Acknowledgements 8. Acknowledgements
RadSec version 1 was first implemented by Open Systems Consultants, RadSec version 1 was first implemented by Open Systems Consultants,
Currumbin Waters, Australia, for their "Radiator" RADIUS server Currumbin Waters, Australia, for their "Radiator" RADIUS server
skipping to change at page 11, line 33 skipping to change at page 11, line 48
March 1997. March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, [RFC2865] Rigney, C., Willens, S., Rubens,
A., and W. Simpson, "Remote A., and W. Simpson, "Remote
Authentication Dial In User Service Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", [RFC2866] Rigney, C., "RADIUS Accounting",
RFC 2866, June 2000. RFC 2866, June 2000.
[RFC4985] Santesson, S., "Internet X.509
Public Key Infrastructure Subject
Alternative Name for Expression of
Service Name", RFC 4985,
August 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, [RFC5280] Cooper, D., Santesson, S., Farrell,
S., Boeyen, S., Housley, R., and W. S., Boeyen, S., Housley, R., and W.
Polk, "Internet X.509 Public Key Polk, "Internet X.509 Public Key
Infrastructure Certificate and Infrastructure Certificate and
Certificate Revocation List (CRL) Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008. Profile", RFC 5280, May 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., [RFC5176] Chiba, M., Dommety, G., Eklund, M.,
Mitton, D., and B. Aboba, "Dynamic Mitton, D., and B. Aboba, "Dynamic
Authorization Extensions to Remote Authorization Extensions to Remote
skipping to change at page 12, line 13 skipping to change at page 12, line 34
draft-dekok-radext-tcp-transport-01 draft-dekok-radext-tcp-transport-01
(work in progress), November 2008. (work in progress), November 2008.
9.2. Informative References 9.2. Informative References
[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport
Layer for RADIUS", Layer for RADIUS",
draft-dekok-radext-dtls-00 (work in draft-dekok-radext-dtls-00 (work in
progress), February 2007. progress), February 2007.
[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery [I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI-
for RADIUS over TLD and DTLS", based Dynamic Peer Discovery for
RADIUS over TLS and DTLS",
draft-winter-dynamic-discovery-00 draft-winter-dynamic-discovery-00
(work in progress), February 2009. (work in progress), February 2009.
[RFC3588] Calhoun, P., Loughney, J., Guttman, [RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, "Diameter Base Protocol", RFC 3588,
September 2003. September 2003.
[radsec-whitepaper] Open System Consultants, "RadSec - [radsec-whitepaper] Open System Consultants, "RadSec -
a secure, reliable RADIUS a secure, reliable RADIUS
skipping to change at page 13, line 6 skipping to change at page 13, line 27
Technology to Europe, "European Technology to Europe, "European
Commission Information Society and Commission Information Society and
Media: GEANT2", 2008, Media: GEANT2", 2008,
<http://www.geant2.net/>. <http://www.geant2.net/>.
[terena] TERENA, "Trans-European Research [terena] TERENA, "Trans-European Research
and Education Networking and Education Networking
Association", 2008, Association", 2008,
<http://www.terena.org/>. <http://www.terena.org/>.
Appendix A. DNS NAPTR Peer Discovery Appendix A. Implementation Overview: Radiator
The following text is paraphrased from the file goodies/dnsroam.cfg
in the Radiator distribution; further documentation of the <AuthBy
DNSROAM> feature in Radiator can be found at [radiator-manual]. It
describes an algorithm to retrieve the RadSec route information from
the global DNS using NAPTR and SRV records. The input of the
algorithm is the realm part of the user name.
The following algorithm is used to discover a target server from a
Realm using DNS:
1. Look for NAPTR records for the Realm. If found, continue at step
2, otherwise continue at step 4.
2. For each NAPTR record found, examine the Service field and use
that to determine the transport protocol and TLS requirements for
the server. The Service field starts with 'AAA' for insecure and
'AAAS' for TLS secured. The Service field contains '+RADSECS'
for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS'
for RADIUS protocol over UDP. The most common Service field you
will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP.
3.
A. If the NAPTR has the 'S' flag, look for SRV records for the
name. For each SRV record found, note the Port number and
then look for A and AAAA records corresponding to the name in
the SRV record.
B. If the NAPTR has the 'A' flag, look for a A and AAAA records
for the name.
4. All A and AAAA records found are ordered according to their Order
and Preference fields. The most preferable server address is
used as the target server address, along with any other server
attributes discovered from DNS. If no SRV record was found for
the address, the DNSROAM configured Port is used. Algorithm
terminates.
5. Look for A and AAAA records on the literal realm name, preceded
by "_radsec._tcp.". For example, if the realm is 'example.com',
it looks for the record '_radsec._tcp.example.com'. If more than
one result is returned, no ordering is assumed. Algorithm
terminates.
For example, if the User-Name realm was 'example.com', and DNS
contained the following records:
example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" ""
_radsec._tcp.example.com.
_radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com.
radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704
Then the target selected would be a RadSec server on port 2083 at
IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be
made over TCP/IP, and TLS encryption would be used. This complete
specification of the realm is the most flexible one and is
recommended.
Appendix B. 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.
The <ServerRADSEC> clause defines a RadSec server, and causes The <ServerRADSEC> clause defines a RadSec server, and causes
skipping to change at page 15, line 22 skipping to change at page 14, line 28
* Secret radsec * Secret radsec
As of Radiator 3.15, the default shared secret for RadSec connections As of Radiator 3.15, the default shared secret for RadSec connections
is configurable and defaults to "mysecret" (without quotes). For is configurable and defaults to "mysecret" (without quotes). For
compliance with this document, this setting needs to be configured compliance with this document, this setting needs to be configured
for the shared secret "radsec". The implementation uses TCP for the shared secret "radsec". The implementation uses TCP
keepalive socket options, but does not send Status-Server packets. keepalive socket options, but does not send Status-Server packets.
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 C. 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 used
in other circumstances as well. 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
 End of changes. 20 change blocks. 
97 lines changed or deleted 64 lines changed or added

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