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.