Posts Tagged ‘Confidentiality

HTTP Redirect/POST binding

a. Stolen Assertion

Threat: If an eavesdropper can copy the real user’s SAML (Security Assertion Markup Language) response and included assertions, then the eavesdropper could construct an appropriate POST body and be able to impersonate the user at the destination site.

Countermeasures: Confidentiality MUST be provided whenever a response is communicated between a site and the user’s browser. This provides protection against an eavesdropper obtaining a real user’s SAML response and assertions.

If an eavesdropper defeats the measures used to ensure confidentiality, additional countermeasures are available:

  1. The Identity Provider and Service Provider sites SHOULD make some reasonable effort to ensure that clock settings at both sites differ by at most a few minutes. Many forms of time synchronization service are available, both over the Internet and from proprietary sources.
  2. When a non-SSO SAML profile uses the POST binding it must ensure that the receiver can perform timely subject confirmation. To this end, a SAML authentication assertion for the principal MUST be included in the POSTed form response.
  3. Values for NotBefore and NotOnOrAfter attributes of SSO (Single Sign-On) assertions SHOULD have the shortest possible validity period consistent with successful communication of the assertion from Identity Provider to Service Provider site. This is typically on the order of a few minutes. This ensures that a stolen assertion can only be used successfully within a small time window.
  4. The Service Provider site MUST check the validity period of all assertions obtained from the Identity Provider site and reject expired assertions. A Service Provider site MAY choose to implement a stricter test of validity for SSO assertions, such as requiring the assertion’s IssueInstant or AuthnInstant attribute value to be within a few minutes of the time at which the assertion is received at the Service Provider site.
  5. If a received authentication statement includes a <saml:SubjectLocality> element with the IP address of the user, the Service Provider site MAY check the browser IP address against the IP address contained in the authentication statement.

b. Man In the Middle Attack

Threat: Since the Service Provider site obtains bearer SAML assertions from the user by means of an HTML form, a malicious site could impersonate the user at some new Service Provider site. The new Service Provider site would believe the malicious site to be the subject of the assertion.

Countermeasures: The Service Provider site MUST check the Recipient attribute of the SAML response to ensure that its value matches the https://<assertion consumer host name and path>. As the response is digitally signed, the Recipient value cannot be altered by the malicious site.

c. Forged Assertion

Threat: A malicious user, or the browser user, could forge or alter a SAML assertion.

Countermeasures: The browser/POST profile requires the SAML response carrying SAML assertions to be signed, thus providing both message integrity and authentication. The Service Provider site MUST verify the signature and authenticate the issuer.

d. Browser State Exposure

Threat: The browser/POST profile involves uploading of assertions from the web browser to a Service Provider site. This information is available as part of the web browser state and is usually stored in persistent storage on the user system in a completely unsecured fashion. The threat here is that the assertion may be “reused” at some later point in time.

Countermeasures: Assertions communicated using this profile must always have short lifetimes and should have a <OneTimeUse> SAML assertion <Conditions> element. Service Provider sites are expected to ensure that the assertions are not re-used.

e. Replay

Threat: Replay attacks amount to re-submission of the form in order to access a protected resource fraudulently.

Countermeasures: The profile mandates that the assertions transferred have the one-use property at the Service Provider site, preventing replay attacks from succeeding.

f. Modification or Exposure of state information

Threat: Relay state tampering or fabrication, Some of the messages may carry a <RelayState> element, which is recommended to be integrity protected by the producer and optionally confidentiality- protected. If these practices are not followed, an adversary could trigger unwanted side effects. In addition, by not confidentiality-protecting the value of this element, a legitimate system entity could inadvertently expose information to the identity provider or a passive attacker.

Countermeasure: Follow the recommended practice of confidentiality and integrity protecting the RelayState data. Note: Because the value of this element is both produced and consumed by the same system entity, symmetric cryptographic primitives could be utilized.

Tags : , , , , , , , , , , , , , , , , , , , ,

Use of SOAP over HTTP

Since the SOAP binding requires that conformant applications support HTTP over TLS/SSL with a number of different bilateral authentication methods such as Basic over server-side SSL and certificate-backed authentication over server-side SSL, these methods are always available to mitigate threats in cases where other lower-level systems are not available and the above listed attacks are considered significant threats.

This does not mean that use of HTTP over TLS with some form of bilateral authentication is mandatory. If an acceptable level of protection from the various risks can be arrived at through other means (for example, by an IPsec tunnel), full TLS with certificates is not required. However, in the majority of cases for SOAP over HTTP, using HTTP over TLS with bilateral authentication will be the appropriate choice.

The HTTP Authentication RFC describes possible attacks in the HTTP environment when basic or message-digest authentication schemes are used. Note, however, that the use of transport-level security (such as the SSL or TLS protocols under HTTP)only provides confidentiality and/or integrity and/or authentication for “one hop”. For models where there may be intermediaries, or the assertions in question need to live over more than one hop, the use of  HTTP with TLS/SSL does not provide adequate security.

Tags : , , , , , , , , , , , ,

Desirable Quantum Key Distribution Attributes

Broadly stated, QKD(Quantum Key Distribution) offers a technique for coming to agreement upon a shared random sequence of bits within two distinct devices, with a very low probability that other devices(eavesdroppers) will be able to make successful inferences as to those bits’ values. In specific practice, such sequences are then used as secret keys for encoding and decoding messages between the two devices. Viewed in this light, QKD is quite clearly a key distribution technique, and one can rate QKD’s strengths against a number of important goals for key distribution, as summarized in the following paragraphs.

Confidentiality of Keys : Confidentiality is the main reason for interest in QKD. Public key systems suffer from an ongoing uncertainty that decryption is mathematically intractable. Thus key agreement primitives widely used in today’s Internet security architecture, e.g., Diffie-Hellman, may perhaps be broken at some point in the future. This would not only hinder future ability to communicate but could reveal past traffic.Classic secret key systems have suffered from different problems, namely, insider threats and the logistical burden of distributing keying material. Assuming that QKD techniques are properly embedded into an overall secure system, they can provide automatic distribution of keys that may offer security superior to that of its competitors.

Authentication : QKD does not in itself provide authentication.Current strategies for authentication in QKD systems include prepositioning of secret keys at pairs of devices, to be used in hash-based authentication schemes, or hybrid QKD-public key techniques. Neither approach is entirely appealing. Prepositioned secret keys require some means of distributing these keys before QKD itself begins, e.g., by human courier,which may be costly and logistically challenging. Furthermore, this approach appears open to denial of service attacks in which an adversary forces a QKD system to exhaust its stockpile of key material, at which point it can no longer perform authentication. On the other hand, hybrid QKD-public key schemes inherit the possible vulnerabilities of public key systems to cracking via quantum computers or unexpectedadvances in mathematics.

Sufficiently Rapid Key Delivery : Key distribution systems must deliver keys fast enough so that encryption devices do not exhaust their supply of key bits. This is a race between the rate at which keying material is put into place and the rate at which it is consumed for encryption or decryption activities. Today’s QKD systems achieve on the order of 1,000 bits/second throughput for keying material, in realistic settings, and often run at much lower rates. This is unacceptably low if one uses these keys in certain ways, e.g., as one-time pads for high speed traffic flows. However it may well be acceptable if the keying material is used as input for less secure (but often secure enough) algorithms such as the Advanced Encryption Standard. Nonetheless, it is both desirable and possible togreatly improve upon the rates provided by today’s QKD technology.

Robustness : This has not traditionally been taken into account by the QKD community. However, since keying material is essential for secure communications, it is extremely important that the flow of keying material not be disrupted, whether by accident or by the deliberate acts of an adversary (i.e. by denial of service). Here QKD has provided a highly fragile service to date since QKD techniques have implicitly been employed along a single point-to-point link. If that link were disrupted,whether by active eavesdropping or indeed by fiber cut, all flow of keying material would cease. In our view a meshed QKD network is inherently far more robust than any single point-to-point link since it offers multiple paths for key distribution.

Distance- and Location-Independence : In the ideal world,any entity can agree upon keying material with any other(authorized) entity in the world. Rather remarkably, the Internet’s security architecture does offer this feature – any computer on the Internet can form a security association with any other, agreeing upon keys through the Internet IPsec protocols. This feature is notably lacking in QKD, which requires the two entities to have a direct and unencumbered path for photons between them, and which can only operate fora few tens of kilometers through fiber.

Resistance to Traffic Analysis : Adversaries may be able to perform useful traffic analysis on a key distribution system,e.g., a heavy flow of keying material between two points might reveal that a large volume of confidential information flows, or will flow, between them. It may thus be desirable to impede such analysis. Here QKD in general has had a rather weak approach since most setups have assumed dedicated, point-to-point QKD links between communicating entities which thus clearly lays out the underlying key distribution relationships.

 

Tags : , , , , , , , , , , , , , , , , , , , , , , , ,