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

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

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Fri Apr 9 12:44:56 EDT 1999


Paul,

You are right. You got your preferred version IPP/1.0 as Experimental.

The IPP WG charter states that the WG is tasked to produce a standard for
Internet printing.

We are now making the IETF standard track version IPP/1.1, based on well
known and long standing requirements from the IESG.

Carl-Uno

> -----Original Message-----
> From: Paul Moore [mailto:paulmo at microsoft.com]
> Sent: Thursday, April 08, 1999 6:17 PM
> To: 'Manros, Carl-Uno B'; Michael Sweet
> Cc: IETF-IPP
> Subject: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
> 
> 
> 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