----- Original Message -----
From: "Jeremy Elson" <jelson(_at_)ISI(_dot_)EDU>
To: "Craig Blitz" <CBlitz(_at_)novell(_dot_)com>
Cc: "Donald Gillies" <gillies(_at_)netapp(_dot_)com>;
<pwg(_at_)catarina(_dot_)usc(_dot_)edu>; <debbief(_at_)netapp(_dot_)com>;
<ietf-openproxy(_at_)imc(_dot_)org>
Sent: Friday, January 12, 2001 5:15 AM
Subject: Re: MISTAKE(s) in ICAP 1.0 specification
We definitely have some changes built up and need to make an -01
version, then maybe we can submit to become an RFC instead of an I-D.
Should we start up teleconfs again or do it over email?
At some point, also, I'd like to hear from folks at IETF how San Deigo
went (sorry again I couldn't make it!)
-J
On a related topic (updates) - I see a conflict between 5.4.2 and 8.1.
Specifically, 5.4.2 requires
"Proxy-Authenticate and Proxy-Authorization headers that MUST be
forwarded to the ICAP server in the ICAP header section (not the
encapsulated message). This allows propagation of client credentials
that might have been sent to the ICAP client in cases where the ICAP
client is also an HTTP proxy. Note that this does not contradict
HTTP/1.1, which explicitly states "A proxy MAY relay the credentials
from the client request to the next proxy if that is the mechanism by
ICAP Protocol Group Expiration: May 2001 [Page 14]
INTERNET-DRAFT Internet Content Adaptation Protocol December 2000
which the proxies cooperatively authenticate a given request." (Section
14.34)."
and 8.1
"-- If authentication is required between an ICAP client and ICAP server,
hop-by-hop Proxy Authentication as described in RFC 2617 MUST be
used.
There are potential applications where a user (as opposed to ICAP
client) might have rights to access an ICAP service. In this version of
the protocol, we assume that ICAP clients and ICAP servers are under the
same administrative domain, and contained in a single trust domain.
Therefore, in these cases, we assume that it is sufficient for users to
authenticate themselves to the ICAP client (which is a proxy from the
point of view from the user). This type of authentication will also be
Proxy Authentication as described in RFC 2617."
The issues I see are
1 5.4.2 is requiring an iCAP client to login. What if a particular iCAP server
wishes to run an anonymous service?
2 non-basic authentication schemes will fail for passing user credentials from
the iCAP client to the iCAP server.
1 is not large - a server could always publish the user credentials. But it
_could_ be annoying in the extreme case.
2 is a larger issue. Challenge - response authentication schemes like digest
require the authenticating device to issue the
challenge. Passing on a challenge response to a non-involved third party may
not provide enough information for the third party to
authenticate the username.
As a specific example, (using rfc 2617 - Digest authentication)
The users client-agent makes a request of a HTTP proxy server.
The proxy responds with 407 and includes Digest authentication, with a Realm of
"HTTP Proxy"
The client-agent retries the authentication request to the HTTP proxy server
with a digest response.
The HTTP proxy offloads the Digest authentication test to the organisations
user directory to authenticate the user.
The HTTP Proxy requests request modification from an iCAP server
The iCAP server responds with 407, and includes Digest authentication, with a
realm of "Vendor specific realm"
At this point the HTTP proxy does not have enough information to authenticate
to the iCAP server - the organisation's directory
performed the H(A1) calculation, and never returned it to the proxy server.
Even if it had been returned from the organisation's
directory service was calculated with the incorrect realm & a new H(A1) needs
calculating.
Likewise the iCAP device may only support Basic authentication, while the proxy
server is supporting Digest authentication.
I have some thoughts on how to solve this, but the first question is: does
anyone disagree that this (point 2) is an issue?
Rob