---------------------- 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
area?
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
story.
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....