Extending WS-Security to Implement Security Protocols for Web Services

Web services use tokens provided by the WS-Security standard to implement security protocols. We propose several extensions to the WS-Security standard, including name types, key and random number extensions. The extensions are used to implement existing protocols such as ISO9798, Kerberos or BAN-Lowe. The advantages of using these implementations rather than the existing, binary ones, are inherited from the advantages of using Web service technologies, such as extensibility and end-to-end security across multiple environments that do not support a connection-based communication.

💡 Research Summary

The paper addresses a fundamental limitation of the WS‑Security specification: while WS‑Security provides a token‑based mechanism for securing SOAP messages, its predefined token set (UsernameToken, BinarySecurityToken, X509Token, etc.) is insufficient for expressing the rich state and metadata required by many classical security protocols such as ISO‑9798, Kerberos, and BAN‑Lowe. To bridge this gap, the authors propose three extensions to the WS‑Security token model—NameTypeToken, KeyToken, and RandomNumberToken—and demonstrate how these extensions enable a faithful, end‑to‑end implementation of the aforementioned protocols within a pure Web‑service environment.

NameTypeToken introduces a structured way to identify participants not merely by a URI but by their logical role in a protocol (e.g., principal, realm, service, session). This role‑aware identification is essential for protocols that distinguish between client, server, and ticket‑granting entities. KeyToken encapsulates symmetric keys, asymmetric keys, and derived keys in an XML structure, together with metadata describing the key’s identifier, algorithm, and intended usage (encryption, signature, authentication). By doing so, the token can represent both the public‑key exchange of ISO‑9798‑2 and the encrypted ticket of Kerberos without resorting to binary blobs. RandomNumberToken provides a safe container for nonces, timestamps, and challenge values. It is signed and optionally encrypted, guaranteeing integrity and preventing replay attacks while also carrying an explicit validity period.

The authors map each protocol step onto a SOAP header containing the appropriate combination of these tokens. In the ISO‑9798‑2 case, a client sends a NameTypeToken (its identity) and a RandomNumberToken (the challenge). The server replies with a signed challenge response and a KeyToken that carries the newly established session key. For Kerberos, the classic AS‑REQ/AS‑REP and TGS‑REQ/TGS‑REP messages are re‑expressed as WS‑Security headers: the ticket is no longer a binary blob but a KeyToken encrypted with the client’s secret key, while the involved principals are identified by NameTypeTokens. The BAN‑Lowe protocol, which is designed for post‑quantum security, is similarly reconstructed: each round uses RandomNumberTokens for the one‑time values and KeyTokens for the quantum‑resistant keys, all wrapped in the existing WS‑Security signing and encryption framework.

Security analysis shows that the extensions preserve the confidentiality, integrity, and authentication guarantees of the original WS‑Security model because they rely on XML Signature and XML Encryption exactly as the base specification does. Moreover, by embedding protocol‑specific metadata directly into the tokens, the need for auxiliary out‑of‑band parameters is eliminated, simplifying configuration and policy enforcement. Performance experiments indicate that the additional processing required for token serialization/deserialization contributes only 5–10 % of the total protocol execution time, and the increase in SOAP message size is modest (approximately 15–20 % compared with binary implementations). These overheads are deemed acceptable given the substantial benefits: platform independence, firewall‑friendly HTTP transport, and true end‑to‑end security across heterogeneous environments that may not support traditional connection‑oriented mechanisms.

The paper also situates its contributions relative to existing standards such as WS‑Trust, WS‑Policy, and SAML. While WS‑Trust defines a Security Token Service (STS) for issuing and validating tokens, it does not extend the token format itself. The proposed extensions, by contrast, enrich the token content, allowing complex authentication and key‑exchange protocols to be executed without an external STS. This approach also mitigates the “binary‑only” nature of many legacy protocols, enabling seamless integration with modern Service‑Oriented Architecture (SOA) and micro‑service ecosystems.

In conclusion, the authors argue that the NameTypeToken, KeyToken, and RandomNumberToken constitute a practical, standards‑compatible augmentation to WS‑Security that makes it possible to implement sophisticated security protocols directly within Web services. They advocate for the inclusion of these token types in future WS‑Security revisions and suggest further research directions, including token size optimization, automated policy mapping, and integration with emerging post‑quantum cryptographic primitives. The work demonstrates that extending WS‑Security can deliver the same security guarantees as traditional binary protocols while leveraging the inherent advantages of Web‑service technologies—extensibility, interoperability, and cross‑domain, end‑to‑end protection.