My comments are marked RT>
R.
> -----Original Message-----
> From: Tom Hastings [SMTP:hastings@cp10.es.xerox.com]
> Sent: Tuesday, January 06, 1998 6:01 PM
> To: Turner, Randy; 'ipp@pwg.org'
> Subject: Re: IPP> Additional proposal details
>
> 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?
>
RT> Yes.
> TH> Also we need to add a redirect status code in section 13.1.3
> TH> Redirection Status Codes, say, "server-redirect", correct?
>
RT>I think we need an indication (like a status code) so
RT>that the client knows that it received a redirect. If we
RT>don't have a status code, then the operation response
RT>attributes would have to be examined on every response
RT>to see if the original request was redirected. Having a
RT>status code like you suggested is better and more
RT>efficient since we're already paying the price of having
RT>to check the status code on all responses.
>
>
> 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'.
>
RT>I really wouldn't like to preclude other security mechanisms
RT>to be used in future IPP revisions, but I would like to nail
RT>down TLS for version 1.0. I intended this operation attribute
RT>to be a BOOLEAN so that (for IPP version 1.0) I'm putting a
RT>stick in the mud with regards to interoperable security.
RT>Having said that, we might want to say that this is an
RT>enumeration, and that for version 1.0 we are only defining
RT>(mandating) that this must be set to the value of "enum-tls"
RT>or whatever. This would save us the hassle of having to
RT>deal with the boolean for legacy IPP 1.0 implementations
RT>in the future. Because if we allow more than one security
RT>mechanism to be specified, then we would have to add
RT>another attribute that was an enum; meaning we would
RT>have to support both the boolean for legacy IPP, AND the
RT>new enum. If we start out with this operation attribute as
RT>an enum and mandate that for 1.0 it only has one value,
RT>then we can add other possible enum values to this
RT>attribute for later revisions of the protocol, and we don't
RT>have the "legacy" IF statements in our code for both old
RT>and new operation attributes. comments?
> 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.
>
RT>All of the attributes and associated status codes would
RT>be mandatory to support for both servers and clients.
RT>However, certain schemed URIs that are returned in a
RT>redirect response may not be supported by all clients.
RT>(unless its an HTTPS-schemed URI, then it must be
RT>supported).
>
> ----
>
> 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?
>
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.
> 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.
>
RT>This is basically true, but we don't really define what the
client
RT>does, you've just outlined some potential client policies but
we
RT>don't "standardize" the clients behavior with regards to the
RT>order of operations. We can suggest, but I don't think we
need
RT>to mandate.
> TH> Presumably, before doing the second validate or Print-Job, the
> TH> client and server perform the TLS handshake.
>
RT>When the client requested security using the
RT>"client-security-requested" attribute, the server returned
RT>a redirect response. In the normal case, the redirected
RT>URI would be an HTTPS-schemed URI to which the client
RT>would then re-issue the operation and negotiate security.
> 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?
>
RT>This is correct, TLS handshakes are expensive and the
RT>successful TLS-handshake negotiated session can be used
RT>for as many operations as the server decides it allows before
RT>a new handshake is required. This isn't my specification, its
RT>defined in detail in the TLS 1.0 specification.
> -- 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"
> >