Michael,
Thanks for your explanation, I think it helped to clarify your concerns to
everybody.
There have been a number of similar discussions both in the WG and in many
other IETF WGs that I have seen.
I think we are talking about what the standard will require vs. for what
environment you intend to implement your product.
The IETF always insists that its standards have to work over the worldwide
Internet and on any platform, even if they may equally well be used in a
more restricted environment such as an intranet, or for a particular
platform, which may not need all the features required by the standard.
In this case, I would expect that any product that wants to CONFORM TO THE
STANDARD actually implements the Digest Authentication feature. If you
expect that your specific customers, may not want to use Digest in their IPP
printers, you can leave it as a configuration option to deselect the use of
Digest at installation time.
Your other option is to build a product that DOES NOT CONFORM TO THE
STANDARD, and we have seen many examples of that too for other IETF
standards. That hasn't generally moved the IETF to relax their standards.
> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Wednesday, April 07, 1999 6:48 AM
> To: Carl-Uno Manros
> Cc: ipp at pwg.org> Subject: Re: IPP> PRO - Issue 32: Use of Basic & Digest Authentication
>>> Carl-Uno Manros wrote:
> >
> > Michael,
> >
> > Can you please explain a bit better what you mean, after all we are
> > trying to define a platform independent Internet standard, and the
> > IETF is very strict on security these days.
> >
> > Are you saying that the Digest Authentication mechanism is totally
> > broken?
> > ...
>> OK, lets say that Operating System XYZ provides user-level access
> control via a username and a password. Typically the username is
> stored as cleartext, but the password is encrypted. The encryption
> varies, but the most prevalent ones are 1-way hashes like the UNIX
> crypt().
>> With Digest authentication you can end up with a very hard to spoof
> method of authentication based upon an MD5 sum of the username,
> password, realm, a server-defined nonce value, and (with some HTTP
> implementations) the document data in the HTTP request. This
> necessarily requires that the server either store the password as
> cleartext or keep an MD5 sum of the username, password, and possibly
> the realm in its password file in order to perform authorization.
>> Now, since the operating system only stores the encrypted password,
> it is impossible for the HTTP server to use that password unless it
> has been "encrypted" using an MD5 sum!
>> In order to support existing non-MD5 based operating system access
> control, we need to allow Basic authentication as a valid method and
> not force Digest for all authentication. Certainly we should urge
> implementers to support Digest, but to force it will make IPP-based
> products unnecessarily difficult to administrate, especially since IPP
> (and HTTP) do not define a standard administration interface.
>> While Basic authentication is definitely *not* spoof-proof, it is
> perfectly adequate for closed or restricted-access networks where you
> have a known set of users. Any spoof attack can be quickly tracked to
> the real user, and attacks on other network resources (user accounts,
> etc.) can similarly be tracked.
>> In summary, IPP should allow for as little or as much security as is
> required, with the emphasis (short of a mandate) on more security. It
> should be sufficient to require Basic and Digest support in all IPP
> clients and recommend Digest support in IPP servers for
> authentication. That way clients will be able to function with all
> servers, and servers will be able to implement the most appropriate
> or convenient method of authentication as desired by the
> administrator.
>> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mike at easysw.com> Printing Software for UNIX http://www.easysw.com>