...jay
Randy Turner wrote:
>
> 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..]