> -----Original Message-----
> From: Michael Sweet [mailto:mike at easysw.com]
> Sent: Monday, April 12, 1999 12:52 PM
> To: Paul Leach
> Cc: Larry Masinter; Paul Moore; IETF-IPP
> Subject: Re: IPP> Re: PRO - Issue 32: Use of Basic & Digest
> Authentication
>>> 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.
That's not a productive line of reasoning. Nothing is secure by that
criterion -- no known security mechanism is proof against every known
attack. Any given mechanism is only secure against _particular_ attacks.
>> > > 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.
Then what are you arguing about? Just say "IPP requires RFC 2069", and let
the market decide how much of it is enough to be secure enough. Since it has
options that prevent replay and support message integrity, when isn't that
good enough?
Paul