[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Internet-Draft                                                    Tom Yu
Common Authentication Technology WG                                  MIT
draft-ietf-cat-krb5gss-mech2-01.txt                      22 October 1998

           The Kerberos Version 5 GSSAPI Mechanism, Version 2

STATUS OF THIS MEMO

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Comments on this document should be sent to
"ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication
Technology WG discussion list.

ABSTRACT

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

ACKNOWLEDGEMENTS

Much of the material in this specification is based on work done for
Cygnus Solutions by Marc Horowitz.

1.  Introduction

The previous GSSAPI Kerberos V5 mechanism, described in RFC 1964, has
several flaws which make integrating new encryption types (enctypes)
more difficult.  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
overloading of that field.  The number assignments for checksum
algorithms are also inconsistent between the Kerberos protocol and the
GSSAPI mechanism.  The previous mechanism also assumes that both
checksums and cryptosystem blocksizes are eight bytes.  There are no
backward-compatible ways to remedy these shortcomings.


Yu                  Document Expiration: 22 Apr 1999            [Page 1]


Internet-Draft             krb5-gss-mech2-01                October 1998

Defining all GSSAPI tokens for the new Kerberos V5 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

All tokens, not just the initial token, are framed as the
InitialContextToken described in RFC 2078 section 3.1.  The
innerContextToken element of the token will not itself be encoded in
ASN.1, with the exception of caller-provided application data.  The
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
fixed size shown.

2.1.  Packet Notation

The order of transmission of this protocol is described at the octet
level.  Packet diagrams depict bits in the order of transmission,
assuming that individual octets are transmitted with the most
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
are numbered in the order of transmission, not the order of the
significance of the bits; thus, bit number 0 is the MSB of the first
octet.  Numbers prefixed by the string "0x" are in hexadecimal notation,
as in the C programming language.  Fixed-length fields that appear to be
aligned on 32-bit boundaries are not necessarily aligned if they follow
a variable length field.  No padding should be used to force alignment
of such fields to a 32-bit boundary.

2.2.  Mechanism OID

The Object Identifier (OID) of the new krb5 v2 mechanism is:

{iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2)
krb5v2(3)}


2.3.  Context Establishment

2.3.1.  Option Format

Context establishment tokens, i.e., the initial ones that the
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
the subsequent behavior of the context.  This document describes only a
small set of options, but additional types may be added by documents

Yu                  Document Expiration: 22 Apr 1999            [Page 2]


Internet-Draft             krb5-gss-mech2-01                October 1998

intended to supplement this one.  The generic format is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          option type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         option length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          option data                          |
   /                               :                               /
   /                               :                               /
   |                          option data                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


option type (32 bits)
     The type identifier of the following option.

option length (32 bits)
     The length in bytes of the following option.

option data (variable length)
     The actual option data.

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
end of the list.

2.3.1.1.  Delegated Credentials Option

Only the initiator may use this option.  The format of the delegated
credentials option is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    option type = 0x00000001                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        KRB-CRED length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        KRB-CRED message                       |
   /                               :                               /
   /                               :                               /
   |                        KRB-CRED message                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


option type (32 bits)
     The option type for this option shall be 0x00000001.

KRB-CRED length (32 bits)
     The length in bytes of the following KRB-CRED message.


Yu                  Document Expiration: 22 Apr 1999            [Page 3]


Internet-Draft             krb5-gss-mech2-01                October 1998

KRB-CRED message (variable length)
     The option data for this option shall be the KRB-CRED message that
     contains the credentials being delegated (forwarded) to the context
     acceptor.  Only the initiator may use this option.

2.3.1.2.  Null Option

The Null option terminates the option list, and must be used by both the
initiator and the acceptor.  Its format is as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        option type = 0                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           length = 0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


option type (32 bits)
     The option type of this option must be zero.

option length (32 bits)
     The length of this option must be zero.

2.3.2.  Initial Token

This is the initial token sent by the context initiator, generated by
GSS_Init_sec_context().


























Yu                  Document Expiration: 22 Apr 1999            [Page 4]


Internet-Draft             krb5-gss-mech2-01                October 1998

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        initial token id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 reserved flag bits                |I|C|S|R|M|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      checksum type count                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      checksum type list                       |
   /                               :                               /
   /                               :                               /
   |                      checksum type list                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            options                            |
   /                               :                               /
   /                               :                               /
   |                            options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         AP-REQ length                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          AP-REQ data                          |
   /                               :                               /
   /                               :                               /
   |                          AP-REQ data                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


initial token ID (32 bits)
     Contains the integer 0x01010101, which identifies this as the
     initial token in the context setup.

reserved flag bits (26 bits)
     These bits are reserved for future expansion.  They must be set to
     zero by the initiator and be ignored by the acceptor.

I flag (1 bit)
     0x00000020 -- GSS_C_INTEG_FLAG

C flag (1 bit)
     0x00000010 -- GSS_C_CONF_FLAG

S flag (1 bit)
     0x00000008 -- GSS_C_SEQUENCE_FLAG

R flag (1 bit)
     0x00000004 -- GSS_C_REPLAY_FLAG

M flag (1 bit)
     0x00000002 -- GSS_C_MUTUAL_FLAG

D flag (1 bit)
     0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the
     "delegated credentials" option is included.

Yu                  Document Expiration: 22 Apr 1999            [Page 5]


Internet-Draft             krb5-gss-mech2-01                October 1998

checksum type count (32 bits)
     The number of checksum types supported by the initiator.

checksum type list (variable length)
     A list of Kerberos checksum types, as defined in RFC 1510
     section 6.4.  These checksum types must be collision-proof and
     keyed with the context key.  Each checksum type number shall be 32
     bits wide.  This list should contain all the checksum types
     supported by the initiator.

options (variable length)
     The option format will be described later.

AP-REQ length (32 bits)
     The length of the following KRB_AP_REQ message.

AP-REQ data (variable length)
     The AP-REQ message as described in RFC 1510.  The checksum in the
     authenticator will be computed over the items listed in the next
     section.

The optional sequence number field shall be used in the AP-REQ.  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
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.
When subkeys are generated, it is strongly recommended that they be of
the same type as the associated session key.

2.3.2.1.  Data to be Checksummed in AP-REQ

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
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
is to be checksummed in the AP-REQ.



















Yu                  Document Expiration: 22 Apr 1999            [Page 6]


Internet-Draft             krb5-gss-mech2-01                October 1998

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     initiator address type                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    initiator address length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       initiator address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     acceptor address type                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    acceptor address length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        acceptor address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        application data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        initial token id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             flags                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      checksum type count                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      checksum type list                       |
   /                               :                               /
   /                               :                               /
   |                      checksum type list                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            options                            |
   /                               :                               /
   /                               :                               /
   |                            options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



initiator address type (32 bits)
     The initiator address type, as defined in the Kerberos protocol
     specification.  If no initiator address is provided, this must be
     zero.

initiator address length (32 bits)
     The length in bytes of the following initiator address.  If there
     is no inititator address provided, this must be zero.

initiator address (variable length)
     The actual initiator address, in network byte order.

acceptor address type (32 bits)
     The acceptor address type, as defined in the Kerberos protocol
     specification.  If no acceptor address is provided, this must be
     zero.



Yu                  Document Expiration: 22 Apr 1999            [Page 7]


Internet-Draft             krb5-gss-mech2-01                October 1998

acceptor address length (32 bits)
     The length in bytes of the following acceptor address.  This must
     be zero is there is no acceptor address provided.

initiator address (variable length)
     The actual acceptor address, in network byte order.

applicatation data (variable length)
     The application data, if provided, encoded as a ASN.1 octet string
     using DER.  If no application data are passed as input channel
     bindings, this shall be a zero-length ASN.1 octet string.

initial token ID (32 bits)
     The initial token ID from the initial token.

flags (32 bits)
     The context establishment flags from the initial token.

checksum type count (32 bits)
     The number of checksum types supported by the initiator.

checksum type list (variable length)
     The same list of checksum types contained in the initial token.

options (variable length)
     The options list from the initial token.

2.3.3.  Response Token

This is the reponse token sent by the context acceptor, if mutual
authentication is enabled.
























Yu                  Document Expiration: 22 Apr 1999            [Page 8]


Internet-Draft             krb5-gss-mech2-01                October 1998

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       response token id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     reserved flag bits                    |D|E|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      checksum type count                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      checksum type list                       |
   /                               :                               /
   /                               :                               /
   |                      checksum type list                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            options                            |
   /                               :                               /
   /                               :                               /
   |                            options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   AP-REP or KRB-ERROR length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    AP-REP or KRB-ERROR data                   |
   /                               :                               /
   /                               :                               /
   |                    AP-REP or KRB-ERROR data                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MIC length                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            MIC data                           |
   /                               :                               /
   /                               :                               /
   |                            MIC data                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


response token id (32 bits)
     Contains the integer 0x02020202, which identifies this as the
     response token in the context setup.

reserved flag bits (30 bits)
     These bits are reserved for future expansion.  They must be set to
     zero by the acceptor and be ignored by the initiator.

D flag -- delegated creds accepted (1 bit)
     0x00000002 -- If this flag is set, the acceptor processed the
     delegated credentials, and GSS_C_DELEG_FLAG should be returned to
     the caller.

E flag -- error (1 bit)
     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,
     an AP-REP message shall be present.



Yu                  Document Expiration: 22 Apr 1999            [Page 9]


Internet-Draft             krb5-gss-mech2-01                October 1998

checksum type count (32 bits)
     The number of checksum types supported by both the initiator and
     the acceptor.

checksum type list (variable length)
     A list of Kerberos checksum types, as defined in RFC 1510
     section 6.4.  These checksum types must be collision-proof and
     keyed with the context key.  Each checksum type number shall be 32
     bits wide.  This list should contain the intersection of the list
     of checksum types specified by the initiator in the initial token
     and the list of checksum types supported by the acceptor.

options (variable length)
     The option list, as described earlier.  At this time, no options
     are defined for the acceptor, but an implementation might make use
     of these options to acknowledge an option from the initial token.
     After all the options are specified, a null option must be used to
     terminate the list.

AP-REP or KRB-ERROR length (32 bits)
     Depending on the value of the error flag, length in bytes of the
     AP-REP or KRB-ERROR message.

AP-REP or KRB-ERROR data (variable length)
     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, 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
     message.

MIC length (32 bits)
     The number of bytes in the following MIC data field.

MIC data (variable length)
     A MIC token, as described in section 2.4.2, computed over the
     concatentation of the response token ID, flags, checksum length and
     type fields, and all option fields.  This field and the preceding
     length field must not be present if the error flag is set.

2.4.  Per-message Tokens

2.4.1.  Sequence Number Usage

Sequence numbers for per-message tokens are 32 bit unsigned integers,
which are incremented by 1 after each token.  An overflow condition
should result in a wraparound of the sequence number to zero.  The
initiator and acceptor each keep their own sequence numbers per
connection.

2.4.2.  MIC Token

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
when it is received.  The MIC token has the following format:

Yu                  Document Expiration: 22 Apr 1999           [Page 10]


Internet-Draft             krb5-gss-mech2-01                October 1998

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MIC token id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           direction                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         checksum type                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        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)
     The sequence number.

direction (32 bits)
     All bits in this field shall be zero if the message is sent from
     the context initiator.  If the message is sent from the context
     acceptor, all bits shall be one.

checksum type (32 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.

checksum length (32 bits)
     The number of bytes in the following checksum data field.

checksum data (variable length)
     The checksum itself, as defined in RFC 1510 section 6.4.  The
     checksum is calculated over the encoding described in the following
     section.  The key usage GSS_TOK_MIC -- 22 [XXX need to register
     this] shall be used.

The mechanism implementation should only use checksum types which it
knows to be valid for both peers.  If mutual authentication is used,
then any checksum type specified by the acceptor may be used.  If mutual
authentication is not used XXX what do we do then?  This seems to be a
more general issue than just GSSAPI.  What checksum type did we use for
the authenticator checksum?


Yu                  Document Expiration: 22 Apr 1999           [Page 11]


Internet-Draft             krb5-gss-mech2-01                October 1998

2.4.2.1.  Data to be Checksummed in MIC Token

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;
the description only appears for the purpose of specifying the method of
calculating the checksum.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          MIC token id                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           direction                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        application data                       |
   /                               :                               /
   /                               :                               /
   |                        application data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


MIC token ID (32 bits)
     The MIC token ID from the MIC message.

sequence number (32 bits)
     The sequence number.

direction (32 bits)
     All bits in this field shall be zero if the message is sent from
     the context initiator.  If the message is sent from the context
     acceptor, all bits shall be one.

application data (variable length)
     The application-supplied data, encoded as an ASN.1 octet string
     using DER.

2.4.3.  Wrap Token

Use of the GSS_Wrap() call yields a token which encapsulates the input
user data (optionally encrypted) along with associated integrity check
quantities.

2.4.3.1.  Wrap Token With Integrity Only










Yu                  Document Expiration: 22 Apr 1999           [Page 12]


Internet-Draft             krb5-gss-mech2-01                October 1998

    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)
     Contains the integer 0x04040404, which identifies this as a Wrap
     token with integrity only.

sequence number (32 bits)
     The sequence number.

direction (32 bits)
     All bits in this field shall be zero if the message is sent from
     the context initiator.  If the message is sent from the context
     acceptor, all bits shall be one.

application data (variable length)
     The application-supplied data, encoded as an ASN.1 octet string
     using DER.

checksum type (32 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.

checksum data (variable length)
     The checksum itself, as defined in RFC 1510 section 6.4, computed
     over the concatenation of the token ID, sequence number, direction
     field, application data length, and application data, as in the MIC
     token checksum in the previous section.  The key usage

Yu                  Document Expiration: 22 Apr 1999           [Page 13]


Internet-Draft             krb5-gss-mech2-01                October 1998

     GSS_TOK_WRAP_INTEG -- 23 [XXX need to register this] shall be used.

The mechanism implementation should only use checksum types which it
knows to be valid for both peers, as described for MIC tokens.

2.4.3.2.  Wrap Token With Integrity and Encryption

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    encrypted wrap token id                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         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)
     The number of bytes in the following encrypted data field.

encrypted data (variable length)
     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
     RFC 1510 section 6.1, but rather the bare ciphertext without
     framing, encryption type, or kvno information.  The encryption is
     performed using the key/enctype exchanged during context setup.
     The key usage 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

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           direction                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        application data                       |
   /                               :                               /
   /                               :                               /
   |                        application data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


sequence number (32 bits)
     The sequence number.

Yu                  Document Expiration: 22 Apr 1999           [Page 14]


Internet-Draft             krb5-gss-mech2-01                October 1998

direction (32 bits)
     All bits in this field shall be zero if the message is sent from
     the context initiator.  If the message is sent from the context
     acceptor, all bits shall be one.

application data (variable length)
     The application-supplied data, encoded as an ASN.1 octet string
     using DER.

3.  ASN.1 Encoding of Octet Strings

In order to encode arbitirarly-sized application data, ASN.1 octet
string encoding is in this protocol.  The Distinguished Encoding Rules
(DER) shall always be used in such cases.  For reference purposes, the
DER encoding of an ASN.1 octet string, adapted from ISO/IEC 8825-1,
follows:

   +--------+-------//-------+-------//-------+
   |00000100| length octets  |contents octets |
   +--------+-------//-------+-------//-------+
    |
    +-- identifier octet = 0x04 = [UNIVERSAL 4]


In this section only, the bits in each octet shall be numbered as in the
ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the octet,
and with bit 1 being the LSB of the octet.

identifier octet (8 bits)
     Contains the constant 0x04, the tag for primitive encoding of an
     octet string with the default (UNIVERSAL 4) tag.

length octets (variable length)
     Contains the length of the contents octets, in definite form (since
     this encoding uses DER).

contents octets (variable length)
     The contents of the octet string.

The length octets shall consist of either a short form (one byte only),
which is to be used only if the number of octets in the contents octets
is less than or equal to 127, or a long form, which is to be used in all
other cases.  The short form shall consist of a single octet with bit 8
(the MSB) equal to zero, and the remaining 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
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
in the length encoding as an unsigned binary integer.  The length must
be encoded in the minimum number of octets.  An initial octet of 0xFF is
reserved by the ASN.1 specification.  Bits 8 to 1 of the first
subsequent octet, followed by bits 8 to 1 of each subsequent octet in
order, shall be the encoding of an unsigned binary integer, with bit 8

Yu                  Document Expiration: 22 Apr 1999           [Page 15]


Internet-Draft             krb5-gss-mech2-01                October 1998

of the first octet being the most 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
by the ASN.1 specification for indefinite lengths in conjunction with
constructed contents encodings, which are not to be used with DER.

4.  Name Types

The name types and forms for this mechanism will be basically identical
to those specified in RFC 1964.  The actual text describing these will
be included later.

5.  Kerberos Protocol Dependencies

This protocol makes several assumptions about the Kerberos protocol,
which may require changes to the successor of RFC 1510.

Sequence numbers, checksum types, and address types are assumed to be no
wider than 32 bits.  The Kerberos protocol specification might need to
be modified to accomodate this.  This obviously requires some further
discussion.

Key usages need to be registered within the Kerberos protocol for use
with GSSAPI per-message tokens.  The current specification of the
Kerberos protocol does not include descriptions of key derivations or
key usages, but planned revisions to the protocol will include them.

This protocol also makes the assumption that any cryptosystem used with
the session key will include integrity protection, i.e., it assumes that
no "raw" cryptosystems will be used.

6.  Security Considerations

The GSSAPI is a security protocol; therefore, security considerations
are discussed throughout this document.  The old Kerberos 5 GSSAPI
mechanism's constraints on possible cryptosystems and checksum types do
not permit it to be readily extended to accomodate more secure
cryptographic technologies with larger checksums or encryption block
sizes.  Sites are strongly encouraged to adopt the mechanism specified
in this document in the light of recent publicity about the deficiencies
of DES.

7.  References

[ISOIEC8824-1:1995] ISO/IEC, "Information technology -- Abstract Syntax
Notation One (ASN.1): Specification of basic notation",
ISO/IEC 8824-1:1995.

[ISOIEC8825-1:1995] ISO/IEC, "Information technology -- ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)",
ISO/IEC 8825-1:1995.


Yu                  Document Expiration: 22 Apr 1999           [Page 16]


Internet-Draft             krb5-gss-mech2-01                October 1998

[RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication
Service (V5)", RFC 1510.

[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964.

[RFC2078] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078

8.  Author's Address
Tom Yu
Massachusetts Institute of Technology
Room E40-345
77 Massachusetts Avenue
Cambridge, MA 02139
USA

email: tlyu@mit.edu
phone: +1 617 253 1753




































Yu                  Document Expiration: 22 Apr 1999           [Page 17]