draft-ietf-radext-radsec-02.txt | draft-ietf-radext-radsec-03.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: April 27, 2009 OSC | Expires: August 15, 2009 OSC | |||
S. Venaas | S. Venaas | |||
UNINETT | UNINETT | |||
K. Wierenga | K. Wierenga | |||
Cisco | Cisco | |||
October 24, 2008 | February 11, 2009 | |||
TLS encryption for RADIUS over TCP (RadSec) | TLS encryption for RADIUS over TCP (RadSec) | |||
draft-ietf-radext-radsec-02 | draft-ietf-radext-radsec-03 | |||
Status of This Memo | Status of This Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. | |||
have been or will be disclosed, and any of which he or she becomes | ||||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
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 April 27, 2009. | This Internet-Draft will expire on August 15, 2009. | |||
Copyright Notice | ||||
Copyright (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents | ||||
(http://trustee.ietf.org/license-info) in effect on the date of | ||||
publication of this document. Please review these documents | ||||
carefully, as they describe your rights and restrictions with respect | ||||
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 . . . . . . . . . . . . . . . . 6 | 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7 | |||
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6 | 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7 | |||
3.2. Ciphersuites and Compression Negotiation Considerations . 8 | 3.2. Ciphersuites and Compression Negotiation Considerations . 7 | |||
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 | 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8 | |||
4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 | 4. Compatibility with other RADIUS transports . . . . . . . . . . 9 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | |||
Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 | |||
Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13 | Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 13 | |||
Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14 | Appendix B. Implementation Overview: Radiator . . . . . . . . . . 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 4, line 35 | skipping to change at page 4, line 35 | |||
RadSec nodes | RadSec nodes | |||
1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] | 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] | |||
2. negotiate TLS sessions according to [RFC5246] or its predecessor | 2. negotiate TLS sessions according to [RFC5246] or its predecessor | |||
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. | |||
* When using X.509 certificates, RadSec servers SHOULD indicate | ||||
their acceptable Certification Authorities as per section | ||||
7.4.4 of [RFC5246] (see Section 3.1 (1) ) | ||||
* When using X.509 certificates, the TLS Extension "Trusted CA | ||||
Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD | ||||
be used to indicate trusted CAs for the client (see | ||||
Section 3.1 (2) ) | ||||
* When using X.509 certificates, certificate validation is | ||||
performed as per [RFC5280] or its predecessor. The client MAY | ||||
perform additional checks to accomodate for different trust | ||||
models. | ||||
* 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 cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be | * The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be | |||
supported. | supported. | |||
* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and | * The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and | |||
TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 | TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 | |||
(1) ) | (1) ) | |||
3. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The | 3. If TLS is used in an X.509 certificate based operation mode, the | |||
following list of certificate validation options applies: | ||||
* Implementations MUST allow to configure a list of acceptable | ||||
Certification Authorities for incoming connections. | ||||
* Certificate validation MUST include the verification rules as | ||||
per [RFC5280]. If an SRV entry is present in the certificate | ||||
and dynamic discovery based on DNS is used, the SRV entry | ||||
SHOULD be validated. refence x.y.z here. | ||||
* Implementations SHOULD indicate their acceptable Certification | ||||
Authorities as per section 7.4.4 (server side) and x.y.z | ||||
["Trusted CA Indication"] (client side) of [RFC5246] (see | ||||
Section 3.1 (1) ) | ||||
* Implementations SHOULD allow to configure a list of acceptable | ||||
certificates, identified via certificate fingerprint. | ||||
* Peer validation always includes a check on whether the DNS | ||||
name or the IP address of the server that is contacted matches | ||||
its certificate. DNS names and IP addresses can be contained | ||||
in the Common Name (CN) or subjectAltName entries. For | ||||
verification, only one these 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 | ||||
values for subjectAltName:URI. | ||||
4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The | ||||
shared secret to compute the (obsolete) MD5 integrity checks and | shared secret to compute the (obsolete) MD5 integrity checks and | |||
attribute encryption MUST be "radsec" (see Section 3.3 (2) ). | attribute encryption MUST be "radsec" (see Section 3.3 (2) ). | |||
2.3. RADIUS Datagrams | 2.3. RADIUS Datagrams | |||
Authentication, Accounting and Authorization packets are sent | Authentication, Accounting and Authorization packets are sent | |||
according to the following rules: | according to the following rules: | |||
RadSec clients handle the following packet types from [RFC2865], | RadSec clients handle the following packet types from [RFC2865], | |||
[RFC2866], [RFC5176] on the connection they initiated (see | [RFC2866], [RFC5176] on the connection they initiated (see | |||
skipping to change at page 6, line 44 | skipping to change at page 7, line 18 | |||
defined in the previous section. | defined in the previous section. | |||
3.1. X.509 Certificate Considerations | 3.1. X.509 Certificate Considerations | |||
(1) If a RadSec client is in possession of multiple certificates from | (1) If a RadSec client is in possession of multiple certificates from | |||
different CAs (i.e. is part of multiple roaming consortia) and | different CAs (i.e. is part of multiple roaming consortia) and | |||
dynamic discovery is used, the discovery mechanism possibly does not | dynamic discovery is used, the discovery mechanism possibly does not | |||
yield sufficient information to identify the consortium uniquely | yield sufficient information to identify the consortium uniquely | |||
(e.g. DNS discovery). Subsequently, the client may not know by | (e.g. DNS discovery). Subsequently, the client may not know by | |||
itself which client certificate to use for the TLS handshake. Then | itself which client certificate to use for the TLS handshake. Then | |||
it is necessary to for the server to signal which consortium it | it is necessary for the server to signal which consortium it belongs | |||
belongs to, and which certificates it expects. If there is no risk | to, and which certificates it expects. If there is no risk of | |||
of confusing multiple roaming consortia, providing this information | confusing multiple roaming consortia, providing this information in | |||
in the handshake is not crucial. | the handshake is not crucial. | |||
(2) If a RadSec server is in possession of multiple certificates from | (2) If a RadSec server is in possession of multiple certificates from | |||
different CAs (i.e. is part of multiple roaming consortia), it will | different CAs (i.e. is part of multiple roaming consortia), it will | |||
need to select one of its certificates to present to the RadSec | need to select one of its certificates to present to the RadSec | |||
client. If the client sends the Trusted CA Indication, this hint can | client. If the client sends the Trusted CA Indication, this hint can | |||
make the server select the appropriate certificate and prevent a | 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) When using X.509 certificate validation, peer validation always | (4) If dynamic peer discovery as per [I-D.winter-dynamic-discovery] | |||
includes a check on whether the DNS name or the IP address of the | is used, peer authentication alone is not sufficient; the peer must | |||
server that is contacted matches its certificate. When a RadSec peer | also be authorised to perform user authentications. In these cases, | |||
establishes a new connection (acts as a client) to another peer, the | the trust fabric cannot depend on peer authentication methods like | |||
following rules of precedence are used during validation: | DNSSEC to identify RadSec nodes. The RadSec nodes also need to be | |||
properly authorised. Typically, this can be achieved by adding | ||||
o If the client expects a certain fully qualified domain name (FQDN) | appropriate authorisation fields into a X.509 certificate. Such | |||
and the presented certificate contains both at least one instance | fields include SRV authority (x.y.z... reference), subjectAltName: | |||
of the subjectAltName field with type dNSName and a Common Name, | URI, or a defined list of certificate fingerprints. Operators of a | |||
then the certificate is considered a match if any one of those | RadSec infrastructure should define their own authorisation trust | |||
subjectAltName fields matches the expected FQDN. The Common Name | model and apply this model to the certificates. The checks | |||
field is not evaluated in this case. | enumerated in Section 2.2 provide sufficient flexibility for the | |||
implementation of authorisation trust models. | ||||
o If the client expects a certain fully qualified domain name (FQDN) | ||||
and the presented certificate does not contain any subjectAltName | ||||
field with type dNSName, then the certificate is considered a | ||||
match if the Common Name field matches the expected FQDN. | ||||
o If the client expects a certain IP address and the presented | ||||
certificate contains both at least one instance of the | ||||
subjectAltName field with type iPAddr and a Common Name, then the | ||||
certificate is considered a match if any one of those | ||||
subjectAltName fields matches the expected IP address. The Common | ||||
Name field is not evaluated in this case. | ||||
o If the client expects a certain IP address and the presented | ||||
certificate does not contain any subjectAltName field with type | ||||
iPAddr, then the certificate is considered a match if the Common | ||||
Name field matches the expected IP address. | ||||
(4) If dynamic peer resolution is used, the above verification steps | ||||
may not be sufficient to ensure that a connecting peer is authorised | ||||
to perform user authentications. In these cases, the trust fabric | ||||
cannot depend on peer authentication methods like DNSSEC to identify | ||||
RadSec nodes. The RadSec nodes also need to be properly authorised. | ||||
Operators of a RadSec infrastructure should define their own | ||||
authorisation trust model and apply this model to the certificates | ||||
after they have passed the standard validity checks above. Current | ||||
RadSec implementations offer varying degrees of versatility for | ||||
defining criteria which certificates to accept. | ||||
3.2. Ciphersuites and Compression Negotiation Considerations | 3.2. Ciphersuites and Compression Negotiation Considerations | |||
RadSec implementations need not necessarily support all TLS | RadSec implementations need not necessarily support all TLS | |||
ciphersuites listed in [RFC5246]. Not all TLS ciphersuites | ciphersuites listed in [RFC5246]. Not all TLS ciphersuites | |||
are supported by available TLS tool kits and licenses may be required | are supported by available TLS tool kits and licenses may be required | |||
in some cases. The existing implementations of RadSec use OpenSSL as | in some cases. The existing implementations of RadSec use OpenSSL as | |||
cryptographic backend, which supports all of the ciphersuites listed | cryptographic backend, which supports all of the ciphersuites listed | |||
in the rules in the normative section. | in the rules in the normative section. | |||
The TLS cphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- | The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- | |||
implement according to [RFC5246] and thus has to be supported by | implement according to [RFC5246] and thus has to be supported by | |||
RadSec nodes. | RadSec nodes. | |||
The two other ciphersuites in the normative section | The two other ciphersuites in the normative section | |||
(TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are | (TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are | |||
widely implemented in TLS toolkits and are considered good practice | widely implemented in TLS toolkits and are considered good practice | |||
to implement. | to implement. | |||
TLS also supports compression. Compression is an optional | TLS also supports compression. Compression is an optional | |||
feature. During the RadSec conversation the client and server may | feature. During the RadSec conversation the client and server may | |||
skipping to change at page 9, line 22 | skipping to change at page 9, line 16 | |||
(4) RADIUS [RFC2865] used negative ICMP responses to a newly | (4) RADIUS [RFC2865] used 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 RadSec | These packet types are listed as to be received in RadSec | |||
implementations. Note well: it is not required for an implementation | implementations. Note well: it is not required for an implementation | |||
to actually process these packet types. It is sufficient that upon | to actually process these packet types. It is sufficient that upon | |||
receiving such a packet, an unconditional NAK is sent back to | receiving such a packet, an unconditional NAK is sent back to | |||
indicate that the action is not supported. | indicate that the action is not supported. | |||
4. Diameter Compatibility | 4. Compatibility with other RADIUS transports | |||
Ongoing work in the IETF defines multiple alternative transports to | ||||
the classic UDP transport model as defined in [RFC2865], namely | ||||
RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS | ||||
[I-D.dekok-radext-dtls] and the present document on RadSec. | ||||
RadSec does not specify any inherent backwards compatibility to | ||||
classic RADIUS or cross compatibility to the other transports, i.e. | ||||
an implementation which implements RadSec only will not be able to | ||||
receive or send RADIUS packet payloads over other transports. An | ||||
implementation wishing to be backward or cross compatible (i.e. | ||||
wishes to serve clients using other transports than RadSec) will need | ||||
to implement the other transports and RadSec transport and be | ||||
prepared to send and receive on all implemented transports, which is | ||||
called a multi-stack implementation. | ||||
If a given IP device is able to receive RADIUS payloads on multiple | ||||
transports, this may or may not be the same instance of software, and | ||||
it may or may not serve the same purposes. It is not safe to assume | ||||
that both ports are interchangeable. In particular, it can not be | ||||
assumed that state is maintained for the packet payloads between the | ||||
transports. Two such instances MUST be considered separate RADIUS | ||||
server entities. | ||||
As a consequence, the selection of transports to communicate from a | ||||
client to a server is a manual administrative action. An automatic | ||||
fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to | ||||
down-bidding attacks on the peer communication. | ||||
5. Diameter Compatibility | ||||
Since RadSec is only a new transport profile for RADIUS, | Since RadSec is only a new transport profile for RADIUS, | |||
compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - | compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] - | |||
Diameter [RFC3588] is identical. The considerations regarding | Diameter [RFC3588] is identical. The considerations regarding | |||
payload size in [I-D.dekok-radext-tcp-transport] apply. | payload size in [I-D.dekok-radext-tcp-transport] apply. | |||
5. 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 RadSec node will more | datagrams. Therefore, clients connecting to a RadSec node will more | |||
easily create high load conditions and a malicious client might | 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, a RadSec node needs to be able | In the case of dynamic peer discovery as per | |||
to accept connections from a large, not previously known, group of | [I-D.winter-dynamic-discovery], a RadSec node needs to be able to | |||
accept connections from a large, not previously known, group of | ||||
hosts, possibly the whole internet. In this case, the server's | hosts, possibly the whole internet. In this case, the server's | |||
RadSec port can not be protected from unauthorised connection | RadSec 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, X.509 certificates are the | In the case of dynamic peer discovery as per | |||
only proof of authorisation for a connecting RadSec nodes. Special | [I-D.winter-dynamic-discovery], X.509 certificates are the only proof | |||
care needs to be taken that certificates get verified properly | of authorisation for a connecting RadSec nodes. Special care needs | |||
according to the chosen trust model (particularly: consulting CRL | to be taken that certificates get verified properly according to the | |||
lists, checking critical extensions, checking subjectAltNames etc.) | chosen trust model (particularly: consulting CRLs, checking critical | |||
to prevent unauthorised connections. | extensions, checking subjectAltNames etc.) to prevent unauthorised | |||
connections. | ||||
Some TLS ciphersuites only provide integrity validation of their | Some TLS ciphersuites only provide integrity validation of their | |||
payload, and provide no encryption. This specification forbids the | payload, and provide no encryption. This specification forbids the | |||
use of such ciphersuites. Since the RADIUS payload's shared secret | use of such ciphersuites. Since the RADIUS payload's shared secret | |||
is fixed and well-known, failure to comply with this requirement will | is fixed and well-known, failure to comply with this requirement will | |||
expose the entire datagram payload in plain text, including User- | expose the entire datagram payload in plain text, including User- | |||
Password, to intermediate IP nodes. | Password, to intermediate IP nodes. | |||
6. IANA Considerations | If peer communication between two devices is configured for both | |||
RadSec and classic RADIUS, a failover from RadSec to classic RADIUS | ||||
opens the way for a down-bidding attack if an adversary can | ||||
maliciously close the TCP connection, or prevent it from being | ||||
established. In this case, security of the packet payload is reduced | ||||
from the selected TLS cipher suite packet encryption to the classic | ||||
MD5 per-attribute encryption. | ||||
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. | |||
7. 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 | |||
product (see [radsec-whitepaper]). | product (see [radsec-whitepaper]). | |||
Funding and input for the development of this Internet Draft was | Funding and input for the development of this Internet Draft was | |||
provided by the European Commission co-funded project "GEANT2" | provided by the European Commission co-funded project "GEANT2" | |||
[geant2] and further feedback was provided by the TERENA Task Force | [geant2] and further feedback was provided by the TERENA Task Force | |||
Mobility [terena]. | Mobility [terena]. | |||
8. References | 9. References | |||
8.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in | [RFC2119] Bradner, S., "Key words for use in | |||
RFCs to Indicate Requirement | RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, | Levels", BCP 14, RFC 2119, | |||
March 1997. | March 1997. | |||
[RFC2865] Rigney, C., Willens, S., Rubens, | [RFC2865] Rigney, C., Willens, S., Rubens, | |||
A., and W. Simpson, "Remote | A., and W. Simpson, "Remote | |||
Authentication Dial In User Service | Authentication Dial In User Service | |||
(RADIUS)", RFC 2865, June 2000. | (RADIUS)", RFC 2865, June 2000. | |||
skipping to change at page 11, line 17 | skipping to change at page 11, line 52 | |||
Authorization Extensions to Remote | Authorization Extensions to Remote | |||
Authentication Dial In User Service | Authentication Dial In User Service | |||
(RADIUS)", RFC 5176, January 2008. | (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. | |||
[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", | [I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", | |||
draft-dekok-radext-tcp-transport-00 | draft-dekok-radext-tcp-transport-01 | |||
(work in progress), July 2008. | (work in progress), November 2008. | |||
8.2. Informative References | 9.2. Informative References | |||
[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport | ||||
Layer for RADIUS", | ||||
draft-dekok-radext-dtls-00 (work in | ||||
progress), February 2007. | ||||
[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery | ||||
for RADIUS over TLD and DTLS", | ||||
draft-winter-dynamic-discovery-00 | ||||
(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 | |||
Protocol", May 2005, <http:// | Protocol", May 2005, <http:// | |||
www.open.com.au/radiator/ | www.open.com.au/radiator/ | |||
skipping to change at page 12, line 25 | skipping to change at page 13, line 21 | |||
describes an algorithm to retrieve the RadSec route information from | describes an algorithm to retrieve the RadSec route information from | |||
the global DNS using NAPTR and SRV records. The input of the | the global DNS using NAPTR and SRV records. The input of the | |||
algorithm is the realm part of the user name. | algorithm is the realm part of the user name. | |||
The following algorithm is used to discover a target server from a | The following algorithm is used to discover a target server from a | |||
Realm using DNS: | Realm using DNS: | |||
1. Look for NAPTR records for the Realm. If found, continue at step | 1. Look for NAPTR records for the Realm. If found, continue at step | |||
2, otherwise continue at step 4. | 2, otherwise continue at step 4. | |||
2. For each NAPTR found record, examine the Service field and use | 2. For each NAPTR record found, examine the Service field and use | |||
that to determine the transport protocol and TLS requirements for | that to determine the transport protocol and TLS requirements for | |||
the server. The Service field starts with 'AAA' for insecure and | the server. The Service field starts with 'AAA' for insecure and | |||
'AAAS' for TLS secured. The Service field contains '+RADSECS' | 'AAAS' for TLS secured. The Service field contains '+RADSECS' | |||
for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' | for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS' | |||
for RADIUS protocol over UDP. The most common Service field you | for RADIUS protocol over UDP. The most common Service field you | |||
will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. | will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP. | |||
3. | 3. | |||
A. If the NAPTR has the 'S' flag, look for SRV records for the | A. If the NAPTR has the 'S' flag, look for SRV records for the | |||
skipping to change at page 13, line 20 | skipping to change at page 14, line 18 | |||
example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" | example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" | |||
_radsec._tcp.example.com. | _radsec._tcp.example.com. | |||
_radsec._tcp.example.com. IN SRV 0 10 2083 radsec.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 | radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704 | |||
Then the target selected would be a RadSec server on port 2083 at | 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 | IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be | |||
made over TCP/IP, and TLS encryption would be used. This complete | made over TCP/IP, and TLS encryption would be used. This complete | |||
specification of the realm is the most flexible and is recommended. | specification of the realm is the most flexible one and is | |||
recommended. | ||||
Appendix B. Implementation Overview: Radiator | 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 | |||
Radiator to listen on the configured port and address(es) for | Radiator to listen on the configured port and address(es) for | |||
connections from <Authby RADSEC> clients. When an <Authby RADSEC> | connections from <Authby RADSEC> clients. When an <Authby RADSEC> | |||
client connects to a <ServerRADSEC> server, the client sends RADIUS | client connects to a <ServerRADSEC> server, the client sends RADIUS | |||
requests through the stream to the server. The server then services | requests through the stream to the server. The server then handles | |||
the request in the same was as if the request had been received from | the request in the same way as if the request had been received from | |||
a conventional UDP RADIUS client. | a conventional UDP RADIUS client. | |||
Radiator is compliant to version 2 of RadSec if the following options | Radiator is compliant to version 2 of RadSec if the following options | |||
are used: | are used: | |||
<AuthBy RADSEC> | <AuthBy RADSEC> | |||
* Protocol tcp | * Protocol tcp | |||
* UseTLS | * UseTLS | |||
* TLS_CertificateFile | * TLS_CertificateFile | |||
* Secret radsec | ||||
* Secret radsec | ||||
<ServerRADSEC> | <ServerRADSEC> | |||
* Protocol tcp | * Protocol tcp | |||
* UseTLS | * UseTLS | |||
* TLS_RequireClientCert | * TLS_RequireClientCert | |||
* Secret radsec | * Secret radsec | |||
skipping to change at page 17, line 4 | skipping to change at line 768 | |||
Klaas Wierenga | Klaas Wierenga | |||
Cisco Systems International BV | Cisco Systems International BV | |||
Haarlerbergweg 13-19 | Haarlerbergweg 13-19 | |||
Amsterdam 1101 CH | Amsterdam 1101 CH | |||
The Netherlands | The Netherlands | |||
Phone: +31 (0)20 3571752 | Phone: +31 (0)20 3571752 | |||
Fax: | Fax: | |||
EMail: kwiereng@cisco.com | EMail: kwiereng@cisco.com | |||
URI: http://www.cisco.com. | URI: http://www.cisco.com. | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Acknowledgement | ||||
This document was produced using xml2rfc v1.33 (of | ||||
http://xml.resource.org/) from a source in RFC-2629 XML format. | ||||
End of changes. 29 change blocks. | ||||
103 lines changed or deleted | 157 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/ |