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@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@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@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
> >
>