IPP> TLS security section of protocol document

IPP> TLS security section of protocol document

Turner, Randy rturner at sharplabs.com
Tue Feb 3 13:03:11 EST 1998


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:kugler at us.ibm.com]
	Sent:	Tuesday, February 03, 1998 8:56 AM
	To:	ipp at 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 at pwg.org on 02/02/98 02:25:38 PM
	Please respond to ipp-owner at pwg.org @ internet
	To: ipp at 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



More information about the Ipp mailing list