Internet-Draft Tom Yu Common Authentication Technology WG MIT draft-ietf-cat-krb5gss-mech2-02.txt 18 November 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: 18 May 1999 [Page 1] Internet-Draft krb5-gss-mech2-02 November 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. In each octet, bit number 7 is the MSB and bit number 0 is the LSB. Right hand sides of rows may be 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 string "0x" are in hexadecimal notation, as in the C programming language. No padding should be used to force alignment of variable-length 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 intended to supplement this one. The generic format is as follows: Yu Document Expiration: 18 May 1999 [Page 2] Internet-Draft krb5-gss-mech2-02 November 1998 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | option type |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 | option length | +---------------+---------------+---------------+---------------+ | . | 4 / option data / | . | +---------------+---------------+---------------+---------------+ option type (16 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. 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 Only the initiator may use this option. The format of the delegated 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 byte +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | option type = 0x0001 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 | KRB-CRED length | +---------------+---------------+---------------+---------------+ | . | 4 / KRB-CRED message / | . | +---------------+---------------+---------------+---------------+ option type (16 bits) The option type for this option shall be 0x0001. KRB-CRED length (32 bits) The length in bytes of the following KRB-CRED message. 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 Yu Document Expiration: 18 May 1999 [Page 3] Internet-Draft krb5-gss-mech2-02 November 1998 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: 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | option type = 0 |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 | length = 0 | +---------------+---------------+---------------+---------------+ option type (16 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(). 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | initial token id (0x0101) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 | reserved flag bits |I|C|S|R|M|D| +---------------+---------------+---------------+---------------+ 6 | checksum type count |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ | . | 8 / checksum type list / | . | +---------------+---------------+---------------+---------------+ | . | n / options / | . | +---------------+---------------+---------------+---------------+ m | AP-REQ length | +---------------+---------------+---------------+---------------+ | . | m+4 / AP-REQ data / | . | +---------------+---------------+---------------+---------------+ initial token ID (16 bits) Contains the integer 0x0101, which identifies this as the initial token in the context setup. Yu Document Expiration: 18 May 1999 [Page 4] Internet-Draft krb5-gss-mech2-02 November 1998 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. checksum type count (16 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; no checksum types that are incompatible with the encryption key shall be used. Each checksum type number shall 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) The context initiation options, described in section 2.3.1. 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. Yu Document Expiration: 18 May 1999 [Page 5] Internet-Draft krb5-gss-mech2-02 November 1998 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 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. The items in this encoding that precede the initial token ID correspond to the channel 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 byte +---------------+---------------+---------------+---------------+ 0 | initiator address type | +---------------+---------------+---------------+---------------+ 4 | initator address length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 6 | initiator address | +---------------+---------------+---------------+---------------+ n | acceptor address type | +---------------+---------------+---------------+---------------+ n+4 | acceptor address length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ n+6 | acceptor address | +---------------+---------------+---------------+---------------+ | . | m / application data / | . | +---------------+---------------+---------------+---------------+ k | initial token id (0x0101) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ k+2 | flags | +---------------+---------------+---------------+---------------+ k+6 | checksum type count |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ | . | k+8 / checksum type list / | . | +---------------+---------------+---------------+---------------+ | . | j / 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. Yu Document Expiration: 18 May 1999 [Page 6] Internet-Draft krb5-gss-mech2-02 November 1998 initiator address length (16 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. acceptor address length (16 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 (16 bits) The initial token ID from the initial token. flags (32 bits) The context establishment flags from the initial token. checksum type count (16 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: 18 May 1999 [Page 7] Internet-Draft krb5-gss-mech2-02 November 1998 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | response token id (0x0202) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 | reserved flag bits |D|E| +---------------+---------------+---------------+---------------+ 6 | checksum type | +---------------+---------------+---------------+---------------+ | . | 14 / options / | . | +---------------+---------------+---------------+---------------+ n | AP-REP or KRB-ERROR length | +---------------+---------------+---------------+---------------+ | . | n+4 / AP-REP or KRB-ERROR data / | . | +---------------+---------------+---------------+---------------+ | . | m / MIC data / | . | +---------------+---------------+---------------+---------------+ response token id (16 bits) Contains the integer 0x0202, 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. checksum type count (16 bits) The number of checksum types supported by both the initiator and the acceptor. checksum type (32 bits) A Kerberos checksum type, as defined in RFC 1510 section 6.4. This checksum type must be among the types listed by the initiator, and will be used in for subsequent checksums generated during this security context. options (variable length) The option list, as described earlier. At this time, no options Yu Document Expiration: 18 May 1999 [Page 8] Internet-Draft krb5-gss-mech2-02 November 1998 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 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 31 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. 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 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: 18 May 1999 [Page 9] Internet-Draft krb5-gss-mech2-02 November 1998 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | MIC token id (0x0303) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 |D| sequence number | +---------------+---------------+---------------+---------------+ 6 | checksum length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ | . | 8 / checksum data / | . | +---------------+---------------+---------------+---------------+ MIC token id (16 bits) Contains the integer 0x0303, which identifies this as a MIC token. D -- direction bit (1 bit) 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. sequence number (31 bits) The sequence number. checksum length (16 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 shall only use the checksum type returned by the acceptor in the case of mutual authentication. If mutual authentication is not requested, then only the checksum type in the initiator token shall be used. 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. Yu Document Expiration: 18 May 1999 [Page 10] Internet-Draft krb5-gss-mech2-02 November 1998 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 | MIC token id (0x0303) |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 |D| sequence number | +---------------+---------------+---------------+---------------+ | . | 6 / application data / | . | +---------------+---------------+---------------+---------------+ MIC token ID (16 bits) The MIC token ID from the MIC message. D -- direction bit (1 bit) 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. sequence number (31 bits) The sequence number. 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 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 |integrity wrap token id(0x0404)|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ 2 |D| sequence number | +---------------+---------------+---------------+---------------+ | . | 6 / application data / | . | +---------------+---------------+---------------+---------------+ n | checksum length |XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ | . | n+2 / checksum data / | . | +---------------+---------------+---------------+---------------+ Yu Document Expiration: 18 May 1999 [Page 11] Internet-Draft krb5-gss-mech2-02 November 1998 integrity wrap token id (16 bits) Contains the integer 0x0404, which identifies this as a Wrap token with integrity only. D -- direction bit (1 bit) 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. sequence number (31 bits) The sequence number. application data (variable length) The application-supplied data, encoded as an ASN.1 octet string using DER. checksum length (16 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 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 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 +---------------+---------------+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 0 |encrypted wrap token id(0x0505)|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX +---------------+---------------+---------------+---------------+ | . | 2 / encrypted data / | . | +---------------+---------------+---------------+---------------+ encrypted wrap token id (16 bits) Contains the integer 0x0505, which identifies this as a Wrap token with integrity and encryption. encrypted data (variable length) 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 the ASN.1 type EncryptedData as defined in RFC 1510 section 6.1, but rather the ciphertext without encryption type or kvno information. The encryption is performed using the key/enctype exchanged during context setup. The confounder and checksum are as specified in the Kerberos protocol specification. The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need to register this] shall be used. Yu Document Expiration: 18 May 1999 [Page 12] Internet-Draft krb5-gss-mech2-02 November 1998 The actual data to be encrypted are specified below. 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 byte +---------------+---------------+---------------+---------------+ 0 |D| sequence number | +---------------+---------------+---------------+---------------+ | . | 4 / application data / | . | +---------------+---------------+---------------+---------------+ D -- direction bit (1 bit) 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. sequence number (31 bits) The sequence number. 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). Yu Document Expiration: 18 May 1999 [Page 13] Internet-Draft krb5-gss-mech2-02 November 1998 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 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 Yu Document Expiration: 18 May 1999 [Page 14] Internet-Draft krb5-gss-mech2-02 November 1998 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. [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: 18 May 1999 [Page 15]