IPP> Additional proposal details

[Tom Hastings]

A minor quibble: A client should NOT use Create-Job, instead of Print-Job,
when the client wants security, because Create-Job is an OPTIONAL operation,
so that the Printer object might not have implemented it.


As you later suggest the client should use the Validate-Job operation
first, not the Create-Job operation.


Tom


At 08:53 01/07/1998 PST, Turner, Randy wrote:
>
>
>	A client IPP implementation would never issue a
>	"print-job" operation in the clear, and it would know
>	that if it is using an "HTTP:" scheme that thats what
>	is happening. An HTTP client wanting to use security
>	for the connection would never use "print-job". It would
>	always use "create-job" with a 
>	"client-security-requested" attribute. It would then
>	send issue "send-data" ops , etc..
>
>	This is because its possible for redirection ot occur with
>	any operation, and a client would want to make sure that
>	a TLS-session is in progress to a particular IPP server
>	before sending any sensitive data. Keep in mind that this
>	is not only possible with IPP redirects, but is possible with
>	standard HTTP redirects as well, which is out-of-band to
>	actual IPP operations, and our normative scope as well
>	(except for the protocol doc).
>
>	By the way, it is possible to issue a "print-job" operation
>	within the context of a TLS session. The client would issue
>	a "validate-job" with the "client-security-requested" operation
>	attribute set, and then use the returned redirect URI to issue
>	the "print-job" operation securely.
>
>	Randy
>
>
>> -----Original Message-----
>> From:	Carl-Uno Manros [SMTP:carl at manros.com]
>> Sent:	Wednesday, January 07, 1998 6:36 AM
>> To:	Turner, Randy; 'Tom Hastings'
>> Cc:	'ipp at pwg.org'
>> Subject:	RE: IPP> Additional proposal details
>> 
>> At 10:53 PM 1/6/98 -0800, Turner, Randy wrote:
>> >
>> >See my response to your comments below.
>> >
>> >My comments are marked RT>
>> >
>> >R.
>> >
>> 
>> Randy, I have not copied your while message, only one comment from
>> you, 
>> where I think you are breaking the security.
>> 
>> Carl-Uno
>> 
>> 
>> >> -- It allows a TLS-capable server the ability
>> >>    to only require TLS negotiation for 
>> >>    particular operations that require the server
>> >>    to allocate resources. For instance, a
>> >>    server that requires all print jobs to be
>> >>    authenticated might still want all clients
>> >>    to be able to get attributes for the printer,
>> >>    as well as validate job parameters, without
>> >>    going to the expense of performing TLS
>> >>    negotiation. It basically allows an 
>> >>    administrator to decide what types of 
>> >>    operations should be authenticated. In the
>> >>    current spec, ALL operations are authenticated
>> >>    or NONE are. This is a nice scalability
>> >>    feature
>> >> 
>> >> TH> This is a good feature.  However, if a client wants security
>> and
>> >> TH> only has an HTTP URL, how does it get started?  It certainly
>> >> doesn't
>> >> TH> want to do a Print-Job and send valuable data, before gettting
>> the
>> >> TH> TLS URL.  So this means that the client that wants security is
>> >> forced
>> >> TH> to do a Validate-Job with the HTTP://... URL in order to get
>> back
>> >> TH> the redirect HTTPS://... URL, correct?
>> >> 
>> >	RT>You'll note that most of the scalability and flexibility of
>> >	RT>this proposal mostly applies to IPP servers and subsequently
>> >	RT>server administration framework. If a CLIENT wants a
>> >particular
>> >	RT>operation to be "secure" , then it includes the 
>> >	RT>"client-security-requested" operation attribute with whatever
>> >	RT>operation it is attempting.
>> >
>> 
>> CM> If you try this with a job submission operation, you have already
>> sent 
>> CM> your MIME type application/ipp, which means that all your data
>> were sent 
>> CM> unencrypted before you got the secure URI back, so your feature
>> does
>> CM> not make any sense in combination with certain operations. It is
>> not as 
>> CM> generic as you describe it above. Instead you might actually
>> mislead
>> CM> a user to think that their transmission is secure, when in reality
>> CM> it is not.
>> 
>> ---
>
>