Classification:
Prologue:
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/24/97 07:42
AM ---------------------------
ipp-owner @ pwg.org
03/21/97 05:43 PM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org at internet
cc:
Subject: Re: IPP>DIR - comments on security document
I have some replies to your replies to my original comments.
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 ...
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.
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 ...
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.
RKD> True, these are unanswered questions we hope to get some help
RKD> with from the ietf security gurus.
... snip ...
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.
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.