Re: [OPSAWG] Question regarding RFC 7860: Password mechanism

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Tue, 19 November 2019 04:37 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0AD12008A for <opsawg@ietfa.amsl.com>; Mon, 18 Nov 2019 20:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pwouOtX4CFW for <opsawg@ietfa.amsl.com>; Mon, 18 Nov 2019 20:37:01 -0800 (PST)
Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C49412006F for <opsawg@ietf.org>; Mon, 18 Nov 2019 20:37:01 -0800 (PST)
Received: by mail-pg1-f182.google.com with SMTP id b10so2192872pgd.4 for <opsawg@ietf.org>; Mon, 18 Nov 2019 20:37:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9zTkwuOG/llpigFsHhvWfscQyYNIomTrQ42Afm1A49Y=; b=jHLUMwbLHznFAz+rnkPLU9M8Xt/nN1JjyA6K4J94KSqkdOtiwUt1mtQU3MIlzaZfPZ vMnoQRNicz/QPwyrYqqZ4LOqWEJzeoy8RdwE/RVmj8lTYCRbao7fm2/7GtZH7gmlvP5w Zb6uLaP5mSAgbwEP9h+8ZcrfwgVChCrgX0MLZaQbz/4h++eQoR9ddBxoKQh95H29Mp7K +Mb915Z880+trQ/ob+xQiCD/9KZvo6sEQ47LPrgwGh688HQ1raIEm2Hoq4TggnWnMszC m++8JHTDL9gJtpPKwsm0lvSOQpAcTr1VFnL0cc8Jy+Ou0NIhlJXLNwhp0V8b+GQdIRgI Hsfw==
X-Gm-Message-State: APjAAAXzJuV8X4VmwIN6z8gb7ROjYuR1J6MxlR0wHl8lOe5sY5suck/U /Fi1/m2Umyn6p0YJGwwF7INIdD5+4Oo=
X-Google-Smtp-Source: APXvYqySmx9u3zaXBytRgeOqNN1ehgdM9F9LYDp/g8OH6gpjmVZXG9NlouqKV8MWesJ3L2/qys2pNg==
X-Received: by 2002:aa7:93cd:: with SMTP id y13mr3345805pff.240.1574138220367; Mon, 18 Nov 2019 20:37:00 -0800 (PST)
Received: from [192.168.1.109] (c-73-231-235-186.hsd1.ca.comcast.net. [73.231.235.186]) by smtp.gmail.com with ESMTPSA id i102sm1174203pje.17.2019.11.18.20.36.59 for <opsawg@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 20:36:59 -0800 (PST)
To: opsawg@ietf.org
References: <CALjx-Cd9US-HfctyRXG-F2qkR9Zw5uw0EbOCKB=Ei7WP1pb+Kg@mail.gmail.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Message-ID: <5DD3716F.2030708@alumni.stanford.edu>
Date: Mon, 18 Nov 2019 20:37:03 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CALjx-Cd9US-HfctyRXG-F2qkR9Zw5uw0EbOCKB=Ei7WP1pb+Kg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/mTUPcz7p4WRZLDcK47D45p9nxAc>
Subject: Re: [OPSAWG] Question regarding RFC 7860: Password mechanism
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2019 04:37:03 -0000

Hi -

On 11/18/2019 7:07 PM, Greg MacLellan wrote:
> I just came across RFC 7860 while looking for updates to the SNMPv3
> authentication models.
>
> It's good to see updated hash algorithms, however, I'm confused by
> several aspects of section 9.3, Derivation of Keys from Passwords:
>
> 1. Why is the word "SHOULD" used for this specification? There is no
> alternative given, and if two systems use a different procedure, they
> will be unable to authenticate successfully. It seems like "MUST" would
> be appropriate here.

The view that prevailed during the SNMPv* wars was that
we shouldn't be *mandating* key localization, despite the
obvious operational benefits of doing so.  The view was also
that even if key localization was a wonderful thing, that we
shouldn't be mandating the use of a specific algorithm.  The
end result was that RFC 3414 has appendices with really useful
examples that, as a matter of operational sanity, people have
treated as though they were actually required by the standard.

As a matter of *interoperability* (rather than operational sanity)
it doesn't matter whether a key localization algorithm was even
used to produce the keys used in an SNMPv3 deployment, so the
use of passwords is technically beyond the scope of the standard's
requirements.  Some of us (including me) would have liked to
nail it down much more firmly than that, but as a practical
matter the compromise text seems to have gotten the job done.

> 2. It specifies using the password-to-key algorithm from RFC 3414,
> however, it seems like this algorithm has no technical merit, and I
> cannot find any basis for why this is a good idea. Using a predictable
> 1MB input to the hash /lowers /its security as compared to using the
> input directly, as it drastically lowers the effective entropy. For
> example, the passwords "abc" and "abcabc" and "abcabcabc" are now
> equivalent. In addition, there is a performance cost for doing this, but
> without the full security benefits of an actual "slow-hash" (such as
> scrypt, bcrypt or PBKDF2).

The more elaborate HMAC used with SNMPv3, chosen to overcome
the deficiencies of the MAC used in RFC 1352 and RFC 1446, appeared
in RFC 2264 and subsequent SNMPv3 documents.  My recollection
is that given the processing power and storage capability available
two decades ago, making the password-to-key computation expensive
was thought to add more to a defense against dictionary attacks
than the reduction in the theoretical size of the password space
would detract from it. Uri Blumenthal probably remembers the details
of his analysis.  The 8-character minimum length requirement for
passwords also undercuts the objection that the algorithm "collapses"
too many passwords.

> 3. The algorithm then says to combine `digest1 + snmpEngineID + digest1`
> -- why do this instead of simply `digest1 + snmpEngineID`? Once again,
> this incurs a performance cost but does nothing to increase the entropy
> or resistance to brute-force attacks.

As I recall...
This was due to concerns about how MAC algorithms work.  Two decades
ago some had concerns that a MAC code might reveal too much about
the most "recent" bits fed to the algorithm.  This concern is heightened
considering some deployments where the snmpEngineID values might differ
from each other in predictable ways involving only a few bits.  By
giving the digest (computed entirely from private information) to the
algorithm both before and after the (effectively public) snmpEngineID
value would be processed, those fears were reduced.  Again, folks like
Uri Blumenthal can speak to the goriest details and might remember the
debates better than I do.

Randy