Hubbry Logo
Challenge-Handshake Authentication ProtocolChallenge-Handshake Authentication ProtocolMain
Open search
Challenge-Handshake Authentication Protocol
Community hub
Challenge-Handshake Authentication Protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Challenge-Handshake Authentication Protocol
Challenge-Handshake Authentication Protocol
Challenge-Handshake Authentication Protocol
View on Wikipedia
from Wikipedia

In computing, the Challenge-Handshake Authentication Protocol (CHAP) is an authentication protocol originally used by Point-to-Point Protocol (PPP) to validate users. CHAP is also carried in other authentication protocols such as RADIUS and Diameter.

Almost all network operating systems support PPP with CHAP, as do most network access servers. CHAP is also used in PPPoE, for authenticating DSL users.

As the PPP sends data unencrypted and "in the clear", CHAP is vulnerable to any attacker who can observe the PPP session. An attacker can see the user's name, CHAP challenge, CHAP response, and any other information associated with the PPP session. The attacker can then mount an offline dictionary attack in order to obtain the original password. When used in PPP, CHAP also provides protection against replay attacks by the peer through the use of a challenge which is generated by the authenticator, which is typically a network access server.

Where CHAP is used in other protocols, it may be sent in the clear, or it may be protected by a security layer such as Transport Layer Security (TLS). For example, when CHAP is sent over RADIUS using User Datagram Protocol (UDP), any attacker who can see the RADIUS packets can mount an offline dictionary attack, as with PPP.

CHAP requires that both the client and server know the clear-text version of the password, although the password itself is never sent over the network. Thus when used in PPP, CHAP provides better security as compared to Password Authentication Protocol (PAP) which is vulnerable for both these reasons.

Benefits of CHAP

[edit]

When the peer sends CHAP, the authentication server will receive it, and obtain the "known good" password from a database, and perform the CHAP calculations. If the resulting hashes match, then the user is deemed to be authenticated. If the hashes do not match, then the user's authentication attempt is rejected.

Since the authentication server has to store the password in clear-text, it is impossible to use different formats for the stored password. If an attacker were to steal the entire database of passwords, all of those passwords would be visible "in the clear" in the database.

As a result, while CHAP can be more secure than PAP when used over a PPP link, it prevents more secure storage "at rest" than with other methods such as PAP.

Variants

[edit]

MS-CHAP is similar to CHAP but uses a different hash algorithm, and allows for each party to authenticate the other.

Working cycle

[edit]

CHAP is an authentication scheme originally used by Point-to-Point Protocol (PPP) servers to validate the identity of remote clients. CHAP periodically verifies the identity of the client by using a three-way handshake. This happens at the time of establishing the initial link (LCP), and may happen again at any time afterwards. The verification is based on a shared secret (such as the client's password).[1]

  1. After the completion of the link establishment phase, the authenticator sends a "challenge" message to the peer.
  2. The peer responds with a value calculated using a one-way hash function on the challenge and the secret combined.
  3. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authenticator acknowledges the authentication; otherwise it should terminate the connection.
  4. In PPP, the authenticator may send a new challenge at random intervals to the peer and repeats steps 1 through 3. However, when CHAP is used in most situations (e.g. RADIUS), this step is not performed.

CHAP packets

[edit]
Description 1 byte 1 byte 2 bytes 1 byte Variable Variable
Challenge Code = 1 ID Length Challenge length Challenge value Name
Response Code = 2 ID Length Response length Response value Name
Success Code = 3 ID Length Message
Failure Code = 4 ID Length Message

The ID chosen for the random challenge is also used in the corresponding response, success, and failure packets. A new challenge with a new ID must be different from the last challenge with another ID. If the success or failure is lost, the same response can be sent again, and it triggers the same success or failure indication. For MD5 as hash the response value is MD5(ID||secret||challenge), the MD5 for the concatenation of ID, secret, and challenge.[2]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Challenge-Handshake Authentication Protocol

View on Grokipedia
from Grokipedia
The Challenge-Handshake Authentication Protocol (CHAP) is a cryptographic method defined for use within the (PPP) to verify the identity of communicating peers through a three-way process involving a server-issued challenge and a client response based on a hashed with the challenge value. This protocol, specified in RFC 1994 (August 1996), enables initial upon link establishment and supports optional periodic re-verification to maintain session without transmitting the plaintext secret over the network. In operation, the authenticator generates a unique, random challenge packet containing an identifier and the challenge string, which it sends to the peer. The peer then computes a response by applying a one-way —typically —to a of the identifier, its , and the challenge, before sending this hashed value back in a response packet. Upon verification against its own computation using the peer's known secret, the authenticator issues a success or failure packet, allowing if negotiated bidirectionally. This mechanism obsoletes earlier proposals in RFC 1334 and provides protection against replay attacks through the use of unpredictable challenges. CHAP offers significant security advantages over the simpler (PAP) by avoiding the transmission of unencrypted credentials and instead relying on cryptographic hashing to obscure the . However, it requires both parties to maintain the secret in form for hashing, which limits compatibility with encrypted credential stores, and its reliance on has drawn modern scrutiny due to known vulnerabilities in that algorithm, though variants like MS-CHAPv2 provide with hashing based on MD4 and , which have their own known vulnerabilities. Primarily employed in PPP-based connections for dial-up, VPN, and access scenarios, CHAP remains a foundational protocol for secure remote , with implementations in network devices from vendors like and ongoing relevance in legacy and hybrid systems despite the rise of more advanced methods like EAP.

Introduction

Definition and Purpose

The Challenge-Handshake Authentication Protocol (CHAP) is a challenge-response designed for use within the (PPP) framework to securely verify the identity of communicating peers. It operates as part of PPP's optional Authentication phase, which is negotiated during the link establishment process to enable multi-protocol transport over point-to-point links. CHAP employs a three-way mechanism to authenticate peers without requiring the transmission of passwords or credentials over the network, thereby enhancing in environments such as dial-up connections and other PPP-based network setups. The primary purpose of CHAP is to confirm the legitimacy of a peer's identity both at the initial establishment of a PPP link and at periodic intervals thereafter, mitigating risks of unauthorized access and . By challenging the peer with a unique value and expecting a response derived from a , CHAP ensures that only entities possessing the correct secret can successfully authenticate, without exposing sensitive information to interception. This approach was developed specifically for PPP to supplant less secure authentication methods like the (PAP), providing a more robust alternative for one-way or in insecure transmission media. At its core, CHAP involves an (typically the access server) generating and sending a random challenge to the peer, which then computes a cryptographic response using the challenge, an identifier, and a pre-shared secret known only to both parties. The verifies this response against its own computation of the expected value, completing the without the secret ever traversing the link. This key component structure supports ongoing re-authentication at irregular intervals post-link establishment, maintaining session integrity over time.

Historical Development

The Challenge-Handshake Authentication Protocol (CHAP) emerged in the early 1990s as an enhancement to the (PPP), addressing the growing need for secure authentication in dial-up internet services and point-to-point serial links. PPP itself was initially proposed in RFC 1134 in November 1989 by Drew Perkins, which outlined a framework for multi-protocol datagram transmission but reserved space for authentication mechanisms without specifying details. As internet connectivity expanded through modems and leased lines, the demand for robust peer verification prompted the development of authentication options within PPP's Link Control Protocol phase. Key milestones in CHAP's specification occurred through Internet Engineering Task Force (IETF) documents. In October 1992, RFC 1334 introduced CHAP alongside the Password Authentication Protocol (PAP) as optional PPP authentication protocols, describing a basic three-way handshake to verify peer identity using hashed responses to random challenges, thereby improving upon the simpler, less secure methods in early PPP drafts. This was further refined and formalized in August 1996 with RFC 1994, which obsoleted the authentication details in RFC 1334 and provided a comprehensive definition of CHAP's mechanics, including its use of MD5 hashing for response generation and support for periodic re-authentication. These specifications established CHAP as a standard for PPP links, emphasizing protection against replay attacks in environments like switched circuits. CHAP was developed under the auspices of the IETF's Extensions (pppext) Working Group, which focused on extending PPP capabilities to meet evolving networking requirements in the post-SLIP era. By the mid-, CHAP saw widespread implementation in modems, routers, and network access servers to secure remote connections, particularly for (ISP) dial-up services. Its integration into major operating systems, including and various Unix variants, accelerated by the late , making it a for PPP-based in enterprise and consumer networking equipment.

Protocol Mechanism

Challenge-Response Process

The Challenge-Handshake Authentication Protocol (CHAP) operates through a core challenge-response mechanism that verifies the identity of the peer without transmitting the over the link. Upon successful link establishment, the generates a random challenge value and a , and transmits this challenge packet to the peer. The peer then computes a response by applying the one-way to the of the received identifier, the known only to both parties, and the challenge value. This hashed response is sent back to the in a response packet, which also includes the peer's name for identification. The independently recomputes the expected hash using the same inputs—identifier, , and challenge value—and compares it to the peer's response; a match confirms successful , while a mismatch indicates failure. To enhance , the identifier is a value that changes with each new challenge, ensuring that responses from previous exchanges cannot be replayed, as the rejects any response with an mismatched identifier. CHAP is designed primarily for one-way authentication, where the peer proves its identity to the , but can be configured by negotiating the protocol in both directions using the same . In case of authentication failure, the authenticator sends a failure packet, which typically terminates the link or prompts renegotiation via the Link Control Protocol (LCP), without allowing retries within the same exchange. Successful authentication, conversely, allows the connection to proceed to the network-layer protocol phase, establishing the full PPP session. This initial challenge-response exchange may be repeated periodically during the session to re-verify the peer's identity.

Authentication Cycle

The Challenge-Handshake Authentication Protocol (CHAP) operates within the (PPP) framework as an iterative that verifies the peer's identity throughout the connection lifecycle. Following the completion of the Link Establishment phase via the Link Control Protocol (LCP), the authenticator initiates the cycle by sending an initial challenge message to the peer. The peer then computes and responds with a value derived from the challenge and a , after which the authenticator validates the response and issues either a or message. Upon success, the connection proceeds to the Network-Layer Protocol phase, such as IP Control Protocol (IPCP) negotiation; a failure, however, terminates the link without retry attempts, preventing further protocol negotiations. To maintain security without interrupting ongoing data transmission, CHAP incorporates periodic re-authentication as part of its ongoing cycle. The generates additional challenges at random intervals during the established connection, prompting the peer to respond similarly to the exchange. These re-authentication events occur whenever the desires, ensuring continuous verification while preserving the flow of network-layer protocols. The protocol's design allows this repetition indefinitely, as long as the link remains active, fostering a dynamic environment integrated seamlessly into PPP's layered structure. The authentication cycle concludes upon link termination, which occurs either through an explicit LCP Terminate-Request/Acknowledge sequence or an abrupt link drop. In such cases, no further challenges are issued, and the connection is fully dismantled, with the option for LCP to renegotiate a new session if needed. This lifecycle emphasizes CHAP's role in providing ongoing, non-disruptive identity assurance within PPP links.

Technical Details

Packet Structure

The Challenge-Handshake Authentication Protocol (CHAP) packets are encapsulated within (PPP) frames, using the protocol field value of 0xC223. This encapsulation ensures CHAP operates as part of the PPP negotiation process. All CHAP packets share a common header structure consisting of three fixed fields, followed by variable data specific to the packet type. The header begins with the Code field, a single octet (1 byte) that identifies the packet type: 1 for Challenge, 2 for Response, 3 for , and 4 for . Next is the Identifier field, also 1 octet, which serves to match a Challenge packet with its corresponding Response and reply; it is typically a sequence number incremented for each new challenge. The header concludes with the Length field, 2 octets in network byte order, specifying the total length of the entire packet, including the header and all data fields, to allow for variable-sized payloads. For Challenge (Code 1) and Response (Code 2) packets, the data portion follows a structured format starting with the Value-Size field (1 octet), which indicates the length of the subsequent Value field. The Value field is variable-length: in a Challenge packet, it contains a stream of pseudo-random bytes (minimum 1 octet, but at least 16 octets recommended, configurable up to the maximum packet size) generated by the to ensure uniqueness and prevent replay attacks. In a Response packet, the Value field is fixed at 16 octets, comprising the hash of the Identifier, , and Challenge Value. Both packet types end with the Name field, a variable-length ASCII string (up to 255 octets) identifying the sending system, such as the peer's or username. Success (Code 3) and (Code 4) packets have a simpler , lacking Value-Size and Value fields. Instead, they include a field of variable octets (up to the Length minus 4), containing a human-readable ASCII string (not null-terminated) for diagnostic or status information; for , this might confirm , while for , it could indicate the reason for denial, though the exact content is implementation-dependent. The following table illustrates the byte-level layout for each packet type, assuming minimum sizes for clarity:
FieldChallenge (Code 1)Response (Code 2)Success (Code 3)Failure (Code 4)
Code1 octet (1)1 octet (2)1 octet (3)1 octet (4)
Identifier1 octet1 octet1 octet1 octet
Length2 octets2 octets2 octets2 octets
Value-Size1 octet1 octet--
ValueVariable (min. 1 octet, recommended ≥16 random)16 octets (MD5 hash)--
Name / MessageVariable (peer ID)Variable (peer ID)Variable (message)Variable (message)
This format ensures efficient transmission over PPP links while accommodating the protocol's challenge-response mechanism.

Hashing and Cryptography

The primary cryptographic mechanism in the Challenge-Handshake Authentication Protocol (CHAP) employs the one-way to generate the authentication response. This algorithm processes a concatenated stream of data to produce a secure, non-reversible output that verifies the peer's identity without exposing sensitive information. The response value is computed by applying MD5 to the identifier (ID), the shared secret (password), and the challenge value in sequence: Response=MD5(ID∥secret∥challenge)\text{Response} = \text{MD5}(\text{ID} \Vert \text{secret} \Vert \text{challenge}) Here, ∥\Vert denotes octet concatenation, and the resulting hash is a fixed 16-byte (128-bit) digest. This formulation ensures that the authenticator can independently recompute the hash using the same inputs to validate the peer's submission. The remains protected throughout the process, as it is never transmitted across the link; both the and peer maintain it locally, often in a hashed or otherwise secured form to minimize exposure risks. This design leverages the secret's role solely in local computations, enhancing . To prevent replay attacks and maintain cryptographic strength, the challenge value must be generated using a secure generator, ensuring global and temporal uniqueness for each authentication instance. The protocol mandates changing this value with every challenge transmission, further bolstering resistance to prediction or reuse. The MD5 algorithm's one-way property is critical, rendering it computationally infeasible to reverse-engineer the secret from observable challenge-response pairs, thus upholding the protocol's model.

Security Considerations

Advantages Over Other Protocols

The Challenge-Handshake Authentication Protocol (CHAP) offers significant improvements over the (PAP) by never transmitting passwords in over the network. In CHAP, the authenticating peer computes a response using a and a server-generated challenge, ensuring that the secret remains protected from eavesdroppers who might intercept the communication. This contrasts sharply with PAP, where credentials are sent unencrypted, making them vulnerable to simple packet sniffing attacks. As a result, CHAP substantially reduces the risk of password exposure during transmission, a critical advantage in environments where link cannot be guaranteed. Another key benefit of CHAP is its built-in protection against replay attacks, achieved through the use of unique, variable challenge values and incrementally changing identifiers in each exchange. Unlike protocols that rely on static or predictable responses, CHAP ensures that even if an attacker captures a valid response packet, it cannot be reused because subsequent challenges will differ, rendering the captured data obsolete. This mechanism provides robust defense against playback attempts by malicious peers, enhancing overall session integrity without requiring additional cryptographic overhead. CHAP also supports periodic re-authentication throughout the session, allowing the server to initiate new challenges at any time after link establishment to verify the peer's ongoing identity. This ongoing verification capability helps detect potential or peer substitution attempts, a feature absent in one-time authentication methods like PAP that perform verification only at connection setup. By enabling repeated checks without disrupting the connection, CHAP maintains in prolonged sessions, such as remote access links. In terms of operational efficiency, CHAP is particularly well-suited for low-bandwidth environments like dial-up connections, as it employs a lightweight three-way that minimizes exchange compared to more resource-intensive certificate-based protocols. These (PKI) methods often involve exchanging and validating digital certificates, which can introduce significant overhead in terms of computational resources and bandwidth on constrained . CHAP's reliance on shared secrets and simple hashing avoids such complexities, making it ideal for intermittent or limited-rate PPP without sacrificing essential security properties.

Vulnerabilities and Limitations

The reliance of CHAP on the hash function introduces significant vulnerabilities, as has been susceptible to collision attacks since the early , allowing attackers to generate inputs that produce identical hash outputs, potentially undermining the integrity of responses. A notable vulnerability was demonstrated in 2024 with the Blast-RADIUS attack (CVE-2024-3596), which uses collisions to forge attributes in CHAP authentications over UDP, enabling authentication bypass and man-in-the-middle attacks in affected systems. Furthermore, because the challenge value is transmitted in plaintext during the handshake, captured challenge-response pairs enable offline dictionary attacks or the use of precomputed rainbow tables to crack weak shared secrets efficiently. A core limitation stems from CHAP's dependence on a static between the authenticator and peer; if this secret is compromised—through insider threats, poor , or side-channel attacks—an adversary can fully impersonate either party in subsequent authentications without needing further interaction. Additionally, the protocol lacks , meaning that exposure of the long-term shared secret retroactively compromises all prior and future sessions derived from it, as no ephemeral keys are used to limit damage. CHAP is particularly exposed to man-in-the-middle (MITM) attacks in untrusted network environments, where an attacker intercepting the connection can observe the challenge and response, relaying them while attempting brute-force or attacks against the in real-time or offline. This risk is amplified in legacy deployments like PPP over insecure links, where the absence of channel encryption allows passive to facilitate active impersonation. In contemporary systems, CHAP is considered outdated for new implementations in favor of more secure protocols like EAP methods, as its cryptographic foundations, including , fail to meet modern security standards. Moreover, secure distribution and mutual trust in the remain challenging, often requiring mechanisms that introduce additional operational complexities. To address these flaws, CHAP should be wrapped in transport-layer security protocols like TLS to encrypt challenges and responses, preventing interception and MITM exploitation. For long-term , migration to extensible alternatives such as EAP-based methods (e.g., EAP-TLS) is recommended, as they support stronger , , and without relying on vulnerable hashes. While CHAP provides advantages over protocols like PAP by avoiding direct password transmission, its inherent weaknesses necessitate these enhancements in any deployment.

Variants

Microsoft CHAP (MS-CHAP)

MS-CHAP, defined in RFC 2433 published in 1998, extends the standard Challenge-Handshake Authentication Protocol (CHAP) specifically for use in Windows networks, enabling authentication of remote workstations over (PPP) links. Unlike standard CHAP, MS-CHAP provides support for -specific password hashes, but authentication in MS-CHAP version 1 (MS-CHAPv1) remains unidirectional (peer to authenticator). This variant is negotiated using CHAP Algorithm identifier 0x80 during the Link Control Protocol (LCP) phase. A primary difference from standard CHAP lies in its hashing mechanisms and response format: MS-CHAP employs Microsoft-specific hashes, including the (LM) hash, which is DES-based and case-insensitive with a 14-character password limit, and the hash, which applies to the Unicode representation of the (supporting up to 256 characters, though practically limited to 14). The peer's response packet includes both LM and NT responses (each 24 octets) along with a flags octet to indicate preference for the NT response, and it incorporates an 8-octet challenge from the authenticator. MS-CHAPv1 supports legacy features like password change packets (with deprecated) and failure packets with reason codes (e.g., 691 for failure) and a retry flag. MS-CHAP version 2 (MS-CHAPv2), specified in RFC 2759 from 2000, builds on this by eliminating the weaker LM response in favor of a peer challenge (16 octets) included in the response packet, enhancing through bidirectional verification between the and peer. For bidirectional authentication, the authenticator's success packet provides a response that the peer can verify using shared secrets derived from the hashes. It uses NTLM-style hashes with for password hashing, for challenge hashing, and DES in ECB mode for key generation, producing 56-bit effective keys expanded to 64 bits with parity. The success packet in MS-CHAPv2 includes a 42-octet authenticator response for peer validation, and it introduces limits on password retries to mitigate brute-force attacks. MS-CHAP is commonly deployed in PPTP-based VPNs for secure tunneling and in legacy Windows dial-up connections, such as those using , , and Windows 98. Both versions support domain-qualified usernames (e.g., "DOMAIN\username") and maintain compatibility with LM and NT password hashes in Windows environments. Recent IETF guidance explicitly deprecates MS-CHAP variants, treating them as equivalent to clear-text password transmission and mandating against their use in new implementations.

Other Extensions

Extensions to the Challenge-Handshake Authentication Protocol (CHAP) have been proposed to address the vulnerabilities of its original hashing mechanism by incorporating stronger hash functions such as and SHA-256. The (IANA) has allocated protocol identifiers for these variants within the (PPP) framework, including algorithm 6 for and algorithm 7 for CHAP with SHA-256, allowing negotiation of the hash type during the phase. These extensions aim to enhance resistance to collision attacks inherent in , though adoption remains limited due to requirements with legacy systems. CHAP has been integrated into the (EAP) as EAP-MD5, providing a challenge-response mechanism suitable for network access control in environments like for wired and wireless networks. Defined in RFC 3748, EAP-MD5 encapsulates the standard CHAP process within EAP packets, using for the hash computation while inheriting EAP's flexibility for method negotiation. This integration enables CHAP-like authentication over diverse link layers without requiring PPP, though it retains MD5's cryptographic weaknesses and lacks mutual authentication or key derivation features found in more advanced EAP methods. In operating systems, CHAP variants are implemented in authentication servers such as FreeRADIUS on and , and OpenBSD's native radiusd daemon, often for integration with -based . These implementations typically adhere to the standard MD5-based CHAP but support PPP algorithm negotiation, allowing potential use of extended hashes like if client and server both enable them. FreeRADIUS, for instance, processes CHAP challenges and responses in its chap module, configurable for environments, while OpenBSD's radiusd handles CHAP packets as part of its standard support. Due to the cryptographic weaknesses of , particularly its vulnerability to preimage and collision attacks, the (IETF) has recommended deprecating CHAP in favor of more secure alternatives like TLS-based methods or EAP-TLS. Recent IETF guidance in draft documents explicitly advises administrators to prefer PAP over CHAP for deployments, citing the protocol's inability to provide adequate protection against modern threats without extensions. These recommendations underscore CHAP's phased-out status in contemporary architectures, promoting migration to protocols with stronger .

References

  1. https://datatracker.ietf.org/doc/rfc1994/
  2. https://datatracker.ietf.org/doc/rfc2759/
  3. https://www.juniper.net/documentation/us/en/software/junos/network-access-protocols/topics/topic-map/interfaces-configuring-the-ppp-challenge-handshake-authentication-protocol.html
  4. https://www.techtarget.com/searchsecurity/definition/CHAP-Challenge-Handshake-Authentication-Protocol
  5. https://www.ietf.org/rfc/rfc1994.txt
  6. https://datatracker.ietf.org/doc/html/rfc1134
  7. https://datatracker.ietf.org/doc/html/rfc1661
  8. https://datatracker.ietf.org/doc/html/rfc1334
  9. https://datatracker.ietf.org/doc/html/rfc1994
  10. https://datatracker.ietf.org/wg/pppext/about/
  11. https://www.ietf.org/rfc/rfc1661.txt
  12. https://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/25647-understanding-ppp-chap.html
  13. https://www.kb.cert.org/vuls/id/836068
  14. https://blog.cloudflare.com/radius-udp-vulnerable-md5-attack/
  15. https://www.ietf.org/archive/id/draft-ietf-radext-deprecating-radius-02.html
  16. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/222287-blast-radius-cve-2024-3596-protocol-sp.html
  17. https://www.securew2.com/blog/eap-tls-vs-peap-mschapv2-which-authentication-protocol-is-superior
  18. https://www.rfc-editor.org/rfc/rfc2433.html
  19. https://www.rfc-editor.org/rfc/rfc2759.html
  20. https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/
  21. https://datatracker.ietf.org/doc/html/rfc3748
  22. https://www.freeradius.org/documentation/freeradius-server/4.0.0/howto/modules/eap/index.html
  23. https://www.freeradius.org/documentation/freeradius-server/4.0.0/howto/modules/chap/index.html
  24. https://man.openbsd.org/radiusd.conf.5
  25. https://man.openbsd.org/radiusd.8
Add your contribution
Related Hubs
User Avatar
No comments yet.