--- 1/draft-ietf-radext-radsec-11.txt 2012-02-14 08:14:02.382672394 +0100 +++ 2/draft-ietf-radext-radsec-12.txt 2012-02-14 08:14:02.430672891 +0100 @@ -1,45 +1,45 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: July 30, 2012 OSC +Expires: August 17, 2012 OSC S. Venaas K. Wierenga Cisco - January 27, 2012 + February 14, 2012 - TLS encryption for RADIUS - draft-ietf-radext-radsec-11 + Transport Layer Security (TLS) encryption for RADIUS + draft-ietf-radext-radsec-12 Abstract - This document specifies security on the transport layer (TLS) for the - RADIUS protocol when transmitted over TCP. This enables dynamic - trust relationships between RADIUS servers. + This document specifies a transport profile for RADIUS using + Transport Layer Security (TLS) over TCP as the transport protocol. + This enables dynamic trust relationships between RADIUS servers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 30, 2012. + This Internet-Draft will expire on August 17, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,62 +60,63 @@ 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 - 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4 - 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4 - 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4 + 2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 5 + 2.1. TCP port and packet types . . . . . . . . . . . . . . . . 5 + 2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 5 2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5 - 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6 - 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7 - 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9 - 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9 - 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9 - 3.3. Ciphersuites and Compression Negotiation Considerations . 10 - 3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10 - 4. Compatibility with other RADIUS transports . . . . . . . . . . 11 - 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16 - Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17 - Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18 + 2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 7 + 2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 8 + 3. Informative: Design Decisions . . . . . . . . . . . . . . . . 10 + 3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 10 + 3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 10 + 3.3. Ciphersuites and Compression Negotiation Considerations . 11 + 3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 11 + 4. Compatibility with other RADIUS transports . . . . . . . . . . 12 + 5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Appendix A. Implementation Overview: Radiator . . . . . . . . . . 18 + Appendix B. Implementation Overview: radsecproxy . . . . . . . . 19 + Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 20 1. Introduction The RADIUS protocol [RFC2865] is a widely deployed authentication and authorisation protocol. The supplementary RADIUS Accounting specification [RFC2866] also provides accounting mechanisms, thus - delivering a full AAA solution. However, RADIUS is experiencing - several shortcomings, such as its dependency on the unreliable - transport protocol UDP and the lack of security for large parts of - its packet payload. RADIUS security is based on the MD5 algorithm, - which has been proven to be insecure. + delivering a full Authentication, Authorization, and Accounting (AAA) + solution. However, RADIUS is experiencing several shortcomings, such + as its dependency on the unreliable transport protocol UDP and the + lack of security for large parts of its packet payload. RADIUS + security is based on the MD5 algorithm, which has been proven to be + insecure. 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 - most important use of this specification lies in roaming environments - where RADIUS packets need to be transferred through different - administrative domains and untrusted, potentially hostile networks. - An example for a world-wide roaming environment that uses RADIUS over - TLS to secure communication is "eduroam", see [eduroam]. + communication between RADIUS/TCP peers using TLS. The most important + use of this specification lies in roaming environments where RADIUS + packets need to be transferred through different administrative + domains and untrusted, potentially hostile networks. An example for + a world-wide roaming environment that uses RADIUS over TLS to secure + communication is "eduroam", see [eduroam]. There are multiple known attacks on the MD5 algorithm which is used in RADIUS to provide integrity protection and a limited confidentiality protection (see [MD5-attacks]). RADIUS over TLS wraps the entire RADIUS packet payload into a TLS stream and thus mitigates the risk of attacks on MD5. Because of the static trust establishment between RADIUS peers (IP address and shared secret) the only scalable way of creating a massive deployment of RADIUS-servers under control by different @@ -153,38 +154,59 @@ 1.3. Document Status This document is an Experimental RFC. It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also Section 4). The specification does not fulfill all recommendations on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues. + If this specification is indeed selected for advancement to standards + track, certificate verification options (section 2.3.2) need to be + refined. + + Another experimental characteristic of this specification is the + question of key management between RADIUS/TLS peers. RADIUS/UDP only + allowed for manual key management, i.e. distribution of a shared + secret between a client and a server. RADIUS/TLS allows manual + distribution of long-term proofs of peer identity as well (by using + TLS-PSK cipher suites, or identifying clients by a certificate + 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 + methods prevail, or if both will find their place in real-life + deployments. The authors can imagine pre-shared keys to be popular + in small-scale deployments (SOHO or isolated enterprise deployments) + where scalability is not an issue and the deployment of a CA is + considered too much a hassle; but can also imagine large roaming + consortia to make use of PKIX. Readers of this specification are + encouraged to read the discussion of key management issus within + [RFC6421] as well as [RFC4107]. + 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 usable at large scale is by observing the uptake, usability and operational behaviour of the protocol in large-scale, real-life deployments. An example for a world-wide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam]. 2. Normative: Transport Layer Security for RADIUS/TCP 2.1. TCP port and packet types The default destination port number for RADIUS over TLS is TCP/2083. There are no separate ports for authentication, accounting and dynamic authorisation changes. The source port is arbitrary. See section Section 3.4 for considerations regarding separation of - authentication, accounting and dynauth traffic. + authentication, accounting and dynamic authorization traffic. 2.2. TLS negotiation RADIUS/TLS 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 @@ -194,122 +216,140 @@ exponentially growing intervals between every try. If multiple servers are defined, the node MAY attempt to establish a connection to these other servers in parallel, in order to implement quick failover. 2. after completing the TCP handshake, immediately negotiate TLS sessions according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply: * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 - [RFC5246] ]) is REQUIRED. + [RFC5246] ]) is REQUIRED. To prevent known attacks on TLS + versions prior to 1.1, implementations MUST NOT negotiate TLS + versions prior to 1.1. * Support for certificate-based mutual authentication is REQUIRED. * Negotiation of mutual authentication is REQUIRED. * Negotiation of a ciphersuite providing for confidentiality as - well as integrity protection is REQUIRED. + well as integrity protection is REQUIRED. Failure to comply + with this requirement can lead to severe security problmes, + like user passwords being recoverable by third parties. See + Section 6 for details. * Support for and negotiation of compression is OPTIONAL. * Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL. * 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.3 (1) ). + TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 ). * In addition, RADIUS/TLS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support. - * RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL - encryption (e.g. [RFC4785]). + 3. Peer authentication can be performed in any of the following + three operation models: - 3. If TLS is used in an X.509 certificate based operation mode, the - following list of certificate validation options applies: + * TLS with X.509 certificates using PKIX trust models (this + model is mandatory to implement): - * Implementations MUST allow to configure a list of acceptable + + Implementations MUST allow to configure a list of trusted Certification Authorities for incoming connections. - * Certificate validation MUST include the verification rules as - per [RFC5280]. + + Certificate validation MUST include the verification rules + as per [RFC5280]. - * Implementations SHOULD indicate their acceptable Certification - Authorities as per section 7.4.4 (server side) and x.y.z - ["Trusted CA Indication"] (client side) of [RFC5246] (see - Section 3.2) + + Implementations SHOULD indicate their trusted Certification + Authorities (CAs). For TLS 1.2, this is done using + [RFC5246] section 7.4.4 "certificate authorities" (server + side) and [RFC6066] Section 6 "Trusted CA Indication" + (client side). See also Section 3.2. - * Implementations SHOULD allow to configure a list of acceptable - certificates, identified via certificate fingerprint. When a - fingerprint configured, the fingerprint is prepended with an - ASCII label identifying the hash function followed by a colon. - Implementations MUST support SHA-1 as the hash algorithm and - use the ASCII label "sha-1" to identify the SHA-1 algorithm. - The length of a SHA-1 hash is 20 bytes and the length of the - corresponding fingerprint string is 65 characters. An example - certificate fingerprint is: sha- - 1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D + + Peer validation always includes a check on whether the + locally configured expected DNS name or IP address of the + server that is contacted matches its presented certificate. + DNS names and IP addresses can be contained in the Common + Name (CN) or subjectAltName entries. For verification, + only one of these entries is to be considered. The + following precedence applies: for DNS name validation, + subjectAltName:DNS has precedence over CN; for IP address + validation, subjectAltName:iPAddr has precedence over CN. + Implementors of this specification are advised to read + [RFC6125] Section 6 for more details on DNS name + validation. - * Peer validation always includes a check on whether the locally - configured expected DNS name or IP address of the server that - is contacted matches its presented certificate. DNS names and - IP addresses can be contained in the Common Name (CN) or - subjectAltName entries. For verification, only one of these - entries is to be considered. The following precedence - applies: for DNS name validation, subjectAltName:DNS has - precedence over CN; for IP address validation, subjectAltName: - iPAddr has precedence over CN. + + Implementations MAY allow to configure a set of additional + properties of the certificate to check for a peer's + authorisation to communicate (e.g. a set of allowed values + in subjectAltName:URI or a set of allowed X509v3 + Certificate Policies) - * Implementations SHOULD allow to configure a set of acceptable - values for subjectAltName:URI. + + When the configured trust base changes (e.g. removal of a + CA from the list of trusted CAs; issuance of a new CRL for + a given CA) implementations MAY re-negotiate the TLS + session to re-assess the connecting peer's continued + authorisation. - 4. start exchanging RADIUS datagrams. Note Section 3.4 (1) ). The + * TLS with X.509 certificates using certificate fingerprints + (this model is optional to implement): Implementations SHOULD + allow to configure a list of trusted certificates, identified + via fingerprint of the DER encoded certificate octets. + Implementations MUST support SHA-1 as the hash algorithm for + the fingerprint. To prevent attacks based on hash collisions, + support for a more contemporary hash function such as SHA-256 + is RECOMMENDED. + + * TLS using TLS-PSK (this model is optional to implement) + + 4. start exchanging RADIUS datagrams (note Section 3.4 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.4 (2) ). 2.4. Connecting Client Identity In RADIUS/UDP, clients are uniquely identified by their IP address. Since the shared secret is associated with the origin IP address, if more than one RADIUS client is associated with the same IP address, then those clients also must utilize the same shared secret, a practice which is inherently insecure as noted in [RFC5247]. RADIUS/TLS supports multiple operation modes. In TLS-PSK operation, a client is uniquely identified by its TLS identifier. In TLS-X.509 mode using fingerprints, a client is uniquely identified by the fingerprint of the presented client certificate. - In TLS-X.509 with PKI infrastructure, a client is uniquely identified - by the serial number of the tuple (presented client + In TLS-X.509 mode using PKIX trust models, a client is uniquely + identified by the tuple (serial number of presented client certificate;Issuer). Note well: having identified a connecting entity does not mean the server necessarily wants to communicate with that client. E.g. if the Issuer is not in a trusted set of Issuers, the server may decline to perform RADIUS transactions with this client. - There are numerous trust models in PKI environments, and it is beyond - the scope of this document to define how a particular deployment - determines whether a client is trustworthy. Implementations which - want to support a wide variety of trust models should expose as many - details of the presented certificate to the administrator as possible - so that the trust model can be implemented by the administrator. As - a suggestion, at least the following parameters of the X.509 client - certificate should be exposed: + There are numerous trust models in PKIX environments, and it is + beyond the scope of this document to define how a particular + deployment determines whether a client is trustworthy. + Implementations which want to support a wide variety of trust models + should expose as many details of the presented certificate to the + administrator as possible so that the trust model can be implemented + by the administrator. As a suggestion, at least the following + parameters of the X.509 client certificate should be exposed: o Originating IP address o Certificate Fingerprint o Issuer o Subject o all X509v3 Extended Key Usage @@ -371,24 +410,43 @@ o ... and they receive o Access-Request o Accounting-Request o Status-Server + o Disconnect-ACK o ... + 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 + types of packets are supported on a server. See also section + Section 3.4 for a discussion of signaling. + + o When receiving an unwanted packet of type 'CoA-Request' or + 'Disconnect-Request', it needs to be replied to with a 'CoA-NAK' + or 'Disconnect-NAK' respectively. The NAK SHOULD contain an + attribute Error-Cause with the value 406 ("Unsupported + Extension"); see [RFC5176] for details. + + o When receiving an unwanted packet of type 'Accounting-Request', + the RADIUS/TLS server SHOULD reply with an Accounting-Response + containing an Error-Cause attribute with value 406 "Unsupported + Extension" as defined in [RFC5176]. A RADIUS/TLS accounting + client receiving such an Accounting-Response SHOULD log the error + and stop sending Accounting-Request packets. + 3. Informative: Design Decisions This section explains the design decisions that led to the rules defined in the previous section. 3.1. Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechanism is still under development and therefore is not a normative @@ -425,21 +483,21 @@ 3.3. Ciphersuites and Compression Negotiation Considerations Not all TLS ciphersuites in [RFC5246] are supported by available TLS tool kits, and licenses may be required in some cases. The existing implementations of RADIUS/TLS use OpenSSL as cryptographic backend, which supports all of the ciphersuites listed in the rules in the normative section. The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to- - implement according to [RFC5246] and thus has to be supported by + implement according to [RFC4346] and thus has to be supported by RADIUS/TLS nodes. The two other ciphersuites in the normative section are widely implemented in TLS toolkits and are considered good practice to implement. 3.4. RADIUS Datagram Considerations (1) After the TLS session is established, RADIUS packet payloads are exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet @@ -472,42 +530,39 @@ of a server which receives requests, processes them and sends the appropriate replies is to be preserved. The normative rules about acceptable packet types for clients and servers mirror the packet flow behaviour from RADIUS/UDP. (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation - to actually process these packet types. It is sufficient that upon - receiving such a packet, an unconditional NAK is sent back to - indicate that the action is not supported. The NAK SHOULD contain an - attribute Error-Cause with the value 406 ("Unsupported Extension"); - see [RFC5176] for details. + to actually process these packet types; it is only required to send + the NAK as defined above. (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets. There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which - does not wish to process their Accounting packet. The server will - need to silently drop the packet. The client will need to deduce - from the absence of replies that it is misconfigured; no negative - ICMP response will reveal this. + does not wish to process their Accounting packet. To prevent a + regression of detectability of this situation, the Accounting- + Response + Error-Cause sgnaling was introduced. 4. Compatibility with other RADIUS transports Ongoing work in the IETF defines multiple alternative transports to the classic UDP transport model as defined in [RFC2865], namely - RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS - [I-D.ietf-radext-dtls] and this present document on RADIUS over TLS. + RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over Datagram + Transport Layer Security (DTLS) [I-D.ietf-radext-dtls] and this + present document on RADIUS over TLS. RADIUS/TLS does not specify any inherent backwards compatibility to RADIUS/UDP or cross compatibility to the other transports, i.e. an implementation which implements RADIUS/TLS only will not be able to receive or send RADIUS packet payloads over other transports. An implementation wishing to be backward or cross compatible (i.e. wishes to serve clients using other transports than RADIUS/TLS) will need to implement these other transports along with the RADIUS/TLS transport and be prepared to send and receive on all implemented transports, which is called a multi-stack implementation. @@ -536,51 +591,69 @@ create a Denial-of-Service attack more easily. Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification forbids the use of such ciphersuites. Since the RADIUS payload's shared secret is fixed to the well-known term "radsec" (see Section 2.3 (4) ) , failure to comply with this requirement will expose the entire datagram payload in plain text, including User-Password, to intermediate IP nodes. - If peer communication between two devices is configured for both - RADIUS/TLS transport (i.e TLS security on the transport layer, shared + By virtue of being based on TCP, there are several generic attack + vectors to slow down or prevent the TCP connection from being + 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 + attacks in general lead only to a minor performance degradation (the + time it takes to re-establish the connection). There is one notable + exception where an attacker might create a bidding-down attack + though: If peer communication between two devices is configured for + 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 with a secret manually configured by the administrator), and where the RADIUS/UDP transport is the failover option if the TLS session - cannot be established, a down-bidding 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 from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/ UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker - RADIUS/UDP transport as soon as the new RADIUS/TLS transport is + RADIUS/UDP transport as soon as the new RADIUS/TLS connection is established and tested. Disabling can happen at either the RADIUS client or server side: o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients - The RADIUS/TLS transport provides authentication and encryption - between RADIUS peers. In the presence of proxies, the intermediate - proxies can still inspect the individual RADIUS packets, i.e. "end- - to-end" encryption is not provided. Where intermediate proxies are + RADIUS/TLS provides authentication and encryption between RADIUS + peers. In the presence of proxies, the intermediate proxies can + still inspect the individual RADIUS packets, i.e. "end-to-end" + encryption is not provided. Where intermediate proxies are untrusted, it is desirable to use other RADIUS mechanisms to prevent RADIUS packet payload from inspection by such proxies. One common - method to protect passwords is the use of EAP methods which utilize - TLS. + method to protect passwords is the use of the Extensible + Authentication Protocol (EAP) and EAP methods which utilize TLS. + + When using certificate fingerprints to identify RADIUS/TLS peers, any + two certificates which produce the same hash value (i.e. which have a + hash collision) will be considered the same client. It is therefore + important to make sure that the hash function used is + cryptographically uncompromised so that an attacker is very unlikely + to be able to produce a hash collision with a certificate of his + choice. While this specification mandates support for SHA-1, a later + revision will likely demand support for more contemporary hash + functions because as of issuance of this document there are already + attacks on SHA-1. 7. IANA Considerations No new RADIUS attributes or packet codes are defined. IANA is requested to update the already-assigned TCP port number 2083 in the following ways: o Reference: list the RFC number of this document as the reference o Assignment Notes: add the text "The TCP port 2083 was already @@ -628,27 +702,20 @@ June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. - [RFC4785] Blumenthal, U. and P. Goel, - "Pre-Shared Key (PSK) - Ciphersuites with NULL - Encryption for Transport Layer - Security (TLS)", RFC 4785, - January 2007. - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5176] Chiba, M., Dommety, G., Eklund, @@ -663,20 +730,25 @@ Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. + [RFC6066] Eastlake, D., "Transport Layer + Security (TLS) Extensions: + Extension Definitions", + RFC 6066, January 2011. + [I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr aft-ietf-radext-tcp-transport-09 (work in progress), October 2010. 10.2. Informative References [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for RADIUS", draft-ietf-radext-dtls-01 (work @@ -692,25 +764,44 @@ [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + [RFC4107] Bellovin, S. and R. Housley, + "Guidelines for Cryptographic + Key Management", BCP 107, + RFC 4107, June 2005. + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. + [RFC4953] Touch, J., "Defending TCP + Against Spoofing Attacks", + RFC 4953, July 2007. + + [RFC6125] Saint-Andre, P. and J. Hodges, + "Representation and Verification + 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 Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011. [radsec-whitepaper] Open System Consultants, "RadSec - a secure, reliable RADIUS Protocol", May 2005,