Hi Rezaur,
On Mon, 2 Jul 2001, Rahman, Rezaur wrote:
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.
In the scenario you described, where the iCAP client and server reside
in the same trusted domain, encryption may not be necessary and in
fact it may affect performance. In addition, encryption is ONLY
necessary if you want to protect privacy, NOT just to only
authenticate the request.
This avoids the overhead of challenge-response authentication
procedure, or the overhead of setting up a secure socket layer
channel for each callout request.
You could establish a secure channel at initialization between the
iCAP client and service and use it for all the requests, you DO NOT
have to set it up for each 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.
If the entire iCAP message is delivered through a secure channel, you
won't see anything.
Even if you send the iCAP URI in the clear and you encrypt the body (I
am following your proposal), I don't see a problem. For instance,
knowing the DNS name or IP address of an ssh server does not make it
inherently less secure.
Cheers,
-Al
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