IPP>DIR - comments on security document

IPP>DIR - comments on security document

IPP>DIR - comments on security document

Roger K Debry rdebry at us.ibm.com
Fri Mar 21 09:48:23 EST 1997

Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/21/97 07:14
AM ---------------------------
This document is a good survey of security issues, but I wish there
were some recommendations for what IPP should do.
RKD> Frankly, we just aren't at that point yet
RKD> in the security group. Our objective in
RKD> getting this document done for the ietf mtg
RKD was to give it the security folks at the ietf
RKD> some background material to help us with.

There are no line numbers in the latest security document ipp-sec-2.0.txt.
RKD> I would have to hand edit them in.

line ?: "security domain" is mentioned but not defined. Please add
     a definition of it.
RKD> Anyone have a definition they'd like to offer?
RKD> Loosley speaking I'd say that it was the domain
RKD> within which a given set of security policies
RKD> and mechanisms operated. A domain in which a
RKD> person has access privileges to resources.

section 2.1:  if security domain is at the level of a DNS domain, then
     it may not be possible to print a document by reference. That is,
     it may be inaccessible for security reasons because client and
     server are on differet hosts.
RKD> See previous response. By definition,
RKD> client has access to documents. If not,
RKD> they are not in the same security domain.

section 2.2: Why can printing only be done by reference?
RKD> Because you can't push a document that's not
RKD> physically on the client, which is the case here.

     What is
     the meaning of the security barrier in this example.  Is the
     document in a secure area or are the client and host in a secure

RKD> They may be secure or not, depending upon
RKD> the policies of the security domain they
RKD> reside in.

     In either case, I assume that either client or server can
     fetch the document.

RKD> If the client fetches it, then from an IPP point
RKD> of view the the document is now in the client's
RKD> security domain. Doesn't matter how (or when) it
RKD> got there. The point is, that at the instant I
RKD> invoke the print request, the document is not on
RKD> the client in the case described in this section.

     Now that I think about it, what is the
     difference between section 2.1 and 2.2. If the document is accessible
     does it really matter whether it is in a different security domain?

section 2.3: This is a case where I would expect the printing by reference
     would be disallowed or there would be lots of caveats.  But the
     text in this section makes it seem like printing by reference
     is a no-brainer.

RKD> You are right, printing by reference will require
RKD> that some credentials be passed to the printer to
RKD> allow it to get the content. I'll add a few words here.

section 2.5: This case also raises some difficult issues in the print
     by reference because the printer somehow as to be able to pull
     the data from another security domain -- exactly what section 2.4
     was disallowing.  This seems like a contradiction to me.

RKD> I'm confused by your comment. Yes, the Printer has to pull
RKD> the content from another security domain. But, I'm not
RKD> sure what your point is with respect to section 2.4. In
RKD> section 2.4 what do you think is disallowed?

section 5.0: the abbreviations in the table header row should be expanded.
     I'm not sure what they all are.
RKD> I'll try to provide some keys, it's not possible
RKD> to fit everything into the space available across
RKD> the page.

     I'm not sure if the table is helpful. I have this uneasy feeling
     that "yes" and "no" along with "C" and "S" give only a small part of the
RKD> It may be, but its what we know so far.

section 6.0: Similar comments to section 5.0.

section 7.0: the columns headings are misaligned or missing.
RKD> I'll fix the alignment problems.

Thanks for your comments....

More information about the Ipp mailing list