From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7360.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc7360.txt (limited to 'doc/rfc/rfc7360.txt') diff --git a/doc/rfc/rfc7360.txt b/doc/rfc/rfc7360.txt new file mode 100644 index 0000000..5ed92d2 --- /dev/null +++ b/doc/rfc/rfc7360.txt @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) A. DeKok +Request for Comments: 7360 FreeRADIUS +Category: Experimental September 2014 +ISSN: 2070-1721 + + + Datagram Transport Layer Security (DTLS) + as a Transport Layer for RADIUS + +Abstract + + The RADIUS protocol defined in RFC 2865 has limited support for + authentication and encryption of RADIUS packets. The protocol + transports data in the clear, although some parts of the packets can + have obfuscated content. Packets may be replayed verbatim by an + attacker, and client-server authentication is based on fixed shared + secrets. This document specifies how the Datagram Transport Layer + Security (DTLS) protocol may be used as a fix for these problems. It + also describes how implementations of this proposal can coexist with + current RADIUS systems. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + 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. + + 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/rfc7360. + + + + + + + + + + + + + +DeKok Experimental [Page 1] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +DeKok Experimental [Page 2] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................5 + 1.2. Requirements Language ......................................5 + 1.3. Document Status ............................................5 + 2. Building on Existing Foundations ................................6 + 2.1. Changes to RADIUS ..........................................7 + 2.2. Similarities with RADIUS/TLS ...............................8 + 2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8 + 3. Interaction with RADIUS/UDP .....................................9 + 3.1. DTLS Port and Packet Types ................................10 + 3.2. Server Behavior ...........................................10 + 4. Client Behavior ................................................11 + 5. Session Management .............................................12 + 5.1. Server Session Management .................................12 + 5.1.1. Session Opening and Closing ........................13 + 5.2. Client Session Management .................................15 + 6. Implementation Guidelines ......................................16 + 6.1. Client Implementations ....................................17 + 6.2. Server Implementations ....................................18 + 7. Diameter Considerations ........................................18 + 8. IANA Considerations ............................................18 + 9. Implementation Status ..........................................18 + 9.1. Radsecproxy ...............................................19 + 9.2. jradius ...................................................19 + 10. Security Considerations .......................................19 + 10.1. Crypto-Agility ...........................................20 + 10.2. Legacy RADIUS Security ...................................21 + 10.3. Resource Exhaustion ......................................22 + 10.4. Client-Server Authentication with DTLS ...................22 + 10.5. Network Address Translation ..............................24 + 10.6. Wildcard Clients .........................................24 + 10.7. Session Closing ..........................................25 + 10.8. Client Subsystems ........................................25 + 11. References ....................................................26 + 11.1. Normative References .....................................26 + 11.2. Informative References ...................................27 + Acknowledgments ...................................................27 + + + + + + + + + + + + +DeKok Experimental [Page 3] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + +1. Introduction + + The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], + and others has traditionally used methods based on MD5 [RFC1321] for + per-packet authentication and integrity checks. However, the MD5 + algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. + As a result, some specifications, such as [RFC5176], have recommended + using IPsec to secure RADIUS traffic. + + While RADIUS over IPsec has been widely deployed, there are + difficulties with this approach. The simplest point against IPsec is + that there is no straightforward way for an application to control or + monitor the network security policies. That is, the requirement that + the RADIUS traffic be encrypted and/or authenticated is implicit in + the network configuration, and it cannot be enforced by the RADIUS + application. + + This specification takes a different approach. We define a method + for using DTLS [RFC6347] as a RADIUS transport protocol. This + approach has the benefit that the RADIUS application can directly + monitor and control the security policies associated with the traffic + that it processes. + + Another benefit is that RADIUS over DTLS continues to be a UDP-based + protocol. The change from RADIUS/UDP is largely to add DTLS support, + and make any necessary related changes to RADIUS. This allows + implementations to remain UDP based, without changing to a TCP + architecture. + + This specification does not, however, solve all of the problems + associated with RADIUS/UDP. The DTLS protocol does not add reliable + or in-order transport to RADIUS. DTLS also does not support + fragmentation of application-layer messages, or of the DTLS messages + themselves. This specification therefore shares with traditional + RADIUS the issues of order, reliability, and fragmentation. These + issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS + [RFC6614]. + + + + + + + + + + + + + + +DeKok Experimental [Page 4] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + +1.1. Terminology + + This document uses the following terms: + + RADIUS/DTLS + This term is a shorthand for "RADIUS over DTLS". + + RADIUS/DTLS client + This term refers both to RADIUS clients as defined in [RFC2865] + and to Dynamic Authorization clients as defined in [RFC5176] that + implement RADIUS/DTLS. + + RADIUS/DTLS server + This term refers both to RADIUS servers as defined in [RFC2865] + and to Dynamic Authorization servers as defined in [RFC5176] that + implement RADIUS/DTLS. + + RADIUS/UDP + RADIUS over UDP, as defined in [RFC2865]. + + RADIUS/TLS + RADIUS over TLS, as defined in [RFC6614]. + + silently discard + This means that the implementation discards the packet without + further processing. + +1.2. Requirements Language + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be + interpreted as described in [RFC2119]. + +1.3. Document Status + + This document is an Experimental RFC. + + It contains one of several approaches to address known cryptographic + weaknesses of the RADIUS protocol, such as described in [RFC6614]. + This specification does not fulfill all recommendations for an + Authentication, Authorization, and Accounting (AAA) transport profile + as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and + therefore does not have head-of-line blocking issues. + + + + + + +DeKok Experimental [Page 5] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + If this specification is indeed selected for advancement to Standards + Track, certificate verification options ([RFC6614], Section 2.3, + point 2) will need to be refined. + + Another experimental characteristic of this specification is the + question of key management between RADIUS/DTLS peers. RADIUS/UDP + only allowed for manual key management, i.e., distribution of a + shared secret between a client and a server. RADIUS/DTLS allows + manual distribution of long-term proofs of peer identity, by using + TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 + certificates in a PKIX infrastructure. It remains to be seen if one + of these methods will prevail or if both will find their place in + real-life deployments. The authors can imagine pre-shared keys + (PSKs) to be popular in small-scale deployments (Small Office, Home + Office (SOHO) or isolated enterprise deployments) where scalability + is not an issue and the deployment of a Certification Authority (CA) + is considered too much of a hassle; however, the authors can also + imagine large 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]. + + 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 on a large scale is by observing the uptake, usability, and + operational behavior of the protocol in large-scale, real-life + deployments. + +2. Building on Existing Foundations + + Adding DTLS as a RADIUS transport protocol requires a number of + changes to systems implementing standard RADIUS. This section + outlines those changes, and defines new behaviors necessary to + implement DTLS. + + + + + + + + + + + + + + + + + + +DeKok Experimental [Page 6] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + +2.1. Changes to RADIUS + + The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and + [RFC5176]. Specifically, all of the following portions of RADIUS + MUST be unchanged when using RADIUS/DTLS: + + * Packet format + * Permitted codes + * Request Authenticator calculation + * Response Authenticator calculation + * Minimum packet length + * Maximum packet length + * Attribute format + * Vendor-Specific Attribute (VSA) format + * Permitted data types + * Calculations of dynamic attributes such as CHAP-Challenge, or + Message-Authenticator. + * Calculation of "obfuscated" attributes such as User-Password and + Tunnel-Password. + + In short, the application creates a RADIUS packet via the usual + methods, and then instead of sending it over a UDP socket, sends the + packet to a DTLS layer for encapsulation. DTLS then acts as a + transport layer for RADIUS: hence, the names "RADIUS/UDP" and + "RADIUS/DTLS". + + The requirement that RADIUS remain largely unchanged ensures the + simplest possible implementation and widest interoperability of this + specification. + + We note that the DTLS encapsulation of RADIUS means that RADIUS + packets have an additional overhead due to DTLS. Implementations + MUST support sending and receiving encapsulated RADIUS packets of + 4096 octets in length, with a corresponding increase in the maximum + size of the encapsulated DTLS packets. This larger packet size may + cause the packet to be larger than the Path MTU (PMTU), where a + RADIUS/UDP packet may be smaller. See Section 5.2, below, for more + discussion. + + + + + + + + + + + + + +DeKok Experimental [Page 7] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + The only changes made from RADIUS/UDP to RADIUS/DTLS are the + following two items: + + (1) The Length checks defined in [RFC2865], Section 3, MUST use the + length of the decrypted DTLS data instead of the UDP packet + length. They MUST treat any decrypted DTLS data octets outside + the range of the Length field as padding and ignore it on + reception. + + (2) The shared secret used to compute the MD5 integrity checks and + the attribute encryption MUST be "radius/dtls". + + All other aspects of RADIUS are unchanged. + +2.2. Similarities with RADIUS/TLS + + While this specification can be thought of as RADIUS/TLS over UDP + instead of the Transmission Control Protocol (TCP), there are some + differences between the two methods. The bulk of [RFC6614] applies + to this specification, so we do not repeat it here. + + This section explains the differences between RADIUS/TLS and + RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as + follows: + + * We replace references to "TCP" with "UDP" + + * We replace references to "RADIUS/TLS" with "RADIUS/DTLS" + + * We replace references to "TLS" with "DTLS" + + Those changes are sufficient to cover the majority of the differences + between the two specifications. The next section reviews some more + detailed changes from [RFC6614], giving additional commentary only + where necessary. + +2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS + + This section describes how particular sections of [RFC6614] apply to + RADIUS/DTLS. + + Section 2.1 applies to RADIUS/DTLS, with the exception that the + RADIUS/DTLS port is UDP/2083. + + Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be + pre-configured to use RADIUS/DTLS for a given endpoint. + + + + + +DeKok Experimental [Page 8] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be + interpreted as applying to DTLS session initiation, instead of TCP + connection establishment. Item (2) applies, except for the + recommendation that implementations "SHOULD" support + TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical + artifact of RADIUS/TLS, and it does not apply to RADIUS/DTLS. Item + (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed + shared secret is "radius/dtls", as described above. + + Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be + determined from DTLS parameters, instead of relying solely on the + source IP address of the packet. + + Section 2.5 does not apply to RADIUS/DTLS. The relationship between + RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from + RADIUS/UDP. + + Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS. + + Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS + packet is encapsulated in one DTLS packet, and there is no "stream" + of RADIUS packets inside of a TLS session. Implementors MUST enforce + the requirements of [RFC2865], Section 3, for the RADIUS Length + field, using the length of the decrypted DTLS data for the checks. + This check replaces the RADIUS method of using the Length field from + the UDP packet. + + Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS. + + Section 4 does not apply to RADIUS/DTLS. Protocol compatibility + considerations are defined in this document. + + Section 6 applies to RADIUS/DTLS. + +3. Interaction with RADIUS/UDP + + Transitioning to DTLS is a process that needs to be done carefully. + A poorly handled transition is complex for administrators and + potentially subject to security downgrade attacks. It is not + sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS + has no provisions for protocol negotiation, so simply disabling + RADIUS/UDP would result in timeouts, lost traffic, and network + instabilities. + + The end result of this specification is that nearly all RADIUS/UDP + implementations should transition to using a secure alternative. In + some cases, RADIUS/UDP may remain where IPsec is used as a transport, + or where implementation and/or business reasons preclude a change. + + + +DeKok Experimental [Page 9] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + However, we do not recommend long-term use of RADIUS/UDP outside of + isolated and secure networks. + + This section describes how clients and servers should use + RADIUS/DTLS, and how it interacts with RADIUS/UDP. + +3.1. DTLS Port and Packet Types + + The default destination port number for RADIUS/DTLS is UDP/2083. + There are no separate ports for authentication, accounting, and + dynamic authorization changes. The source port is arbitrary. The + text in [RFC6614], Section 3.4, describes issues surrounding the use + of one port for multiple packet types. We recognize that + implementations may allow the use of RADIUS/DTLS over non-standard + ports. In that case, the references to UDP/2083 in this document + should be read as applying to any port used for transport of + RADIUS/DTLS traffic. + +3.2. Server Behavior + + When a server receives packets on UDP/2083, all packets MUST be + treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on + this port. + + Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. + Early versions of this specification permitted this behavior. It is + forbidden here, as it depended on behavior in DTLS that may change + without notice. + + Servers MUST authenticate clients. RADIUS is designed to be used by + mutually trusted systems. Allowing anonymous clients would ensure + privacy for RADIUS/DTLS traffic, but would negate all other security + aspects of the protocol. + + As RADIUS has no provisions for capability signaling, there is no way + for a server to indicate to a client that it should transition to + using DTLS. This action has to be taken by the administrators of the + two systems, using a method other than RADIUS. This method will + likely be out of band, or manual configuration will need to be used. + + Some servers maintain a list of allowed clients per destination port. + Others maintain a global list of clients that are permitted to send + packets to any port. Where a client can send packets to multiple + ports, the server MUST maintain a "DTLS Required" flag per client. + + This flag indicates whether or not the client is required to use + DTLS. When set, the flag indicates that the only traffic accepted + from the client is over UDP/2083. When packets are received from a + + + +DeKok Experimental [Page 10] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + client on non-DTLS ports, for which DTLS is required, the server MUST + silently discard these packets, as there is no RADIUS/UDP shared + secret available. + + This flag will often be set by an administrator. However, if a + server receives DTLS traffic from a client, it SHOULD notify the + administrator that DTLS is available for that client. It MAY mark + the client as "DTLS Required". + + It is RECOMMENDED that servers support the following Perfect Forward + Secrecy (PFS) ciphersuites: + + o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 + + o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + + Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the + traffic to downbidding attacks and is NOT RECOMMENDED. + +4. Client Behavior + + When a client sends packets to the assigned RADIUS/DTLS port, all + packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this + port. + + Clients MUST authenticate themselves to servers via credentials that + are unique to each client. + + It is RECOMMENDED that clients support the following PFS + ciphersuites: + + o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 + + o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + + RADIUS/DTLS clients SHOULD NOT probe servers to see if they support + DTLS transport. Instead, clients SHOULD use DTLS as a transport + layer only when administratively configured. If a client is + configured to use DTLS and the server appears to be unresponsive, the + client MUST NOT fall back to using RADIUS/UDP. Instead, the client + should treat the server as being down. + + RADIUS clients often had multiple independent RADIUS implementations + and/or processes that originate packets. This practice was simple to + implement, but the result is that each independent subsystem must + independently discover network issues or server failures. It is + therefore RECOMMENDED that clients with multiple internal RADIUS + sources use a local proxy as described in Section 6.1, below. + + + +DeKok Experimental [Page 11] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + Clients may implement "pools" of servers for fail-over or load- + balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS + servers. + +5. Session Management + + Where [RFC6614] can rely on the TCP state machine to perform session + tracking, this specification cannot. As a result, implementations of + this specification may need to perform session management of the DTLS + session in the application layer. This section describes logically + how this tracking is done. Implementations may choose to use the + method described here, or another, equivalent method. + + We note that [RFC5080], Section 2.2.2, already mandates a duplicate + detection cache. The session tracking described below can be seen as + an extension of that cache, where entries contain DTLS sessions + instead of RADIUS/UDP packets. + + [RFC5080], Section 2.2.2, describes how duplicate RADIUS/UDP requests + result in the retransmission of a previously cached RADIUS/UDP + response. Due to DTLS sequence window requirements, a server MUST + NOT retransmit a previously sent DTLS packet. Instead, it should + cache the RADIUS response packet, and re-process it through DTLS to + create a new RADIUS/DTLS packet, every time it is necessary to + retransmit a RADIUS response. + +5.1. Server Session Management + + A RADIUS/DTLS server MUST track ongoing DTLS sessions for each, based + on the following 4-tuple: + + * source IP address + * source port + * destination IP address + * destination port + + Note that this 4-tuple is independent of IP address version (IPv4 or + IPv6). + + + + + + + + + + + + + +DeKok Experimental [Page 12] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + Each 4-tuple points to a unique session entry, which usually contains + the following information: + + DTLS Session + Any information required to maintain and manage the DTLS session. + + Last Traffic + A variable containing a timestamp that indicates when this session + last received valid traffic. If "Last Traffic" is not used, this + variable may not exist. + + DTLS Data + An implementation-specific variable that may contain information + about the active DTLS session. This variable may be empty or + nonexistent. + + This data will typically contain information such as idle + timeouts, session lifetimes, and other implementation-specific + data. + +5.1.1. Session Opening and Closing + + Session tracking is subject to Denial-of-Service (DoS) attacks due to + the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers + SHOULD use the stateless cookie tracking technique described in + [RFC6347], Section 4.2.1. DTLS sessions SHOULD NOT be tracked until + a ClientHello packet has been received with an appropriate Cookie + value. Server implementation SHOULD have a way of tracking DTLS + sessions that are partially set up. Servers MUST limit both the + number and impact on resources of partial sessions. + + Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure + Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert + ([RFC5246], Section 7.2.2) is received. When a session is deleted + due to it failing security requirements, the DTLS session MUST be + closed, any TLS session resumption parameters for that session MUST + be discarded, and all tracking information MUST be deleted. + + Sessions MUST also be deleted when a RADIUS packet fails validation + due to a packet being malformed, or when it has an invalid Message- + Authenticator or invalid Request Authenticator. There are other + cases when the specifications require that a packet received via a + DTLS session be "silently discarded". In those cases, + implementations MAY delete the underlying session as described above. + There are few reasons to communicate with a Network Access Server + (NAS) that is not implementing RADIUS. + + + + + +DeKok Experimental [Page 13] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + A session MUST be deleted when non-RADIUS traffic is received over + it. This specification is for RADIUS, and there is no reason to + allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST + be deleted when RADIUS traffic fails to pass security checks. There + is no reason to permit insecure networks. A session SHOULD NOT be + deleted when a well-formed, but "unexpected", RADIUS packet is + received over it. Future specifications may extend RADIUS/DTLS, and + we do not want to forbid those specifications. + + The goal of the above requirements is to ensure security, while + maintaining flexibility. Any security-related issue causes the + connection to be closed. After the security restrictions have been + applied, any unexpected traffic may be safely ignored, as it cannot + cause a security issue. There is no need to close the session for + unexpected but valid traffic, and the session can safely remain open. + + Once a DTLS session is established, a RADIUS/DTLS server SHOULD use + DTLS Heartbeats [RFC6520] to determine connectivity between the two + servers. A server SHOULD also use watchdog packets from the client + to determine that the session is still active. + + As UDP does not guarantee delivery of messages, RADIUS/DTLS servers + that do not implement an application-layer watchdog MUST also + maintain a "Last Traffic" timestamp per DTLS session. The + granularity of this timestamp is not critical and could be limited to + one-second intervals. The timestamp SHOULD be updated on reception + of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than + once per interval. The timestamp MUST NOT be updated in other + situations. + + When a session has not received a packet for a period of time, it is + labeled "idle". The server SHOULD delete idle DTLS sessions after an + "idle timeout". The server MAY cache the TLS session parameters, in + order to provide for fast session resumption. + + This session "idle timeout" SHOULD be exposed to the administrator as + a configurable setting. It SHOULD NOT be set to less than 60 seconds + and SHOULD NOT be set to more than 600 seconds (10 minutes). The + minimum useful value for this timer is determined by the application- + layer watchdog mechanism defined in the following section. + + RADIUS/DTLS servers SHOULD also monitor the total number of open + sessions. They SHOULD have a "maximum sessions" setting exposed to + administrators as a configurable parameter. When this maximum is + reached and a new session is started, the server MUST either drop an + old session in order to open the new one or not create a new session. + + + + + +DeKok Experimental [Page 14] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + RADIUS/DTLS servers SHOULD implement session resumption, preferably + stateless session resumption as given in [RFC5077]. This practice + lowers the time and effort required to start a DTLS session with a + client and increases network responsiveness. + + Since UDP is stateless, the potential exists for the client to + initiate a new DTLS session using a particular 4-tuple, before the + server has closed the old session. For security reasons, the server + MUST keep the old session active until either it has received secure + notification from the client that the session is closed or the server + decides to close the session based on idle timeouts. Taking any + other action would permit unauthenticated clients to perform a DoS + attack, by reusing a 4-tuple and thus causing the server to close an + active (and authenticated) DTLS session. + + As a result, servers MUST ignore any attempts to reuse an existing + 4-tuple from an active session. This requirement can likely be + reached by simply processing the packet through the existing session, + as with any other packet received via that 4-tuple. Non-compliant, + or unexpected packets will be ignored by the DTLS layer. + + The above requirement is mitigated by the suggestion in Section 6.1, + below, that the client use a local proxy for all RADIUS traffic. + That proxy can then track the ports that it uses and ensure that + reuse of 4-tuples is avoided. The exact process by which this + tracking is done is outside of the scope of this document. + +5.2. Client Session Management + + Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU + between the client and server, prior to sending any RADIUS traffic. + Once a DTLS session is established, a RADIUS/DTLS client SHOULD use + DTLS Heartbeats [RFC6520] to determine connectivity between the two + systems. RADIUS/DTLS clients SHOULD also use the application-layer + watchdog algorithm defined in [RFC3539] to determine server + responsiveness. The Status-Server packet defined in [RFC5997] SHOULD + be used as the "watchdog packet" in any application-layer watchdog + algorithm. + + RADIUS/DTLS clients SHOULD proactively close sessions when they have + been idle for a period of time. Clients SHOULD close a session when + the DTLS Heartbeat algorithm indicates that the session is no longer + active. Clients SHOULD close a session when no traffic other than + watchdog packets and (possibly) watchdog responses has been sent for + three watchdog timeouts. This behavior ensures that clients do not + waste resources on the server by causing it to track idle sessions. + + + + + +DeKok Experimental [Page 15] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + When a client fails to implement both DTLS Heartbeats and watchdog + packets, it has no way of knowing that a DTLS session has been + closed. Therefore, there is the possibility that the server closes + the session without the client knowing. When that happens, the + client may later transmit packets in a session, and those packets + will be ignored by the server. The client is then forced to time out + those packets and then the session, leading to delays and network + instabilities. + + For these reasons, it is RECOMMENDED that all DTLS sessions be + configured to use DTLS Heartbeats and/or watchdog packets. + + DTLS sessions MUST also be deleted when a RADIUS packet fails + validation due to a packet being malformed, or when it has an invalid + Message-Authenticator or invalid Response Authenticator. There are + other cases when the specifications require that a packet received + via a DTLS session be "silently discarded". In those cases, + implementations MAY delete the underlying DTLS session. + + RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS + packets to different servers from the same source socket. This + practice causes increased complexity in the client application and + increases the potential for security breaches due to implementation + issues. + + RADIUS/DTLS clients SHOULD implement session resumption, preferably + stateless session resumption as given in [RFC5077]. This practice + lowers the time and effort required to start a DTLS session with a + server and increases network responsiveness. + +6. Implementation Guidelines + + The text above describes the protocol. In this section, we give + additional implementation guidelines. These guidelines are not part + of the protocol, but they may help implementors create simple, + secure, and interoperable implementations. + + Where a TLS-PSK method is used, implementations MUST support keys of + at least 16 octets in length. Implementations SHOULD support key + lengths of 32 octets and SHOULD allow for longer keys. The key data + MUST be capable of being any value (0 through 255, inclusive). + Implementations MUST NOT limit themselves to using textual keys. It + is RECOMMENDED that the administration interface allow for the keys + to be entered as human-readable strings in hex format. + + + + + + + +DeKok Experimental [Page 16] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + When creating keys for use with PSK ciphersuites, it is RECOMMENDED + that keys be derived from a Cryptographically Secure Pseudorandom + Number Generator (CSPRNG) instead of administrators inventing keys on + their own. If managing keys is too complicated, a certificate-based + TLS method SHOULD be used instead. + +6.1. Client Implementations + + RADIUS/DTLS clients should use connected sockets where possible. Use + of connected sockets means that the underlying kernel tracks the + sessions, so that the client subsystem does not need to manage + multiple sessions on one socket. + + RADIUS/DTLS clients should use a single source (IP + port) when + sending packets to a particular RADIUS/DTLS server. Doing so + minimizes the number of DTLS session setups. It also ensures that + information about the home server state is discovered only once. + + In practice, this means that RADIUS/DTLS clients with multiple + internal RADIUS sources should use a local proxy that arbitrates all + RADIUS traffic between the client and all servers. The proxy should + accept traffic only from the authorized subsystems on the client + machine and should proxy that traffic to known servers. Each + authorized subsystem should include an attribute that uniquely + identifies that subsystem to the proxy, so that the proxy can apply + origin-specific proxy rules and security policies. We suggest using + NAS-Identifier for this purpose. + + The local proxy should be able to interact with multiple servers at + the same time. There is no requirement that each server have its own + unique proxy on the client, as that would be inefficient. + + The suggestion to use a local proxy means that there is only one + process that discovers network and/or connectivity issues with a + server. If each client subsystem communicated directly with a + server, issues with that server would have to be discovered + independently by each subsystem. The side effect would be increased + delays in re-routing traffic, error reporting, and network + instabilities. + + Each client subsystem can include a subsystem-specific NAS-Identifier + in each request. The format of this attribute is implementation- + specific. The proxy should verify that the request originated from + the local system, ideally via a loopback address. The proxy MUST + then rewrite any subsystem-specific NAS-Identifier to a NAS- + Identifier that identifies the client as a whole, or, remove the NAS- + Identifier entirely and replace it with NAS-IP-Address or NAS- + IPv6-Address. + + + +DeKok Experimental [Page 17] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + In traditional RADIUS, the cost to set up a new "session" between a + client and server was minimal. The client subsystem could simply + open a port, send a packet, wait for the response, and then close the + port. With RADIUS/DTLS, the connection setup is significantly more + expensive. In addition, there may be a requirement to use DTLS in + order to communicate with a server, as RADIUS/UDP may not be + supported by that server. The knowledge of what protocol to use is + best managed by a dedicated RADIUS subsystem, rather than by each + individual subsystem on the client. + +6.2. Server Implementations + + RADIUS/DTLS servers should not use connected sockets to read DTLS + packets from a client. This recommendation exists because a + connected UDP socket will accept packets only from one source IP + address and port. This limitation would prevent the server from + accepting packets from multiple clients on the same port. + +7. Diameter Considerations + + This specification defines a transport layer for RADIUS. It makes no + other changes to the RADIUS protocol. As a result, there are no + Diameter considerations. + +8. IANA Considerations + + No new RADIUS attributes or packet codes are defined. IANA has + updated the "Service Name and Transport Protocol Port Number + Registry". The entries corresponding to port service name "radsec", + port number "2083", and transport protocol "UDP" have been updated as + follows: + + o Assignee: IESG + + o Contact: IETF Chair + + o Reference: This document + + o Assignment Notes: The UDP port 2083 was already previously + assigned by IANA for "RadSec", an early implementation of + RADIUS/TLS, prior to issuance of this RFC. + +9. Implementation Status + + This section records the status of known implementations of + RADIUS/DTLS at the time of writing, and is based on a proposal + described in [RFC6982]. + + + + +DeKok Experimental [Page 18] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + The description of implementations in this section is intended to + assist the IETF in its decision processes in progressing Internet- + Drafts to RFCs. + +9.1. Radsecproxy + + Organization: Radsecproxy + + URL: https://software.uninett.no/radsecproxy/ + + Maturity: Widely used software based on early versions of this + document. + The use of the DTLS functionality is not clear. + + Coverage: The bulk of this specification is implemented, based on + earlier versions of this document. Exact revisions that + were implemented are unknown. + + Licensing: Freely distributable with acknowledgment. + + Implementation experience: No comments from implementors. + +9.2. jradius + + Organization: Coova + + URL: http://www.coova.org/JRadius/RadSec + + Maturity: Production software based on early versions of this + document. + The use of the DTLS functionality is not clear. + + Coverage: The bulk of this specification is implemented, based on + earlier versions of this document. Exact revisions that + were implemented are unknown. + + Licensing: Freely distributable with requirement to redistribute + source. + + Implementation experience: No comments from implementors. + +10. Security Considerations + + The bulk of this specification is devoted to discussing security + considerations related to RADIUS. However, we discuss a few + additional issues here. + + + + + +DeKok Experimental [Page 19] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + This specification relies on the existing DTLS, RADIUS/UDP, and + RADIUS/TLS specifications. As a result, all security considerations + for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the + TLS and RADIUS security issues discussed in [RFC6614] also apply to + this specification. Most of the security considerations for RADIUS + apply to the RADIUS portion of the specification. + + However, many security considerations raised in the RADIUS documents + are related to RADIUS encryption and authorization. Those issues are + largely mitigated when DTLS is used as a transport method. The + issues that are not mitigated by this specification are related to + the RADIUS packet format and handling, which is unchanged in this + specification. + + This specification also suggests that implementations use a session + tracking table. This table is an extension of the duplicate + detection cache mandated in [RFC5080], Section 2.2.2. The changes + given here are that DTLS-specific information is tracked for each + table entry. Section 5.1.1, above, describes steps to mitigate any + DoS issues that result from tracking additional information. + + The fixed shared secret given above in Section 2.2.1 is acceptable + only when DTLS is used with a non-null encryption method. When a + DTLS session uses a null encryption method due to misconfiguration or + implementation error, all of the RADIUS traffic will be readable by + an observer. Therefore, implementations MUST NOT use null encryption + methods for RADIUS/DTLS. + + For systems that perform protocol-based firewalling and/or filtering, + it is RECOMMENDED that they be configured to permit only DTLS over + the RADIUS/DTLS port. + +10.1. Crypto-Agility + + Section 4.2 of [RFC6421] makes a number of recommendations about + security properties of new RADIUS proposals. All of those + recommendations are satisfied by using DTLS as the transport layer. + + Section 4.3 of [RFC6421] makes a number of recommendations about + backwards compatibility with RADIUS. Section 3, above, addresses + these concerns in detail. + + Section 4.4 of [RFC6421] recommends that change control be ceded to + the IETF, and that interoperability is possible. Both requirements + are satisfied. + + + + + + +DeKok Experimental [Page 20] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + Section 4.5 of [RFC6421] requires that the new security methods apply + to all packet types. This requirement is satisfied by allowing DTLS + to be used for all RADIUS traffic. In addition, Section 3, above, + addresses concerns about documenting the transition from legacy + RADIUS to crypto-agile RADIUS. + + Section 4.6 of [RFC6421] requires automated key management. This + requirement is satisfied by using DTLS key management. + +10.2. Legacy RADIUS Security + + We reiterate here the poor security of the legacy RADIUS protocol. + We suggest that RADIUS clients and servers implement either this + specification or [RFC6614]. New attacks on MD5 have appeared over + the past few years, and there is a distinct possibility that MD5 may + be completely broken in the near future. Such a break would mean + that RADIUS/UDP was completely insecure. + + The existence of fast and cheap attacks on MD5 could result in a loss + of all network security that depends on RADIUS. Attackers could + obtain user passwords and possibly gain complete network access. We + cannot overstate the disastrous consequences of a successful attack + on RADIUS. + + We also caution implementors (especially client implementors) about + using RADIUS/DTLS. It may be tempting to use the shared secret as + the basis for a TLS-PSK method and to leave the user interface + otherwise unchanged. This practice MUST NOT be used. The + administrator MUST be given the option to use DTLS. Any shared + secret used for RADIUS/UDP MUST NOT be used for DTLS. Reusing a + shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of + the benefits found by using DTLS. + + RADIUS/DTLS client implementors MUST expose a configuration that + allows the administrator to choose the ciphersuite. Where + certificates are used, RADIUS/DTLS client implementors MUST expose a + configuration that allows an administrator to configure all + certificates necessary for certificate-based authentication. These + certificates include client, server, and root certificates. + + TLS-PSK methods are susceptible to dictionary attacks. Section 6, + above, recommends deriving TLS-PSK keys from a Cryptographically + Secure Pseudorandom Number Generator (CSPRNG), which makes dictionary + attacks significantly more difficult. Servers SHOULD track failed + client connections by TLS-PSK ID and block TLS-PSK IDs that seem to + be attempting brute-force searches of the keyspace. + + + + + +DeKok Experimental [Page 21] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + The historic RADIUS practice of using shared secrets (here, PSKs) + that are minor variations of words is NOT RECOMMENDED, as it would + negate all of the security of DTLS. + +10.3. Resource Exhaustion + + The use of DTLS allows DoS attacks and resource-exhaustion attacks + that were not possible in RADIUS/UDP. These attacks are similar to + those described in [RFC6614], Section 6, for TCP. + + Session tracking, as described in Section 5.1, can result in resource + exhaustion. Therefore, servers MUST limit the absolute number of + sessions that they track. When the total number of sessions tracked + is going to exceed the configured limit, servers MAY free up + resources by closing the session that has been idle for the longest + time. Doing so may free up idle resources that then allow the server + to accept a new session. + + Servers MUST limit the number of partially open DTLS sessions. These + limits SHOULD be exposed to the administrator as configurable + settings. + +10.4. Client-Server Authentication with DTLS + + We expect that the initial deployment of DTLS will follow the + RADIUS/UDP model of statically configured client-server + relationships. The specification for dynamic discovery of RADIUS + servers is under development, so we will not address that here. + + Static configuration of client-server relationships for RADIUS/UDP + means that a client has a fixed IP address for a server and a shared + secret used to authenticate traffic sent to that address. The server + in turn has a fixed IP address for a client and a shared secret used + to authenticate traffic from that address. This model needs to be + extended for RADIUS/DTLS. + + Instead of a shared secret, TLS credentials MUST be used by each + party to authenticate the other. The issue of identity is more + problematic. As with RADIUS/UDP, IP addresses may be used as a key + to determine the authentication credentials that a client will + present to a server or which credentials a server will accept from a + client. This is the fixed IP address model of RADIUS/UDP, with the + shared secret replaced by TLS credentials. + + + + + + + + +DeKok Experimental [Page 22] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + There are, however, additional considerations with RADIUS/DTLS. When + a client is configured with a hostname for a server, the server may + present to the client a certificate containing a hostname. The + client MUST then verify that the hostnames match. Any mismatch is a + security violation, and the connection MUST be closed. + + A RADIUS/DTLS server MAY be configured with a "wildcard" IP address + match for clients, instead of a unique fixed IP address for each + client. In that case, clients MUST be individually configured with a + unique certificate. When the server receives a connection from a + client, it MUST determine client identity from the client + certificate, and MUST authenticate (or not) the client based on that + certificate. See [RFC6614], Section 2.4, for a discussion of how to + match a certificate to a client identity. + + However, servers SHOULD use IP address filtering to minimize the + possibility of attacks. That is, they SHOULD permit clients only + from a limited IP address range or ranges. They SHOULD silently + discard all traffic from outside of those ranges. + + Since the client-server relationship is static, the authentication + credentials for that relationship must also be statically configured. + That is, a client connecting to a DTLS server SHOULD be pre- + configured with the server's credentials (e.g., PSK or certificate). + If the server fails to present the correct credentials, the DTLS + session MUST be closed. Each server SHOULD be pre-configured with + sufficient information to authenticate connecting clients. + + The requirement for clients to be individually configured with a + unique certificate can be met by using a private CA for certificates + used in RADIUS/DTLS environments. If a client were configured to use + a public CA, then it could accept as valid any server that has a + certificate signed by that CA. While the traffic would be secure + from third-party observers, the server would, however, have + unrestricted access to all of the RADIUS traffic, including all user + credentials and passwords. + + Therefore, clients SHOULD NOT be pre-configured with a list of known + public CAs by the vendor or manufacturer. Instead, the clients + SHOULD start off with an empty CA list. The addition of a CA SHOULD + be done only when manually configured by an administrator. + + + + + + + + + + +DeKok Experimental [Page 23] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + This scenario is the opposite of web browsers, where they are pre- + configured with many known CAs. The goal there is security from + third-party observers, but also the ability to communicate with any + unknown site that presents a signed certificate. In contrast, the + goal of RADIUS/DTLS is both security from third-party observers and + the ability to communicate with only a small set of well-known + servers. + + This requirement does not prevent clients from using hostnames + instead of IP addresses for locating a particular server. Instead, + it means that the credentials for that server should be pre- + configured on the client, and associated with that hostname. This + requirement does suggest that in the absence of a specification for + dynamic discovery, clients SHOULD use only those servers that have + been manually configured by an administrator. + +10.5. Network Address Translation + + Network Address Translation (NAT) is fundamentally incompatible with + RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the + shared secret for the client, and NAT hides many clients behind one + source IP address. As a result, RADIUS/UDP clients cannot be located + behind a NAT gateway. + + In addition, port reuse on a NAT gateway means that packets from + different clients may appear to come from the same source port on the + NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from + one source IP/port combination, followed by the reception of a + RADIUS/UDP packet from that same source IP/port combination. If this + behavior is allowed, then the server would have an inconsistent view + of the client's security profile, allowing an attacker to choose the + most insecure method. + + If more than one client is located behind a NAT gateway, then every + client behind the NAT MUST use a secure transport such as TLS or + DTLS. As discussed below, a method for uniquely identifying each + client MUST be used. + +10.6. Wildcard Clients + + Some RADIUS server implementations allow for "wildcard" clients -- + that is, clients with an IPv4 netmask of other than 32 or an IPv6 + netmask of other than 128. That practice is not recommended for + RADIUS/UDP, as it means multiple clients will use the same shared + secret. + + + + + + +DeKok Experimental [Page 24] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + The use of RADIUS/DTLS can allow for the safe usage of wildcards. + When RADIUS/DTLS is used with wildcards, clients MUST be uniquely + identified using TLS parameters, and any certificate or PSK used MUST + be unique to each client. + +10.7. Session Closing + + Section 5.1.1, above, requires that DTLS sessions be closed when the + transported RADIUS packets are malformed or fail the authenticator + checks. The reason is that the session is expected to be used for + transport of RADIUS packets only. + + Any non-RADIUS traffic on that session means the other party is + misbehaving and is a potential security risk. Similarly, any RADIUS + traffic failing authentication vector or Message-Authenticator + validation means that two parties do not have a common shared secret, + and the session is therefore unauthenticated and insecure. + + We wish to avoid the situation where a third party can send well- + formed RADIUS packets that cause a DTLS session to close. Therefore, + in other situations, the session SHOULD remain open in the face of + non-conformant packets. + +10.8. Client Subsystems + + Many traditional clients treat RADIUS as subsystem-specific. That + is, each subsystem on the client has its own RADIUS implementation + and configuration. These independent implementations work for simple + systems, but break down for RADIUS when multiple servers, fail-over, + and load-balancing are required. They have even worse issues when + DTLS is enabled. + + As noted in Section 6.1, above, clients SHOULD use a local proxy that + arbitrates all RADIUS traffic between the client and all servers. + This proxy will encapsulate all knowledge about servers, including + security policies, fail-over, and load-balancing. All client + subsystems SHOULD communicate with this local proxy, ideally over a + loopback address. The requirements on using strong shared secrets + still apply. + + The benefit of this configuration is that there is one place in the + client that arbitrates all RADIUS traffic. Subsystems that do not + implement DTLS can remain unaware of DTLS. DTLS sessions opened by + the proxy can remain open for long periods of time, even when client + subsystems are restarted. The proxy can do RADIUS/UDP to some + servers and RADIUS/DTLS to others. + + + + + +DeKok Experimental [Page 25] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + + Delegation of responsibilities and separation of tasks are important + security principles. By moving all RADIUS/DTLS knowledge to a DTLS- + aware proxy, security analysis becomes simpler, and enforcement of + correct security becomes easier. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and + Accounting (AAA) Transport Profile", RFC 3539, June 2003. + + [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption + without Server-Side State", RFC 5077, January 2008. + + [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication + Dial In User Service (RADIUS) Implementation Issues and + Suggested Fixes", RFC 5080, December 2007. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote + Authentication Dial In User Service (RADIUS) Protocol", + RFC 5997, August 2010. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012. + + [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport + Layer Security (TLS) and Datagram Transport Layer + Security (DTLS) Heartbeat Extension", RFC 6520, February + 2012. + + [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. + + [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, + "Transport Layer Security (TLS) Encryption for RADIUS", + RFC 6614, May 2012. + + + + +DeKok Experimental [Page 26] + +RFC 7360 DTLS as a Transport Layer for RADIUS September 2014 + + +11.2. Informative References + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC4107] Bellovin, S. and R. Housley, "Guidelines for + Cryptographic Key Management", BCP 107, RFC 4107, June + 2005. + + [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC 5176, + January 2008. + + [RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote + Authentication Dial-In User Service (RADIUS)", RFC 6421, + November 2011. + + [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of + Running Code: The Implementation Status Section", RFC + 6982, July 2013. + + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", + CryptoBytes Vol.2 No.2, Summer 1996. + + [MD5Break] Wang, X. and H. Yu, "How to Break MD5 and Other Hash + Functions", EUROCRYPT '05 Proceedings of the 24th annual + international conference on Theory and Applications of + Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4, + 2005. + +Acknowledgments + + Parts of the text in Section 3 defining the Request and Response + Authenticators were taken with minor edits from [RFC2865], Section 3. + +Author's Address + + Alan DeKok + The FreeRADIUS Server Project + URI: http://freeradius.org + EMail: aland@freeradius.org + + + + + + + +DeKok Experimental [Page 27] + -- cgit v1.2.3