Revisions to Kerberos RFC

[Clifford Neuman <[e-mail]>]

A new draft revision to the Kerberos specification (RFC1510) is now
available.  I will be submitting this AS IS to become an Internet
draft, and the announcement will be sent to this list once it is
officially available.  The text that I am submitting is presently
available as http://gost.isi.edu/info/kerberos/1510revision.txt.

Please send any comments about this draft to the mailing list
[e-mail], and if you feel the suggestion is significant
enough to require discussion in the context of the CAT working group,
to [e-mail].  Next week I will be announcing a web page that
has been set up to track over issues in this draft (and a couple of
other drafts).  To make sure that your concern is addressed, in
addition to sending mail to the mailing list - you should register
your issue on that page when it is announced.

Very briefly, the changes to the Kerberos specification:

. Clarify the presentation of the protocol to better convey the
  intent and use of certain fields and options.

. Change some of the examples or descriptions to bring them up to
  date with extensions that have been proposed and implemented
  (through the pre-authentication and authorization data fields).

. Update the assigned numbers for error messages,  preauthentication, 
  authorization data, and encryption and checksum types.

. Fix flaws in the pseudocode that was presented in the spec, to bring
  it in line with the implementations, and the descriptions from the spec. 

In greater detail, the changes are listed below in several categories:
  . Changes since the RFC
  . Questions that still need to be answered
  . Responses to suggested changes that did not result in changes
  . Items for which further discussion is needed
  . Items for which changes are planned, but not yet integrated with draft

There have been a lot of contributions made to the Kerberos
specification both in its original form and in this revision.  At
present the acknowledgments section is omitted from the draft, but a
new section will be drafted as the draft starts to stabilize, and
everyone will have a chance to remind me if they were inadvertently
omitted.  In the meantime, I thank everyone that has contributed to
the rewrite.

Clifford Neuman

---------------

Changes:

O Changes specified in the eratta document released with the MIT
  reference implementation, and previously sent to the Kerberos list
  have been incorporated in the draft.  These included:

  1. [19940312] The following lines describes corrections to pseudocode
     in rfc1510 as of March 12, 1994.

    A: Throughout the pseudocode (section A), flags.ALLOW-POSTDATE should be
       replaced by flags.MAY-POSTDATE.  kdc-options.ALLOW-POSTDATE is
       correct, however.

  A.2: In the processing for the kdc-options.POSTDATE (imperative), both
       the POSTDATED and the INVALID flag should be set. The setting of the
       POSTDATE flag was inadvertently omitted.

       You should change:

          if (req.kdc-options.POSTDATED is set) then
             if (against_postdate_policy(req.from)) then
                  error_out(KDC_ERR_POLICY);
             endif
             set new_tkt.flags.INVALID;
             new_tkt.starttime := req.from;
          else
             omit new_tkt.starttime; /* treated as authtime when

       To:
          if (req.kdc-options.POSTDATED is set) then
             if (against_postdate_policy(req.from)) then
                  error_out(KDC_ERR_POLICY);
             endif
             set new_tkt.flags.POSTDATED;                         <****
             set new_tkt.flags.INVALID;
             new_tkt.starttime := req.from;
         else
             omit new_tkt.starttime; /* treated as authtime when




   A.6: In section A.6, all occurrences of kdc-options.POSTDATE (imperative)
        should be replaced by kdc-options.ALLOW-POSTDATE and tgt.flags.POSTDATE
        should be replaced by tgt.flags.MAY-POSTDATE.

        Note that instances of POSTDATED (adjective) are correct.

   2. [19940614] Processing of the etype filed, described in 3.1.3,
      and 5.4.1. 

       If there are multiple encryption keys registered for a client in the
       Kerberos database (or if the key registered supports multiple
       encryption types; e.g. DES-CBC-CRC and DES-CBC-MD5), then the etype
       field from the AS request is used by the KDC to select the encryption
       method to be used for encrypting the response to the client.  If there
       is more than one supported, strong encryption type in the etype list,
       the first valid etype for which an encryption key is available is
       used.  The encryption method used to respond to a TGS request is taken
       from the keytype of the session key found in the ticket granting
       ticket.

       When the etype field is present in a KDC request, whether an AS or TGS
       request, the KDC will attempt to assign the type of the random session
       key from the list of methods in the etype field.  The KDC will select
       the appropriate type using the list of methods provided together with
       information from the Kerberos database indicating acceptable
       encryption methods for the application server.  The KDC will not issue
       tickets with a weak session key encryption type.

    3. [19940707] Case of realm names for DNS based realm names, 

       The following should appear in section 7.1 before the description
       of the four classed of realm names (before "There are presently...")

         Kerberos realm names are case sensitive.  Realm names that differ
         only in the case of the characters are not equivalent.

       The domain example should be changes from:
   	  domain:   host.subdomain.domain (example)

        To:
 
   	  domain:   ATHENA.MIT.EDU (example)

        The following should be append to the domain name paragraph of
        section 7.1 (following "nor slashes (/).")

        Domain names must be converted to upper case when used as realm names.

     4. [19940707] Official name of host is instance for NT-SRV-HST

        Append to paragraph 7.2.1:

        When a host has an official name and one or more aliases, the
        official name of the host must be used when constructing the name
        of the server principal.

     5. [19940722] The protocol is standards track
   
        In the 3rd paragraph of the overview delete:

         ", and are not being submitted for consideration as
         an Internet standard at this time"

        as it contradicts the first sentence of the RFC. 

O An optional checksum has been added to the krb-error message.  I
  want to know if anyone is aware of implementations that will break if
  they receive a message containing such a checksum that they are not
  expecting.

O A new ticket flag has been added: transited-policy-checked(12).
  Transited policy checked provides a means by which an application
  server can be sure that the destination realms policy on the
  authentication path has been checked and that the transited path in
  the ticket is acceptable.  It allows an application server to skip
  the check if it accepts the policy of the end realm.  Application
  servers that do not possess the information needed to check 
  the policy on their own must reject an authentication request unless
  either the transited field is empty, or this bit is set.  

O A new KDC option has been added: disable-transited-check(26), which
  prevents the KDC (if its policy allows) from applying the transited
  realm check described above.  If the check is not performed, the
  transited-policy-checked flag will not be set in the issued ticket.

O A new ticket flag has been added ok-as-delegate(13). This flag does
  not conceptually fit into the ticket flags, so discussion is
  sought.  It indicates that the server named in the ticket is a
  suitable target for delegation.  The version of this flag returned in
  the TGS reply (and encrypted in the key known to the client) can be
  used by the client to help it decide whether to forward credentials
  to a server or otherwise provide it a proxy.

O A Triple-DES encryption method and string to key algorithm has been
  specified. 

O Encryption and field types have been reserved for the PKINIT,
  PKCROSS, and OTP/SAM extensions.  Other constants previously
  released in the 1510 eratta document have been specified in the new
  list.  

O The expected uses for the authorization data field have been
  more clearly explained, and warnings about potential mis-uses
  provided.  Other misconceptions about authorization have been
  dispelled. 

O The method for selecting encryption methods by the KDC and assigning
  key types for the generated session key have been specified for
  situations where multiple encryption methods are possible.

O Requirements on the length of bitstrings for options and tickets
  have been specified.  These fields should be generated as multiples
  of 32 bits and have a minimum length of 32 bits.

O Words have been added regarding TCP support for messages to and
  from the KDC.

O A possibly controversial example of subkey negotiation has been added.

O The sender address in the KRB_SAFE and KRB_PRIV messages have been
  made optional.  There may be some interoperability issues to be
  discussed here and discussion may be required.

O Other minor changes to wording have been made in many places.

O The till field in the KDC request (i.e. the requested endtime) is
  now optional.  If left out, it implies a request for the greatest
  endtime allowed by policy.  There are existing implementations that
  already omit this field (I think when requesting ticket renewal).
  Unfortunately, there are implementations that also currently break
  under this condition - treating the request as for an endtime at
  time zero. 

O A new KDC option has been added: request-anonymous(14), has been
  added which asks the KDC to assign an anonymous principal identfier.
  If allowed by the policy of the realm, the policy of the realm will
  specify a particular principal name (suggested anonymous@realm) that
  will be assigned in the ticket.  Additionally, the anonymous flag
  will be set in the ticket.  The response will be the same otherwise,
  and will be returned protected by the appropriate keys (the TGT
  session key, the users key, or any other key specified by
  preauthentication options) so that it may be decrypted by the client.
  This change is subject to discussion regarding whether it is a
  significant change, and whether it can be part of the 1510 revisions.

O A new ticket flag anonymous(14) has been added as described in the
  previous paragraph.  This change is subject to discussion regarding
  whether it is a significant change, and whether it can be part of
  the 1510 revisions. 

O Numerous editorial and minor technical changes were made in response
  to comments from John Linn.

*********************************************************************
---------------------------------------------------------------------
*********************************************************************
Questions that need to be answered:

O  Compliant servers (must/should) support communication over TCP.

O  Compliant implementations (must/should) support the Triple-DES
   SHA encryption method.

O  How much to deprecate Single-DES/MD5, Single-DES/MD4,
   Single-DES/CRC.

O Where all existing implementations implement one of the deprecated
  methods incorrectly, do we change the spec to confirm with existing
  implementation, or do we define a new deprecated method to support
  the existing methods (note that the method ID would then be wrong).

*********************************************************************
---------------------------------------------------------------------
*********************************************************************
Responses to suggested changes that did not result in changes:


O Assar Westerlund <[e-mail]> writes:
       Requirements on the length of bitstrings for options and tickets
       have been specified.  These fields should be generated as multiples
       of 32 bits and have a minimum length of 32 bits.
     Why should this restriction be incorporated?  Given that the
     specification is using ASN.1/DER, why not follow it?

  While DER does guarantee a single way of encoding a particular bit
  string, but a bit string of "0001" is a different bit string that "1",
  and DER does not specify how long the bit string is that should be
  encoded.

O Stephen Farrell <[e-mail]> Writes:
    I have a use for etype and kytpe for 112/128 bit 3des (EDE) 
    with MD5 hashing (old hardware just doesn't go away:-)
    If you could add these transforms, I'd appreciate it. If it helps
    to contribute text, I can probably do that early next month. 

  I think that the des3-cbc-md5 reserved value is what you want here.
  This definition was already in the last draft I sent out, because I
  think there were some people playing with it already. If there is to
  be text describing the method, but this should be the description of
  the implementation that had already been done - so that we don't end
  up with two definitions.  I am not sure that we want to define the
  details of these methods in the RFC, though, since I don't want to
  encourage a proliferation of methods.

O Mike Swift writes: 
     If one of the goals is compatibility with the MIT release of Kerberos,
     then there should be additional documentation on how the MIT release
     uses ASN.1 encoding. Specifically:
     - Maximum time is Unix maximum time (some time in 2037)
     - Minimum time is Unix minimum time (1/1/70)
     - I believe the CRC-32 in MIT Kerberos implementation doesn't start off
     with an initial value of 0xfffffff and finally xor with 0xffffffff (per
     the official spec. of CRC-32)

  The behavior should be defined for maximum and minimum time when these
  fields are not present in terms of: present - clock skew, and
  infinity.  These values are usually adjusted by other constants.  With
  the change to deal with a missing "till" field, I am not aware of any
  protocol issues for which this remains ambiguous.

  Regarding CRC 32, I think this is an implementation and not a
  protocol spec issue, but it does play in with one of the "questions"
  regarding incorrect implementation of various methods.

*********************************************************************
---------------------------------------------------------------------
*********************************************************************
Items for which further discussion is needed:

O Walt Tuvell at OpenGroup, and a few other people, indicated that the
  transited field should contain an ordered list of the realms that were
  transited.  The current spec describes it as an unordered set.

     I'd like to see a discussion of the ordering/unordering of the
     transited field.  It is currently spec'ed to be unordered.  While I
     have become convinced there is no *security* advantage to either
     ordering or unordering, there is a considerable *performance*
     advantage to be had by spec'ing it to be ordered.  Since this is the
     way all[?] known implementations currently operate, making this change
     would would cause no appreciable damage on installed base.

  The original rationale was that by leaving the list unordered, better
  compression of the field is possible.   In fact, the compression
  algorithm that is described and implemented in the MIT release does
  not preserve ordering.

  Further, the order of the fields in the transited field does not
  affect the security implications at all since it is the presence of an
  untrusted realm that causes problems, and once compromised, passing
  through trusted realms should not increase ones confidence in the
  authentication process.

  If there were a decision to support ordered fields here, it would
  require the identification of a new transited-encoding value to
  indicate that the ordering must be preserved.  We would probably still
  want to remove the first and last realms entirely since both their
  presence and position can be inferred from the principal names in the
  ticket.  We could specify that an uncompressed transited field is
  ordered, but without a new transited-encoding value, this would not
  prevent subsequent realms in the path from choosing to compress the
  field, losing the ordering information.

  My personal view here is that there is not much to be gained from
  making this field ordered and in the absence of significant arguments
  for it, the complication of creating yet more transited encodings is
  not worth it.

O Gene Hilborn <[e-mail]> suggested the inclusion of a service
  interface that would indicate what parts of Kerberos are exposed to
  the higher level applications.  While I don't feel that specifying an
  API is appropriate for the protocol specification, a section
  specifying what information should be made available through an API is
  appropriate and I will draft such a section for the next draft.

O Doug Engert suggests (and a similar suggestion from Mike Swift):

     o The KRB_TGS_REP message be extended to allow for the client's TGS
       to return, in addition to a ticket for the "closest" realm, an
       authentication path which should be used to obtain the tickets to get
       to the end-service's realm. (See RFC-1510 Section 3.3.3.) 

    Without this, either the client has to (1) rely on a hierarchy path
    model of authentication, (2) maintain a configurable authentication
    path table, or (3) rely on each of the intermediate TGS's to know the
    path to the end-service's realm.

    (1) Has the problem as stated above that different implementations of
    kerberos have implemented the notion of a hierarchy differently. (2)
    Has the maintenance problem of having this table on the client. (3)
    Has the problem of the intermediate TGS's having to know the path to
    the end-server's TGS. 

    The MIT Kerberos V5-1.0 release has the configurable authentication
    path code which implements non-hierarchical authentication paths which
    can be used to solve the above problems, but it suffers from a
    maintenance view-point, and requires intermediate realms to also
    maintain the authentication paths to all the other realms.

    These two changes as outlined above, remove the responsibility of the
    client, end-service and intermediate TGS's of having to know or to
    check authentication paths. They place the responsibility on the
    client's TGS to supply the path to the end-service's realm, and for
    the end-service's TGS to check the authentication path. The changes
    also streamline the processing, reduce the maintenance and allow for
    the handling of the additional information being proposed by "pk-init"
    and "pk-cross".

  I am reluctant to include this as part of the current revision.  It is
  not necessary for interoperability, and it introduces a number of
  issues that are likely to require significant discussion.  I would
  suggest that this be proposed as the subject of a separate draft, and
  that this information be included in one of the returned
  pre-authentication fields in the KDC reply.

O Matt Hurr suggests:
     The revisions to the KRB-ERROR message add the optional e-cksum field (see
     excerpt below).  As was suggested in the draft "Integrity Protection for
     the Kerberos Error Message", presented at the Memphis IETF, I propose that
     the optional e-cksum field be changed to an optional sequence that
     specifies a type and value pair
     e.g.
	 TypedData ::=  SEQUENCE {
		     data-type    [1] INTEGER,
		     data-value   [2] OCTET STRING,
	 }

     The KRB-ERROR message would then change as follows:
     KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
	     pvno[0]                       INTEGER,
	     msg-type[1]                   INTEGER,
	     ctime[2]                      KerberosTime OPTIONAL,
	     cusec[3]                      INTEGER OPTIONAL,
	     stime[4]                      KerberosTime,
	     susec[5]                      INTEGER,
	     error-code[6]                 INTEGER,
	     crealm[7]                     Realm OPTIONAL,
	     cname[8]                      PrincipalName OPTIONAL,
	     realm[9]                      Realm, -- Correct realm
	     sname[10]                     PrincipalName, -- Correct name
	     e-text[11]                    GeneralString OPTIONAL,
	     e-data[12]                    OCTET STRING OPTIONAL,
	     e-typed-data[13]              SEQUENCE TypedData OPTIONAL
     }

     This would allow for any number of data types to be defined and
     returned in any KRB-ERROR message regardless of the error code.
     Currently, any additional data that is returned in a KRB-ERROR
     message is explicitly bound to the error code; this solution
     would allow for extensibility. 

     A checksum e-typed-data type would be defined as follows:
        data-type = CHECKSUM
        data-value = Checksum (as defined in RFC 1510)

  My view on this is that the extensibility is nice, but it is a
  little bit confusing to have the two e-data fields (a typed one and
  untyped one).  Further, I think that the e-cksum should be pulled
  out as a separate optional field as per the last draft.  Thus, the
  issue to be discussed is whether to add an option e-typed-data
  field in addition to the e-cksum field.

O Marc Horowitz submitted an internet draft regarding the derivation
  of encryption keys used for different purposes (checksums,
  confidentiality, etc) within the Kerberos protocol.  These are
  changes to existing practice and I am reluctant to include these
  changes in the revised spec, but there should be some discussion of
  these items and whether any of the proposals should be considered.
  While they are canges to existing practice, it might be possible to
  include the changes (if we consider them worthwhile) in the definition
  of new encryption types for which there is not existing practice
  (actually - it is this compromise that Marc proposes in the internet
  draft) 

O A framework for clarifying authorization data field values is needs
  to be defined so that the behavior of KDC's and application servers
  is better defined for the case when the specific interpretation of
  the field is not understood.

O Mike Swift writes:
  How to use Kerberos in cross-national environment where some servers
  support long key lengths and some support only 40 bit encryption (for
  export reasons). The two approaches I've come up with are two either (a)
  introduce shorter key encryption types or (b) make the client and server
  negotiate a session key (using the USE_SESSION_KEY AP option). In this
  case, the client needs to be able to tell the server what size
  encryption key it supports.

O There were several objections to the particular example chosen for
  subkey negotiation.

*********************************************************************
---------------------------------------------------------------------
*********************************************************************
Items for which changes are planned:

O Updates to references suggested by Gene Hilborn

  1) DES: The cited FIPS 46 (1977) is obsolete by 15 years, and does not
  even allow software implementation.  The current standard is FIPS 46-2,
  December 1993, which does allow software implementation.

  2) The DES CBC mode: The concept of "DES in CBC mode" is used with no
  definition or reference.  The standard is "DES MODES OF OPERATION," 1980
  December 2, National Bureau of Standards.

  3) DES-MAC checksum: The standard reference is missing in RFC 1510.  The
  calculation procedure is described, but the actual standard is only
  cited in RFC 1964.  It should be

  "National Bureau of Standards, Federal Information Processing Standard
  113, "Computer Data Authentication", May 1985.

  The "DES MODES OF OPERATION" standard is FIPS-PUB-81.

O  [e-mail] (Nathan Neulinger) Writes:
   I am looking for code examples on how to do some of the following
   functions: (The examples should work with MIT kerberos v5 1.0pl1.)

     o Verify a password is correct

     o Change a password, given the user's old password (I suppose I could
       look at kpasswd source for this one.)

     o Change a password, given an admin instance's password

     o Perform other standard administrative functions normally done
       by kadmin.  

  Samples will be provided for the first function, and a few other
  functions.  However, the last two functions listed (and part of the
  second) are specific to the admin protocol and not the base Kerberos
  protocol, so their inclusion is not appropriate for this draft.

O Marc Horowitz asked for clarification on the order of processing of
  preauth fields if preauth is required and these fields were returned
  to the client in the KRB_ERROR message.  In particular, it needs to
  be clear whether there are cases where multiple fields apply, or if
  only one option is to be selected.

O More information will be provided regarding the use of TCP as a
  supported transport for communication with the KDC.  One of these
  changes was suggested by Assar Westerlund who asked that we specify:
    that the client should close its side of the TCP connection (with i.e.
    shutdown) to signal that the packet has ended.  It makes life easier
    for the KDC and the client is anyway not going to send more data.

O As suggested by Assar Westerlund:
     we should add a type for IPv6 addresses in 8.1?  There's not any
     value for `AF_INET6' in draft-ietf-ipngwg-bsd-api-07.txt so I
     guess we will have to come up with a value on our own.

O A better discussion of some of the extensions that use the pa-data
  fields including SAM/OTP, PKINT, PKTAPP, and PKCROSS.  They will not
  be defined, but the ability to use the fields for things like these
  functions will be stated.

O The pseudocode needs to be updated to specify the processing of the
  e-type field and selection of encryption methods.

O Pseudocode regarding the transited checking in the KDC must be added.

O Pseudocode setting the ok-for-delegation flag must be added.

O Pseudocode for other changes in the list above is needed.

O The definition for SHA checksum types must be added