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..]