draft-ietf-radext-radsec-12.txt | rfc6614.txt | |||
---|---|---|---|---|
RADIUS Extensions Working Group S. Winter | Internet Engineering Task Force (IETF) S. Winter | |||
Internet-Draft RESTENA | Request for Comments: 6614 RESTENA | |||
Intended status: Experimental M. McCauley | Category: Experimental M. McCauley | |||
Expires: August 17, 2012 OSC | ISSN: 2070-1721 OSC | |||
S. Venaas | S. Venaas | |||
K. Wierenga | K. Wierenga | |||
Cisco | Cisco | |||
February 14, 2012 | May 2012 | |||
Transport Layer Security (TLS) encryption for RADIUS | Transport Layer Security (TLS) Encryption for RADIUS | |||
draft-ietf-radext-radsec-12 | ||||
Abstract | Abstract | |||
This document specifies a transport profile for RADIUS using | This document specifies a transport profile for RADIUS using | |||
Transport Layer Security (TLS) over TCP as the transport protocol. | Transport Layer Security (TLS) over TCP as the transport protocol. | |||
This enables dynamic trust relationships between RADIUS servers. | This enables dynamic trust relationships between RADIUS servers. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for examination, experimental implementation, and | |||
evaluation. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document defines an Experimental Protocol for the Internet | |||
and may be updated, replaced, or obsoleted by other documents at any | community. This document is a product of the Internet Engineering | |||
time. It is inappropriate to use Internet-Drafts as reference | Task Force (IETF). It represents the consensus of the IETF | |||
material or to cite them other than as "work in progress." | community. It has received public review and has been approved for | |||
publication by the Internet Engineering Steering Group (IESG). Not | ||||
all documents approved by the IESG are a candidate for any level of | ||||
Internet Standard; see Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on August 17, 2012. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6614. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
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. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language ......................................3 | |||
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Terminology ................................................4 | |||
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 | 1.3. Document Status ............................................4 | |||
2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 5 | 2. Normative: Transport Layer Security for RADIUS/TCP ..............5 | |||
2.1. TCP port and packet types . . . . . . . . . . . . . . . . 5 | 2.1. TCP port and Packet Types ..................................5 | |||
2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. TLS Negotiation ............................................5 | |||
2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 | 2.3. Connection Setup ...........................................5 | |||
2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 7 | 2.4. Connecting Client Identity .................................7 | |||
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 8 | 2.5. RADIUS Datagrams ...........................................8 | |||
3. Informative: Design Decisions . . . . . . . . . . . . . . . . 10 | 3. Informative: Design Decisions ..................................10 | |||
3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 10 | 3.1. Implications of Dynamic Peer Discovery ....................10 | |||
3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 10 | 3.2. X.509 Certificate Considerations ..........................10 | |||
3.3. Ciphersuites and Compression Negotiation Considerations . 11 | 3.3. Ciphersuites and Compression Negotiation Considerations ...11 | |||
3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 11 | 3.4. RADIUS Datagram Considerations ............................11 | |||
4. Compatibility with other RADIUS transports . . . . . . . . . . 12 | 4. Compatibility with Other RADIUS Transports .....................12 | |||
5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 13 | 5. Diameter Compatibility .........................................13 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6. Security Considerations ........................................13 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations ............................................14 | |||
8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 15 | 8. Acknowledgements ...............................................15 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. References .....................................................15 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9.1. Normative References ......................................15 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 9.2. Informative References ....................................16 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 | Appendix A. Implementation Overview: Radiator .....................18 | |||
Appendix A. Implementation Overview: Radiator . . . . . . . . . . 18 | Appendix B. Implementation Overview: radsecproxy ..................19 | |||
Appendix B. Implementation Overview: radsecproxy . . . . . . . . 19 | Appendix C. Assessment of Crypto-Agility Requirements .............20 | |||
Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 20 | ||||
1. Introduction | 1. Introduction | |||
The RADIUS protocol [RFC2865] is a widely deployed authentication and | The RADIUS protocol [RFC2865] is a widely deployed authentication and | |||
authorisation protocol. The supplementary RADIUS Accounting | authorization protocol. The supplementary RADIUS Accounting | |||
specification [RFC2866] also provides accounting mechanisms, thus | specification [RFC2866] provides accounting mechanisms, thus | |||
delivering a full Authentication, Authorization, and Accounting (AAA) | delivering a full Authentication, Authorization, and Accounting (AAA) | |||
solution. However, RADIUS is experiencing several shortcomings, such | solution. However, RADIUS is experiencing several shortcomings, such | |||
as its dependency on the unreliable transport protocol UDP and the | as its dependency on the unreliable transport protocol UDP and the | |||
lack of security for large parts of its packet payload. RADIUS | lack of security for large parts of its packet payload. RADIUS | |||
security is based on the MD5 algorithm, which has been proven to be | security is based on the MD5 algorithm, which has been proven to be | |||
insecure. | insecure. | |||
The main focus of RADIUS over TLS is to provide a means to secure the | The main focus of RADIUS over TLS is to provide a means to secure the | |||
communication between RADIUS/TCP peers using TLS. The most important | communication between RADIUS/TCP peers using TLS. The most important | |||
use of this specification lies in roaming environments where RADIUS | use of this specification lies in roaming environments where RADIUS | |||
packets need to be transferred through different administrative | packets need to be transferred through different administrative | |||
domains and untrusted, potentially hostile networks. An example for | domains and untrusted, potentially hostile networks. An example for | |||
a world-wide roaming environment that uses RADIUS over TLS to secure | a worldwide roaming environment that uses RADIUS over TLS to secure | |||
communication is "eduroam", see [eduroam]. | communication is "eduroam", see [eduroam]. | |||
There are multiple known attacks on the MD5 algorithm which is used | There are multiple known attacks on the MD5 algorithm that is used in | |||
in RADIUS to provide integrity protection and a limited | RADIUS to provide integrity protection and a limited confidentiality | |||
confidentiality protection (see [MD5-attacks]). RADIUS over TLS | protection (see [MD5-attacks]). RADIUS over TLS wraps the entire | |||
wraps the entire RADIUS packet payload into a TLS stream and thus | RADIUS packet payload into a TLS stream and thus mitigates the risk | |||
mitigates the risk of attacks on MD5. | 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 the control of 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 use of more contemporary | identify other peers and thus allow the use of more contemporary | |||
trust models, e.g. checking a certificate by inspecting the issuer | trust models, e.g., checking a certificate by inspecting the issuer | |||
and other certificate properties. | and other certificate properties. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
In this document, several words are used to signify the requirements | In this document, several words are used to signify the requirements | |||
of the specification. The key words "MUST", "MUST NOT", "REQUIRED", | of the specification. The key words "MUST", "MUST NOT", "REQUIRED", | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT | |||
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | |||
interpreted as described in RFC 2119. [RFC2119] | interpreted as described in RFC 2119 [RFC2119]. | |||
1.2. Terminology | 1.2. Terminology | |||
RADIUS/TLS node: a RADIUS over TLS client or server | RADIUS/TLS node: a RADIUS-over-TLS client or server | |||
RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new | RADIUS/TLS Client: a RADIUS-over-TLS instance that initiates a new | |||
connection. | connection. | |||
RADIUS/TLS Server: a RADIUS over TLS instance which listens on a | RADIUS/TLS Server: a RADIUS-over-TLS instance that listens on a | |||
RADIUS over TLS port and accepts new connections | RADIUS-over-TLS port and accepts new connections | |||
RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865] | RADIUS/UDP: a classic RADIUS transport over UDP as defined in | |||
[RFC2865] | ||||
1.3. Document Status | 1.3. Document Status | |||
This document is an Experimental RFC. | This document is an Experimental RFC. | |||
It is one out of several approaches to address known cryptographic | It is one out of several approaches to address known cryptographic | |||
weaknesses of the RADIUS protocol (see also Section 4). The | weaknesses of the RADIUS protocol (see also Section 4). The | |||
specification does not fulfill all recommendations on a AAA transport | specification does not fulfill all recommendations on a AAA transport | |||
profile as per [RFC3539]; in particular, by being based on TCP as a | profile as per [RFC3539]; in particular, by being based on TCP as a | |||
transport layer, it does not prevent head-of-line blocking issues. | transport layer, it does not prevent head-of-line blocking issues. | |||
If this specification is indeed selected for advancement to standards | If this specification is indeed selected for advancement to Standards | |||
track, certificate verification options (section 2.3.2) need to be | Track, certificate verification options (Section 2.3, point 2) need | |||
refined. | to be refined. | |||
Another experimental characteristic of this specification is the | Another experimental characteristic of this specification is the | |||
question of key management between RADIUS/TLS peers. RADIUS/UDP only | question of key management between RADIUS/TLS peers. RADIUS/UDP only | |||
allowed for manual key management, i.e. distribution of a shared | allowed for manual key management, i.e., distribution of a shared | |||
secret between a client and a server. RADIUS/TLS allows manual | secret between a client and a server. RADIUS/TLS allows manual | |||
distribution of long-term proofs of peer identity as well (by using | distribution of long-term proofs of peer identity as well (by using | |||
TLS-PSK cipher suites, or identifying clients by a certificate | TLS-PSK ciphersuites, or identifying clients by a certificate | |||
fingerprint), but as a new feature enables use of X.509 certificates | fingerprint), but as a new feature enables use of X.509 certificates | |||
in a PKIX infrastructure. It remains to be seen if one of these | in a PKIX infrastructure. It remains to be seen if one of these | |||
methods prevail, or if both will find their place in real-life | methods will prevail or if both will find their place in real-life | |||
deployments. The authors can imagine pre-shared keys to be popular | deployments. The authors can imagine pre-shared keys (PSK) to be | |||
in small-scale deployments (SOHO or isolated enterprise deployments) | popular in small-scale deployments (Small Office, Home Office (SOHO) | |||
where scalability is not an issue and the deployment of a CA is | or isolated enterprise deployments) where scalability is not an issue | |||
considered too much a hassle; but can also imagine large roaming | and the deployment of a Certification Authority (CA) is considered | |||
consortia to make use of PKIX. Readers of this specification are | too much of a hassle; however, the authors can also imagine large | |||
encouraged to read the discussion of key management issus within | roaming consortia to make use of PKIX. Readers of this specification | |||
are encouraged to read the discussion of key management issues within | ||||
[RFC6421] as well as [RFC4107]. | [RFC6421] as well as [RFC4107]. | |||
It has yet to be decided whether this approach is to be chosen for | It has yet to be decided whether this approach is to be chosen for | |||
standards track. One key aspect to judge whether the approach is | Standards Track. One key aspect to judge whether the approach is | |||
usable at large scale is by observing the uptake, usability and | usable on a large scale is by observing the uptake, usability, and | |||
operational behaviour of the protocol in large-scale, real-life | operational behavior of the protocol in large-scale, real-life | |||
deployments. | deployments. | |||
An example for a world-wide roaming environment that uses RADIUS over | An example for a worldwide roaming environment that uses RADIUS over | |||
TLS to secure communication is "eduroam", see [eduroam]. | TLS to secure communication is "eduroam", see [eduroam]. | |||
2. Normative: Transport Layer Security for RADIUS/TCP | 2. Normative: Transport Layer Security for RADIUS/TCP | |||
2.1. TCP port and packet types | 2.1. TCP port and Packet Types | |||
The default destination port number for RADIUS over TLS is TCP/2083. | The default destination port number for RADIUS over TLS is TCP/2083. | |||
There are no separate ports for authentication, accounting and | There are no separate ports for authentication, accounting, and | |||
dynamic authorisation changes. The source port is arbitrary. See | dynamic authorization changes. The source port is arbitrary. See | |||
section Section 3.4 for considerations regarding separation of | Section 3.4 for considerations regarding the separation of | |||
authentication, accounting and dynamic authorization traffic. | authentication, accounting, and dynamic authorization traffic. | |||
2.2. TLS negotiation | 2.2. TLS Negotiation | |||
RADIUS/TLS has no notion of negotiating TLS in an established | RADIUS/TLS has no notion of negotiating TLS in an established | |||
connection. Servers and clients need to be preconfigured to use | connection. Servers and clients need to be preconfigured to use | |||
RADIUS/TLS for a given endpoint. | RADIUS/TLS for a given endpoint. | |||
2.3. Connection Setup | 2.3. Connection Setup | |||
RADIUS/TLS nodes | RADIUS/TLS nodes | |||
1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. | 1. establish TCP connections as per [RFC6613]. Failure to connect | |||
Failure to connect leads to continuous retries, with | leads to continuous retries, with exponentially growing intervals | |||
exponentially growing intervals between every try. If multiple | between every try. If multiple servers are defined, the node MAY | |||
servers are defined, the node MAY attempt to establish a | attempt to establish a connection to these other servers in | |||
connection to these other servers in parallel, in order to | parallel, in order to implement quick failover. | |||
implement quick failover. | ||||
2. after completing the TCP handshake, immediately negotiate TLS | 2. after completing the TCP handshake, immediately negotiate TLS | |||
sessions according to [RFC5246] or its predecessor TLS 1.1. The | sessions according to [RFC5246] or its predecessor TLS 1.1. The | |||
following restrictions apply: | following restrictions apply: | |||
* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 | * Support for TLS v1.1 [RFC4346] or later (e.g., TLS 1.2 | |||
[RFC5246] ]) is REQUIRED. To prevent known attacks on TLS | [RFC5246]) is REQUIRED. To prevent known attacks on TLS | |||
versions prior to 1.1, implementations MUST NOT negotiate TLS | versions prior to 1.1, implementations MUST NOT negotiate TLS | |||
versions prior to 1.1. | versions prior to 1.1. | |||
* Support for certificate-based mutual authentication is | * Support for certificate-based mutual authentication is | |||
REQUIRED. | REQUIRED. | |||
* Negotiation of mutual authentication is REQUIRED. | * Negotiation of mutual authentication is REQUIRED. | |||
* Negotiation of a ciphersuite providing for confidentiality as | * Negotiation of a ciphersuite providing for confidentiality as | |||
well as integrity protection is REQUIRED. Failure to comply | well as integrity protection is REQUIRED. Failure to comply | |||
with this requirement can lead to severe security problmes, | with this requirement can lead to severe security problems, | |||
like user passwords being recoverable by third parties. See | like user passwords being recoverable by third parties. See | |||
Section 6 for details. | Section 6 for details. | |||
* Support for and negotiation of compression is OPTIONAL. | * Support for and negotiation of compression is OPTIONAL. | |||
* Support for TLS-PSK mutual authentication [RFC4279] is | * Support for TLS-PSK mutual authentication [RFC4279] is | |||
OPTIONAL. | OPTIONAL. | |||
* RADIUS/TLS implementations MUST at a minimum support | * RADIUS/TLS implementations MUST, at a minimum, support | |||
negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD | negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD | |||
support TLS_RSA_WITH_RC4_128_SHA and | support TLS_RSA_WITH_RC4_128_SHA and | |||
TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 ). | TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3. | |||
* In addition, RADIUS/TLS implementations MUST support | * In addition, RADIUS/TLS implementations MUST support | |||
negotiation of the mandatory-to-implement ciphersuites | negotiation of the mandatory-to-implement ciphersuites | |||
required by the versions of TLS that they support. | required by the versions of TLS that they support. | |||
3. Peer authentication can be performed in any of the following | 3. Peer authentication can be performed in any of the following | |||
three operation models: | three operation models: | |||
* TLS with X.509 certificates using PKIX trust models (this | * TLS with X.509 certificates using PKIX trust models (this | |||
model is mandatory to implement): | model is mandatory to implement): | |||
+ Implementations MUST allow to configure a list of trusted | + Implementations MUST allow the configuration of a list of | |||
Certification Authorities for incoming connections. | trusted Certification Authorities for incoming connections. | |||
+ Certificate validation MUST include the verification rules | + Certificate validation MUST include the verification rules | |||
as per [RFC5280]. | as per [RFC5280]. | |||
+ Implementations SHOULD indicate their trusted Certification | + Implementations SHOULD indicate their trusted Certification | |||
Authorities (CAs). For TLS 1.2, this is done using | Authorities (CAs). For TLS 1.2, this is done using | |||
[RFC5246] section 7.4.4 "certificate authorities" (server | [RFC5246], Section 7.4.4, "certificate_authorities" (server | |||
side) and [RFC6066] Section 6 "Trusted CA Indication" | side) and [RFC6066], Section 6 "Trusted CA Indication" | |||
(client side). See also Section 3.2. | (client side). See also Section 3.2. | |||
+ Peer validation always includes a check on whether the | + Peer validation always includes a check on whether the | |||
locally configured expected DNS name or IP address of the | locally configured expected DNS name or IP address of the | |||
server that is contacted matches its presented certificate. | server that is contacted matches its presented certificate. | |||
DNS names and IP addresses can be contained in the Common | DNS names and IP addresses can be contained in the Common | |||
Name (CN) or subjectAltName entries. For verification, | Name (CN) or subjectAltName entries. For verification, | |||
only one of these entries is to be considered. The | only one of 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 | |||
skipping to change at page 6, line 47 | skipping to change at page 7, line 4 | |||
+ Peer validation always includes a check on whether the | + Peer validation always includes a check on whether the | |||
locally configured expected DNS name or IP address of the | locally configured expected DNS name or IP address of the | |||
server that is contacted matches its presented certificate. | server that is contacted matches its presented certificate. | |||
DNS names and IP addresses can be contained in the Common | DNS names and IP addresses can be contained in the Common | |||
Name (CN) or subjectAltName entries. For verification, | Name (CN) or subjectAltName entries. For verification, | |||
only one of these entries is to be considered. The | only one of 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. | |||
Implementors of this specification are advised to read | Implementors of this specification are advised to read | |||
[RFC6125] Section 6 for more details on DNS name | [RFC6125], Section 6, for more details on DNS name | |||
validation. | validation. | |||
+ Implementations MAY allow to configure a set of additional | + Implementations MAY allow the configuration of a set of | |||
properties of the certificate to check for a peer's | additional properties of the certificate to check for a | |||
authorisation to communicate (e.g. a set of allowed values | peer's authorization to communicate (e.g., a set of allowed | |||
in subjectAltName:URI or a set of allowed X509v3 | values in subjectAltName:URI or a set of allowed X509v3 | |||
Certificate Policies) | Certificate Policies). | |||
+ When the configured trust base changes (e.g. removal of a | + When the configured trust base changes (e.g., removal of a | |||
CA from the list of trusted CAs; issuance of a new CRL for | CA from the list of trusted CAs; issuance of a new CRL for | |||
a given CA) implementations MAY re-negotiate the TLS | a given CA), implementations MAY renegotiate the TLS | |||
session to re-assess the connecting peer's continued | session to reassess the connecting peer's continued | |||
authorisation. | authorization. | |||
* TLS with X.509 certificates using certificate fingerprints | * TLS with X.509 certificates using certificate fingerprints | |||
(this model is optional to implement): Implementations SHOULD | (this model is optional to implement): Implementations SHOULD | |||
allow to configure a list of trusted certificates, identified | allow the configuration of a list of trusted certificates, | |||
via fingerprint of the DER encoded certificate octets. | identified via fingerprint of the DER encoded certificate | |||
Implementations MUST support SHA-1 as the hash algorithm for | octets. Implementations MUST support SHA-1 as the hash | |||
the fingerprint. To prevent attacks based on hash collisions, | algorithm for the fingerprint. To prevent attacks based on | |||
support for a more contemporary hash function such as SHA-256 | hash collisions, support for a more contemporary hash function | |||
is RECOMMENDED. | such as SHA-256 is RECOMMENDED. | |||
* TLS using TLS-PSK (this model is optional to implement) | * TLS using TLS-PSK (this model is optional to implement). | |||
4. start exchanging RADIUS datagrams (note Section 3.4 (1) ). The | 4. start exchanging RADIUS datagrams (note Section 3.4 (1)). The | |||
shared secret to compute the (obsolete) MD5 integrity checks and | shared secret to compute the (obsolete) MD5 integrity checks and | |||
attribute encryption MUST be "radsec" (see Section 3.4 (2) ). | attribute encryption MUST be "radsec" (see Section 3.4 (2)). | |||
2.4. Connecting Client Identity | 2.4. Connecting Client Identity | |||
In RADIUS/UDP, clients are uniquely identified by their IP address. | In RADIUS/UDP, clients are uniquely identified by their IP address. | |||
Since the shared secret is associated with the origin IP address, if | Since the shared secret is associated with the origin IP address, if | |||
more than one RADIUS client is associated with the same IP address, | more than one RADIUS client is associated with the same IP address, | |||
then those clients also must utilize the same shared secret, a | then those clients also must utilize the same shared secret, a | |||
practice which is inherently insecure as noted in [RFC5247]. | practice that is inherently insecure, as noted in [RFC5247]. | |||
RADIUS/TLS supports multiple operation modes. | RADIUS/TLS supports multiple operation modes. | |||
In TLS-PSK operation, a client is uniquely identified by its TLS | In TLS-PSK operation, a client is uniquely identified by its TLS | |||
identifier. | identifier. | |||
In TLS-X.509 mode using fingerprints, a client is uniquely identified | In TLS-X.509 mode using fingerprints, a client is uniquely identified | |||
by the fingerprint of the presented client certificate. | by the fingerprint of the presented client certificate. | |||
In TLS-X.509 mode using PKIX trust models, a client is uniquely | In TLS-X.509 mode using PKIX trust models, a client is uniquely | |||
identified by the tuple (serial number of presented client | identified by the tuple (serial number of presented client | |||
certificate;Issuer). | certificate;Issuer). | |||
Note well: having identified a connecting entity does not mean the | Note well: having identified a connecting entity does not mean the | |||
server necessarily wants to communicate with that client. E.g. if | server necessarily wants to communicate with that client. For | |||
the Issuer is not in a trusted set of Issuers, the server may decline | example, if the Issuer is not in a trusted set of Issuers, the server | |||
to perform RADIUS transactions with this client. | may decline to perform RADIUS transactions with this client. | |||
There are numerous trust models in PKIX environments, and it is | There are numerous trust models in PKIX environments, and it is | |||
beyond the scope of this document to define how a particular | beyond the scope of this document to define how a particular | |||
deployment determines whether a client is trustworthy. | deployment determines whether a client is trustworthy. | |||
Implementations which want to support a wide variety of trust models | Implementations that want to support a wide variety of trust models | |||
should expose as many details of the presented certificate to the | should expose as many details of the presented certificate to the | |||
administrator as possible so that the trust model can be implemented | administrator as possible so that the trust model can be implemented | |||
by the administrator. As a suggestion, at least the following | by the administrator. As a suggestion, at least the following | |||
parameters of the X.509 client certificate should be exposed: | parameters of the X.509 client certificate should be exposed: | |||
o Originating IP address | o Originating IP address | |||
o Certificate Fingerprint | o Certificate Fingerprint | |||
o Issuer | o Issuer | |||
skipping to change at page 8, line 40 | skipping to change at page 8, line 46 | |||
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.5. RADIUS Datagrams | 2.5. RADIUS Datagrams | |||
Authentication, Accounting and Authorization packets are sent | Authentication, Authorization, and Accounting packets are sent | |||
according to the following rules: | according to the following rules: | |||
RADIUS/TLS clients transmit the same packet types on the connection | RADIUS/TLS clients transmit the same packet types on the connection | |||
they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and | they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and | |||
(4) ). E.g. they send | (4)). For example, they send | |||
o Access-Request | o Access-Request | |||
o Accounting-Request | o Accounting-Request | |||
o Status-Server | o Status-Server | |||
o Disconnect-ACK | o Disconnect-ACK | |||
o Disconnect-NAK | o Disconnect-NAK | |||
o ... | o ... | |||
and they receive | and they receive | |||
skipping to change at page 9, line 23 | skipping to change at page 9, line 27 | |||
o Access-Accept | o Access-Accept | |||
o Accounting-Response | o Accounting-Response | |||
o Disconnect-Request | o Disconnect-Request | |||
o ... | o ... | |||
RADIUS/TLS servers transmit the same packet types on connections they | RADIUS/TLS servers transmit the same packet types on connections they | |||
have accepted as a RADIUS/UDP server would. E.g. they send | have accepted as a RADIUS/UDP server would. For example, they send | |||
o Access-Challenge | o Access-Challenge | |||
o Access-Accept | o Access-Accept | |||
o Access-Reject | o Access-Reject | |||
o Accounting-Response | o Accounting-Response | |||
o Disconnect-Request | o Disconnect-Request | |||
skipping to change at page 9, line 50 | skipping to change at page 10, line 6 | |||
o Accounting-Request | o Accounting-Request | |||
o Status-Server | o Status-Server | |||
o Disconnect-ACK | o Disconnect-ACK | |||
o ... | o ... | |||
Due to the use of one single TCP port for all packet types, it is | Due to the use of one single TCP port for all packet types, it is | |||
required for a RADIUS/TLS server to signal to a connecting peer which | required that a RADIUS/TLS server signal which types of packets are | |||
types of packets are supported on a server. See also section | supported on a server to a connecting peer. See also Section 3.4 for | |||
Section 3.4 for a discussion of signaling. | a discussion of signaling. | |||
o When receiving an unwanted packet of type 'CoA-Request' or | o When an unwanted packet of type 'CoA-Request' or 'Disconnect- | |||
'Disconnect-Request', it needs to be replied to with a 'CoA-NAK' | Request' is received, a RADIUS/TLS server needs to respond with a | |||
or 'Disconnect-NAK' respectively. The NAK SHOULD contain an | 'CoA-NAK' or 'Disconnect-NAK', respectively. The NAK SHOULD | |||
attribute Error-Cause with the value 406 ("Unsupported | contain an attribute Error-Cause with the value 406 ("Unsupported | |||
Extension"); see [RFC5176] for details. | Extension"); see [RFC5176] for details. | |||
o When receiving an unwanted packet of type 'Accounting-Request', | o When an unwanted packet of type 'Accounting-Request' is received, | |||
the RADIUS/TLS server SHOULD reply with an Accounting-Response | the RADIUS/TLS server SHOULD reply with an Accounting-Response | |||
containing an Error-Cause attribute with value 406 "Unsupported | containing an Error-Cause attribute with value 406 "Unsupported | |||
Extension" as defined in [RFC5176]. A RADIUS/TLS accounting | Extension" as defined in [RFC5176]. A RADIUS/TLS accounting | |||
client receiving such an Accounting-Response SHOULD log the error | client receiving such an Accounting-Response SHOULD log the error | |||
and stop sending Accounting-Request packets. | and stop sending Accounting-Request packets. | |||
3. Informative: Design Decisions | 3. Informative: Design Decisions | |||
This section explains the design decisions that led to the rules | This section explains the design decisions that led to the rules | |||
defined in the previous section. | defined in the previous section. | |||
3.1. Implications of Dynamic Peer Discovery | 3.1. Implications of Dynamic Peer Discovery | |||
One mechanism to discover RADIUS over TLS peers dynamically via DNS | One mechanism to discover RADIUS-over-TLS peers dynamically via DNS | |||
is specified in [I-D.ietf-radext-dynamic-discovery]. While this | is specified in [DYNAMIC]. While this mechanism is still under | |||
mechanism is still under development and therefore is not a normative | development and therefore is not a normative dependency of RADIUS/ | |||
dependency of RADIUS/TLS, the use of dynamic discovery has potential | TLS, the use of dynamic discovery has potential future implications | |||
future implications that are important to understand. | that are important to understand. | |||
Readers of this document who are considering the deployment of DNS- | Readers of this document who are considering the deployment of DNS- | |||
based dynamic discovery are thus encouraged to read | based dynamic discovery are thus encouraged to read [DYNAMIC] and | |||
[I-D.ietf-radext-dynamic-discovery] and follow its future | follow its future development. | |||
development. | ||||
3.2. X.509 Certificate Considerations | 3.2. X.509 Certificate Considerations | |||
(1) If a RADIUS/TLS client is in possession of multiple certificates | (1) If a RADIUS/TLS client is in possession of multiple certificates | |||
from different CAs (i.e. is part of multiple roaming consortia) and | from different CAs (i.e., is part of multiple roaming consortia) | |||
dynamic discovery is used, the discovery mechanism possibly does not | and dynamic discovery is used, the discovery mechanism possibly | |||
yield sufficient information to identify the consortium uniquely | does not yield sufficient information to identify the consortium | |||
(e.g. DNS discovery). Subsequently, the client may not know by | uniquely (e.g., DNS discovery). Subsequently, the client may | |||
itself which client certificate to use for the TLS handshake. Then | not know by itself which client certificate to use for the TLS | |||
it is necessary for the server to signal which consortium it belongs | handshake. Then, it is necessary for the server to signal to | |||
to, and which certificates it expects. If there is no risk of | which consortium it belongs and which certificates it expects. | |||
confusing multiple roaming consortia, providing this information in | If there is no risk of confusing multiple roaming consortia, | |||
the handshake is not crucial. | providing this information in the handshake is not crucial. | |||
(2) If a RADIUS/TLS server is in possession of multiple certificates | (2) If a RADIUS/TLS server is in possession of multiple certificates | |||
from different CAs (i.e. is part of multiple roaming consortia), it | from different CAs (i.e., is part of multiple roaming | |||
will need to select one of its certificates to present to the RADIUS/ | consortia), it will need to select one of its certificates to | |||
TLS client. If the client sends the Trusted CA Indication, this hint | present to the RADIUS/TLS client. If the client sends the | |||
can make the server select the appropriate certificate and prevent a | Trusted CA Indication, this hint can make the server select the | |||
handshake failure. Omitting this indication makes it impossible to | appropriate certificate and prevent a handshake failure. | |||
deterministically select the right certificate in this case. If | Omitting this indication makes it impossible to | |||
there is no risk of confusing multiple roaming consortia, providing | deterministically select the right certificate in this case. If | |||
this indication in the handshake is not crucial. | there is no risk of confusing multiple roaming consortia, | |||
providing this indication in the handshake is not crucial. | ||||
3.3. Ciphersuites and Compression Negotiation Considerations | 3.3. Ciphersuites and Compression Negotiation Considerations | |||
Not all TLS ciphersuites in [RFC5246] are supported by available TLS | Not all TLS ciphersuites in [RFC5246] are supported by available TLS | |||
tool kits, and licenses may be required in some cases. The existing | tool kits, and licenses may be required in some cases. The existing | |||
implementations of RADIUS/TLS use OpenSSL as cryptographic backend, | implementations of RADIUS/TLS use OpenSSL as a cryptographic backend, | |||
which supports all of the ciphersuites listed in the rules in the | which supports all of the ciphersuites listed in the rules in the | |||
normative section. | normative section. | |||
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- | The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory to | |||
implement according to [RFC4346] and thus has to be supported by | implement according to [RFC4346]; thus, it has to be supported by | |||
RADIUS/TLS nodes. | RADIUS/TLS nodes. | |||
The two other ciphersuites in the normative section are widely | The two other ciphersuites in the normative section are widely | |||
implemented in TLS toolkits and are considered good practice to | implemented in TLS tool kits and are considered good practice to | |||
implement. | implement. | |||
3.4. RADIUS Datagram Considerations | 3.4. RADIUS Datagram Considerations | |||
(1) After the TLS session is established, RADIUS packet payloads are | (1) After the TLS session is established, RADIUS packet payloads are | |||
exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet | exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the | |||
size can be determined by evaluating the size of the datagram that | packet size can be determined by evaluating the size of the | |||
arrived. Due to the stream nature of TCP and TLS, this does not hold | datagram that arrived. Due to the stream nature of TCP and TLS, | |||
true for RADIUS/TLS packet exchange. Instead, packet boundaries of | this does not hold true for RADIUS/TLS packet exchange. | |||
RADIUS packets that arrive in the stream are calculated by evaluating | Instead, packet boundaries of RADIUS packets that arrive in the | |||
the packet's Length field. Special care needs to be taken on the | stream are calculated by evaluating the packet's Length field. | |||
packet sender side that the value of the Length field is indeed | Special care needs to be taken on the packet sender side that | |||
correct before sending it over the TLS tunnel, because incorrect | the value of the Length field is indeed correct before sending | |||
packet lengths can no longer be detected by a differing datagram | it over the TLS tunnel, because incorrect packet lengths can no | |||
boundary. See section 2.6.4 of [I-D.ietf-radext-tcp-transport] for | longer be detected by a differing datagram boundary. See | |||
more details. | Section 2.6.4 of [RFC6613] for more details. | |||
(2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding | (2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding | |||
of attributes such as User-Password, as well as in computation 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 | |||
integrity protection and encryption sufficient to substitute for | provides integrity protection and encryption sufficient to | |||
RADIUS application-layer security, it is not necessary to configure a | substitute for RADIUS application-layer security, it is not | |||
RADIUS shared secret. The use of a fixed string for the obsolete | necessary to configure a RADIUS shared secret. The use of a | |||
shared secret eliminates possible node misconfigurations. | fixed string for the obsolete shared secret eliminates possible | |||
node misconfigurations. | ||||
(3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, | (3) RADIUS/UDP [RFC2865] uses different UDP ports for | |||
accounting and dynamic authorisation changes. RADIUS/TLS allocates a | authentication, accounting, and dynamic authorization changes. | |||
single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS | RADIUS/TLS allocates a single port for all RADIUS packet types. | |||
the notion of a client which sends authentication requests and | Nevertheless, in RADIUS/TLS, the notion of a client that sends | |||
processes replies associated with it's users' sessions and the notion | authentication requests and processes replies associated with | |||
of a server which receives requests, processes them and sends the | its users' sessions and the notion of a server that receives | |||
appropriate replies is to be preserved. The normative rules about | requests, processes them, and sends the appropriate replies is | |||
acceptable packet types for clients and servers mirror the packet | to be preserved. The normative rules about acceptable packet | |||
flow behaviour from RADIUS/UDP. | types for clients and servers mirror the packet flow behavior | |||
from RADIUS/UDP. | ||||
(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | |||
allocated UDP port to signal that a peer RADIUS server does not | allocated UDP port to signal that a peer RADIUS server does not | |||
support reception and processing of the packet types in [RFC5176]. | support the reception and processing of the packet types in | |||
These packet types are listed as to be received in RADIUS/TLS | [RFC5176]. These packet types are listed as to be received in | |||
implementations. Note well: it is not required for an implementation | RADIUS/TLS implementations. Note well: it is not required for | |||
to actually process these packet types; it is only required to send | an implementation to actually process these packet types; it is | |||
the NAK as defined above. | only required that the NAK be sent as defined above. | |||
(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly | |||
allocated UDP port to signal that a peer RADIUS server does not | allocated UDP port to signal that a peer RADIUS server does not | |||
support reception and processing of RADIUS Accounting packets. There | support the reception and processing of RADIUS Accounting | |||
is no RADIUS datagram to signal an Accounting NAK. Clients may be | packets. There is no RADIUS datagram to signal an Accounting | |||
misconfigured to send Accounting packets to a RADIUS/TLS server which | NAK. Clients may be misconfigured for sending Accounting | |||
does not wish to process their Accounting packet. To prevent a | packets to a RADIUS/TLS server that does not wish to process | |||
regression of detectability of this situation, the Accounting- | their Accounting packet. To prevent a regression of | |||
Response + Error-Cause sgnaling was introduced. | detectability of this situation, the Accounting-Response + | |||
Error-Cause signaling was introduced. | ||||
4. Compatibility with other RADIUS transports | 4. Compatibility with Other RADIUS Transports | |||
Ongoing work in the IETF defines multiple alternative transports to | The IETF defines multiple alternative transports to the classic UDP | |||
the classic UDP transport model as defined in [RFC2865], namely | transport model as defined in [RFC2865], namely RADIUS over TCP | |||
RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over Datagram | [RFC6613] and the present document on RADIUS over TLS. The IETF also | |||
Transport Layer Security (DTLS) [I-D.ietf-radext-dtls] and this | proposed RADIUS over Datagram Transport Layer Security (DTLS) | |||
present document on RADIUS over TLS. | [RADEXT-DTLS]. | |||
RADIUS/TLS does not specify any inherent backwards compatibility to | RADIUS/TLS does not specify any inherent backward compatibility to | |||
RADIUS/UDP or cross compatibility to the other transports, i.e. an | RADIUS/UDP or cross compatibility to the other transports, i.e., an | |||
implementation which implements RADIUS/TLS only will not be able to | implementation that utilizes RADIUS/TLS only will not be able to | |||
receive or send RADIUS packet payloads over other transports. An | receive or send RADIUS packet payloads over other transports. An | |||
implementation wishing to be backward or cross compatible (i.e. | implementation wishing to be backward or cross compatible (i.e., | |||
wishes to serve clients using other transports than RADIUS/TLS) will | wishes to serve clients using other transports than RADIUS/TLS) will | |||
need to implement these other transports along with the RADIUS/TLS | need to implement these other transports along with the RADIUS/TLS | |||
transport and be prepared to send and receive on all implemented | transport and be prepared to send and receive on all implemented | |||
transports, which is called a multi-stack implementation. | transports, which is called a "multi-stack implementation". | |||
If a given IP device is able to receive RADIUS payloads on multiple | 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 | 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 | 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 | that both ports are interchangeable. In particular, it cannot be | |||
assumed that state is maintained for the packet payloads between the | assumed that state is maintained for the packet payloads between the | |||
transports. Two such instances MUST be considered separate RADIUS | transports. Two such instances MUST be considered separate RADIUS | |||
server entities. | server entities. | |||
5. Diameter Compatibility | 5. Diameter Compatibility | |||
Since RADIUS/TLS is only a new transport profile for RADIUS, | Since RADIUS/TLS is only a new transport profile for RADIUS, the | |||
compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP | compatibility of RADIUS/TLS - Diameter [RFC3588] and RADIUS/UDP | |||
[RFC2865] - Diameter [RFC3588] is identical. The considerations | [RFC2865] - Diameter [RFC3588] is identical. The considerations | |||
regarding payload size in [I-D.ietf-radext-tcp-transport] apply. | regarding payload size in [RFC6613] apply. | |||
6. Security Considerations | 6. Security Considerations | |||
The computational resources to establish a TLS tunnel are | The computational resources to establish a TLS tunnel are | |||
significantly higher than simply sending mostly unencrypted UDP | significantly higher than simply sending mostly unencrypted UDP | |||
datagrams. Therefore, clients connecting to a RADIUS/TLS node will | datagrams. Therefore, clients connecting to a RADIUS/TLS node will | |||
more easily create high load conditions and a malicious client might | more easily create high load conditions and a malicious client might | |||
create a Denial-of-Service attack more easily. | create a Denial-of-Service attack more easily. | |||
Some TLS ciphersuites only provide integrity validation of their | Some TLS ciphersuites only provide integrity validation of their | |||
payload, and provide no encryption. This specification forbids the | payload, and provide no encryption. This specification forbids the | |||
use of such ciphersuites. Since the RADIUS payload's shared secret | use of such ciphersuites. Since the RADIUS payload's shared secret | |||
is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , | is fixed to the well-known term "radsec" (see Section 2.3 (4)), | |||
failure to comply with this requirement will expose the entire | failure to comply with this requirement will expose the entire | |||
datagram payload in plain text, including User-Password, to | datagram payload in plaintext, including User-Password, to | |||
intermediate IP nodes. | intermediate IP nodes. | |||
By virtue of being based on TCP, there are several generic attack | By virtue of being based on TCP, there are several generic attack | |||
vectors to slow down or prevent the TCP connection from being | vectors to slow down or prevent the TCP connection from being | |||
established; see [RFC4953] for details. If a TCP connection is not | established; see [RFC4953] for details. If a TCP connection is not | |||
up when a packet is to be processed, it gets re-established, so such | up when a packet is to be processed, it gets re-established, so such | |||
attacks in general lead only to a minor performance degradation (the | attacks in general lead only to a minor performance degradation (the | |||
time it takes to re-establish the connection). There is one notable | time it takes to re-establish the connection). There is one notable | |||
exception where an attacker might create a bidding-down attack | exception where an attacker might create a bidding-down attack | |||
though: If peer communication between two devices is configured for | though. If peer communication between two devices is configured for | |||
both RADIUS/TLS (i.e TLS security over TCP as a transport, shared | both RADIUS/TLS (i.e., TLS security over TCP as a transport, shared | |||
secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security | secret fixed to "radsec") and RADIUS/UDP (i.e., shared secret | |||
with a secret manually configured by the administrator), and where | security with a secret manually configured by the administrator), and | |||
the RADIUS/UDP transport is the failover option if the TLS session | the RADIUS/UDP transport is the failover option if the TLS session | |||
cannot be established, a bidding-down attack can occur if an | cannot be established, a bidding-down attack can occur if an | |||
adversary can maliciously close the TCP connection, or prevent it | adversary can maliciously close the TCP connection or prevent it from | |||
from being established. Situations where clients are configured in | being established. Situations where clients are configured in such a | |||
such a way are likely to occur during a migration phase from RADIUS/ | way are likely to occur during a migration phase from RADIUS/UDP to | |||
UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker | RADIUS/TLS. By preventing the TLS session setup, the attacker can | |||
can reduce the security of the packet payload from the selected TLS | reduce the security of the packet payload from the selected TLS | |||
cipher suite packet encryption to the classic MD5 per-attribute | ciphersuite packet encryption to the classic MD5 per-attribute | |||
encryption. The situation should be avoided by disabling the weaker | encryption. The situation should be avoided by disabling the weaker | |||
RADIUS/UDP transport as soon as the new RADIUS/TLS connection is | RADIUS/UDP transport as soon as the new RADIUS/TLS connection is | |||
established and tested. Disabling can happen at either the RADIUS | established and tested. Disabling can happen at either the RADIUS | |||
client or server side: | client or server side: | |||
o Client side: de-configure the failover setup, leaving RADIUS/TLS | o Client side: de-configure the failover setup, leaving RADIUS/TLS | |||
as the only communication option | as the only communication option | |||
o Server side: de-configure the RADIUS/UDP client from the list of | o Server side: de-configure the RADIUS/UDP client from the list of | |||
valid RADIUS clients | valid RADIUS clients | |||
RADIUS/TLS provides authentication and encryption between RADIUS | RADIUS/TLS provides authentication and encryption between RADIUS | |||
peers. In the presence of proxies, the intermediate proxies can | peers. In the presence of proxies, the intermediate proxies can | |||
still inspect the individual RADIUS packets, i.e. "end-to-end" | still inspect the individual RADIUS packets, i.e., "end-to-end" | |||
encryption is not provided. Where intermediate proxies are | encryption is not provided. Where intermediate proxies are | |||
untrusted, it is desirable to use other RADIUS mechanisms to prevent | untrusted, it is desirable to use other RADIUS mechanisms to prevent | |||
RADIUS packet payload from inspection by such proxies. One common | RADIUS packet payload from inspection by such proxies. One common | |||
method to protect passwords is the use of the Extensible | method to protect passwords is the use of the Extensible | |||
Authentication Protocol (EAP) and EAP methods which utilize TLS. | Authentication Protocol (EAP) and EAP methods that utilize TLS. | |||
When using certificate fingerprints to identify RADIUS/TLS peers, any | When using certificate fingerprints to identify RADIUS/TLS peers, any | |||
two certificates which produce the same hash value (i.e. which have a | two certificates that produce the same hash value (i.e., that have a | |||
hash collision) will be considered the same client. It is therefore | hash collision) will be considered the same client. Therefore, it is | |||
important to make sure that the hash function used is | important to make sure that the hash function used is | |||
cryptographically uncompromised so that an attacker is very unlikely | cryptographically uncompromised so that an attacker is very unlikely | |||
to be able to produce a hash collision with a certificate of his | to be able to produce a hash collision with a certificate of his | |||
choice. While this specification mandates support for SHA-1, a later | choice. While this specification mandates support for SHA-1, a later | |||
revision will likely demand support for more contemporary hash | revision will likely demand support for more contemporary hash | |||
functions because as of issuance of this document there are already | functions because as of issuance of this document, there are already | |||
attacks on SHA-1. | attacks on SHA-1. | |||
7. IANA Considerations | 7. IANA Considerations | |||
No new RADIUS attributes or packet codes are defined. IANA is | No new RADIUS attributes or packet codes are defined. IANA has | |||
requested to update the already-assigned TCP port number 2083 in the | updated the already assigned TCP port number 2083 to reflect the | |||
following ways: | following: | |||
o Reference: list the RFC number of this document as the reference | ||||
o Assignment Notes: add the text "The TCP port 2083 was already | ||||
previously assigned by IANA for "RadSec", an early implementation | ||||
of RADIUS/TLS, prior to issuance of this RFC. This early | ||||
implementation can be configured to be compatible to RADIUS/TLS as | ||||
specified by the IETF. See RFC (RFC number of this document), | ||||
Appendix A for details." | ||||
8. Notes to the RFC Editor | ||||
[I-D.ietf-radext-tcp-transport] is currently in the publication queue | ||||
because it has a normative reference on this draft; it has no other | ||||
blocking dependencies. The two drafts should be published as an RFC | ||||
simultaneously, ideally with consequtive numbers. The references in | ||||
this draft to [I-D.ietf-radext-tcp-transport] should be changed to | ||||
references to the corresponding RFC prior to publication. | ||||
This section, "Notes to the RFC Editor" should be deleted from the | o Reference: [RFC6614] | |||
draft prior to publication. | o Assignment Notes: The TCP port 2083 was already previously | |||
assigned by IANA for "RadSec", an early implementation of RADIUS/ | ||||
TLS, prior to issuance of this RFC. This early implementation can | ||||
be configured to be compatible to RADIUS/TLS as specified by the | ||||
IETF. See RFC 6614, Appendix A for details. | ||||
9. Acknowledgements | 8. Acknowledgements | |||
RADIUS/TLS was first implemented as "RADSec" by Open Systems | RADIUS/TLS was first implemented as "RADSec" by Open Systems | |||
Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS | Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS | |||
server product (see [radsec-whitepaper]). | server product (see [radsec-whitepaper]). | |||
Funding and input for the development of this Internet Draft was | Funding and input for the development of this document was provided | |||
provided by the European Commission co-funded project "GEANT2" | by the European Commission co-funded project "GEANT2" [geant2] and | |||
[geant2] and further feedback was provided by the TERENA Task Force | further feedback was provided by the TERENA Task Force on Mobility | |||
Mobility [terena]. | and Network Middleware [terena]. | |||
10. References | 9. References | |||
10.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
in RFCs to Indicate Requirement | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
Levels", BCP 14, RFC 2119, | ||||
March 1997. | ||||
[RFC2865] Rigney, C., Willens, S., Rubens, | [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, | |||
A., and W. Simpson, "Remote | "Remote Authentication Dial In User Service (RADIUS)", | |||
Authentication Dial In User | RFC 2865, June 2000. | |||
Service (RADIUS)", RFC 2865, | ||||
June 2000. | ||||
[RFC2866] Rigney, C., "RADIUS Accounting", | [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. | |||
RFC 2866, June 2000. | ||||
[RFC4279] Eronen, P. and H. Tschofenig, | [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites | |||
"Pre-Shared Key Ciphersuites for | for Transport Layer Security (TLS)", RFC 4279, | |||
Transport Layer Security (TLS)", | December 2005. | |||
RFC 4279, December 2005. | ||||
[RFC5280] Cooper, D., Santesson, S., | [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. | |||
Farrell, S., Boeyen, S., | Aboba, "Dynamic Authorization Extensions to Remote | |||
Housley, R., and W. Polk, | Authentication Dial In User Service (RADIUS)", RFC 5176, | |||
"Internet X.509 Public Key | January 2008. | |||
Infrastructure Certificate and | ||||
Certificate Revocation List | ||||
(CRL) Profile", RFC 5280, | ||||
May 2008. | ||||
[RFC5176] Chiba, M., Dommety, G., Eklund, | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
M., Mitton, D., and B. Aboba, | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
"Dynamic Authorization | ||||
Extensions to Remote | ||||
Authentication Dial In User | ||||
Service (RADIUS)", RFC 5176, | ||||
January 2008. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The | [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible | |||
Transport Layer Security (TLS) | Authentication Protocol (EAP) Key Management Framework", | |||
Protocol Version 1.2", RFC 5246, | RFC 5247, August 2008. | |||
August 2008. | ||||
[RFC5247] Aboba, B., Simon, D., and P. | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
Eronen, "Extensible | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
Authentication Protocol (EAP) | Infrastructure Certificate and Certificate Revocation List | |||
Key Management Framework", | (CRL) Profile", RFC 5280, May 2008. | |||
RFC 5247, August 2008. | ||||
[RFC6066] Eastlake, D., "Transport Layer | [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: | |||
Security (TLS) Extensions: | Extension Definitions", RFC 6066, January 2011. | |||
Extension Definitions", | ||||
RFC 6066, January 2011. | ||||
[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr | [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. | |||
aft-ietf-radext-tcp-transport-09 | ||||
(work in progress), | ||||
October 2010. | ||||
10.2. Informative References | 9.2. Informative References | |||
[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport | [DYNAMIC] Winter, S. and M. McCauley, "NAI-based Dynamic Peer | |||
Layer for RADIUS", | Discovery for RADIUS/TLS and RADIUS/DTLS", Work | |||
draft-ietf-radext-dtls-01 (work | in Progress, July 2011. | |||
in progress), October 2010. | ||||
[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley, | [MD5-attacks] | |||
"NAI-based Dynamic Peer | Black, J., Cochran, M., and T. Highland, "A Study of the | |||
Discovery for RADIUS/TLS and | MD5 Attacks: Insights and Improvements", October 2006, | |||
RADIUS/DTLS", draft-ietf-radext- | <http://www.springerlink.com/content/40867l85727r7084/>. | |||
dynamic-discovery-03 (work in | ||||
progress), July 2011. | ||||
[RFC3539] Aboba, B. and J. Wood, | [RADEXT-DTLS] | |||
"Authentication, Authorization | DeKok, A., "DTLS as a Transport Layer for RADIUS", Work | |||
and Accounting (AAA) Transport | in Progress, October 2010. | |||
Profile", RFC 3539, June 2003. | ||||
[RFC3588] Calhoun, P., Loughney, J., | [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and | |||
Guttman, E., Zorn, G., and J. | Accounting (AAA) Transport Profile", RFC 3539, June 2003. | |||
Arkko, "Diameter Base Protocol", | ||||
RFC 3588, September 2003. | ||||
[RFC4107] Bellovin, S. and R. Housley, | [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. | |||
"Guidelines for Cryptographic | Arkko, "Diameter Base Protocol", RFC 3588, September 2003. | |||
Key Management", BCP 107, | ||||
RFC 4107, June 2005. | ||||
[RFC4346] Dierks, T. and E. Rescorla, "The | [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic | |||
Transport Layer Security (TLS) | Key Management", BCP 107, RFC 4107, June 2005. | |||
Protocol Version 1.1", RFC 4346, | ||||
April 2006. | ||||
[RFC4953] Touch, J., "Defending TCP | [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
Against Spoofing Attacks", | (TLS) Protocol Version 1.1", RFC 4346, April 2006. | |||
RFC 4953, July 2007. | ||||
[RFC6125] Saint-Andre, P. and J. Hodges, | [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", | |||
"Representation and Verification | RFC 4953, July 2007. | |||
of Domain-Based Application | ||||
Service Identity within Internet | ||||
Public Key Infrastructure Using | ||||
X.509 (PKIX) Certificates in the | ||||
Context of Transport Layer | ||||
Security (TLS)", RFC 6125, | ||||
March 2011. | ||||
[RFC6421] Nelson, D., "Crypto-Agility | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
Requirements for Remote | Verification of Domain-Based Application Service Identity | |||
Authentication Dial-In User | within Internet Public Key Infrastructure Using X.509 | |||
Service (RADIUS)", RFC 6421, | (PKIX) Certificates in the Context of Transport Layer | |||
November 2011. | Security (TLS)", RFC 6125, March 2011. | |||
[radsec-whitepaper] Open System Consultants, "RadSec | [RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote | |||
- a secure, reliable RADIUS | Authentication Dial-In User Service (RADIUS)", RFC 6421, | |||
Protocol", May 2005, <http:// | November 2011. | |||
www.open.com.au/radiator/ | ||||
radsec-whitepaper.pdf>. | ||||
[MD5-attacks] Black, J., Cochran, M., and T. | [eduroam] Trans-European Research and Education Networking | |||
Highland, "A Study of the MD5 | Association, "eduroam Homepage", 2007, | |||
Attacks: Insights and | <http://www.eduroam.org/>. | |||
Improvements", October 2006, <ht | ||||
tp://www.springerlink.com/ | ||||
content/40867l85727r7084/>. | ||||
[radsecproxy-impl] Venaas, S., "radsecproxy Project | [geant2] Delivery of Advanced Network Technology to Europe, | |||
Homepage", 2007, <http:// | "European Commission Information Society and Media: | |||
software.uninett.no/ | GEANT2", 2008, <http://www.geant2.net/>. | |||
radsecproxy/>. | ||||
[eduroam] Trans-European Research and | [radsec-whitepaper] | |||
Education Networking | Open System Consultants, "RadSec - a secure, reliable | |||
Association, "eduroam Homepage", | RADIUS Protocol", May 2005, | |||
2007, <http://www.eduroam.org/>. | <http://www.open.com.au/radiator/radsec-whitepaper.pdf>. | |||
[geant2] Delivery of Advanced Network | [radsecproxy-impl] | |||
Technology to Europe, "European | Venaas, S., "radsecproxy Project Homepage", 2007, | |||
Commission Information Society | <http://software.uninett.no/radsecproxy/>. | |||
and Media: GEANT2", 2008, | ||||
<http://www.geant2.net/>. | ||||
[terena] TERENA, "Trans-European Research | [terena] Trans-European Research and Education Networking | |||
and Education Networking | Association (TERENA), "Task Force on Mobility and Network | |||
Association", 2008, | Middleware", 2008, | |||
<http://www.terena.org/>. | <http://www.terena.org/activities/tf-mobility/>. | |||
Appendix A. Implementation Overview: Radiator | Appendix A. Implementation Overview: Radiator | |||
Radiator implements the RadSec protocol for proxying requests with | Radiator implements the RadSec protocol for proxying requests with | |||
the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator | the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator | |||
configuration file. | configuration file. | |||
The <AuthBy RADSEC> clause defines a RadSec client, and causes | The <AuthBy RADSEC> clause defines a RadSec client, and causes | |||
Radiator to send RADIUS requests to the configured RadSec server | Radiator to send RADIUS requests to the configured RadSec server | |||
using the RadSec protocol. | using the RadSec protocol. | |||
skipping to change at page 19, line 40 | skipping to change at page 19, line 12 | |||
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 B. 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 | |||
in other circumstances as well. | used 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 | |||
there is one such clause for each client or server. In such a clause | there is one such clause for each client or server. In such a | |||
one specifies either "type tls" or "type udp" for RadSec or UDP | clause, one specifies either "type tls" or "type udp" for TLS or UDP | |||
transport. For RadSec the default shared secret "mysecret" (without | transport. Versions prior to 1.6 used "mysecret" as a default shared | |||
quotes), the same as Radiator, is used. For compliance with this | secret for RADIUS/TLS; version 1.6 and onwards uses "radsec". For | |||
document, this setting needs to be configured for the shared secret | backwards compatibility with older versions, the secret can be | |||
"radsec". A secret may be specified by putting say "secret | changed (which makes the configuration not compliant with this | |||
somesharedsecret" inside a client or server clause. | specification). | |||
In order to use TLS for clients and/or servers, one must also specify | In order to use TLS for clients and/or servers, one must also specify | |||
where to locate CA certificates, as well as certificate and key for | where to locate CA certificates, as well as certificate and key for | |||
the client or server. This is done in a TLS clause. There may be | the client or server. This is done in a TLS clause. There may be | |||
one or several TLS clauses. A client or server clause may reference | one or several TLS clauses. A client or server clause may reference | |||
a particular TLS clause, or just use a default one. One use for | a particular TLS clause, or just use a default one. One use for | |||
multiple TLS clauses may be to present one certificate to clients and | multiple TLS clauses may be to present one certificate to clients and | |||
another to servers. | another to servers. | |||
If any RadSec (TLS) clients are configured, the proxy will at startup | If any RadSec (TLS) clients are configured, the proxy will, at | |||
listen on port 2083, as assigned by IANA for the OSC RadSec | startup, listen on port 2083, as assigned by IANA for the OSC RadSec | |||
implementation. An alternative port may be specified. When a client | implementation. An alternative port may be specified. When a client | |||
connects, the client certificate will be verified, including checking | connects, the client certificate will be verified, including checking | |||
that the configured FQDN or IP address matches what is in the | that the configured Fully Qualified Domain Name (FQDN) or IP address | |||
certificate. Requests coming from a RadSec client are treated | matches what is in the certificate. Requests coming from a RadSec | |||
exactly like requests from UDP clients. | client are treated exactly like requests from UDP clients. | |||
The proxy will at startup try to establish a TLS connection to each | At startup, the proxy will try to establish a TLS connection to each | |||
(if any) of the configured RadSec (TLS) servers. If it fails to | (if any) of the configured RadSec (TLS) servers. If it fails to | |||
connect to a server, it will retry regularly. There is some back-off | connect to a server, it will retry regularly. There is some back-off | |||
where it will retry quickly at first, and with longer intervals | where it will retry quickly at first, and with longer intervals | |||
later. If a connection to a server goes down it will also start | later. If a connection to a server goes down, it will also start | |||
retrying regularly. When setting up the TLS connection, the server | retrying regularly. When setting up the TLS connection, the server | |||
certificate will be verified, including checking that the configured | certificate will be verified, including checking that the configured | |||
FQDN or IP address matches what is in the certificate. Requests are | FQDN or IP address matches what is in the certificate. Requests are | |||
sent to a RadSec server just like they would to a UDP server. | sent to a RadSec server, just like they would be to a UDP server. | |||
The proxy supports Status-Server messages. They are only sent to a | The proxy supports Status-Server messages. They are only sent to a | |||
server if enabled for that particular server. Status-Server requests | server if enabled for that particular server. Status-Server requests | |||
are always responded to. | are always responded to. | |||
This RadSec implementation has been successfully tested together with | This RadSec implementation has been successfully tested together with | |||
Radiator. It is a freely available open-source implementation. For | Radiator. It is a freely available, open-source implementation. For | |||
source code and documentation, see [radsecproxy-impl]. | source code and documentation, see [radsecproxy-impl]. | |||
Appendix C. Assessment of Crypto-Agility Requirements | Appendix C. Assessment of Crypto-Agility Requirements | |||
The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous | The RADIUS Crypto-Agility Requirements document [RFC6421] defines | |||
classification criteria for protocols that strive to enhance the | numerous classification criteria for protocols that strive to enhance | |||
security of RADIUS. It contains mandatory (M) and recommended (R) | the security of RADIUS. It contains mandatory (M) and recommended | |||
criteria which crypto-agile protocols have to fulfill. The authors | (R) criteria that crypto-agile protocols have to fulfill. The | |||
believe that the following assessment about the crypto-agility | authors believe that the following assessment about the crypto- | |||
properties of RADIUS/TLS are true. | agility properties of RADIUS/TLS are true. | |||
By virtue of being a transport profile using TLS over TCP as a | By virtue of being a transport profile using TLS over TCP as a | |||
transport protocol, the cryptographically agile properties of TLS are | transport protocol, the cryptographically agile properties of TLS are | |||
inherited, and RADIUS/TLS subsequently meets the following points: | inherited, and RADIUS/TLS subsequently meets the following points: | |||
(M) negotiation of cryptographic algorithms for integrity and auth | (M) negotiation of cryptographic algorithms for integrity and auth | |||
(M) negotiation of cryptographic algorithms for encryption | (M) negotiation of cryptographic algorithms for encryption | |||
(M) replay protection | (M) replay protection | |||
(M) define mandatory-to-implement cryptographic algorithms | (M) define mandatory-to-implement cryptographic algorithms | |||
(M) generate fresh session keys for use between client and server | (M) generate fresh session keys for use between client and server | |||
(R) support for Perfect Forward Secrecy in session keys | (R) support for Perfect Forward Secrecy in session keys | |||
skipping to change at page 21, line 14 | skipping to change at page 20, line 34 | |||
(M) negotiation of cryptographic algorithms for encryption | (M) negotiation of cryptographic algorithms for encryption | |||
(M) replay protection | (M) replay protection | |||
(M) define mandatory-to-implement cryptographic algorithms | (M) define mandatory-to-implement cryptographic algorithms | |||
(M) generate fresh session keys for use between client and server | (M) generate fresh session keys for use between client and server | |||
(R) support for Perfect Forward Secrecy in session keys | (R) support for Perfect Forward Secrecy in session keys | |||
(R) support X.509 certificate based operation | (R) support X.509 certificate-based operation | |||
(R) support Pre-Shared keys | (R) support Pre-Shared keys | |||
(R) support for confidentiality of the entire packet | (R) support for confidentiality of the entire packet | |||
(M/R) support Automated Key Management | (M/R) support Automated Key Management | |||
The remainder of the requirements is discussed individually below in | The remainder of the requirements is discussed individually below in | |||
more detail: | more detail: | |||
(M) "avoid security compromise, even in situations where the | (M) "...avoid security compromise, even in situations where the | |||
existing cryptographic alogrithms used by RADIUS implementations | existing cryptographic algorithms utilized by RADIUS | |||
are shown to be weak enough to provide little or no security" - | implementations are shown to be weak enough to provide little or | |||
The existing algorithm, based on MD5, is not of any significance | no security" [RFC6421]. The existing algorithm, based on MD5, is | |||
in RADIUS/TLS; its compromise does not compromise the outer | not of any significance in RADIUS/TLS; its compromise does not | |||
transport security. | compromise the outer transport security. | |||
(R) mandatory-to-implement alogrithms are to be NIST-Acceptable | (R) mandatory-to-implement algorithms are to be NIST-Acceptable | |||
with no deprecation date - The mandatory-to-implement algorithm is | with no deprecation date - The mandatory-to-implement algorithm is | |||
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three- | TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three- | |||
key 3DES operation, which is classified as Acceptable with no | key 3DES operation, which is classified as Acceptable with no | |||
known deprecation date by NIST. | known deprecation date by NIST. | |||
(M) demonstrate backward compatibility with RADIUS - There are | (M) demonstrate backward compatibility with RADIUS - There are | |||
multiple implementations supporting both RADIUS and RADIUS/TLS, | multiple implementations supporting both RADIUS and RADIUS/TLS, | |||
and the translation between them. | and the translation between them. | |||
(M) After legacy mechanisms have been compromised, secure | (M) After legacy mechanisms have been compromised, secure | |||
skipping to change at page 22, line 17 | skipping to change at page 21, line 37 | |||
created exclusively based on this specification and is | created exclusively based on this specification and is | |||
interoperable with other RADIUS/TLS implementations. | interoperable with other RADIUS/TLS implementations. | |||
(M) apply to all packet types - RADIUS/TLS operates on the | (M) apply to all packet types - RADIUS/TLS operates on the | |||
transport layer, and can carry all packet types. | transport layer, and can carry all packet types. | |||
(R) message data exchanged with Diameter SHOULD NOT be affected - | (R) message data exchanged with Diameter SHOULD NOT be affected - | |||
The solution is Diameter-agnostic. | The solution is Diameter-agnostic. | |||
(M) discuss any inherent assumptions - The authors are not aware | (M) discuss any inherent assumptions - The authors are not aware | |||
of any implicit assumptions which would be yet-unarticulated in | of any implicit assumptions that would be yet-unarticulated in the | |||
the draft | document. | |||
(R) provide recommendations for transition - The Security | (R) provide recommendations for transition - The Security | |||
Considerations section contains a transition path. | Considerations section contains a transition path. | |||
(R) discuss legacy interoperability and potential for bidding-down | (R) discuss legacy interoperability and potential for bidding-down | |||
attacks - The Security Considerations section contains an | attacks - The Security Considerations section contains a | |||
corresponding discussion. | corresponding discussion. | |||
Summarizing, it is believed that this specification fulfills all the | Summarizing, it is believed that this specification fulfills all the | |||
mandatory and all the recommended requirements for a crypto-agile | mandatory and all the recommended requirements for a crypto-agile | |||
solution and should thus be considered UNCONDITIONALLY COMPLIANT. | solution and should thus be considered UNCONDITIONALLY COMPLIANT. | |||
Authors' Addresses | Authors' Addresses | |||
Stefan Winter | Stefan Winter | |||
Fondation RESTENA | Fondation RESTENA | |||
6, rue Richard Coudenhove-Kalergi | 6, rue Richard Coudenhove-Kalergi | |||
Luxembourg 1359 | Luxembourg 1359 | |||
LUXEMBOURG | Luxembourg | |||
Phone: +352 424409 1 | Phone: +352 424409 1 | |||
Fax: +352 422473 | Fax: +352 422473 | |||
EMail: stefan.winter@restena.lu | EMail: stefan.winter@restena.lu | |||
URI: http://www.restena.lu. | URI: http://www.restena.lu. | |||
Mike McCauley | Mike McCauley | |||
Open Systems Consultants | Open Systems Consultants | |||
9 Bulbul Place | 9 Bulbul Place | |||
Currumbin Waters QLD 4223 | Currumbin Waters QLD 4223 | |||
AUSTRALIA | Australia | |||
Phone: +61 7 5598 7474 | Phone: +61 7 5598 7474 | |||
Fax: +61 7 5598 7070 | Fax: +61 7 5598 7070 | |||
EMail: mikem@open.com.au | EMail: mikem@open.com.au | |||
URI: http://www.open.com.au. | URI: http://www.open.com.au. | |||
Stig Venaas | Stig Venaas | |||
cisco Systems | Cisco Systems | |||
Tasman Drive | Tasman Drive | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
USA | USA | |||
EMail: stig@cisco.com | EMail: stig@cisco.com | |||
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: | EMail: klaas@cisco.com | |||
EMail: kwiereng@cisco.com | URI: http://www.cisco.com | |||
URI: http://www.cisco.com. | ||||
End of changes. 133 change blocks. | ||||
446 lines changed or deleted | 377 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |