krb5: Import MIT 1.21.3 - src - FreeBSD source tree

diff options


context:
space:
mode:

author	Cy Schubert <cy@FreeBSD.org>	2025-03-19 22:12:25 +0000
committer	Cy Schubert <cy@FreeBSD.org>	2025-03-19 22:12:25 +0000
commit	8f7d3ef26dec89a92ec0665de84a5936310a5574 (patch)
tree	9a465418bd4056bf0d369751320a414eaed29fa4 /doc/html/appdev/gssapi.html
parent	1a79b20663ca26acc2998b90ea2ff2aefd8af5b1 (diff)

Diffstat (limited to 'doc/html/appdev/gssapi.html')

-rw-r--r--

doc/html/appdev/gssapi.html

242

1 files changed, 118 insertions, 124 deletions

diff --git a/doc/html/appdev/gssapi.html b/doc/html/appdev/gssapi.html
index 80f34ade3c46..c51274a4b2ce 100644
--- a/doc/html/appdev/gssapi.html
+++ b/doc/html/appdev/gssapi.html

@@ -1,35 +1,26 @@

-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

+<!DOCTYPE html>

-<html xmlns="http://www.w3.org/1999/xhtml">

+<html>

<head>

- <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

+ <meta charset="utf-8" />

+ <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />

<title>Developing with GSSAPI — MIT Kerberos Documentation</title>

- <link rel="stylesheet" href="../_static/agogo.css" type="text/css" />

- <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />

- <link rel="stylesheet" href="../_static/kerb.css" type="text/css" />

- <script type="text/javascript">

- var DOCUMENTATION_OPTIONS = {

- URL_ROOT: '../',

- VERSION: '1.21.2',

- COLLAPSE_INDEX: false,

- FILE_SUFFIX: '.html',

- HAS_SOURCE: true,

- SOURCELINK_SUFFIX: '.txt'

- };

- </script>

- <script type="text/javascript" src="../_static/jquery.js"></script>

- <script type="text/javascript" src="../_static/underscore.js"></script>

- <script type="text/javascript" src="../_static/doctools.js"></script>

+ <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />

+ <link rel="stylesheet" type="text/css" href="../_static/agogo.css" />

+ <link rel="stylesheet" type="text/css" href="../_static/kerb.css" />

+ <script data-url_root="../" id="documentation_options" src="../_static/documentation_options.js"></script>

+ <script src="../_static/jquery.js"></script>

+ <script src="../_static/underscore.js"></script>

+ <script src="../_static/doctools.js"></script>

- </head>

- <body>

+ </head><body>

@@ -61,7 +52,7 @@

- <div class="section" id="developing-with-gssapi">

+ <section id="developing-with-gssapi">

<h1>Developing with GSSAPI<a class="headerlink" href="#developing-with-gssapi" title="Permalink to this headline">¶</a></h1>

The GSSAPI (Generic Security Services API) allows applications to

communicate securely using Kerberos 5 or other security mechanisms.

@@ -74,50 +65,50 @@ server program.

This documentation will describe how various ways of using the

GSSAPI will behave with the krb5 mechanism as implemented in MIT krb5,

as well as krb5-specific extensions to the GSSAPI.

-<div class="section" id="name-types">

+<section id="name-types">

<h2>Name types<a class="headerlink" href="#name-types" title="Permalink to this headline">¶</a></h2>

A GSSAPI application can name a local or remote entity by calling

<a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.16">gss_import_name</a>, specifying a name type and a value. The following

name types are supported by the krb5 mechanism:

-<li>GSS_C_NT_HOSTBASED_SERVICE: The value should be a string of the

-form <code class="docutils literal">service</code> or <code class="docutils literal">service@hostname</code>. This is the most common

+<li>GSS_C_NT_HOSTBASED_SERVICE: The value should be a string of the

+form <code class="docutils literal notranslate">service</code> or <code class="docutils literal notranslate">service@hostname</code>. This is the most common

way to name target services when initiating a security context, and

-is the most likely name type to work across multiple mechanisms.</li>

-<li>GSS_KRB5_NT_PRINCIPAL_NAME: The value should be a principal name

+is the most likely name type to work across multiple mechanisms.</li>

+<li>GSS_KRB5_NT_PRINCIPAL_NAME: The value should be a principal name

string. This name type only works with the krb5 mechanism, and is

-defined in the <code class="docutils literal"><gssapi/gssapi_krb5.h></code> header.</li>

-<li>GSS_C_NT_USER_NAME or GSS_C_NULL_OID: The value is treated

+defined in the <code class="docutils literal notranslate"><gssapi/gssapi_krb5.h></code> header.</li>

+<li>GSS_C_NT_USER_NAME or GSS_C_NULL_OID: The value is treated

as an unparsed principal name string, as above. These name types

may work with mechanisms other than krb5, but will have different

interpretations in those mechanisms. GSS_C_NT_USER_NAME is

intended to be used with a local username, which will parse into a

-single-component principal in the default realm.</li>

-<li>GSS_C_NT_ANONYMOUS: The value is ignored. The anonymous

+single-component principal in the default realm.</li>

+<li>GSS_C_NT_ANONYMOUS: The value is ignored. The anonymous

principal is used, allowing a client to authenticate to a server

without asserting a particular identity (which may or may not be

-allowed by a particular server or Kerberos realm).</li>

-<li>GSS_C_NT_MACHINE_UID_NAME: The value is uid_t object. On

+allowed by a particular server or Kerberos realm).</li>

+<li>GSS_C_NT_MACHINE_UID_NAME: The value is uid_t object. On

Unix-like systems, the username of the uid is looked up in the

system user database and the resulting username is parsed as a

-principal name.</li>

-<li>GSS_C_NT_STRING_UID_NAME: As above, but the value is a decimal

-string representation of the uid.</li>

-<li>GSS_C_NT_EXPORT_NAME: The value must be the result of a

-<a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.13">gss_export_name</a> call.</li>

-<li>GSS_KRB5_NT_ENTERPRISE_NAME: The value should be a krb5

+principal name.</li>

+<li>GSS_C_NT_STRING_UID_NAME: As above, but the value is a decimal

+string representation of the uid.</li>

+<li>GSS_C_NT_EXPORT_NAME: The value must be the result of a

+<a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.13">gss_export_name</a> call.</li>

+<li>GSS_KRB5_NT_ENTERPRISE_NAME: The value should be a krb5

enterprise name string (see <a class="rfc reference external" href="https://tools.ietf.org/html/rfc6806.html">RFC 6806</a> section 5), in the form

-<code class="docutils literal">user@suffix</code>. This name type is used to convey alias names, and

-is defined in the <code class="docutils literal"><gssapi/gssapi_krb5.h></code> header. (New in

-release 1.17.)</li>

-<li>GSS_KRB5_NT_X509_CERT: The value should be an X.509 certificate

+<code class="docutils literal notranslate">user@suffix</code>. This name type is used to convey alias names, and

+is defined in the <code class="docutils literal notranslate"><gssapi/gssapi_krb5.h></code> header. (New in

+release 1.17.)</li>

+<li>GSS_KRB5_NT_X509_CERT: The value should be an X.509 certificate

encoded according to <a class="rfc reference external" href="https://tools.ietf.org/html/rfc5280.html">RFC 5280</a>. This name form can be used for

the desired_name parameter of gss_acquire_cred_impersonate_name(),

to identify the S4U2Self user by certificate. (New in release

-1.19.)</li>

+1.19.)</li>

</ul>

-</div>

-<div class="section" id="initiator-credentials">

+</section>

+<section id="initiator-credentials">

<h2>Initiator credentials<a class="headerlink" href="#initiator-credentials" title="Permalink to this headline">¶</a></h2>

A GSSAPI client application uses <a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.19">gss_init_sec_context</a> to establish a

security context. The initiator_cred_handle parameter determines

@@ -129,7 +120,7 @@ initiator credential. The call to <a class="reference external" href="https://t

not have a specific name preference.

If the desired name for a krb5 initiator credential is a host-based

name, it is converted to a principal name of the form

-<code class="docutils literal">service/hostname</code> in the local realm, where hostname is the local

+<code class="docutils literal notranslate">service/hostname</code> in the local realm, where hostname is the local

hostname if not specified. The hostname will be canonicalized using

forward name resolution, and possibly also using reverse name

resolution depending on the value of the rdns variable in

@@ -167,8 +158,8 @@ for the first principal in the default client keytab.

client keytab, the resulting tickets will be stored in the default

cache or collection, and will be refreshed by future calls to

<a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.2">gss_acquire_cred</a> as they approach their expire time.

-</div>

-<div class="section" id="acceptor-names">

+</section>

+<section id="acceptor-names">

<h2>Acceptor names<a class="headerlink" href="#acceptor-names" title="Permalink to this headline">¶</a></h2>

A GSSAPI server application uses <a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.1">gss_accept_sec_context</a> to establish

a security context based on tokens provided by the client. The

@@ -190,37 +181,37 @@ keytab, just as if no acceptor credential was supplied.

the most common choice is a host-based name. If the host-based

desired_name contains just a service, then clients will be allowed

to authenticate to any host-based service principal (that is, a

-principal of the form <code class="docutils literal">service/hostname@REALM</code>) for the named

+principal of the form <code class="docutils literal notranslate">service/hostname@REALM</code>) for the named

service, regardless of hostname or realm, as long as it is present in

the default keytab. If the input name contains both a service and a

hostname, clients will be allowed to authenticate to any host-based

principal for the named service and hostname, regardless of realm.

-Note

-If a hostname is specified, it will be canonicalized

+Note

+If a hostname is specified, it will be canonicalized

using forward name resolution, and possibly also using

reverse name resolution depending on the value of the

rdns variable in <a class="reference internal" href="../admin/conf_files/krb5_conf.html#libdefaults">[libdefaults]</a>.

</div>

-Note

-If the ignore_acceptor_hostname variable in

+Note

+If the ignore_acceptor_hostname variable in

<a class="reference internal" href="../admin/conf_files/krb5_conf.html#libdefaults">[libdefaults]</a> is enabled, then hostname will be

ignored even if one is specified in the input name.

</div>

-Note

-In MIT krb5 versions prior to 1.10, and in Heimdal’s

+Note

+In MIT krb5 versions prior to 1.10, and in Heimdal’s

implementation of the krb5 mechanism, an input name with

just a service is treated like an input name of

-<code class="docutils literal">service@localhostname</code>, where localhostname is the

+<code class="docutils literal notranslate">service@localhostname</code>, where localhostname is the

string returned by gethostname().

</div>

If the desired_name is a krb5 principal name or a local system name

type which is mapped to a krb5 principal name, clients will only be

allowed to authenticate to that principal in the default keytab.

-</div>

-<div class="section" id="name-attributes">

+</section>

+<section id="name-attributes">

<h2>Name Attributes<a class="headerlink" href="#name-attributes" title="Permalink to this headline">¶</a></h2>

In release 1.8 or later, the <a class="reference external" href="https://tools.ietf.org/html/rfc6680.txt#section-7.4">gss_inquire_name</a> and

<a class="reference external" href="https://tools.ietf.org/html/6680.html#section-7.5">gss_get_name_attribute</a> functions, specified in <a class="rfc reference external" href="https://tools.ietf.org/html/rfc6680.html">RFC 6680</a>, can be

@@ -228,20 +219,20 @@ used to retrieve name attributes from the src_name returned by

<a class="reference external" href="https://tools.ietf.org/html/rfc2744.html#section-5.1">gss_accept_sec_context</a>. The following attributes are defined when

the krb5 mechanism is used:

-<li>“auth-indicators” attribute:</li>

+<li>“auth-indicators” attribute:</li>

</ul>

This attribute will be included in the <a class="reference external" href="https://tools.ietf.org/html/rfc6680.txt#section-7.4">gss_inquire_name</a> output if the

ticket contains <a class="reference internal" href="../admin/auth_indicator.html#auth-indicator">authentication indicators</a>.

One indicator is returned per invocation of <a class="reference external" href="https://tools.ietf.org/html/6680.html#section-7.5">gss_get_name_attribute</a>,

so multiple invocations may be necessary to retrieve all of the

indicators from the ticket. (New in release 1.15.)

-</div>

-<div class="section" id="credential-store-extensions">

+</section>

+<section id="credential-store-extensions">

<h2>Credential store extensions<a class="headerlink" href="#credential-store-extensions" title="Permalink to this headline">¶</a></h2>

Beginning with release 1.11, the following GSSAPI extensions declared

-in <code class="docutils literal"><gssapi/gssapi_ext.h></code> can be used to specify how credentials

+in <code class="docutils literal notranslate"><gssapi/gssapi_ext.h></code> can be used to specify how credentials

are acquired or stored:

-<div class="highlight-default"><div class="highlight"><pre>struct gss_key_value_element_struct {

+<div class="highlight-default notranslate"><div class="highlight"><pre>struct gss_key_value_element_struct {

const char *key;

const char *value;

};

@@ -279,33 +270,33 @@ are acquired or stored:

information about how the credentials should be obtained and stored.

The following options are supported by the krb5 mechanism:

-<li>ccache: For acquiring initiator credentials, the name of the

+<li>ccache: For acquiring initiator credentials, the name of the

<a class="reference internal" href="../basic/ccache_def.html#ccache-definition">credential cache</a> to which the handle will

refer. For storing credentials, the name of the cache or collection

-where the credentials will be stored (see below).</li>

-<li>client_keytab: For acquiring initiator credentials, the name of

+where the credentials will be stored (see below).</li>

+<li>client_keytab: For acquiring initiator credentials, the name of

the <a class="reference internal" href="../basic/keytab_def.html#keytab-definition">keytab</a> which will be used, if

-necessary, to refresh the credentials in the cache.</li>

-<li>keytab: For acquiring acceptor credentials, the name of the

+necessary, to refresh the credentials in the cache.</li>

+<li>keytab: For acquiring acceptor credentials, the name of the

<a class="reference internal" href="../basic/keytab_def.html#keytab-definition">keytab</a> to which the handle will refer.

In release 1.19 and later, this option also determines the keytab to

be used for verification when initiator credentials are acquired

-using a password and verified.</li>

-<li>password: For acquiring initiator credentials, this option

+using a password and verified.</li>

+<li>password: For acquiring initiator credentials, this option

instructs the mechanism to acquire fresh credentials into a unique

memory credential cache. This option may not be used with the

ccache or client_keytab options, and a desired_name must

-be specified. (New in release 1.19.)</li>

-<li>rcache: For acquiring acceptor credentials, the name of the

+be specified. (New in release 1.19.)</li>

+<li>rcache: For acquiring acceptor credentials, the name of the

<a class="reference internal" href="../basic/rcache_def.html#rcache-definition">replay cache</a> to be used when processing

-the initiator tokens. (New in release 1.13.)</li>

-<li>verify: For acquiring initiator credentials, this option

+the initiator tokens. (New in release 1.13.)</li>

+<li>verify: For acquiring initiator credentials, this option

instructs the mechanism to verify the credentials by obtaining a

ticket to a service with a known key. The service key is obtained

from the keytab specified with the keytab option or the default

keytab. The value may be the name of a principal in the keytab, or

-the empty string. If the empty string is given, any <code class="docutils literal">host</code>

-service principal in the keytab may be used. (New in release 1.19.)</li>

+the empty string. If the empty string is given, any <code class="docutils literal notranslate">host</code>

+service principal in the keytab may be used. (New in release 1.19.)</li>

</ul>

In release 1.20 or later, if a collection name is specified for

cache in a call to gss_store_cred_into(), an existing cache for

@@ -315,12 +306,12 @@ false and the selected credential cache already exists, a

GSS_S_DUPLICATE_ELEMENT error will be returned. If default_cred

is true, the primary cache of the collection will be switched to the

selected cache.

-</div>

-<div class="section" id="importing-and-exporting-credentials">

+</section>

+<section id="importing-and-exporting-credentials">

<h2>Importing and exporting credentials<a class="headerlink" href="#importing-and-exporting-credentials" title="Permalink to this headline">¶</a></h2>

The following GSSAPI extensions can be used to import and export

-credentials (declared in <code class="docutils literal"><gssapi/gssapi_ext.h></code>):

-<div class="highlight-default"><div class="highlight"><pre>OM_uint32 gss_export_cred(OM_uint32 *minor_status,

+credentials (declared in <code class="docutils literal notranslate"><gssapi/gssapi_ext.h></code>):

+<div class="highlight-default notranslate"><div class="highlight"><pre>OM_uint32 gss_export_cred(OM_uint32 *minor_status,

gss_cred_id_t cred_handle,

gss_buffer_t token);

@@ -358,8 +349,8 @@ delegated credentials received by <a class="reference external" href="https://to

case, the contents of the credential cache are serialized, so that the

resulting token may be imported even if the original memory credential

cache no longer exists.

-</div>

-<div class="section" id="constrained-delegation-s4u">

+</section>

+<section id="constrained-delegation-s4u">

<h2>Constrained delegation (S4U)<a class="headerlink" href="#constrained-delegation-s4u" title="Permalink to this headline">¶</a></h2>

The Microsoft S4U2Self and S4U2Proxy Kerberos protocol extensions

allow an intermediate service to acquire credentials from a client to

@@ -386,7 +377,7 @@ determine that the client’s ticket is not a valid evidence ticket, it

will place GSS_C_NO_CREDENTIAL in delegated_cred_handle.

To acquire a proxy credential using an S4U2Self request, the service

can use the following GSSAPI extension:

-<div class="highlight-default"><div class="highlight"><pre>OM_uint32 gss_acquire_cred_impersonate_name(OM_uint32 *minor_status,

+<div class="highlight-default notranslate"><div class="highlight"><pre>OM_uint32 gss_acquire_cred_impersonate_name(OM_uint32 *minor_status,

gss_cred_id_t icred,

gss_name_t desired_name,

OM_uint32 time_req,

@@ -419,10 +410,10 @@ service.

If an application needs to find out whether a credential it holds is a

proxy credential and the name of the intermediate service, it can

query the credential with the GSS_KRB5_GET_CRED_IMPERSONATOR OID

-(new in release 1.16, declared in <code class="docutils literal"><gssapi/gssapi_krb5.h></code>) using

+(new in release 1.16, declared in <code class="docutils literal notranslate"><gssapi/gssapi_krb5.h></code>) using

the gss_inquire_cred_by_oid extension (declared in

-<code class="docutils literal"><gssapi/gssapi_ext.h></code>):

-<div class="highlight-default"><div class="highlight"><pre>OM_uint32 gss_inquire_cred_by_oid(OM_uint32 *minor_status,

+<code class="docutils literal notranslate"><gssapi/gssapi_ext.h></code>):

+<div class="highlight-default notranslate"><div class="highlight"><pre>OM_uint32 gss_inquire_cred_by_oid(OM_uint32 *minor_status,

const gss_cred_id_t cred_handle,

gss_OID desired_object,

gss_buffer_set_t *data_set);

@@ -434,14 +425,14 @@ unparsed principal name of the intermediate service. If cred_handle

is not a proxy credential, data_set will be set to an empty buffer

set. If the library does not support the query,

gss_inquire_cred_by_oid will return GSS_S_UNAVAILABLE.

-</div>

-<div class="section" id="aead-message-wrapping">

+</section>

+<section id="aead-message-wrapping">

<h2>AEAD message wrapping<a class="headerlink" href="#aead-message-wrapping" title="Permalink to this headline">¶</a></h2>

The following GSSAPI extensions (declared in

-<code class="docutils literal"><gssapi/gssapi_ext.h></code>) can be used to wrap and unwrap messages

+<code class="docutils literal notranslate"><gssapi/gssapi_ext.h></code>) can be used to wrap and unwrap messages

with additional “associated data” which is integrity-checked but is

not included in the output buffer:

-<div class="highlight-default"><div class="highlight"><pre>OM_uint32 gss_wrap_aead(OM_uint32 *minor_status,

+<div class="highlight-default notranslate"><div class="highlight"><pre>OM_uint32 gss_wrap_aead(OM_uint32 *minor_status,

gss_ctx_id_t context_handle,

int conf_req_flag, gss_qop_t qop_req,

gss_buffer_t input_assoc_buffer,

@@ -461,14 +452,14 @@ not included in the output buffer:

Wrap tokens created with gss_wrap_aead will successfully unwrap only

if the same input_assoc_buffer contents are presented to

gss_unwrap_aead.

-</div>

-<div class="section" id="iov-message-wrapping">

+</section>

+<section id="iov-message-wrapping">

<h2>IOV message wrapping<a class="headerlink" href="#iov-message-wrapping" title="Permalink to this headline">¶</a></h2>

-The following extensions (declared in <code class="docutils literal"><gssapi/gssapi_ext.h></code>) can

+The following extensions (declared in <code class="docutils literal notranslate"><gssapi/gssapi_ext.h></code>) can

be used for in-place encryption, fine-grained control over wrap token

layout, and for constructing wrap tokens compatible with Microsoft DCE

RPC:

-<div class="highlight-default"><div class="highlight"><pre>typedef struct gss_iov_buffer_desc_struct {

+<div class="highlight-default notranslate"><div class="highlight"><pre>typedef struct gss_iov_buffer_desc_struct {

OM_uint32 type;

gss_buffer_desc buffer;

} gss_iov_buffer_desc, *gss_iov_buffer_t;

@@ -500,22 +491,22 @@ RPC:

structures, each containing a type and a gss_buffer_desc structure.

Valid types include:

-<li>GSS_C_BUFFER_TYPE_DATA: A data buffer to be included in the

+<li>GSS_C_BUFFER_TYPE_DATA: A data buffer to be included in the

token, and to be encrypted or decrypted in-place if the token is

-confidentiality-protected.</li>

-<li>GSS_C_BUFFER_TYPE_HEADER: The GSSAPI wrap token header and

-underlying cryptographic header.</li>

-<li>GSS_C_BUFFER_TYPE_TRAILER: The cryptographic trailer, if one is

-required.</li>

-<li>GSS_C_BUFFER_TYPE_PADDING: Padding to be combined with the data

+confidentiality-protected.</li>

+<li>GSS_C_BUFFER_TYPE_HEADER: The GSSAPI wrap token header and

+underlying cryptographic header.</li>

+<li>GSS_C_BUFFER_TYPE_TRAILER: The cryptographic trailer, if one is

+required.</li>

+<li>GSS_C_BUFFER_TYPE_PADDING: Padding to be combined with the data

during encryption and decryption. (The implementation may choose to

place padding in the trailer buffer, in which case it will set the

-padding buffer length to 0.)</li>

-<li>GSS_C_BUFFER_TYPE_STREAM: For unwrapping only, a buffer

-containing a complete wrap token in standard format to be unwrapped.</li>

-<li>GSS_C_BUFFER_TYPE_SIGN_ONLY: A buffer to be included in the

+padding buffer length to 0.)</li>

+<li>GSS_C_BUFFER_TYPE_STREAM: For unwrapping only, a buffer

+containing a complete wrap token in standard format to be unwrapped.</li>

+<li>GSS_C_BUFFER_TYPE_SIGN_ONLY: A buffer to be included in the

token’s integrity protection checksum, but not to be encrypted or

-included in the token itself.</li>

+included in the token itself.</li>

</ul>

For gss_wrap_iov, the IOV list should contain one HEADER buffer,

followed by zero or more SIGN_ONLY buffers, followed by one or more

@@ -531,7 +522,7 @@ gss_release_iov_buffer can be used to release all allocated buffers

within an iov list and unset their allocated flags. Here is an

example of how gss_wrap_iov can be used with allocation requested

(ctx is assumed to be a previously established gss_ctx_id_t):

-<div class="highlight-default"><div class="highlight"><pre>OM_uint32 major, minor;

+<div class="highlight-default notranslate"><div class="highlight"><pre>OM_uint32 major, minor;

gss_iov_buffer_desc iov[4];

char str[] = "message";

@@ -558,7 +549,7 @@ lengths of the HEADER, PADDING, and TRAILER buffers. DATA buffers

must be provided in the iov list so that padding length can be

computed correctly, but the output buffers need not be initialized.

Here is an example of using gss_wrap_iov_length and gss_wrap_iov:

gss_iov_buffer_desc iov[4];

char str[1024] = "message", *ptr;

@@ -610,7 +601,7 @@ STREAM buffer, unless it has the GSS_C_BUFFER_FLAG_ALLOCATE fla

set, in which case it will be initialized with a copy of the decrypted

data. Here is an example (token and token_len are assumed to be a

pre-existing pointer and length for a modifiable region of data):

gss_iov_buffer_desc iov[2];

iov[0].type = GSS_IOV_BUFFER_TYPE_STREAM;

@@ -625,13 +616,13 @@ pre-existing pointer and length for a modifiable region of data):

* token. */

</pre></div>

</div>

-</div>

-<div class="section" id="iov-mic-tokens">

+</section>

+<section id="iov-mic-tokens">

<h2>IOV MIC tokens<a class="headerlink" href="#iov-mic-tokens" title="Permalink to this headline">¶</a></h2>

-The following extensions (declared in <code class="docutils literal"><gssapi/gssapi_ext.h></code>) can

+The following extensions (declared in <code class="docutils literal notranslate"><gssapi/gssapi_ext.h></code>) can

be used in release 1.12 or later to construct and verify MIC tokens

using an IOV list:

-<div class="highlight-default"><div class="highlight"><pre>OM_uint32 gss_get_mic_iov(OM_uint32 *minor_status,

+<div class="highlight-default notranslate"><div class="highlight"><pre>OM_uint32 gss_get_mic_iov(OM_uint32 *minor_status,

gss_ctx_id_t context_handle,

gss_qop_t qop_req,

gss_iov_buffer_desc *iov,

@@ -654,10 +645,10 @@ using an IOV list:

structures, each containing a type and a gss_buffer_desc structure.

Valid types include:

-<li>GSS_C_BUFFER_TYPE_DATA and GSS_C_BUFFER_TYPE_SIGN_ONLY: The

+<li>GSS_C_BUFFER_TYPE_DATA and GSS_C_BUFFER_TYPE_SIGN_ONLY: The

corresponding buffer for each of these types will be signed for the

-MIC token, in the order provided.</li>

-<li>GSS_C_BUFFER_TYPE_MIC_TOKEN: The GSSAPI MIC token.</li>

+MIC token, in the order provided.</li>

+<li>GSS_C_BUFFER_TYPE_MIC_TOKEN: The GSSAPI MIC token.</li>

</ul>

The type of the MIC_TOKEN buffer may be combined with

GSS_C_BUFFER_FLAG_ALLOCATE to request that gss_get_mic_iov

@@ -668,7 +659,7 @@ buffers within an iov list and unset their allocated flags. Here is

an example of how gss_get_mic_iov can be used with allocation

requested (ctx is assumed to be a previously established

gss_ctx_id_t):

gss_iov_buffer_desc iov[3];

@@ -692,7 +683,7 @@ gss_ctx_id_t):

gss_get_mic_iov, it should first call gss_get_mic_iov_length to query

the length of the MIC_TOKEN buffer. Here is an example of using

gss_get_mic_iov_length and gss_get_mic_iov:

gss_iov_buffer_desc iov[2];

char data[1024];

@@ -713,15 +704,17 @@ gss_get_mic_iov_length and gss_get_mic_iov:

handle_error(major, minor);

</pre></div>

</div>

-</div>

+</section>

+ <div class="clearer"></div>

</div>

<ul>

<li><a class="reference internal" href="#">Developing with GSSAPI</a><ul>

@@ -772,6 +765,7 @@ gss_get_mic_iov_length and gss_get_mic_iov:

</form>

</div>

</div>

@@ -779,8 +773,8 @@ gss_get_mic_iov_length and gss_get_mic_iov:

- <div class="right" >Release: 1.21.2

+ <div class="right" >Release: 1.21.3

</div>