draft-ietf-cat-krb5gss-mech2-01.txt   draft-ietf-cat-krb5gss-mech2-02.txt 
skipping to change at page 2, line 33 skipping to change at page 2, line 33
All integer fields are in network byte order. All other fields have the All integer fields are in network byte order. All other fields have the
fixed size shown. fixed size shown.
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 and
from top to bottom, as in printed English. When bits are numbered, they from top to bottom, as in printed English. In each octet, bit number 7
are numbered in the order of transmission, not the order of the is the MSB and bit number 0 is the LSB. Right hand sides of rows may be
significance of the bits; thus, bit number 0 is the MSB of the first filled with the upper-case letter "X" to denote the absence of
octet. Numbers prefixed by the string "0x" are in hexadecimal notation, additional bytes in the row; this padding is for visual purposes only.
as in the C programming language. Fixed-length fields that appear to be Numbers prefixed by the string "0x" are in hexadecimal notation, as in
aligned on 32-bit boundaries are not necessarily aligned if they follow the C programming language. No padding should be used to force
a variable length field. No padding should be used to force alignment alignment of variable-length fields to a 32-bit boundary.
of such fields to a 32-bit boundary.
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
skipping to change at page 3, line 4 skipping to change at page 2, line 57
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 while
a security context is being set up, may contain options that influence a security context is being set up, may contain options that influence
the subsequent behavior of the context. This document describes only a the subsequent behavior of the context. This document describes only a
small set of options, but additional types may be added by documents small set of options, but additional types may be added by documents
intended to supplement this one. The generic format is as follows: intended to supplement this one. The generic format is as follows:
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | option type |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| option type | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | option length |
| option length | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| option data | 4 / option data /
/ : / | . |
/ : / +---------------+---------------+---------------+---------------+
| option data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option type (32 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. The
final option in a token must be the null option, in order to mark the final option in a token must be the null option, in order to mark the
end of the list. end of the list. Option type 0xffff is reserved.
The initiator and acceptor shall ignore any options that they do not
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:
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | option type = 0x0001 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| option type = 0x00000001 | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | KRB-CRED length |
| KRB-CRED length | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| KRB-CRED message | 4 / KRB-CRED message /
/ : / | . |
/ : / +---------------+---------------+---------------+---------------+
| KRB-CRED message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option type (32 bits) option type (16 bits)
The option type for this option shall be 0x00000001. 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 that
contains the credentials being delegated (forwarded) to the context contains the credentials being delegated (forwarded) to the context
acceptor. Only the initiator may use this option. 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 the
initiator and the acceptor. Its format is as follows: initiator and the acceptor. Its format is as follows:
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | option type = 0 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| option type = 0 | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | length = 0 |
| length = 0 | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option type (32 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().
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | initial token id (0x0101) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| initial token id | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | reserved flag bits |I|C|S|R|M|D|
| reserved flag bits |I|C|S|R|M|D| +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | checksum type count |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| checksum type count | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| checksum type list | 8 / checksum type list /
/ : / | . |
/ : / +---------------+---------------+---------------+---------------+
| checksum type list | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n / options /
| options | | . |
/ : / +---------------+---------------+---------------+---------------+
/ : / m | AP-REQ length |
| options | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| AP-REQ length | m+4 / AP-REQ data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| AP-REQ data | +---------------+---------------+---------------+---------------+
/ : /
/ : /
| AP-REQ data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
initial token ID (32 bits) initial token ID (16 bits)
Contains the integer 0x01010101, which identifies this as the Contains the integer 0x0101, which identifies this as the initial
initial token in the context setup. 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 to
zero by the initiator and be ignored by the acceptor. 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
skipping to change at page 6, line 5 skipping to change at page 5, line 28
R flag (1 bit) R flag (1 bit)
0x00000004 -- GSS_C_REPLAY_FLAG 0x00000004 -- GSS_C_REPLAY_FLAG
M flag (1 bit) M flag (1 bit)
0x00000002 -- GSS_C_MUTUAL_FLAG 0x00000002 -- GSS_C_MUTUAL_FLAG
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 (32 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 section 6.4. These checksum types must be collision-proof and keyed
keyed with the context key. Each checksum type number shall be 32 with the context key; no checksum types that are incompatible with
bits wide. This list should contain all the checksum types the encryption key shall be used. Each checksum type number shall
supported by the initiator. be 32 bits wide. This list should contain all the checksum types
supported by the initiator. If mutual authentication is not used,
then this list shall contain only one checksum type.
options (variable length) options (variable length)
The option format will be described later. 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 the
authenticator will be computed over the items listed in the next authenticator will be computed over the items listed in the next
section. 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 the
per-message tokens will be the AP-REP subkey, or if that is not present, per-message tokens will be the AP-REP subkey, or if that is not present,
the authenticator subkey, or if that is not present, the session key. the authenticator subkey, or if that is not present, the session key.
When subkeys are generated, it is strongly recommended that they be of When subkeys are generated, it is strongly recommended that they be of
the same type as the associated session key. the same type as the associated session key.
XXX The above is not secure. There should be an algorithmic process 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
both parties, and this should probably be part of the revised 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 force
integer fields to align on 32 bit boundaries. This particular set of integer fields to align on 32 bit boundaries. This particular set of
data should not be sent as a part of any token; it merely specifies what data should not be sent as a part of any token; it merely specifies what
is to be checksummed in the AP-REQ. is to be checksummed in the AP-REQ. The items in this encoding that
precede the initial token ID correspond to the channel bindings passed
to GSS_Init_sec_context().
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | initiator address type |
| initiator address type | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | initator address length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| initiator address length | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | initiator address |
| initiator address | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n | acceptor address type |
| acceptor address type | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n+4 | acceptor address length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| acceptor address length | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ n+6 | acceptor address |
| acceptor address | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| application data | m / application data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| initial token id | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ k | initial token id (0x0101) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| flags | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ k+2 | flags |
| checksum type count | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ k+6 | checksum type count |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| checksum type list | +---------------+---------------+---------------+---------------+
/ : / | . |
/ : / k+8 / checksum type list /
| checksum type list | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------+---------------+---------------+---------------+
| options | | . |
/ : / j / options /
/ : / | . |
| 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 be
zero. zero.
initiator address length (32 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 there
is no inititator address provided, this must be zero. 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 (32 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 must
be zero is there is no acceptor address provided. 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 string
using DER. If no application data are passed as input channel using DER. If no application data are passed as input channel
bindings, this shall be a zero-length ASN.1 octet string. bindings, this shall be a zero-length ASN.1 octet string.
initial token ID (32 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 (32 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)
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.
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | response token id (0x0202) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| response token id | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | reserved flag bits |D|E|
| reserved flag bits |D|E| +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | checksum type |
| checksum type count | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| checksum type list | 14 / options /
/ : / | . |
/ : / +---------------+---------------+---------------+---------------+
| checksum type list | n | AP-REP or KRB-ERROR length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------+---------------+---------------+---------------+
| options | | . |
/ : / n+4 / AP-REP or KRB-ERROR data /
/ : / | . |
| options | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| AP-REP or KRB-ERROR length | m / MIC data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| AP-REP or KRB-ERROR data | +---------------+---------------+---------------+---------------+
/ : /
/ : /
| AP-REP or KRB-ERROR data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIC length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIC data |
/ : /
/ : /
| MIC data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
response token id (32 bits) response token id (16 bits)
Contains the integer 0x02020202, which identifies this as the Contains the integer 0x0202, which identifies this as the response
response token in the context setup. 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 to
zero by the acceptor and be ignored by the initiator. 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 to
the caller. 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 set,
an AP-REP message shall be present. an AP-REP message shall be present.
checksum type count (32 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 list (variable length) checksum type (32 bits)
A list of Kerberos checksum types, as defined in RFC 1510 A Kerberos checksum type, as defined in RFC 1510 section 6.4. This
section 6.4. These checksum types must be collision-proof and checksum type must be among the types listed by the initiator, and
keyed with the context key. Each checksum type number shall be 32 will be used in for subsequent checksums generated during this
bits wide. This list should contain the intersection of the list security context.
of checksum types specified by the initiator in the initial token
and the list of checksum types supported by the acceptor.
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 use
of these options to acknowledge an option from the initial token. of these options to acknowledge an option from the initial token.
After all the options are specified, a null option must be used to After all the options are specified, a null option must be used to
terminate the list. 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 KRB-ERROR
message as described in RFC 1510. If this field contains an AP-REP message as described in RFC 1510. If this field contains an AP-REP
message, the sequence number field in the AP-REP shall be filled. message, the sequence number field in the AP-REP shall be filled.
If this is a KRB-ERROR message, no further fields will be in this If this is a KRB-ERROR message, no further fields will be in this
message. message.
MIC length (32 bits)
The number of bytes in the following MIC data field.
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 and
type fields, and all option fields. This field and the preceding type fields, and all option fields. This field and the preceding
length field must not be present if the error flag is set. 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 32 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
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 acceptor to the initiator shall be the least significant 31 bits of
the sequence number in the AP-REP message if mutual authentication is
used; if mutual authentication is not used, the initial sequence number
from acceptor to initiator shall be the least significant 31 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 data
being protected, which can be used to verify the integrity of that data being protected, which can be used to verify the integrity of that data
when it is received. The MIC token has the following format: when it is received. The MIC token has the following format:
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | MIC token id (0x0303) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| MIC token id | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |D| sequence number |
| sequence number | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | checksum length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| direction | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| checksum type | 8 / checksum data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| checksum length | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum data |
/ : /
/ : /
| checksum data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MIC token id (32 bits)
Contains the integer 0x03030303, which identifies this as a MIC
token.
sequence number (32 bits) MIC token id (16 bits)
The sequence number. Contains the integer 0x0303, which identifies this as a MIC token.
direction (32 bits) D -- direction bit (1 bit)
All bits in this field shall be zero if the message is sent from This bit shall be zero if the message is sent from the context
the context initiator. If the message is sent from the context initiator. If the message is sent from the context acceptor, this
acceptor, all bits shall be one. bit shall be one.
checksum type (32 bits) sequence number (31 bits)
A Kerberos checksum type, as defined in RFC 1510 section 6.4. This The sequence number.
checksum type must be collision-proof and keyed with the context
key.
checksum length (32 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 following
section. The key usage GSS_TOK_MIC -- 22 [XXX need to register section. The key usage GSS_TOK_MIC -- 22 [XXX need to register
this] shall be used. this] shall be used.
The mechanism implementation should only use checksum types which it The mechanism implementation shall only use the checksum type returned
knows to be valid for both peers. If mutual authentication is used, by the acceptor in the case of mutual authentication. If mutual
then any checksum type specified by the acceptor may be used. If mutual authentication is not requested, then only the checksum type in the
authentication is not used XXX what do we do then? This seems to be a initiator token shall be used.
more general issue than just GSSAPI. What checksum type did we use for
the authenticator checksum?
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 is;
the description only appears for the purpose of specifying the method of the description only appears for the purpose of specifying the method of
calculating the checksum. calculating the checksum.
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | MIC token id (0x0303) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| MIC token id | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 |D| sequence number |
| sequence number | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| direction | 6 / application data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| application data | +---------------+---------------+---------------+---------------+
/ : /
/ : /
| application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MIC token ID (32 bits) MIC token ID (16 bits)
The MIC token ID from the MIC message. The MIC token ID from the MIC message.
sequence number (32 bits) D -- direction bit (1 bit)
The sequence number. This bit shall be zero if the message is sent from the context
initiator. If the message is sent from the context acceptor, this
bit shall be one.
direction (32 bits) sequence number (31 bits)
All bits in this field shall be zero if the message is sent from The sequence number.
the context initiator. If the message is sent from the context
acceptor, all bits shall be one.
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 input
user data (optionally encrypted) along with associated integrity check user data (optionally encrypted) along with associated integrity check
quantities. quantities.
2.4.3.1. Wrap Token With Integrity Only 2.4.3.1. Wrap Token With Integrity Only
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| integrity wrap token id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application data |
/ : /
/ : /
| application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| checksum data |
/ : /
/ : /
| checksum data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
integrity wrap token id (32 bits) 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
Contains the integer 0x04040404, which identifies this as a Wrap byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
token with integrity only. 0 |integrity wrap token id(0x0404)|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+---------------+---------------+---------------+---------------+
2 |D| sequence number |
+---------------+---------------+---------------+---------------+
| . |
6 / application data /
| . |
+---------------+---------------+---------------+---------------+
n | checksum length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+---------------+---------------+---------------+---------------+
| . |
n+2 / checksum data /
| . |
+---------------+---------------+---------------+---------------+
sequence number (32 bits) integrity wrap token id (16 bits)
The sequence number. Contains the integer 0x0404, which identifies this as a Wrap token
with integrity only.
direction (32 bits) D -- direction bit (1 bit)
All bits in this field shall be zero if the message is sent from This bit shall be zero if the message is sent from the context
the context initiator. If the message is sent from the context initiator. If the message is sent from the context acceptor, this
acceptor, all bits shall be one. bit shall be one.
sequence number (31 bits)
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 type (32 bits) checksum length (16 bits)
A Kerberos checksum type, as defined in RFC 1510 section 6.4. This
checksum type must be collision-proof and keyed with the context
key. The checksum type implies the length of the checksum data.
checksum length (32 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, computed
over the concatenation of the token ID, sequence number, direction over the concatenation of the token ID, sequence number, direction
field, application data length, and application data, as in the MIC field, application data length, and application data, as in the MIC
token checksum in the previous section. The key usage token checksum in the previous section. The key usage
GSS_TOK_WRAP_INTEG -- 23 [XXX need to register this] shall be used. GSS_TOK_WRAP_INTEG -- 23 [XXX need to register this] shall be used.
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
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 |encrypted wrap token id(0x0505)|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
| encrypted wrap token id | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| encrypted data | 2 / encrypted data /
/ : / | . |
/ : / +---------------+---------------+---------------+---------------+
| encrypted data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
encrypted wrap token id (32 bits)
Contains the integer 0x05050505, which identifies this as a Wrap
token with integrity and encryption.
encrypted data length (32 bits) encrypted wrap token id (16 bits)
The number of bytes in the following encrypted data field. Contains the integer 0x0505, which identifies this as a Wrap 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,
Note that this is not the ASN.1 type EncryptedData as defined in encoded as an ASN.1 octet string using DER. Note that this is not
RFC 1510 section 6.1, but rather the bare ciphertext without the ASN.1 type EncryptedData as defined in RFC 1510 section 6.1,
framing, encryption type, or kvno information. The encryption is but rather the ciphertext without encryption type or kvno
performed using the key/enctype exchanged during context setup. information. The encryption is performed using the key/enctype
The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need to register this] exchanged during context setup. The confounder and checksum are as
shall be used. The actual data to be encrypted are specified specified in the Kerberos protocol specification. The key usage
below. GSS_TOK_WRAP_PRIV -- 24 [XXX need to register this] shall be used.
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
0 1 2 3 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 byte +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 |D| sequence number |
| sequence number | +---------------+---------------+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| direction | 4 / application data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . |
| application data | +---------------+---------------+---------------+---------------+
/ : /
/ : /
| application data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sequence number (32 bits) D -- direction bit (1 bit)
The sequence number. This bit shall be zero if the message is sent from the context
initiator. If the message is sent from the context acceptor, this
bit shall be one.
direction (32 bits) sequence number (31 bits)
All bits in this field shall be zero if the message is sent from The sequence number.
the context initiator. If the message is sent from the context
acceptor, all bits shall be one.
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 Rules
(DER) shall always be used in such cases. For reference purposes, the (DER) shall always be used in such cases. For reference purposes, the
 End of changes. 49 change blocks. 
306 lines changed or deleted 264 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/