Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37 |
|
#
2a9893f7 |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove net/sunrpc/auth_gss/gss_krb5_seqnum.c
These functions are no longer used.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
#
cfb6b328 |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove the ->import_ctx method
All supported encryption types now use the same context import function.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever
SUNRPC: Remove the ->import_ctx method
All supported encryption types now use the same context import function.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
6964629f |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove krb5_derive_key_v1()
This function is no longer used.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
#
ec596aaf |
| 29-Jun-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove code behind CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED
None of this code can be enabled any more.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.
SUNRPC: Remove code behind CONFIG_RPCSEC_GSS_KRB5_SIMPLIFIED
None of this code can be enabled any more.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
Revision tags: v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7 |
|
#
c4a9f055 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add encryption self-tests
With the KUnit infrastructure recently added, we are free to define other unit tests particular to our implementation. As an example, I've added a self-test that en
SUNRPC: Add encryption self-tests
With the KUnit infrastructure recently added, we are free to define other unit tests particular to our implementation. As an example, I've added a self-test that encrypts then decrypts a string, and checks the result.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
4d2d15c0 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add RFC 8009 encryption KUnit tests
RFC 8009 provides sample encryption results. Add KUnit tests to ensure our implementation derives the expected results for the provided sample input.
I h
SUNRPC: Add RFC 8009 encryption KUnit tests
RFC 8009 provides sample encryption results. Add KUnit tests to ensure our implementation derives the expected results for the provided sample input.
I hate how large this test is, but using non-standard key usage values means rfc8009_encrypt_case() can't simply reuse ->import_ctx to allocate and key its ciphers; and the test provides its own confounders, which means krb5_etm_encrypt() can't be used directly.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
e1a9a384 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryption
Add Kunit tests for ENCTYPE_AES128_CTS_HMAC_SHA1_96. The test vectors come from RFC 3962 Appendix B.
Tested-by: Scott Mayhew <smay
SUNRPC: Add Kunit tests for RFC 3962-defined encryption/decryption
Add Kunit tests for ENCTYPE_AES128_CTS_HMAC_SHA1_96. The test vectors come from RFC 3962 Appendix B.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
ddd8c1f9 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Export get_gss_krb5_enctype()
I plan to add KUnit tests that will need enctype profile information. Export the enctype profile lookup function.
Tested-by: Scott Mayhew <smayhew@redhat.com>
SUNRPC: Export get_gss_krb5_enctype()
I plan to add KUnit tests that will need enctype profile information. Export the enctype profile lookup function.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
eebd8c2d |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add KUnit tests for rpcsec_krb5.ko
The Kerberos RFCs provide test vectors to verify the operation of an implementation. Introduce a KUnit test framework to exercise the Linux kernel's implem
SUNRPC: Add KUnit tests for rpcsec_krb5.ko
The Kerberos RFCs provide test vectors to verify the operation of an implementation. Introduce a KUnit test framework to exercise the Linux kernel's implementation of Kerberos.
Start with test cases for the RFC 3961-defined n-fold function. The sample vectors for that are found in RFC 3961 Section 10.
Run the GSS Kerberos 5 mechanism's unit tests with this command:
$ ./tools/testing/kunit/kunit.py run \ --kunitconfig ./net/sunrpc/.kunitconfig
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
6e460c23 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Move remaining internal definitions to gss_krb5_internal.h
The goal is to leave only protocol-defined items in gss_krb5.h so that it can be easily replaced by a generic header. Implementatio
SUNRPC: Move remaining internal definitions to gss_krb5_internal.h
The goal is to leave only protocol-defined items in gss_krb5.h so that it can be easily replaced by a generic header. Implementation specific items are moved to the new internal header.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
45b4ef46 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add KDF_FEEDBACK_CMAC
The Camellia enctypes use the KDF_FEEDBACK_CMAC Key Derivation Function defined in RFC 6803 Section 3.
Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuc
SUNRPC: Add KDF_FEEDBACK_CMAC
The Camellia enctypes use the KDF_FEEDBACK_CMAC Key Derivation Function defined in RFC 6803 Section 3.
Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
0d5b5a0f |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add RFC 8009 encryption and decryption functions
RFC 8009 enctypes use different crypt formulae than previous Kerberos 5 encryption types. Section 1 of RFC 8009 explains the reason for this
SUNRPC: Add RFC 8009 encryption and decryption functions
RFC 8009 enctypes use different crypt formulae than previous Kerberos 5 encryption types. Section 1 of RFC 8009 explains the reason for this change:
> The new types conform to the framework specified in [RFC3961], > but do not use the simplified profile, as the simplified profile > is not compliant with modern cryptographic best practices such as > calculating Message Authentication Codes (MACs) over ciphertext > rather than plaintext.
Add new .encrypt and .decrypt functions to handle this variation.
The new approach described above is referred to as Encrypt-then-MAC (or EtM). Hence the names of the new functions added here are prefixed with "krb5_etm_".
A critical second difference with previous crypt formulae is that the cipher state is included in the computed HMAC. Note however that for RPCSEC, the initial cipher state is easy to compute on both initiator and acceptor because it is always all zeroes.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
ae2e4d2b |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Add KDF-HMAC-SHA2
The RFC 8009 encryption types use a different key derivation function than the RFC 3962 encryption types. The new key derivation function is defined in Section 3 of RFC 800
SUNRPC: Add KDF-HMAC-SHA2
The RFC 8009 encryption types use a different key derivation function than the RFC 3962 encryption types. The new key derivation function is defined in Section 3 of RFC 8009.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
2691a27d |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Hoist KDF into struct gss_krb5_enctype
Each Kerberos enctype can have a different KDF. Refactor the key derivation path to support different KDFs for the enctypes introduced in subsequent pa
SUNRPC: Hoist KDF into struct gss_krb5_enctype
Each Kerberos enctype can have a different KDF. Refactor the key derivation path to support different KDFs for the enctypes introduced in subsequent patches.
In particular, expose the key derivation function in struct gss_krb5_enctype instead of the enctype's preferred random-to-key function. The latter is usually the identity function and is only ever called during key derivation, so have each KDF call it directly.
A couple of extra clean-ups: - Deduplicate the set_cdata() helper - Have ->derive_key return negative errnos, in accordance with usual kernel coding conventions
This patch is a little bigger than I'd like, but these are all mechanical changes and they are all to the same areas of code. No behavior change is intended.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
ae6ad5d0 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
Clean up: there is now only one encrypt and only one decrypt method, thus there is no longer a need for the v2-suffixed method names.
Tested-by: S
SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methods
Clean up: there is now only one encrypt and only one decrypt method, thus there is no longer a need for the v2-suffixed method names.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
d50b8152 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
Clean up: ->encrypt is set to only one value. Replace the two remaining call sites with direct calls to krb5_encrypt().
T
SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctype
Clean up: ->encrypt is set to only one value. Replace the two remaining call sites with direct calls to krb5_encrypt().
There have never been any call sites for the ->decrypt() method.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
e01b2c79 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
Replace a number of switches on encryption type so that all of them don't have to be modified when adding or removing support
SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanism
Replace a number of switches on encryption type so that all of them don't have to be modified when adding or removing support for an enctype.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
2dbe0cac |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Obscure Kerberos signing keys
There's no need to keep the signing keys around if we instead allocate and key an ahash and keep that. This not only enables the subkeys to be destroyed immedia
SUNRPC: Obscure Kerberos signing keys
There's no need to keep the signing keys around if we instead allocate and key an ahash and keep that. This not only enables the subkeys to be destroyed immediately after deriving them, but it makes the Kerberos signing code path more efficient.
Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|
#
7f675ca7 |
| 15-Jan-2023 |
Chuck Lever <chuck.lever@oracle.com> |
SUNRPC: Improve Kerberos confounder generation
Other common Kerberos implementations use a fully random confounder for encryption. The reason for this is explained in the new comment added by this p
SUNRPC: Improve Kerberos confounder generation
Other common Kerberos implementations use a fully random confounder for encryption. The reason for this is explained in the new comment added by this patch. The current get_random_bytes() implementation does not exhaust system entropy.
Since confounder generation is part of Kerberos itself rather than the GSS-API Kerberos mechanism, the function is renamed and moved.
Note that light top-down analysis shows that the SHA-1 transform is by far the most CPU-intensive part of encryption. Thus we do not expect this change to result in a significant performance impact. However, eventually it might be necessary to generate an independent stream of confounders for each Kerberos context to help improve I/O parallelism.
Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
show more ...
|