I just don't want printing on the Internet to be any more difficult or
constrained (necessarily) than Faxing is today, as an analogy. You tell me
your fax number, I "fax" you. I tell you my printer URL, you "IPP" me. Is
there a reason we'd want it to be more difficult? A full pyramid of
security options on top of that (based on standards so we can actually
interporate) is great and will make IPP more viable in a myriad of
enterprise, campus and government security scenarios.
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
"Manros, Carl-Uno B" <cmanros at cp10.es.xerox.com> on 04/09/99 10:57:14 AM
To: Harry Lewis/Boulder/IBM, "Manros, Carl-Uno B"
<cmanros at cp10.es.xerox.com>, IETF-IPP <ipp at pwg.org>
cc: Keith Moore <moore at cs.utk.edu>, Michael Sweet <mike at easysw.com>
Subject: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest Authentication
Harry,
I tried to explain this to Michael before.
The MUST requirement would be for the functionality to be in your IPP
product.
Your customer is however free to configure the IPP Printer to never issue
any Basic
or Digest challenges. Please note that this is also impacted by the
solution
we will come up with for Issue 2 on our list, but I don't think that the
client
should ever by allowed to DICTATE the server behavior in this respect.
Carl-Uno
> -----Original Message-----
> From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
> Sent: Friday, April 09, 1999 7:16 AM
> To: Manros, Carl-Uno B; IETF-IPP
> Cc: Keith Moore; Michael Sweet
> Subject: RE: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
>>>>> 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
> >
>>>