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
Mon Mar 24 10:05:45 EST 1997


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.



More information about the Ipp mailing list