RE: IPP> TLS security section of protocol document

["Turner, Randy" <[e-mail]>]

This and other work being considered for credential delegation would be
potential solutions but nothing is standards-track (yet), and it is
unclear whether anything is being considered for any kind of near-term
deployment. If anyone has any other info, please post the DL.

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:[e-mail]]
	Sent:	Tuesday, February 03, 1998 8:56 AM
	To:	[e-mail]
	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



	[e-mail] on 02/02/98 02:25:38 PM
	Please respond to [e-mail] @ internet
	To: [e-mail] @ 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