what do you think denial-of-service means?
> 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...
"works" is a funny term for something that causes so many problems.
but as I said, it's not appropriate for IPP to make such assumptions
about the operating environment.
> > 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...
I don't see why; it's very relevant to the subject of printing and
other printer protocols have supported it in the past. (the Imagen
protocol comes to mind). It's an important problem, it needs a
standard vendor-independent solution, and I'd certainly be happy
to see IPP propose one.
> > 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!)
nothing prevents anyone from implementing basic. as far as I'm concerned,
the IPP group can even make basic mandatory if it wants to. but regardless
of whether basic is required, there must be at least one mandatory
authentication mechanism that doesn't compromise passwords.
> > > 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.
authentication is part of the protocol, because you need it to protect
precious resources. if you don't have authentication, you don't
interoperate.
> 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.
nobody has said that basic has to be abandoned entirely.
> 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.
this is a very limited view of "interoperability". you can interoperate
only if you're willing to accept large security risks.
> In order to promote the most interoperability possible, we need to
> mandate that IPP clients support both Basic and Digest authentication.
fine w/me if IPP wants to do that.
> > > 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?
many people, I suspect, would consider that misleading advertising.
a reasonable implementation would allow admins to set up users to
use either digest (with separate password) or basic (with either the
system-native password or a separate password - because you really
don't want to compromise your system-native passwords by exposing
them to basic authentication)
> > 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.
I'm not even going to argue with you about this. The bottom line
is that IPP will not get a standard out of IETF unless it provides
a minimum level of security.
Keith