I agree with you. However, I was thinking that the security in callout
protocol need not be as general as that needed by HTTP protocol. Assuming
the callout services provided at the edge will be maintained by a single or
closely associated authority, it may be possible to distribute the public
key associated with each callout devices offline and encrypt the service
request with the public key of the service provider device. This avoids the
overhead of challenge-response authentication procedure, or the overhead of
setting up a secure socket layer channel for each callout request. The
problem I see is that if we use these public key methods (asymmetric
encryption algorithm) with ICAP, we can encrypt the message body, however,
we do need to keep the requested uri (and hence the service requested) in
clear text. That was my concern.
regards
Reza
-----Original Message-----
From: Alberto Cerpa [mailto:cerpa(_at_)lecs(_dot_)cs(_dot_)ucla(_dot_)edu]
Sent: Friday, June 29, 2001 5:56 PM
To: Rahman, Rezaur
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Comparison of ICAP and SOAP
Hi Rezaur,
A comment on security regarding iCAP.
"Rahman, Rezaur" wrote:
4. Security
ICAP: The ICAP uri needs to be in the clear to be able to
reach the service,
which can easily be snooped by a third party. One needs to
provide secure
tunneling mechanism.
Authentication is provided using the mechanism described in RFC 2617.
Similarly to HTTP, if privacy is necessary, additional
mechanisms MAY be used,
such as encryption at the transport level or via message
encapsulation.
Regards,
-Al