IPP Mail Archive: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

IPP Mail Archive: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication

Fri, 9 Apr 1999 08:16:21 -0600

Throughout this thread... is Anonymous a valid default? I don't have a
problem with hammering out the security framework for IPP but I do have a
problem if I can't put a printer on the internet and allow anyone to print.

Harry Lewis
IBM Printing Systems

"Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com> on 04/08/99 06:44:01 PM

To: Keith Moore <moore@cs.utk.edu>, Michael Sweet <mike@easysw.com>
cc: "Manros, Carl-Uno B" <cmanros@cp10.es.xerox.com>, IETF-IPP
<ipp@pwg.org> (bcc: Harry Lewis/Boulder/IBM)
Subject: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication


This has been a long and interesting thread, some of which is a repeat from
earlier discussions.
I tend to put higher weight on the statements from Keith Moore as our Area

I have checked the latest documentation from the IETF-HTTP WG and this is
what I found:

1) Both Basic and Digest are OPTIONAL for use with HTTP/1.1

2) Although Basic is still in the Digest Authentication draft, there are
lots of reasons mentioned why you should NOT use it, and that using it on
its own totally useless.

I think this is our decision flow chart for our face-to-face discussion
week, and any further discussion on the DL of course. It is really quite

A) ALL Clients and ALL Printers MUST implement Digest (my earlier
Basic could be an OPTION
YES = Goto D) NO = Goto B)

B) ALL Clients and ALL Printers MUST implement Basic, AND TLS to create a
secure channel over which Basic can be used.
Digest could be an OPTION.
YES = Goto D) NO = Goto C)

C) We WILL NOT get an IETF IPP standard :-(

D) Chances are high that we WILL get an IETF standard :-)


> -----Original Message-----
> From: Keith Moore [mailto:moore@cs.utk.edu]
> Sent: Thursday, April 08, 1999 6:55 AM
> To: Michael Sweet
> Cc: Keith Moore; Manros, Carl-Uno B; IETF-IPP
> Subject: Re: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
> > 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...)
> 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