Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
RFC 8559
Document | Type | RFC - Proposed Standard (April 2019) | |
---|---|---|---|
Authors | Alan DeKok , Jouni Korhonen | ||
Last updated | 2019-04-09 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Benjamin Kaduk | |
Send notices to | (None) |
RFC 8559
Network Working Group M. Bellare Request for Comments: 4344 T. Kohno Category: Standards Track UC San Diego C. Namprempre Thammasat University January 2006 The Secure Shell (SSH) Transport Layer Encryption Modes Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Table of Contents 1. Introduction ....................................................2 2. Conventions Used in This Document ...............................2 3. Rekeying ........................................................2 3.1. First Rekeying Recommendation ..............................3 3.2. Second Rekeying Recommendation .............................3 4. Encryption Modes ................................................3 5. IANA Considerations .............................................6 6. Security Considerations .........................................6 6.1. Rekeying Considerations ....................................7 6.2. Encryption Method Considerations ...........................8 Normative References ...............................................9 Informative References ............................................10 Bellare, et al. Standards Track [Page 1] RFC 4344 SSH Transport Layer Encryption Modes January 2006 1. Introduction The symmetric portion of the SSH Transport Protocol was designed to provide both privacy and integrity of encapsulated data. Researchers ([DAI,BKN1,BKN2]) have, however, identified several security problems with the symmetric portion of the SSH Transport Protocol, as described in [RFC4253]. For example, the encryption mode specified in [RFC4253] is vulnerable to a chosen-plaintext privacy attack. Additionally, if not rekeyed frequently enough, the SSH Transport Protocol may leak information about payload data. This latter property is true regardless of what encryption mode is used. In [BKN1,BKN2], Bellare, Kohno, and Namprempre show how to modify the symmetric portion of the SSH Transport Protocol so that it provably preserves privacy and integrity against chosen-plaintext, chosen- ciphertext, and reaction attacks. This document instantiates the recommendations described in [BKN1,BKN2]. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The used data types and terminology are specified in the architecture document [RFC4251]. The SSH Transport Protocol is specified in the transport document [RFC4253]. 3. Rekeying Section 9 of [RFC4253] suggests that SSH implementations rekey after every gigabyte of transmitted data. [RFC4253] does not, however, discuss all the problems that could arise if an SSH implementation does not rekey frequently enough. This section serves to strengthen the suggestion in [RFC4253] by giving firm upper bounds on the tolerable number of encryptions between rekeying operations. In Section 6, we discuss the motivation for these rekeying recommendations in more detail. This section makes two recommendations. Informally, the first recommendation is intended to protect against possible information leakage through the MAC tag, and the second recommendation is intended to protect against possible information leakage through the block cipher. Note that, depending on the block length of the Bellare, et al. Standards Track [Page 2] RFC 4344 SSH Transport Layer Encryption Modes January 2006 underlying block cipher and the length of the encrypted packets, the first recommendation may supersede the second recommendation, or vice versa. 3.1. First Rekeying Recommendation Because of possible information leakage through the MAC tag, SSH implementations SHOULD rekey at least once every 2**32 outgoing packets. More explicitly, after a key exchange, an SSH implementation SHOULD NOT send more than 2**32 packets before rekeying again. SSH implementations SHOULD also attempt to rekey before receiving more than 2**32 packets since the last rekey operation. The preferred way to do this is to rekey after receiving more than 2**31 packets since the last rekey operation. 3.2. Second Rekeying Recommendation Because of a birthday property of block ciphers and some modes of operation, implementations must be careful not to encrypt too many blocks with the same encryption key. Let L be the block length (in bits) of an SSH encryption method's block cipher (e.g., 128 for AES). If L is at least 128, then, after rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4) blocks before rekeying again. If L is at least 128, then SSH implementations should also attempt to force a rekey before receiving more than 2**(L/4) blocks. If L is less than 128 (which is the case for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, although it may be too expensive to rekey every 2**(L/4) blocks, it is still advisable for SSH implementations to follow the original recommendation in [RFC4253]: rekey at least once for every gigabyte of transmitted data. Note that if L is less than or equal to 128, then the recommendation in this subsection supersedes the recommendation in Section 3.1. If an SSH implementation uses a block cipher with a larger block size (e.g., Rijndael with 256-bit blocks), then the recommendations in Section 3.1 may supersede the recommendations in this subsection (depending on the lengths of the packets). 4. Encryption Modes This document describes new encryption methods for use with the SSH Transport Protocol. These encryption methods are in addition to the encryption methods described in Section 6.3 of [RFC4253]. Bellare, et al. Standards Track [Page 3] RFC 4344 SSH Transport Layer Encryption Modes January 2006 Recall from [RFC4253] that the encryption methods in each direction of an SSH connection MUST run independently of each other and that, when encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the chosen method. Further recall that the total length of the concatenation of the packet length, padding length, payload, and padding MUST be a multiple of the cipher's block size when the cipher's block size is greater than or equal to 8 bytes (which is the case for all of the following methods). This document describes the following new methods: aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode twofish128-ctr OPTIONAL Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr OPTIONAL Serpent in SDCTR mode, with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode, with 128-bit key The label <cipher>-ctr indicates that the block cipher <cipher> is to be used in "stateful-decryption counter" (SDCTR) mode. Let L be the block length of <cipher> in bits. In stateful-decryption counter mode, both the sender and the receiver maintain an internal L-bit counter X. The initial value of X should be the initial IV (as computed in Section 7.2 of [RFC4253]) interpreted as an L-bit unsigned integer in network-byte-order. If X=(2**L)-1, then "increment X" has the traditional semantics of "set X to 0." We use the notation <X> to mean "convert X to an L-bit string in network- byte-order." Naturally, implementations may differ in how the internal value X is stored. For example, implementations may store X as multiple unsigned 32-bit counters. To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each blocks of length L), the encryptor first encrypts <X> with <cipher> to obtain a block B1. The block B1 is then XORed with P1 to generate the ciphertext block C1. The counter X is then incremented, and the process is repeated for each subsequent block in order to generate Bellare, et al. Standards Track [Page 4] RFC 4344 SSH Transport Layer Encryption Modes January 2006 the entire ciphertext C=C1||C2||...||Cn corresponding to the packet P. Note that the counter X is not included in the ciphertext. Also note that the keystream can be pre-computed and that encryption is parallelizable. To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also maintains its own copy of X) first encrypts its copy of <X> with <cipher> to generate a block B1 and then XORs B1 to C1 to get P1. The decryptor then increments its copy of the counter X and repeats the above process for each block to obtain the plaintext packet P=P1||P2||...||Pn. As before, the keystream can be pre-computed, and decryption is parallelizable. The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes. At this time, it appears likely that a future specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged. The "aes192-ctr" method uses AES with 192-bit keys. The "aes256-ctr" method uses AES with 256-bit keys. The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt- encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). The block size is 8 bytes. This algorithm is defined in [DES]. The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER]. The block size is 8 bytes. (Note that "blowfish-cbc" from [RFC4253] uses 128-bit keys.) The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. The block size is 16 bytes. The "twofish192-ctr" method uses Twofish with 192-bit keys. The "twofish256-ctr" method uses Twofish with 256-bit keys. The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] with 128-bit keys. The block size is 16 bytes. The "serpent192-ctr" method uses Serpent with 192-bit keys. Bellare, et al. Standards Track [Page 5] RFC 4344 SSH Transport Layer Encryption Modes January 2006quot; and one or more next-hop CoA servers. When proxying CoA-Request and Disconnect-Request packets, the lookups will return data from the "CoA server" field instead of the "AAA server" field. In practice, this process means that CoA proxying works exactly like "normal" RADIUS proxying, except that the proxy decision is made using the realm from the Operator-Name attribute instead of using the realm from the User-Name attribute. Proxies that receive the CoA packet will look up the realm from the Operator-Name attribute in a logical "realm routing table", as with home servers, above. The packet is then sent to the proxy for the realm that was found in that table. This process continues with any subsequent proxies until the packet reaches a public CoA server at the visited network. Where the realm is unknown, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable"). DeKok & Korhonen Standards Track [Page 9] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 Proxies that receive a CoA packet MUST NOT use the NAI from the User-Name attribute in order to make proxying decisions. Doing so would result in the CoA packet being forwarded to the home network, while the user's session is in the visited network. We also update Section 5 of [RFC5580] to permit CoA-Request and Disconnect-Request packets to contain zero or one instance of the Operator-Name attribute. 3.3. Reception of CoA-Request and Disconnect-Request Packets After some proxying, the CoA packet will be received by the CoA server in the visited network. That CoA server MUST validate the NAI in the Operator-Name attribute against the list of realms hosted by the visited network. If the realm is not found, then the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable"). Some home networks will not have permission to send CoA packets to the visited network. The CoA server SHOULD therefore also validate the NAI contained in the User-Name attribute. If the home network is not permitted to send CoA packets to this visited network, then the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable"). These checks make it more difficult for a malicious home network to scan roaming networks in order to determine which visited network hosts which realm. That information should be known to all parties in advance and exchanged via methods outside the scope of this specification. Those methods will typically be in the form of contractual relationships between parties or membership in a roaming consortium. The CoA server in the visited network will also ensure that the Operator-NAS-Identifier attribute is known, as described below. If the attribute matches a known NAS, then the packet will be sent to that NAS. Otherwise, the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 403 ("NAS Identification Mismatch"). All other received packets are processed as per local site rules and will result in an appropriate response packet being sent. This process mirrors the method used to process Access-Request and Accounting-Request packets (described above). DeKok & Korhonen Standards Track [Page 10] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 Processing done by the visited network will normally include sending the CoA packet to the NAS, having the NAS process it, and then returning any response packets back up the proxy chain to the home server. The only missing piece here is the procedure by which the visited network gets the packet from its public CoA server to the NAS. The visited network could use NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these attributes may have been edited by an intermediate proxy or the attributes may be missing entirely. These attributes may be incorrect because proxies forwarding Access-Request packets often rewrite them for internal policy reasons. These attributes may be missing, because the visited network may not want all upstream proxies and home servers to have detailed information about the internals of its private network and may remove them itself. We therefore need a way to identify a NAS in the visited network via a method that affords privacy and does not use any existing attributes. Our solution is to define an Operator-NAS-Identifier attribute, which identifies an individual NAS in the visited network. 3.4. Operator-NAS-Identifier The Operator-NAS-Identifier attribute is an opaque token that identifies an individual NAS in a visited network. It MAY appear in the following packets: Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in any other packets. Operator-NAS-Identifier MAY occur in a packet if the packet also contains an Operator-Name attribute. Operator-NAS-Identifier MUST NOT appear in a packet if there is no Operator-Name in the packet. As each proxied CoA packet is sent to only one NAS, the Operator-NAS-Identifier attribute MUST NOT occur more than once in a packet. If a packet contains more than one Operator-NAS-Identifier, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929]. An Operator-NAS-Identifier attribute SHOULD be added to an Access-Request or Accounting-Request packet by a visited network, before proxying a packet to an external RADIUS server. When the Operator-NAS-Identifier attribute is added to a packet, the following attributes SHOULD be deleted from the packet: NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier. If these attributes are deleted, the proxy MUST then add a new NAS-Identifier attribute, DeKok & Korhonen Standards Track [Page 11] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 in order to satisfy the requirements of Section 4.1 of [RFC2865] and Section 4.1 of [RFC2866]. The contents of the new NAS-Identifier attribute SHOULD be the realm name of the visited network. When a server receives a packet that already contains an Operator- NAS-Identifier attribute, no such editing is performed. The Operator-NAS-Identifier attribute MUST NOT be added to any packet by any other proxy or server in the network. Only the visited network (i.e., the operator) can name a NAS that is inside of the visited network. The result of these requirements is that for everyone outside of the visited network there is only one NAS: the visited network itself. Also, the visited network is able to identify its own NASes to its own satisfaction. This usage of the Operator-NAS-Identifier attribute parallels the Operator-Name attribute as defined in Section 4.1 of [RFC5580]. The Operator-NAS-Identifier attribute is defined as follows. Description An opaque token describing the NAS a user has logged into. Type 241.8 (assigned by IANA from the "short extended space" [RFC6929] of the "RADIUS Attribute Types" registry). Length 4 to 35. Implementations supporting this attribute MUST be able to handle between one (1) and thirty-two (32) octets of data. Implementations creating an Operator-NAS-Identifier attribute MUST NOT create attributes with more than sixty-four (64) octets of data. A 32-octet string should be more than sufficient for future uses. Data Type The data type of this field is "string". See Section 3.5 of [RFC8044] for a definition. DeKok & Korhonen Standards Track [Page 12] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 Value This attribute contains an opaque token that can only be interpreted by the visited network. This token MUST allow the visited network to direct the packet to the NAS for the user's session. In practice, this requirement means that the visited network has two practical methods for creating the value. The first method is to create an opaque token per NAS and then to store that information in a database. The database can be configured to allow querying by NAS IP address in order to find the correct Operator-NAS-Identifier. The database can also be configured to allow querying by Operator-NAS-Identifier in order to find the correct NAS IP address. The second method is to obfuscate the NAS IP address using information known locally by the visited network -- for example, by XORing it with a locally known secret key. The output of that obfuscation operation is data that can be used as the value of Operator-NAS-Identifier. On reception of a CoA packet, the locally known information can be used to unobfuscate the value of Operator-NAS-Identifier, in order to determine the actual NAS IP address. Note that there is no requirement that the value of Operator-NAS- Identifier be checked for integrity. Modification of the value can only result in the erroneous transaction being rejected. We note that the Access-Request and Accounting-Request packets often contain the Media Access Control (MAC) address of the NAS. There is therefore no requirement that Operator-NAS-Identifier obfuscate or hide in any way the total number of NASes in a visited network. That information is already public knowledge. DeKok & Korhonen Standards Track [Page 13] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 4. Requirements 4.1. Requirements on Home Servers The Operator-NAS-Identifier attribute MUST be stored by a home server along with any user session identification attributes. When sending a CoA packet for a user session, the home server MUST include verbatim any Operator-NAS-Identifier it has recorded for that session. A home server MUST NOT send CoA packets for users of other networks. The next few sections describe how other participants in the RADIUS ecosystem can help enforce this requirement. 4.2. Requirements on Visited Networks A visited network that receives a CoA packet that will be proxied to a NAS MUST perform all of the operations required for proxies; see Section 4.3.2. We specify this requirement because we assume that the visited network has a proxy between the NAS and any external (i.e., third-party) proxy. Situations where a NAS sends packets directly to a third-party RADIUS server are outside the scope of this specification. The visited network uses the contents of the Operator-NAS-Identifier attribute to determine which NAS will receive the packet. The visited network MUST remove the Operator-Name and Operator-NAS- Identifier attributes from a given CoA packet prior to sending that packet to the final CoA server (i.e., NAS). This step is necessary due to the limits specified in Section 2.3 of [RFC5176]. The visited network MUST also ensure that the CoA packet sent to the NAS contains one of the following attributes: NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier. This step is the inverse of the removal suggested above in Section 3.4. In general, the NAS should only receive attributes that identify or modify a user's session. It is not appropriate to send to a NAS attributes that are used only for inter-proxy signaling. 4.3. Requirements on Proxies There are a number of requirements on both CoA proxies and RADIUS proxies. For the purpose of this section, we assume that each RADIUS proxy shares a common administration with a corresponding CoA proxy and that the two systems can communicate electronically. There is no requirement that these systems be co-located. DeKok & Korhonen Standards Track [Page 14] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 4.3.1. Security Requirements on Proxies Section 6.1 of [RFC5176] has some security requirements on proxies that handle CoA-Request and Disconnect-Request packets: ... a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client. We strengthen that requirement by saying that a proxy MUST perform a reverse path forwarding check to verify that a CoA packet originates from an authorized Dynamic Authorization Client. Without this check, a proxy may forward packets from misconfigured or malicious parties and thus contribute to the problem instead of preventing it. Where the check fails, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable"). Proxies that record user session information SHOULD verify the contents of a received CoA packet against the recorded data for that user session. If the proxy determines that the information in the packet does not match the recorded user session, it SHOULD return a NAK packet that contains an Error-Cause Attribute having value 503 ("Session Context Not Found"). These checks cannot be mandated due to the fact that [RFC5176] offers no advice on which attributes are used to identify a user's session. Because a RADIUS proxy will see Access-Request and Accounting-Request packets, we recognize that it will have sufficient information to forge CoA packets. The RADIUS proxy will thus have the ability to subsequently disconnect any user who was authenticated through itself. We suggest that the real-world effect of this security problem is minimal. RADIUS proxies can already return Access-Accept or Access-Reject for Access-Request packets and can change authorization attributes contained in an Access-Accept. Allowing a proxy to change (or disconnect) a user session post-authentication is not substantially different from changing (or refusing to connect) a user session during the initial process of authentication. The biggest problem is that there are no provisions in RADIUS for "end-to-end" security. That is, the visited network and home network cannot communicate privately in the presence of proxies. This limitation originates from the design of RADIUS for Access-Request and Accounting-Request packets. That limitation is then carried over to CoA-Request and Disconnect-Request packets. DeKok & Korhonen Standards Track [Page 15] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 We therefore cannot prevent proxies or home servers from forging CoA packets. We can only create scenarios where that forgery is hard to perform, is likely to be detected, and/or has no effect. 4.3.2. Filtering Requirements on Proxies Section 2.3 of [RFC5176] makes the following requirement for CoA servers: In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory. This requirement is too stringent for a CoA proxy. Only the final CoA server (i.e., NAS) can decide which attributes are mandatory and which are not. Instead, in the case of a CoA proxy, we say that all attributes MUST NOT be treated as mandatory. Proxies implementing this specification MUST perform proxying based on Operator-Name. Other schemes are possible but are not discussed here. Proxies SHOULD forward all packets either "as is" or with minimal changes. We note that some NAS implementations currently treat signaling attributes as mandatory. For example, some NAS implementations will NAK any CoA packet that contains a Proxy-State attribute. While this behavior is based on a straightforward reading of the above text, it causes problems in practice. We update Section 2.3 of [RFC5176] as follows: in CoA-Request and Disconnect-Request packets, the NAS MUST NOT treat as mandatory any attribute that is known to not affect the user's session -- for example, the Proxy-State attribute. Proxy-State is an attribute used for proxy-to-proxy signaling. It cannot affect the user's session, and therefore Proxy-State (and similar attributes) MUST be ignored by the NAS. When Operator-Name and/or Operator-NAS-Identifier are received by a proxy, the proxy MUST pass those attributes through unchanged. This requirement applies to all proxies, including proxies that forward any or all of Access-Request, Accounting-Request, CoA-Request, and Disconnect-Request packets. All attributes added by a RADIUS proxy when sending packets from the visited network to the home network MUST be removed by the corresponding CoA proxy from packets traversing the reverse path. That is, any editing of attributes that is done on the "forward" path MUST be undone on the "reverse" path. DeKok & Korhonen Standards Track [Page 16] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 The result is that a NAS will only ever receive CoA packets that either contain (1) attributes sent by the NAS to its local RADIUS server or (2) attributes that are sent by the home server in order to perform a change of authorization. Finally, we extend the above requirement not only to Operator-Name and Operator-NAS-Identifier but also to any future attributes that are added for proxy-to-proxy signaling. 5. Functionality This section describes how the two attributes work together to permit CoA proxying. 5.1. User Login In this scenario, we follow a roaming user who is attempting to log in to a visited network. The login attempt is done via a NAS in the visited network. That NAS will send an Access-Request packet to the visited RADIUS server. The visited RADIUS server will see that the user is roaming and will add an Operator-Name attribute, with value "1" followed by its own realm name, e.g., "1example.com". The visited RADIUS server MAY also add an Operator-NAS-Identifier attribute. The NAS identification attributes are also edited, as required by Section 3.4, above. The visited server will then proxy the authentication request to an upstream server. That server may be the home server, or it may be a proxy. In the case of a proxy, the proxy will forward the packet until the packet reaches the home server. The home server will record the Operator-Name and Operator-NAS- Identifier attributes, along with other information about the user's session, if those attributes are present in a packet. 5.2. CoA Proxying At some later point in time, the home server determines that (1) a user session should have its authorization changed or (2) the user should be disconnected. The home server looks up the Operator-Name and Operator-NAS-Identifier attributes, along with other user session identifiers as described in [RFC5176]. The home server then looks up the realm from the Operator-Name attribute in the logical AAA routing table, in order to find the next-hop CoA server for that realm (which may be a proxy). The CoA-Request is then sent to that CoA server. DeKok & Korhonen Standards Track [Page 17] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 The CoA server receives the request and, if it is a proxy, performs a lookup similar to the lookup done by the home server. The packet is then proxied repeatedly until it reaches the visited network. If the proxy cannot find a destination for the request or if no Operator-Name attribute exists in the request, the proxy will return a CoA-NAK with Error-Cause 502 ("Request Not Routable"). The visited network will receive the CoA-Request packet and will use the Operator-NAS-Identifier attribute (if available) to determine which local CoA server (i.e., NAS) the packet should be sent to. If there is no Operator-NAS-Identifier attribute, the visited network may use other means to locate the NAS, such as consulting a local database that tracks user sessions. The Operator-Name and Operator-NAS-Identifier attributes are then removed from the packet; one of NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier is added to the packet; and the packet is then sent to the CoA server. If no CoA server can be found, the visited network returns a CoA-NAK with Error-Cause 403 ("NAS Identification Mismatch"). Any response from the CoA server (NAS) is returned to the home network via the normal method of returning responses to requests. 6. Security Considerations This specification incorporates by reference Section 11 of [RFC6929]. In short, RADIUS has many known issues; those issues are discussed in detail in [RFC6929] and do not need to be repeated here. This specification adds one new attribute and defines new behavior for RADIUS proxying. As this behavior mirrors existing RADIUS proxying, we do not believe that it introduces any new security issues. We note, however, that RADIUS proxying has many inherent security issues. 6.1. RADIUS Security and Proxies The requirement that packets be signed with a shared secret means that a CoA packet can only be received from a trusted party or, transitively, received from a third party via a trusted party. This security provision of the base RADIUS protocol makes it impossible for untrusted parties to affect the user's session. DeKok & Korhonen Standards Track [Page 18] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 When RADIUS proxying is performed, all packets are signed on a hop-by-hop basis. Any intermediate proxy can therefore forge packets, replay packets, or modify the contents of any packet. Any system receiving correctly signed packets must accept them at face value and is unable to detect any forgery, replay, or modifications. As a result, the secure operation of such a system depends largely on trust instead of on technical means. CoA packet proxying has all of the same issues as those noted above. We note that the proxies that see and can modify CoA packets are generally the same proxies that can see or modify Access-Request and Accounting-Request packets. As such, there are few additional security implications in allowing CoA proxying. The main security implication that remains is that home networks now have the ability to disconnect or change the authorization of users in a visited network. As this capability is only enabled when mutual agreement is in place, and only for those parties who can already control user sessions, there are no new security issues with this specification. 6.2. Security of the Operator-NAS-Identifier Attribute Nothing in this specification depends on the security of the Operator-NAS-Identifier attribute. The entire process would work exactly the same if the Operator-NAS-Identifier attribute simply contained the NAS IP address that is hosting the user's session. The only real downside in that situation would be that external parties would see some additional private information about the visited network. They would still, however, be unable to leverage that information to do anything malicious. The main reason to use an opaque token for the Operator-NAS- Identifier attribute is that there is no compelling reason to make the information public. We therefore recommend that the value be simply an opaque token. We also state that there is no requirement for integrity protection or replay detection of this attribute. The rest of the RADIUS protocol ensures that modification or replay of the Operator-NAS-Identifier attribute will either have no effect or have the same effect as if the value had not been modified. Trusted parties can modify a user's session on the NAS only when they have sufficient information to identify that session. In practice, this limitation means that those parties already have access to the user's session information. In other words, those parties are the proxies who are already forwarding Access-Request and Accounting- Request packets. DeKok & Korhonen Standards Track [Page 19] The "serpent256-ctr" method uses Serpent with 256-bit keys. The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block size is 8 bytes. The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys [RFC2144]. The block size is 8 bytes. 5. IANA Considerations The thirteen encryption algorithm names defined in Section 4 have been added to the Secure Shell Encryption Algorithm Name registry established by Section 4.11.1 of [RFC4250]. 6. Security Considerations This document describes additional encryption methods and recommendations for the SSH Transport Protocol [RFC4253]. [BKN1,BKN2] prove that if an SSH application incorporates the methods and recommendations described in this document, then the symmetric cryptographic portion of that application will resist a large class of privacy and integrity attacks. This section is designed to help implementors understand the security-related motivations for, as well as possible consequences of deviating from, the methods and recommendations described in this document. Additional motivation and discussion, as well as proofs of security, appear in the research papers [BKN1,BKN2]. Please note that the notion of "prove" in the context of [BKN1,BKN2] is that of practice-oriented reductionist security: if an attacker is able to break the symmetric portion of the SSH Transport Protocol using a certain type of attack (e.g., a chosen-ciphertext attack), then the attacker will also be able to break one of the transport protocol's underlying components (e.g., the underlying block cipher or MAC). If we make the reasonable assumption that the underlying components (such as AES and HMAC-SHA1) are secure, then the attacker against the symmetric portion of the SSH protocol cannot be very successful (since otherwise there would be a contradiction). Please see [BKN1,BKN2] for details. In particular, attacks are not impossible, just extremely improbable (unless the building blocks, like AES, are insecure). Note also that cryptography often plays only a small (but critical) role in an application's overall security. In the case of the SSH Transport Protocol, even though an application might implement the symmetric portion of the SSH protocol exactly as described in this document, the application may still be vulnerable to non-protocol- Bellare, et al. Standards Track [Page 6] RFC 4344 SSH Transport Layer Encryption Modes January 2006 based attacks (as an egregious example, an application might save cryptographic keys in cleartext to an unprotected file). Consequently, even though the methods described herein come with proofs of security, developers must still execute caution when developing applications that implement these methods. 6.1. Rekeying Considerations Section 3 of this document makes two rekeying recommendations: (1) rekey at least once every 2**32 packets, and (2) rekey after a certain number of encrypted blocks (e.g., 2**(L/4) blocks if the block cipher's block length L is at least 128 bits). The motivations for recommendations (1) and (2) are different, and we consider each recommendation in turn. Briefly, (1) is designed to protect against information leakage through the SSH protocol's underlying MAC, and (2) is designed to protect against information leakage through the SSH protocol's underlying encryption scheme. Please note that, depending on the encryption method's block length L and the number of blocks encrypted per packet, recommendation (1) may supersede recommendation (2) or vice versa. Recommendation (1) states that SSH implementations should rekey at least once every 2**32 packets. If more than 2**32 packets are encrypted and MACed by the SSH Transport Protocol between rekeyings, then the SSH Transport Protocol may become vulnerable to replay and re-ordering attacks. This means that an adversary may be able to convince the receiver to accept the same message more than once or to accept messages out of order. Additionally, the underlying MAC may begin to leak information about the protocol's payload data. In more detail, an adversary looks for a collision between the MACs associated to two packets that were MACed with the same 32-bit sequence number (see Section 4.4 of [RFC4253]). If a collision is found, then the payload data associated with those two ciphertexts is probably identical. Note that this problem occurs regardless of how secure the underlying encryption method is. Also note that although compressing payload data before encrypting and MACing and the use of random padding may reduce the risk of information leakage through the underlying MAC, compression and the use of random padding will not prevent information leakage. Implementors who decide not to rekey at least once every 2**32 packets should understand these issues. These issues are discussed further in [BKN1,BKN2]. One alternative to recommendation (1) would be to make the SSH Transport Protocol's sequence number more than 32 bits long. This document does not suggest increasing the length of the sequence number because doing so could hinder interoperability with older versions of the SSH protocol. Another alternative to recommendation (1) would be to switch from basic HMAC to a another MAC, such as a Bellare, et al. Standards Track [Page 7] RFC 4344 SSH Transport Layer Encryption Modes January 2006 MAC that has its own internal counter. Because of the 32-bit counter already present in the protocol, such a counter would only need to be incremented once every 2**32 packets. Recommendation (2) states that SSH implementations should rekey before encrypting more than 2**(L/4) blocks with the same key (assuming L is at least 128). This recommendation is designed to minimize the risk of birthday attacks against the encryption method's underlying block cipher. For example, there is a theoretical privacy attack against stateful-decryption counter mode if an adversary is allowed to encrypt approximately 2**(L/2) messages with the same key. It is because of these birthday attacks that implementors are highly encouraged to use secure block ciphers with large block lengths. Additionally, recommendation (2) is designed to protect an encryptor from encrypting more than 2**L blocks with the same key. The motivation here is that, if an encryptor were to use SDCTR mode to encrypt more than 2**L blocks with the same key, then the encryptor would reuse keystream, and the reuse of keystream can lead to serious privacy attacks [SCHNEIER]. 6.2. Encryption Method Considerations Researchers have shown that the original CBC-based encryption methods in [RFC4253] are vulnerable to chosen-plaintext privacy attacks [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption methods described in Section 4 of this document were designed to be secure replacements to the original encryption methods described in [RFC4253]. Many people shy away from counter mode-based encryption schemes because, when used incorrectly (such as when the keystream is allowed to repeat), counter mode can be very insecure. Fortunately, the common concerns with counter mode do not apply to SSH because of the rekeying recommendations and because of the additional protection provided by the transport protocol's MAC. This discussion is formalized with proofs of security in [BKN1,BKN2]. As an additional note, when one of the stateful-decryption counter mode encryption methods (Section 4) is used, then the padding included in an SSH packet (Section 4 of [RFC4253]) need not be (but can still be) random. This eliminates the need to generate cryptographically secure pseudorandom bytes for each packet. One property of counter mode encryption is that it does not require that messages be padded to a multiple of the block cipher's block length. Although not padding messages can reduce the protocol's network consumption, this document requires that padding be a multiple of the block cipher's block length in order to (1) not alter Bellare, et al. Standards Track [Page 8] RFC 4344 SSH Transport Layer Encryption Modes January 2006 the packet description in [RFC4253] and (2) not leak precise information about the length of the packet's payload data. (Although there may be some network savings from padding to only 8-bytes even if the block cipher uses 16-byte blocks, because of (1) we do not make that recommendation here.) In addition to stateful-decryption counter mode, [BKN1,BKN2] describe other provably secure encryption methods for use with the SSH Transport Protocol. The stateful-decryption counter mode methods in Section 4 are, however, the preferred alternatives to the insecure methods in [RFC4253] because stateful-decryption counter mode is the most efficient (in terms of both network consumption and the number of required cryptographic operations per packet). Normative References [AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001. [DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standards Publication 46-3, October 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: Protocols algorithms and source in code in C", Wiley, 1996. [SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998. Bellare, et al. Standards Track [Page 9] RFC 4344 SSH Transport Layer Encryption Modes January 2006 [TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999. Informative References [BKN1] Bellare, M., Kohno, T., and Namprempre, C., "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol", Ninth ACM Conference on Computer and Communications Security, 2002. [BKN2] Bellare, M., Kohno, T., and Namprempre, C., "Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm", ACM Transactions on Information and System Security, 7(2), May 2004. [DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to the ietf-ssh@netbsd.org email list, 2002. Bellare, et al. Standards Track [Page 10] RFC 4344 SSH Transport Layer Encryption Modes January 2006 Authors' Addresses Mihir Bellare Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404 Phone: +1 858-534-8833 EMail: mihir@cs.ucsd.edu Tadayoshi Kohno Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404 Phone: +1 858-534-8833 EMail: tkohno@cs.ucsd.edu Chanathip Namprempre Thammasat University Faculty of Engineering Electrical Engineering Department Rangsit Campus, Klong Luang Pathumthani, Thailand 12121 EMail: meaw@alum.mit.edu Bellare, et al. Standards Track [Page 11] RFC 4344 SSH Transport Layer Encryption Modes January 2006 RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 Since those parties already have the ability to see and modify all of the information about a user's session, there is no additional security issue with allowing them to see and modify CoA packets. In short, any security issues with the contents of Operator-NAS- Identifier are largely limited by the security of the underlying RADIUS protocol. This limitation means that it does not matter how the values of Operator-NAS-Identifier are created, stored, or used. 7. IANA Considerations Per Section 3.4 of this document, IANA has allocated one new RADIUS attribute (the Operator-NAS-Identifier attribute) from the "short extended space" of the "RADIUS Attribute Types" registry as follows: Value: 241.8 Description: Operator-NAS-Identifier Data Type: string Reference: RFC 8559 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, <https://www.rfc-editor.org/info/rfc5080>. [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, DOI 10.17487/RFC5176, January 2008, <https://www.rfc-editor.org/info/rfc5176>. DeKok & Korhonen Standards Track [Page 20] RFC 8559 Dynamic Authorization Proxying in RADIUS April 2019 [RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, <https://www.rfc-editor.org/info/rfc5580>. [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <https://www.rfc-editor.org/info/rfc6929>. [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>. [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, January 2017, <https://www.rfc-editor.org/info/rfc8044>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 8.2. Informative References [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>. Authors' Addresses Alan DeKok The FreeRADIUS Server Project Email: aland@freeradius.org Jouni Korhonen Email: jouni.nospam@gmail.com DeKok & Korhonen Standards Track [Page 21]