Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length

Heikki Vatiainen <hvn@radiatorsoftware.com> Fri, 27 January 2023 11:18 UTC

Return-Path: <hvn@radiatorsoftware.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731C6C14CE27 for <emu@ietfa.amsl.com>; Fri, 27 Jan 2023 03:18:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=radiatorsoftware-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXfJWpxtfo7A for <emu@ietfa.amsl.com>; Fri, 27 Jan 2023 03:18:16 -0800 (PST)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B82DC14F72D for <emu@ietf.org>; Fri, 27 Jan 2023 03:18:16 -0800 (PST)
Received: by mail-ej1-x62e.google.com with SMTP id vw16so12707681ejc.12 for <emu@ietf.org>; Fri, 27 Jan 2023 03:18:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Qgw2WpS4EeXpFNtqD5foE+x4dmBZ7jN790X1649rbgE=; b=P/T5OkJY/xGve4ER9yuBd/H7eC7ZbP1zWFFWtMQt0y0eoCFz3+6WlsF53rth5LU/XR Ho2/Lv16s+tPqZX9FvW0WmgxZ/RXSTbASXQ6uYwmt/1FfjV1OfJbyzPrQbPG8XPQUmYc 9g8ntwMhfFfac/ajBwwgLbatJgy64E9O/huCENQmbouqKr1Mf3C7fqeLx37DquL/YDFM PBdFo9GZb2zhB+MkK56/V5EL+R40UVYnZIlDNUmLSrTZ+7gfx0PBdflhTTBmHu/O6LIm IViAKnu2EFtRxqoRZvQ7n0Q31rBJ86l/Yv4riQKUQQc0Rg9xXtjfwnHiBvAZwdjqKg1S iUGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Qgw2WpS4EeXpFNtqD5foE+x4dmBZ7jN790X1649rbgE=; b=vwStLRd1PCW2eoRqvymAPpd7LJsawAOEgefpvaH4oql5KkxLKkiMulKDq+BH5CsqpD RpfTG4U/RSI8ZuW15nFgsmXjNDScIj0dtlwqDz+ZkOLqATHusW6q4A7EHEECU6JSrQgu g1oGjyhaHahRuWrcbBcIZcjt7lLuxcV5HnRne6D3i+YQ+uYDJB6Qya4e/DqGMIrRdzuZ p9V6cjdfstPikcMxTdrkSPb+hgDed2nFOcC+z8eR3de9iPt9VnsJulKyXaWx+ZywYvlJ /AG0e89ko4V3Z1prIZ7sTrKZM4FrdBM+S8l2h/99xszRVyqUzT1mcH5IFVzhr7zNCiBW rLsw==
X-Gm-Message-State: AFqh2kpnzrTyooKumpnTb0EEX61aQRYTjsLXQujmS9z6agZAotMHtVRj dpmf8TJEIH/jVRieb3MZxWPxsV0eKJVUaVZ/6HPi51Jvvc8SWdKC
X-Google-Smtp-Source: AMrXdXtzB78hv+Aers/i5ZnzJvzS7IDXOcloksRAIhk9OwKJ6k/vmZ4STfpEd/pPjx8rWgjRp6SpiUYNwU/sBw3UpY4=
X-Received: by 2002:a17:906:b750:b0:877:9ea9:2792 with SMTP id fx16-20020a170906b75000b008779ea92792mr5120409ejb.123.1674818294775; Fri, 27 Jan 2023 03:18:14 -0800 (PST)
MIME-Version: 1.0
References: <9A85E1BF-4CBF-4D3F-98F9-A07D496F7759@deployingradius.com> <DB6PR0701MB304746750BFA21068CB8B23489CE9@DB6PR0701MB3047.eurprd07.prod.outlook.com>
In-Reply-To: <DB6PR0701MB304746750BFA21068CB8B23489CE9@DB6PR0701MB3047.eurprd07.prod.outlook.com>
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Fri, 27 Jan 2023 13:17:58 +0200
Message-ID: <CAA7Lko8=kJnqpB-YNFVTs=E0mpCrcOsEpRePvwkGp-h8dDdw9g@mail.gmail.com>
To: EMU WG <emu@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/17T3cbHFj-HCHOvWaNSlr6tz_uA>
Subject: Re: [Emu] draft-ietf-emu-rfc7170bis-03.txt and password length
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2023 11:18:20 -0000

On Wed, 25 Jan 2023 at 10:21, John Mattsson
<john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
>
> That sounds good. Would be good to have text stating that passwords of length 255 characters (the current max) shall be allowed. Requiring a minimum length of 8 or a least 6 characters would be good.

Basic-Password-Auth-Resp TLV is used for non-password purposes too.
The RFC and draft call these "housekeeping" functions. Because the TLV
is used for both password authentication and housekeeping functions, I
wouldn't say much about minimum length. 4 digit PINs are still used
and various OTP systems may use a dialogue where the password field is
used to transport a response that directs how the OTP protocol
proceeds.

For example, an OTP system could do this:
- Start authentication with username + static password; if ok then
- Server prompts for the next method: Choose 1 for push to mobile app,
2 for telephone callback, 3 for emergency use pre-printed code. Leave
password empty for the default method (not mandatory: can always
choose one of 1-3).
- The next server response then depends on what was chosen by the user

The above may need to run as one exchange without any
Intermediate-Result TLV between static password and OTP dialogue
because it gets proxied as Radius PAP to "Inner Method server" as
described in section 2.1 of the draft. The RADIUS, and Diameter, RFC
appears not to say empty passwords are not supported, therefore
rejecting zero length Password field in Basic-Password-Auth-Resp TLV
may be problematic with interoperability.

I wouldn't mind being able to mandate non-zero length passwords, but
I'm not sure if this is the right place to do it.

Regarding interoperability, the Radius and Diameter RFCs restrict
User-Password, and therefore unencrypted password, length to less than
253, the maximum User-Password attribute payload length for Radius [1]
and [2]. Should we consider Radius and Diameter interoperability if we
give guidance for Basic-Password-Auth-Resp TLV password length?

[1] https://www.rfc-editor.org/rfc/rfc2865#section-5.2
[2] https://www.rfc-editor.org/rfc/rfc7155.html#section-4.3.1

-- 
Heikki Vatiainen
hvn@radiatorsoftware.com