From nobody Tue Mar 14 02:25:07 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PbHS42fYDz3yWmX for ; Tue, 14 Mar 2023 02:25:24 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PbHS25Tmfz3vSv for ; Tue, 14 Mar 2023 02:25:22 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ej5piTX3; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x1033.google.com with SMTP id p13-20020a17090a284d00b0023d2e945aebso153833pjf.0 for ; Mon, 13 Mar 2023 19:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678760720; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=EhQu9sRQ3OHHEn45RW2DxCN2ZU0HVOnuJV9Ymoi2k80=; b=ej5piTX3hYzI8ZdIG7K8tmJw2GlmHepGrSLS+MvohyM7ckkLkmKPL3ecBjr3OkAbf6 tG4xoJ8RTi6QeHw6PVdqRFjFGGrDWWlNyXtlRKFaSdswhpM4tWfvdPugsCofC6doIGzZ VqEbfmDXMO8LG5ym1HVx4FyGy6BA4BVD4cH357/wNQ8M35BvYeUJ2EY9wmzDLQ8JsJ7u RL/fzhwiLrvIzPdKGyvlqX1hmdIrKT8RhwdByweHhFGtbGmeovOm6gggob7dUgfFOnN2 EkHAwQ8EDbfr+oeww2hQi6EB6sKgrmoYCJGGM1dJq7YoJRZOf4CoFxvLyiy+q/Er1HPG XxNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678760720; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=EhQu9sRQ3OHHEn45RW2DxCN2ZU0HVOnuJV9Ymoi2k80=; b=QVMpoa5MiabWiMvaz9Vmu2af4Z4B/K9JXbYoe568RJ51OVBBjYqONksPEcd6nGW0C3 yZ6dL8ZrjudloKmsFoWQ6VT0DMf6BzeTPzOaihIoFxuSmbDs86iyDE3tO+vzfJ7oiRBh xGcBSl6Rz79pwNfGjje9ElZegue11AbnWKdB4gIMkaHMIywgcwLPVvufYyTNt18VkIOd 30jfkMmrzKPngyr8PP9kd6m0LL9Pepn1HrvWhtu2PnN0tAzlh8FxxLf7U/tkLu1/N9RA Y838YY9464vIyEYE4/N3UZaYwet8cIAHeoFvIeYTp4jebZS3lEznET4RTAsLId4jebe8 lOAw== X-Gm-Message-State: AO0yUKXZ1FCogVY1KdnokwOZvMb4l6LeOg8pOdlVkz85whBuIgrvCeZA v8D/uUeTKV3s62P+kwveOJLgY+OXvuQAWhlUEMRcJxCZhffp X-Google-Smtp-Source: AK7set92E/m6RsL5h2wjgyTbEzuW9zVw8IKM6vmLjCX/Z/oAROz6BbivyNFVl+gq/48C7l2969htnCTsst4nb4KyqE8= X-Received: by 2002:a17:903:33cd:b0:19f:3cc1:e3b9 with SMTP id kc13-20020a17090333cd00b0019f3cc1e3b9mr2490744plb.4.1678760720585; Mon, 13 Mar 2023 19:25:20 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 From: Rick Macklem Date: Mon, 13 Mar 2023 19:25:07 -0700 Message-ID: Subject: RFC: A new NFS mount option to encourage use of Kerberized mounts To: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.73 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; NEURAL_HAM_SHORT(-0.75)[-0.751]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1033:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PbHS25Tmfz3vSv X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi, I have implemented a new mount option for NFSv4.1/4.2 mounts that I hope will encourage use of Kerberos and TLS to help secure NFS mounts. Although I do not know why users choose to not use Kerberized NFS mounts, I think that the administrative issues related to the "machine credential" is a factor. This new option, which I have called "syskrb5" (feel free to suggest a better name), avoids the need for a Kerberos machine credential. I discussed doing this type of mount on the IETF and Linux nfs mailing lists and there seemed to be support for the concept. Without this patch, a Kerberized NFSv4.1/4.2 mount must provide a Kerberos credential for the client at mount time. This credential is typically referred to as a "machine credential". It can be created one of two ways: - The user (usually root) has a valid TGT at the time the mount is done and this becomes the machine credential. There are two problems with this. 1 - The user doing the mount must have a valid TGT for a user principal at mount time. As such, the mount cannot be put in fstab(5) or similar. 2 - When the TGT expires, the mount breaks. - The client machine has a service principal in its default keytab file and this service principal (typically called a host-based initiator credential) is used as the machine credential. There are problems with this approach as well: 1 - There is a certain amount of administrative overhead creating the service principal for the NFS client, creating a keytab entry for this principal and then copying the keytab entry into the client's default keytab file via some secure means. 2 - The NFS client must have a fixed, well known, DNS name, since that FQDN is in the service principal name as the instance. This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which allows the state maintenance operations to be performed by any authentication mechanism, to do these operations via AUTH_SYS instead of RPCSEC_GSS (Kerberos). As such, neither of the above mechanisms is needed. This new NFSv4.1/4.2 mount option, called "syskrb5" must be used with "sec=krb5[ip]" to avoid the need for either of the above Kerberos setups to be done by the client. Note that all file access/modification operations still require users on the NFS client to have a valid TGT recognized by the NFSv4.1/4.2 server. As such, this option allows, at most, a malicious client to do some sort of DOS attack. Although not required, use of "tls" with this new option is encouraged, since it provides on-the-wire encryption plus, optionally, client identity verification via a X.509 certificate provided to the server during TLS handshake. Alternately, "sec=krb5p" does provide on-the-wire encryption of file data. So, does this sound like something that should be committed to FreeBSD? Thanks for any comments, rick