CVS shishi/doc/specifications

[shishi-commit]

Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv21719

Added Files:
        rfc3961.txt rfc3962.txt 
Log Message:
Add.


--- /home/cvs/shishi/doc/specifications/rfc3961.txt     2005/02/15 09:19:48     
NONE
+++ /home/cvs/shishi/doc/specifications/rfc3961.txt     2005/02/15 09:19:48     
1.1






Network Working Group                                         K. Raeburn
Request for Comments: 3961                                           MIT
Category: Standards Track                                  February 2005


                 Encryption and Checksum Specifications
                             for Kerberos 5

Status of This Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a framework for defining encryption and
   checksum mechanisms for use with the Kerberos protocol, defining an
   abstraction layer between the Kerberos protocol and related
   protocols, and the actual mechanisms themselves.  The document also
   defines several mechanisms.  Some are taken from RFC 1510, modified
   in form to fit this new framework and occasionally modified in
   content when the old specification was incorrect.  New mechanisms are
   presented here as well.  This document does NOT indicate which
   mechanisms may be considered "required to implement".

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Encryption Algorithm Profile  . . . . . . . . . . . . . . . .  4
   4.  Checksum Algorithm Profile  . . . . . . . . . . . . . . . . .  9
   5.  Simplified Profile for CBC Ciphers with Key Derivation  . . . 10
       5.1.  A Key Derivation Function . . . . . . . . . . . . . . . 10
       5.2.  Simplified Profile Parameters . . . . . . . . . . . . . 12
       5.3.  Cryptosystem Profile Based on Simplified Profile  . . . 13
       5.4.  Checksum Profiles Based on Simplified Profile . . . . . 16
   6.  Profiles for Kerberos Encryption and Checksum Algorithms  . . 16
       6.1.  Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
       6.2.  DES-based Encryption and Checksum Types . . . . . . . . 18
       6.3.  Triple-DES Based Encryption and Checksum Types  . . . . 28
   7.  Use of Kerberos Encryption Outside This Specification . . . . 30



Raeburn                     Standards Track                     [Page 1]

RFC 3961         Encryption and Checksum Specifications    February 2005


   8.  Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . . 31
   9.  Implementation Notes  . . . . . . . . . . . . . . . . . . . . 32
   10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
   12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
   A.  Test vectors  . . . . . . . . . . . . . . . . . . . . . . . . 38
       A.1.  n-fold  . . . . . . . . . . . . . . . . . . . . . . . . 38
       A.2.  mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
       A.3.  DES3 DR and DK  . . . . . . . . . . . . . . . . . . . . 43
       A.4.  DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
       A.5.  Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
   B.  Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
   Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
   Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
   Informative References. . . . . . . . . . . . . . . . . . . . . . 48
   Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50

1.  Introduction

   The Kerberos protocols [Kerb] are designed to encrypt messages of
   arbitrary sizes, using block encryption ciphers or, less commonly,
   stream encryption ciphers.  Encryption is used to prove the
   identities of the network entities participating in message
   exchanges.  However, nothing in the Kerberos protocol requires that
   any specific encryption algorithm be used, as long as the algorithm
   includes certain operations.

   The following sections specify the encryption and checksum mechanisms
   currently defined for Kerberos, as well as a framework for defining
   future mechanisms.  The encoding, chaining, padding, and other
   requirements for each are described.  Appendix A gives test vectors
   for several functions.

2.  Concepts

   Both encryption and checksum mechanisms are profiled in later
   sections.  Each profile specifies a collection of operations and
   attributes that must be defined for a mechanism.  A Kerberos
   encryption or checksum mechanism specification is not complete if it
   does not define all of these operations and attributes.

   An encryption mechanism must provide for confidentiality and
   integrity of the original plaintext.  (Incorporating a checksum may
   permit integrity checking, if the encryption mode does not provide an
   integrity check itself.)  It must also provide non-malleability





Raeburn                     Standards Track                     [Page 2]

RFC 3961         Encryption and Checksum Specifications    February 2005


   [Bellare98] [Dolev91].  Use of a random confounder prepended to the
   plaintext is recommended.  It should not be possible to determine if
   two ciphertexts correspond to the same plaintext without the key.

   A checksum mechanism [1] must provide proof of the integrity of the
   associated message and must preserve the confidentiality of the
   message in case it is not sent in the clear.  Finding two plaintexts
   with the same checksum should be infeasible.  It is NOT required that
   an eavesdropper be unable to determine whether two checksums are for
   the same message, as the messages themselves would presumably be
   visible to any such eavesdropper.

   Due to advances in cryptography, some cryptographers consider using
   the same key for multiple purposes unwise.  Since keys are used in
   performing a number of different functions in Kerberos, it is
   desirable to use different keys for each of these purposes, even
   though we start with a single long-term or session key.

   We do this by enumerating the different uses of keys within Kerberos
   and by making the "usage number" an input to the encryption or
   checksum mechanisms; such enumeration is outside the scope of this
   document.  Later sections define simplified profile templates for
   encryption and checksum mechanisms that use a key derivation function
   applied to a CBC mode (or similar) cipher and a checksum or hash
   algorithm.

   We distinguish the "base key" specified by other documents from the
   "specific key" for a specific encryption or checksum operation.  It
   is expected but not required that the specific key be one or more
   separate keys derived from the original protocol key and the key
   usage number.  The specific key should not be explicitly referenced
   outside of this document.  The typical language used in other
   documents should be something like, "encrypt this octet string using
   this key and this usage number"; generation of the specific key and
   cipher state (described in the next section) are implicit.  The
   creation of a new cipher-state object, or the re-use of one from a
   previous encryption operation, may also be explicit.

   New protocols defined in terms of the Kerberos encryption and
   checksum types should use their own key usage values.  Key usages are
   unsigned 32-bit integers; zero is not permitted.

   All data is assumed to be in the form of strings of octets or eight-
   bit bytes.  Environments with other byte sizes will have to emulate
   this behavior in order to get correct results.






Raeburn                     Standards Track                     [Page 3]

RFC 3961         Encryption and Checksum Specifications    February 2005


   Each algorithm is assigned an encryption type (or "etype") or
   checksum type number, for algorithm identification within the
   Kerberos protocol.  The full list of current type number assignments
   is given in section 8.

3.  Encryption Algorithm Profile

   An encryption mechanism profile must define the following attributes
   and operations.  The operations must be defined as functions in the
   mathematical sense.  No additional or implicit inputs (such as
   Kerberos principal names or message sequence numbers) are permitted.

   protocol key format
      This describes which octet string values represent valid keys.
      For encryption mechanisms that don't have perfectly dense key
      spaces, this will describe the representation used for encoding
      keys.  It need not describe invalid specific values; all key
      generation routines should avoid such values.

   specific key structure
      This is not a protocol format at all, but a description of the
      keying material derived from the chosen key and used to encrypt or
      decrypt data or compute or verify a checksum.  It may, for
      example, be a single key, a set of keys, or a combination of the
      original key with additional data.  The authors recommend using
      one or more keys derived from the original key via one-way key
      derivation functions.

   required checksum mechanism
      This indicates a checksum mechanism that must be available when
      this encryption mechanism is used.  Since Kerberos has no built in
      mechanism for negotiating checksum mechanisms, once an encryption
      mechanism is decided, the corresponding checksum mechanism can be
      used.

   key-generation seed length, K
      This is the length of the random bitstring needed to generate a
      key with the encryption scheme's random-to-key function (described
      below).  This must be a fixed value so that various techniques for
      producing a random bitstring of a given length may be used with
      key generation functions.

   key generation functions
      Keys must be generated in a number of cases, from different types
      of inputs.  All function specifications must indicate how to
      generate keys in the proper wire format and must avoid generating
      keys that significantly compromise the confidentiality of
      encrypted data, if the cryptosystem has such.  Entropy from each



Raeburn                     Standards Track                     [Page 4]

RFC 3961         Encryption and Checksum Specifications    February 2005


      source should be preserved as much as possible.  Many of the
      inputs, although unknown, may be at least partly predictable
      (e.g., a password string is likely to be entirely in the ASCII
      subset and of fairly short length in many environments; a semi-
      random string may include time stamps).  The benefit of such
      predictability to an attacker must be minimized.

   string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
      This function generates a key from two UTF-8 strings and an opaque
      octet string.  One of the strings is usually the principal's pass
      phrase, but generally it is merely a secret string.  The other
      string is a "salt" string intended to produce different keys from
      the same password for different users or realms.  Although the
      strings provided will use UTF-8 encoding, no specific version of
      Unicode should be assumed; all valid UTF-8 strings should be
      allowed.  Strings provided in other encodings MUST first be
      converted to UTF-8 before applying this function.

      The third argument, the octet string, may be used to pass
      mechanism-specific parameters into this function.  Since doing so
      implies knowledge of the specific encryption system, generating
      non-default parameter values should be an uncommon operation, and
      normal Kerberos applications should be able to treat this
      parameter block as an opaque object supplied by the Key
      Distribution Center or defaulted to some mechanism-specific
      constant value.

      The string-to-key function should be a one-way function so that
      compromising a user's key in one realm does not compromise it in
      another, even if the same password (but a different salt) is used.

   random-to-key (bitstring[K])->(protocol-key)
      This function generates a key from a random bitstring of a
      specific size.  All the bits of the input string are assumed to be
      equally random, even though the entropy present in the random
      source may be limited.

   key-derivation (protocol-key, integer)->(specific-key)
      In this function, the integer input is the key usage value, as
      described above.  An attacker is assumed to know the usage values.
      The specific-key output value was described in section 2.

   string-to-key parameter format
      This describes the format of the block of data that can be passed
      to the string-to-key function above to configure additional
      parameters for that function.  Along with the mechanism of
      encoding parameter values, bounds on the allowed parameters should
      also be described to avoid allowing a spoofed KDC to compromise



Raeburn                     Standards Track                     [Page 5]

RFC 3961         Encryption and Checksum Specifications    February 2005


      the user's password.  If practical it may be desirable to
      construct the encoding so that values unacceptably weakening the
      resulting key cannot be encoded.

      Local security policy might permit tighter bounds to avoid excess
      resource consumption.  If so, the specification should recommended
      defaults for these bounds.  The description should also outline
      possible weaknesses if bounds checks or other validations are not
      applied to a parameter string received from the network.

      As mentioned above, this should be considered opaque to most
      normal applications.

   default string-to-key parameters (octet string)
      This default value for the "params" argument to the string-to-key
      function should be used when the application protocol (Kerberos or
      other) does not explicitly set the parameter value.  As indicated
      above, in most cases this parameter block should be treated as an
      opaque object.

   cipher state
      This describes any information that can be carried over from one
      encryption or decryption operation to the next, for use with a
      given specific key.  For example, a block cipher used in CBC mode
      may put an initial vector of one block in the cipher state.  Other
      encryption modes may track nonces or other data.

      This state must be non-empty and must influence encryption so that
      messages are decrypted in the same order they were a encrypted, if
      the cipher state is carried over from one encryption to the next.
      Distinguishing out-of-order or missing messages from corrupted
      messages is not required.  If desired, this can be done at a
      higher level by including sequence numbers and not "chaining" the
      cipher state between encryption operations.

      The cipher state may not be reused in multiple encryption or
      decryption operations.  These operations all generate a new cipher
      state that may be used for following operations using the same key
      and operation.

      The contents of the cipher state must be treated as opaque outside
      of encryption system specifications.

   initial cipher state (specific-key, direction)->(state)
      This describes the generation of the initial value for the cipher
      state if it is not being carried over from a previous encryption
      or decryption operation.




Raeburn                     Standards Track                     [Page 6]

RFC 3961         Encryption and Checksum Specifications    February 2005


      This describes any initial state setup needed before encrypting
      arbitrary amounts of data with a given specific key.  The specific
      key and the direction of operations to be performed (encrypt
      versus decrypt) must be the only input needed for this
      initialization.

      This state should be treated as opaque in any uses outside of an
      encryption algorithm definition.

      IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what
      degree an application protocol could exercise control over the
      initial vector used in DES CBC operations.  Some existing
      implementations permit setting the initial vector.  This framework
      does not provide for application control of the cipher state
      (beyond "initialize" and "carry over from previous encryption"),
      as the form and content of the initial cipher state can vary
      between encryption systems and may not always be a single block of
      random data.

      New Kerberos application protocols should not assume control over
      the initial vector, or that one even exists.  However, a general-
      purpose implementation may wish to provide the capability, in case
      applications explicitly setting it are encountered.

   encrypt (specific-key, state, octet string)->(state, octet string)
      This function takes the specific key, cipher state, and a non-
      empty plaintext string as input and generates ciphertext and a new
      cipher state as outputs.  If the basic encryption algorithm itself
      does not provide for integrity protection (e.g., DES in CBC mode),
      then some form of verifiable MAC or checksum must be included.
      Some random factor such as a confounder should be included so that
      an observer cannot know if two messages contain the same
      plaintext, even if the cipher state and specific keys are the
      same.  The exact length of the plaintext need not be encoded, but
      if it is not and if padding is required, the padding must be added
      at the end of the string so that the decrypted version may be
      parsed from the beginning.

      The specification of the encryption function must indicate not
      only the precise contents of the output octet string, but also the
      output cipher state.  The application protocol may carry the
      output cipher state forward from one encryption with a given
      specific key to another; the effect of this "chaining" must be
      defined [2].

      Assuming that values for the specific key and cipher state are
      correctly-produced, no input octet string may result in an error
      indication.



Raeburn                     Standards Track                     [Page 7]

RFC 3961         Encryption and Checksum Specifications    February 2005


   decrypt (specific-key, state, octet string)->(state, octet string)
      This function takes the specific key, cipher state, and ciphertext

[2403 lines skipped]
--- /home/cvs/shishi/doc/specifications/rfc3962.txt     2005/02/15 09:19:48     
NONE
+++ /home/cvs/shishi/doc/specifications/rfc3962.txt     2005/02/15 09:19:48     
1.1

[3302 lines skipped]