[LU-3289] IU Shared Secret Key authentication and encryption

• Type: New Feature
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.9.0
• Labels: SSK gssapi patch
• Assignee: Jeremy Filizetti
• Reporter: Andreas Dilger

Description

Tracking bug for Indiana University's Shared Secret Key authentication and encryption security feature.

Issue Links

• is blocked by: LU-5951 sanity test_39k: mtime is lost on close
• is blocked by: LU-7508 LBUG sending reply to GSS enabled client
• is related to: LU-3290 disallow ptlrpc RPCs with old client XIDs
• is related to: LU-4625 errors seen during lustre rpm install
• is related to: LU-7661 MGS_SET_INFO handler is too permissive
• is related to: LU-7182 LBUG during key reestablishment with GSS clients
• is related to: LU-7184 (lod_dev.c:1493:lod_device_free()) ASSERTION( atomic_read(&lu->ld_ref) == 0 ) failed: lu is ffff88010cf8a000
• is related to: LU-7185 restore flags on ptlrpc_connect_import failure to prevent LBUG
• is related to: LU-7183 lctl set_param -P does not work for sptlrpc flavor
• is related to: LUDOC-197 Complete Lustre Manual updates for IU Shared Secret Key authentication and encryption
• is related to: LU-3778 GSS doesn't know about proxy subsystems
• is related to: LU-8229 SSK: allow multiple keys on a single nodemap
• is related to: LU-8602 Support GSS crypto code with linux 4.6 kernels
• is related to: LU-8590 Fix issues with SK privacy and integrity mode
• is related to: LU-6356 Kerberos revival
• is related to: LU-4371 Mechanism-agnostic GSSAPI testing
• is related to: LU-4764 Factor common code out of GSS-related test scripts
• is related to: LU-8275 ssk: add flag to test suite to enable ssk for tests

Comments

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/22626/
Subject: LU-3289 gss: Change the handling of keys for SK
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 7b596ad0b36ec5f0281be368b67b7e624457de18

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/22806/
Subject: LU-3289 gss: don't build SSK if libssl-1.0+ not available
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: bbee5d1ae941a208d7a07d0348e835ab58ca90ce

[Gerrit Updater]

Andreas Dilger ([e-mail]) uploaded a new patch: http://review.whamcloud.com/22806
Subject: LU-3289 gss: don't build SSK if libssl-1.0+ not available
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 3d750b41a6892e5b19f3bab4de75ca4dd0b6c033

[Gerrit Updater]

Jeremy Filizetti ([e-mail]) uploaded a new patch: http://review.whamcloud.com/22801
Subject: LU-3289 gss: Add autoconf check to prevent GSS with SLES11
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 2807d42f2dcead6092d4ffc58c1aaf9631e41253

[Gerrit Updater]

Jeremy Filizetti ([e-mail]) uploaded a new patch: http://review.whamcloud.com/22626
Subject: LU-3289 gss: Change the handling of keys for SK
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 8ae0caabad096181b21ba7d7013662f928327738

[James A Simmons]

I created ticket LU-8602 for the crypto API changes in 4.6+ kernels.

[Peter Jones]

It really sounds to me like sometihng to spin out into a separate ticket

[Andreas Dilger]

I just noticed that this ticket is closed, since the SSK code is landed for 2.9.0.

James, can you please file a separate ticket for the crypto API changes for 4.6 so that this can be tracked separately.

[Andreas Dilger]

Since this affects the network protocol compatibility, I don't think we should allow arbitrary crypto algorithms for SSK. I argued in the past that we shouldn't even allow old algorithms like 3DES for Kerberos, but this might be needed for backward compatibility. For SSK the current plan is to allow only AES with varying key sizes. We'll need more input from Jeremy before this moves forward.

[James A Simmons]

I can do the work The question is what approach should be done? Do I use the libcfs crypto API's or the kernel internal APIs. Their are pros and cons to both approaches. The main difference being that libcfs crypto is limited to the number of algo's it supports and the digest size. If I remembering right libcfs crypto API's limits the digest to 64 bytes whereas the kernel's api can support up to 2K if I remember right.

[Nathan Rutman]

The scope of Lustre 2.9 does not include support for such new kernels; we will defer any work for supporting 4.6 until Lustre 2.10.