Trait libgssapi::context::SecurityContext

source ·

pub trait SecurityContext {
Show 14 methods    // Required methods
    fn wrap(&mut self, encrypt: bool, msg: &[u8]) -> Result<Buf, Error>;
    fn wrap_iov(
        &mut self,
        encrypt: bool,
        msg: &mut [GssIov<'_>]
    ) -> Result<(), Error>;
    fn wrap_iov_length(
        &mut self,
        encrypt: bool,
        msg: &mut [GssIovFake]
    ) -> Result<(), Error>;
    fn unwrap(&mut self, msg: &[u8]) -> Result<Buf, Error>;
    fn unwrap_iov(&mut self, msg: &mut [GssIov<'_>]) -> Result<(), Error>;
    fn info(&mut self) -> Result<CtxInfo, Error>;
    fn source_name(&mut self) -> Result<Name, Error>;
    fn target_name(&mut self) -> Result<Name, Error>;
    fn lifetime(&mut self) -> Result<Duration, Error>;
    fn mechanism(&mut self) -> Result<&'static Oid, Error>;
    fn flags(&mut self) -> Result<CtxFlags, Error>;
    fn local(&mut self) -> Result<bool, Error>;
    fn open(&mut self) -> Result<bool, Error>;
    fn is_complete(&self) -> bool;
}

Required Methods§

source

fn wrap(&mut self, encrypt: bool, msg: &[u8]) -> Result<Buf, Error>

Wrap a message with optional encryption. If encrypt is true then only the other side of the context can read the message. In any case the other side can always verify message integrity.

source

fn wrap_iov( &mut self, encrypt: bool, msg: &mut [GssIov<'_>] ) -> Result<(), Error>

From the MIT kerberos documentation,

Sign and optionally encrypt a sequence of buffers. The buffers shall be ordered HEADER | DATA | PADDING | TRAILER. Suitable space for the header, padding and trailer should be provided by calling gss_wrap_iov_length(), or the ALLOCATE flag should be set on those buffers.

rust note: if you don’t want to use the ALLOCATE flag then call wrap_iov_length with a set of GssIovFake objects. These don’t contain any allocated memory, and can’t be dererenced or used, but the C library will set their length. You then need to use those lengths to allocate the correct amount of memory for the real wrap_iov call.

Encryption is in-place. SIGN_ONLY buffers are untouched. Only a single PADDING buffer should be provided. The order of the buffers in memory does not matter. Buffers in the IOV should be arranged in the order above, and in the case of multiple DATA buffers the sender and receiver should agree on the order.

With GSS_C_DCE_STYLE it is acceptable to not provide PADDING and TRAILER, but the caller must guarantee the plaintext data being encrypted is correctly padded, otherwise an error will be returned.

While applications that have knowledge of the underlying cryptosystem may request a specific configuration of data buffers, the only generally supported configurations are:

HEADER | DATA | PADDING | TRAILER

which will emit GSS_Wrap() compatible tokens, and:

HEADER | SIGN_ONLY | DATA | PADDING | TRAILER

for AEAD.

The typical (special cased) usage for DCE is as follows:

SIGN_ONLY_1 | DATA | SIGN_ONLY_2 | HEADER

source

fn wrap_iov_length( &mut self, encrypt: bool, msg: &mut [GssIovFake] ) -> Result<(), Error>

This will set the required length of all the buffers except the data buffer, which must be provided as it will be to wrap_iov. The value of the encrypt flag must match what you pass to wrap_iov.

source

fn unwrap(&mut self, msg: &[u8]) -> Result<Buf, Error>

Unwrap a wrapped message, checking it’s integrity and decrypting it if necessary.

source

fn unwrap_iov(&mut self, msg: &mut [GssIov<'_>]) -> Result<(), Error>

From the MIT Kerberos documentation,

gss_unwrap_iov may be called with an IOV list just like one which would be provided to gss_wrap_iov. DATA buffers will be decrypted in-place if they were encrypted, and SIGN_ONLY buffers will not be modified.

Alternatively, gss_unwrap_iov may be called with a single STREAM buffer, zero or more SIGN_ONLY buffers, and a single DATA buffer. The STREAM buffer is interpreted as a complete wrap token. The STREAM buffer will be modified in-place to decrypt its contents. The DATA buffer will be initialized to point to the decrypted data within the STREAM buffer, unless it has the GSS_C_BUFFER_FLAG_ALLOCATE flag set, in which case it will be initialized with a copy of the decrypted data.

source