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
>