> Keith Moore wrote:
> > ...
> > neither does it cost much to implement, and requiring every
> > conforming client and server to implement digest will at least
> > provide one way for users to authenticate to printers without
> > compromising their passwords. This certainly seems better than
>> It costs a *lot* to implement it! Consider that you need to provide
> not only the MD5 code in the client and server (which is trivial),
> but you also may need to update the HTTP server to handle the digest
> information *after* the request data has been received, and you have
> to provide user and administrator tools for managing accounts and
> passwords.
okay, point taken. (I am accustomed to command-line interfaces for
such tools, which are easy to implement and very flexible; but I
admit that most customers will want GUIs, and this drastically
increases implementation complexity.)
> We should require no type of authentication in the servers. Certainly
> there will be a large number of printers that (because of limited
> resources) are unable to maintain a list of users and their passwords.
it's hard to imagine that an internet-connected printer doesn't
require any authentication at all, since there's a large potential
for denial-of-service/theft-of-service. but it would clearly be
desirable to allow an IPP printer to ask an authentication server
whether a particular user's credentials were valid and whether
that user had permission / quota to print.
and if we need authentication in IPP printers, then we need to
for the standard to ensure minimum interoperability. and we won't
accept a minimum interoperability standard that makes it easy for
an eavesdropper to discover a password.
> IPP clients must be able to handle Basic or Digest authentication as
> needed. IPP servers should handle Digest and/or Basic (with the
> emphasis on Digest), but should not be forced into a specific type
> of authorization.
disagree emphatically with the last statement. we have to have some
basis for interoperability.
> > To put it another way: To make basic authentication "safe" you need
> > to protect the entire network over which such credentials might
> > be transmitted. To make digest authentication "safe" you need
> > only to protect the server that stores the credentials. It's
> > usually easier to protect a single server machine, than the network
> > that supports the same number of users.
>> True, however to eavesdrop on network traffic that is confined to a
> LAN you need to be on that LAN, which means that if there is a breach
> of security you can usually track down the offender.
we're talking about the Internet here, not a LAN. Internet standards
should not be making assumptions that external traffic will not be
permitted by the local environment. There are too many reasons why
it's desirable to allow (at least some) external traffic, there
are too many problems caused by the mechanisms that are employed,
to filter it, and there is too much variation between different
operating environments.
> > However, a bit of clarification may be in order: although support
> > for digest authentication is required for HTTP/1.1, nothing says
> > that digest authentication must be available for all principals
> > under all conditions. A server may support both basic and digest
>> If the spec says something is required (MUST) for compliance, then you
> have to implement it to be compliant.
yes, you have to implement it. but you don't have to implement it
for all users in the UNIX password file.
on the other hand, nothing says that digest has to be the mandatory
mechanism for 1.1. if, the IPP group wants to make it, say, basic
authentication protected by TLS with 56-bit DES, IESG would probably
consider that. (though given Moore's law, in a few years DES will
not be adequate even for casual use)
Keith