In a replay attack, the attacker obtains a valid ARID in some way and uses the ARID to spoof user attributes to a relying party, or to retrieve user attributes from the AVS. A replay attack potentially occurs from a compromised intermediary along the signaling or message path, such as an HTTP or SIP proxy server or an SMTP server. We first de- scribe countermeasures to replay attacks from outsiders, and then analyze the vulnerability to replay attacks from compromised or malicious intermediaries. Another form of replay attacks occurs from a legitimate relying party by using a received ARID, as described in Section8.3.1.
8.6.2.1 Replay Attacks from Outsiders
To prevent unauthorized retrieval of user attributes using a stolen ARID, the AVS must restrict relying parties who can use a specific ARID based on the information the principal specifies (an ARID access code). The information is HMAC over the SIP AoR or email address of a relying party; thus, SIP UAs or email clients must support HMAC-SHA1.
If an ARID is stolen with the information, for example, a validation request itself is captured in some way, the user attributes corresponding to the ARID can be fetched by anyone. To mitigate this unauthorized access to user attributes, the AVS must limit an ARID’s lifetime to a short time period. The AVS may also limit the number of times it can be resolved. However, while limiting the use times of an ARID strengthens security, it may reduce the degree of applicability to email, especially in the following scenario. An ARID cannot be used for validating user attributes when a principal specifies a single relying party in a message, but the message is copied to multiple destinations, for example, using a forking proxy at the recipient side or using a listing service. Thus, this limitation on the use times of an ARID is recommended only for a communication service which needs the long lifetime of an ARID, such as email.
To detect posing user attributes using a stolen ARID in a communication request, a relying party may collect received ARIDs until their lifetime end. When receiving an ARID in a new communication request, a relying party sees if the same ARID exists in previously received ARIDs.
8.6.2.2 Replay Attacks from Intermediaries
An HTTP proxy server often exists between a principal and the AVS and between the relying party and the AVS. SIP proxy servers or email servers usually exist between the principal and a relying party depending on the communication means. If these intermediaries include a malicious or compromised server, the attacker can exploit the information stored on the server for replay attacks. However, a malicious server is rarely involved in the signaling path using HTTP, SIP, or email protocols, if each entity configures its application settings to connect only to a trust proxy server using TLS, and carefully authenticates the server using its X.509 PKC. Therefore, for each signaling path, we analyze the potential damage by replay attacks mainly from compromised intermediares and from malicious ones on the condition in which server authentication is not properly done.
To prevent man in the middle attacks described in Section 8.6.1, these HTTP proxy servers are supposed to transmit messages protected with an end-to-end TLS connection without terminating and restarting a secure TLS connection. If a principal neglects to authenticate an X.509 PKC of the AVS, the HTTP proxy server can intercept a response including an ARID from the AVS. However, this ARID alone is insufficient for the attacker to impersonate user attributes to a relying party or to retrieve user attributes from the AVS. If a relying party neglects to authenticate an X.509 PKC of the AVS, the HTTP proxy server can intercept a request carrying full information for retrieving user attributes. A short lifetime of an ARID and its limited use time, if enabled, can reduce the effect of replay attacks using this request for retrieving user attributes.
Similarly, SIP proxy servers or email servers also are supposed to use TLS, but they do not allow TLS tunneling to provide its communication service by dealing with the message headers of a communication request. Thus, the attacker can obtain a message including an ARID from a compromised server. However, to exploit the ARID for replay attacks on the AVS, the attacker needs the same processes as a relying party does in order to form an HTTP GET request. The processes include parsing two header fields of To and Sender- Reference and generating HMAC over the destination address with the secret found in these header fields. Although the computational costs of parsing and generating HMAC are not expensive, they are expensive than the cost of copy and replay. Combined with a short
lifetime of an ARID, this additional required process can reduce the effect of replay attacks using a captured communication request.
To detect replay attacks at a relying party, the relying party needs to test whether an ARID is new or has been used before (within the lifetime of an ARID), relying on collected received ARIDs, and also relying on the countermeasures (limiting the lifetime of an ARID) implemented on the AVS. If an intermediary wrongly modifies with message headers before forwarding a message (e.g., swapping a set of the To and Sender-References header fields of a message with others), a relying party cannot detect that. In that case, however, the communication service itself is also disrupted.
8.6.2.3 Replay Attacks from Relying Party Using a Received ARID
Any legitimate relying party of an ARID can attempt to impersonate the principal of the ARID just by sending the ARID to another user since this mechanism does not have a tight link between the username of AVS and the caller ID, as described in Section8.3.2, nor a link between the signaling path and the ARID. As described in Section 8.3.1, to mitigate this attack, a relying party need to generate an ARID access code, the hash of his CEID (i.e., SIP AoR or email address) and the secret in the communication request. This is one of the countermeasures as preventing replay attacks from outsiders, as described in Section8.6.2.1. When it comes to this service applied to email and instant messaging where a message is copied and shared by multiple recipients, the attacker can easily pick another recipient of the received message and reuse the received ARID when sending a new message to the recipient.
To mitigate this form of forwarding attacks, the AVS and a relying party need to rely on the same countermeasures, as preventing replay attacks from outsiders, as described in Section8.6.2.1. These countermeasures include, limiting relying parties to whom have been authorized by the principal, limiting the lifetime of an ARID to a short time period and limiting the use time of an ARID to one per relying party. Furthermore, they include that each relying party collects ARIDs that have been received until their lifetime ends. As the lifetime of an ARID is set longer to be adjusted to asynchronous services such as email, the countermeasures become more costly and less effective.