Subject: Re: IPP> Additional proposal details

From: Tom Hastings <[email-masked]>
Date: Tue, 6 Jan 1998 18:00:57 PST

Randy,

I have a few questions on your proposal to use an IPP redirect mechanism.  
But it does seem to be simple and allows scalability where a print job could 
be performed on a different server than to which it was originally 
submitted.  This was a feature that Kinko's liked.

Also, as you point out, it allows an implementor and/or system administrator 
to decide on an operation by operation basis, which operations needs
more security and which do not.

The key is that all clients MUST support the redirect mechanism.

I'm trying to compare your scheme with Carl-Uno and Larry's
of having a single multi-valued "printer-uri-supported" Printer attribute
and a single-valued  "printer-uri" operation attribute.  The directory
entry would also be the multi-valued "printer-uri-supported" attribute.

Both schemes simplify our current document and have a single attribute.

See comments marked TH> below on your proposal.

Tom

Here is your attachment as text:

TLS Redirection Modifications

The following changes to the model document
would be required in order to support my
earlier redirection proposal. The changes
appear to be simple, and would allow us to
use the term "printer-uri" throughout the
document, without all the "hand waving"
(similar to Bob's proposal).

Section 3.1.3.2 Response Operation Attributes

An additional operation response
attribute would be defined:

server-redirect-uri

This is a generic redirect (not TLS specific)
that allows servers to redirect requests to
another URI. NOTE: The redirect only applies
to each request. A client should not assume
the lifetime of a redirect to last beyond the
particular request that was originally
redirected.

TH> Presumably, this "server-redirect-uri" Operation attribute is
TH> MANDATORY for a Printer to support, but is only returned on
TH> a redirect response, correct?

TH> Also we need to add a redirect status code in section 13.1.3
TH> Redirection Status Codes, say, "server-redirect", correct?

clients MUST recognize and use redirects.

----

For all operations, an additional operation
attribute MAY be included by clients:

client-TLS-requested

TH> Presumably, a 'boolean' attribute, correct?
TH> How about making the value of this attribute specifying what
TH> security is requested, perhaps as a keyword value? 
TH> Something like "client-security-requested" with values: 'tls' and
TH> 'digest'.

This attribute would indicate to the server
that the client wishes to use TLS for the
session.

If the server supports TLS, it would return
the generic redirect response attribute
described above. If the server DOES NOT
support TLS, then the server would return the
"scheme-not-supported" error code to the
client.

TH> Presumably the server rejects the request as well, correct?
TH> Also this attribute is MANDATORY for a server to support,
TH> but which values depends on implementation.

----

On a get-printer-attributes request, the
"printer-uri" returned would always be the
URI that was used to issue the get-attributes
request (like Bob's proposal)

On a get-job-attributes request, the 
"containing-printer-uri" would be either the
base "printer-uri" (non-TLS), or a
redirected TLS URI that was actually used to
submit the job. I submit that we can leave
this up to implementations since I think the
client results would be the same.

----

On a get-jobs request to a printer-uri, the
"containing-printer-uri" attribute returned
for each job would be implementation-specific.
It would either be the "printer-URI" (non-TLS)
for the printer, or it could be a redirected
TLS URI. This needs to be implementation-specific
so as to allow servers to decide how job-
specific information is displayed for a 
particular client.

--

In addition to addressing Bob's concerns
with printer-uri and printer-tls-uri, this
proposal also offers the following
advantages:

-- 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?

TH> After getting back the HTTPS:// URL, the client can either do another
TH> Validate-Job operation to validate the attributes before wasting time
TH> sending the data, or it can do the Print-Job operation and send the
TH> data and risk wasting the time sending the data for a job that is
TH> rejected.

TH> Presumably, before doing the second validate or Print-Job, the
TH> client and server perform the TLS handshake.

TH> Presumably, the TLS handshake doesn't have to be repeated for the
TH> Print-Job, after the second Validate-Job, correct?  In other words,
TH> the TLS handshake is for the session, not for each operation?
TH> Only after a redirect, does the client have to repeat the TLS
TH> handshake, correct?

-- We no longer have to worry about publishing
   multiple URI strings in directories or other
   places in order to support TLS sessions to
   a server. There's only one URI for the 
   printer. If a client attempts an operation to
   the printer URI, and the server deems that
   authentication is required, then it 
   automatically issues a redirect, similar to
   the way current web browsers bounce back and
   forth from SSL and non-SSL connections to a
   a particular web "service".

At 23:46 12/20/1997 PST, Turner, Randy wrote:
>
>Please review the attached details to the
>proposal I loosely suggested earlier. This
>proposal addresses Bob's concerns with
>the problems of printer-uri and printer-tls-uri
>handling...
>
>Randy
>
> 
>
>Attachment Converted: "C:\WINNT\Profiles\hastings\Personal\Attach\redir.txt"
>

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 07 Jan 1998 06:35:30 -0800

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

>	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.

---

---

From: Tom Hastings <[email-masked]>
Date: Wed, 7 Jan 1998 11:37:11 PST

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:[email-masked]]
>> Sent:	Wednesday, January 07, 1998 6:36 AM
>> To:	Turner, Randy; 'Tom Hastings'
>> Cc:	[email-masked]'
>> Subject:	RE: IPP> Additional proposal details
>>