summaryrefslogtreecommitdiffstats
path: root/include/linux/sunrpc/gss_krb5.h
Commit message (Collapse)AuthorAgeFilesLines
* SUNRPC: Move remaining internal definitions to gss_krb5_internal.hChuck Lever2023-02-201-117/+0
| | | | | | | | | | 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>
* SUNRPC: Support the Camellia enctypesChuck Lever2023-02-201-0/+4
| | | | | | | | | | | | | | | | RFC 6803 defines two encryption types that use Camellia ciphers (RFC 3713) and CMAC digests. Implement support for those in SunRPC's GSS Kerberos 5 mechanism. There has not been an explicit request to support these enctypes. However, this new set of enctypes provides a good alternative to the AES-SHA1 enctypes that are to be deprecated at some point. As this implementation is still a "beta", the default is to not build it automatically. Tested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Add gk5e definitions for RFC 8009 encryption typesChuck Lever2023-02-201-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | Fill in entries in the supported_gss_krb5_enctypes array for the encryption types defined in RFC 8009. These new enctypes use the SHA-256 and SHA-384 message digest algorithms (as defined in FIPS-180) instead of the deprecated SHA-1 algorithm, and are thus more secure. Note that NIST has scheduled SHA-1 for deprecation: https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm Thus these new encryption types are placed under a separate CONFIG option to enable distributors to separately introduce support for the AES-SHA2 enctypes and deprecate support for the current set of AES-SHA1 encryption types as their user space allows. As this implementation is still a "beta", the default is to not build it automatically. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Add new subkey length fieldsChuck Lever2023-02-201-2/+12
| | | | | | | | | | | | The aes256-cts-hmac-sha384-192 enctype specifies the length of its checksum and integrity subkeys as 192 bits, but the length of its encryption subkey (Ke) as 256 bits. Add new fields to struct gss_krb5_enctype that specify the key lengths individually, and where needed, use the correct new field instead of ->keylength. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Hoist KDF into struct gss_krb5_enctypeChuck Lever2023-02-201-20/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* SUNRPC: Rename .encrypt_v2 and .decrypt_v2 methodsChuck Lever2023-02-201-16/+4
| | | | | | | | | 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>
* SUNRPC: Remove ->encrypt and ->decrypt methods from struct gss_krb5_enctypeChuck Lever2023-02-201-14/+0
| | | | | | | | | | | 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>
* SUNRPC: Remove another switch on ctx->enctypeChuck Lever2023-02-201-0/+1
| | | | | | | | | Replace another switch on encryption type so that it does not 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>
* SUNRPC: Refactor the GSS-API Per Message calls in the Kerberos mechanismChuck Lever2023-02-201-14/+9
| | | | | | | | | 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>
* SUNRPC: Obscure Kerberos integrity keysChuck Lever2023-02-201-7/+2
| | | | | | | | | | | There's no need to keep the integrity keys around if we instead allocate and key a pair of ahashes and keep those. This not only enables the subkeys to be destroyed immediately after deriving them, but it makes the Kerberos integrity 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>
* SUNRPC: Obscure Kerberos signing keysChuck Lever2023-02-201-3/+2
| | | | | | | | | | | 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>
* SUNRPC: Obscure Kerberos encryption keysChuck Lever2023-02-201-2/+0
| | | | | | | | | | The encryption subkeys are not used after the cipher transforms have been allocated and keyed. There is no need to retain them in struct krb5_ctx. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Refactor set-up for aux_cipherChuck Lever2023-02-201-0/+1
| | | | | | | | | | Hoist the name of the aux_cipher into struct gss_krb5_enctype to prepare for obscuring the encryption keys just after they are derived. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Improve Kerberos confounder generationChuck Lever2023-02-201-3/+0
| | | | | | | | | | | | | | | | | | | | 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>
* SUNRPC: Remove .conflen field from struct gss_krb5_enctypeChuck Lever2023-02-201-3/+0
| | | | | | | | | | Now that arcfour-hmac is gone, the confounder length is again the same as the cipher blocksize for every implemented enctype. The gss_krb5_enctype::conflen field is no longer necessary. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Remove .blocksize field from struct gss_krb5_enctypeChuck Lever2023-02-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is not clear from documenting comments, specifications, or code usage what value the gss_krb5_enctype.blocksize field is supposed to store. The "encryption blocksize" depends only on the cipher being used, so that value can be derived where it's needed instead of stored as a constant. RFC 3961 Section 5.2 says: > cipher block size, c > This is the block size of the block cipher underlying the > encryption and decryption functions indicated above, used for key > derivation and for the size of the message confounder and initial > vector. (If a block cipher is not in use, some comparable > parameter should be determined.) It must be at least 5 octets. > > This is not actually an independent parameter; rather, it is a > property of the functions E and D. It is listed here to clarify > the distinction between it and the message block size, m. In the Linux kernel's implemenation of the SunRPC RPCSEC GSS Kerberos 5 mechanism, the cipher block size, which is dependent on the encryption and decryption transforms, is used only in krb5_derive_key(), so it is straightforward to replace it. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: Add header ifdefs to linux/sunrpc/gss_krb5.hChuck Lever2023-02-201-2/+5
| | | | | | | | | Standard convention: Ensure the contents of the header are included only once per source file. Tested-by: Scott Mayhew <smayhew@redhat.com> Reviewed-by: Simo Sorce <simo@redhat.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* SUNRPC: remove RC4-HMAC-MD5 support from KerberosVArd Biesheuvel2020-09-111-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which was specifically issued for interoperability with Windows 2000, but was never intended to receive the same level of support. The RFC says The IETF Kerberos community supports publishing this specification as an informational document in order to describe this widely implemented technology. However, while these encryption types provide the operations necessary to implement the base Kerberos specification [RFC4120], they do not provide all the required operations in the Kerberos cryptography framework [RFC3961]. As a result, it is not generally possible to implement potential extensions to Kerberos using these encryption types. The Kerberos encryption type negotiation mechanism [RFC4537] provides one approach for using such extensions even when a Kerberos infrastructure uses long-term RC4 keys. Because this specification does not implement operations required by RFC 3961 and because of security concerns with the use of RC4 and MD4 discussed in Section 8, this specification is not appropriate for publication on the standards track. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in 2018, stating that 'none of the encryption types it specifies should be used' Note that other outdated algorithms are left in place (some of which are guarded by CONFIG_SUNRPC_DISABLE_INSECURE_ENCTYPES), so this should only adversely affect interoperability with Windows NT/2000 systems that have not received any updates since 2008 (but are connected to a network nonetheless) [0] https://tools.ietf.org/html/rfc4757 [1] https://tools.ietf.org/html/rfc8429 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* SUNRPC: Add "@len" parameter to gss_unwrap()Chuck Lever2020-04-271-3/+3
| | | | | | | | | | | | | Refactor: This is a pre-requisite to fixing the client-side ralign computation in gss_unwrap_resp_priv(). The length value is passed in explicitly rather that as the value of buf->len. This will subsequently allow gss_unwrap_kerberos_v1() to compute a slack and align value, instead of computing it in gss_unwrap_resp_priv(). Fixes: 35e77d21baa0 ("SUNRPC: Add rpc_auth::au_ralign field") Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
* sunrpc: convert to time64_t for expiryArnd Bergmann2019-12-181-1/+1
| | | | | | | | | | | | | Using signed 32-bit types for UTC time leads to the y2038 overflow, which is what happens in the sunrpc code at the moment. This changes the sunrpc code over to use time64_t where possible. The one exception is the gss_import_v{1,2}_context() function for kerberos5, which uses 32-bit timestamps in the protocol. Here, we can at least treat the numbers as 'unsigned', which extends the range from 2038 to 2106. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* Merge tag 'nfs-for-4.20-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds2018-11-041-5/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull NFS client bugfixes from Trond Myklebust: "Highlights include: Bugfix: - Fix build issues on architectures that don't provide 64-bit cmpxchg Cleanups: - Fix a spelling mistake" * tag 'nfs-for-4.20-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFS: fix spelling mistake, EACCESS -> EACCES SUNRPC: Use atomic(64)_t for seq_send(64)
| * SUNRPC: Use atomic(64)_t for seq_send(64)Paul Burton2018-11-011-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The seq_send & seq_send64 fields in struct krb5_ctx are used as atomically incrementing counters. This is implemented using cmpxchg() & cmpxchg64() to implement what amount to custom versions of atomic_fetch_inc() & atomic64_fetch_inc(). Besides the duplication, using cmpxchg64() has another major drawback in that some 32 bit architectures don't provide it. As such commit 571ed1fd2390 ("SUNRPC: Replace krb5_seq_lock with a lockless scheme") resulted in build failures for some architectures. Change seq_send to be an atomic_t and seq_send64 to be an atomic64_t, then use atomic(64)_* functions to manipulate the values. The atomic64_t type & associated functions are provided even on architectures which lack real 64 bit atomic memory access via CONFIG_GENERIC_ATOMIC64 which uses spinlocks to serialize access. This fixes the build failures for architectures lacking cmpxchg64(). A potential alternative that was raised would be to provide cmpxchg64() on the 32 bit architectures that currently lack it, using spinlocks. However this would provide a version of cmpxchg64() with semantics a little different to the implementations on architectures with real 64 bit atomics - the spinlock-based implementation would only work if all access to the memory used with cmpxchg64() is *always* performed using cmpxchg64(). That is not currently a requirement for users of cmpxchg64(), and making it one seems questionable. As such avoiding cmpxchg64() outside of architecture-specific code seems best, particularly in cases where atomic64_t seems like a better fit anyway. The CONFIG_GENERIC_ATOMIC64 implementation of atomic64_* functions will use spinlocks & so faces the same issue, but with the key difference that the memory backing an atomic64_t ought to always be accessed via the atomic64_* functions anyway making the issue moot. Signed-off-by: Paul Burton <paul.burton@mips.com> Fixes: 571ed1fd2390 ("SUNRPC: Replace krb5_seq_lock with a lockless scheme") Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <anna.schumaker@netapp.com> Cc: J. Bruce Fields <bfields@fieldses.org> Cc: Jeff Layton <jlayton@kernel.org> Cc: David S. Miller <davem@davemloft.net> Cc: linux-nfs@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* | Merge tag 'nfs-for-4.20-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfsLinus Torvalds2018-10-261-1/+2
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull NFS client updates from Trond Myklebust: "Highlights include: Stable fixes: - Fix the NFSv4.1 r/wsize sanity checking - Reset the RPC/RDMA credit grant properly after a disconnect - Fix a missed page unlock after pg_doio() Features and optimisations: - Overhaul of the RPC client socket code to eliminate a locking bottleneck and reduce the latency when transmitting lots of requests in parallel. - Allow parallelisation of the RPCSEC_GSS encoding of an RPC request. - Convert the RPC client socket receive code to use iovec_iter() for improved efficiency. - Convert several NFS and RPC lookup operations to use RCU instead of taking global locks. - Avoid the need for BH-safe locks in the RPC/RDMA back channel. Bugfixes and cleanups: - Fix lock recovery during NFSv4 delegation recalls - Fix the NFSv4 + NFSv4.1 "lookup revalidate + open file" case. - Fixes for the RPC connection metrics - Various RPC client layer cleanups to consolidate stream based sockets - RPC/RDMA connection cleanups - Simplify the RPC/RDMA cleanup after memory operation failures - Clean ups for NFS v4.2 copy completion and NFSv4 open state reclaim" * tag 'nfs-for-4.20-1' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (97 commits) SUNRPC: Convert the auth cred cache to use refcount_t SUNRPC: Convert auth creds to use refcount_t SUNRPC: Simplify lookup code SUNRPC: Clean up the AUTH cache code NFS: change sign of nfs_fh length sunrpc: safely reallow resvport min/max inversion nfs: remove redundant call to nfs_context_set_write_error() nfs: Fix a missed page unlock after pg_doio() SUNRPC: Fix a compile warning for cmpxchg64() NFSv4.x: fix lock recovery during delegation recall SUNRPC: use cmpxchg64() in gss_seq_send64_fetch_and_inc() xprtrdma: Squelch a sparse warning xprtrdma: Clean up xprt_rdma_disconnect_inject xprtrdma: Add documenting comments xprtrdma: Report when there were zero posted Receives xprtrdma: Move rb_flags initialization xprtrdma: Don't disable BH's in backchannel server xprtrdma: Remove memory address of "ep" from an error message xprtrdma: Rename rpcrdma_qp_async_error_upcall xprtrdma: Simplify RPC wake-ups on connect ...
| * SUNRPC: Replace krb5_seq_lock with a lockless schemeTrond Myklebust2018-09-301-1/+2
| | | | | | | | Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
* | gss_krb5: Remove VLA usage of skcipherKees Cook2018-09-281-15/+15
|/ | | | | | | | | | | | | | | | | | In the quest to remove all stack VLA usage from the kernel[1], this replaces struct crypto_skcipher and SKCIPHER_REQUEST_ON_STACK() usage with struct crypto_sync_skcipher and SYNC_SKCIPHER_REQUEST_ON_STACK(), which uses a fixed stack size. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com Cc: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Anna Schumaker <anna.schumaker@netapp.com> Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Jeff Layton <jlayton@kernel.org> Cc: YueHaibing <yuehaibing@huawei.com> Cc: linux-nfs@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* sunrpc: Use skcipher and ahash/shashHerbert Xu2016-01-271-16/+16
| | | | | | | | This patch replaces uses of blkcipher with skcipher and the long obsolete hash interface with either shash (for non-SG users) and ahash. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* sunrpc: remove "ec" argument from encrypt_v2 operationJeff Layton2014-08-031-2/+2
| | | | | | | | It's always 0. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
* NFS: Don't use GFP_KERNEL in rpcsec_gss downcallsTrond Myklebust2010-05-141-1/+2
| | | | | | | Again, we can deadlock if the memory reclaim triggers a writeback that requires a rpcsec_gss credential lookup. Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: Add support for rc4-hmac encryptionKevin Coffman2010-05-141-0/+9
| | | | | | | | | Add necessary changes to add kernel support for the rc4-hmac Kerberos encryption type used by Microsoft and described in rfc4757. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: Use confounder length in wrap codeKevin Coffman2010-05-141-0/+3
| | | | | | | | | | | | | | | | All encryption types use a confounder at the beginning of the wrap token. In all encryption types except arcfour-hmac, the confounder is the same as the blocksize. arcfour-hmac has a blocksize of one, but uses an eight byte confounder. Add an entry to the crypto framework definitions for the confounder length and change the wrap/unwrap code to use the confounder length rather than assuming it is always the blocksize. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gssd_krb5: More arcfour-hmac supportKevin Coffman2010-05-141-2/+3
| | | | | | | | | | For the arcfour-hmac support, the make_seq_num and get_seq_num functions need access to the kerberos context structure. This will be used in a later patch. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: Save the raw session key in the contextKevin Coffman2010-05-141-0/+1
| | | | | | | | | This is needed for deriving arcfour-hmac keys "on the fly" using the sequence number or checksu Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gssd_krb5: arcfour-hmac supportKevin Coffman2010-05-141-2/+2
| | | | | | | | | | For arcfour-hmac support, the make_checksum function needs a usage field to correctly calculate the checksum differently for MIC and WRAP tokens. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: add remaining pieces to enable AES encryption supportKevin Coffman2010-05-141-0/+20
| | | | | | | | | Add the remaining pieces to enable support for Kerberos AES encryption types. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: add support for new token formats in rfc4121Kevin Coffman2010-05-141-0/+28
| | | | | | | | | | | This is a step toward support for AES encryption types which are required to use the new token formats defined in rfc4121. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> [SteveD: Fixed a typo in gss_verify_mic_v2()] Signed-off-by: Steve Dickson <steved@redhat.com> [Trond: Got rid of the TEST_ROTATE/TEST_EXTRA_COUNT crap] Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: add support for triple-des encryptionKevin Coffman2010-05-141-0/+5
| | | | | | | | Add the final pieces to support the triple-des encryption type. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: handle new context format from gssdKevin Coffman2010-05-141-2/+21
| | | | | | | | | | For encryption types other than DES, gssd sends down context information in a new format. This new format includes the information needed to support the new Kerberos GSS-API tokens defined in rfc4121. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: import functionality to derive keys into the kernelKevin Coffman2010-05-141-0/+31
| | | | | | | | | | Import the code to derive Kerberos keys from a base key into the kernel. This will allow us to change the format of the context information sent down from gssd to include only a single key. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: add ability to have a keyed checksum (hmac)Kevin Coffman2010-05-141-3/+8
| | | | | | | | | | | Encryption types besides DES may use a keyed checksum (hmac). Modify the make_checksum() function to allow for a key and take care of enctype-specific processing such as truncating the resulting hash. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: introduce encryption type frameworkKevin Coffman2010-05-141-1/+24
| | | | | | | | | Add enctype framework and change functions to use the generic values from it rather than the values hard-coded for des. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: split up functions in preparation of adding new enctypesKevin Coffman2010-05-141-0/+1
| | | | | | | | | Add encryption type to the krb5 context structure and use it to switch to the correct functions depending on the encryption type. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: Introduce encryption type frameworkKevin Coffman2010-05-141-0/+25
| | | | | | | | | | | | | | | | | Make the client and server code consistent regarding the extra buffer space made available for the auth code when wrapping data. Add some comments/documentation about the available buffer space in the xdr_buf head and tail when gss_wrap is called. Add a compile-time check to make sure we are not exceeding the available buffer space. Add a central function to shift head data. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: Steve Dickson <steved@redhat.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss_krb5: create a define for token header size and clean up ptr locationKevin Coffman2008-06-231-0/+3
| | | | | | | | | | | | | | | | | cleanup: Document token header size with a #define instead of open-coding it. Don't needlessly increment "ptr" past the beginning of the header which makes the values passed to functions more understandable and eliminates the need for extra "krb5_hdr" pointer. Clean up some intersecting white-space issues flagged by checkpatch.pl. This leaves the checksum length hard-coded at 8 for DES. A later patch cleans that up. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
* gss_krb5: consistently use unsigned for seqnumKevin Coffman2008-04-231-2/+2
| | | | | | | | | | Consistently use unsigned (u32 vs. s32) for seqnum. In get_mic function, send the local copy of seq_send, rather than the context version. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
* Remove define for KRB5_CKSUM_LENGTH, which will become enctype-dependentKevin Coffman2008-04-231-2/+0
| | | | | | | | | cleanup: When adding new encryption types, the checksum length can be different for each enctype. Face the fact that the current code only supports DES which has a checksum length of 8. Signed-off-by: Kevin Coffman <kwc@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
* rpcgss: krb5: ignore seedJ. Bruce Fields2006-12-061-2/+0
| | | | | | | We're currently not actually using seed or seed_init. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* rpcgss: krb5: sanity check sealalg value in the downcallJ. Bruce Fields2006-12-061-1/+0
| | | | | | | | | | | | | The sealalg is checked in several places, giving the impression it could be either SEAL_ALG_NONE or SEAL_ALG_DES. But in fact SEAL_ALG_NONE seems to be sufficient only for making mic's, and all the contexts we get must be capable of wrapping as well. So the sealalg must be SEAL_ALG_DES. As with signalg, just check for the right value on the downcall and ignore it otherwise. Similarly, tighten expectations for the sealalg on incoming tokens, in case we do support other values eventually. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* rpcgss: simplify make_checksumJ. Bruce Fields2006-12-061-1/+1
| | | | | | | | | | We're doing some pointless translation between krb5 constants and kernel crypto string names. Also clean up some related spkm3 code as necessary. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* gss: krb5: remove signalg and sealalgJ. Bruce Fields2006-12-061-1/+0
| | | | | | | | | | | | | We designed the krb5 context import without completely understanding the context. Now it's clear that there are a number of fields that we ignore, or that we depend on having one single value. In particular, we only support one value of signalg currently; so let's check the signalg field in the downcall (in case we decide there's something else we could support here eventually), but ignore it otherwise. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
* [SUNRPC] GSS: Use block ciphers where applicableHerbert Xu2006-09-211-9/+10
| | | | | | | This patch converts SUNRPC/GSS to use the new block cipher type where applicable. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-28 14:04:19 +0000