Internet-Draft J. Linn
IETF Common Authentication Technology WG OpenVision Technologies
draft-ietf-cat-kerb5gss-01.txt July 1994
The Kerberos Version 5 GSS-API Mechanism
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.
Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list.
ABSTRACT
This specification defines protocols, procedures, and conventions to
be employed by peers implementing the Generic Security Service
Application Program Interface (as specified in RFCs 1508 and 1509)
when using Kerberos Version 5 technology (as specified in RFC 1510).
ACKNOWLEDGMENTS
Much of the material in this Internet-Draft is based on working
documents drafted by John Wray of Digital Equipment Corporation and
on discussions, implementation activities, and interoperability
testing involving Marc Horowitz of OpenVision Technologies, Ted Ts'o
of the Massachusetts Institute of Technology (MIT), and John Wray.
Thanks are due to each of these individuals for their contributions
towards development and availability of GSS-API support within the
Kerberos Version 5 code base.
1. Token Formats
This section discusses protocol-visible characteristics of the GSS-
Linn Document Expiration: 31 January 1995 [Page 1]
Internet-Draft July 1994
API mechanism to be implemented atop Kerberos V5 security technology
per RFC-1508 and RFC-1510; it defines elements of protocol for
interoperability and is independent of language bindings per RFC-
1509.
Tokens transferred between GSS-API peers (for security context
management and per-message protection purposes) are defined. The
data elements exchanged between a GSS-API endpoint implementation and
the Kerberos KDC are not specific to GSS-API usage and are therefore
defined within RFC-1510 rather than within this specification.
To support ongoing experimentation, testing, and evolution of the
specification, the Kerberos V5 GSS-API mechanism as defined in this
and any successor Internet-Drafts will be identified with the
following Object Identifier, as defined in RFC-1510, until the
specification is advanced to the level of Proposed Standard RFC:
{iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}
Upon advancement to the level of Proposed Standard RFC, the Kerberos
V5 GSS-API mechanism will be identified by an Object Identifier
having the value:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2)}
1.1. Context Establishment Tokens
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType
-- MechType is OBJECT IDENTIFIER
-- representing "Kerberos V5"
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}
The innerContextToken of the initial context token will consist of a
Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
(TOK_ID) field, which shall contain the value 01 00.
The above GSS-API framing shall be applied to all tokens emitted by
the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
Linn Document Expiration: 31 January 1995 [Page 2]
Internet-Draft July 1994
context-deletion, and per-message tokens, not just to the initial
token in a context establishment sequence. While not required by
RFC-1508, this enables implementations to perform enhanced error-
checking. The innerContextToken field of context establishment tokens
for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
(KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
messages and 03 00 for KRB_ERROR messages.
Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER, -- indicates Version 5
msg-type [1] INTEGER, -- indicates KRB_AP_REQ
ap-options[2] APOptions,
ticket[3] Ticket,
authenticator[4] EncryptedData
}
APOptions ::= BIT STRING {
reserved (0),
use-session-key (1),
mutual-required (2)
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER, -- indicates Version 5
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags[0] TicketFlags,
key[1] EncryptionKey,
crealm[2] Realm,
cname[3] PrincipalName,
transited[4] TransitedEncoding,
authtime[5] KerberosTime,
starttime[6] KerberosTime OPTIONAL,
endtime[7] KerberosTime,
renew-till[8] KerberosTime OPTIONAL,
caddr[9] HostAddresses OPTIONAL,
authorization-data[10] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Linn Document Expiration: 31 January 1995 [Page 3]
Internet-Draft July 1994
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER,
crealm[1] Realm,
cname[2] PrincipalName,
cksum[3] Checksum OPTIONAL,
cusec[4] INTEGER,
ctime[5] KerberosTime,
subkey[6] EncryptionKey OPTIONAL,
seq-number[7] INTEGER OPTIONAL,
authorization-data[8] AuthorizationData OPTIONAL
}
For purposes of this specification, the authenticator shall include
the optional sequence number, and the checksum field shall be used to
convey the channel bindings. The checksum will have a type of 0x8003
(within the set of negative 16-bit values reserved by Kerberos for
application use), and a 24-byte value field, as follows:
Byte Name Description
0..3 Lgth Number of bytes in Bnd field;
Currently contains hex 10 00 00 00
(16, represented in little-endian form)
4..19 Bnd MD5 hash of channel bindings, taken over all non-null
components of bindings, in order of declaration.
Integer fields within channel bindings are represented
in little-endian order for the purposes of the MD5
calculation.
20..23 Flags Bit vector of context-establishment flags,
with values consistent with RFC-1509, p. 41:
GSS_C_DELEG_FLAG: 1
GSS_C_MUTUAL_FLAG: 2
GSS_C_REPLAY_FLAG: 4
GSS_C_SEQUENCE_FLAG: 8
GSS_C_CONF_FLAG: 16
GSS_C_INTEG_FLAG: 32
The resulting bit vector is encoded into bytes 20..23
in little-endian form.
In computing the contents of the "Bnd" field, the following detailed
points apply:
(1) Each integer field shall be formatted into four bytes, using
little-endian byte ordering, for purposes of MD5 hash
computation.
(2) All input length fields within gss_buffer_desc elements of a
gss_channel_bindings_struct, even those which are zero-valued,
shall be included in the hash calculation; the value elements of
Linn Document Expiration: 31 January 1995 [Page 4]
Internet-Draft July 1994
gss_buffer_desc elements shall be dereferenced, and the
resulting data shall be included within the hash computation,
only for the case of gss_buffer_desc elements having non-zero
length specifiers.
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of
a valid channel bindings structure, the Bnd field shall be set
to 16 zero-valued bytes.
It is anticipated that future extensions to this specification may
add new features by suffixing additional data following the checksum
value field as defined above. In order that such extended
implementations may remain interoperable with implementations based
on the current specification, implementations of this Internet-Draft
shall be capable of accepting checksum value fields with Lgth
specifiers indicating 24 bytes or greater. Processing procedures for
data elements within the checksum value field but after the Flags are
not, however, currently defined.
A context establishment sequence based on the Kerberos V5 mechanism
will perform one-way authentication (without confirmation or any
return token from target to initiator in response to the initiator's
KRB_AP_REQ) if the mutual_req bit is not set in the application's
call to gss_init_sec_context(). Applications requiring confirmation
that their authentication was successful should request mutual
authentication, resulting in a "mutual-required" indication within
KRB_AP_REQ APoptions and the setting of the mutual_req bit in the
flags field of the authenticator checksum. In response to such a
request, the context target will reply to the initiator with a token
containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
context establishment exchange.
Relevant KRB_AP_REP syntax is as follows:
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER, -- represents Kerberos V5
msg-type [1] INTEGER, -- represents KRB_AP_REP
enc-part [2] EncryptedData
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] INTEGER,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] INTEGER OPTIONAL
}
The optional seq-number element within the AP-REP's EncAPRepPart
Linn Document Expiration: 31 January 1995 [Page 5]
Internet-Draft July 1994
shall be included.
The syntax of KRB_ERROR is as follows:
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno[0] INTEGER,
msg-type[1] INTEGER,
ctime[2] KerberosTime OPTIONAL,
cusec[3] INTEGER OPTIONAL,
stime[4] KerberosTime,
susec[5] INTEGER,
error-code[6] INTEGER,
crealm[7] Realm OPTIONAL,
cname[8] PrincipalName OPTIONAL,
realm[9] Realm, -- Correct realm
sname[10] PrincipalName, -- Correct name
e-text[11] GeneralString OPTIONAL,
e-data[12] OCTET STRING OPTIONAL
}
Values to be transferred in the error-code field of a KRB-ERROR
message are defined in [RFC-1510], not in this specification.
1.2. Per-Message and Context Deletion Tokens
Three classes of tokens are defined in this section: "Sign" tokens,
emitted by calls to gss_sign() and consumed by calls to gss_verify(),
"Seal" tokens, emitted by calls to gss_seal() and consumed by calls
to gss_unseal(), and context deletion tokens, emitted by calls to
gss_delete_sec_context() and consumed by calls to
gss_process_context_token().
Several variants of cryptographic keys are used in generation and
processing of per-message tokens:
(1) context key: uses Kerberos session key (or subkey, if
present in authenticator emitted by context initiator) directly
(2) confidentiality key: forms variant of context key by
exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.
(3) MD2.5 seed key: forms variant of context key by reversing
the bytes of the context key (i.e. if the original key is the
8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
will be {hh, gg, ff, ee, dd, cc, bb, aa}).
1.2.1. Per-message Tokens - Sign
Linn Document Expiration: 31 January 1995 [Page 6]
Internet-Draft July 1994
Use of the gss_sign() call yields a token, separate from the user
data being protected, which can be used to verify the integrity of
that data as received. The token has the following format:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by gss_sign() contain
the hex value 01 01 in this field.
2..3 SGN_ALG Integrity algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.
GSS-API tokens must be encapsulated within the higher-level protocol
by the application; no embedded length field is necessary.
1.2.1.1. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the data field, logically prepended by the first
8 bytes of the plaintext packet header. The resulting signature
binds the data to the packet type and signature algorithm identifier
fields.
DES MAC MD5 algorithm: The checksum is formed by computing an MD5
[RFC-1321] hash over the plaintext data, and then computing a DES-CBC
MAC on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is
computed per [FIPS-PUB-113], employing the context key and a zero IV.
The 8-byte result is stored in the SGN_CKSUM field.
MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
16-byte zero-block, using a zero IV and a key formed by reversing the
bytes of the context key (i.e. if the original key is the 8-byte
sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
{hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
logically prepended to the to-be-signed data. A standard MD5
checksum is calculated over the combined data, and the first 8 bytes
of the result are stored in the SGN_CKSUM field. (Note: we refer to
this algorithm informally as "MD2.5" to connote the fact that it uses
half of the 128 bits generated by MD5; use of only a subset of the
MD5 bits is intended to protect against the prospect that data could
be postfixed to an existing message with corresponding modifications
being made to the checksum.)
Linn Document Expiration: 31 January 1995 [Page 7]
Internet-Draft July 1994
DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
plaintext data per [FIPS-PUB-113], employing the context key and a
zero IV. Padding procedures to accomodate plaintext data lengths
which may not be integral multiples of 8 bytes are defined in [FIPS-
PUB-113]. The result is an 8-byte value, which is stored in the
SGN_CKSUM field. Support for this algorithm may not be present in
all implementations.
1.2.1.2. Sequence Number
Sequence number field: The 8 byte plaintext sequence number field is
formed from the sender's four-byte sequence number as follows. If
the four bytes of the sender's sequence number are named s0, s1, s2
and s3 (from least to most significant), the plaintext sequence
number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
di), where 'di' is the direction-indicator (Hex 0 - sender is the
context initiator, Hex FF - sender is the context acceptor). The
field is then DES-CBC encrypted using the context key and an IV
formed from the first 8 bytes of the previously calculated SGN_CKSUM
field. After sending a gss_sign() or gss_seal() token, the sender's
sequence number is incremented by one.
The receiver of the token will first verify the SGN_CKSUM field. If
valid, the sequence number field may be decrypted and compared to the
expected sequence number. The repetition of the (effectively 1-bit)
direction indicator within the sequence number field provides
redundancy so that the receiver may verify that the decryption
succeeded.
Since the checksum computation is used as an IV to the sequence
number decryption, attempts to splice a checksum and sequence number
from different messages will be detected. The direction indicator
will detect packets that have been maliciously reflected.
1.2.2. Per-message Tokens - Seal
Use of the gss_seal() call yields a token which encapsulates the
input user data (optionally encrypted) along with associated
integrity check quantities. The token emitted by gss_seal() consists
of an integrity header whose format is identical to that emitted by
gss_sign() (except that the TOK_ID field contains the value 02 01),
followed by a body portion that contains either the plaintext data
(if SEAL_ALG = ff ff) or encrypted data for any other supported value
of SEAL_ALG. Currently, only SEAL_ALG = 00 00 is supported, and
means that DES-CBC encryption is being used to protect the data.
The gss_seal() token has the following format:
Linn Document Expiration: 31 January 1995 [Page 8]
Internet-Draft July 1994
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by gss_seal() contain
the hex value 02 01 in this field.
2..3 SGN_ALG Checksum algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..5 SEAL_ALG ff ff - none
00 00 - DES
6..7 Filler Contains ff ff
8..15 SND_SEQ Encrypted sequence number field.
16..23 SGN_CKSUM Checksum of plaintext padded data,
calculated according to algorithm
specified in SGN_ALG field.
24..last Data encrypted or plaintext padded data
GSS-API tokens must be encapsulated within the higher-level protocol
by the application; no embedded length field is necessary.
1.2.2.1. Checksum
Checksum calculation procedure (common to all algorithms): Checksums
are calculated over the plaintext padded data field, logically
prepended by the first 8 bytes of the plaintext packet header. The
resulting signature binds the data to the packet type, protocol
version, and signature algorithm identifier fields.
DES MAC MD5 algorithm: The checksum is formed by computing an MD5
hash over the plaintext padded data, and then computing a DES-CBC MAC
on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is computed
per [FIPS-PUB-113], employing the context key and a zero IV. The 8-
byte result is stored in the SGN_CKSUM field.
MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
16-byte zero-block, using a zero IV and a key formed by reversing the
bytes of the context key (i.e., if the original key is the 8-byte
sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
{hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
logically pre-pended to the "to-be-signed data". A standard MD5
checksum is calculated over the combined data, and the first 8 bytes
of the result are stored in the SGN_CKSUM field.
DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
plaintext padded data per [FIPS-PUB-113], employing the context key
and a zero IV. The plaintext padded data is already assured to be an
integral multiple of 8 bytes; no additional padding is required or
applied in order to accomplish MAC calculation. The result is an 8-
Linn Document Expiration: 31 January 1995 [Page 9]
Internet-Draft July 1994
byte value, which is stored in the SGN_CKSUM field. Support for this
algorithm may not be present in all implementations.
1.2.2. Sequence Number
Sequence number field: The 8 byte plaintext sequence number field is
formed from the sender's four-byte sequence number as follows. If
the four bytes of the sender's sequence number are named s0, s1, s2
and s3 (from least to most significant), the plaintext sequence
number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
di), where 'di' is the direction-indicator (Hex 0 - sender is the
context initiator, Hex FF - sender is the context acceptor).
The field is then DES-CBC encrypted using the context key and an IV
formed from the first 8 bytes of the SEAL_CKSUM field.
After sending a gss_sign() or gss_seal() token, the sender's sequence
numbers are incremented by one.
1.2.2.3: Padding
Data padding: Before encryption and/or signature calculation,
plaintext data is padded to the next highest multiple of 8 bytes, by
appending between 1 and 8 bytes, the value of each such byte being
the total number of pad bytes. For example, given data of length 20
bytes, four pad bytes will be appended, and each byte will contain
the hex value 04. An 8-byte random confounder is prepended to the
data, and signatures are calculated over the resulting padded
plaintext.
After padding, the data is encrypted according to the algorithm
specified in the SEAL_ALG field. For SEAL_ALG=DES (the only non-null
algorithm currently supported), the data is encrypted using DES-CBC,
with an IV of zero. The key used is derived from the established
context key by XOR-ing the context key with the hexadecimal constant
f0f0f0f0f0f0f0f0.
1.2.3. Context deletion token
The token emitted by gss_delete_sec_context() is based on the packet
format for tokens emitted by gss_sign(). The context-deletion token
has the following format:
Byte no Name Description
0..1 TOK_ID Identification field.
Tokens emitted by
gss_delete_sec_context() contain
the hex value 01 02 in this field.
Linn Document Expiration: 31 January 1995 [Page 10]
Internet-Draft July 1994
2..3 SGN_ALG Integrity algorithm indicator.
00 00 - DES MAC MD5
01 00 - MD2.5
02 00 - DES MAC
4..7 Filler Contains ff ff ff ff
8..15 SND_SEQ Sequence number field.
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to algorithm
specified in SGN_ALG field.
SGN_ALG and SND_SEQ will be calculated as for tokens emitted by
gss_sign(). The SGN_CKSUM will be calculated as for tokens emitted
by gss_sign(), except that the user-data component of the "to-be-
signed" data will be a zero-length string.
2. Name Types and Object Identifiers
This section discusses the name types which may be passed as input to
the Kerberos V5 GSS-API mechanism's gss_import_name() call, and their
associated identifier values. It defines interface elements in
support of portability, and assumes use of C language bindings per
RFC-1509. In addition to specifying OID values for name type
identifiers, symbolic names are included and recommended to GSS-API
implementors in the interests of convenience to callers. It is
understood that not all implementations of the Kerberos V5 GSS-API
mechanism need support all name types in this list, and that
additional name forms will likely be added to this list over time.
Further, the definitions of some or all name types may later migrate
to other, mechanism-independent, specifications. The occurrence of a
name type in this specification is specifically not intended to
suggest that the type may be supported only by an implementation of
the Kerberos V5 mechanism. In particular, the occurrence of the
string "_KRB5_" in the symbolic name strings constitutes a means to
unambiguously register the name strings, avoiding collision with
other documents; it is not meant to limit the name types' usage or
applicability.
For purposes of clarification to GSS-API implementors, this section's
discussion of some name forms describes means through which those
forms can be supported with existing Kerberos technology. These
discussions are not intended to preclude alternative implementation
strategies for support of the name forms within Kerberos mechanisms
or mechanisms based on other technologies. To enhance application
portability, implementors of mechanisms are encouraged to support
name forms as defined in this section, even if their mechanisms are
independent of Kerberos V5.
2.1. Mandatory Name Forms
Linn Document Expiration: 31 January 1995 [Page 11]
Internet-Draft July 1994
This section discusses name forms which are to be supported by all
conformant implementations of the Kerberos V5 GSS-API mechanism.
2.1.1 Kerberos Principal Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
krb5(2) krb5_name(1)}. The recommended symbolic name for this type is
"GSS_KRB5_NT_PRINCIPAL_NAME".
This name type represents any valid Kerberos name parseable by the
Kerberos V5 routine krb5_parse_name; such names have characteristics
as follows: Components of a name are separated by `/`. The separator
`@` may be used instead of `/`, signifying that the remainder of the
string following the `@` is to be interpreted as a realm identifier;
if no `@` is encountered, the name is interpreted in the context of
the local realm. Once a `@` is encountered, a non-null realm name,
with no embedded `/` separators, must follow. The `\` character is
used to quote the immediately-following character.
2.1.2. Host-Based Service Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) service_name(4)}. The recommended symbolic name for this
type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".
This name type is used to represent services associated with host
computers. The two parts of this name form, which is constructed as:
service@hostname
can be supported with Kerberos V5 technology by passing those name
parts as the first two arguments to the Kerberos V5 library function
krb5_sname_to_principal, with the type argument set to
KRB5_NT_SRV_HST. This processing canonicalizes the hostname (by
attempting a DNS lookup and using the fully-qualified domain name
returned, or using the name as input should the DNS lookup fail), and
ensures that its characters are lower case. No facility is currently
provided for explicit specification of a Kerberos realm.
2.2. Optional Name Forms
This section discusses additional name forms which may optionally be
supported by implementations of the Kerberos V5 GSS-API mechanism.
It is recognized that the set of name forms cited here are derived
from UNIX(tm) operating system platforms; some listed forms may be
irrelevant to non-UNIX platforms, and definition of additional forms
Linn Document Expiration: 31 January 1995 [Page 12]
Internet-Draft July 1994
corresponding to such platforms may also be appropriate. It is also
recognized that OS-specific functions outside GSS-API are likely to
exist in order to perform translations among these forms, and that
GSS-API implementations supporting these forms may themselves be
layered atop such OS-specific functions. Inclusion of this support
within GSS-API implementations is intended as a convenience to
applications.
2.2.1. User Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) user_name(1)}. The recommended symbolic name for this
type is "GSS_KRB5_NT_USER_NAME".
This name type is used to indicate a named user on a local system.
Its interpretation is OS-specific. This name form is constructed as:
username
Assuming that users' principal names are the same as their local
operating system names, an implementation of gss_import_name() based
on Kerberos V5 technology can process names of this form by
postfixing an "@" sign and the name of the local realm.
2.2.2. Machine UID Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) machine_uid_name(2)}. The recommended symbolic name for
this type is "GSS_KRB5_NT_MACHINE_UID_NAME".
This name type is used to indicate a numeric user identifier
corresponding to a user on a local system. Its interpretation is
OS-specific. The gss_buffer_desc representing a name of this type
should contain a locally-significant uid_t, represented in host byte
order. The gss_import_name() operation resolves this uid into a
username, which is then treated as the User Name Form.
2.2.3. String UID Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
generic(1) string_uid_name(3)}. The recommended symbolic name for
this type is "GSS_KRB5_NT_STRING_UID_NAME".
This name type is used to indicate a string of digits representing
the numeric user identifier of a user on a local system. Its
Linn Document Expiration: 31 January 1995 [Page 13]
Internet-Draft July 1994
interpretation is OS-specific. This name type is similar to the
Machine UID Form, except that the buffer contains a string
representing the uid_t.
2.3. Internal Name Object Support
This section defines optional routines for use by implementations of
the Kerberos V5 mechanism which enable support for input and output
of Kerberos principal objects as naming structures, and defines an
identifier for this name form. Implementors should note that use of
these routines, and associated mechanism-specific name objects, by an
application is a construct unlikely to be portable to other
mechanisms.
2.3.1. GSS_Import_internal_name routine
OM_uint32 gss_import_internal_name(
OM_uint32 minor_status,
void * input_name,
gss_oid_t name_type,
gss_name_t * output_name);
Converts an implementation-specific name <input_name> into a
gss_name_t. The name_type argument specifies the format of
input_name.
2.3.2. GSS_Export_internal_name routine
OM_uint32 gss_export_internal_name(
OM_uint32 minor_status,
gss_name_t input_name,
gss_oid_t desired_name_type,
void ** output_name);
Converts a gss_name_t name into an implementation-specific
representation. The desired representation is specified by the
<desired_name_type> argument. Note that it may not be possible to
convert some gss_name_t values into some supported internal name
types.
2.3.3. krb5_principal Form
This mechanism-internal name form shall be represented by the Object
Identifier {iso(1) member-body(2) United States(840) mit(113554)
infosys(1) gssapi(2) krb5(2) krb5_principal(2)}. The recommended
symbolic name for this type is "GSS_KRB5_NT_PRINCIPAL". A name of
this type shall be referenced via a krb5_principal object (which is
defined within the MIT Kerberos V5 implementation as a pointer to a
Linn Document Expiration: 31 January 1995 [Page 14]
Internet-Draft July 1994
krb5_principal_data object), with the krb5_principal's data type cast
to (void *).
3. Parameter Definitions
This section defines parameter values used by the Kerberos V5 GSS-API
mechanism. It defines interface elements in support of portability,
and assumes use of C language bindings per RFC-1509.
3.1. Minor Status Codes
This section recommends common symbolic names for minor_status values
to be returned by the Kerberos V5 GSS-API mechanism. Use of these
definitions will enable independent implementors to enhance
application portability across different implementations of the
mechanism defined in this specification. (In all cases,
implementations of gss_display_status() will enable callers to
convert minor_status indicators to text representations.) Each
implementation should make available, through include files or other
means, a facility to translate these symbolic names into the concrete
values which a particular GSS-API implementation uses to represent
the minor_status values specified in this section. It is recognized
that this list may grow over time, and that the need for additional
minor_status codes specific to particular implementations may arise.
3.1.1. Non-Kerberos-specific codes
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
3.1.2. Kerberos-specific-codes
Linn Document Expiration: 31 January 1995 [Page 15]
Internet-Draft July 1994
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Principal in credential cache does not match desired name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No principal in keytab matches desired name" */
GSS_KRB5_S_KG_TGT_MISSING
/* "Credential cache has no TGT" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
3.2. Quality of Protection Values
The following Quality of Protection (QOP) values are currently
defined for the Kerberos V5 GSS-API mechanism, and are used as input
to gss_sign() and gss_seal() to select among alternate integrity
checking algorithms. Additional QOP values corresponding to
additional integrity and/or confidentiality algorithms may be added
in future versions of this specification.
GSS_KRB5_INTEG_C_QOP_MD5
/* Integrity using partial MD5 ("MD2.5") of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MD5
/* Integrity using DES MAC of MD5 of plaintext */
GSS_KRB5_INTEG_C_QOP_DES_MAC
/* Integrity using DES MAC of plaintext */
3.3. Buffer Sizes
All implementations of this specification shall be capable of
accepting buffers of at least 2 Kbytes as input to GSS_Sign(),
GSS_Verify(), and GSS_Seal(), and shall be capable of accepting the
output_token generated by GSS_Seal() for a 2 Kbyte input buffer as
input to GSS_Unseal(). Support for larger buffer sizes is optional
but recommended.
4. Security Considerations
Security issues are discussed throughout this memo.
5. References
Linn Document Expiration: 31 January 1995 [Page 16]
Internet-Draft July 1994
[RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321.
[RFC-1508]: J. Linn, "Generic Security Service Application Program
Interface", RFC 1508.
[RFC-1509]: J. Wray, "Generic Security Service Application Program
Interface: C-bindings", RFC 1509.
[RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510.
[FIPS-PUB-113]: National Bureau of Standards, Federal Information
Processing Standard 113, "Computer Data Authentication", May 1985.
Linn Document Expiration: 31 January 1995 [Page 17]
Internet-Draft July 1994
AUTHOR'S ADDRESS
John Linn
OpenVision Technologies
One Main St.
Cambridge, MA 02142 USA
Phone: +1 617.374.2245
E-mail: Linn@cam.ov.com
Linn Document Expiration: 31 January 1995 [Page 18]
