draft-ietf-radext-radsec-06.txt | draft-ietf-radext-radsec-07.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: September 6, 2010 OSC | Expires: January 13, 2011 OSC | |||
S. Venaas | S. Venaas | |||
UNINETT | UNINETT | |||
K. Wierenga | K. Wierenga | |||
Cisco | Cisco | |||
March 05, 2010 | July 12, 2010 | |||
TLS encryption for RADIUS | TLS encryption for RADIUS | |||
draft-ietf-radext-radsec-06 | draft-ietf-radext-radsec-07 | |||
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 to IETF 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), its areas, and its working groups. Note that | Task Force (IETF). Note that other groups may also distribute | |||
other groups may also distribute working documents as Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts. | 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." | |||
The list of current Internet-Drafts can be accessed at | This Internet-Draft will expire on January 13, 2011. | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on September 6, 2010. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 34 | skipping to change at page 2, line 27 | |||
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 | |||
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. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Connecting Client Identity . . . . . . . . . . . . . . . . 6 | 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.4. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 | 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 | |||
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 | ||||
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 | 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8 | |||
3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 | 3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8 | |||
3.2. Ciphersuites and Compression Negotiation Considerations . 9 | 3.2. Ciphersuites and Compression Negotiation Considerations . 9 | |||
3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9 | 3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9 | |||
4. Compatibility with other RADIUS transports . . . . . . . . . . 10 | 4. Compatibility with other RADIUS transports . . . . . . . . . . 10 | |||
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 | 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
skipping to change at page 3, line 26 | skipping to change at page 3, line 26 | |||
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 on the transport layer. The | |||
most important use of this specification lies in roaming environments | most important use of this specification lies in roaming environments | |||
where RADIUS packets need to be transferred through different | where RADIUS packets need to be transferred through different | |||
administrative domains and untrusted, potentially hostile networks. | administrative domains and untrusted, potentially hostile networks. | |||
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]. | |||
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. RADIUS over TLS wraps the entire RADIUS | confidentiality protection (see [MD5-attacks]). RADIUS over TLS | |||
packet payload into a TLS stream and thus mitigates the risk of | wraps the entire RADIUS packet payload into a TLS stream and thus | |||
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 | |||
administrative entities is to introduce some form of a proxy chain to | administrative entities is to introduce some form of a proxy chain to | |||
route the access requests to their home server. This creates a lot | route the access requests to their home server. This creates a lot | |||
of overhead in terms of possible points of failure, longer | of overhead in terms of possible points of failure, longer | |||
transmission times as well as middleboxes through which | transmission times as well as middleboxes through which | |||
authentication traffic flows. These middleboxes may learn privacy- | authentication traffic flows. These middleboxes may learn privacy- | |||
relevant data while forwarding requests. The new features in RADIUS | relevant data while forwarding requests. The new features in RADIUS | |||
over TLS obsolete the use of IP addresses and shared MD5 secrets to | over TLS obsolete the use of IP addresses and shared MD5 secrets to | |||
identify other peers and thus allow the 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 intermediate aggregation proxies. One | makes it possible to avoid aggregation-only RADIUS proxies and reduce | |||
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.winter-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", "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] | |||
skipping to change at page 4, line 25 | skipping to change at page 4, line 26 | |||
RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] | RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] | |||
2. Normative: Transport Layer Security for RADIUS over TCP | 2. Normative: Transport Layer Security for RADIUS over 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. | dynamic authorisation changes. The source port is arbitrary. | |||
2.2. Connection Setup | 2.2. TLS negotiation | |||
RADIUS has no notion of negotiating TLS in an established connection. | ||||
Servers and clients need to be preconfigured to use RADIUS/TLS for a | ||||
given endpoint. | ||||
2.3. Connection Setup | ||||
RADIUS/TLS nodes | RADIUS/TLS 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. immediately negotiate TLS sessions. The following restrictions | |||
TLS 1.1. The following restrictions apply: | apply: according to [RFC5246] or its predecessor TLS 1.1. The | |||
following restrictions apply: | ||||
* The authentication MUST be mutual, i.e. both the RADIUS/TLS | * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 | |||
server and the RADIUS/TLS client authenticate each other. | [RFC5246]]) is REQUIRED. | |||
* The client MUST NOT negotiate cipher suites which only provide | * Support for certificate-based mutual authentication is | |||
integrity protection. | REQUIRED. | |||
* The TLS session MAY use mutual PSKs for connection setup. | * Negotiation of mutual authentication is REQUIRED. | |||
* Negotiation of compression for the TLS session is OPTIONAL. | * Negotiation of a ciphersuite providing for confidentiality as | |||
well as integrity protection is REQUIRED. | ||||
* RADIUS/TLS implementations MUST support the mandatory to | * Support for and negotiation of compression is OPTIONAL. | |||
implement cipher suites specified in TLS (i.e. | ||||
TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility | * Support for TLS-PSK mutual authentication [RFC4279] is | |||
with some current deployments implementations SHOULD support | OPTIONAL. | |||
TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as | ||||
well (see Section 3.2 (1) ). | * RADIUS/TLS implementations MUST at a minimum support | |||
negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD | ||||
support TLS_RSA_WITH_RC4_128_SHA and | ||||
TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ). | ||||
* In addition, RADIUS/TLS implementations MUST support | ||||
negotiation of the mandatory-to-implement ciphersuites | ||||
required by the versions of TLS that they support. | ||||
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], using information from trusted sources only | per [RFC5280]. | |||
(e.g. locally configured names). If service names as per | ||||
[RFC4985] are present in the certificate and dynamic discovery | ||||
utilizing SRVs in DNS is used (see | ||||
[I-D.winter-dynamic-discovery]) and the TLS implementation | ||||
supports evaluation of the extensions in [RFC4985], the SRV | ||||
entry MUST be validated. In cases where no DNS SRV resolution | ||||
took place to arrive at the TLS peer, subjectAltName:SRV | ||||
entries can be ignored. | ||||
* 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) | Section 3.1) | |||
* Implementations SHOULD allow to configure a list of acceptable | * Implementations SHOULD allow to configure a list of acceptable | |||
certificates, identified via certificate fingerprint. When a | certificates, identified via certificate fingerprint. When a | |||
fingerprint configured, the fingerprint is prepended with an | fingerprint configured, the fingerprint is prepended with an | |||
ASCII label identifying the hash function followed by a colon. | ASCII label identifying the hash function followed by a colon. | |||
skipping to change at page 6, line 9 | skipping to change at page 6, line 12 | |||
precedence over CN; for IP address validation, subjectAltName: | precedence over CN; for IP address validation, subjectAltName: | |||
iPAddr has precedence over CN. | iPAddr has precedence over CN. | |||
* Implementations SHOULD allow to configure a set of acceptable | * Implementations SHOULD allow to configure a set of acceptable | |||
values for subjectAltName:URI. | values for subjectAltName:URI. | |||
4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The | 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. 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. | |||
This does not permit to determine whether the connecting entity is a | The IP address alone does not permit the server to determine whether | |||
NAS or a different server which proxies a request. When NAT is used | the connecting entity is a NAS or a different server which proxies a | |||
on the path to the server, it also does not permit to determine | request. When NAT is used on the path to the server, it also does | |||
whether there is more than one entity connecting from the same IP | not permit to determine whether there is more than one entity | |||
address. | connecting from the same IP address. | |||
RADIUS/TLS makes it possible to preserve this traditional RADIUS | RADIUS/TLS makes it possible to preserve this traditional RADIUS | |||
semantics by identifying a connecting client by the IP address which | semantics by identifying a connecting client by the IP address which | |||
initiated the TLS connection. In addition, it permits a much more | initiated the TLS connection. In addition, it permits a much more | |||
fine-grained identification. The parameters of the TLS connection | fine-grained identification. The parameters of the TLS connection | |||
can be attributed to the RADIUS packets inside the TLS connection. | can be attributed to the RADIUS packets inside the TLS connection. | |||
An implementation of RADIUS/TLS should expose as many details of the | An implementation of RADIUS/TLS should expose as many details of the | |||
TLS connection which belongs to an incoming RADIUS packet as possible | TLS connection which belongs to an incoming RADIUS packet as possible | |||
to the application layer to allow the administrator to define the | to the application layer to allow the administrator to define the | |||
identification criteria which are applicable to his desired | identification criteria which are applicable to his desired | |||
skipping to change at page 6, line 48 | skipping to change at page 7, line 4 | |||
o all X509v3 Extended Key Usage | o all X509v3 Extended Key Usage | |||
o all X509v3 Subject Alternative Name | o all X509v3 Subject Alternative Name | |||
o all X509v3 Certificate Policies | o all X509v3 Certificate Policies | |||
In TLS-PSK operation, at least the following parameters of the TLS | In TLS-PSK operation, at least the following parameters of the TLS | |||
connection should be exposed: | connection should be exposed: | |||
o Originating IP address | o Originating IP address | |||
o TLS Identifier | o TLS Identifier | |||
2.4. RADIUS Datagrams | 2.5. 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: | |||
RADIUS/TLS clients handle the following packet types from [RFC2865], | RADIUS/TLS clients handle the following packet types from [RFC2865], | |||
[RFC2866], [RFC5176] on the connection they initiated (see | [RFC2866], [RFC5176] on the connection they initiated (see | |||
Section 3.3 (3) and (4) ): | Section 3.3 (3) and (4) ): | |||
o send Access-Request | o send Access-Request | |||
skipping to change at page 9, line 11 | skipping to change at page 9, line 13 | |||
is used, peer authentication alone is not sufficient; the peer must | is used, peer authentication alone is not sufficient; the peer must | |||
also be authorised to perform user authentications. In these cases, | also be authorised to perform user authentications. In these cases, | |||
the trust fabric cannot depend on peer authentication methods like | the trust fabric cannot depend on peer authentication methods like | |||
DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be | DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be | |||
properly authorised. Typically, this can be achieved by adding | properly authorised. Typically, this can be achieved by adding | |||
appropriate authorisation fields into a X.509 certificate. Such | appropriate authorisation fields into a X.509 certificate. Such | |||
fields include SRV authority [RFC4985], subjectAltNames, or a defined | fields include SRV authority [RFC4985], subjectAltNames, or a defined | |||
list of certificate fingerprints. Operators of a RADIUS/TLS | list of certificate fingerprints. Operators of a RADIUS/TLS | |||
infrastructure should define their own authorisation trust model and | infrastructure should define their own authorisation trust model and | |||
apply this model to the certificates. The checks enumerated in | apply this model to the certificates. The checks enumerated in | |||
Section 2.2 provide sufficient flexibility for the implementation of | Section 2.3 provide sufficient flexibility for the implementation of | |||
authorisation trust models. | 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. | |||
skipping to change at page 9, line 42 | skipping to change at page 9, line 44 | |||
(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 | |||
size can be determined by evaluating the size of the datagram that | size can be determined by evaluating the size of the datagram that | |||
arrived. Due to the stream nature of TCP and TLS, this does not hold | arrived. Due to the stream nature of TCP and TLS, this does not hold | |||
true for RADIUS/TLS packet exchange. Instead, packet boundaries of | true for RADIUS/TLS packet exchange. Instead, packet boundaries of | |||
RADIUS packets that arrive in the stream are calculated by evaluating | RADIUS packets that arrive in the stream are calculated by evaluating | |||
the packet's Length field. Special care needs to be taken on the | the packet's Length field. Special care needs to be taken on the | |||
packet sender side that the value of the Length field is indeed | packet sender side that the value of the Length field is indeed | |||
correct before sending it over the TLS tunnel, because incorrect | correct before sending it over the TLS tunnel, because incorrect | |||
packet lengths can no longer be detected by a differing datagram | packet lengths can no longer be detected by a differing datagram | |||
boundary. | boundary. See section 2.6.4 of [I-D.dekok-radext-tcp-transport] for | |||
more details. | ||||
(2) Within RADIUS [RFC2865], a shared secret is used for hiding | (2) Within RADIUS [RFC2865], a shared secret is used for hiding | |||
of attributes such as User-Password, as well as in computation of | of attributes such as User-Password, as well as in computation of | |||
the Response Authenticator. In RADIUS accounting [RFC2866], the | the Response Authenticator. In RADIUS accounting [RFC2866], the | |||
shared secret is used in computation of both the Request | shared secret is used in computation of both the Request | |||
Authenticator and the Response Authenticator. Since TLS provides | Authenticator and the Response Authenticator. Since TLS provides | |||
integrity protection and encryption sufficient to substitute for | integrity protection and encryption sufficient to substitute for | |||
RADIUS application-layer security, it is not necessary to configure a | RADIUS application-layer security, it is not necessary to configure a | |||
RADIUS shared secret. The use of a fixed string for the obsolete | RADIUS shared secret. The use of a fixed string for the obsolete | |||
shared secret eliminates possible node misconfigurations. | shared secret eliminates possible node misconfigurations. | |||
skipping to change at page 12, line 5 | skipping to change at page 12, line 7 | |||
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. | |||
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. | the classic MD5 per-attribute encryption. Such an attack can be | |||
mitigated by delisting the RADIUS/UDP client from the server | ||||
configuration after successfully migrating that client to RADIUS/TLS. | ||||
The RADIUS/TLS transport provides authentication and encryption | The RADIUS/TLS transport provides authentication and encryption | |||
between RADIUS peers. In the presence of proxies, the intermediate | between RADIUS peers. In the presence of proxies, the intermediate | |||
proxies can still inspect the individual RADIUS packets, i.e. "end- | proxies can still inspect the individual RADIUS packets, i.e. "end- | |||
to-end" encryption is not provided. Where intermediate proxies are | to-end" 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 EAP methods which utilize | |||
TLS. | TLS. | |||
skipping to change at page 12, line 50 | skipping to change at page 13, line 6 | |||
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. | |||
[RFC4279] Eronen, P. and H. Tschofenig, "Pre- | ||||
Shared Key Ciphersuites for | ||||
Transport Layer Security (TLS)", | ||||
RFC 4279, December 2005. | ||||
[RFC4346] Dierks, T. and E. Rescorla, "The | ||||
Transport Layer Security (TLS) | ||||
Protocol Version 1.1", RFC 4346, | ||||
April 2006. | ||||
[RFC4985] Santesson, S., "Internet X.509 | [RFC4985] Santesson, S., "Internet X.509 | |||
Public Key Infrastructure Subject | Public Key Infrastructure Subject | |||
Alternative Name for Expression of | Alternative Name for Expression of | |||
Service Name", RFC 4985, | Service Name", RFC 4985, | |||
August 2007. | 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 | |||
skipping to change at page 13, line 26 | skipping to change at page 13, line 40 | |||
Mitton, D., and B. Aboba, "Dynamic | Mitton, D., and B. Aboba, "Dynamic | |||
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 | |||
draft-dekok-radext-tcp-transport-01 | -ietf-dekok-radext-tcp-transport-08 | |||
(work in progress), November 2008. | (work in progress), July 2010. | |||
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-01 (work in | draft-dekok-radext-dtls-02 (work in | |||
progress), June 2009. | progress), March 2010. | |||
[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery | [I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery | |||
for RADIUS over TLD and DTLS", | for RADIUS over TLD 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 | |||
Protocol", May 2005, <http:// | Protocol", May 2005, <http:// | |||
www.open.com.au/radiator/ | www.open.com.au/radiator/ | |||
radsec-whitepaper.pdf>. | radsec-whitepaper.pdf>. | |||
[MD5-attacks] Black, J., Cochran, M., and T. | ||||
Highland, "A Study of the MD5 | ||||
Attacks: Insights and | ||||
Improvements", October 2006, <http: | ||||
//www.springerlink.com/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 Association, | |||
"eduroam Homepage", 2007, | "eduroam Homepage", 2007, | |||
<http://www.eduroam.org/>. | <http://www.eduroam.org/>. | |||
[geant2] Delivery of Advanced Network | [geant2] Delivery of Advanced Network | |||
End of changes. 28 change blocks. | ||||
61 lines changed or deleted | 83 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |