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

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

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

Paul Moore paulmo at microsoft.com
Thu Apr 8 21:17:15 EDT 1999


So no matter whether we think it makes sense or not the overriding thing is
to get an IETF standard

-----Original Message-----
From: Manros, Carl-Uno B [mailto:cmanros at cp10.es.xerox.com]
Sent: Thursday, April 08, 1999 5:44 PM
To: Keith Moore; Michael Sweet
Cc: Manros, Carl-Uno B; IETF-IPP
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