IPP> Security proposal

IPP> Security proposal

Randy Turner rturner at sharplabs.com
Sat Nov 8 12:13:49 EST 1997


Another comment on my previous comment...


I would like to suggest that we might want to
consider *anonymous* printing, a separate case
(and class) of IPP printing. I think TLS 
can handle most of the other requirements
for *authenticated* printing (including the
exchange of shared secrets...). 


 I'm wondering if we could define an *anonymous*
 authentication that clients could use and that IPP
 servers would recognize as a kind of *guest*
 authentication...this may have already been
 defined within some other security working group....


 Randy




Philip Thambidurai wrote:
> 
> I think that the MD5 (or other message digest or secure hash algorithm)
> is used only when
> the client and the server ALREADY SHARE A SECRET (such as a password).
> (it is assumed that some other secure channel has been used to transmit
> that
> secret from one party to the other).
> 
> In the Internet Printing context, I can see an end-user who would like
> to print to
> an IPP-Printer that may not have any knowledge about the end-user.
> In such a case, requiring MD5 will prevent the end-user from
> printing, even if no security of any kind is necessary (internet or
> intranet).
> 
> Turner, Randy wrote:
> 
> >         [Carl Uno Manros wrote...]
> > >
> > > Randy,
> > >
> > > Thanks for taking the time to put your ideas on paper.
> > >
> > > I looked over your proposal and would like you to comment on the
> > > following
> > > things.
> > > I expect to get back with more detailed comments after having spoken
> >
> > > to my
> > > security guys on Monday.
> > >
> > > 1) I was disappointed that you did not spell out what is now the
> > > minimum
> > > "extra stuff" that every implementation would have to include if we
> > > mandated TLS negotiation for all IPP clients and servers. My latest
> > > impression is that it is a lot more than we anticipated when the
> > > subject
> > > was discussed in the Boulder PWG meeting.
> >         [Turner, Randy]
> >         I modified my stand in Boulder to require the minimum
> > negotiated
> >         security to be MD5 message digest, this is in order to be
> > compliant
> >         with some web servers that use SSL3 but might not be able to
> >         negotiate down to NO security. Also, after thinking about it,
> > it
> > didn't
> >         make much sense to have an encapsulation without utilizing it
> > to
> > some
> >         degree. MD5 message digest is a very simple security mechanism
> >
> >         that, even in intranet environments, would not be a burden to
> > implement.
> >         And in the cases where a minimally compliant printer would be
> > accessed
> >         across a possibly insecure topology (i.e., the internet), then
> >
> > at least the
> >         minimally compliant printer could offer some level of
> > security.
> > I don't think
> >         this minimal level of security is too much to ask from an
> > "Internet"
> >         printing protocol...
> >         [Turner, Randy]  [end]
> >
> > >
> > > 2) Earlier today Keith Moore came up with a proposal to take a new
> > > look at
> > > SASL, which might eliviate some of the extra burden that 1) above
> > > might
> > > incur. Do you or anybody else knows if "the world" is really going
> > to
> > > implement SASL in the foreseeable future (or are we up against yet
> > > another
> > > road block here)? Judging from the comments on the DL recently, a
> > > number of
> > > people have asked for a very light weight mechanism to do the
> > initial
> > > security negotiation, with the option to say "NO I do not want any
> > > security", and I am still not convinced that TLS will deliver that.
> >         [Turner, Randy]
> >         All I can say is to read the TLS specification. Its quite
> > clear
> > on
> >         what it is and is not capable of doing.
> >
> >         Randy
> >
> >         [..snip..]



More information about the Ipp mailing list