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

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

harryl at us.ibm.com harryl at us.ibm.com
Fri Apr 9 10:16:21 EDT 1999



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
harryl at us.ibm.com



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

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





All,

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

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
next
week, and any further discussion on the DL of course. It is really quite
simple:

A) ALL Clients and ALL Printers MUST implement Digest (my earlier
suggestion)
   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 :-)

Carl-Uno

> -----Original Message-----
> From: Keith Moore [mailto:moore at 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
>






More information about the Ipp mailing list