I haven't seen any activity on the ietf-tls-apps mailing list either. I
just thought a paragraph describing the current situation might be
needed in the protocol document, possibly before submission to the IESG
for publication as an RFC.
Randy
-----Original Message-----
From: Carl Kugler [SMTP:kugler@us.ibm.com]
Sent: Tuesday, February 03, 1998 8:56 AM
To: ipp@pwg.org
Subject: Re: IPP> TLS security section of protocol
document
Is the approach in
Network Working Group Ari
Luotonen
Request for Comments: XXXX Netscape Communications
Corporation
Category: Informational
September, 1997
Tunneling SSL through Web Proxy Servers
draft-luotonen-ssl-tunneling-03.txt, expires on 9/26/97
being considered for TLS?
-Carl
ipp-owner@pwg.org on 02/02/98 02:25:38 PM
Please respond to ipp-owner@pwg.org @ internet
To: ipp@pwg.org @ internet
cc:
Subject: IPP> TLS security section of protocol document
Just a note from the WG meeting in Hawaii...
During the discussions of security related matters regarding
using
multiple
HTTP methods at the last meeting, Josh brought up a point that
proxies
should be no problem with using a new method (such as PRINT)
because it
would just transparently pass it on through. I'm assuming that
proxies
do this with all methods the proxy does not recognize (unless
some type
of method filtering is turned on).
This discussion got me thinking about proxies and IPP in
general, with
my initial conclusion being that we have a problem using TLS for
end-to-end security in the presence of proxies. There is
currently no
standard for delegation of authentication info across proxies (
or any
kind of "firewall" type of software). If the IPP client is
configured to
work with a particular proxy, and the IPP client is attempting
communication with a TLS-based printer URI, we might need to
indicate in
the protocol document that this (and possibly other scenarios)
can
happen and what the implications of these scenarios might be.
My immediate question is do we consider updating the security
considerations section of the protocol document prior to IETF
last call?
Randy