diff mbox series

[v2,15/41] SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES

Message ID 167380331214.10651.11224254824457738270.stgit@bazille.1015granger.net (mailing list archive)
State New, archived
Headers show
Series RPCSEC GSS krb5 enhancements | expand

Commit Message

Chuck Lever Jan. 15, 2023, 5:21 p.m. UTC 
From: Chuck Lever <chuck.lever@oracle.com>

Because the DES block cipher has been deprecated by Internet
standard, highly secure configurations might require that DES
support be blacklisted or not installed. NFS Kerberos should still
be able to work correctly with only the AES-based enctypes in that
situation.

Also note that MIT Kerberos has begun a deprecation process for DES
encryption types. Their README for 1.19.3 states:

> Beginning with the krb5-1.19 release, a warning will be issued
> if initial credentials are acquired using the des3-cbc-sha1
> encryption type.  In future releases, this encryption type will
> be disabled by default and eventually removed.
>
> Beginning with the krb5-1.18 release, single-DES encryption
> types have been removed.

Aside from the CONFIG option name change, there are two important
policy changes:

1. The 'insecure enctype' group is now disabled by default.
   Distributors have to take action to enable support for deprecated
   enctypes. Implementation of these enctypes will be removed in a
   future kernel release.

2. des3-cbc-sha1 is now considered part of the 'insecure enctype'
   group, having been deprecated by RFC 8429, and is thus disabled
   by default

After this patch is applied, SunRPC support can be built with
Kerberos 5 support but without CRYPTO_DES enabled in the kernel.
And, when these enctypes are disabled, the Linux kernel's SunRPC
RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649
and BCP 218 / RFC 8429.

Tested-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
 net/sunrpc/Kconfig                    |   54 +++++++++++++++++++++--------
 net/sunrpc/auth_gss/gss_krb5_mech.c   |   27 +++++++++++---
 net/sunrpc/auth_gss/gss_krb5_seal.c   |   62 ++++++++++++++++++---------------
 net/sunrpc/auth_gss/gss_krb5_unseal.c |    3 +-
 net/sunrpc/auth_gss/gss_krb5_wrap.c   |    4 ++
 5 files changed, 101 insertions(+), 49 deletions(-)

Comments

Geert Uytterhoeven March 6, 2023, 8:16 a.m. UTC | #1 
Hi Chuck,

On Sun, 15 Jan 2023, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> Because the DES block cipher has been deprecated by Internet
> standard, highly secure configurations might require that DES
> support be blacklisted or not installed. NFS Kerberos should still
> be able to work correctly with only the AES-based enctypes in that
> situation.
>
> Also note that MIT Kerberos has begun a deprecation process for DES
> encryption types. Their README for 1.19.3 states:
>
>> Beginning with the krb5-1.19 release, a warning will be issued
>> if initial credentials are acquired using the des3-cbc-sha1
>> encryption type.  In future releases, this encryption type will
>> be disabled by default and eventually removed.
>>
>> Beginning with the krb5-1.18 release, single-DES encryption
>> types have been removed.
>
> Aside from the CONFIG option name change, there are two important
> policy changes:
>
> 1. The 'insecure enctype' group is now disabled by default.
>   Distributors have to take action to enable support for deprecated
>   enctypes. Implementation of these enctypes will be removed in a
>   future kernel release.
>
> 2. des3-cbc-sha1 is now considered part of the 'insecure enctype'
>   group, having been deprecated by RFC 8429, and is thus disabled
>   by default
>
> After this patch is applied, SunRPC support can be built with
> Kerberos 5 support but without CRYPTO_DES enabled in the kernel.
> And, when these enctypes are disabled, the Linux kernel's SunRPC
> RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649
> and BCP 218 / RFC 8429.
>
> Tested-by: Scott Mayhew <smayhew@redhat.com>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>

Thanks for your patch, which is now commit dfe9a123451a6e73 ("SUNRPC:
Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES") in v6.3-rc1.

> --- a/net/sunrpc/Kconfig
> +++ b/net/sunrpc/Kconfig
> @@ -19,10 +19,10 @@ config SUNRPC_SWAP
> config RPCSEC_GSS_KRB5
> 	tristate "Secure RPC: Kerberos V mechanism"
> 	depends on SUNRPC && CRYPTO
> -	depends on CRYPTO_MD5 && CRYPTO_DES && CRYPTO_CBC && CRYPTO_CTS
> -	depends on CRYPTO_ECB && CRYPTO_HMAC && CRYPTO_SHA1 && CRYPTO_AES
> 	default y
> 	select SUNRPC_GSS
> +	select CRYPTO_SKCIPHER
> +	select CRYPTO_HASH
> 	help
> 	  Choose Y here to enable Secure RPC using the Kerberos version 5
> 	  GSS-API mechanism (RFC 1964).

While updating my defconfigs for v6.3-rc1, I noticed this change has an
interesting side-effect: if any of the CRYPTO_* algorithms were modular
before, RPCSEC_GSS_KRB5 was modular, too.
After this change, RPCSEC_GSS_KRB5 is promoted to builtin.

This is not necessarily bad in-se, but you might want to be aware of it,
and perhaps change the "default y".

Gr{oetje,eeting}s,

 						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 							    -- Linus Torvalds
Chuck Lever March 6, 2023, 4:17 p.m. UTC | #2 
> On Mar 6, 2023, at 3:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 
> 	Hi Chuck,
> 
> On Sun, 15 Jan 2023, Chuck Lever wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>> 
>> Because the DES block cipher has been deprecated by Internet
>> standard, highly secure configurations might require that DES
>> support be blacklisted or not installed. NFS Kerberos should still
>> be able to work correctly with only the AES-based enctypes in that
>> situation.
>> 
>> Also note that MIT Kerberos has begun a deprecation process for DES
>> encryption types. Their README for 1.19.3 states:
>> 
>>> Beginning with the krb5-1.19 release, a warning will be issued
>>> if initial credentials are acquired using the des3-cbc-sha1
>>> encryption type.  In future releases, this encryption type will
>>> be disabled by default and eventually removed.
>>> 
>>> Beginning with the krb5-1.18 release, single-DES encryption
>>> types have been removed.
>> 
>> Aside from the CONFIG option name change, there are two important
>> policy changes:
>> 
>> 1. The 'insecure enctype' group is now disabled by default.
>>  Distributors have to take action to enable support for deprecated
>>  enctypes. Implementation of these enctypes will be removed in a
>>  future kernel release.
>> 
>> 2. des3-cbc-sha1 is now considered part of the 'insecure enctype'
>>  group, having been deprecated by RFC 8429, and is thus disabled
>>  by default
>> 
>> After this patch is applied, SunRPC support can be built with
>> Kerberos 5 support but without CRYPTO_DES enabled in the kernel.
>> And, when these enctypes are disabled, the Linux kernel's SunRPC
>> RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649
>> and BCP 218 / RFC 8429.
>> 
>> Tested-by: Scott Mayhew <smayhew@redhat.com>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> 
> Thanks for your patch, which is now commit dfe9a123451a6e73 ("SUNRPC:
> Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES") in v6.3-rc1.
> 
>> --- a/net/sunrpc/Kconfig
>> +++ b/net/sunrpc/Kconfig
>> @@ -19,10 +19,10 @@ config SUNRPC_SWAP
>> config RPCSEC_GSS_KRB5
>> 	tristate "Secure RPC: Kerberos V mechanism"
>> 	depends on SUNRPC && CRYPTO
>> -	depends on CRYPTO_MD5 && CRYPTO_DES && CRYPTO_CBC && CRYPTO_CTS
>> -	depends on CRYPTO_ECB && CRYPTO_HMAC && CRYPTO_SHA1 && CRYPTO_AES
>> 	default y
>> 	select SUNRPC_GSS
>> +	select CRYPTO_SKCIPHER
>> +	select CRYPTO_HASH
>> 	help
>> 	  Choose Y here to enable Secure RPC using the Kerberos version 5
>> 	  GSS-API mechanism (RFC 1964).
> 
> While updating my defconfigs for v6.3-rc1, I noticed this change has an
> interesting side-effect: if any of the CRYPTO_* algorithms were modular
> before, RPCSEC_GSS_KRB5 was modular, too.
> After this change, RPCSEC_GSS_KRB5 is promoted to builtin.

I'm not following. Which CRYPTO_ options trigger the behavior?
On my test system, CONFIG_RPCSEC_GSS_KRB5=m and the CRYPTO stuff
is all =y.


> This is not necessarily bad in-se, but you might want to be aware of it,
> and perhaps change the "default y".

Well that might be there to address the need for GSS to be
enabled if NFSv4 support is built. See commit df486a25900f
("NFS: Fix the selection of security flavours in Kconfig")

I'm not claiming I understand exactly how that fix works.

--
Chuck Lever
Geert Uytterhoeven March 6, 2023, 6:01 p.m. UTC | #3 
Hi Chuck,

On Mon, Mar 6, 2023 at 5:17 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
> > On Mar 6, 2023, at 3:16 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sun, 15 Jan 2023, Chuck Lever wrote:
> >> From: Chuck Lever <chuck.lever@oracle.com>
> >>
> >> Because the DES block cipher has been deprecated by Internet
> >> standard, highly secure configurations might require that DES
> >> support be blacklisted or not installed. NFS Kerberos should still
> >> be able to work correctly with only the AES-based enctypes in that
> >> situation.
> >>
> >> Also note that MIT Kerberos has begun a deprecation process for DES
> >> encryption types. Their README for 1.19.3 states:
> >>
> >>> Beginning with the krb5-1.19 release, a warning will be issued
> >>> if initial credentials are acquired using the des3-cbc-sha1
> >>> encryption type.  In future releases, this encryption type will
> >>> be disabled by default and eventually removed.
> >>>
> >>> Beginning with the krb5-1.18 release, single-DES encryption
> >>> types have been removed.
> >>
> >> Aside from the CONFIG option name change, there are two important
> >> policy changes:
> >>
> >> 1. The 'insecure enctype' group is now disabled by default.
> >>  Distributors have to take action to enable support for deprecated
> >>  enctypes. Implementation of these enctypes will be removed in a
> >>  future kernel release.
> >>
> >> 2. des3-cbc-sha1 is now considered part of the 'insecure enctype'
> >>  group, having been deprecated by RFC 8429, and is thus disabled
> >>  by default
> >>
> >> After this patch is applied, SunRPC support can be built with
> >> Kerberos 5 support but without CRYPTO_DES enabled in the kernel.
> >> And, when these enctypes are disabled, the Linux kernel's SunRPC
> >> RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649
> >> and BCP 218 / RFC 8429.
> >>
> >> Tested-by: Scott Mayhew <smayhew@redhat.com>
> >> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >
> > Thanks for your patch, which is now commit dfe9a123451a6e73 ("SUNRPC:
> > Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES") in v6.3-rc1.
> >
> >> --- a/net/sunrpc/Kconfig
> >> +++ b/net/sunrpc/Kconfig
> >> @@ -19,10 +19,10 @@ config SUNRPC_SWAP
> >> config RPCSEC_GSS_KRB5
> >>      tristate "Secure RPC: Kerberos V mechanism"
> >>      depends on SUNRPC && CRYPTO
> >> -    depends on CRYPTO_MD5 && CRYPTO_DES && CRYPTO_CBC && CRYPTO_CTS
> >> -    depends on CRYPTO_ECB && CRYPTO_HMAC && CRYPTO_SHA1 && CRYPTO_AES
> >>      default y
> >>      select SUNRPC_GSS
> >> +    select CRYPTO_SKCIPHER
> >> +    select CRYPTO_HASH
> >>      help
> >>        Choose Y here to enable Secure RPC using the Kerberos version 5
> >>        GSS-API mechanism (RFC 1964).
> >
> > While updating my defconfigs for v6.3-rc1, I noticed this change has an
> > interesting side-effect: if any of the CRYPTO_* algorithms were modular
> > before, RPCSEC_GSS_KRB5 was modular, too.
> > After this change, RPCSEC_GSS_KRB5 is promoted to builtin.
>
> I'm not following. Which CRYPTO_ options trigger the behavior?
> On my test system, CONFIG_RPCSEC_GSS_KRB5=m and the CRYPTO stuff
> is all =y.

On v6.2, "make ARCH=m68k defconfig" gives you
CONFIG_RPCSEC_GSS_KRB5=m
On v6.3, it became builtin, due to dropping the dependencies on
the individual crypto modules.

$ grep -E "CRYPTO_(MD5|DES|CBC|CTS|ECB|HMAC|SHA1|AES)" .config
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_TI=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m

> > This is not necessarily bad in-se, but you might want to be aware of it,
> > and perhaps change the "default y".
>
> Well that might be there to address the need for GSS to be
> enabled if NFSv4 support is built. See commit df486a25900f
> ("NFS: Fix the selection of security flavours in Kconfig")
>
> I'm not claiming I understand exactly how that fix works.

And that was changed again a little bit later in commit
e3b2854faabd1043 ("SUNRPC: Fix the SUNRPC Kerberos V RPCSEC_GSS
module dependencies").

Gr{oetje,eeting}s,

                        Geert
diff mbox series

Patch

diff --git a/net/sunrpc/Kconfig b/net/sunrpc/Kconfig
index bbbb5af0af13..1135ff362132 100644
--- a/net/sunrpc/Kconfig
+++ b/net/sunrpc/Kconfig
@@ -19,10 +19,10 @@  config SUNRPC_SWAP
 config RPCSEC_GSS_KRB5
 	tristate "Secure RPC: Kerberos V mechanism"
 	depends on SUNRPC && CRYPTO
-	depends on CRYPTO_MD5 && CRYPTO_DES && CRYPTO_CBC && CRYPTO_CTS
-	depends on CRYPTO_ECB && CRYPTO_HMAC && CRYPTO_SHA1 && CRYPTO_AES
 	default y
 	select SUNRPC_GSS
+	select CRYPTO_SKCIPHER
+	select CRYPTO_HASH
 	help
 	  Choose Y here to enable Secure RPC using the Kerberos version 5
 	  GSS-API mechanism (RFC 1964).
@@ -34,21 +34,47 @@  config RPCSEC_GSS_KRB5
 
 	  If unsure, say Y.
 
-config SUNRPC_DISABLE_INSECURE_ENCTYPES
-	bool "Secure RPC: Disable insecure Kerberos encryption types"
+config RPCSEC_GSS_KRB5_SIMPLIFIED
+	bool
+	depends on RPCSEC_GSS_KRB5
+
+config RPCSEC_GSS_KRB5_CRYPTOSYSTEM
+	bool
+	depends on RPCSEC_GSS_KRB5
+
+config RPCSEC_GSS_KRB5_ENCTYPES_DES
+	bool "Enable Kerberos enctypes based on DES (deprecated)"
 	depends on RPCSEC_GSS_KRB5
+	depends on CRYPTO_CBC && CRYPTO_CTS && CRYPTO_ECB
+	depends on CRYPTO_HMAC && CRYPTO_MD5 && CRYPTO_SHA1
+	depends on CRYPTO_DES
 	default n
+	select RPCSEC_GSS_KRB5_SIMPLIFIED
+	help
+	  Choose Y to enable the use of deprecated Kerberos 5
+	  encryption types that utilize Data Encryption Standard
+	  (DES) based ciphers. These include des-cbc-md5,
+	  des-cbc-crc, and des-cbc-md4, which were deprecated by
+	  RFC 6649, and des3-cbc-sha1, which was deprecated by RFC
+	  8429.
+
+	  Support for these encryption types is available for
+	  compatibility with legacy NFS client and server
+	  implementations. The default is N which is more secure.
+
+config RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1
+	bool "Enable Kerberos enctypes based on AES and SHA-1"
+	depends on RPCSEC_GSS_KRB5
+	depends on CRYPTO_CBC && CRYPTO_CTS
+	depends on CRYPTO_HMAC && CRYPTO_SHA1
+	depends on CRYPTO_AES
+	default y
+	select RPCSEC_GSS_KRB5_CRYPTOSYSTEM
 	help
-	  Choose Y here to disable the use of deprecated encryption types
-	  with the Kerberos version 5 GSS-API mechanism (RFC 1964). The
-	  deprecated encryption types include DES-CBC-MD5, DES-CBC-CRC,
-	  and DES-CBC-MD4. These types were deprecated by RFC 6649 because
-	  they were found to be insecure.
-
-	  N is the default because many sites have deployed KDCs and
-	  keytabs that contain only these deprecated encryption types.
-	  Choosing Y prevents the use of known-insecure encryption types
-	  but might result in compatibility problems.
+	  Choose Y to enable the use of Kerberos 5 encryption types
+	  that utilize Advanced Encryption Standard (AES) ciphers and
+	  SHA-1 digests. These include aes128-cts-hmac-sha1-96 and
+	  aes256-cts-hmac-sha1-96.
 
 config SUNRPC_DEBUG
 	bool "RPC: Enable dprintk debugging"
diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
index 2553d18fd288..9ddc6fc7077f 100644
--- a/net/sunrpc/auth_gss/gss_krb5_mech.c
+++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
@@ -29,12 +29,16 @@ 
 
 static struct gss_api_mech gss_kerberos_mech;
 
+#if defined(CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED)
 static int gss_krb5_import_ctx_des(struct krb5_ctx *ctx, gfp_t gfp_mask);
 static int gss_krb5_import_ctx_v1(struct krb5_ctx *ctx, gfp_t gfp_mask);
+#endif
+#if defined(CONFIG_RPCSEC_GSS_KRB5_CRYPTOSYSTEM)
 static int gss_krb5_import_ctx_v2(struct krb5_ctx *ctx, gfp_t gfp_mask);
+#endif
 
 static const struct gss_krb5_enctype supported_gss_krb5_enctypes[] = {
-#ifndef CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES
+#if defined(CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_DES)
 	/*
 	 * DES (All DES enctypes are mapped to the same gss functionality)
 	 */
@@ -59,7 +63,6 @@  static const struct gss_krb5_enctype supported_gss_krb5_enctypes[] = {
 	  .cksumlength = 8,
 	  .keyed_cksum = 0,
 	},
-#endif	/* CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES */
 	/*
 	 * 3DES
 	 */
@@ -84,8 +87,11 @@  static const struct gss_krb5_enctype supported_gss_krb5_enctypes[] = {
 	  .cksumlength = 20,
 	  .keyed_cksum = 1,
 	},
+#endif
+
+#if defined(CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1)
 	/*
-	 * AES128
+	 * AES-128 with SHA-1 (RFC 3962)
 	 */
 	{
 	  .etype = ENCTYPE_AES128_CTS_HMAC_SHA1_96,
@@ -114,7 +120,7 @@  static const struct gss_krb5_enctype supported_gss_krb5_enctypes[] = {
 	  .keyed_cksum = 1,
 	},
 	/*
-	 * AES256
+	 * AES-256 with SHA-1 (RFC 3962)
 	 */
 	{
 	  .etype = ENCTYPE_AES256_CTS_HMAC_SHA1_96,
@@ -142,6 +148,7 @@  static const struct gss_krb5_enctype supported_gss_krb5_enctypes[] = {
 	  .cksumlength = 12,
 	  .keyed_cksum = 1,
 	},
+#endif
 };
 
 /*
@@ -153,10 +160,12 @@  static char gss_krb5_enctype_priority_list[64];
 static void gss_krb5_prepare_enctype_priority_list(void)
 {
 	static const u32 gss_krb5_enctypes[] = {
+#if defined(CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA1)
 		ENCTYPE_AES256_CTS_HMAC_SHA1_96,
 		ENCTYPE_AES128_CTS_HMAC_SHA1_96,
+#endif
+#if defined(CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_DES)
 		ENCTYPE_DES3_CBC_SHA1,
-#ifndef CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES
 		ENCTYPE_DES_CBC_MD5,
 		ENCTYPE_DES_CBC_CRC,
 		ENCTYPE_DES_CBC_MD4,
@@ -337,7 +346,7 @@  gss_import_v1_context(const void *p, const void *end, struct krb5_ctx *ctx)
 	return PTR_ERR(p);
 }
 
-static struct crypto_sync_skcipher *
+static inline struct crypto_sync_skcipher *
 context_v2_alloc_cipher(struct krb5_ctx *ctx, const char *cname, u8 *key)
 {
 	struct crypto_sync_skcipher *cp;
@@ -367,6 +376,7 @@  set_cdata(u8 cdata[GSS_KRB5_K5CLENGTH], u32 usage, u8 seed)
 	cdata[4] = seed;
 }
 
+#if defined(CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED)
 static int
 gss_krb5_import_ctx_des(struct krb5_ctx *ctx, gfp_t gfp_mask)
 {
@@ -417,6 +427,9 @@  gss_krb5_import_ctx_v1(struct krb5_ctx *ctx, gfp_t gfp_mask)
 out_err:
 	return -EINVAL;
 }
+#endif
+
+#if defined(CONFIG_RPCSEC_GSS_KRB5_CRYPTOSYSTEM)
 
 static struct crypto_ahash *
 gss_krb5_alloc_hash_v2(struct krb5_ctx *kctx, const struct xdr_netobj *key)
@@ -551,6 +564,8 @@  gss_krb5_import_ctx_v2(struct krb5_ctx *ctx, gfp_t gfp_mask)
 	goto out;
 }
 
+#endif
+
 static int
 gss_import_v2_context(const void *p, const void *end, struct krb5_ctx *ctx,
 		gfp_t gfp_mask)
diff --git a/net/sunrpc/auth_gss/gss_krb5_seal.c b/net/sunrpc/auth_gss/gss_krb5_seal.c
index f74125407588..146aa755f07d 100644
--- a/net/sunrpc/auth_gss/gss_krb5_seal.c
+++ b/net/sunrpc/auth_gss/gss_krb5_seal.c
@@ -71,6 +71,8 @@ 
 # define RPCDBG_FACILITY        RPCDBG_AUTH
 #endif
 
+#if defined(CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED)
+
 static void *
 setup_token(struct krb5_ctx *ctx, struct xdr_netobj *token)
 {
@@ -97,34 +99,6 @@  setup_token(struct krb5_ctx *ctx, struct xdr_netobj *token)
 	return krb5_hdr;
 }
 
-static void *
-setup_token_v2(struct krb5_ctx *ctx, struct xdr_netobj *token)
-{
-	u16 *ptr;
-	void *krb5_hdr;
-	u8 *p, flags = 0x00;
-
-	if ((ctx->flags & KRB5_CTX_FLAG_INITIATOR) == 0)
-		flags |= 0x01;
-	if (ctx->flags & KRB5_CTX_FLAG_ACCEPTOR_SUBKEY)
-		flags |= 0x04;
-
-	/* Per rfc 4121, sec 4.2.6.1, there is no header,
-	 * just start the token */
-	krb5_hdr = ptr = (u16 *)token->data;
-
-	*ptr++ = KG2_TOK_MIC;
-	p = (u8 *)ptr;
-	*p++ = flags;
-	*p++ = 0xff;
-	ptr = (u16 *)p;
-	*ptr++ = 0xffff;
-	*ptr = 0xffff;
-
-	token->len = GSS_KRB5_TOK_HDR_LEN + ctx->gk5e->cksumlength;
-	return krb5_hdr;
-}
-
 u32
 gss_krb5_get_mic_v1(struct krb5_ctx *ctx, struct xdr_buf *text,
 		    struct xdr_netobj *token)
@@ -164,6 +138,38 @@  gss_krb5_get_mic_v1(struct krb5_ctx *ctx, struct xdr_buf *text,
 	return (ctx->endtime < now) ? GSS_S_CONTEXT_EXPIRED : GSS_S_COMPLETE;
 }
 
+#endif
+
+static void *
+setup_token_v2(struct krb5_ctx *ctx, struct xdr_netobj *token)
+{
+	u16 *ptr;
+	void *krb5_hdr;
+	u8 *p, flags = 0x00;
+
+	if ((ctx->flags & KRB5_CTX_FLAG_INITIATOR) == 0)
+		flags |= 0x01;
+	if (ctx->flags & KRB5_CTX_FLAG_ACCEPTOR_SUBKEY)
+		flags |= 0x04;
+
+	/* Per rfc 4121, sec 4.2.6.1, there is no header,
+	 * just start the token.
+	 */
+	krb5_hdr = (u16 *)token->data;
+	ptr = krb5_hdr;
+
+	*ptr++ = KG2_TOK_MIC;
+	p = (u8 *)ptr;
+	*p++ = flags;
+	*p++ = 0xff;
+	ptr = (u16 *)p;
+	*ptr++ = 0xffff;
+	*ptr = 0xffff;
+
+	token->len = GSS_KRB5_TOK_HDR_LEN + ctx->gk5e->cksumlength;
+	return krb5_hdr;
+}
+
 u32
 gss_krb5_get_mic_v2(struct krb5_ctx *ctx, struct xdr_buf *text,
 		    struct xdr_netobj *token)
diff --git a/net/sunrpc/auth_gss/gss_krb5_unseal.c b/net/sunrpc/auth_gss/gss_krb5_unseal.c
index 939d199eb7b7..7d6d4ae4a3c9 100644
--- a/net/sunrpc/auth_gss/gss_krb5_unseal.c
+++ b/net/sunrpc/auth_gss/gss_krb5_unseal.c
@@ -70,9 +70,9 @@ 
 #endif
 
 
+#if defined(CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED)
 /* read_token is a mic token, and message_buffer is the data that the mic was
  * supposedly taken over. */
-
 u32
 gss_krb5_verify_mic_v1(struct krb5_ctx *ctx, struct xdr_buf *message_buffer,
 		       struct xdr_netobj *read_token)
@@ -144,6 +144,7 @@  gss_krb5_verify_mic_v1(struct krb5_ctx *ctx, struct xdr_buf *message_buffer,
 
 	return GSS_S_COMPLETE;
 }
+#endif
 
 u32
 gss_krb5_verify_mic_v2(struct krb5_ctx *ctx, struct xdr_buf *message_buffer,
diff --git a/net/sunrpc/auth_gss/gss_krb5_wrap.c b/net/sunrpc/auth_gss/gss_krb5_wrap.c
index d983da6f9530..7dabf379406b 100644
--- a/net/sunrpc/auth_gss/gss_krb5_wrap.c
+++ b/net/sunrpc/auth_gss/gss_krb5_wrap.c
@@ -40,6 +40,8 @@ 
 # define RPCDBG_FACILITY	RPCDBG_AUTH
 #endif
 
+#if defined(CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED)
+
 static inline int
 gss_krb5_padding(int blocksize, int length)
 {
@@ -323,6 +325,8 @@  gss_krb5_unwrap_v1(struct krb5_ctx *kctx, int offset, int len,
 	return GSS_S_COMPLETE;
 }
 
+#endif
+
 /*
  * We can shift data by up to LOCAL_BUF_LEN bytes in a pass.  If we need
  * to do more than that, we shift repeatedly.  Kevin Coffman reports