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