I don't really see a problem in having two URLs, one for non-secure and the
other for secure (https). The directory schema could list both. If security is
desired then TLS could be used to negogitate (automatically) to the desired
ciphersuite.
The non-secure server could allow unauthenticated, basic-auth and digest-auth.
The unauthenticated case would correspond to the "anonymous printing" that Randy
mentioned earlier.
Using https and then negotiating down to no security at all still requires use
of port 453 --- this is somewhat deceptive (to a sys admin person). It might??
be difficult to monitor who is using non-secure vs. secure if we use port 453
for both. If security is mandated when using 453, then the sys admin does not
have to worry as much about any potential attack. It then makes sense to keep
the non-secure server separate (port 80).
Philip Thambidurai
______________________________ Reply Separator _________________________________
Subject: RE: IPP> Security proposal
Author: "Turner; Randy" <rturner at sharplabs.com> at INTERNET
Date: 11/11/97 1:37 PM
> -----Original Message-----
> From: Scott Lawrence [SMTP:lawrence at agranat.com]
> Sent: Monday, November 10, 1997 6:49 AM
> To: ipp at pwg.org> Subject: Re: IPP> Security proposal
>>> >>>>> "RT" == Randy Turner <rturner at sharplabs.com> writes:
>> RT> Currently, I don't know of any way an HTTP client has to direct an
> RT> HTTP server to make a particular connection secure, and IPP needs
> RT> either end to indicate this requirement.
>> >>>>> "SL" == Scott Lawrence
>> SL> If you're using 'secure' as 'confidential', then the client
> requests
> SL> that protection by making the connection on the SSL port (https:),
> SL> and indicates that it does not require confidentiality by making
> the
> SL> request on a non-SSL port.
>> The problem is that HTTPS is a different URL. What I was considering
> was the
> case where there is only one URL specified for the IPP printer. What
> I'm trying to
> avoid is running two different IPP services (one secure and one
> non-secure) if
> I want to support both secure and non-secure environments. With one
> URL,
> we just connect and negotiate whether or not security is required.
>> SL> The service (the printer or print server) probably cares more
> about
> SL> authentication than confidentiality for IPP, and it can get that
> on
> SL> a connection that is either confidentiality protected or not
> using
> SL> Digest Access Authentication.
>> The server caring more about authentication than confidentiality is
> emphaisized in my previous proposal, as is the option for
> confidentiality or not.
>> Ultimately, my proposal prioritizes the selection of TLS for our only
> security framework for IPP. If we end up going down the path of
> supporting multiple URLs for different types of security, I think
> it would be unfortunate and add greater administrative and
> resource impact for those environments that would like to
> support both secure and non-secure IPP services.
> Randy
> --
> Scott Lawrence EmWeb Embedded Server
> <lawrence at agranat.com>
> Agranat Systems, Inc. Engineering
>http://www.agranat.com/