next up previous
Next: 4.3 Conclusion Up: 4.2 Security Assessment of Previous: 4.2.2 Security Service Requirements

4.2.3 Other Factors

* Proxy Operation

SHTTP's selective security services and support for multiple encapsulations provide some flexibility for accommodating proxy environments. Most importantly, SHTTP allows for authentication (or other security services) between multiple parties in a transaction path. Consequently, a proxy may be authenticated along with the end client or server. Such authentication may be performed either through a single signature which can be checked by multiple parties or through multiple encapsulations.

The interaction with proxies will depend on the peer relationships of security services, especially with respect to encryption and key management and the operation of the proxy itself. The compatibility with proxies will depend upon the degree to which the proxy is SHTTP aware and the nature of the processing performed at the proxy. If the proxy is not SHTTP aware or if the HTTP transaction is encrypted and hidden from the proxy, then the functions which can be performed are very limited (e.g., limited caching, no information based processing).

SHTTP does provide an ability to decouple the encryption and authentication functions and to encapsulate these services in either order so that a proxy may be capable of authenticating the source without seeing the data or may examine the data while still preserving end-to-end authentication.

These abilities will support some, but not all, proxy environments. There are limitations using SHTTP with non-SHTTP aware proxies or in situations where the proxy must access the information within an HTTP transaction.

* Performance impacts

There are several dimensions to performance including connection establishment latency, transaction overhead, and processing complexity. For SHTTP the establishment latency is minimal with many situations requiring no added exchanges. SHTTP does add a possibly significant amount of overhead to a transaction depending on the security format and services selected. This overhead is apparent in terms of both the increased size of transactions (especially requests) and in the time to process a transaction. Depending on the processing, a number of expensive (i.e. private key) operations may be required to process a request and response. In addition, certification path validation (possibly including retrieving certificate validation data) is likely to be required for most transactions. The significance of the performance impact must be assessed for specific environments (formats, algorithms, and policies).

* Granularity of security services provided by protocol

Security services are applied to individual HTTP transactions and apply to the entire encapsulated data item (an HTTP or SHTTP transaction). The identity being used for security services will depend upon the naming information in the client or server certificate (or other data) and on local key management issues (outside of the scope of the specification).

* Associated key management and cryptography

SHTTP provides for a large and extensible set of algorithms and key management techniques. These algorithms may be grouped together to support selectable suites or may be individually selected.

* Negotiation of services, mechanisms, and formats

The SHTTP negotiation process is based on each party making known required and optional capabilities. These lists may be sent in HTTP exchanges and may also be present in HTML anchors (this will determine, in part, whether additional protocol exchanges are required). The sender selects an appropriate choice from the list based on the sender's own capabilities and policies. The information used to negotiate algorithms and formats is not authenticated. This allows an active attacker to cause two parties to use a particular selection common to both parties rather than having a party's own selection logic invoked. So long as both the client and server enforce a check that appropriate protection is applied to all transactions, this is not a major issue. It may result in weaker cryptographic protection being applied to an association than ``should'' have been used.

SHTTP provides a rich set of options in terms of services, formats, and algorithms. Consequently, there is a significant possibility of having independent, compliant implementations which are not capable of interoperating. Definition of minimum essential requirements (MERs) or standard profiles would enhance the likelihood of interoperability.

* Ability to convey certificate and authorization information

The information which may be conveyed depends upon the format/domain selected. Certification path information may always be sent while PKCS-7 encapsulation also supports transfer of CRLs. Authorization data is not currently addressed. It is important that certificates used with SHTTP provide identification information which can meaningfully be compared with identity information used with HTTP.

* Compromise Recovery and Handling

There is no explicit mechanism to deal with compromise recovery for outband or shared secret keys managed externally. This should be dealt with through whatever mechanism is used to manage such keys.

* Susceptibility to active and passive attacks

The security services provided by SHTTP appear to be robust in the presence of active or passive attackers to the extent that robust cryptographic algorithms are selected.

* Time based issues

Local clocks are used as one basis of ensuring freshness of transactions. Based on the reliability and accuracy of local clocks, this is a weak mechanism.

* Longevity of mechanism

There are no constraints in SHTTP which represent concerns about the longevity of the protection, given the flexibility in algorithms.

* Interoperability considerations

SHTTP provides a very rich set of options for applying security services. The specification describes these tools, but is not clear in guiding the use of these options. Additional explanation, and especially the inclusion of examples, would enhance the ability to implement compatible systems.

SHTTP does make use of other standard security encapsulations (PEM, PGP, PKCS-7) to apply the security services and this should facilitate interoperability and integration in client environments. SHTTP's architectural placement requires integration with the HTTP processing engine; however, the security processing may be performed by an external filter (especially given the use of existing security protocol encapsulations).

* Error handling and recovery

SHTTP relies on error codes and handling sent in HTTP. This allows protection of the error information and makes use of defined processing rules which provides a good basis for error handling.


next up previous
Next: 4.3 Conclusion Up: 4.2 Security Assessment of Previous: 4.2.2 Security Service Requirements
Denis Arnaud
12/19/1997