IPP> Security proposal

IPP> Security proposal

IPP> Security proposal

Philip Thambidurai pthambi at ibm.net
Sat Nov 8 09:36:19 EST 1997


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