draft-ietf-cat-krb5gss-mech2-02.txt   draft-ietf-cat-krb5gss-mech2-03.txt 
Internet-Draft Tom Yu INTERNET-DRAFT Tom Yu
Common Authentication Technology WG MIT Common Authentication Technology WG MIT
The Kerberos Version 5 GSSAPI Mechanism, Version 2 The Kerberos Version 5 GSSAPI Mechanism, Version 2
STATUS OF THIS MEMO Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, and all provisions of Section 10 of RFC2026.
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. 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 are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), The list of Internet-Draft Shadow Directories can be accessed at
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Comments on this document should be sent to Comments on this document should be sent to
"ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication
Technology WG discussion list. Technology WG discussion list.
ABSTRACT Abstract
This specification defines protocols, procedures, and conventions to be This document defines protocols, procedures, and conventions to be
employed by peers implementing the Generic Security Service Application employed by peers implementing the Generic Security Service
Program Interface (as specified in RFC 2078) when using Kerberos Application Program Interface (as specified in RFC 2743) when using
Version 5 technology (as specified in RFC 1510). This obsoletes Kerberos Version 5 technology (as specified in RFC 1510). This
RFC 1964. obsoletes RFC 1964.
ACKNOWLEDGEMENTS Acknowledgements
Much of the material in this specification is based on work done for Much of the material in this specification is based on work done for
Cygnus Solutions by Marc Horowitz. Cygnus Solutions by Marc Horowitz.
Table of Contents
Status of This Memo ............................................ 1
Abstract ....................................................... 1
Acknowledgements ............................................... 1
Table of Contents .............................................. 1
1. Introduction ............................................... 3
2. Token Formats .............................................. 3
2.1. Packet Notation ....................................... 3
2.2. Mechanism OID ......................................... 4
2.3. Context Establishment ................................. 4
2.3.1. Option Format .................................... 4
2.3.1.1. Delegated Credentials Option ................ 5
2.3.1.2. Null Option ................................. 5
2.3.2. Initial Token .................................... 6
2.3.2.1. Data to be Checksummed in APREQ ............. 8
2.3.3. Response Token ................................... 10
2.4. Per-message Tokens .................................... 12
2.4.1. Sequence Number Usage ............................ 12
2.4.2. MIC Token ........................................ 12
2.4.2.1. Data to be Checksummed in MIC Token ......... 13
2.4.3. Wrap Token ....................................... 14
2.4.3.1. Wrap Token With Integrity Only .............. 14
2.4.3.2. Wrap Token With Integrity and Encryption
............................................. 15
2.4.3.2.1. Data to be Encrypted in Wrap Token ..... 16
3. ASN.1 Encoding of Octet Strings ............................ 17
4. Name Types ................................................. 18
4.1. Mandatory Name Forms .................................. 18
4.1.1. Kerberos Principal Name Form ..................... 18
4.1.2. Exported Name Object Form for Kerberos5
Mechanism ........................................ 19
5. Credentials ................................................ 20
6. Parameter Definitions ...................................... 20
6.1. Minor Status Codes .................................... 20
6.1.1. Non-Kerberos-specific codes ...................... 21
6.1.2. Kerberos-specific-codes .......................... 21
7. Kerberos Protocol Dependencies ............................. 22
8. Security Considerations .................................... 22
9. References ................................................. 22
10. Author's Address .......................................... 23
1. Introduction 1. Introduction
The previous GSSAPI Kerberos V5 mechanism, described in RFC 1964, has The original Kerberos 5 GSSAPI mechanism[RFC1964] has a number of
several flaws which make integrating new encryption types (enctypes) shortcomings. This document attempts to remedy them by defining a
more difficult. The context establishment token format requires that completely new Kerberos 5 GSSAPI mechanism.
the authenticator of AP-REQ messages contain a cleartext data structure
The context establishment token format requires that the
authenticator of AP-REQ messages contain a cleartext data structure
in its checksum field, which is a needless and potentially confusing in its checksum field, which is a needless and potentially confusing
overloading of that field. The number assignments for checksum overloading of that field. This is implemented by a special checksum
algorithms are also inconsistent between the Kerberos protocol and the algorithm whose purpose is to copy the input data directly into the
GSSAPI mechanism. The previous mechanism also assumes that both checksum field of the authenticator.
checksums and cryptosystem blocksizes are eight bytes. There are no
backward-compatible ways to remedy these shortcomings.
Defining all GSSAPI tokens for the new Kerberos V5 mechanism in terms of The number assignments for checksum algorithms and for encryption
the Kerberos protocol specification ensures that new encryption types types are inconsistent between the Kerberos protocol and the original
and checksum types may be automatically used as they are defined for the GSSAPI mechanism. If new encryption or checksum algorithms are added
Kerberos protocol. to the Kerberos protocol at some point, the GSSAPI mechanism will
need to be separately updated to use these new algorithms.
The original mechanism specifies a crude method of key derivation (by
using the XOR of the context key with a fixed constant), which is
incompatible with newer cryptosystems which specify key derivation
procedures themselves. The original mechanism also assumes that both
checksums and cryptosystem blocksizes are eight bytes.
Defining all GSSAPI tokens for the new Kerberos 5 mechanism in terms
of the Kerberos protocol specification ensures that new encryption
types and checksum types may be automatically used as they are
defined for the Kerberos protocol.
2. Token Formats 2. Token Formats
All tokens, not just the initial token, are framed as the All tokens, not just the initial token, are framed as the
InitialContextToken described in RFC 2078 section 3.1. The InitialContextToken described in RFC 2743 section 3.1. The
innerContextToken element of the token will not itself be encoded in innerContextToken element of the token will not itself be encoded in
ASN.1, with the exception of caller-provided application data. The ASN.1, with the exception of caller-provided application data.
rationale for avoiding the use of ASN.1 in the inner token is that some
implementors may wish to implement this mechanism in a kernel or other
similarly constrained application where full ASN.1 encoding may be
cumbersome. Also, ASN.1 encoders and decoders are very difficult to
implement completely correctly, so keeping ASN.1 usage to a minimum
decreases the probability of bugs in the implementation of the
mechanism.
All integer fields are in network byte order. All other fields have the One rationale for avoiding the use of ASN.1 in the inner token is
fixed size shown. that some implementors may wish to implement this mechanism in a
kernel or other similarly constrained application where handling of
full ASN.1 encoding may be cumbersome. Also, due to the poor
availability of the relevant standards documents, ASN.1 encoders and
decoders are difficult to implement completely correctly, so keeping
ASN.1 usage to a minimum decreases the probability of bugs in the
implementation of the mechanism. In particular, bit strings need to
be transferred at certain points in this mechanism. There are many
conflicting common misunderstandings of how to encode and decode
ASN.1 bit strings, which have led difficulties in the implementaion
of the Kerberos protocol.
2.1. Packet Notation 2.1. Packet Notation
The order of transmission of this protocol is described at the octet The order of transmission of this protocol is described at the octet
level. Packet diagrams depict bits in the order of transmission, level. Packet diagrams depict bits in the order of transmission,
assuming that individual octets are transmitted with the most assuming that individual octets are transmitted with the most
significant bit (MSB) first. The diagrams read from left to right and significant bit (MSB) first. The diagrams read from left to right
from top to bottom, as in printed English. In each octet, bit number 7 and from top to bottom, as in printed English. In each octet, bit
is the MSB and bit number 0 is the LSB. Right hand sides of rows may be number 7 is the MSB and bit number 0 is the LSB.
filled with the upper-case letter "X" to denote the absence of
additional bytes in the row; this padding is for visual purposes only. Numbers prefixed by the characters "0x" are in hexadecimal notation,
Numbers prefixed by the string "0x" are in hexadecimal notation, as in as in the C programming language. Even though packet diagrams are
the C programming language. No padding should be used to force drawn 16 bits wide, no padding should be used to align the ends of
alignment of variable-length fields to a 32-bit boundary. variable-length fields to a 32-bit or 16-bit boundary.
All integer fields are in network byte order. All other fields have
the size shown in the diagrams, with the exception of variable length
fields.
2.2. Mechanism OID 2.2. Mechanism OID
The Object Identifier (OID) of the new krb5 v2 mechanism is: The Object Identifier (OID) of the new krb5 v2 mechanism is:
{iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) {iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
krb5v2(3)} krb5v2(3)}
2.3. Context Establishment 2.3. Context Establishment
2.3.1. Option Format 2.3.1. Option Format
Context establishment tokens, i.e., the initial ones that the Context establishment tokens, i.e., the initial ones that the
GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit while GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit
a security context is being set up, may contain options that influence while a security context is being set up, may contain options that
the subsequent behavior of the context. This document describes only a influence the subsequent behavior of the context. This document
small set of options, but additional types may be added by documents describes only a small set of options, but additional types may be
intended to supplement this one. The generic format is as follows: added by documents intended to supplement this one. The generic
format is as follows:
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | option type |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | option type |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 | option length | 2 | |
+---------------+---------------+---------------+---------------+ +-- option length (32 bits) --+
| . | 4 | |
4 / option data / +-------------------------------+-------------------------------+
6 | . |
/ option data (variable length) /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
option type (16 bits) option type (16 bits)
The type identifier of the following option. The type identifier of the following option.
option length (32 bits) option length (32 bits)
The length in bytes of the following option. The length in bytes of the following option.
option data (variable length) option data (variable length)
The actual option data. The actual option data.
Any number of options may appear in an initator or acceptor token. The Any number of options may appear in an initator or acceptor token.
final option in a token must be the null option, in order to mark the The final option in a token must be the null option, in order to mark
end of the list. Option type 0xffff is reserved. the end of the list. Option type 0xffff is reserved.
The initiator and acceptor shall ignore any options that they do not The initiator and acceptor shall ignore any options that they do not
understand. understand.
2.3.1.1. Delegated Credentials Option 2.3.1.1. Delegated Credentials Option
Only the initiator may use this option. The format of the delegated Only the initiator may use this option. The format of the delegated
credentials option is as follows: credentials option is as follows:
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | option type = 0x0001 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | option type = 0x00001 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 | KRB-CRED length | 2 | |
+---------------+---------------+---------------+---------------+ +-- KRB-CRED length --+
| . | 4 | |
4 / KRB-CRED message / +-------------------------------+-------------------------------+
6 | . |
/ KRB-CRED message /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
option type (16 bits) option type (16 bits)
The option type for this option shall be 0x0001. The option type for this option shall be 0x0001.
KRB-CRED length (32 bits) KRB-CRED length (32 bits)
The length in bytes of the following KRB-CRED message. The length in bytes of the following KRB-CRED message.
KRB-CRED message (variable length) KRB-CRED message (variable length)
The option data for this option shall be the KRB-CRED message that The option data for this option shall be the KRB-CRED message
contains the credentials being delegated (forwarded) to the context that contains the credentials being delegated (forwarded) to the
acceptor. Only the initiator may use this option. context acceptor. Only the initiator may use this option.
2.3.1.2. Null Option 2.3.1.2. Null Option
The Null option terminates the option list, and must be used by both the The Null option terminates the option list, and must be used by both
initiator and the acceptor. Its format is as follows: the initiator and the acceptor. Its format is as follows:
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | option type = 0 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | option type = 0 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 | length = 0 | 2 | |
+---------------+---------------+---------------+---------------+ +-- length = 0 --+
4 | |
+-------------------------------+-------------------------------+
option type (16 bits) option type (16 bits)
The option type of this option must be zero. The option type of this option must be zero.
option length (32 bits) option length (32 bits)
The length of this option must be zero. The length of this option must be zero.
2.3.2. Initial Token 2.3.2. Initial Token
This is the initial token sent by the context initiator, generated by This is the initial token sent by the context initiator, generated by
GSS_Init_sec_context(). GSS_Init_sec_context().
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | initial token id (0x0101) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | initial token id = 0x0101 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 | reserved flag bits |I|C|S|R|M|D| 2 | |
+---------------+---------------+---------------+---------------+ +-- reserved flag bits +-----------------------+
6 | checksum type count |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 4 | | I | C | S | R | M | D |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
| . | 6 | checksum type count |
8 / checksum type list / +-------------------------------+-------------------------------+
| . | 8 | . |
+---------------+---------------+---------------+---------------+ / checksum type list /
| . |
n / options /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
m | AP-REQ length | n | . |
+---------------+---------------+---------------+---------------+ / options /
| . | | . |
m+4 / AP-REQ data / +-------------------------------+-------------------------------+
m | |
+-- AP-REQ length --+
m+2 | |
+-------------------------------+-------------------------------+
m+4 | . |
/ AP-REQ data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
initial token ID (16 bits) initial token ID (16 bits)
Contains the integer 0x0101, which identifies this as the initial Contains the integer 0x0101, which identifies this as the
token in the context setup. initial token in the context setup.
reserved flag bits (26 bits) reserved flag bits (26 bits)
These bits are reserved for future expansion. They must be set to These bits are reserved for future expansion. They must be set
zero by the initiator and be ignored by the acceptor. to zero by the initiator and be ignored by the acceptor.
I flag (1 bit) I flag (1 bit)
0x00000020 -- GSS_C_INTEG_FLAG 0x00000020 -- GSS_C_INTEG_FLAG
C flag (1 bit) C flag (1 bit)
0x00000010 -- GSS_C_CONF_FLAG 0x00000010 -- GSS_C_CONF_FLAG
S flag (1 bit) S flag (1 bit)
0x00000008 -- GSS_C_SEQUENCE_FLAG 0x00000008 -- GSS_C_SEQUENCE_FLAG
skipping to change at page 5, line 33 skipping to change at page 7, line 33
D flag (1 bit) D flag (1 bit)
0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the 0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the
"delegated credentials" option is included. "delegated credentials" option is included.
checksum type count (16 bits) checksum type count (16 bits)
The number of checksum types supported by the initiator. The number of checksum types supported by the initiator.
checksum type list (variable length) checksum type list (variable length)
A list of Kerberos checksum types, as defined in RFC 1510 A list of Kerberos checksum types, as defined in RFC 1510
section 6.4. These checksum types must be collision-proof and keyed section 6.4. These checksum types must be collision-proof and
with the context key; no checksum types that are incompatible with keyed with the context key; no checksum types that are
the encryption key shall be used. Each checksum type number shall incompatible with the encryption key shall be used. Each
be 32 bits wide. This list should contain all the checksum types checksum type number shall be 32 bits wide. This list should
supported by the initiator. If mutual authentication is not used, contain all the checksum types supported by the initiator. If
then this list shall contain only one checksum type. mutual authentication is not used, then this list shall contain
only one checksum type.
options (variable length) options (variable length)
The context initiation options, described in section 2.3.1. The context initiation options, described in section 2.3.1.
AP-REQ length (32 bits) AP-REQ length (32 bits)
The length of the following KRB_AP_REQ message. The length of the following KRB_AP_REQ message.
AP-REQ data (variable length) AP-REQ data (variable length)
The AP-REQ message as described in RFC 1510. The checksum in the The AP-REQ message as described in RFC 1510. The checksum in
authenticator will be computed over the items listed in the next the authenticator will be computed over the items listed in the
section. next section.
The optional sequence number field shall be used in the AP-REQ. The The optional sequence number field shall be used in the AP-REQ. The
initiator should generate a subkey in the authenticator, and the initiator should generate a subkey in the authenticator, and the
acceptor should generate a subkey in the AP-REP. The key used for the acceptor should generate a subkey in the AP-REP. The key used for
per-message tokens will be the AP-REP subkey, or if that is not present, the per-message tokens will be the AP-REP subkey, or if that is not
the authenticator subkey, or if that is not present, the session key. present, the authenticator subkey, or if that is not present, the
When subkeys are generated, it is strongly recommended that they be of session key. When subkeys are generated, it is strongly recommended
the same type as the associated session key. that they be of the same type as the associated session key.
XXX The above is not secure. There should be an algorithmic process to XXX The above is not secure. There should be an algorithmic process
arrive at a subsession key which both sides of the authentication to arrive at a subsession key which both sides of the authentication
exchange can perform based on the ticket sessions key and data known to exchange can perform based on the ticket sessions key and data known
both parties, and this should probably be part of the revised Kerberos to both parties, and this should probably be part of the revised
protocol rather than bound to the GSSAPI mechanism. Kerberos protocol rather than bound to the GSSAPI mechanism.
2.3.2.1. Data to be Checksummed in AP-REQ 2.3.2.1. Data to be Checksummed in AP-REQ
The checksum in the AP-REQ message is calculated over the following The checksum in the AP-REQ message is calculated over the following
items. Like in the actual tokens, no padding should be added to force items. Like in the actual tokens, no padding should be added to
integer fields to align on 32 bit boundaries. This particular set of force integer fields to align on 32 bit boundaries. This particular
data should not be sent as a part of any token; it merely specifies what set of data should not be sent as a part of any token; it merely
is to be checksummed in the AP-REQ. The items in this encoding that specifies what is to be checksummed in the AP-REQ. The items in this
precede the initial token ID correspond to the channel bindings passed encoding that precede the initial token ID correspond to the channel
to GSS_Init_sec_context(). bindings passed to GSS_Init_sec_context().
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+---------------+---------------+ byte +-------------------------------+-------------------------------+
0 | initiator address type | 0 | |
+---------------+---------------+---------------+---------------+ +-- initiator address type --+
4 | initator address length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 2 | |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
6 | initiator address | 4 | initiator address length |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
n | acceptor address type | 6 | . |
+---------------+---------------+---------------+---------------+ / initiator address /
n+4 | acceptor address length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+---------------+---------------+---------------+---------------+
n+6 | acceptor address |
+---------------+---------------+---------------+---------------+
| . |
m / application data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
k | initial token id (0x0101) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX n | |
+---------------+---------------+---------------+---------------+ +-- acceptor address type --+
k+2 | flags | | |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
k+6 | checksum type count |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX n+4 | acceptor address length |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
n+6 | . |
/ acceptor address /
| . | | . |
k+8 / checksum type list / +-------------------------------+-------------------------------+
m | . |
/ application data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
k | initial token id = 0x0101 |
+-------------------------------+-------------------------------+
k+2 | |
+-- flags --+
k+4 | |
+-------------------------------+-------------------------------+
k+6 | checksum type count |
+-------------------------------+-------------------------------+
k+8 | . |
/ checksum type list /
| . | | . |
j / options / +-------------------------------+-------------------------------+
j | . |
/ options /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
initiator address type (32 bits) initiator address type (32 bits)
The initiator address type, as defined in the Kerberos protocol The initiator address type, as defined in the Kerberos protocol
specification. If no initiator address is provided, this must be specification. If no initiator address is provided, this must
zero. be zero.
initiator address length (16 bits) initiator address length (16 bits)
The length in bytes of the following initiator address. If there The length in bytes of the following initiator address. If
is no inititator address provided, this must be zero. there is no inititator address provided, this must be zero.
initiator address (variable length) initiator address (variable length)
The actual initiator address, in network byte order. The actual initiator address, in network byte order.
acceptor address type (32 bits) acceptor address type (32 bits)
The acceptor address type, as defined in the Kerberos protocol The acceptor address type, as defined in the Kerberos protocol
specification. If no acceptor address is provided, this must be specification. If no acceptor address is provided, this must be
zero. zero.
acceptor address length (16 bits) acceptor address length (16 bits)
The length in bytes of the following acceptor address. This must The length in bytes of the following acceptor address. This
be zero is there is no acceptor address provided. must be zero is there is no acceptor address provided.
initiator address (variable length) initiator address (variable length)
The actual acceptor address, in network byte order. The actual acceptor address, in network byte order.
applicatation data (variable length) applicatation data (variable length)
The application data, if provided, encoded as a ASN.1 octet string The application data, if provided, encoded as a ASN.1 octet
using DER. If no application data are passed as input channel string using DER. If no application data are passed as input
bindings, this shall be a zero-length ASN.1 octet string. channel bindings, this shall be a zero-length ASN.1 octet
string.
initial token ID (16 bits) initial token ID (16 bits)
The initial token ID from the initial token. The initial token ID from the initial token.
flags (32 bits) flags (32 bits)
The context establishment flags from the initial token. The context establishment flags from the initial token.
checksum type count (16 bits) checksum type count (16 bits)
The number of checksum types supported by the initiator. The number of checksum types supported by the initiator.
skipping to change at page 8, line 5 skipping to change at page 11, line 5
The same list of checksum types contained in the initial token. The same list of checksum types contained in the initial token.
options (variable length) options (variable length)
The options list from the initial token. The options list from the initial token.
2.3.3. Response Token 2.3.3. Response Token
This is the reponse token sent by the context acceptor, if mutual This is the reponse token sent by the context acceptor, if mutual
authentication is enabled. authentication is enabled.
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | response token id (0x0202) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | response token id = 0x0202 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 | reserved flag bits |D|E| 2 | |
+---------------+---------------+---------------+---------------+ +-- reserved flag bits +-------+
6 | checksum type | 4 | | D | E |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
| . | 6 | |
14 / options / +-- checksum type --+
| . | 8 | |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
n | AP-REP or KRB-ERROR length | 10 | . |
+---------------+---------------+---------------+---------------+ / options /
| . |
n+4 / AP-REP or KRB-ERROR data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
n | |
+-- AP-REP or KRB-ERROR length --+
n+2 | |
+-------------------------------+-------------------------------+
n+4 | . |
/ AP-REP or KRB-ERROR data /
| . | | . |
m / MIC data / +-------------------------------+-------------------------------+
m | . |
/ MIC data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
response token id (16 bits) response token id (16 bits)
Contains the integer 0x0202, which identifies this as the response Contains the integer 0x0202, which identifies this as the
token in the context setup. response token in the context setup.
reserved flag bits (30 bits) reserved flag bits (30 bits)
These bits are reserved for future expansion. They must be set to These bits are reserved for future expansion. They must be set
zero by the acceptor and be ignored by the initiator. to zero by the acceptor and be ignored by the initiator.
D flag -- delegated creds accepted (1 bit) D flag -- delegated creds accepted (1 bit)
0x00000002 -- If this flag is set, the acceptor processed the 0x00000002 -- If this flag is set, the acceptor processed the
delegated credentials, and GSS_C_DELEG_FLAG should be returned to delegated credentials, and GSS_C_DELEG_FLAG should be returned
the caller. to the caller.
E flag -- error (1 bit) E flag -- error (1 bit)
0x00000001 -- If this flag is set, a KRB-ERROR message shall be 0x00000001 -- If this flag is set, a KRB-ERROR message shall be
present, rather than an AP-REP message. If this flag is not set, present, rather than an AP-REP message. If this flag is not
an AP-REP message shall be present. set, an AP-REP message shall be present.
checksum type count (16 bits) checksum type count (16 bits)
The number of checksum types supported by both the initiator and The number of checksum types supported by both the initiator and
the acceptor. the acceptor.
checksum type (32 bits) checksum type (32 bits)
A Kerberos checksum type, as defined in RFC 1510 section 6.4. This A Kerberos checksum type, as defined in RFC 1510 section 6.4.
checksum type must be among the types listed by the initiator, and This checksum type must be among the types listed by the
will be used in for subsequent checksums generated during this initiator, and will be used in for subsequent checksums
security context. generated during this security context.
options (variable length) options (variable length)
The option list, as described earlier. At this time, no options The option list, as described earlier. At this time, no options
are defined for the acceptor, but an implementation might make use are defined for the acceptor, but an implementation might make
of these options to acknowledge an option from the initial token. use of these options to acknowledge an option from the initial
After all the options are specified, a null option must be used to token. After all the options are specified, a null option must
terminate the list. be used to terminate the list.
AP-REP or KRB-ERROR length (32 bits) AP-REP or KRB-ERROR length (32 bits)
Depending on the value of the error flag, length in bytes of the Depending on the value of the error flag, length in bytes of the
AP-REP or KRB-ERROR message. AP-REP or KRB-ERROR message.
AP-REP or KRB-ERROR data (variable length) AP-REP or KRB-ERROR data (variable length)
Depending on the value of the error flag, the AP-REP or KRB-ERROR Depending on the value of the error flag, the AP-REP or
message as described in RFC 1510. If this field contains an AP-REP KRB-ERROR message as described in RFC 1510. If this field
message, the sequence number field in the AP-REP shall be filled. contains an AP-REP message, the sequence number field in the
If this is a KRB-ERROR message, no further fields will be in this AP-REP shall be filled. If this is a KRB-ERROR message, no
message. further fields will be in this message.
MIC data (variable length) MIC data (variable length)
A MIC token, as described in section 2.4.2, computed over the A MIC token, as described in section 2.4.2, computed over the
concatentation of the response token ID, flags, checksum length and concatentation of the response token ID, flags, checksum length
type fields, and all option fields. This field and the preceding and type fields, and all option fields. This field and the
length field must not be present if the error flag is set. preceding length field must not be present if the error flag is
set.
2.4. Per-message Tokens 2.4. Per-message Tokens
2.4.1. Sequence Number Usage 2.4.1. Sequence Number Usage
Sequence numbers for per-message tokens are 31 bit unsigned integers, Sequence numbers for per-message tokens are 31 bit unsigned integers,
which are incremented by 1 after each token. An overflow condition which are incremented by 1 after each token. An overflow condition
should result in a wraparound of the sequence number to zero. The should result in a wraparound of the sequence number to zero. The
initiator and acceptor each keep their own sequence numbers per initiator and acceptor each keep their own sequence numbers per
connection. connection.
The intial sequence number for tokens sent from the initiator to the The intial sequence number for tokens sent from the initiator to the
acceptor shall be the least significant 31 bits of sequence number in acceptor shall be the least significant 31 bits of sequence number in
the AP-REQ message. The initial sequence number for tokens sent from the AP-REQ message. The initial sequence number for tokens sent from
the acceptor to the initiator shall be the least significant 31 bits of the acceptor to the initiator shall be the least significant 31 bits
the sequence number in the AP-REP message if mutual authentication is of the sequence number in the AP-REP message if mutual authentication
used; if mutual authentication is not used, the initial sequence number is used; if mutual authentication is not used, the initial sequence
from acceptor to initiator shall be the least significant 31 bits of the number from acceptor to initiator shall be the least significant 31
sequence number in the AP-REQ message. bits of the sequence number in the AP-REQ message.
2.4.2. MIC Token 2.4.2. MIC Token
Use of the GSS_GetMIC() call yields a token, separate from the user data Use of the GSS_GetMIC() call yields a token, separate from the user
being protected, which can be used to verify the integrity of that data data being protected, which can be used to verify the integrity of
when it is received. The MIC token has the following format: that data when it is received. The MIC token has the following
format:
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | MIC token id (0x0303) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | MIC token id = 0x0303 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 |D| sequence number | 2 | D | |
+---------------+---------------+---------------+---------------+ +---+ sequence number --+
6 | checksum length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 4 | |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
| . | 6 | checksum length |
8 / checksum data / +-------------------------------+-------------------------------+
8 | . |
/ checksum data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
MIC token id (16 bits) MIC token id (16 bits)
Contains the integer 0x0303, which identifies this as a MIC token. Contains the integer 0x0303, which identifies this as a MIC
token.
D -- direction bit (1 bit) D -- direction bit (1 bit)
This bit shall be zero if the message is sent from the context This bit shall be zero if the message is sent from the context
initiator. If the message is sent from the context acceptor, this initiator. If the message is sent from the context acceptor,
bit shall be one. this bit shall be one.
sequence number (31 bits) sequence number (31 bits)
The sequence number. The sequence number.
checksum length (16 bits) checksum length (16 bits)
The number of bytes in the following checksum data field. The number of bytes in the following checksum data field.
checksum data (variable length) checksum data (variable length)
The checksum itself, as defined in RFC 1510 section 6.4. The The checksum itself, as defined in RFC 1510 section 6.4. The
checksum is calculated over the encoding described in the following checksum is calculated over the encoding described in the
section. The key usage GSS_TOK_MIC -- 22 [XXX need to register following section. The key usage GSS_TOK_MIC -- 22 [XXX need to
this] shall be used. register this] shall be used in cryptosystems that support key
derivation.
The mechanism implementation shall only use the checksum type returned The mechanism implementation shall only use the checksum type
by the acceptor in the case of mutual authentication. If mutual returned by the acceptor in the case of mutual authentication. If
authentication is not requested, then only the checksum type in the mutual authentication is not requested, then only the checksum type
initiator token shall be used. in the initiator token shall be used.
2.4.2.1. Data to be Checksummed in MIC Token 2.4.2.1. Data to be Checksummed in MIC Token
The checksum in the MIC token shall be calculated over the following The checksum in the MIC token shall be calculated over the following
elements. This set of data is not actually included in the token as is; elements. This set of data is not actually included in the token as
the description only appears for the purpose of specifying the method of is; the description only appears for the purpose of specifying the
calculating the checksum. method of calculating the checksum.
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 | MIC token id (0x0303) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | MIC token id = 0x0303 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
2 |D| sequence number | 2 | D | |
+---------------+---------------+---------------+---------------+ +---+ sequence number --+
| . | 4 | |
6 / application data / +-------------------------------+-------------------------------+
6 | . |
/ application data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
MIC token ID (16 bits) MIC token ID (16 bits)
The MIC token ID from the MIC message. The MIC token ID from the MIC message.
D -- direction bit (1 bit) D -- direction bit (1 bit)
This bit shall be zero if the message is sent from the context This bit shall be zero if the message is sent from the context
initiator. If the message is sent from the context acceptor, this initiator. If the message is sent from the context acceptor,
bit shall be one. this bit shall be one.
sequence number (31 bits) sequence number (31 bits)
The sequence number. The sequence number.
application data (variable length) application data (variable length)
The application-supplied data, encoded as an ASN.1 octet string The application-supplied data, encoded as an ASN.1 octet string
using DER. using DER.
2.4.3. Wrap Token 2.4.3. Wrap Token
Use of the GSS_Wrap() call yields a token which encapsulates the input Use of the GSS_Wrap() call yields a token which encapsulates the
user data (optionally encrypted) along with associated integrity check input user data (optionally encrypted) along with associated
quantities. integrity check quantities.
2.4.3.1. Wrap Token With Integrity Only 2.4.3.1. Wrap Token With Integrity Only
bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 byte +-------------------------------+-------------------------------+
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | integrity wrap token id = 0x0404 |
0 |integrity wrap token id(0x0404)|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +-------------------------------+-------------------------------+
+---------------+---------------+---------------+---------------+ 2 | D | |
2 |D| sequence number | +---+ sequence number --+
+---------------+---------------+---------------+---------------+ 4 | |
| . | +-------------------------------+-------------------------------+
6 / application data / 6 | . |
| . | / application data /
+---------------+---------------+---------------+---------------+
n | checksum length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+---------------+---------------+---------------+---------------+
| . | | . |
n+2 / checksum data / +-------------------------------+-------------------------------+
n | checksum length |
+-------------------------------+-------------------------------+
n+2 | . |
/ checksum data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
integrity wrap token id (16 bits) integrity wrap token id (16 bits)
Contains the integer 0x0404, which identifies this as a Wrap token Contains the integer 0x0404, which identifies this as a Wrap
with integrity only. token with integrity only.
D -- direction bit (1 bit) D -- direction bit (1 bit)
This bit shall be zero if the message is sent from the context This bit shall be zero if the message is sent from the context
initiator. If the message is sent from the context acceptor, this initiator. If the message is sent from the context acceptor,
bit shall be one. this bit shall be one.
sequence number (31 bits) sequence number (31 bits)
The sequence number. The sequence number.
application data (variable length) application data (variable length)
The application-supplied data, encoded as an ASN.1 octet string The application-supplied data, encoded as an ASN.1 octet string
using DER. using DER.
checksum length (16 bits) checksum length (16 bits)
The number of bytes in the following checksum data field. The number of bytes in the following checksum data field.
checksum data (variable length) checksum data (variable length)
The checksum itself, as defined in RFC 1510 section 6.4, computed The checksum itself, as defined in RFC 1510 section 6.4,
over the concatenation of the token ID, sequence number, direction computed over the concatenation of the token ID, sequence
field, application data length, and application data, as in the MIC number, direction field, application data length, and
token checksum in the previous section. The key usage application data, as in the MIC token checksum in the previous
GSS_TOK_WRAP_INTEG -- 23 [XXX need to register this] shall be used. section. The key usage GSS_TOK_WRAP_INTEG -- 23 [XXX need to
register this] shall be used in cryptosystems that support key
derivation.
The mechanism implementation should only use checksum types which it The mechanism implementation should only use checksum types which it
knows to be valid for both peers, as described for MIC tokens. knows to be valid for both peers, as described for MIC tokens.
2.4.3.2. Wrap Token With Integrity and Encryption 2.4.3.2. Wrap Token With Integrity and Encryption
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX byte +-------------------------------+-------------------------------+
0 |encrypted wrap token id(0x0505)|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | encrypted wrap token id = 0x0505 |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
| . | 2 | . |
2 / encrypted data / / encrypted data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
encrypted wrap token id (16 bits) encrypted wrap token id (16 bits)
Contains the integer 0x0505, which identifies this as a Wrap token Contains the integer 0x0505, which identifies this as a Wrap
with integrity and encryption. token with integrity and encryption.
encrypted data (variable length) encrypted data (variable length)
The encrypted data itself, as defined in RFC 1510 section 6.3, The encrypted data itself, as defined in RFC 1510 section 6.3,
encoded as an ASN.1 octet string using DER. Note that this is not encoded as an ASN.1 octet string using DER. Note that this is
the ASN.1 type EncryptedData as defined in RFC 1510 section 6.1, not the ASN.1 type EncryptedData as defined in RFC 1510
but rather the ciphertext without encryption type or kvno section 6.1, but rather the ciphertext without encryption type
information. The encryption is performed using the key/enctype or kvno information. The encryption is performed using the
exchanged during context setup. The confounder and checksum are as key/enctype exchanged during context setup. The confounder and
specified in the Kerberos protocol specification. The key usage checksum are as specified in the Kerberos protocol
GSS_TOK_WRAP_PRIV -- 24 [XXX need to register this] shall be used. specification. The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need
to register this] shall be used in cryptosystems that support
The actual data to be encrypted are specified below. key derivation. The actual data to be encrypted are specified
below.
2.4.3.2.1. Data to be Encrypted in Wrap Token 2.4.3.2.1. Data to be Encrypted in Wrap Token
bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
byte +---------------+---------------+---------------+---------------+ byte +-------------------------------+-------------------------------+
0 |D| sequence number | 0 | D | |
+---------------+---------------+---------------+---------------+ +---+ sequence number --+
| . | 2 | |
4 / application data / +-------------------------------+-------------------------------+
4 | . |
/ application data /
| . | | . |
+---------------+---------------+---------------+---------------+ +-------------------------------+-------------------------------+
D -- direction bit (1 bit) D -- direction bit (1 bit)
This bit shall be zero if the message is sent from the context This bit shall be zero if the message is sent from the context
initiator. If the message is sent from the context acceptor, this initiator. If the message is sent from the context acceptor,
bit shall be one. this bit shall be one.
sequence number (31 bits) sequence number (31 bits)
The sequence number. The sequence number.
application data (variable length) application data (variable length)
The application-supplied data, encoded as an ASN.1 octet string The application-supplied data, encoded as an ASN.1 octet string
using DER. using DER.
3. ASN.1 Encoding of Octet Strings 3. ASN.1 Encoding of Octet Strings
In order to encode arbitirarly-sized application data, ASN.1 octet In order to encode arbitirarly-sized application data, ASN.1 octet
string encoding is in this protocol. The Distinguished Encoding Rules string encoding is in this protocol. The Distinguished Encoding
(DER) shall always be used in such cases. For reference purposes, the Rules (DER) shall always be used in such cases. For reference
DER encoding of an ASN.1 octet string, adapted from ISO/IEC 8825-1, purposes, the DER encoding of an ASN.1 octet string, adapted from
follows: ITU-T X.690, follows:
+--------+-------//-------+-------//-------+ +--------+-------//-------+-------//-------+
|00000100| length octets |contents octets | |00000100| length octets |contents octets |
+--------+-------//-------+-------//-------+ +--------+-------//-------+-------//-------+
| |
+-- identifier octet = 0x04 = [UNIVERSAL 4] +-- identifier octet = 0x04 = [UNIVERSAL 4]
In this section only, the bits in each octet shall be numbered as in the In this section only, the bits in each octet shall be numbered as in
ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the octet, the ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the
and with bit 1 being the LSB of the octet. octet, and with bit 1 being the LSB of the octet.
identifier octet (8 bits) identifier octet (8 bits)
Contains the constant 0x04, the tag for primitive encoding of an Contains the constant 0x04, the tag for primitive encoding of an
octet string with the default (UNIVERSAL 4) tag. octet string with the default (UNIVERSAL 4) tag.
length octets (variable length) length octets (variable length)
Contains the length of the contents octets, in definite form (since Contains the length of the contents octets, in definite form
this encoding uses DER). (since this encoding uses DER).
contents octets (variable length) contents octets (variable length)
The contents of the octet string. The contents of the octet string.
The length octets shall consist of either a short form (one byte only), The length octets shall consist of either a short form (one byte
which is to be used only if the number of octets in the contents octets only), which is to be used only if the number of octets in the
is less than or equal to 127, or a long form, which is to be used in all contents octets is less than or equal to 127, or a long form, which
other cases. The short form shall consist of a single octet with bit 8 is to be used in all other cases. The short form shall consist of a
(the MSB) equal to zero, and the remaining bits encoding the number of single octet with bit 8 (the MSB) equal to zero, and the remaining
contents octets (which may be zero) as an unsigned binary integer. bits encoding the number of contents octets (which may be zero) as an
unsigned binary integer.
The long form shall consist of an initial octet and one or more The long form shall consist of an initial octet and one or more
subsequent octets. The first octet shall have bit 8 (the MSB) set to subsequent octets. The first octet shall have bit 8 (the MSB) set to
one, and the remaining bits shall encode the number of subsequent octets one, and the remaining bits shall encode the number of subsequent
in the length encoding as an unsigned binary integer. The length must octets in the length encoding as an unsigned binary integer. The
be encoded in the minimum number of octets. An initial octet of 0xFF is length must be encoded in the minimum number of octets. An initial
reserved by the ASN.1 specification. Bits 8 to 1 of the first octet of 0xFF is reserved by the ASN.1 specification. Bits 8 to 1 of
subsequent octet, followed by bits 8 to 1 of each subsequent octet in the first subsequent octet, followed by bits 8 to 1 of each
order, shall be the encoding of an unsigned binary integer, with bit 8 subsequent octet in order, shall be the encoding of an unsigned
of the first octet being the most significant bit. Thus, the length binary integer, with bit 8 of the first octet being the most
encoding within is in network byte order. significant bit. Thus, the length encoding within is in network byte
order.
An initial length octet of 0x80 shall not be used, as that is reserved An initial length octet of 0x80 shall not be used, as that is
by the ASN.1 specification for indefinite lengths in conjunction with reserved by the ASN.1 specification for indefinite lengths in
constructed contents encodings, which are not to be used with DER. conjunction with constructed contents encodings, which are not to be
used with DER.
4. Name Types 4. Name Types
The name types and forms for this mechanism will be basically identical This section discusses the name types which may be passed as input to
to those specified in RFC 1964. The actual text describing these will the Kerberos 5 GSSAPI mechanism's GSS_Import_name() call, and their
be included later. associated identifier values. It defines interface elements in
support of portability, and assumes use of C language bindings per
RFC 2744. In addition to specifying OID values for name type
identifiers, symbolic names are included and recommended to GSSAPI
implementors in the interests of convenience to callers. It is
understood that not all implementations of the Kerberos 5 GSSAPI
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 5 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.
5. Kerberos Protocol Dependencies For purposes of clarification to GSSAPI 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 5.
4.1. Mandatory Name Forms
This section discusses name forms which are to be supported by all
conformant implementations of the Kerberos 5 GSSAPI mechanism.
4.1.1. Kerberos Principal Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) us(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 corresponds to the single-string representation of a
Kerberos name. (Within the MIT Kerberos 5 implementation, such names
are parseable with the krb5_parse_name() function.) The 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 one
principal name component is included, the components are
separated by '/'. Arbitrary octets may be included within
principal name components, with the following constraints and
special considerations:
(1a) Any occurrence of the characters '@' or '/' within a
name component must be immediately preceded by the '\'
quoting character, to prevent interpretation as a component
or realm separator.
(1b) The ASCII newline, tab, backspace, and null characters
may occur directly within the component or may be
represented, respectively, by '\n', '\t', '\b', or '\0'.
(1c) If the '\' quoting character occurs outside the contexts
described in (1a) and (1b) above, the following character is
interpreted literally. As a special case, this allows the
doubled representation '\\' to represent a single occurrence
of the quoting character.
(1d) An occurrence of the '\' quoting character as the last
character of a component is illegal.
(2) Optionally, a '@' character, signifying that a realm name
immediately follows. If no realm name element is included, the
local realm name is assumed. The '/' , ':', and null characters
may not occur within a realm name; the '@', newline, tab, and
backspace characters may be included using the quoting
conventions described in (1a), (1b), and (1c) above.
4.1.2. Exported Name Object Form for Kerberos 5 Mechanism
When generated by the Kerberos 5 mechanism, the Mechanism OID within
the exportable name shall be that of the original Kerberos 5
mechanism[RFC1964]. The Mechanism OID for the original Kerberos 5
mechanism is:
{iso(1) member-body(2) us(840) mit(113554) infosys(1) gssapi(2)
krb5(2)}
The name component within the exportable name shall be a contiguous
string with structure as defined for the Kerberos Principal Name
Form.
In order to achieve a distinguished encoding for comparison purposes,
the following additional constraints are imposed on the export
operation:
(1) all occurrences of the characters '@', '/', and '\' within
principal components or realm names shall be quoted with an
immediately-preceding '\'.
(2) all occurrences of the null, backspace, tab, or newline
characters within principal components or realm names will be
represented, respectively, with '\0', '\b', '\t', or '\n'.
(3) the '\' quoting character shall not be emitted within an
exported name except to accomodate cases (1) and (2).
5. Credentials
The Kerberos 5 protocol uses different credentials (in the GSSAPI
sense) for initiating and accepting security contexts. Normal
clients receive a ticket-granting ticket (TGT) and an associated
session key at "login" time; the pair of a TGT and its corresponding
session key forms a credential which is suitable for initiating
security contexts. A ticket-granting ticket, its session key, and
any other (ticket, key) pairs obtained through use of the
ticket-granting-ticket, are typically stored in a Kerberos 5
credentials cache, sometimes known as a ticket file.
The encryption key used by the Kerberos server to seal tickets for a
particular application service forms the credentials suitable for
accepting security contexts. These service keys are typically stored
in a Kerberos 5 key table (keytab), or srvtab file (the Kerberos 4
terminology). In addition to their use as accepting credentials,
these service keys may also be used to obtain initiating credentials
for their service principal.
The Kerberos 5 mechanism's credential handle may contain references
to either or both types of credentials. It is a local matter how the
Kerberos 5 mechanism implementation finds the appropriate Kerberos 5
credentials cache or key table.
However, when the Kerberos 5 mechanism attempts to obtain initiating
credentials for a service principal which are not available in a
credentials cache, and the key for that service principal is
available in a Kerberos 5 key table, the mechanism should use the
service key to obtain initiating credentials for that service. This
should be accomplished by requesting a ticket-granting-ticket from
the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
reply using the service key.
6. Parameter Definitions
This section defines parameter values used by the Kerberos V5 GSSAPI
mechanism. It defines interface elements in support of portability,
and assumes use of C language bindings per RFC 2744.
6.1. Minor Status Codes
This section recommends common symbolic names for minor_status values
to be returned by the Kerberos 5 GSSAPI 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 GSSAPI 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. It is recommended, however, that
implementations should return a minor_status value as defined on a
mechanism-wide basis within this section when that code is accurately
representative of reportable status rather than using a separate,
implementation-defined code.
6.1.1. Non-Kerberos-specific codes
These symbols should likely be incorporated into the generic GSSAPI
C-bindings document, since they really are more general.
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" */
6.1.2. Kerberos-specific-codes
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" */
7. Kerberos Protocol Dependencies
This protocol makes several assumptions about the Kerberos protocol, This protocol makes several assumptions about the Kerberos protocol,
which may require changes to the successor of RFC 1510. which may require changes to the successor of RFC 1510.
Sequence numbers, checksum types, and address types are assumed to be no Sequence numbers, checksum types, and address types are assumed to be
wider than 32 bits. The Kerberos protocol specification might need to no wider than 32 bits. The Kerberos protocol specification might
be modified to accomodate this. This obviously requires some further need to be modified to accomodate this. This obviously requires some
discussion. further discussion.
Key usages need to be registered within the Kerberos protocol for use Key usages need to be registered within the Kerberos protocol for use
with GSSAPI per-message tokens. The current specification of the with GSSAPI per-message tokens. The current specification of the
Kerberos protocol does not include descriptions of key derivations or Kerberos protocol does not include descriptions of key derivations or
key usages, but planned revisions to the protocol will include them. key usages, but planned revisions to the protocol will include them.
This protocol also makes the assumption that any cryptosystem used with This protocol also makes the assumption that any cryptosystem used
the session key will include integrity protection, i.e., it assumes that with the session key will include integrity protection, i.e., it
no "raw" cryptosystems will be used. assumes that no "raw" cryptosystems will be used.
6. Security Considerations 8. Security Considerations
The GSSAPI is a security protocol; therefore, security considerations The GSSAPI is a security protocol; therefore, security considerations
are discussed throughout this document. The old Kerberos 5 GSSAPI are discussed throughout this document. The original Kerberos 5
GSSAPI mechanism's constraints on possible cryptosystems and checksum
mechanism's constraints on possible cryptosystems and checksum types do types do not permit it to be readily extended to accomodate more
not permit it to be readily extended to accomodate more secure secure cryptographic technologies with larger checksums or encryption
cryptographic technologies with larger checksums or encryption block block sizes. Sites are strongly encouraged to adopt the mechanism
sizes. Sites are strongly encouraged to adopt the mechanism specified specified in this document in the light of recent publicity about the
in this document in the light of recent publicity about the deficiencies deficiencies of DES.
of DES.
7. References
[ISOIEC8824-1:1995] ISO/IEC, "Information technology -- Abstract Syntax 9. References
Notation One (ASN.1): Specification of basic notation",
ISO/IEC 8824-1:1995.
[ISOIEC8825-1:1995] ISO/IEC, "Information technology -- ASN.1 encoding [X.680] ISO/IEC, "Information technology -- Abstract Syntax Notation
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding One (ASN.1): Specification of basic notation", ITU-T X.680 (1997) |
Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8824-1:1998
ISO/IEC 8825-1:1995. [X.690] ISO/IEC, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding Rules
(CER) and Distinguished Encoding Rules (DER)", ITU-T X.690 (1997) |
ISO/IEC 8825-1:1998.
[RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510. Service (V5)", RFC 1510.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964. RFC 1964.
[RFC2078] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078 Interface, Version 2, Update 1", RFC 2743.
[RFC2744] Wray, J., "Generic Security Service API Version 2:
C-bindings", RFC 2744.
10. Author's Address
8. Author's Address
Tom Yu Tom Yu
Massachusetts Institute of Technology Massachusetts Institute of Technology
Room E40-345 Room E40-345
77 Massachusetts Avenue 77 Massachusetts Avenue
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
email: tlyu@mit.edu email: tlyu@mit.edu
phone: +1 617 253 1753 phone: +1 617 253 1753
 End of changes. 101 change blocks. 
373 lines changed or deleted 693 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/