RFC relevance of represent

As per Relevance of the word represent, we have this rfc below:

Network Working Group J.
Request for Comments: 1964 OpenVision
Category: Standards Track June 1996

The Kerberos Version 5 GSS-API

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

This specification defines protocols, procedures, and conventions
be employed by peers implementing the Generic Security
Application Program Interface (as specified in RFCs 1508 and 1509)
when using Kerberos Version 5 technology (as specified in RFC 1510).

Much of the material in this memo is based on working
drafted by John Wray of Digital Equipment Corporation and
discussions, implementation activities, and interoperability
involving Marc Horowitz, Ted Ts'o, and John Wray. Particular
are due to each of these individuals for their contributions
development and availability of GSS-API support within the
Version 5 code base

1. Token

This section discusses protocol-visible characteristics of the GSS
API mechanism to be implemented atop Kerberos V5 security
per RFC-1508 and RFC-1510; it defines elements of protocol
interoperability and is independent of language bindings per RFC
1509.

Tokens transferred between GSS-API peers (for security
management and per-message protection purposes) are defined.
data elements exchanged between a GSS-API endpoint implementation
the Kerberos KDC are not specific to GSS-API usage and are
defined within RFC-1510 rather than within this specification

Linn Standards Track [Page 1]

RFC 1964 Kerberos Version 5 GSS-API June 1996

To support ongoing experimentation, testing, and evolution of
specification, the Kerberos V5 GSS-API mechanism as defined in
and any successor memos will be identified with the following
Identifier, as defined in RFC-1510, until the specification
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
V5 GSS-API mechanism will be identified by an Object
having the value

{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2)}

1.1. Context Establishment

Per RFC-1508, Appendix B, the initial context establishment
will be enclosed within framing as follows

InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech
-- MechType is OBJECT
-- representing "Kerberos V5"
innerContextToken ANY DEFINED BY
-- contents mechanism-specific
-- ASN.1 usage within
-- is not
}

The innerContextToken of the initial context token will consist of
Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-
(TOK_ID) field, which shall contain the value 01 00.

The above GSS-API framing shall be applied to all tokens emitted
the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR
context-deletion, and per-message tokens, not just to the
token in a context establishment sequence. While not required
RFC-1508, this enables implementations to perform enhanced error
checking. The innerContextToken field of context establishment
for the Kerberos V5 GSS-API mechanism will contain a Kerberos
(KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_
field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_
messages and 03 00 for KRB_ERROR messages

Linn Standards Track [Page 2]

RFC 1964 Kerberos Version 5 GSS-API June 1996

1.1.1. Initial

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_
ap-options[2] APOptions
ticket[3] Ticket
authenticator[4]
}

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]
}

-- Encrypted part of
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
}

-- Unencrypted
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno[0] INTEGER
crealm[1] Realm
cname[2] PrincipalName
cksum[3] Checksum OPTIONAL
cusec[4] INTEGER
ctime[5] KerberosTime

Linn Standards Track [Page 3]

RFC 1964 Kerberos Version 5 GSS-API June 1996

subkey[6] EncryptionKey OPTIONAL
seq-number[7] INTEGER OPTIONAL
authorization-data[8] AuthorizationData
}

For purposes of this specification, the authenticator shall
the optional sequence number, and the checksum field shall be used
convey channel binding, service flags, and optional
information. The checksum will have a type of 0x8003 (a value
registered within the Kerberos protocol specification), and a
field of at least 24 bytes in length. The length of the value
is extended beyond 24 bytes if and only if an optional facility
carry a Kerberos-defined KRB_CRED message for delegation purposes
supported by an implementation and active on a context.
delegation is active, a TGT with its FORWARDABLE flag set will
transferred within the KRB_CRED message

The checksum value field's format is as follows

Byte Name
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-
components of bindings, in order of declaration
Integer fields within channel bindings are
in little-endian order for the purposes of the MD
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
24..25 DlgOpt The Delegation Option identifier (=1) [optional
26..27 Dlgth The length of the Deleg field. [optional
28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional

In computing the contents of the "Bnd" field, the following
points apply

(1) Each integer field shall be formatted into four bytes,
little-endian byte ordering, for purposes of MD5
computation

Linn Standards Track [Page 4]

RFC 1964 Kerberos Version 5 GSS-API June 1996

(2) All input length fields within gss_buffer_desc elements of
gss_channel_bindings_struct, even those which are zero-valued
shall be included in the hash calculation; the value elements
gss_buffer_desc elements shall be dereferenced, and
resulting data shall be included within the hash computation
only for the case of gss_buffer_desc elements having non-
length specifiers

(3) If the caller passes the value GSS_C_NO_BINDINGS instead
a valid channel bindings structure, the Bnd field shall be
to 16 zero-valued bytes

In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token
from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG
GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be
as the logical AND of the initiator's corresponding request flag
GSS_Init_sec_context() and a Boolean indicator of whether
optional service is available to GSS_Init_sec_context()'s caller
GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no
context-level input indicator flags to GSS_Init_sec_context() exist
shall each be set to indicate whether their respective per-
protection services are available for use on the context
established

When input source address channel binding values are provided by
caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or
source address specifier value within the input structure
GSS_C_NULL_ADDRTYPE), and the corresponding token received from
context's peer bears address restrictions, it is recommended that
implementation of the Kerberos V5 GSS-API mechanism should check
the source address as provided by the caller matches that in
received token, and should return the GSS_S_BAD_BINDINGS major_
value if a mismatch is detected. Note: discussion is ongoing
the strength of recommendation to be made in this area, and on
circumstances under which such a recommendation should be applicable
implementors are therefore advised that changes on this matter may
included in subsequent versions of this specification

1.1.2. Response

A context establishment sequence based on the Kerberos V5
will perform one-way authentication (without confirmation or
return token from target to initiator in response to the initiator'
KRB_AP_REQ) if the mutual_req bit is not set in the application'
call to GSS_Init_sec_context(). Applications requiring
that their authentication was successful should request
authentication, resulting in a "mutual-required" indication
KRB_AP_REQ APoptions and the setting of the mutual_req bit in

Linn Standards Track [Page 5]

RFC 1964 Kerberos Version 5 GSS-API June 1996

flags field of the authenticator checksum. In response to such
request, the context target will reply to the initiator with a
containing either a KRB_AP_REP or KRB_ERROR, completing the
context establishment exchange

Relevant KRB_AP_REP syntax is as follows

AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER, -- represents Kerberos V
msg-type [1] INTEGER, -- represents KRB_AP_
enc-part [2]
}

EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime
cusec [1] INTEGER
subkey [2] EncryptionKey OPTIONAL
seq-number [3] INTEGER
}

The optional seq-number element within the AP-REP's
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
sname[10] PrincipalName, -- Correct
e-text[11] GeneralString OPTIONAL
e-data[12] OCTET STRING
}

Values to be transferred in the error-code field of a KRB-
message are defined in [RFC-1510], not in this specification

Linn Standards Track [Page 6]

RFC 1964 Kerberos Version 5 GSS-API June 1996

1.2. Per-Message and Context Deletion

Three classes of tokens are defined in this section: "MIC" tokens
emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and
by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens
emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed
calls to GSS_Unwrap() (formerly GSS_Unseal()), and context
tokens, emitted by calls to GSS_Delete_sec_context() and consumed
calls to GSS_Process_context_token(). Note: References to GSS-
per-message routines in the remainder of this specification will
based on those routines' newer recommended names rather than
names' predecessors

Several variants of cryptographic keys are used in generation
processing of per-message tokens

(1) context key: uses Kerberos session key (or subkey,
present in authenticator emitted by context initiator)

(2) confidentiality key: forms variant of context key
exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.

(3) MD2.5 seed key: forms variant of context key by
the bytes of the context key (i.e. if the original key is
8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed
will be {hh, gg, ff, ee, dd, cc, bb, aa}).

1.2.1. Per-message Tokens -

Use of the GSS_GetMIC() call yields a token, separate from the
data being protected, which can be used to verify the integrity
that data as received. The token has the following format

Byte no Name
0..1 TOK_ID Identification field
Tokens emitted by GSS_GetMIC()
the hex value 01 01 in this field
2..3 SGN_ALG Integrity algorithm indicator
00 00 - DES MAC MD
01 00 - MD2.5
02 00 - DES
4..7 Filler Contains ff ff ff
8..15 SND_SEQ Sequence number field
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to
specified in SGN_ALG field

Linn Standards Track [Page 7]

RFC 1964 Kerberos Version 5 GSS-API June 1996

GSS-API tokens must be encapsulated within the higher-level
by the application; no embedded length field is necessary

1.2.1.1.

Checksum calculation procedure (common to all algorithms):
are calculated over the data field, logically prepended by the
8 bytes of the plaintext packet header. The resulting value
the data to the packet type and signature algorithm
fields

DES MAC MD5 algorithm: The checksum is formed by computing an MD
[RFC-1321] hash over the plaintext data, and then computing a DES-
MAC on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC
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
16-byte zero-block, using a zero IV and a key formed by reversing
bytes of the context key (i.e. if the original key is the 8-
sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will
{hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value
logically prepended to the to-be-signed data. A standard MD
checksum is calculated over the combined data, and the first 8
of the result are stored in the SGN_CKSUM field. Note 1: we refer
this algorithm informally as "MD2.5" to connote the fact that it
half of the 128 bits generated by MD5; use of only a subset of
MD5 bits is intended to protect against the prospect that data
be postfixed to an existing message with corresponding
being made to the checksum. Note 2: This algorithm is fairly
and has received more limited evaluation than that to which
integrity algorithms have been subjected. An initial,
evaluation indicates that it may be significantly weaker than DES
MD5.

DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on
plaintext data per [FIPS-PUB-113], employing the context key and
zero IV. Padding procedures to accomodate plaintext data
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
SGN_CKSUM field. Support for this algorithm may not be present
all implementations

1.2.1.2. Sequence

Sequence number field: The 8 byte plaintext sequence number field
formed from the sender's four-byte sequence number as follows.
the four bytes of the sender's sequence number are named s0, s1, s

Linn Standards Track [Page 8]

RFC 1964 Kerberos Version 5 GSS-API June 1996

and s3 (from least to most significant), the plaintext
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
context initiator, Hex FF - sender is the context acceptor).
field is then DES-CBC encrypted using the context key and an
formed from the first 8 bytes of the previously calculated SGN_
field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender'
sequence number is incremented by one

The receiver of the token will first verify the SGN_CKSUM field.
valid, the sequence number field may be decrypted and compared to
expected sequence number. The repetition of the (effectively 1-bit
direction indicator within the sequence number field
redundancy so that the receiver may verify that the
succeeded

Since the checksum computation is used as an IV to the
number decryption, attempts to splice a checksum and sequence
from different messages will be detected. The direction
will detect packets that have been maliciously reflected

The sequence number provides a basis for detection of
tokens. Replay detection can be performed using state
retained on received sequence numbers, interpreted in
with the security context on which they arrive

Provision of per-message replay and out-of-sequence
services is optional for implementations of the Kerberos V5 GSS-
mechanism. Further, it is recommended that implementations of
Kerberos V5 GSS-API mechanism which offer these services should
a caller's request that the services be disabled on a context
Specifically, if replay_det_req_flag is input FALSE, replay_det_
should be returned FALSE and the GSS_DUPLICATE_TOKEN
GSS_OLD_TOKEN stati should not be indicated as a result of
detection when tokens are processed; if sequence_req_flag is
FALSE, sequence_state should be returned FALSE
GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati
not be indicated as a result of out-of-sequence detection when
are processed

1.2.2. Per-message Tokens -

Use of the GSS_Wrap() call yields a token which encapsulates
input user data (optionally encrypted) along with
integrity check quantities. The token emitted by GSS_Wrap()
of an integrity header whose format is identical to that emitted
GSS_GetMIC() (except that the TOK_ID field contains the value 02 01),
followed by a body portion that contains either the plaintext

Linn Standards Track [Page 9]

RFC 1964 Kerberos Version 5 GSS-API June 1996

(if SEAL_ALG = ff ff) or encrypted data for any other supported
of SEAL_ALG. Currently, only SEAL_ALG = 00 00 is supported,
means that DES-CBC encryption is being used to protect the data

The GSS_Wrap() token has the following format

Byte no Name
0..1 TOK_ID Identification field
Tokens emitted by GSS_Wrap()
the hex value 02 01 in this field
2..3 SGN_ALG Checksum algorithm indicator
00 00 - DES MAC MD
01 00 - MD2.5
02 00 - DES
4..5 SEAL_ALG ff ff -
00 00 -
6..7 Filler Contains ff
8..15 SND_SEQ Encrypted sequence number field
16..23 SGN_CKSUM Checksum of plaintext padded data
calculated according to
specified in SGN_ALG field
24..last Data encrypted or plaintext padded

GSS-API tokens must be encapsulated within the higher-level
by the application; no embedded length field is necessary

1.2.2.1.

Checksum calculation procedure (common to all algorithms):
are calculated over the plaintext padded data field,
prepended by the first 8 bytes of the plaintext packet header.
resulting signature binds the data to the packet type,
version, and signature algorithm identifier fields

DES MAC MD5 algorithm: The checksum is formed by computing an MD
hash over the plaintext padded data, and then computing a DES-CBC
on the 16-byte MD5 result. A standard 64-bit DES-CBC MAC is
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
16-byte zero-block, using a zero IV and a key formed by reversing
bytes of the context key (i.e., if the original key is the 8-
sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will
{hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value
logically pre-pended to the "to-be-signed data". A standard MD
checksum is calculated over the combined data, and the first 8
of the result are stored in the SGN_CKSUM field

Linn Standards Track [Page 10]

RFC 1964 Kerberos Version 5 GSS-API June 1996

DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on
plaintext padded data per [FIPS-PUB-113], employing the context
and a zero IV. The plaintext padded data is already assured to be
integral multiple of 8 bytes; no additional padding is required
applied in order to accomplish MAC calculation. The result is an 8-
byte value, which is stored in the SGN_CKSUM field. Support for
lgorithm may not be present in all implementations

1.2.2.2. Sequence

Sequence number field: The 8 byte plaintext sequence number field
formed from the sender's four-byte sequence number as follows.
the four bytes of the sender's sequence number are named s0, s1, s
and s3 (from least to most significant), the plaintext
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
context initiator, Hex FF - sender is the context acceptor).

The field is then DES-CBC encrypted using the context key and an
formed from the first 8 bytes of the SEAL_CKSUM field

After sending a GSS_GetMIC() or GSS_Wrap() token, the sender'
sequence numbers are incremented by one

1.2.2.3.

Data padding: Before encryption and/or signature calculation
plaintext data is padded to the next highest multiple of 8 bytes,
appending between 1 and 8 bytes, the value of each such byte
the total number of pad bytes. For example, given data of length 20
bytes, four pad bytes will be appended, and each byte will
the hex value 04. An 8-byte random confounder is prepended to
data, and signatures are calculated over the resulting
plaintext

After padding, the data is encrypted according to the
specified in the SEAL_ALG field. For SEAL_ALG=DES (the only non-
algorithm currently supported), the data is encrypted using DES-CBC
with an IV of zero. The key used is derived from the
context key by XOR-ing the context key with the hexadecimal
f0f0f0f0f0f0f0f0.

1.2.3. Context deletion

The token emitted by GSS_Delete_sec_context() is based on the
format for tokens emitted by GSS_GetMIC(). The context-
token has the following format

Linn Standards Track [Page 11]

RFC 1964 Kerberos Version 5 GSS-API June 1996

Byte no Name
0..1 TOK_ID Identification field
Tokens emitted
GSS_Delete_sec_context()
the hex value 01 02 in this field
2..3 SGN_ALG Integrity algorithm indicator
00 00 - DES MAC MD
01 00 - MD2.5
02 00 - DES
4..7 Filler Contains ff ff ff
8..15 SND_SEQ Sequence number field
16..23 SGN_CKSUM Checksum of "to-be-signed data",
calculated according to
specified in SGN_ALG field

SGN_ALG and SND_SEQ will be calculated as for tokens emitted
GSS_GetMIC(). The SGN_CKSUM will be calculated as for tokens
by GSS_GetMIC(), except that the user-data component of the "to-be
signed" data will be a zero-length string

2. Name Types and Object

This section discusses the name types which may be passed as input
the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and
associated identifier values. It defines interface elements
support of portability, and assumes use of C language bindings
RFC-1509. In addition to specifying OID values for name
identifiers, symbolic names are included and recommended to GSS-
implementors in the interests of convenience to callers. It
understood that not all implementations of the Kerberos V5 GSS-
mechanism need support all name types in this list, and
additional name forms will likely be added to this list over time
Further, the definitions of some or all name types may later
to other, mechanism-independent, specifications. The occurrence of
name type in this specification is specifically not intended
suggest that the type may be supported only by an implementation
the Kerberos V5 mechanism. In particular, the occurrence of
string "_KRB5_" in the symbolic name strings constitutes a means
unambiguously register the name strings, avoiding collision
other documents; it is not meant to limit the name types' usage
applicability

For purposes of clarification to GSS-API implementors, this section'
discussion of some name forms describes means through which
forms can be supported with existing Kerberos technology.
discussions are not intended to preclude alternative
strategies for support of the name forms within Kerberos
or mechanisms based on other technologies. To enhance

Linn Standards Track [Page 12]

RFC 1964 Kerberos Version 5 GSS-API June 1996

portability, implementors of mechanisms are encouraged to
name forms as defined in this section, even if their mechanisms
independent of Kerberos V5.

2.1. Mandatory Name

This section discusses name forms which are to be supported by
conformant implementations of the Kerberos V5 GSS-API mechanism

2.1.1. Kerberos Principal Name

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
is "GSS_KRB5_NT_PRINCIPAL_NAME".

This name type corresponds to the single-string representation of
Kerberos name. (Within the MIT Kerberos V5 implementation,
names are parseable with the krb5_parse_name() function.)
elements included within this name representation are as follows
proceeding from the beginning of the string

(1) One or more principal name components; if more than
principal name component is included, the components
separated by `/`. Arbitrary octets may be included
principal name components, with the following constraints
special considerations

(1a) Any occurrence of the characters `@` or `/` within
name component must be immediately preceded by the `\`
quoting character, to prevent interpretation as a
or realm separator

(1b) The ASCII newline, tab, backspace, and null
may occur directly within the component or may
represented, respectively, by `\n`, `\t`, `\b`, or `\0`.

(1c) If the `\` quoting character occurs outside the
described in (1a) and (1b) above, the following character
interpreted literally. As a special case, this allows
doubled representation `\\` to represent a single
of the quoting character

(1d) An occurrence of the `\` quoting character as the
character of a component is illegal

Linn Standards Track [Page 13]

RFC 1964 Kerberos Version 5 GSS-API June 1996

(2) Optionally, a `@` character, signifying that a realm
immediately follows. If no realm name element is included,
local realm name is assumed. The `/` , `:`, and null
may not occur within a realm name; the `@`, newline, tab,
backspace characters may be included using the
conventions described in (1a), (1b), and (1c) above

2.1.2. Host-Based Service Name

This name form has been incorporated at the mechanism-
GSS-API level as of GSS-API, Version 2. This subsection retains
Object Identifier and symbolic name assignments previously made
the Kerberos V5 GSS-API mechanism level, and adopts the definition
promoted to the mechanism-independent level

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 previously recommended
name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".
currently preferred symbolic name for this type
"GSS_C_NT_HOSTBASED_SERVICE".

This name type is used to represent services associated with
computers. This name form is constructed using two elements
"service" and "hostname", as follows

service@

When a reference to a name of this type is resolved, the "hostname
is canonicalized by attempting a DNS lookup and using the fully
qualified domain name which is returned, or by using the "hostname
as provided if the DNS lookup fails. The canonicalization
also maps the host's name into lower-case characters

The "hostname" element may be omitted. If no "@" separator
included, the entire name is interpreted as the service specifier
with the "hostname" defaulted to the canonicalized name of the
host

Values for the "service" element will be registered with the IANA

2.1.3. Exported Name Object Form for Kerberos V5

Support for this name form is not required for GSS-V
implementations, but will be required for use in conjunction with
GSS_Export_name() call planned for GSS-API Version 2. Use of
name form will be signified by a "GSS-API Exported Name Object"
value which will be defined at the mechanism-independent level

Linn Standards Track [Page 14]

RFC 1964 Kerberos Version 5 GSS-API June 1996

GSS-API Version 2.

This name type represents a self-describing object, whose
structure will be defined at the mechanism-independent level
GSS-API Version 2. When generated by the Kerberos V5 mechanism,
Mechanism OID within the exportable name shall be that of
Kerberos V5 mechanism. The name component within the exportable
shall be a contiguous string with structure as defined for
Kerberos Principal Name Form

In order to achieve a distinguished encoding for comparison purposes
the following additional constraints are imposed on the
operation

(1) all occurrences of the characters `@`, `/`, and `\`
principal components or realm names shall be quoted with
immediately-preceding `\`.

(2) all occurrences of the null, backspace, tab, or
characters within principal components or realm names will
represented, respectively, with `\0`, `\b`, `\t`, or `\n`.

(3) the `\` quoting character shall not be emitted within
exported name except to accomodate cases (1) and (2).

2.2. Optional Name

This section discusses additional name forms which may optionally
supported by implementations of the Kerberos V5 GSS-API mechanism
It is recognized that some of the name forms cited here are
from UNIX(tm) operating system platforms; some listed forms may
irrelevant to non-UNIX platforms, and definition of additional
corresponding to such platforms may also be appropriate. It is
recognized that OS-specific functions outside GSS-API are likely
exist in order to perform translations among these forms, and
GSS-API implementations supporting these forms may themselves
layered atop such OS-specific functions. Inclusion of this
within GSS-API implementations is intended as a convenience
applications

2.2.1. User Name

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
type is "GSS_KRB5_NT_USER_NAME".

This name type is used to indicate a named user on a local system

Linn Standards Track [Page 15]

RFC 1964 Kerberos Version 5 GSS-API June 1996

Its interpretation is OS-specific. This name form is constructed as

Assuming that users' principal names are the same as their
operating system names, an implementation of GSS_Import_name()
on Kerberos V5 technology can process names of this form
postfixing an "@" sign and the name of the local realm

2.2.2. Machine UID

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
this type is "GSS_KRB5_NT_MACHINE_UID_NAME".

This name type is used to indicate a numeric user
corresponding to a user on a local system. Its interpretation
OS-specific. The gss_buffer_desc representing a name of this
should contain a locally-significant uid_t, represented in host
order. The GSS_Import_name() operation resolves this uid into
username, which is then treated as the User Name Form

2.2.3. String UID

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
this type is "GSS_KRB5_NT_STRING_UID_NAME".

This name type is used to indicate a string of digits
the numeric user identifier of a user on a local system.
interpretation is OS-specific. This name type is similar to
Machine UID Form, except that the buffer contains a
representing the uid_t

3. Credentials

The Kerberos V5 protocol uses different credentials (in the
sense) for initiating and accepting security contexts.
clients receive a ticket-granting ticket (TGT) and an
session key at "login" time; the pair of a TGT and its
session key forms a credential which is suitable for
security contexts. A ticket-granting ticket, its session key,
any other (ticket, key) pairs obtained through use of the ticket
granting-ticket, are typically stored in a Kerberos V5
cache, sometimes known as a ticket file

Linn Standards Track [Page 16]

RFC 1964 Kerberos Version 5 GSS-API June 1996

The encryption key used by the Kerberos server to seal tickets for
particular application service forms the credentials suitable
accepting security contexts. These service keys are typically
in a Kerberos V5 key table, or srvtab file. In addition to their
as accepting credentials, these service keys may also be used
obtain initiating credentials for their service principal

The Kerberos V5 mechanism's credential handle may contain
to either or both types of credentials. It is a local matter how
Kerberos V5 mechanism implementation finds the appropriate
V5 credentials cache or key table

However, when the Kerberos V5 mechanism attempts to obtain
credentials for a service principal which are not available in
credentials cache, and the key for that service principal
available in a Kerberos V5 key table, the mechanism should use
service key to obtain initiating credentials for that service.
should be accomplished by requesting a ticket-granting-ticket
the Kerberos Key Distribution Center (KDC), and decrypting the KDC'
reply using the service key

4. Parameter

This section defines parameter values used by the Kerberos V5 GSS-
mechanism. It defines interface elements in support of portability
and assumes use of C language bindings per RFC-1509.

4.1. Minor Status

This section recommends common symbolic names for minor_status
to be returned by the Kerberos V5 GSS-API mechanism. Use of
definitions will enable independent implementors to
application portability across different implementations of
mechanism defined in this specification. (In all cases
implementations of GSS_Display_status() will enable callers
convert minor_status indicators to text representations.)
implementation should make available, through include files or
means, a facility to translate these symbolic names into the
values which a particular GSS-API implementation uses to
the minor_status values specified in this section

It is recognized that this list may grow over time, and that the
for additional minor_status codes specific to
implementations may arise. It is recommended, however,
implementations should return a minor_status value as defined on
mechanism-wide basis within this section when that code is
representative of reportable status rather than using a separate
implementation-defined code

Linn Standards Track [Page 17]

RFC 1964 Kerberos Version 5 GSS-API June 1996

4.1.1. Non-Kerberos-specific

GSS_KRB5_S_G_BAD_SERVICE_
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_
/* "Couldn't allocate gss_buffer_t data" */
GSS_KRB5_S_G_BAD_MSG_
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_
/* "Unknown quality of protection specified" */

4.1.2. Kerberos-specific-

GSS_KRB5_S_KG_CCACHE_
/* "Principal in credential cache does not match desired name" */
GSS_KRB5_S_KG_KEYTAB_
/* "No principal in keytab matches desired name" */
GSS_KRB5_S_KG_TGT_
/* "Credential cache has no TGT" */
GSS_KRB5_S_KG_NO_
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_
/* "Attempt to use incomplete security context" */

4.2. Quality of Protection

This section defines Quality of Protection (QOP) values to be
with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap()
GSS_GetMIC() routines in order to select among alternate
and confidentiality algorithms. Additional QOP values may be added
future versions of this specification. Non-overlapping bit
are and will be employed in order that both integrity

Linn Standards Track [Page 18]

RFC 1964 Kerberos Version 5 GSS-API June 1996

confidentiality QOP may be selected within a single parameter,
inclusive-OR of the specified integrity and confidentiality values

4.2.1. Integrity

The following Quality of Protection (QOP) values are
defined for the Kerberos V5 GSS-API mechanism, and are used to
among alternate integrity checking algorithms

GSS_KRB5_INTEG_C_QOP_MD5 (numeric value: 1)
/* Integrity using partial MD5 ("MD2.5") of plaintext */

GSS_KRB5_INTEG_C_QOP_DES_MD5 (numeric value: 2)
/* Integrity using DES MAC of MD5 of plaintext */

GSS_KRB5_INTEG_C_QOP_DES_MAC (numeric value: 3)
/* Integrity using DES MAC of plaintext */

4.2.2. Confidentiality

Only one confidentiality QOP value is currently defined for
Kerberos V5 GSS-API mechanism

GSS_KRB5_CONF_C_QOP_DES (numeric value: 0)
/* Confidentiality with DES */

Note: confidentiality QOP should be indicated only by GSS-API
capable of providing confidentiality services. If non-
confidentiality QOP values are defined in future to
different algorithms, therefore, the bit positions containing
values should be cleared before being returned by implementations
GSS_GetMIC() and GSS_VerifyMIC().

4.3. Buffer

All implementations of this specification shall be capable
accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(),
GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of
the output_token generated by GSS_Wrap() for a 16 Kbyte input
as input to GSS_Unwrap(). Support for larger buffer sizes is
but recommended

Linn Standards Track [Page 19]

RFC 1964 Kerberos Version 5 GSS-API June 1996

5. Security

Security issues are discussed throughout this memo

6.

[RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm",
1321, April 1992.

[RFC-1508]: Linn, J., "Generic Security Service Application
Interface", RFC 1508, September 1993.

[RFC-1509]: Wray, J., "Generic Security Service Application
Interface: C-bindings", RFC 1509, September 1993.

[RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos
Authentication Service (V5)", RFC 1510, September 1993.

[FIPS-PUB-113]: National Bureau of Standards, Federal
Processing Standard 113, "Computer Data Authentication", May 1985.

AUTHOR'S

John
OpenVision
One Main St
Cambridge, MA 02142

Phone: +1 617.374.2245
EMail: John.Linn@ov.

Linn Standards Track [Page 20]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX