Subject: Re: IPP>DIR - comments on security document

From: [email-masked] (Robert Herriot)
Date: Thu, 20 Mar 1997 18:46:49 -0800

This document is a good survey of security issues, but I wish there
were some recommendations for what IPP should do.

Other comments:

There are no line numbers in the latest security document ipp-sec-2.0.txt.

line ?: "security domain" is mentioned but not defined. Please add 
     a definition of it.

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.

section 2.2: Why can printing only be done by reference?  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?  In either case, I assume that either client or server can 
     fetch the document.  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.

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.

section 5.0: the abbreviations in the table header row should be expanded.
     I'm not sure what they all are.

     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.

section 6.0: Similar comments to section 5.0.

section 7.0: the columns headings are misaligned or missing.

---

From: Roger K Debry <[email-masked]>
Date: Fri, 21 Mar 1997 09:48:23 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
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
     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?

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.

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 7.0: the columns headings are misaligned or missing.
RKD> I'll fix the alignment problems.

Thanks for your comments....

---

From: [email-masked] (Robert Herriot)
Date: Fri, 21 Mar 1997 16:39:27 -0800

I have some replies to your replies to my original comments.

I am still concerned about the notion of security domain and
what it means.  I don't understand what retrictions a security
domain imposes on the availability of files.  In some examples below,
files seem not to be able to pass from one security domain to another
and in other examples they can.

I don't see the connection between security domains and real security
on existing systems, namely user/group/public file permissions.  
Bob Herriot

More comments below.

> From [email-masked] Fri Mar 21 06:52:08 1997
> 

So if two people are a member of the same security domain, they
both have access to exactly the same files?  This doesn't seem
realistic.  In most systems, I can make some file visible to
just me and others visible to others and I can decide who those
others are for each file.

And if a file is in a different domain from client or printer, how
does anyone get access to it?  I confused.

> RKD> they are not in the same security domain.

You describe 2.1 as the traditional office, so I assume this is where
there is some security on files. I may want to print a file that only
I can read on a printer.  I can push it because I have access to it.
A printer cannot pull it unless I send it appropriate credentials and
that problem is not yet solved as far as I know.

>From all of your comments in the above 3 groups, I conclude that 
a client can send a file or the printer can fetch it.  What is
left unanswered is how a client get authority to fetch the file
or how the printer knows that the client is allowed to print the file.

>      by reference because the printer somehow has to be able to pull

The point I was making is that in section 2.4 the client cannot gain
direct access to the data because it is in a different security domain
and yet in section 2.5 the print can gain access to the data even though
it is in a different security domain.

---

From: Roger K Debry <[email-masked]>
Date: Mon, 24 Mar 1997 10:05:45 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 03/24/97 07:42
AM ---------------------------

        ipp-owner @ pwg.org
        03/21/97 05:43 PM

To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet
cc:
Subject: Re: IPP>DIR - comments on security document

I am still concerned about the notion of security domain

RKD> I think security domain is a pretty well understood term
RKD> among security folks and I intend to keep that term in the
RKD> paper. If you are unhappy with the definition we'll have to
RKD> get some security folks to help explain it better.

... snip ...

So if two people are a member of the same security domain, they
both have access to exactly the same files?

RKD> No, it simply means that there is a set of policies and/or
RKD> security mechanisms in place that dictate how access to
RKD> files is provided. An exampoe would be user/group/public
RKD> file permissions, but might be something more sophisticated.

And if a file is in a different domain from client or printer, how
does anyone get access to it?

RKD> One case would be where the files are public. An example of
RKD> this would be the PWG FTP site where IPP files can be accessed
RKD> by anonymous FTP.  The owner of the ftp site sets the policy
RKD> that establishes these files as accessible by anonymous FTP.

RKD> Another case might be where someone in the security domain of
RKD> the file gives me permission to get the file. Permission may
RKD> come, for example, by purchasing the file.

... snip ...

RKD> If you mean that we do not yet have a solution to providing
RKD> the credentials, you are correct. We recognize this as
RKD> a requirement.

... snip ...

RKD> True, these are unanswered questions we hope to get some help
RKD> with from the ietf security gurus.

... snip ...

RKD> In both cases permission must be provided through some
RKD> mechanism yet to be determined and which may be outside
RKD> the scope of IPP.