Keith Moore wrote:
> ...
> 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
Well, if company A had an IPP printer on the Internet with no
password, and company B sent a job to company A's printer, how would
company B get the printout short of breaking into company A's
facilities (at which point they might be able to steal the printer
anyways...)
Many companies do have their printers accessable via the Internet
already, but employ IP-based access control and firewalls to control
access to authorized systems. Obviously this isn't the best method
of access control, but it works...
> 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.
Distributed authentication/quota stuff is beyond IPP's domain...
> 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.
Let me say this again - if you require Digest and alienate Basic,
then IPP interoperability and usability will suffer. NO large site
will use Digest because of the increased administration load, and
then NO authentication will be used (or you'll end up with a lot of
incompatible IPP implementations because they can't implement Digest!)
> > 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.
Interoperability != authentication or security.
At the present time, I know of NO HTTP server product that implements
Digest completely according to the final HTTP/1.1 draft, and NO
operating system that uses MD5 sums for its access control files.
Obviously the HTTP server situation will change over time, but until
you either have 1) a standard for common access control using Digest
or 2) given sufficient time for developers to create the user and
admin tools needed to support Digest properly, then forcing Digest
and abandoning Basic entirely is not an acceptable solution.
Basic is not a secure authentication method. Noone is arguing that
point.
HOWEVER, Basic authentication can be integrated into an existing
authorization system while Digest cannot (unless the authorization
system uses MD5 sums...) Clearly this gives Basic greater
interoperability than Digest, at least in the short term.
In order to promote the most interoperability possible, we need to
mandate that IPP clients support both Basic and Digest authentication.
Servers can then choose the method that works best, with a
recommendation that new implementations be based off Digest whenever
possible.
The purpose of the IPP group and IETF is to define a standard, not
(en)force security. Clearly security and authorization need to be
addressed, but once you require things that can't be done the standard
is doomed.
> ...
> > 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.
So I can advertise that my server accepts digest, and oh by the way
since I don't have any MD5 passwords I can't authorize any access?
"Oh, our server handles Digest, it just denies all access!"
> 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)
IPP should mandate Digest and Basic in IPP clients. IPP should not
mandate any authentication in the server. Period. IESG/IETF has
no right or charter to determine the security requirements of people
using Internet standards, only to describe standard methods for
implementing security/authorization.
If all clients support Digest and Basic authentication, then they
will work with any server that implements one of them. The client
can determine 1) what type of authentication to use, and 2) if it
should use Basic or not (based on user or admin preference).
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com