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

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

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

Michael Sweet (mike@easysw.com)
Mon, 12 Apr 1999 15:51:52 -0400

Paul Leach wrote:
> ...
> No, protection against passive attacks has nothing to do with any of
> those things. A replay attack could exploit slowly changing nonces,
> but it's an active attack. If message body is not authenticated, you
> could change the message body, but that's an active attack, too.
>
> It appears to me that you are using an incorrect definition of
> "passive attack".

It's at least different than your definition. Irregardless, my point
still stands - Digest without message body authentication is still
susceptable to attack and can't be considered "secure" by any stretch
of the imagination. *More* secure than Basic, but definitely not
secure.

> > The Apache Digest authentication module, for example, seems to
> > accept any incoming nonce value for authorization.
>
> So what?

Apache is just one example, and I'm sure there are a lot of servers
out there that have similar limitations. The point is, MOST IPP
implementations will rely on an existing server (one that the vendor
has already implemented or licensed), so we have to be careful about
requiring too much too soon (otherwise IPP will not be accepted by
the industry at-large and we'll have yet another useless "standard"
that no one uses!)

> Just because RFC 2069 has options, doesn't mean that IPP has to
> allow the use of less-secure ones. There is no reason that the IPP
> spec for security can't mandate that nonce-count is used (so nonces
> change every time), and the message integrity is used (if those are
> what the WG decides are needed to meet its security objectives).

Unless absolutely required by the IETF, I'd be very much against any
such wording. This whole discussion should be proof enough that one
person's "secure" solution can be seen as inadequate or unsecure by
another.

Let the implementers decide what options are necessary and
appropriate, and if stronger language is requested by the IETF add it
as a recommendation and not a requirement.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com